Sie sind auf Seite 1von 31

ICI 542

INGENIERA DE SOFTWARE
Dr. Cristian Rusu
cristian.rusu@ucv.cl

3. Modelos del proceso de


software
n

Un modelo de proceso software es


una descripcin del proceso, desde un
punto de vista particular
Un modelo es siempre una
simplificacin del proceso software,
una abstraccin del proceso real

3. Modelos del proceso de


software
Ejemplos:
n
Modelo de flujo de trabajo representa la sucesin
de actividades (acciones humanas) en el proceso,
en conjuncin con sus entradas, salidas y
dependencias
n
Modelo flujo de datos representa un conjunto de
actividades, cada una produciendo alguna
transformacin en los datos; los actividades son de
menor nivel que las de un modelo de flujo de
trabajo y pueden representar acciones humanas o
de las computadoras
n
Modelo de rol/accin representa los roles de la
gente involucrada en el proceso de software y las
actividades de cual son responsables

3. Modelos del proceso de


software
n

Los modelos generales del proceso software


(paradigmas del proceso software) son
abstracciones tiles para explicar diferentes
enfoques para el desarrollo de software
Para desarrollar un sistema muy complejo,
se pueden utilizar diferentes paradigmas
para diversas partes del sistema

3.1. El modelo de

cascada
n

El primero modelo de proceso de desarrollo


de software, derivado de otros procesos de
ingeniera (Royse, 1970)
Se denomina tambin ciclo de vida del
software
Representa las actividades fundamentales
del proceso como fases separadas de esto
El modelo se denomina cascada

3.1. El modelo de

cascada
Definicin de
requerimientos
Diseo de sistemas y
de software
Implementacin y
prueba de unidades
Integracin y prueba
del sistema
Operacin y
mantenimiento

3.1. El modelo de

cascada
1.

2.

Anlisis y definicin de requerimientos los


servicios, restricciones y metas del sistema se
definen en detalles, a partir de las consultas a
los usuarios/clientes
Diseo de sistemas y de software el diseo
de sistemas establece los requerimientos de
hardware/software y establece la arquitectura
del sistema; el diseo de software identifica y
describe las abstracciones fundamentales del
sistema de software y sus relaciones

3.1. El modelo de

cascada
3.

4.

5.

Implementacin y prueba de unidades se obtiene un


conjunto de unidades y/o programas; cada uno debe
cumplir su especificacin
Integracin y prueba del sistema los unidades
individuales se integran y prueban como sistema
completo, que debe cumplir el conjunto de
requerimientos establecidos
Operacin y mantenimiento el sistema se instala y se
pone en marcho (uso prctico); se corrigen los errores
no descubiertos etapas anteriores, se mejora la
implementacin de las unidades, los servicios del
sistema, se establecen (eventualmente) nuevos
requerimientos

3.1. El modelo de

cascada
El modelo de cascada es inflexible en dividir el
proyecto en etapas separadas
Refleja la practica de la ingeniera, por lo tanto
se siguen utilizando para el desarrollo de
software, particularmente cuando ste es parte
de proyectos grandes (de ingeniera de
sistemas)
En la practica:

n
n

Las etapas interaccionan y intercambian


informaciones
El proceso no es un modelo lineal; requiere
iteraciones de las actividades de desarrollo

3.1. El modelo de

cascada
n

Las iteraciones son costosas e implican rehacer el


trabajo, por lo tanto es normal congelar partes del
desarrollo despus de un numero reducido de
iteraciones
El congelamiento prematuro de requerimientos puede
implicar que el sistema no va a hacer lo que los
usuarios desean, o que se obtiene un sistema mal
estructurado
Tambin puede ocurrir la necesidad de repetir algunos
(o todas las) etapas previas del proceso, debido a los
errores y omisiones que se descubren, o a la
necesidad de nuevas funcionalidades

3.2. El desarrollo evolutivo


(basado en prototipos)
n

Se desarrolla una implementacin inicial,


exponindola a los comentarios del usuario y
redefinindola a travs de varias versiones
Las actividades de especificacin, desarrollo y
validacin se llevan a cabo concurrentemente, y
tienen realimentacin (rpida) a lo largo del
proceso
Una primera versin de sistema se desarrolla
rpidamente, a partir de especificaciones
abstractas, y se refina despus, con la ayuda del
cliente

3.2. El desarrollo evolutivo


(basado en prototipos)
n

Un enfoque evolutivo para el desarrollo de


