APGR Ingeniera de Software I

Ciclos de vida y metodologas

1
I
INTRODUCCIN A LA
INGENIERA DE SOFTWARE

Modelos de ciclos de vida


Ciclo de vida de cascada


Desarrollado a finales de los sesenta, el modelo en cascada es el
ciclo de vida ms practicado en el desarrollo de software.

Tambin conocido como modelo lineal secuencial. Sugiere un
enfoque sistemtico y secuencial del desarrollo del software que comienza
en el nivel de definicin del producto y progresa con el anlisis, diseo,
codificacin, pruebas y mantenimiento.






Anlisis del
sistema
Anlisis de
requisitos
Diseo
Codificacin
Pruebas
Mantenimiento
APGR Ingeniera de Software I
Ciclos de vida y metodologas

2
El modelo lineal secuencial es el paradigma ms antiguo y
extensamente usado. Entre los problemas que se encuentran algunas veces
se incluyen:

Los proyectos raras veces siguen el modelo secuencial propuesto.

A menudo es difcil que el cliente exponga explcitamente todos los
requerimientos como el modelo lo requiere. Por lo tanto, los
requerimientos deben ser correctos y estables.


El cliente debe tener paciencia ya que toma demasiado tiempo el ver
los resultados; no se puede ejecutar o mostrar el producto hasta que
se produce el cdigo. Una versin del trabajo no estar disponible
hasta que el proyecto est muy avanzado.

Retrasa la deteccin de errores hasta el final. Los resultados y errores
se ven hasta la ltima etapa de codificacin.

No promueve la construccin de prototipos.


Ciclo de vida de cascada recurrente


Modelo en cascada propuesto por Winston Royce con bucles de
retroalimentacin.




Anlisis del
sistema
Anlisis de
requisitos
Diseo
Codificacin
Pruebas
Mantenimiento
APGR Ingeniera de Software I
Ciclos de vida y metodologas

3
El modelo de construccin de prototipos


Comienza con la recoleccin de requerimientos. El desarrollador y el
cliente encuentran y definen los objetivos globales para el software e
identifican los requerimientos conocidos. Entonces aparece un diseo
rpido, el cual lleva a la construccin del prototipo.

El diseo rpido se centra en una representacin de esos aspectos del
software que sern visibles para el usuario/cliente. El prototipo es evaluado
por el cliente y lo utiliza para refinar los requerimientos del software a
desarrollar.



Escuchar
al cliente
Construir/
revisar maqueta
El cliente prueba
la maqueta
Escuchar
al cliente
Construir/
revisar maqueta
El cliente prueba
la maqueta



Desventajas:

El desarrollador a menudo hace compromisos de implementacin
para hacer que el prototipo funcione rpidamente. Se puede utilizar
un sistema operativo o lenguaje de programacin inadecuado,
simplemente porque est disponible o es conocido.

El cliente ve lo que parece ser una versin del trabajo de software,
sin saber que con la prisa de hacer que funcione no se ha tenido en
cuenta la calidad del software global o la facilidad de mantenimiento
a largo plazo. Cuando se informa que el producto se debe construir
otra vez para poder mantener un nivel alto de calidad, el cliente no lo
entiende (no lo acepta).
APGR Ingeniera de Software I
Ciclos de vida y metodologas

4
Ciclo de vida incremental


Las limitaciones del modelo en cascada han sido ms que evidentes.
Barry Bohem ha sugerido que el desarrollo del software puede ser realizado
en una serie de incrementos: de esta manera, existira una serie de ciclos
de vida en cascada, uno para cada incremento.

El ciclo de vida incremental combina elementos del modelo lineal
secuencial (aplicados repetitivamente) con la filosofa interactiva de
construccin de prototipos.

Aplica secuencias lineales, donde cada secuencia lineal produce un
incremento (versin) del software. El modelo incremental es interactivo
por naturaleza.

Cuando se utiliza un modelo incremental, el primer incremento a
menudo es un producto esencial (ncleo). Es decir, se afrontan requisitos
bsicos, pero muchas funciones suplementarias quedan sin extraer. Como
un resultado de la evaluacin se desarrolla un plan para el siguiente
incremento.

En cada nueva etapa, el sistema va teniendo mayor funcionalidad
hasta llegar al nivel deseado.


VERSIN 1 PRUEBAS DISEO ANLISIS PLANEACIN VERSIN 1 PRUEBAS DISEO ANLISIS PLANEACIN
VERSIN 2 PRUEBAS DISEO ANLISIS PLANEACIN VERSIN 2 PRUEBAS DISEO ANLISIS PLANEACIN
VERSIN 3 PRUEBAS DISEO ANLISIS PLANEACIN VERSIN 3 PRUEBAS DISEO ANLISIS PLANEACIN



Ejemplo: Un software de tratamiento de texto desarrollado con el
paradigma incremental podra extraer funciones de gestin de archivos
bsicos y de produccin de documentos en el primer incremento; funciones
de edicin ms sofisticadas en el segundo incremento; correccin
ortogrfica y gramatical en el tercero; y as sucesivamente.



APGR Ingeniera de Software I
Ciclos de vida y metodologas

5
Ciclo de vida en espiral Modelo de Boehm


