Date post: | 07-Jul-2018 |
Category: |
Documents |
Upload: | alejandro-encina |
View: | 216 times |
Download: | 0 times |
of 12
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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.1. El modelo decascada
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
8/19/2019 Ingenieria de Software - 3
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
3.1. El modelo decascada
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
7/31
7
3.2. El desarrollo evolutivo
(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/19/2019 Ingenieria de Software - 3
8/31
8
3.2. El desarrollo evolutivo
(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
8/19/2019 Ingenieria de Software - 3
9/31
9
3.3. El desarrollo formal
Definición derequerimientos
Especificaciónformal
Transformaciónformal
Integración yprueba del sistema
3.3. El desarrollo formal
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
8/19/2019 Ingenieria de Software - 3
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”
8/19/2019 Ingenieria de Software - 3
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
3.4. El desarrollo basado enreutilización
Definición derequerimientos
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!
8/19/2019 Ingenieria de Software - 3
12/31
12
3.4. El desarrollo basado en
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
3.4. El desarrollo basado enreutilización
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
8/19/2019 Ingenieria de Software - 3
13/31
13
3.4. El desarrollo basado en
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
3.5.1 El modeloincremental
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
8/19/2019 Ingenieria de Software - 3
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
3.5.1 El modeloincremental
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
8/19/2019 Ingenieria de Software - 3
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
3.5.1 El modeloincremental
Definiresquema de
requerimientos
Asignarrequerimientos alos incrementos
Diseñar laarquitectura del
sistema
Desarrollarincrementosdel sistema
Validarincrementos
Integrarincrementos
Validarsistema
Sistemafinal
8/19/2019 Ingenieria de Software - 3
19/31
19
3.5.1 El modeloincremental
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
3.5.1 El modeloincremental
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
3.5.3 Proceso unificado dedesarrollo de software
8/19/2019 Ingenieria de Software - 3
24/31
24
3.5.3 Proceso unificado de
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
3.5.3 Proceso unificado dedesarrollo de software
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
8/19/2019 Ingenieria de Software - 3
25/31
25
3.5.3 Proceso unificado de
desarrollo de software
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
3.5.3 Proceso unificado dedesarrollo de software
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
8/19/2019 Ingenieria de Software - 3
26/31
26
3.5.3 Proceso unificado de
desarrollo de software
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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
8/19/2019 Ingenieria de Software - 3
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