software es ms efectivo que el de cascada,
porque cumple con las necesidades
inmediatas de los clientes
La especificacin se puede desarrollar de
forma creciente
Permite un mejor entendimiento de las
necesidades de los usuarios, con
consecuencia directa en el sistema software

3.2. El desarrollo evolutivo


(basado en prototipos)
Desde la perspectiva de ingeniera y administracin, el
desarrollo evolutivo es complejo:
n El proceso no es visible si los sistemas se desarrollan
rpidamente, es (muy) costoso generar la
documentacin asociada
n Frecuentemente los sistemas tienen estructura deficiente
los frecuente cambios tienden a debilitar la estructura
del software
n Requiere herramientas y tcnicas especficas
relativamente pocas personas tenien las
competencias/habilidades necesarias para utilizarlas

3.2. El desarrollo evolutivo


(basado en prototipos)
Esquema de la
descripcin
Especificacin

Versin inicial

Desarrollo

Versiones intermedias

Validacin

Versin final

3.2. El desarrollo evolutivo


(basado en prototipos)
n

Adecuado para sistemas pequeos (menos de 100.000


instrucciones) o medianos (hasta 500.000 instrucciones),
con un periodo de vida relativamente corto
Para sistemas grandes, con un periodo de vida largo, es
ms eficiente un proceso mixto, que rena las mejores
caractersticas del modelo cascada y del desarrollo
evolutivo:
n

Las partes del sistema bien comprendidas, se especifican y


desarrollan utilizando un proceso basado en el modelo cascada
Las partes difcil de especificar desde un inicio se desarrollan
utilizando un enfoque de programacin exploratoria

3.3. El desarrollo formal


n

n
n

Enfoque parecido al modelo de cascada,


pero el proceso de desarrollo se basa
en la transformacin matemtica formal
de una especificacin del sistema a un
programa ejecutable
El desarrollo de software es incremental
Cada etapa se desarrolla y verifica
utilizando el enfoque formal

3.3. El desarrollo formal

Definicin de
requerimientos

Especificacin
formal

Transformacin
formal

Integracin y
prueba del sistema

3.3. El desarrollo formal


n

La especificacin formal se refina a travs


de una serie de transformaciones, hasta
llegar a un programa
La representacin matemtica formal del
sistema se convierte sistemticamente en
representaciones mas detalladas,
matemticamente correctas, cada paso
agregando mas detalles

3.3. El desarrollo formal


n

n
n

El enfoque por transformaciones compuestas de


pasos pequeos es adecuado para sistemas de
gran escala
Por este tipo de sistemas las pruebas son muy
largas y pocas practicas
Qu transformacin aplicar?
Como probar la correspondencia entre
transformaciones?

3.4. El desarrollo basado en


reutilizacin
n

Basado en la disponibilidad de un
numero significante de componentes
reutilizables,
Los componentes se integran en el
sistema
La mayora de los proyectos software
incluyen reutilizacin de software, pero
una reutilizacin informal, emprica

10

3.4. El desarrollo basado en


reutilizacin
n

Las personas que trabajan en el


proyecto buscan diseos o cdigos
similares para (modificarlos e)
incorporarlos en el sistema
El enfoque orientado a reutilizacin
requiere componentes de software
reutilizable, as como de marcos de
trabajos especficos

3.4. El desarrollo basado en


reutilizacin
Definicin de
requerimientos
Anlisis de
componentes

Modificacin de
requerimientos

Diseo de sistemas
con reutilizacin

La primera y la ultima etapa del proceso


son similares a otros procesos, pero las
etapas intermedias son distintas!

Desarrollo e
integracin
Validacin
del sistema

11

3.4. El desarrollo basado en


reutilizacin
n

Anlisis de componentes se buscan


componentes para implementar la
especificacin de requerimientos
Modificacin de requerimientos los
requerimientos se modifican, para
adaptarlos a los componentes disponibles;
si eso no es posible, se buscan soluciones
alternativas

3.4. El desarrollo basado en


reutilizacin
n

Diseo de sistemas con reutilizacin basado en


los componentes disponibles; si no hay
componentes adecuados, se disean otros
nuevos
Desarrollo e integracin los componentes
disponibles (eventualmente) se compran, los
componentes no-disponibles se desarrollan;
todos los componentes se integran

12

3.4. El desarrollo basado en


reutilizacin
n

n
n

El modelo orientado a reutilizacin


reduce la cantidad de software a
desarrollar, los costos y los riesgos
El proceso es mas rpido
La adaptacin (compromisos en
requerimientos) es casi siembre
inevitable
Cumple el sistema las necesidades
reales de los usuarios/clientes?

