18
DE JUNIO DEL 2014
SEMANA # 3
SEMANA # 3
INTRODUCCIÓN
El Proceso Unificado no es
simplemente un proceso, sino un marco de trabajo prolongable que puede ser
adaptado a organizaciones o proyectos específicos para así de esta manera
llegar al objetivo planeado.
El Proceso Unificado
reconoce la importancia de la comunicación con el cliente y los métodos
directos para describir su punto de vista respecto de un sistema (el caso de
uso).
MARCO TEÓRICO
PROCESO UNIFICADO
El
proceso unificado es un intento por obtener los mejores rasgos y
características de los modelos tradicionales del proceso del software, pero en
forma que implemente muchos de los mejores principios del desarrollo ágil de
software.El Proceso Unificado es un marco de desarrollo iterativo e
incremental compuesto por cuatro fases.
FASES DEL PROCESO
UNIFICADO
Al
principio de este capítulo se estudiaron cinco actividades estructurales
generales y se dijo que podían usarse para describir cualquier modelo de
proceso del software. El proceso unificado no es la excepción. La figura que se
ilustra a continuación muestra las “fases” del PU y las relaciona con las
actividades generales ya estudiadas. La fase de concepción del PU agrupa
actividades tanto de comunicación con el cliente como de planeación. Al
colaborar con los participantes, se identifican los requerimientos del negocio, se
propone una arquitectura aproximada para el sistema y se desarrolla un plan
para la naturaleza iterativa e incremental del proyecto en cuestión. Los
requerimientos fundamentales del negocio se describen por medio de un conjunto
de casos de uso preliminares que detallan las características y funciones
que desea cada clase principal de usuarios. En este punto, la arquitectura no
es más que un lineamiento tentativo de subsistemas principales y la función y
rasgos que tienen. La arquitectura se mejorará después y se expandirá en un
conjunto de modelos que representarán distintos puntos de vista del sistema. La
planeación identifica los recursos, evalúa los riesgos principales, define un
programa de actividades y establece una base para las fases que se van a
aplicar a medida que avanza el incremento del software.
La
fase de elaboración incluye las actividades de comunicación y modelado del
modelo general del proceso La elaboración mejora y amplía los casos de uso
preliminares desarrollados como parte de la fase de concepción y aumenta la
representación de la arquitectura para incluir cinco puntos de vista distintos
del software: los modelos del caso de uso, de requerimientos, del diseño, de la
implementación y del despliegue. En ciertos casos, la elaboración crea una
“línea de base de la arquitectura ejecutable” [Arl02] que representa un sistema
ejecutable de “primer corte”.20 La línea de base de la arquitectura demuestra
la viabilidad de ésta, pero no proporciona todas las características y
funciones que se requieren para usar el sistema.
Además,
al terminar la fase de elaboración se revisa con cuidado el plan a fin de
asegurar que el alcance, riesgos y fechas de entrega siguen siendo razonables.
Es frecuente que en este momento se hagan modificaciones al plan.
La
fase de construcción del PU es idéntica a la actividad de construcción definida
para el proceso general del software. Con el uso del modelo de arquitectura
como entrada, la fase de construcción desarrolla o adquiere los componentes del
software que harán que cada caso de uso sea operativo para los usuarios finales.
Para lograrlo, se completan los modelos de requerimientos y diseño que se
comenzaron durante la fase de elaboración, a fin de que reflejen la versión
final del incremento de software. Después se implementan en código fuente todas
las características y funciones necesarias para el incremento de software (por
ejemplo, el lanzamiento).
A
medida de que se implementan los componentes, se diseñan y efectúan pruebas
unitarias para cada uno. Además, se realizan actividades de integración
(ensamble de componentes y pruebas de integración). Se emplean casos de uso
para obtener un grupo de pruebas de aceptación que se ejecutan antes de
comenzar la siguiente fase del PU.
La
fase de transición del PU incluye las últimas etapas de la actividad general de
construcción y la primera parte de la actividad de despliegue general (entrega
y retroalimentación). Se da el software a los usuarios finales para las pruebas
beta, quienes reportan tanto los defectos como los cambios necesarios. Además,
el equipo de software genera la información de apoyo necesaria (por ejemplo,
manuales de usuario, guías de solución de problemas, procedimientos de
instalación, etc.) que se requiere para el lanzamiento. Al finalizar la fase de
transición, el software incrementado se convierte en un producto utilizable que
se lanza.
La
fase de producción del PU coincide con la actividad de despliegue del proceso
general.
Durante
esta fase, se vigila el uso que se da al software, se brinda apoyo para el
ambiente de operación (infraestructura) y se reportan defectos y solicitudes de
cambio para su evaluación.
Es
probable que al mismo tiempo que se llevan a cabo las fases de construcción,
transición y producción, comience el trabajo sobre el siguiente incremento del
software. Esto significa que las cinco fases del PU no ocurren en secuencia
sino que concurren en forma escalonada.
El
flujo de trabajo de la ingeniería de software está distribuido a través de
todas las fases del PU. En el contexto de éste, un flujo de trabajo es análogo
al conjunto de tareas. Es decir, un flujo de trabajo identifica las tareas
necesarias para completar una acción importante de la ingeniería de software y
los productos de trabajo que se generan como consecuencia de la terminación
exitosa de aquéllas. Debe notarse que no toda tarea identificada para el flujo
de trabajo del PU es realizada en todos los proyectos de software. El equipo
adapta el proceso (acciones, tareas, subtareas y productos del trabajo) a fin
de que cumpla sus necesidades.
CONCLUSIÓN
Un
proceso es un conjunto de pasos ordenados para obtener un objetivo. En ingeniería
de software, el objetivo es edificar un producto de software nuevo o extender
uno existente.
BIBLIOGRAFÍA
Pressman,
R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
