Un arquitecto de software propone el contenido técnico y el orden de varias iteraciones sucesivas seleccionando
un determinado número de casos de ejemplo y guiones de uso para analizarlos y diseñarlos. Los distintos equipos de
desarrollo completan y perfeccionan esta propuesta técnica, según la disponibilidad del personal, los requisitos del
cliente en términos de entregables, la disponibilidad de las herramientas y los productos COTS, y las necesidades de
otros proyectos.
La selección de casos de ejemplo y guiones de uso que se consideran "significativos arquitectónicamente" (por ej., que
constituyen la vista de guión de uso de la arquitectura) viene dictada por algunos factores clave que se resumen a
continuación.
-
La ventaja que supone el caso de ejemplo para los interesados: crítica, importante, útil.
-
El impacto del caso de ejemplo en la arquitectura: ninguno, la amplía, la modifica. Pueden existir guiones de uso
críticos que tengan poco o ningún impacto en la arquitectura, y guiones de uso con pocas ventajas que tengan un
gran impacto. El gestor de proyectos debe revisar los guiones de uso con pocas ventajas que tengan un gran impacto
en la arquitectura para determinar si se tiene que eliminar algún ámbito.
-
Los riesgos que se deben migrar (rendimiento, disponibilidad de un producto e idoneidad de un componente).
-
La finalización de la cobertura de la arquitectura (asegurarse de que al final de la fase de elaboración, todas las
partes del software que se tienen que desarrollar hayan encontrado un lugar en la vista de implementación).
-
Otros objetivos tácticos o restricciones: demostraciones para el usuario, etc.
Puede haber dos casos de ejemplo que afecten a los mismos componentes y que traten riesgos similares. Si implementa A
primero, B no será significativo arquitectónicamente. Si implementa B primero, A no será significativo
arquitectónicamente. Por lo tanto, estos atributos pueden depender del orden de iteración, y se deben volver a evaluar
cuando cambie el orden, así como cuando cambien los propios requisitos.
Hay que dar prioridad a los guiones de uso significativos arquitectónicamente que no se entienden bien o que tienen
probabilidad de cambiar, para aclararlos y estabilizarlos. En algunos casos, esto significa que se deben realizar más
análisis de requisitos antes de implementar ningún requisito. En otros casos, será mejor alguna forma de
prototipo.
|