3.5. Modelos de iteracin de


procesos
n

Cada modelo de proceso software tiene


ventajas y desventajas
Raras veces un modelo es completamente
adecuado para un proceso especifico
Para sistemas grandes, complejos,
generalmente deben utilizarse enfoques
distintos para distintas parte del sistema
Se deben utilizar modelos hbridos

13

3.5. Modelos de iteracin de


procesos
n

n
n

El diseo y la implementacin del sistema


requieren cambios, para adaptarse a los
cambios de los requerimientos del sistema
Son necesarios iteraciones!
En los procesos iterativos la especificacin
se desarrolla junto con el software mismo

3.5. Modelos de iteracin de


procesos
n

La especificacin completa del sistema es


disponible solo al fin del proyecto
Pueden ocurrir conflictos si la
especificacin completa del sistema es
parte del contrato
Se requiere un nuevo tipo de contrato,
que a los algunos clientes les es difcil de
aceptar

14

3.5. Modelos de iteracin de


procesos
Dos principales modelos hbridos:
n El desarrollo incremental la especificacin,
el diseo y la implementacin se dividen en una
serie de incrementos, los cuales se desarrollan
de a uno
n El desarrollo en espiral el desarrollo gira en
espiral hacia fuera, empezando con un bosquejo
inicial y terminando con el desarrollo de la
versin final del sistema

3.5.1 El modelo

incremental
El desarrollo incremental:
n Sugerido por Mills (1980)
n Enfoque intermedio que combina las
ventajas del modelo en cascada con las
ventajas del modelo de desarrollo
evolutivo
n Combina el modelo lineal secuencial con la
filosofa interactiva de construccin de
prototipos

15

3.5.1 El modelo

incremental
El modelo de desarrollo en cascada:
n Se administra fcilmente
n La separacin clara en etapas favorece el
desarrollo de sistemas robustos
n Los cambios de requerimientos durante el
desarrollo requieren rehacer el trabajo

3.5.1 El modelo

incremental
El modelo de desarrollo evolutivo:
n Permite retrasar la especificacin completa
de requerimientos y las decisiones de
diseo
n Pueden llevar a sistemas dbilmente
estructurado y difcil de mantener

16

3.5.1 El modelo

incremental
El modelo incremental:
Disminuye la repeticin del trabajo en el proceso de
desarrollo
Ofrece oportunidades para retrasar decisiones sobre
requerimientos detallados, hasta que se adquiere cierta
experiencia en el sistema
Los clientes identifican, de forma general, los servicios que
proveer el sistema, y la importancia de estos servicios
Se definen incrementos; cada uno proporcionar un
subconjunto de funcionalidades del sistema
Se entregan primero los servicios de prioridad ms alta

3.5.1 El modelo

incremental
n

Los requerimientos para los servicios de un incremento


se definen en detalle
El incremento se desarrolla utilizando el modelo de
proceso mas apropiado
Una vez que el incremento finaliza, no se aceptan
cambios en los requerimientos del mismo
El incremento est disponible una vez finalizado su
desarrollo, los clientes tendrn acceso a las
funcionalidades ofrecidas
El uso de los incrementos desarrollados permiten aclarar
requerimientos para incrementes posteriores

17

3.5.1 El modelo

incremental
n

Los nuevos incrementos, se integran a los


existentes, mejorando la funcionalidad del
sistema cada incremento
No es necesario utilizar el mismo proceso de
desarrollo por cada incremento!
Habitualmente se usa:
n

un modelo de cascada para incrementos con servicios


de especificacin bien definida
un modelo de desarrollo evolutivo si la especificacin
no est clara todava

3.5.1 El modelo

incremental
Definir
esquema de
requerimientos

Desarrollar
incrementos
del sistema

Asignar
requerimientos a
los incrementos

Validar
incrementos

Integrar
incrementos

Disear la
arquitectura del
sistema

Validar
sistema

Sistema
final

18

3.5.1 El modelo

incremental
Ventajas:
n

Los clientes no tienen que esperar hasta tener el


sistema completo, cada incremento ofrece una versin
de sistema disponible para el uso inmediato
Los primeros incrementos pueden ser utilizados como
prototipos para especificar/refinar requerimientos de los
incrementos posteriores
El riesgo de falla en el proyecto total es mas bajo,
especialmente en las partes mas importantes del
sistema; sobre los incrementos que se entregan
primeros se harn ms pruebas

3.5.1 El modelo

incremental
Problemas:
n

