Actividades a lo largo del ciclo vital:
-
Introducción
-
Actividades de la fase inicial
-
Actividades de la fase de elaboración
-
Actividades de la fase de construcción
-
Actividades de la fase de transición
El desarrollo basado en componentes es una variación del desarrollo general de aplicaciones en el que:
-
La aplicación se ensambla a partir de componentes ejecutables discretos que se desarrollan y
despliegan de forma relativamente independiente, potencialmente por equipos diferentes.
-
La aplicación se puede actualizar en incrementos más pequeños mediante la actualización de únicamente
los componentes que componen la aplicación.
-
Los componentes se pueden compartir entre aplicaciones mediante la creación de oportunidades de
reutilización, y también mediante la creación de dependencias entre proyectos.
-
Aunque no está estrictamente relacionado con el hecho de estar basado en componentes, las aplicaciones basadas
en componentes suelen ser distribuidas.
En esta página, se utiliza el término "componente" para hacer referencia a componentes desplegables y desarrollados
independientemente. En el resto de RUP, sin embargo, se utiliza en un sentido más general que se describe en Concepto: Componente y se califica como necesario.
La adaptación de Rational Unified Process (RUP) para manejar los retos del desarrollo basado en componentes se trata
más abajo.
Se aplica el flujo de trabajo básico para la fase inicial, con las
siguientes ampliaciones o variaciones:
Gestión de proyectos
-
Actividad: Concebir un proyecto nuevo
-
El foco de la Tarea: Desarrollar caso de negocio se ajusta para que tenga
en cuenta que la utilización de componentes cambia la estructura de costes del desarrollo. Específicamente, el
coste de desarrollar componentes disminuye, pero se necesita más esfuerzo para identificar componentes y
comprobar que los componentes seleccionados satisfacen los requisitos.
-
Actividad: Planificar el proyecto
-
En la Tarea: Planear fases e iteraciones, el plan de la fase de
construcción tiene el potencial para mostrar la división del proyecto en dos seguimientos diferentes pero
paralelos: uno que desarrolla componentes específicos del dominio y específicos de la aplicación (organizado en
las capas superiores de la arquitectura; consulte el apartado Concepto:
Creación de capas) y otro que desarrolla los componentes que no son específicos del dominio ni de la
aplicación y que se organizan en las capas inferiores. En algunos casos, los equipos de desarrollo gestionados
independientemente desarrollarán componentes reutilizables. La decisión de introducir seguimientos paralelos es
un aspecto de personal y recursos conducido por un deseo de gestionar componentes reutilizables como activos
independientes de las aplicaciones en que se despliegan.
Requisitos
-
Actividad: Perfeccionar la definición del sistema
-
Cuando se perfeccionan los requisitos del sistema, deben capturarse las restricciones que impone la
infraestructura del componente seleccionado. Las infraestructuras de componentes aumentan la productividad de
desarrollo, en parte restringiendo los grados de libertad que se ofrecen al arquitecto y el diseñador de
software. La Tarea: Detallar los requisitos de software debe centrarse en
documentar estas restricciones.
Prueba
Entorno
-
Actividad: Preparar el entorno para el proyecto
-
Cuando recopile y prepare directrices para el proyecto, consulte la Tarea: Preparar directrices para el proyecto para obtener
detalles, tenga en cuenta la infraestructura de componentes específica y las restricciones que impone. Las
directrices deben incluir cómo diseñar y codificar utilizando la infraestructura. También deberían proporcionar
instrucciones de prueba sobre cómo comprobar la conformidad con la infraestructura de componentes y las
interfaces definidas entre componentes.
Se aplica el flujo de trabajo básico para la fase de
elaboración, con las siguientes ampliaciones o variaciones:
Requisitos
-
Actividad: Perfeccionar la definición del sistema
-
La Tarea: Detallar los requisitos de software también se centra
en las restricciones y los requisitos técnicos y no funcionales que imponen los componentes construidos o
adquiridos. Los requisitos no funcionales específicos que se deben considerar son el tamaño, el rendimiento, la
impresión en la memoria o el disco, los aspectos de la licencia de tiempo de ejecución y otras restricciones
similares que influirán en la construcción o la selección del componente.
Análisis y diseño
-
Actividad: Diseñar componentes
-
La Tarea: Diseño del subsistema perfecciona aún más el diseño de
los componentes, identificando las clases del componente que proporcionan el comportamiento real del
componente. Al principio de la fase de elaboración, es probable que haya una sola clase, un tipo de 'proxy de
componente/subsistema' que actúa como un fragmento para simular el comportamiento del componente para crear
prototipos arquitectónicos. Más adelante, el comportamiento de esta clase se distribuye en una colaboración de
clases contenidas en el subsistema. Estas clases contenidas se perfeccionan en la Tarea: Diseño de clase.
-
Actividad: Diseñar la base de datos
-
El aspecto más importante de la elaboración es garantizar que la estrategia de permanencia es escalable y que
el mecanismo de permanencia y el diseño de bases de datos soportarán los requisitos de rendimiento del sistema.
Las clases permanentes se identifican y se correlacionan con el mecanismo de permanencia. Los casos de uso de
datos intensivos se analizan para garantizar que los mecanismos serán escalables. Junto con las actividades de
prueba, se valora y se valida el mecanismo de permanencia y el diseño de bases de datos.
Implementación
Prueba
-
Actividades: Definir la misión de evaluación, Verificar el enfoque de prueba, Probar y evaluar, Conseguir una misión aceptable, Aumentar los activos de prueba
Las actividades de prueba de la fase elaboración se centran en validar la arquitectura. Para un sistema basado
en componentes, se centran en:
-
ejercitar las interfaces entre componentes para garantizar que los límites del componente son adecuados
-
una atención mayor en la prueba de rendimiento, especialmente en las pruebas de escala de rendimiento, para
garantizar que se pueden sostener los volúmenes de transacción anticipados
También es necesario valorar las suposiciones inherentes de la infraestructura de componentes. Estas
suposiciones suelen ser la escalabilidad y el rendimiento de los mecanismos de gestión de la transacción y la
permanencia, donde el diseñador de mecanismos efectúa suposiciones ocultas que a menudo socavan eficazmente la
arquitectura de la aplicación si no conoce la suposición.
Gestión de proyectos
-
Actividad: Planear la siguiente iteración
Si se utilizan los subsistemas de implementación como 'unidades lógicas de responsabilidad', el trabajo de
construcción se puede particionar en dos o más "seguimientos" paralelos: uno que se centra en las funciones
específicas de la aplicación y uno o varios que se centran en componentes genéricos reutilizables. Por
supuesto, esto depende de si se tienen los recursos humanos suficientes para esfuerzos de desarrollo paralelo.
La capacidad de dividir los equipos de desarrollo y trabajar en paralelo depende totalmente de la estabilidad
de la arquitectura y, más específicamente, de la calidad y la estabilidad de las interfaces entre los
componentes. Esta división será posible si se realiza un esfuerzo enorme en la fase de elaboración.
Se aplica el flujo de trabajo básico para la fase de
construcción, con las siguientes ampliaciones o variaciones:
Gestión de proyectos
-
Actividad: Planear la siguiente iteración
Anteriormente se describió la planificación de la primera iteración de construcción, igual que sucede hacia el
final de la elaboración. Igual que la planificación de la iteración, la capacidad de dividir los equipos de
desarrollo y trabajar en paralelo sigue dependiendo de la estabilidad de la arquitectura y la calidad y la
estabilidad de las interfaces entre los componentes.
Análisis y diseño
-
Actividad: Diseñar la base de datos
El aspecto principal de la construcción es terminar el diseño de la base de datos y asegurarse de que todas las
clases permanentes son soportadas tanto por la base de datos como por el mecanismo de permanencia. Este trabajo
se realiza en paralelo y de forma repetitiva con el trabajo que se realiza en la Actividad: Perfeccionar la arquitectura y la Actividad: Diseñar componentes. La organización ideal
consiste en contar con equipos de componentes integrados, y con coordinación entre equipos de los asuntos de
permanencia para garantizar un buen diseño de base de datos.
Implementación
Prueba
Las pruebas de rendimiento siguen siendo importantes, aunque cada vez se presta más atención a las pruebas
funcionales. Deben tenerse en cuenta la completitud de la funcionalidad, las pruebas de revisión de la
funcionalidad existente y la satisfacción de las expectativas de rendimiento.
-
El release del producto en el entorno web suele ser incremental y continuo, y se centra menos en la
distribución tradicional de medios de soporte. La planificación del release debe ajustarse en consecuencia.
-
El soporte de producción es cada vez más importante en la fase.
-
Se realizan actividades de conversión de datos.
|