¿¿Funcionalidad - Arquitectura - Atributos - Escenarios??
Conseguir un
rendimiento extremadamente rápido no es posible, lo que si es posible
diseñar una arquitectura que cumpla con su funcion para la cual fue creada de
una forma rapida, eficiente y eficaz en donde varios componentes o sub-sistemas
interrelacionados colaboren en la realización de la función.
Los atributos
de calidad debemos tenerlos en cuenta al momento de diseñar una arquitectura de
software pero es aquí donde esos atributos son diferentes de acuerdos a las
prioridades y necesidades del proyecto y/o servicio para la cual se hace uso
del sistema.
Cuando nos
refiramos a los atributos de calidad tenemos que tener en cuenta que estos
siguen una determinadas "reglas" o pasos que no siempre se pueden
cumplir según sea el escenario donde se van a aplicar estos atributos
de calidad, también tenemos que tener en cuenta que dependiendo de
cada estimulo se puede tener diferentes soluciones lo cual me parece que el
arquitecto tiene que darse cuenta de este tipo de situaciones.
En mi opinión el arquitecto nunca va ha seguir unos pasos determinados para hacer escenarios y añadir atributos de calidad pero si debe tener en cuenta algunos detalles que se especifiquen según las modificabilidades o funciones de cada sistema.
Como ya
sabemos existen varios escenarios de calidad y que cada uno de estos pueden ser
tan importante como cualquier otro pero su importancia depende de las
necesidades del sistemas, los requerimientos, la disposición, la
modificabilidad, el rendimiento, la seguridad, usabilidad pero todo esto no es
posible si no existe una comunicación clara y exacta entre
los escenarios que es otro de los aspectos que debe tener en cuenta
un arquitecto de software, ademas que cada escenario interactua con diferente y
muchos atributos ademas recordemos que cada tipo de escenario usa su modo
de comunicación para interactuar con los atributos que a su vez son
las mismas funcionalidades básicas, intermedias y avanzadas que puede
hacer el sistema.
Por nuestra parte algo que nos gusto y nos llamo
la atención es que el uno de los capítulos dice "otros
atributos de calidad" es algo que el arquitecto de software pueda usar e
implementar dependiendo las necesidades del sistemas porque los atributos
convencionales no siempre llegan a cumplir o cubrir con todo lo que pide el
sistema en desarrollo.
La
arquitectura de software se tiene que centrar y apuntar hacia el negocio y este
a la vez debe poseer unas cualidades que
la hagan un producto de calidad.
Por ejemplo
si se analiza el caso de Twitter. ¿Por qué es tan sencillo y lo utilizan muchas
personas? Básicamente, porque es usable (en este caso amigable y simple) y
tiene un corto tiempo de respuesta para el usuario (performance). ¿Qué pasa con
la disponibilidad? ¿Twitter funciona 24 horas los siete días de la semana? La
respuesta es no.
Cuando
queremos hacer algo que pone en riesgo el rendimiento de Twitter, aparece una
pantalla con un mensaje que nos explica que “Twitter sobrepasó su capacidad”),
lo cual indica que el sitio no se cayó, pero, en ese momento, no se puede
operar. No obstante, no hay dudas de que, cuando está bien, es rápido y usable.
Ahora, ¿qué pasaría si Twitter permitiera 50.000 caracteres en vez de 140? ¿Qué
impacto cree que tendría en la performance? ¿En la disponibilidad? ¿Y en la
facilidad de uso?
Para
crear una aplicación de tal magnitud y que cumpla estas características se pensó
y enfoco en el negocio unas cualidades muy fundamentales como:
Tiempo de comercialización: El tiempo de desarrollo es un
elemento crucial a lo hora de tener un producto con calidad.
Costo y
beneficio: No se debe superar los costos presupuestados.
Vida proyectada del sistema: Si el sistema va a tener una
vida útil larga, debe cumplir con los siguientes parámetros: modificabilidad,
escalabilidad y portabilidad.
Mercado de destino: Determinar para quien va
dirigido el producto.
Plan de puesta en servicio: En particular, el sistema debe
construirse con la facilidad de expansión y contracción en mente.
Además de
las cualidades del sistema y cualidades relacionadas con negocio de la organización en el que se está
desarrollando el sistema, también hay cualidades directamente relacionados con
la arquitectura que son importantes para alcanzar.
Integridad Conceptual: Es la consideración más
importante durante la fase de desarrollo, por lo cual tiene que ser correcto y unificar
o integrar el diseño del sistema en todos los niveles.
Exactitud e integridad: Son elementos muy importantes para la arquitectura para que
todos los requisitos del sistema deban cumplirse
Edificabilidad: Siempre estar abierto a cambios
y que sean de fácil aplicación.
No hay comentarios:
Publicar un comentario