Ingenieria de Software - 3

8/19/2019 Ingenieria de Software - 3

1/31

1

ICI 542INGENIERÍA DE SOFTWARE

Dr. Cristian [email protected]

3. Modelos del proceso desoftware

n Un modelo de proceso software esuna descripción del proceso, desde unpunto de vista particular

n Un modelo es siempre unasimplificación del proceso software,

una abstracción del proceso real


2/31

2

3. Modelos del proceso de

softwareEjemplos:n Modelo de flujo de trabajo – representa la sucesión

de actividades (acciones humanas) en el proceso,en conjunción con sus entradas, salidas ydependencias

n Modelo flujo de datos – representa un conjunto deactividades, cada una produciendo algunatransformación en los datos; los actividades son demenor nivel que las de un modelo de flujo detrabajo y pueden representar acciones humanas ode las computadoras

n Modelo de rol/acción – representa los roles de lagente involucrada en el proceso de software y lasactividades de cual son responsables

3. Modelos del proceso desoftware

n Los modelos generales del proceso software(paradigmas del proceso software) sonabstracciones útiles para explicar diferentesenfoques para el desarrollo de software

n Para desarrollar un sistema muy complejo,se pueden utilizar diferentes paradigmas

para diversas partes del sistema


3/31

3

3.1. El modelo de

cascadan El primero modelo de proceso de desarrollo

de software, derivado de otros procesos deingeniería (Royse, 1970)

n Se denomina también ciclo de vida delsoftware

n Representa las actividades fundamentalesdel proceso como fases separadas de esto

n

El modelo se denomina “cascada”

3.1. El modelo decascada

Definición derequerimientos

Diseño de sistemas yde software

Implementación yprueba de unidades

Integración y pruebadel sistema

Operación ymantenimiento


4/31

4

3.1. El modelo de

cascada1. Análisis y definición de requerimientos – los

servicios, restricciones y metas del sistema sedefinen en detalles, a partir de las consultas alos usuarios/clientes

2. Diseño de sistemas y de software – el diseñode sistemas establece los requerimientos dehardware/software y establece la arquitecturadel sistema; el diseño de software identifica ydescribe las abstracciones fundamentales delsistema de software y sus relaciones


3. Implementación y prueba de unidades – se obtiene unconjunto de unidades y/o programas; cada uno debecumplir su especificación

4. Integración y prueba del sistema – los unidadesindividuales se integran y prueban como sistemacompleto, que debe cumplir el conjunto derequerimientos establecidos

5. Operación y mantenimiento – el sistema se instala y se

pone en marcho (uso práctico); se corrigen los erroresno descubiertos etapas anteriores, se mejora laimplementación de las unidades, los servicios delsistema, se establecen (eventualmente) nuevosrequerimientos


5/31

5

3.1. El modelo de

cascadan El modelo de cascada es inflexible en dividir el

proyecto en etapas separadasn Refleja la practica de la ingeniería, por lo tanto

se siguen utilizando para el desarrollo desoftware, particularmente cuando éste es partede proyectos grandes (de ingeniería desistemas)

n En la practica:n

Las etapas interaccionan y intercambianinformacionesn El proceso no es un modelo lineal; requiere

iteraciones de las actividades de desarrollo


n Las iteraciones son costosas e implican rehacer eltrabajo, por lo tanto es normal congelar partes deldesarrollo después de un numero reducido deiteraciones

n El congelamiento prematuro de requerimientos puedeimplicar que el sistema no va a hacer lo que losusuarios desean, o que se obtiene un sistema malestructurado

n También puede ocurrir la necesidad de repetir algunos(o todas las) etapas previas del proceso, debido a loserrores y omisiones que se descubren, o a lanecesidad de nuevas funcionalidades


6/31

6

3.2. El desarrollo evolutivo

(basado en prototipos)

n Se desarrolla una implementación inicial,exponiéndola a los comentarios del usuario yredefiniéndola a través de varias versiones

n Las actividades de especificación, desarrollo yvalidación se llevan a cabo concurrentemente, ytienen realimentación (rápida) a lo largo delproceso

n Una primera versión de sistema se desarrollarápidamente, a partir de especificacionesabstractas, y se refina después, con la ayuda delcliente

3.2. El desarrollo evolutivo(basado en prototipos)

