Que es la arquitectura de software?
Existen muchas definiciones, pero mucha basta con chequear el conjunto de definiciones que publica el sei (Instituto de ingeniería de software) : http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
Yo tengo una definición personal, la pueden criticar pero no van a poder negar que es simple: La arquitectura de software son las decisiones que tomamos para satisfacer los requerimientos no funcionales (o atributos de calidad)
Hablo de requerimientos no funcionales o atributos de calidad, que sería eso? Bueno, son requerimientos que no describen una funcionalidad, sino que definen atributos para medir la calidad. Veamos un ejemplo:
- La aplicación no debe demorar más de 50 segundos en listar las ordenes diarias procesadas.
- Debe permitir que solo un usuario con permisos pueda autorizar un pedido.
- Un usuario novato debe ser capaz de crear un pedido en 1 hora.
- Debe permitir agregar un campo nuevo a la pantalla en menos de 1 día.
Como se puede ver los requerimientos no funcionales necesitan decisiones muy importantes para poder satisfacerlos. Las cuales son muy pero muy difícil cambiar luego de haberlas tomado. Por lo tanto es muy importante analizar los requerimientos no funcionales y definir la arquitectura y además documentarla.
Que quede muy claro, olvidarse un requerimiento no funcional puede ser critico y podemos perder un proyecto o atrasarnos mucho. Es decir podemos perder mucho dinero!! Por lo tanto no tomarse el tiempo de analizar la arquitectura es una irresponsabilidad.
Una buena practica es hacer un pequeño cuadro en el cual se listan los requerimientos no funcionales y las decisiones que tomamos para solucionarlos.
Además existe un proceso de desarrollo de arquitectura de software que debe ser respetado:
- Analizar requerimientos, puff, tenemos que leer todos los requerimientos y detectar los requerimientos no funcionales que muchas veces se ocultan entre los requerimientos funcionales. Luego de encontrarlos debemos documentarlos y checkearlos con los usuarios.
- Diseño: Debemos diseñar la solución.
- Documentar: Debemos documentar la solución y luego debemos ver si es coherente, además si se entiende. Para esto se puede recurrir a las revisiones por pares.
- Evaluación: Esto se va ir haciendo a medida que se diseña y se documenta. A la vez juega un rol importante las revisiones por pares.
- Implementación: A trabajar! Pico, pala, sudor, un poco de inspiración y suerte. Debemos programar todo lo que diseñamos, y si algo falla o no se puede implementar volver al inicio de la lista :P
Como se puede ver el rol de arquitecto de software no es fácil y necesita que los desarrolladores, funcionales y testers, lo ayuden constantemente.
