Procesos Complejos

Ingeniería del Software II 2011
Tema 2. Procesos de desarrollo de software
complejos.
Definición de modelo de proceso.
Un modelo de proceso es un conjunto de actividades que conducen a la creación de un
producto software, no existe un proceso ideal y su composición depende del sistema software
a desarrollar, por lo tanto existen diferentes modelos o enfoques para el desarrollo de
software y distintas representaciones abstractas.
Los modelos no se excluyen mutuamente y a menudo se usan conjuntamente en el desarrollo
de sistemas grandes.
Aunque todos los modelos de proceso son complejos se suelen clasificar en:
Modelos de procesos pesados:



Gran esfuerzo de planificación, diseño y documentación.
Grandes equipos, normalmente dispersos espacialmente.
Proyecto de larga duración o de gran tamaño.
Modelos de procesos ligeros o ágiles:



Si se busca la entrega de un software funcional en un tiempo corto.
Como respuesta a unos requerimientos cambiantes.
Para el desarrollo de aplicaciones pequeñas o específicas (pequeños negocios,
software con muy pocas funcionalidades o de poca complejidad).
Tipo de modelos de proceso.
Desarrollo evolutivo
Bases:




Requerimientos que cambian en el tiempo y
exposición continúa a la crítica del usuario.
Plazos estrictos de finalización (competencia) .
Buena comprensión del producto básico, pero poca definición de los detalles.
Dirigido por prototipos (modelos): desarrollo iterativo y gran refinamiento a través de
las diferentes versiones del sistema.
1
Problemas:






Convertir un prototipo en producto final (mala calidad). El cliente ve lo que parece ser
una versión funcional, cuando se le dice que hay que rehacerlo no lo entienden y piden
unos pequeños “arreglos”. El desarrollador cede.
Pobre interacción entre las partes. Elementos no adecuados (S.O., Interfaces,
Algoritmos,…) que permanecen y pasan a formar parte del producto final cuando sólo
lo eran del prototipo.
La evolución del proceso es dificil de gestionar y cuantificar.
Requiere herramientas y técnicas especiales para llevarse a cabo.
Poco adecuado para grandes sistemas o sistemas muy complejos.
¿Cuándo terminamos?
Se parará el desarrollo cuando el producto sea de calidad y cumpla con los requisitos del
cliente.
Ventajas:




Satisface las necesidades inmediatas del cliente.
La especificación de requisitos se puede realizar de modo creciente.
Este modelo de proceso facilita la comprensión del nivel de complejidad de la actividad
de desarrollar software por parte del usuario/cliente.
Gran especificación de los requisitos. No es necesario conocerlos todos para comenzar
el desarrollo.
Los prototipos son versiones funcionales o no funcionales del sistema que sirven para valorar y
corregir el desarrollo del software.
Prototipo evolutivo:


Trabajo con el cliente para explorar sus requerimientos y poder plasmarlos en el
sistema final.
Sirve como evaluación continua y punto de control del cliente sobre las
funcionalidades que se vayan implementando y la validación de las ya implementadas.
Prototipo desechable:



Fomenta la comprensión de las necesidades del cliente.
Permite desarrollar una definición mejorada de los requerimientos del sistema.
Se pueden centrar para definir o analizar requisitos poco claros o complejos.
Desarrollo Incremental
Bases:


Es un enfoque intermedio entre el modelo en cascada y el desarrollo evolutivo.
Se identifican y priorizan las funciones y servicios del sistema.
2



Se definen los requerimientos que proporcionan una o varias funcionalidades
concretas y se priorizan por importancia.
Se realiza una definición detallada de los requerimientos a incluir en cada incremento
y el sistema de desarrollo más adecuado para dicho
incremento.
Se integran los nuevos requerimientos implementados y
se validan hasta que el sistema está completo.
Problemas:




Los incrementos deben ser relativamente pequeños.
Adaptar los requerimientos dentro de un incremento de
un tamaño concreto es difícil (estimar la carga de trabajo
y el tiempo).
La identificación de los recursos comunes a todos los
incrementos es difícil de identificar.
Es necesario conocer bien el sistema para poder ordenar
correctamente las funcionalidades.
Ventajas:




Temprana implementación.
Los incrementos iniciales permiten refinar los
incrementos posteriores ya que ayudan a conocer el
sistema y sus necesidades.
El cliente observa el avance del proyecto lo que reduce el riesgo de cancelación del
mismo.
Se consigue un sistema final muy testeado y por lo tanto con pocos fallos.
Al contrario que en el evolutivo, intentamos identificar la mayoría de los requisitos. Al tener la
perspectiva global del sistema, repartimos los requisitos en trozos que vamos a ir
desarrollando en vueltas obteniendo cada vez un producto más complejo.
Priorización de requisitos: se implementan primero las partes con mayor prioridad, las más
importantes.
El sistema final está muy probado y con pocos fallos; al desarrollarse las partes más
importantes al principio y realizar pruebas a cada vuelta, estas funcionalidades están muy
probadas y tienen una baja propensión a fallar.
Proceso Unificado del Desarrollo del software.
Propuesto por los autores de UML (lenguaje unificado de desarrollo).
Principales aspectos definitorios:

Dirigido por casos de uso.
3


Centrado en la arquitectura.
Iterativo e incremental.
Describe un enfoque para la construcción, desarrollo y mantenimiento del software, está
pensado principalmente sobre el paradigma de orientación a objetos y constituye un marco
de trabajo genérico que puede adaptarse fácilmente y que es comúnmente aceptado como el
adecuado.



Basado en componentes interconectados a través de interfaces.
Utiliza UML para desarrollar los esquemas y diagramas de un sistema software.
Abarca: ciclos, fases, flujos de trabajo, gestión de riesgos, control de la calidad, gestión
y planificación del proyecto, control de la configuración y automatización de los
procesos.
Propone dividir el sistema en trozos fáciles de desarrollar, estas divisiones se comunican a
través de interfaces.
Propone desarrollar vistas estáticas y dinámicas (vista del modelo de ejecución y de la
estructura del sistema).
Proceso integrado de desarrollo que abarca ciclos, fases, flujos, controles de calidad, etc.
Dirigido por Casos de Uso.
Para construir un sistema con éxito hay que conocer las necesidades y deseos de los futuros
usuarios.
Usuario:


Personas que trabajan y necesitan el sistema
Otros sistemas que interactúan con el que estamos
desarrollando
Interacción:



Usuario inserta tarjeta en cajero automático.
Usuario responde sobre la pantalla a las preguntas
que realiza el cajero.
El usuario recibe una cantidad de dinero y su tarjeta.
4
Una interacción así es un caso de uso:

Fragmento de funcionalidad del sistema que proporciona al usuario un resultado
importante.
Utilidad casos de uso:
-
Herramienta para especificar los requisitos de un sistema: representan los requisitos
funcionales y juntos constituyen el modelo de casos de uso, que describe la
funcionalidad total del sistema.
-
Guían el proceso de desarrollo (diseño, implementación y prueba).



-
Basándose en el modelo de casos de uso, se crean modelos de diseño e
implementación.
Se revisa cada modelo para que sean conformes al modelo de casos de uso.
Se prueba la implementación para garantizar que los componentes del modelo de
implementación implementan correctamente los casos de uso.
No sólo inician el proceso de desarrollo sino que éste sigue un hilo de trabajo que
parte de los casos de uso.
Los casos de uso constituyen una técnica para recopilar requisitos de usuario, historias del
manejo de un sistema, etc.
Otros sistemas externos también pueden interactuar con el nuestro.
Los casos de uso guían el proceso. Son indispensables para desarrollar el resto de actividades;
tanto otros diagramas como todo tipo de actividades.
Se usan para todo en todo el sistema.
Inician el proceso y son el flujo conductor del mismo.
Interacción: secuencia de acciones. Una sola acción no constituye un caso de uso.
Centrado en la arquitectura.
La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en
construcción:



Influida por diversos factores:
o
Necesidades de la empresa, tal y como las perciben los usuarios y clientes.
o
Otros factores, como plataforma de explotación (arquitectura hardware,
sistema operativo, gestor de bases de datos, protocolos de comunicación,...),
componentes reutilizables, sistemas heredados, requisitos no funcionales...
Es una vista del diseño completo con las características más importantes resaltadas,
dejando los detalles de lado.
Hay una constante interacción entre los casos de uso y la arquitectura, que
evolucionan en paralelo:
5

o
Los casos de uso deben encajar en la arquitectura cuando se realizan.
o
La arquitectura debe permitir el desarrollo de todos los casos de uso
requeridos.
El arquitecto
o
Realiza un esquema en borrador de la arquitectura que no es específica de los
casos de uso (por ejemplo, la plataforma).
o
Trabaja con un subconjunto de los casos de uso principales del sistema,
especificándolo en detalle y realizándolo en términos de subsistemas, clases y
componentes.
o
A medida que los casos de uso se especifican y maduran, se descubre más de
la arquitectura, lo que a su vez lleva a la maduración de más casos de uso
o
Este proceso continúa hasta que se considera que se dispone de una
arquitectura estable.
o
El Proceso Unificado del Desarrollo del software permite:

Ganar y retener el control intelectual sobre el proyecto para así administrar la
complejidad del sistema.

Facilita el desarrollo basado en componentes.

Provee una base efectiva para la reutilización código.
6