n Un enfoque evolutivo para el desarrollo desoftware es más efectivo que el de cascada,porque cumple con las necesidadesinmediatas de los clientes

n La especificación se puede desarrollar deforma creciente

n Permite un mejor entendimiento de lasnecesidades de los usuarios, conconsecuencia directa en el sistema software


7/31

7


(basado en prototipos)Desde la perspectiva de ingeniería y administración, el

desarrollo evolutivo es complejo:n El proceso no es visible – si los sistemas se desarrollan

rápidamente, es (muy) costoso generar ladocumentación asociada

n Frecuentemente los sistemas tienen estructura deficiente – los frecuente cambios tienden a debilitar la estructuradel software

n

Requiere herramientas y técnicas específicas –relativamente pocas personas tenien lascompetencias/habilidades necesarias para utilizarlas

3.2. El desarrollo evolutivo(basado en prototipos)

Esquema de ladescripción

Especificación Desarrollo Validación

Versión inicial Versiones intermedias Versión final


8/31

8


(basado en prototipos)n Adecuado para sistemas pequeños (menos de 100.000

instrucciones) o medianos (hasta 500.000 instrucciones),con un periodo de vida relativamente corto

n Para sistemas grandes, con un periodo de vida largo, esmás eficiente un proceso mixto, que reúna las mejorescaracterísticas del modelo cascada y del desarrolloevolutivo:

n Las partes del sistema bien comprendidas, se especifican ydesarrollan utilizando un proceso basado en el modelo cascada

n Las partes difícil de especificar desde un inicio se desarrollanutilizando un enfoque de programación exploratoria

3.3. El desarrollo formal

n Enfoque parecido al modelo de cascada,pero el proceso de desarrollo se basaen la transformación matemática formalde una especificación del sistema a unprograma ejecutable

n

El desarrollo de software es incrementaln Cada etapa se desarrolla y verifica

utilizando el enfoque formal


9/31

9



Especificaciónformal

Transformaciónformal

Integración yprueba del sistema


n La especificación formal se refina a travésde una serie de transformaciones, hastallegar a un programa

n La representación matemática formal delsistema se convierte sistemáticamente en

representaciones mas detalladas,matemáticamente correctas, cada pasoagregando mas detalles


10/31

10

3.3. El desarrollo formaln El enfoque por transformaciones compuestas de

pasos pequeños es adecuado para sistemas degran escala

n Por este tipo de sistemas las pruebas son muylargas y pocas practicas

n Qué transformación aplicar?n Como probar la correspondencia entre

transformaciones?

3.4. El desarrollo basado enreutilización

n Basado en la disponibilidad de unnumero significante de componentesreutilizables,

n Los componentes se integran en elsistema

n La mayoría de los proyectos softwareincluyen reutilización de software, perouna reutilización informal, “empírica”


11/31

11

3.4. El desarrollo basado en

reutilización

n Las personas que trabajan en elproyecto buscan diseños o códigossimilares para (modificarlos e)incorporarlos en el sistema

n El enfoque orientado a reutilizaciónrequiere componentes de softwarereutilizable, así como de marcos detrabajos específicos



Análisis decomponentes Modificación de

requerimientos Diseño de sistemascon reutilización Desarrollo e

integración

Validacióndel sistemaLa primera y la ultima etapa del procesoLa primera y la ultima etapa del proceso

son similaresson similares aa otros procesos,otros procesos, ¡pero las¡pero lasetapas intermedias son distintas!etapas intermedias son distintas!


12/31

12


reutilización

n Análisis de componentes – se buscancomponentes para implementar laespecificación de requerimientos

n Modificación de requerimientos – losrequerimientos se modifican, para

adaptarlos a los componentes disponibles;si eso no es posible, se buscan solucionesalternativas


n Diseño de sistemas con reutilización – basado enlos componentes disponibles; si no haycomponentes adecuados, se diseñan otrosnuevos

n Desarrollo e integración – los componentes

disponibles (eventualmente) se compran, loscomponentes no-disponibles se desarrollan;todos los componentes se integran


13/31

13


reutilización

n El modelo orientado a reutilizaciónreduce la cantidad de software adesarrollar, los costos y los riesgos

n El proceso es mas rápidon La adaptación (compromisos en

requerimientos) es casi siembre

