El Proceso Unificado de Desarrollo de Software
El Proceso Unificado de Desarrollo de Software
El Proceso Unificado de Desarrollo de Software
Ing. En Software
ASIGNATURA:
INGENIERO:
MATRICULA:
13-011-0770
12-011-0610
11-011-0641
NOMBRE DE LA ACTIVIDAD:
Proceso Unificado
FECHA DE ENTREGA:
01 – Febrero – 2018
El Proceso Unificado de Desarrollo de Software
El Proceso Unificado es un proceso de software genérico que puede ser utilizado para
una gran cantidad de tipos de sistemas de software, para diferentes áreas de
aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y
diferentes tamaños de proyectos.
Provee un enfoque disciplinado en la asignación de tareas y responsabilidades
dentro de una organización de desarrollo. Su meta es asegurar la producción de
software de muy alta calidad que satisfaga las necesidades de los usuarios finales,
dentro de un calendario y presupuesto predecible.
El Proceso Unificado se basa en componentes (component-based), lo que significa
que el sistema en construcción está hecho de componentes de software
interconectados por medio de interfaces bien definidas (well-defined interfaces).
El Proceso Unificado usa el Lenguaje de Modelado
Unificado (UML) en la preparación de todos los
planos del sistema. De hecho, UML es una parte
integral del Proceso Unificado, fueron
desarrollados a la par.
Los aspectos distintivos del Proceso Unificado
están capturados en tres conceptos clave: dirigido
por casos de uso (use-case driven), centrado en la
arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace único
al Proceso Unificado.
El Proceso Unificado es dirigido por casos de uso
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir
un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios
prospectos.
Un caso de uso es una
pieza en la funcionalidad
del sistema que le da al
usuario un resultado de
valor. Los casos de uso
capturan los
requerimientos
funcionales. Todos los
casos de uso juntos
constituyen el modelo de casos de uso el cual describe la funcionalidad completa del
sistema. Este modelo reemplaza la tradicional especificación funcional del sistema.
Una especificación funcional tradicional se concentra en responder la pregunta:
¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser
definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas
tres palabras tienen una implicación importante, nos fuerzan a pensar en términos
del valor a los usuarios y no solamente en términos de las funciones que sería bueno
que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para
especificar los requerimientos del sistema, también dirigen su diseño,
implementación y pruebas, esto es, dirigen el proceso de desarrollo.
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada.
Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso
dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección
de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso
maduran conforme avanza el ciclo de vida.
El Proceso Unificado es Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que puede
continuar por varios meses o años. Es práctico dividir el trabajo en pequeños pedazos
o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en un
incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos
se refieren a crecimiento en el producto. Para ser más efectivo, las iteraciones deben
estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera
planeada.
Los desarrolladores basan su selección de qué van a implementar en una iteración
en dos factores. Primero, la iteración trata con un grupo de casos de uso que en
conjunto extienden la usabilidad del producto. Segundo, la iteración trata con los
riesgos más importantes. Las iteraciones sucesivas construyen los artefactos del
desarrollo a partir del estado en el que fueron dejados en la iteración anterior.
En cada iteración, los desarrolladores identifican y especifican los casos de uso
relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño
en componentes y verifican que los componentes satisfacen los casos de uso. Si una
iteración cumple sus metas – y usualmente lo hace – el desarrollo continúa con la
siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores
deben revisar sus decisiones previas y probar un nuevo enfoque.