Provee de una base para la gestión del proyecto.
Arquitectura: manera de describir un sistema mediante diferentes vistas.
Está influida por diversos factores: necesidades de la empresa, hardware, requisitos no
funcionales, sistemas heredados, etc.
La elección de arquitectura tiene que ver con varios factores como la seguridad.
El proceso unificado es centrado en la arquitectura porque se enfatiza el uso de esas vistas y la
arquitectura se desarrolla en paralelo al sistema.
Facilidad para controlar el proyecto, administración de complejidad. Facilita el entendimiento
del sistema, con mayor o menor complejidad.
Iterativo e incremental.
El trabajo se divide en partes más pequeñas o miniproyectos:

Miniproyecto: una iteración que resulta en un incremento:
o
o
o

Factores para seleccionar lo que se implementará en una iteración:
o
o

La iteración se centra en un grupo de casos de uso que juntos amplían la
utilidad del producto desarrollado hasta ahora.
La iteración trata los riesgos más importantes.
Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como
quedaron al final de la última iteración:
o
o

Iteración: pasos en el flujo de trabajo.
Incremento: crecimiento del producto.
Las iteraciones están controladas y planificadas.
En las primeras fases del ciclo de vida los incrementos implican
modificaciones.
En las últimas fases los incrementos implican menos modificaciones y más
añadidos a los modelos.
Cada iteración se compone de los siguientes pasos:
o
o
o
o
o
Identificación y especificación de los casos de uso relevantes.
Creación de un diseño utilizando la arquitectura seleccionada como guía.
Implementación del diseño mediante componentes.
Verificación de que los componentes satisfacen los casos de uso.
Si una iteración cumple con sus objetivos, el desarrollo continúa con la
siguiente iteración. Si no, se revisan las decisiones previas y se adopta un
nuevo enfoque.
Ventajas:
7





Reducción del coste del riesgo a los costes de un solo incremento.
Reducción del riesgo de no sacar al mercado el producto en el calendario previsto.
Se acelera el ritmo del esfuerzo de desarrollo en su totalidad, para obtener resultados
claros a corto plazo.
Los requerimientos del usuario se van refinando en iteraciones sucesivas, por lo que se
pueden acomodar mejor los cambios.
Mantiene un equilibrio entre definir un conjunto concreto de requisitos al inicio del
desarrollo y la realidad donde los requisitos varían a lo largo del proyecto.
Los riesgos se reducen a una iteración debido a las pruebas de cada incremento.
Mayor entendimiento del sistema, se acelera el ritmo.
Refinamiento de los requisitos en sucesivas iteraciones.
El Proceso Unificado del Desarrollo del software se repite a lo largo de una serie de ciclos.
Cada ciclo concluye con una nueva “versión” del producto y consta de cuatro fases divididas a
su vez en iteraciones.




Inicio. Descripción del producto a partir de una idea inicial y análisis del negocio.
o Principales funciones del sistema y usuarios más importantes (modelos de
casos de uso).
o Es posible que se diseñe arquitectura del sistema.
o Plan del proyecto, coste y gestión de riegos.
o Visión y especificación complementaria, glosario y otros artefactos.
Elaboración. Se diseñan todas las partes y se constituye la arquitectura del sistema.
o Se especifican en detalle los principales casos de uso.
o Se diseña el núcleo central de la arquitectura del sistema.
o Prosigue la gestión de riesgos.
o Se obtiene el modelo de dominio y el modelo conceptual del sistema a
desarrollar.
o Se implementa y prueba la arquitectura.
o Se planifican las actividades y se estiman los recursos necesarios para finalizar
el proyecto de un modo realista.
o Se crean nuevas versiones de todos los artefactos y manuales preliminares
para los usuarios del sistema.
Construcción. En esta fase se construye (codifica) el sistema en sí.
o Se crea el producto añadiendo el software a la arquitectura.
o Se ejecuta el plan planificado y se codifican todas las partes del sistema.
Transición. Se valida y verifica el producto.
o Se prueba el producto mediante un entorno real donde los usuarios analizan
sus defectos y deficiencias.
o Se corrigen los problemas y se incorporan las sugerencias de los usuarios.
o Se terminan todos los artefactos.
o Se adjuntan licencias, contratos y referencias de soporte.
o Se maquetan manuales de usuario, operador y administrador.
8
o
Puede impartirse formación sobre
el sistema.
División en miniproyectos: una iteración que resulta
en un incremento. Con cada iteración es muy
posible que obtengamos alguna funcionalidad.
Cada iteración se centra en un grupo de casos de
uso empezando por los que tengan mayor riesgo.
Las iteraciones se construyen sobre los artefactos
tal y como quedaron al final de la última iteración;
entendiendo como artefacto cualquier documento o archivo resultante de la anterior
iteración.
Es un proceso iterativo controlado.
9