inevitablen ¿Cumple el sistema las necesidades

reales de los usuarios/clientes?

3.5. Modelos de iteración deprocesos

n Cada modelo de proceso software tieneventajas y desventajas

n Raras veces un modelo es completamenteadecuado para un proceso especifico

n Para sistemas grandes, complejos,

generalmente deben utilizarse enfoquesdistintos para distintas parte del sistema

n Se deben utilizar modelos híbridos


14/31

14

3.5. Modelos de iteración de

procesos

n El diseño y la implementación del sistemarequieren cambios, para adaptarse a loscambios de los requerimientos del sistema

n ¡Son necesarios iteraciones!n En los procesos iterativos la especificación

se desarrolla junto con el software mismo

3.5. Modelos de iteración deprocesos

n La especificación completa del sistema esdisponible solo al fin del proyecto

n Pueden ocurrir conflictos si laespecificación completa del sistema esparte del contrato

n Se requiere un nuevo tipo de contrato,

que a los algunos clientes les es difícil deaceptar


15/31

15

3.5. Modelos de iteración de

procesos

Dos principales modelos híbridos:n El desarrollo incremental – la especificación,

el diseño y la implementación se dividen en unaserie de incrementos, los cuales se desarrollande a uno

n El desarrollo en espiral – el desarrollo gira enespiral hacia fuera, empezando con un bosquejoinicial y terminando con el desarrollo de la

versión final del sistema

3.5.1 El modeloincremental

El desarrollo incremental:n Sugerido por Mills (1980)n Enfoque intermedio que combina las

ventajas del modelo en cascada con lasventajas del modelo de desarrolloevolutivo

n Combina el modelo lineal secuencial con lafilosofía interactiva de construcción deprototipos


16/31

16

3.5.1 El modelo

incrementalEl modelo de desarrollo en cascada:n Se administra fácilmenten La separación clara en etapas favorece el

desarrollo de sistemas robustosn Los cambios de requerimientos durante el

desarrollo requieren rehacer el trabajo


El modelo de desarrollo evolutivo:n Permite retrasar la especificación completa

de requerimientos y las decisiones dediseño

n Pueden llevar a sistemas débilmenteestructurado y difícil de mantener


17/31

17

3.5.1 El modelo

incrementalEl modelo incremental:n Disminuye la repetición del trabajo en el proceso de

desarrollon Ofrece oportunidades para retrasar decisiones sobre

requerimientos detallados, hasta que se adquiere ciertaexperiencia en el sistema

n Los clientes identifican, de forma general, los servicios queproveerá el sistema, y la importancia de estos servicios

n Se definen incrementos; cada uno proporcionará unsubconjunto de funcionalidades del sistema

n Se entregan primero los servicios de prioridad más alta


n Los requerimientos para los servicios de un incrementose definen en detalle

n El incremento se desarrolla utilizando el modelo deproceso mas apropiado

n Una vez que el incremento finaliza, no se aceptancambios en los requerimientos del mismo

n El incremento está disponible una vez finalizado sudesarrollo, los clientes tendrán acceso a lasfuncionalidades ofrecidas

n El uso de los incrementos desarrollados permiten aclararrequerimientos para incrementes posteriores


18/31

18

3.5.1 El modelo

incremental

n Los nuevos incrementos, se integran a losexistentes, mejorando la funcionalidad delsistema cada incremento

n ¡No es necesario utilizar el mismo proceso dedesarrollo por cada incremento!

n Habitualmente se usa:n un modelo de cascada para incrementos con servicios

de especificación bien definidan un modelo de desarrollo evolutivo si la especificación

no está clara todavía


Definiresquema de

requerimientos

Asignarrequerimientos alos incrementos

Diseñar laarquitectura del

sistema

Desarrollarincrementosdel sistema

Validarincrementos

Integrarincrementos

Validarsistema

Sistemafinal


19/31

19


Ventajas:n Los clientes no tienen que esperar hasta tener el

sistema completo, cada incremento ofrece una versiónde sistema disponible para el uso inmediato

n Los primeros incrementos pueden ser utilizados comoprototipos para especificar/refinar requerimientos de losincrementos posteriores

n El riesgo de falla en el proyecto total es mas bajo,