Los incrementos deben ser relativamente


pequeos (menos de 20.000 lneas de cdigo)
Puede resultar ser difcil adaptar los
requerimientos del cliente a incrementos de
tamao apropiado
Puede ser difcil identificar los recursos comunes
para todos los incrementos

19

3.5.2 El modelo en

espiral
El modelo en espiral:
n
n
n

Propuesto originalmente por Boehm (1988)


Es un modelo centrado en actividades
Se basa en las mismas actividades del modelo
de cascada, pero aade varias tareas:
n
n
n

Administracin de riesgo
Reutilizacin
Elaboracin de prototipos

3.5.2 El modelo en

espiral
Cada ciclo de la espiral se divide en cuatro sectores:
n
Definicin de objetivos se identifican las restricciones
del proceso y el producto, se establece el plan detallado
de administracin, se identifican los riesgos y se planean
estrategias alternativas
n
Evaluacin de alternativas y reduccin de riesgos se
hace un anlisis detallado para cada uno de los riesgos
definindose los pasos para reducir dichos riesgos
n
Desarrollo y validacin se elige el modelo apropiado por
el desarrollo del sistema, segn los riesgos identificados
n
Planeacin Se revisa el proyecto y se toma la decisin
de continuar con un ciclo posterior de la espiral, en este
caso planendose la siguiente fase

20

3.5.2 El modelo en

espiral
Cada ciclo de la espiral sigue el modelo de cascada
e incluye las siguientes actividades:
n
n
n
n
n
n
n

Determinar objetivos
Especificar restricciones
Generar alternativas
Identificar riesgos
Resolver riesgos
Desarrollar y verificar el producto del siguiente nivel
Planear

3.5.2 El modelo en

espiral

21

3.5.2 El modelo en

espiral
n

A diferencia de otros modelos, el desarrollo en


espiral toma en cuenta de forma explicita los
riesgos
La disminucin de riesgos es una actividad muy
importante en la administracin del proyecto
En el modelo en espiral no existen fases fijas,
cerradas, como la de especificacin o diseo
El modelo cascada puede incluir otros modelos

3.5.3 Proceso unificado de


desarrollo de software
n

Propuesto por Booch, Jacobson,


Rumbaugh
Similar al modelo espiral, el proceso
consta de varios ciclos
Cada ciclo termina con la entrega de un
producto al cliente

22

3.5.3 Proceso unificado de


desarrollo de software
n

Cada ciclo consta de cuatro fases:


n

n
n

Inicio se define una necesidad o idea y se evala


su factibilidad
Elaboracin se planea el proyecto, se define el
sistema, se asignan los recursos
Construccin desarrollo
Transicin instalacin y pos desarrollo

Cada iteracin responde a un conjunto de casos


de uso relacionados o resuelve un riesgo
identificado al inicio de la iteracin

3.5.3 Proceso unificado de


desarrollo de software

23

3.5.3 Proceso unificado de


desarrollo de software
n

A diferencia de otros modelos, enfatiza en


el escalonamiento de recursos
Asume que las actividades clsicas

(anlisis, diseo, implementacin,


pruebas) participan en cada una de las
iteraciones, pero en porcentajes distintas,
segn las caractersticas de cada etapa

3.5.3 Proceso unificado de


desarrollo de software
Se utiliza un conjunto de modelos relacionadas:
n
Modelo de casos de uso captura los requerimientos
n
Modelo de anlisis describe el sistema como un
conjunto de clases
n
Modelo de diseo define la estructura del sistema
como un conjunto de subsistemas e interfaces
n
Modelo de organizacin define la distribucin
n
Modelo de implementacin - establece la
correspondencia entre clases y componentes
n
Modelo de pruebas verifica que el sistema ejecutable
proporcione la funcionalidad necesaria

24

3.5.3 Proceso unificado de


desarrollo de software
Modelo de casos
de uso
Especificado por

Modelo de
anlisis

Realizado por

Modelo de
diseo

Distribuido por
Implementado por
Verificado por

Modelo de
distribucin
Modelo de
implementacin

Modelo de
pruebas

3.5.3 Proceso unificado de


desarrollo de software
n

Existen dependencia de rastreabilidad entre


todos los modelos (no solamente entre el
modelo de caso de uso y los dems)
Un elemento de un modelo puede rastrearse
por lo menos hacia un elemento de un modelo
asociado
La rastreabilidad permite entender el efecto del
cambio en un modelo sobre otros modelos

25

3.5.3 Proceso unificado de


