Herramientas
Herramientas
Herramientas
Introducción
Algunos factores que se deben tener en cuenta para la adaptación del proceso son
el dominio de la aplicación, las personas y factores organizativos, los factores
relacionados con el ciclo de vida del producto, o los factores de proceso como el
cumplimiento de estándares.
Una actividad es una unidad de trabajo que puede ejecutar uno o varios individuos
en un rol específico. Tiene un propósito claro expresado en términos de actualizar
un artefacto. La granularidad de una actividad es generalmente de horas o pocos
días. Ejemplos son planificar una iteración, encontrar casos de uso y actores, o
revisar el diseño.
Un recurso humano puede desempeñar uno o más roles, que le permiten ejecutar
las actividades asociadas a tales roles.
El ciclo de desarrollo del proceso unificado se divide en cuatro fases en las que los
distintos flujos de trabajo se desarrollan con distinta intensidad. Cada fase está
dividida en iteraciones. Estas cuatro fases son:
• modelado de negocio,
• requisitos,
• análisis y diseño,
• implementación,
• prueba,
• lanzamiento.
Los flujos de trabajo de apoyo o accesorios son:
• gestión de configuración,
• gestión del proyecto,
• entorno.
Los casos de uso van progresando a través de las fases. Al terminar la fase de
inicio, la mayoría del modelo de negocio ha sido terminado y la mayoría de los
casos de uso han sido identificados. Muy pocos se describen, se analizan, y mucho
menos se implementan. Al terminar la fase de elaboración el modelo de negocio
está terminado, la inmensa mayoría de casos de usos han sido identificados y
muchos de ellos han sido descritos. Algunos de ellos han sido analizados y apenas
ninguno ha sido diseñado, implementado y probado. Al terminar la fase de
construcción, todos los casos de usos tienen que haber sido identificados, descritos,
analizados, diseñados, implementados y probados.
• Se produce una mitigación, en las capas iniciales, de los riesgos más críticos
(técnicos, requisitos, objetivos, facilidad de uso, etc.).
• El progreso es visible desde muy pronto.
• La realimentación temprana, la implicación del usuario y la adaptación
conducen a un sistema refinado que satisface más estrechamente las
necesidades reales de los "usuarios".
• La complejidad se gestiona, el equipo no se abruma por la "parálisis del
análisis" o por etapas muy grandes y complejas.
• El aprendizaje que se va obteniendo en cada iteración se puede utilizar
metódicamente para mejorar el proceso de desarrollo, iteración a iteración.
A medida que se avanza en el desarrollo de la ingeniería de software se debe definir
un modelo de proceso para soportar una evolución de los planes, requisitos y
arquitectura junto con puntos de sincronización bien definidos; una gestión de
requisitos y medidas objetivas de progreso y calidad; y una evolución de las
capacidades del sistema a través de demostraciones de funcionalidad incremental.
El ciclo de vida se divide en dos etapas. La etapa de ingeniería, con equipos más
pequeños, es donde se realizan actividades menos previsibles de diseño y síntesis.
La etapa de producción es donde se realizan las actividades más previsibles
relacionadas con construcción, prueba y lanzamiento, en un equipo más grande.
Análisis, diseño,
Actividades Implementación, pruebas
planificación
Demostración, inspección,
Valoración Pruebas
análisis
Resolución de la Explotación de la
Economía
diseconomía de escala economía de escala
Gestión Planificación Operaciones
La transición entre ingeniería y producción es un evento crucial para los
"stakeholders".
Modelos
Partimos de un modelo de casos de uso que modela los casos de uso y sus
relaciones con los actores. El modelo de casos de uso es especificado por un
modelo de análisis que refina los casos de uso y realiza una visión inical del
comportamiento del conjunto de objetos. Es realizado por un modelo de diseño
que define la estructura estática del sistema como subsistemas, clases e interfaces
y define los casos de uso como colaboraciones de subsistemas, clases e interfaces.
Es implementado por un modelo de implementación que incluye componentes
representados por su código fuente y la correspondencia entre clases y
componentes. Es distribuido por un modelo de despliegue que define los nodos
físicos y establece la correspondencia entre componentes y nodos. Es verificado por
un modelo de pruebas que describe los casos de prueba que verifican los casos de
uso.
Fase de inicio
Objetivos principales:
• Un documento de visión general con los requisitos generales del proyecto, las
características principales y las restricciones.
• Un modelo inicial de casos de uso con aproximadamente un 15% de ellos
listos.
• Un glosario inicial con la terminología clave del dominio.
• Caso de negocio con un contexto, criterios de éxito y pronóstico financiero.
• Identificación inicial de riesgos.
• Plan de proyecto mostrando fases e iteraciones.
• Modelo de negocio si es necesario.
• Uno o más prototipos exploratorios para probar conceptos o la arquitectura
candidata.
El hito que marca el fin de la fase de inicio debe suponer el acuerdo entre las partes
interesadas sobre el alcance y la estimación de tiempo y coste, así como la
comprensión de los requisitos plasmados en casos de uso.
Fase de elaboración
Objetivos:
• Elaborar la visión. Desarrollar los casos de uso a un nivel que dirija las
decisiones de la arquitectura o de planificación.
• Elaborar el proceso y la infraestructura.
• Elaborar la arquitectura y los componentes seleccionados.
Productos:
El hito que marca el fin de la fase de elaboración debe cumplir los siguientes
criterios de evaluación:
• ¿Es estable la visión del proyecto?
• ¿Es estable la arquitectura?
• ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y
resueltos?
• ¿El plan de proyecto es algo realista?
• Las personas involucradas, ¿están de acuerdo con el plan?
Fase de construcción
Objetivos principales:
Fase de transición
Objetivos principales:
Arquitectura
Cada actor implicado en el proceso mira al sistema desde una perspectiva diferente
a lo largo de la vida del proyecto. La arquitectura del sistema es uno de los
productos más importantes que se pueden utilizar para gestionar estos puntos de
vista y, por tanto, para controlar el desarrollo del sistema a través de su ciclo de
vida.
Un proceso basado en casos de uso implica ajustarse a las necesidades reales del
usuario. Que esté centrado en la arquitectura quiere decir que el trabajo de
desarrollo se centra en obtener un patrón que dirigirá la construcción del sistema en
las primeras fases. La mejor forma de conseguir equilibrar casos de uso y
arquitectura, que es como equilibrar forma y función, es el desarrollo iterativo e
incremental. De esta forma se plantea una estrategia de desarrollo para productos
software basada en pequeños pasos manejables: se planifica poco, se especifica,
diseña e implementa un poco, se integra, prueba y ejecuta un poco en cada
iteración.
Un white paper de Rational en 2011 considera que RUP facilita las siguientes
buenas prácticas para desarrollo de software: