Vous êtes sur la page 1sur 70

Facultad de Ingeniería

EAP. Ingeniería de Sistemas

Ing. CIP. Eddy Iván Quispe Soto


Contenido

Introducción a la Ingeniería de software


Conceptos generales sobre programa,
software e ingeniería de software
Etapas y procesos de la Ingeniería de
Software
Paradigmas de la Ingeniería de
software
Enfoques para el desarrollo de
software.
El Software
¿Que es?
El software de computadora es el
producto que los ingenieros de
software construyen y brindan
mantenimiento en el largo plazo.
Incluye programas que se ejecutan
dentro de la computadora de cualquier
tamaño y arquitectura, el contenido que
se presenta conforme los programas se
ejecutan y los documentos, tanto físicos
como virtuales, que engloban todas las
formas de medios electrónicos.
(Pressman 2006) Cap. 1. Pag. 1
…El Software

¿Quién lo hace?
Los profesionales ligados a la
construcción de soluciones con
perfil TIC lo construyen y brindan
mantenimiento, y casi todos en el
mundo industrializado y
automatizado usan de manera
indirecta ó indirecta
…El Software

¿Por qué es importante?


Por que afecta de forma muy
cercana todos los aspectos de
nuestras vidas y se ha vuelto
omnipresente en el comercio, la
cultura y las actividades cotidianas.
…El Software

¿Cuáles son los pasos?


El software de computadora se
construye de la misma forma que
cualquier producto de éxito:
mediante la aplicación de un proceso
que conduzca a un resultado de alta
calidad que satisfaga los
requerimientos de la gente que usará
el producto.
Se aplica el enfoque de Ingeniería de
software.
… El Software

¿Cuál es el producto obtenido?


Desde el punto de vista del
ingeniero de software, el producto
obtenido lo forman los programas,
el contenido (datos) y los
documentos que constituyen el
software.
Pero desde el enfoque del usuario,
el producto obtenido es la
información resultante que de
alguna manera mejora el mundo del
usuario.
Características del software

Se desarrolla o construye; no se
manufactura en el sentido clásico.

No se desgasta, pero se deteriora.

La mayoría del software aún se


construye a la medida, a pesar de que
la industria tiene una tendencia hacia la
construcción por componentes.
…Características del software
Son confiables: No debe causar daños
físicos o económicos en el caso de fallos.

Eficiencia: El software no debe desperdiciar


los recursos del Sistema.

Tienen Mantenimiento: Debe ser posible


que el software evolucione y que siga
cumpliendo con sus especificaciones.

Utilización Adecuada: Debe contar con una


interfaz de usuario adecuada y
documentación legible.
…Características del software
Productos genéricos: Son producidos
por una organización para ser vendidos
al mercado.

Productos hechos a la medida. Sistemas


que son desarrollados bajo pedido a un
desarrollador en específico.
Software
Ingeniero: Capaz de Construir un Producto de Alta
calidad usando Componentes ya elaborados e
integrándolos bajo restricciones de tiempo y presupuestos.

Técnicamente:
“Software es la suma total de los programas de
computadora, procedimientos, reglas,
documentación asociada y los datos que
pertenecen a un sistema de cómputo".
“Un producto de software es un producto
diseñado para un usuario"
Ingeniería de Software
Fritz Bauer
La Ingeniería de Software es el establecimiento
y uso de principios sólidos de la ingeniería para
obtener económicamente un software confiable
y que funcione de modo eficiente en maquinas
reales.

IEEE [IEE93]
La Ingeniería de Software es la aplicación de un
enfoque sistemático, disciplinado y cuantificable
al desarrollo, operación y mantenimiento del
software. Es decir la aplicación de la Ingeniería
al software
…Ingeniería de Software
Es el estudio de los principios y metodologías para el
desarrollo y mantenimiento de sistemas software
(Zelkovitz, 1978) .

Es la aplicación práctica del conocimiento científico


al diseño y construcción de programas de
computadora y a la documentación asociada
requerida para desarrollar, operar y mantenerlos. Se
conoce también como Desarrollo de Software o
Producción de Software (Bohem, 1976).

Trata del establecimiento de los principios y métodos


de la ingeniería a fin de obtener software de modo
rentable, que sea fiable y trabaje en máquinas reales
(Bauer, 1972).
…Ingeniería de Software
Técnicamente:
Ingeniería de software es la
disciplina o área de la informática que
ofrece métodos y/o técnicas para
desarrollar y mantener Software de
calidad.
Roles de la Ingeniería de Software

Negociadores (Staske Holders):


Usuarios finales, compradores, ect.

Desarrolladores (Developers):
Analistas, Diseñadores, Administradores
de proyectos, etc.
Ingeniería de Software
Información = Uno de los principales activos

Desarrollo de SI

Artesanal Calidad
Disciplina de Herramientas
Ingeniería
Gestión de proyectos
Davis (1974), “información son datos procesados en forma
significativa, para el receptor, con valor real y perceptible para
decisiones presentes o futuras”.
Concepto (pensamiento) Sistémico:

“ Es tener conocimiento de lo que está


sucediendo en el momento que ocurre “

El cuerpo humano es una buena


analogía en lo que respecta al
OUCH!! Concepto Sistémico.
Así como, cuando una persona
se pincha un dedo y se da cuenta
de inmediato, también el gerente
se debe enterar de lo que sucede
en la empresa.
La crisis del Software

Se identificó por primera vez en 1968, año en


el que la organización NATO desarrolló la
primera conferencia sobre desarrollo de
software, y en la que se acuñaron los
términos “crisis del software” para definir a
los problemas que surgían en el desarrollo de
software, e “ingeniería del software” para
describir el conjunto de conocimientos que
existían en aquel estado inicial.
…La crisis del Software
Causas:
El incremento de la complejidad y de los errores del
software.
El registro de aplicaciones pendientes.
Avances del software no van a la par con la
ganancia de productividad del hardware.
Necesidades de administración, procedimientos y
políticas.
La crisis del software es parte de un problema sobre
análisis de sistemas, diseño e implantación.
Necesidad de aseguramiento de la calidad en el
software.
Costo.
Mantenimiento.
Metodologías de Desarrollo.
…La crisis del Software
…La crisis del Software
Proyectos para el desarrollo de Software

Fracaso Problemático Éxito


2006 10% 58% 32%

2003 19% 53% 29%

2000 23% 49% 28%

1998 28% 46% 26%

1995 40% 33% 27%

1994 31% 53% 16%

El proyecto se aborta o el software no se llega a utilizar


Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas.
Problemas funcionales
Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.

Fuente: Standish Group Survey,


Ingeniería de Software

1. Lo que el director desea. 2. Como lo define el director de 3. Como se diseña el Sistema.


proyecto.

4. Como lo desarrolla el 5. Como se ha realizado la 6. Lo que el usuario quería.


programador. instalación.
Ingeniería de Software
Ingeniería de Software
Porcentaje del coste total del
sistema

100

80
Hardware
60
Software
40

20

0
años
60 70 80
Mitos del Software

En la actualidad, la mayoría de los profesionales reconocidos


en la ingeniería del software identifican los mitos en su real
dimensión: actitudes equivocadas que han causado
problemas serios a los administradores y al personal técnico
por igual. Sin embargo, las antiguas actitudes y viejos
hábitos son difíciles de modificar, por lo que aún subsisten
creencias falsas sobre el software.

• Mitos de los administradores


• Mitos de los Clientes
• Mitos de los Desarrolladores
Mitos de los administradores

Mito 1. Ya se tiene un libro lleno de estándares y


procedimientos para la construcción de software. ¿Esto
proporcionará a mi gente todo el conocimiento
necesario?

Mito 2. Si se está atrasado en el itinerario es posible


contratar más programadores para así terminar a
tiempo.

Mito 3. Si decido subcontratar el proyecto de software a


un tercero, puedo relajarme y dejar que esa compañía lo
construya.
Mitos de los Clientes

Mito 1. Un enunciado general de los objetivos es


suficiente para comenzar a escribir programas; los
detalles se pueden afinar después.

Mito 2. Los requerimientos del proyecto cambian de


manera continua, pero el cambio puede ajustarse con
facilidad porque el software es flexible.
Mitos de los Desarrolladores

Mito 1. Una vez que el programa ha sido escrito y puesto


a funcionar, el trabajo está terminado.

Mito 2. Mientras el programa no se esté ejecutando, no


existe forma de evaluar su calidad.

Mito 3. El único producto del trabajo que puede


entregarse para tener un proyecto exitoso es el programa
en funcionamiento.

Mito 4. La Ing de Sw obligará a emprender la creación de


una documentación voluminosa e innecesaria y de
manera invariable tornará más lento el proceso.
Ingeniería de Software
Problemas con Modelos

Tecnología de Objetos

CAMBIOS EN Tiempo para


INGENIERIA DE salir al mercado
Desktop computing
SOFTWARE

Inversión de relación Interfaces


de costo entre HW y SW Interconexión
Gráficas
en Redes
Historia del Desarrollo de Software
Historia del Desarrollo de Software
Etapas y procesos de la Ingeniería de
Software
Está formada por:
Fases
Actividades
Tareas
Requerimientos
Análisis
Diseño
Construcción
Pruebas
Puesta en Marcha
Modelos del ciclo de vida del software.
Bibliografía
(Pressman 2006) Cap. 3. Aptdos. 3.3-3.6
(Piattini et al. 04) Cap. 3. Aptdo. 3.6
(Piattini et al. 96) Cap. 3. Aptdos. 3.3-3.6
(Balzer et al. 83) Balzer, R., T.E. Cheatham,
and C.C. Green, Software Technology in the
1990's: Using a New Paradigm. Computer,
1983. 16(11): pp. 39-45.
El Ciclo de Vida del Desarrollo

Etapas:
Investigación preliminar
Determinación de requerimientos
Desarrollo del sistema prototipo
Diseño del sistema
Desarrollo del software
Prueba de los sistemas
Puesta en marcha y evaluación
Investigación preliminar

Esta actividad se inicia al formularse un


requerimiento, tiene tres partes:
- Aclaración del requerimiento,
- Estudio de factibilidad (Factibilidad técnica,
operativa y económica),
- Aprobación del requerimiento.
…Investigación preliminar

Aclaración del requerimiento.


La clarificación del problema en este caso
es mucho más difícil; en cualquier caso,
antes de poder llegar a otro paso, el
requerimiento del proyecto debe estar
claramente establecido.
…Investigación preliminar

Estudio de factibilidad
Factibilidad técnica. ¿Puede realizarse el
trabajo para el proyecto con el equipo actual,
tecnología de software y el personal
disponible? Si se requiere nueva tecnología,
¿qué probabilidades hay de que pueda
desarrollarse?.
…Investigación preliminar

Estudio de factibilidad
Factibilidad económica. ¿Existen suficientes
beneficios en la creación del sistema para
hacer que los costos sean aceptables? O, en
forma inversa, ¿son tan altos los costos
como para que el proyecto no deba llevarse
a cabo?.
…Investigador preliminar

Estudio de factibilidad
Factibilidad operativa. ¿Se utilizará el
software? ¿Si se desarrolla y se pone en
marcha? Habrá resistencia de los usuarios,
los posibles beneficios.
Determinación de Los Requerimientos
Adquirir un conocimiento detallado de las
facetas importantes de la parte de la
empresa (a menudo esta actividad se conoce
como investigación detallada). Los analistas,
deben estudiar el proceso que actualmente
se efectúa. Preguntas claves.
¿Qué es lo que se hace?
¿Cómo se hace?
¿Qué tan frecuentemente ocurre?
¿Qué tan grande es el volumen de transacciones o
decisiones?
¿Qué tan eficiente se lleva a cabo la tarea?
¿Existe algún problema?
Si el problema existe ¿qué tan serio es?
Si el problema existe ¿cual es la causa principal?
Desarrollo del Sistema Prototipo
Proporciona información preliminar en
cuanto a la factibilidad del concepto. Se
seleccionan como prototipo situaciones
únicas, de las cuales las personas que
desarrollan el sistema no tienen ninguna
información ni experiencia.
También se evalúan situaciones de alto
costo y alto riesgo, en donde el diseño
propuesto es nuevo y no ha sido probado a
través del prototipo.
Obsérvese que el prototipo (a veces llamado
versión Beta del software) es realmente un
piloto o una prueba.
Diseño de Sistemas
Los diseñadores son responsables de
proporcionar a los programadores las
especificaciones completas y escritas con
claridad, que establezcan lo que debe hacer
el software. Los diseñadores están
pendientes para contestar preguntas,
esclarecer ideas confusas y manejar los
problemas que confronten los
programadores cuando utilicen las
especificaciones de destino.
Desarrollo del Software
En esta actividad se realiza la codificación de
los programas nuevos o algunas
modificaciones que estos necesiten.
Los programadores son también
responsables de documentar el programa e
incluir los comentarios que expliquen tanto
el cómo y porqué se utilizó cierto
procedimiento. La documentación es
esencial para probar el programa y darle
mantenimiento una vez que la aplicación se
ha puesto en marcha.
Prueba de los Sistemas
El software se utiliza en forma experimental
para asegurar que el software no falle; que
ejecutará de acuerdo con sus
especificaciones y a la manera en la que los
usuarios esperan que lo haga.
Se examinan datos especiales de prueba
como entrada y los resultados para localizar
algunos problemas inesperados. En
ocasiones es recomendable que esta
actividad sea realizada por terceras
personas lo cual asegura una mayor y más
completa prueba, además de ser imparcial,
lo que da un software más confiable.
Puesta en Marcha y Evaluación
Cuando el personal de sistemas verifica y
pone en uso el nuevo equipo, entrena al
personal usuario, instala la nueva aplicación
y construye los archivos de datos que se
necesiten entonces se dice que el sofware se
ha puesto en marcha.
La evaluación de un sistema se lleva a cabo
para identificar puntos débiles y fuertes.
…Puesta en Marcha y Evaluación
Evaluación operacional. Valoración, como funciona
el sistema, incluyendo su facilidad de uso, tiempo
de respuesta, lo adecuado de los formatos de
información, confiabilidad global y nivel de
utilización.
Impacto organizacional Identificación y medición
de los beneficios para la organización, eficiencia
operacional e impacto competitivo.
Opinión de los administradores Evaluación de las
actitudes de directivos y administradores, así como
de los usuarios finales.
Desempeño del desarrollo La evaluación del
proceso de desarrollo (tiempo y esfuerzo de
desarrollo), concuerdan con presupuestos y
estándares, ect. Incluye la valoración de los
métodos y herramientas utilizados en el desarrollo.
¿Qué es un Proceso de Desarrollo de SW?
Define Quién debe hacer Qué, Cuándo y Cómo
debe hacerlo

Requisitos nuevos Sistema nuevo


o modificados o modificado
Proceso de Desarrollo
de Software

No existe un proceso de software universal. Las


características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso
sea configurable
¿Qué es un modelo del ciclo de vida
del software?
Es una descripción de un proceso de
software que se presenta desde una
perspectiva particular.

Es una abstracción de un proceso real.

Existe una gran variedad de modelos


diferentes “genéricos” o paradigmas de
desarrollo de software.
Ciclo de vida del software
Modelos de ciclo de vida para el desarrollo
Los conceptos de partida son definidos y normalizados en el estándar 12207:
 Ciclo de vida del software: El periodo de tiempo comprendido desde la definición de los
requisitos hasta el fin del su uso.
 Procesos: Actividades y tareas implicadas en el desarrollo operación y mantenimiento de un
sistema de software.
Los procesos, en desarrollo, mantenimiento y operación del software, se dibuja a través de
“patrones fijos” que configuran la situación, relación y continuidad entre procesos, actividades y
tareas.

En la etapa de desarrollo los patrones básicos son:


 Desarrollo en cascada. (o variante secuencial)
 Desarrollo en espiral.
Una vez desarrollada la primera versión, el ciclo de vida del sistema discurre en cada momento
según uno de los siguientes patrones.
 Desarrollo incremental del sistema.
 Desarrollo evolutivo del sistema.
Sobre estos patrones básicos, en las diferentes etapas del ciclo de vida pueden intervenir como
modificadores los siguientes factores:
 Prototipado.
 Concurrencia.
 Componentes comerciales y reutilización.
Generando la riqueza de modelos y sub-modelos de patrones que algunos textos clasifican de
forma lineal y agrupada como “modelos de ciclos de vida”.
Ciclo de vida del software
Modelos de ciclos de vida

MODELOS MODELOS CICLOS DE


MODIFICADORES

CICLOS DESARROLLO VIDA DE SISTEMAS

SECUENCIAL
INCREMENTAL
CASCADA
EVOLUTIVO
CASCADA
ESPIRAL

PROTOTIPADO CONCURRENCIA

COMPONENTES COMERCIALES Y REUTILIZAZIÓN


Ciclo de vida del software
Modelos de ciclos de desarrollo
Lineal o secuencial
También denominado:
“ciclo de vida clásico” o “paradigma clásico”
Requisitos
“orientado a fases”

Diseño

Codificación

Pruebas
- Proyectos no muy complejos
- Metódico y ordenado
Integración
- Dirigido por documentos
- Discontinuas
Operación y
- Esta identificado el producto mantenimiento
- Proporciona requerimientos anhelados
- Minimiza gastos de la planificación
- Personal poco cualificado y experto
Ciclo de vida del software
Modelos de ciclo de desarrollo Lineal o secuencial

Este modelo refleja un desarrollo marcado por la sucesión escalonada de las


etapas que lo componen : requisitos, diseño, codificación, pruebas e
integración.
Es necesario terminar por completo cada etapa para pasar a la siguiente.
Este modelo, identificado ya a principios de la década de los 50, resulta muy
rígido porque cada fase requiere como elemento de entrada el resultado
completo de la anterior.
Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas
veces resulta difícil poder disponer de requisitos completos o del diseño
pormenorizado del sistema en las fases iniciales, creando una barrera que
impide avanzar.
Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas ya veteranos en los que el
desconocimiento de las necesidades de los usuarios, o del entorno de
operación no plantea riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo.
Ciclo de vida del software
Modelos de ciclo de desarrollo Cascada

En 1970 Winston Royce definió flujos de retorno sobre el modelo secuencial.


El modelo en cascada refleja la necesidad impuesta por la realidad de retornar
con frecuencia desde una fase hacia las anteriores con la información generada al
avanzar el desarrollo.
Este modelo, reconoce la importancia de disponer de requisitos y un diseño
previo antes de comenzar con la codificación del sistema, pero al mismo tiempo
se enfrenta al hecho de que en la realidad la dificultad que supone disponer de
documentación elaborada de requisitos y diseño antes de empezar a codificar
puede actuar como una barrera que bloquee el comienzo de la siguiente fase.
Por estas razones el modelo no se ha hecho muy popular, y los equipos que lo
aplican pueden caer en la tentación de comenzar con el diseño o incluso con la
codificación, sin tener un conocimiento suficiente de los requisitos.
Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas ya veteranos en los que el
desconocimiento de las necesidades de los usuarios, o del entorno de
operación no plantean riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo.
Ciclo de vida del software
Modelos de ciclos de desarrollo
Cascada
Algunos textos llaman “cascada” al modelo lineal, y
“cascada modificada” al modelo de cascada

Requisitos

Diseño

Codificación

Pruebas

Integración

Operación y
mantenimiento
Ciclo de vida del software
Modelos de ciclos de desarrollo
Cascada
Ciclo de vida del software
Modelos de ciclo de desarrollo Espiral

Boehm en 1988, presenta un desarrollo evolutivo, en contraste a la linealidad de los


anteriores. También introduce como elemento distintivo la actividad de “análisis de riego”
para guiar la evolución del proceso de desarrollo.
El ciclo de iteración de este modelo evolutivo se convierte en una espiral, que al
representarse sobre ejes cartesianos muestra en cada cuadrante una clase particular de
actividad: Planificación, Análisis de riesgo, Ingeniería y Evaluación, que se suceden de forma
consecutiva a lo largo del ciclo de vida del desarrollo. La dimensión angular representa el
avance relativo en el desarrollo de las actividades de cada cuadrante.
En la planificación de cada vuelta se establece el contexto del desarrollo y se decide qué parte
del mismo se abordará en el ciclo siguiente.
Las actividades de análisis de riesgo evalúan las alternativas posibles para la ejecución de la
siguiente parte del desarrollo, seleccionando la más ventajosa y previendo los riesgos.
Las actividades de ingeniería corresponden a las indicadas en los modelos lineales (secuencial
y cascada): análisis, diseño, codificación, etc.
Las actividades de evaluación analizan los resultados de la fase de ingeniería, tomando el
resultado de la evaluación como punto de partida para el análisis de la siguiente fase.
Permite múltiples combinaciones ya que en la planificación de cada ciclo se determina el
avance que se va a ejecutar durante la vuelta. Éste puede consistir en la obtención y
validación de requisitos, o en el desarrollo del diseño, o el diseño junto con la codificación, o
en la obtención de un subsistema completo.
Ciclo de vida del software
Modelos de ciclo de desarrollo
Espiral
En función de las combinaciones empleadas se podría argumentar que un
desarrollo en espiral puede acabar siendo idéntico a otro modelo. Así por
ejemplo si cada vuelta realizase exactamente una de las fases del modelo en
cascada, al final se podría argumentar que se ha seguido una cascada. Si por
el contrario en cada vuelta se desarrollara una parte del sistema global, se
podría decir que se ha seguido no un modelo de ciclo de desarrollo, sino de
ciclo de vida, y concretamente el modelo incremental.
Aunque a primera vista puede parecer cierto, en realidad no lo es.
Si al comenzar el desarrollo se tiene decidido que se van a abordar las fases
de una cascada de forma secuencial, indudablemente se va a seguir un modelo
en cascada.
Si se determina ir elaborando partes del sistema, se opta por un ciclo de vida
incremental.
Si sólo se determina dar un pequeño paso, y después de conseguido, evaluar
el resultado y planificar el siguiente paso, y antes de cada ejecución se
analizan los riesgos, en ese caso, el modelo seguido es un modelo en espiral
Ciclo de vida del Software
Modelos de ciclo de desarrollo
Espiral Planificación Análisis de riesgo Análisis de riesgo
Recolección de basado en los
requisitos y requisitos iniciales
planificación del
proyecto iniciales
Análisis de riesgo
basado en la reacción
Planificación del cliente
basada en los
comentarios del
cliente Prototipo inicial del
software

Prototipos de
Evaluación del
cliente siguiente nivel

Evaluación del cliente Ingeniería Hacia el final


del sistema
- Control de riesgos - Reduce riesgos
- De pequeño a complejo. - Cada iteración mas costoso.
- Dividido en 4 cuadrantes - Combinable con otros modelos.
- Tiene 6 fases - Adaptable cualquier fase y cuadrante.
- Extremadamente complejo.
Ciclo de vida del software
Modelos de ciclos de evolución
Incremental
Operación
Diseño Codificación Pruebas Integración Sub-sistema
Mantenim.
REQUISITOS

Operación
Diseño Codificación Pruebas Integración Sub-sistema SISTEMA
Mantenim.

Diseño Codificación Pruebas …

El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un


sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo (en cascada en la
representación gráfica siguiente).
Las ventajas que ofrece son:
 El usuario dispone de pequeños subsistemas operativos que ayudan a perfilar mejor las
necesidades reales del sistema en su conjunto.
 El modelo produce entregas parciales en periodos cortos de tiempo, comparados con el
tiempo necesario para la construcción del sistema en su conjunto, y permite la
incorporación de nuevos requisitos que pueden no estar disponibles o no ser conocidos al
iniciar el desarrollo.
Ciclo de vida del software
Modelos de ciclos de evolución
Incremental

Aunque en la representación gráfica de la figura anterior, los


desarrollos de cada subsistema se solapan en el tiempo, en su
aplicación real, el segundo y siguientes subsistemas pueden
comenzar una vez concluido el anterior.
Resulta apropiado:
Desarrollo de sistemas en los que el cliente necesita disponer de
parte de la funcionalidad antes de lo que costaría desarrollar el
sistema completo.
Desarrollo de sistemas en los que por razones del contexto
interesa realizar la obtención de los requisitos de forma
escalonada a través de subsistemas.
MSF RUP
Ciclo de vida del software
Modelos de ciclos de evolución
Evolutivo
Operación
Requisitos Diseño Codificación Pruebas Integración Sistema
Mantenim.

Operación
Requisitos Diseño Codificación Pruebas Integración Sistema
Mantenim.

Requisitos Diseño …

Este modelo está compuesto por varios ciclos de desarrollo. Cada uno
de ellos produce un sistema completo con el que se operará en el
entorno de operación.
La información acumulada en el desarrollo de cada sistema, y durante
su fase de operación sirve para mejorar o ampliar los requisitos y el
diseño del siguiente.
En realidad es un ciclo de vida común a todos los sistemas
desarrollados que se mejoran a través de versiones sucesivas.
Ciclo de vida del software
Modelos de ciclos de evolución
Evolutivo

Las circunstancias en las que este modelo puede resultar apropiado


son
 Desconocimiento inicial de todas las necesidades operativas que
serán precisas, generalmente por tratarse del desarrollo de un
sistema que operará en un entorno nuevo sin experiencia previa.
 Necesidad de que el sistema entre en operación en tiempos
inferiores a los que serían necesarios para diseñarlo y elaborarlo de
forma exhaustiva.
 Necesidad de desarrollar sistemas en entornos cambiantes (sujetos
a normas legislativas, mejora continua del producto para hacer
frente a desarrollos de la competencia, etc.).
Aunque en su concepción inicial contempla desarrollos internos en
cascada, también podría plantearse, por ejemplo, un ciclo de vida
evolutivo con desarrollos internos en espiral.
Entrega Evolutiva

- Cuando se estima que


sobra el tiempo.
- Hasta que se acabe el
presupuesto.
- Combinación del
modelo entrega por
etapas y prototipos
evolutivos.
- Cuando el cliente
agrega solicitudes,
dentro de los
previstos.
Entrega por Etapas
- Permite entregar una
funcionalidad útil del
proyecto al cliente
- No funciona sin una
planificación técnica ni de
gestión.
- No se espera al final para
entregar el proyecto.
- Adecuado para proyecto
a largo plazo con tiempos
dados.
- Cubre defectos del
cascada.
- Personal de gestión con
experiencia.
- Mucha documentación?.
Ciclo de vida OO
Booch 94 (Macroproceso)

Establecer requisitos Desarrollar un modelo


básicos del comportamiento
(conceptualización) deseado (análisis)
(Prototipo
desechable)
Crear una arquitectura
(diseño)
Gestionar la
evolución tras la Desplegar la implementación
entrega (evolución)
(mantenimiento)
Interesa a la dirección técnica
Ciclo de vida OO
Booch 94 (Microproceso)

Identificar clases y
objetos

Especificar interfaces e Identificar la


implantación de clases semántica de clases
y objetos y objetos

Identificar relaciones
entre clases y objetos

Interesa al programador
Ciclo de vida 00 - Proceso Unificado
(Jacobson, Booch y Rumbaugh 99)

Soporte al estándar del OMG UML (Lenguaje


Unificado de Modelado)
Entre otros, integra los métodos
Grady Booch - Booch Method
James Rumbaugh - Object Modeling Technique
(OMT)
Ivar Jacobson - Object Oriented Software
Engineering (OOSE)
Características principales:
Dirigido por casos de uso
Centrado en la arquitectura
Iterativo e incremental
Facultad de Ingeniería
EAP. Ingeniería de Sistemas

Ing. CIP. Eddy Iván Quispe Soto