desarrollo de software
El mantenimiento de las dependencias entre los modelos se
puede realizar por:
n
Ingeniera hacia delante los modelos de anlisis y
diseo se establecen a partir del modelo de casos de
uso, los modelos de implementacin y pruebas se
generan luego, a partir de estos
n
Ingeniera inversa los modelos de anlisis y diseo se
extraen o actualizan mediante el cdigo existente
n
Ingeniera de viaje redondo combinacin de ingeniera
hacia delante e inversa, dependiente de cul modelo
est sufriendo la mayor cantidad de cambios

3.6. Modelos centrados en


problemas
n

La mayora de los modelos de procesos


software se enfocan en las actividades de stos
Una visin alternativa es el enfocarse en los
productos creados por estas actividades
Las dos visiones son complementarias:
n

Para cada producto existe una o ms actividades que


lo generan
Cada actividad genera uno o ms productos

26

3.6.1 Perspectivas centradas


en actividades y perspectivas
centradas en entidades
n

Modelos centrados en actividades:


n

Representan de manera explicita las actividades del


proceso
Los participantes se enfocan en la manera de crear
los productos de trabajo

Modelos centrados en problemas:


n

Representan de manera explicita los productos de


trabajo
Los participantes se enfocan en el contenido y
estructura de los productos de trabajo

3.6.2 El modelo basado en


problemas
n
n

Esta centrado en entidades


Esta orientado al manejo de los cambios
frecuentes
Se puede utilizar si el tiempo entre cambios es
significativamente ms pequeo que la duracin
de una actividad
Cada proyecto empieza con la identificacin de
un conjunto de problemas
Todos los problemas estn guardados en una
base de problemas a la que tienen acceso todos
los participantes en el proyecto

27

3.6.2 El modelo basado en


problemas
n

El estado de un problema puede ser:


n
n

Cerrado ha sido resuelto


Abierto se resuelven mediante
conversaciones y negociaciones entre los
participantes en el proyecto

Un problema cerrado puede abrirse de


nuevo si ocurren cambios
Entre problemas existen dependencias

3.6.2 El modelo basado en


problemas
n

Se pueden establecer correspondencias


entre los problemas y las actividades de
otros modelos (paradigmas)
n

En el modelo en cascada los desarrolladores


resuelven por completo los problemas asociadas a
una actividad, antes de pasar a la siguiente
En el modelo espiral los riesgos corresponden a
problemas que se estn evaluando, y se vuelven a
abrir al inicio de cada ciclo

28

3.6.2 El modelo basado en


problemas
n

El uso de problemas y sus dependencias


permite que las actividades del ciclo de
vida se lleven a cabo en forma
concurrente
La administracin del proyecto es muy
importante
El administrador debe mantener la
cantidad de problemas abiertos pequea
y manejable

3.7 El estndar para el


desarrollo de procesos
software
El estndar IEEE 1074:
n Describe el conjunto de actividades y
procesos obligatorios para el desarrollo y
mantenimiento del software
n Establece un marco comn para el
desarrollo de modelos de ciclo de vida
n Ofrece ejemplos de situaciones tpicas

29

3.7 El estndar para el


desarrollo de procesos
software
Actividad tarea o grupo de subactividades que se
asignan a un equipo o a un participante del proyecto,
para lograr un propsito especfico
Proceso conjunto de actividades que se realiza para un
propsito especfico
Grupo de procesos conjunto de procesos agrupados en
un nivel superior de abstraccin
n
Las tareas usan recursos y crean un producto de
trabajo
n
Las actividades se descomponen en tareas especficas,
se le dan fechas de inicio y fin, se asignan a un
participante o a un equipo

3.7 El estndar para el desarrollo


de procesos software (IEEE
1074)
Grupo de
procesos
Modelado del ciclo de vida

Administracin del
proyecto

Predesarrollo

Procesos
n

Seleccin de un modelo de ciclo de vida

Inicio del proyecto


n Supervisin y control del proyecto
n Administracin de la calidad del software
n

Exploracin de conceptos
n Asignacin del sistema
n

30

3.7 El estndar para el desarrollo


de procesos software (IEEE
1074)
Grupo de Procesos
procesos
Desarrollo

Posdesarroll
o

Procesos
integrales

Requerimientos
n Diseo
n Implementacin
n

Instalacin
n Operacin y soporte
n Mantenimiento
n Retiro
n

Verificacin y validacin
Administracin de la configuracin del software
n Desarrollo de la documentacin
n Entrenamiento
n
n

31

Das könnte Ihnen auch gefallen