especialmente en las partes mas importantes delsistema; sobre los incrementos que se entreganprimeros se harán más pruebas


Problemas:n Los incrementos deben ser relativamente

pequeños (menos de 20.000 líneas de código)n Puede resultar ser difícil adaptar los

requerimientos del cliente a incrementos detamaño apropiado

n

Puede ser difícil identificar los recursos comunespara todos los incrementos


20/31

20

3.5.2 El modelo en

espiralEl modelo en espiral:n Propuesto originalmente por Boehm (1988)n Es un modelo centrado en actividadesn Se basa en las mismas actividades del modelo

de cascada, pero añade varias tareas:n Administración de riesgon

Reutilizaciónn Elaboración de prototipos

3.5.2 El modelo en

espiral

Cada ciclo de la espiral se divide en cuatro sectores:n Definición de objetivos – se identifican las restricciones

del proceso y el producto, se establece el plan detalladode administración, se identifican los riesgos y se planeanestrategias alternativas

n Evaluación de alternativas y reducción de riesgos – sehace un análisis detallado para cada uno de los riesgosdefiniéndose los pasos para reducir dichos riesgos

n

Desarrollo y validación – se elige el modelo apropiado porel desarrollo del sistema, según los riesgos identificadosn Planeación – Se revisa el proyecto y se toma la decisión

de continuar con un ciclo posterior de la espiral, en estecaso planeándose la siguiente fase


21/31

21

3.5.2 El modelo en

espiralCada ciclo de la espiral sigue el modelo de cascada

e incluye las siguientes actividades:n Determinar objetivosn Especificar restriccionesn Generar alternativasn Identificar riesgosn Resolver riesgosn Desarrollar y verificar el producto del siguiente niveln

Planear

3.5.2 El modelo enespiral


22/31

22

3.5.2 El modelo en

espiraln A diferencia de otros modelos, el desarrollo en

espiral toma en cuenta de forma explicita losriesgos

n La disminución de riesgos es una actividad muyimportante en la administración del proyecto

n En el modelo en espiral no existen fases fijas,cerradas, como la de especificación o diseño

n El modelo cascada puede incluir otros modelos

3.5.3 Proceso unificado dedesarrollo de software

n Propuesto por Booch, Jacobson,Rumbaugh

n Similar al modelo espiral, el procesoconsta de varios ciclos

n Cada ciclo termina con la entrega de un

producto al cliente


23/31

23

3.5.3 Proceso unificado de

desarrollo de software

n Cada ciclo consta de cuatro fases:n Inicio – se define una necesidad o idea y se evalúa

su factibilidadn Elaboración – se planea el proyecto, se define el

sistema, se asignan los recursosn Construcción – desarrollon Transición – instalación y pos desarrollo

n

Cada iteración responde a un conjunto de casosde uso relacionados o resuelve un riesgoidentificado al inicio de la iteración



24/31

24


desarrollo de softwaren A diferencia de otros modelos, enfatiza en

el escalonamiento de recursosn Asume que las actividades clásicas

(análisis, diseño, implementación, pruebas) participan en cada una de lasiteraciones, pero en porcentajes distintas,

según las características de cada etapa


Se utiliza un conjunto de modelos relacionadas:n Modelo de casos de uso – captura los requerimientosn Modelo de análisis – describe el sistema como un

conjunto de clasesn Modelo de diseño – define la estructura del sistema

como un conjunto de subsistemas e interfacesn Modelo de organización – define la distribuciónn Modelo de implementación - establece la

correspondencia entre clases y componentesn Modelo de pruebas – verifica que el sistema ejecutable

proporcione la funcionalidad necesaria


25/31

25



Modelo de casosde uso

Modelo deanálisis

Modelo depruebas

Modelo deimplementación

Modelo de

distribución

Modelo dediseño

Especificado por

Realizado por

Distribuido por

Implementado por

Verificado por


n Existen dependencia de rastreabilidad entretodos los modelos (no solamente entre elmodelo de caso de uso y los demás)

n Un elemento de un modelo puede rastrearsepor lo menos hacia un elemento de un modeloasociado

n La rastreabilidad permite entender el efecto delcambio en un modelo sobre otros modelos


26/31

26



El mantenimiento de las dependencias entre los modelos sepuede realizar por:

n Ingeniería hacia delante – los modelos de análisis ydiseño se establecen a partir del modelo de casos deuso, los modelos de implementación y pruebas segeneran luego, a partir de estos

n Ingeniería inversa – los modelos de análisis y diseño seextraen o actualizan mediante el código existente

n

Ingeniería de viaje redondo – combinación de ingenieríahacia delante e inversa, dependiente de cuál modeloesté sufriendo la mayor cantidad de cambios

3.6. Modelos centrados enproblemas

n La mayoría de los modelos de procesossoftware se enfocan en las actividades de éstos

n Una visión alternativa es el enfocarse en losproductos creados por estas actividades

n Las dos visiones son complementarias:n Para cada producto existe una o más actividades que

lo generann Cada actividad genera uno o más productos


27/31

27

3.6.1 Perspectivas centradasen actividades y perspectivas

centradas en entidades

n Modelos centrados en actividades:n Representan de manera explicita las actividades del

proceson Los participantes se enfocan en la manera de crear

los productos de trabajon Modelos centrados en problemas:

n Representan de manera explicita los productos detrabajo

n Los participantes se enfocan en el contenido yestructura de los productos de trabajo

3.6.2 El modelo basado enproblemas

n Esta centrado en entidadesn Esta orientado al manejo de los cambios

frecuentesn Se puede utilizar si el tiempo entre cambios es

significativamente más pequeño que la duraciónde una actividad

n Cada proyecto empieza con la identificación deun conjunto de problemas

n Todos los problemas están guardados en unabase de problemas a la que tienen acceso todoslos participantes en el proyecto


28/31

28

3.6.2 El modelo basado en

problemasn El estado de un problema puede ser:

n Cerrado – ha sido resuelton Abierto – se resuelven mediante

conversaciones y negociaciones entre losparticipantes en el proyecto

n Un problema cerrado puede abrirse de

nuevo si ocurren cambiosn Entre problemas existen dependencias

3.6.2 El modelo basado enproblemas

n Se pueden establecer correspondenciasentre los problemas y las actividades deotros modelos (paradigmas)n En el modelo en cascada los desarrolladores

resuelven por completo los problemas asociadas auna actividad, antes de pasar a la siguiente

n En el modelo espiral los riesgos corresponden aproblemas que se están evaluando, y se vuelven aabrir al inicio de cada ciclo


29/31

29

3.6.2 El modelo basado en

problemasn El uso de problemas y sus dependencias

permite que las actividades del ciclo devida se lleven a cabo en formaconcurrente

n La administración del proyecto es muyimportante

n

El administrador debe mantener lacantidad de problemas abiertos pequeñay manejable

3.7 El est ndar para el

desarrollo de procesossoftware

El estándar IEEE 1074:n Describe el conjunto de actividades y

procesos obligatorios para el desarrollo ymantenimiento del software

n Establece un marco común para el

desarrollo de modelos de ciclo de vidan Ofrece ejemplos de situaciones típicas


30/31

30

3.7 El estándar para eldesarrollo de procesos

software

Actividad – tarea o grupo de subactividades que seasignan a un equipo o a un participante del proyecto,para lograr un propósito específico

Proceso – conjunto de actividades que se realiza para unpropósito específico

Grupo de procesos – conjunto de procesos agrupados enun nivel superior de abstracción

n Las tareas usan recursos y crean un producto detrabajo

n Las actividades se descomponen en tareas específicas,se le dan fechas de inicio y fin, se asignan a unparticipante o a un equipo

3.7 El estándar para el desarrollo

de procesos software (IEEE1074)

Grupo deprocesos

Procesos

Modelado del ciclo de vida nSelección de un modelo de ciclo de vida

Administración del

proyecto

nInicio del proyecto

n

Supervisión y control del proyecton Administración de la calidad del software

Predesarrollo nExploración de conceptosn Asignación del sistema


31/31

3.7 El estándar para el desarrollode procesos software (IEEE

1074)Grupo deprocesos

Procesos

Desarrollo nRequerimientosnDiseñonImplementación

Posdesarrollo

nInstalaciónnOperación y soportenMantenimiento

n

RetiroProcesosintegrales

n Verificación y validaciónn Administración de la configuración del softwarenDesarrollo de la documentaciónnEntrenamiento

Documents

Ingenieria de Software - 3