En el modelo en espiral, el SW se desarrolla en una serie de
versiones incrementales. Cada espiral representa una fase (por ejemplo: la
espiral interna representa el estudio de factibilidad, la segunda sera la
definicin de requerimientos, la siguiente el diseo, etc.).

Las espirales se dividen en un nmero de actividades estructurales,
tambin llamadas regiones de tareas. Por ejemplo: determinar objetivos,
evaluar alternativas e identificar riesgos, desarrollar el producto de entrada
a la siguiente fase, planeacin de la siguiente fase, etc.

No existen fases predefinidas en este modelo; las fases mostradas en
la siguiente figura son meramente ejemplos. El administrador del proyecto
debe decidir cmo estructurar el proyecto en fases, ya que stas no estn
preestablecidas; sino que dependen del proyecto especfico.







APGR Ingeniera de Software I
Ciclos de vida y metodologas

6
Desarrollo rpido de aplicaciones - DRA


Es un modelo de proceso del desarrollo de software lineal secuencial
que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA
es una adaptacin a alta velocidad del modelo lineal secuencial en el que
se logra el desarrollo rpido utilizando un enfoque de construccin basado
en componentes (programas reutilizables). Si se comprenden bien los
requerimientos y se limita el alcance del proyecto, el proceso DRA permite
al equipo de desarrollo crear un sistema completamente funcional dentro de
periodos cortos de tiempo.

Si una aplicacin puede modularse de forma que permita
completarse cada una de las funciones principales en menos de tres meses,
es un candidato del DRA.

El DRA tiene algunos inconvenientes:

Para proyectos grandes aunque por escalas, el DRA requiere recursos
humanos suficientes como para crear el nmero correcto de equipos
DRA.
DRA requiere clientes y desarrolladores comprometidos en las
rpidas actividades necesarias para completar un sistema en un
marco de tiempo abreviado.

No todas las aplicaciones son apropiadas para DRA. Si un sistema no
se puede modularizar adecuadamente, la construccin de los
componentes necesarios para DRA ser problemtico. DRA no es
adecuado cuando los riesgos tcnicos son altos. Esto sucede cuando
una nueva aplicacin hace uso de tecnologas nuevas, o cuando el
nuevo software requiere un alto grado de interoperatividad con
programas de computadora ya existentes.


APGR Ingeniera de Software I
Ciclos de vida y metodologas

7




APGR Ingeniera de Software I
Ciclos de vida y metodologas

8
Metodologas de desarrollo de
software


Una metodologa (o paradigma) de Ingeniera de SW puede ser
considerada como una lista de reglas y guas, combinadas con
notacin grfica para modelar los requerimientos y el diseo de un
sistema.

Una metodologa cuenta con un conjunto de mtodos, procesos,
procedimientos, tcnicas y herramientas (organizados dentro de un
ciclo de vida).

Las metodologas ms conocidas son:
- Estructuradas
- Orientadas a objetos

Cualquier metodologa contiene los siguientes elementos:



Sistema de Calidad
Ciclo de Vida
Procesos de Soporte y Administracin
Etapa
1
Etapa
2
Etapa
n Procedimientos
Tcnicas
Herramientas
Procesos Procesos Procesos



APGR Ingeniera de Software I
Ciclos de vida y metodologas

9
Metodologas estructuradas

Las tcnicas estructuradas aparecieron a finales de los 60s con la
introduccin de la programacin estructurada; el diseo estructurado
apareci a mediados de los 70s.

El anlisis y diseo estructurado fueron originalmente caracterizados
por dos herramientas grficas de modelado diagramas de flujo de datos y
diagramas de estructura que enfatizaban las funciones realizadas por un
sistema; componentes adicionales que incluye la metodologa son
diccionario de datos, especificacin de procesos, etc. Formas ms recientes
de anlisis estructurado han incorporado diagramas entidad-relacin y
diagramas estado-transicin que ayudan al ingeniero de software a modelar
los datos y el comportamiento dependiente del tiempo de un sistema.

Ejemplo: Metodologa estructurada propuesta por Yourdon / De Marco.

Metodologas orientadas a objetos

Las tecnologas de programacin orientadas a objetos fueron discutidas
a finales de los 60s por el grupo de trabajo del lenguaje SIMULA; a finales
de los 70s, investigadores de Xerox PARC desarrollaron un lenguaje
conocido como SmallTalk-80. Y la primera versin del ahora popular
lenguaje C++ fue desarrollado por Bjarne Stroustrup en los laboratorios
Bell en 1981.

Pero, qu significa orientado a objetos?

Abstraccin de datos. En lugar de descomposicin funcional, las metodologas
OO enfatizan la abstraccin de datos.
Encapsulacin. La esencia del enfoque OO es el concepto de empaquetar o
encapsular datos y funciones juntos, de tal manera que la nica forma de acceder
los datos sea mediante la invocacin de las funciones asociadas.
Herencia. Permite que un objeto herede tanto datos como funciones de objetos
de mayor nivel.
Comunicacin a travs de mensajes. En un sistema OO, la arquitectura consiste
de una red de objetos asncronos que se comunican mediante el envo de
mensajes de unos a otros.
Diagramas principales. Diagramas de casos de uso y Diagramas de clases.


Ejemplos: Booch, OMT, OOSE, Fusin, UML.