introduccion a la ing.de software

Ing. CIP. Eddy Iván Quispe SotoIng. CIP. Eddy Iván Quispe Soto
Facultad de IngenieríaFacultad de Ingeniería
EAP. Ingeniería de SistemasEAP. Ingeniería de Sistemas

ContenidoContenido
Introducción a la Ingeniería de softwareIntroducción a la Ingeniería de software
Conceptos generales sobre programa,Conceptos generales sobre programa,
software e ingeniería de softwaresoftware e ingeniería de software
Etapas y procesos de la Ingeniería deEtapas y procesos de la Ingeniería de
SoftwareSoftware
Paradigmas de la Ingeniería deParadigmas de la Ingeniería de
softwaresoftware
Enfoques para el desarrollo deEnfoques para el desarrollo de
softwaresoftware..

El SoftwareEl Software
¿Que es?¿Que es?
El software de computadora es elEl software de computadora es el
productoproducto que los ingenieros deque los ingenieros de
software construyen y brindansoftware construyen y brindan
mantenimientomantenimiento en el largo plazo.en el largo plazo.
IncluyeIncluye programasprogramas que se ejecutanque se ejecutan
dentro de la computadora de cualquierdentro de la computadora de cualquier
tamaño y arquitectura, el contenido quetamaño y arquitectura, el contenido que
se presenta conforme los programas sese presenta conforme los programas se
ejecutan y los documentos, tanto físicosejecutan y los documentos, tanto físicos
como virtuales, que engloban todas lascomo virtuales, que engloban todas las
formas de medios electrónicos.formas de medios electrónicos.
(Pressman 2006) Cap. 1. Pag. 1

……El SoftwareEl Software
¿Quién lo hace?¿Quién lo hace?
LosLos profesionalesprofesionales ligados a laligados a la
construcción deconstrucción de solucionessoluciones concon
perfilperfil TICTIC lo construyen y brindanlo construyen y brindan
mantenimiento, y casi todos en elmantenimiento, y casi todos en el
mundo industrializado ymundo industrializado y
automatizado usan de maneraautomatizado usan de manera
indirecta ó indirectaindirecta ó indirecta

¿Por qué es importante?¿Por qué es importante?
Por que afecta de forma muyPor que afecta de forma muy
cercana todos los aspectos decercana todos los aspectos de
nuestras vidas y se ha vueltonuestras vidas y se ha vuelto
omnipresente en el comercio, laomnipresente en el comercio, la
cultura y las actividades cotidianas.cultura y las actividades cotidianas.

¿Cuáles son los pasos?¿Cuáles son los pasos?
El software de computadora seEl software de computadora se
construyeconstruye de la misma forma quede la misma forma que
cualquiercualquier productoproducto de éxito:de éxito:
mediante la aplicación de unmediante la aplicación de un procesoproceso
que conduzca a un resultado de altaque conduzca a un resultado de alta
calidad que satisfaga loscalidad que satisfaga los
requerimientos de la gente que usarárequerimientos de la gente que usará
el producto.el producto.
Se aplica el enfoque de Ingeniería deSe aplica el enfoque de Ingeniería de
software.software.

…… El SoftwareEl Software
¿Cuál es el producto obtenido?¿Cuál es el producto obtenido?
Desde el punto de vista delDesde el punto de vista del
ingeniero de software, elingeniero de software, el productoproducto
obtenido lo forman losobtenido lo forman los programasprogramas,,
el contenido (datos) y losel contenido (datos) y los
documentosdocumentos que constituyen elque constituyen el
software.software.
Pero desde el enfoque del usuario,Pero desde el enfoque del usuario,
el producto obtenido esel producto obtenido es lala
información resultanteinformación resultante que deque de
alguna manera mejora el mundo delalguna manera mejora el mundo del
usuario.usuario.

Características del softwareCaracterísticas del software
Se desarrolla o construye; no seSe desarrolla o construye; no se
manufactura en el sentido clásico.manufactura en el sentido clásico.
No se desgasta, pero se deteriora.No se desgasta, pero se deteriora.
La mayoría del software aún seLa mayoría del software aún se
construye a la medida, a pesar de queconstruye a la medida, a pesar de que
la industria tiene una tendencia hacia lala industria tiene una tendencia hacia la
construcción por componentes.construcción por componentes.

……Características del softwareCaracterísticas del software
Son confiables: No debe causar dañosSon confiables: No debe causar daños
físicos o económicos en el caso de fallos.físicos o económicos en el caso de fallos.
Eficiencia: El software no debe desperdiciarEficiencia: El software no debe desperdiciar
los recursos del Sistema.los recursos del Sistema.
Tienen Mantenimiento: Debe ser posibleTienen Mantenimiento: Debe ser posible
que el software evolucione y que sigaque el software evolucione y que siga
cumpliendo con sus especificaciones.cumpliendo con sus especificaciones.
Utilización Adecuada: Debe contar con unaUtilización Adecuada: Debe contar con una
interfaz de usuario adecuada yinterfaz de usuario adecuada y
documentación legible.documentación legible.

……Características del softwareCaracterísticas del software
Productos genéricos: Son producidosProductos genéricos: Son producidos
por una organización para ser vendidospor una organización para ser vendidos
al mercado.al mercado.
Productos hechos a la medida. SistemasProductos hechos a la medida. Sistemas
que son desarrollados bajo pedido a unque son desarrollados bajo pedido a un
desarrollador en específico.desarrollador en específico.

SoftwareSoftware
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"
Ingeniero: Capaz de Construir un Producto de Alta
calidad usando Componentes ya elaborados e
integrándolos bajo restricciones de tiempo y presupuestos.

Ingeniería de SoftwareIngeniería de Software
Fritz BauerFritz Bauer
La Ingeniería de Software es el establecimiento yLa Ingeniería de Software es el establecimiento y
uso de principios sólidos de la ingeniería parauso de principios sólidos de la ingeniería para
obtener económicamente un software confiable yobtener económicamente un software confiable y
que funcione de modo eficiente en maquinasque funcione de modo eficiente en maquinas
realesreales..
IEEE [IEE93]IEEE [IEE93]
La Ingeniería de Software es la aplicación de unLa Ingeniería de Software es la aplicación de un
enfoque sistemático, disciplinado y cuantificableenfoque sistemático, disciplinado y cuantificable
al desarrollo, operación y mantenimiento delal desarrollo, operación y mantenimiento del
software.software. Es decir la aplicación de la Ingeniería alEs decir la aplicación de la Ingeniería al
softwaresoftware

……Ingeniería de SoftwareIngeniería de Software
Es el estudio de los principios y metodologías para elEs el estudio de los principios y metodologías para el
desarrollo y mantenimiento de sistemas softwaredesarrollo y mantenimiento de sistemas software
(Zelkovitz, 1978) .(Zelkovitz, 1978) .
Es la aplicación práctica del conocimiento científico alEs la aplicación práctica del conocimiento científico al
diseño y construcción de programas de computadora ydiseño y construcción de programas de computadora y
a la documentación asociada requerida paraa la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce tambiéndesarrollar, operar y mantenerlos. Se conoce también
como Desarrollo de Software o Producción de Softwarecomo Desarrollo de Software o Producción de Software
(Bohem, 1976).(Bohem, 1976).
Trata del establecimiento de los principios y métodosTrata del establecimiento de los principios y métodos
de la ingeniería a fin de obtener software de modode la ingeniería a fin de obtener software de modo
rentable, que sea fiable y trabaje en máquinas realesrentable, que sea fiable y trabaje en máquinas reales
(Bauer, 1972).(Bauer, 1972).

……Ingeniería de SoftwareIngeniería de Software
Técnicamente:Técnicamente:
Ingeniería de softwareIngeniería de software es laes la
disciplina o área de la informática quedisciplina o área de la informática que
ofrece métodos y/o técnicas paraofrece métodos y/o técnicas para
desarrollar y mantener Software dedesarrollar y mantener Software de
calidad.calidad.

Roles de la Ingeniería de SoftwareRoles de la Ingeniería de Software
Negociadores (Staske Holders):Negociadores (Staske Holders):
Usuarios finales, compradores, ect.Usuarios finales, compradores, ect.
Desarrolladores (Developers):Desarrolladores (Developers):
Analistas, Diseñadores, AdministradoresAnalistas, Diseñadores, Administradores
de proyectos, etc.de proyectos, etc.

Información = Uno de los principales activos
Desarrollo de SI
Artesanal
Disciplina de
Ingeniería
Calidad
Herramientas
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”.

““ Es tener conocimiento de lo que estáEs tener conocimiento de lo que está
sucediendo en el momento que ocurre “sucediendo en el momento que ocurre “
Concepto (pensamiento) Sistémico:Concepto (pensamiento) Sistémico:
El cuerpo humano es una buenaEl cuerpo humano es una buena
analogía en lo que respecta alanalogía en lo que respecta al
Concepto Sistémico.Concepto Sistémico.
Así como, cuando una persona seAsí como, cuando una persona se
pincha un dedo y se da cuenta depincha un dedo y se da cuenta de
inmediato, también el gerente seinmediato, también el gerente se
debe enterar de lo que sucede endebe enterar de lo que sucede en
la empresa.la empresa.
OUCH!!

La crisis del SoftwareLa 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 delLa crisis del
SoftwareSoftwareCausas: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 delLa crisis del
SoftwareSoftware

2000
1998
1995
1994
28%23% 49%
26%28% 46%
27%40% 33%
16%31% 53%
ÉxitoProblemáticoFracaso
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,
Proyectos para el desarrollo de Software
2003
2006
29%19% 53%
32%10% 58%
……La crisis del SoftwareLa crisis del Software

Ingeniería de Software
1. Lo que el director desea. 2. Como lo define el director de
proyecto.
3. Como se diseña el Sistema.
4. Como lo desarrolla el
programador.
5. Como se ha realizado la
instalación.
6. Lo que el usuario quería.

Ingeniería deIngeniería de
SoftwareSoftware
0
20
40
60
80
100
60 70 80
Hardware
Software
Porcentaje del coste total del
sistema
años

Mitos del SoftwareMitos del Software
• Mitos de los administradoresMitos de los administradores
• Mitos de los ClientesMitos de los Clientes
• Mitos de los DesarrolladoresMitos de los Desarrolladores
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 administradoresMitos de los administradores
Mito 1.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 ClientesMitos de los Clientes
Mito 1.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 DesarrolladoresMitos 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 deIngeniería de
SoftwareSoftware
Tiempo para
salir al mercado
Inversión de relación
de costo entre HW y SW
Desktop computing
Interconexión
en Redes
Tecnología de Objetos
Problemas con Modelos
Interfaces
Gráficas
CAMBIOS ENCAMBIOS EN
INGENIERIA DEINGENIERIA DE
SOFTWARESOFTWARE

Historia del Desarrollo de SoftwareHistoria del Desarrollo de Software

Etapas y procesos de la Ingeniería deEtapas y procesos de la Ingeniería de
SoftwareSoftware
Está formada por:Está formada por:
FasesFases
ActividadesActividades
TareasTareas
RequerimientosRequerimientos
AnálisisAnálisis
DiseñoDiseño
ConstrucciónConstrucción
PruebasPruebas
Puesta en MarchaPuesta en Marcha

introduccion a la ing.de software

Modelos del ciclo de vida delModelos del ciclo de vida del
software. Bibliografíasoftware. Bibliografía
(Pressman 2006) Cap. 3. Aptdos. 3.3-3.6(Pressman 2006) Cap. 3. Aptdos. 3.3-3.6
(Piattini et al. 04) Cap. 3. Aptdo. 3.6(Piattini et al. 04) Cap. 3. Aptdo. 3.6
(Piattini et al. 96) Cap. 3. Aptdos. 3.3-3.6(Piattini et al. 96) Cap. 3. Aptdos. 3.3-3.6
(Balzer et al. 83)(Balzer et al. 83) Balzer, R., T.E. Cheatham, andBalzer, R., T.E. Cheatham, and
C.C. Green,C.C. Green, Software Technology in the 1990's:Software Technology in the 1990's:
Using a New Paradigm.Using a New Paradigm. Computer, 1983.Computer, 1983.
16(11): p16(11): ppp. 39-45.. 39-45.

El Ciclo de Vida del DesarrolloEl Ciclo de Vida del Desarrollo
Etapas: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 preliminarInvestigación preliminar
Esta actividad se inicia al formularse unformularse un
requerimientorequerimiento, tiene tres partes:
- Aclaración del requerimiento,- Aclaración del requerimiento,
- Estudio de factibilidad (Factibilidad técnica- Estudio de factibilidad (Factibilidad técnica,,
operativa y económicaoperativa y económica),),
- Aprobación del requerimiento.- Aprobación del requerimiento.

……Investigación preliminarInvestigación preliminar
Aclaración del requerimiento.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 requerimientorequerimiento
del proyecto debe estar claramentedel proyecto debe estar claramente
establecidoestablecido.

Estudio de factibilidadEstudio 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íase requiere nueva tecnología,
¿qué probabilidades hay de que pueda
desarrollarse?.

Factibilidad económica. ¿Existen suficientes
beneficiosbeneficios en la creación del sistema para
hacer que los costos sean aceptablescostos sean aceptables? O, en
forma inversa, ¿son tan altos los costoscostos como
para que el proyecto no deba llevarse a
cabo?.

……Investigador preliminarInvestigador preliminar
Factibilidad operativa. ¿Se utilizará el
software? ¿Si se desarrolla y se pone en
marcha? Habrá resistencia de los usuariosHabrá resistencia de los usuarios,
los posibles beneficios.

Determinación de LosDeterminación de Los
RequerimientosRequerimientosAdquirir 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?Qué es lo que se hace?
¿Cómo se hace?¿Cómo se hace?
¿Qué tan frecuentemente ocurre?¿Qué tan frecuentemente ocurre?
¿Qué tan grande es el volumen de transacciones o¿Qué tan grande es el volumen de transacciones o
decisiones?decisiones?
¿Qué tan eficiente se lleva a cabo la tarea?¿Qué tan eficiente se lleva a cabo la tarea?
¿Existe algún problema?¿Existe algún problema?
Si el problema existe ¿qué tan serio es?Si el problema existe ¿qué tan serio es?
Si el problema existe ¿cual es la causa principal?Si el problema existe ¿cual es la causa principal?

Desarrollo delDesarrollo del SistemaSistema PrototipoPrototipo
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 SistemasDiseñ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 SoftwareDesarrollo 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 SistemasPrueba 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ónPuesta 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ónPuesta en Marcha y Evaluación
Evaluación operacional.Evaluación operacional. Valoración, comoValoración, como
funciona el sistema, incluyendo su facilidad de uso,funciona el sistema, incluyendo su facilidad de uso,
tiempo de respuesta, lo adecuado de los formatostiempo de respuesta, lo adecuado de los formatos
de información, confiabilidad global y nivel dede información, confiabilidad global y nivel de
utilización.utilización.
Impacto organizacionalImpacto organizacional Identificación yIdentificación y
medición de los beneficios para la organización,medición de los beneficios para la organización,
eficiencia operacional e impacto competitivo.eficiencia operacional e impacto competitivo.
Opinión de los administradoresOpinión de los administradores EvaluaciónEvaluación
de las actitudes de directivos y administradores, asíde las actitudes de directivos y administradores, así
como de los usuarios finales.como de los usuarios finales.
Desempeño del desarrolloDesempeño del desarrollo La evaluación delLa evaluación del
proceso de desarrollo (tiempo y esfuerzo deproceso de desarrollo (tiempo y esfuerzo de
desarrollo), concuerdan con presupuestos ydesarrollo), concuerdan con presupuestos y
estándares, ect. Incluye la valoración de losestándares, ect. Incluye la valoración de los
métodos y herramientas utilizados en el desarrollo.métodos y herramientas utilizados en el desarrollo.

¿Qué es un Proceso de Desarrollo de¿Qué es un Proceso de Desarrollo de
SW?SW?
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
DefineDefine QuiénQuién debedebe hacerhacer QuéQué,, CuándoCuándo yy CómoCómo
debedebe hacerlohacerlo
No existe un proceso de software universal.No existe un proceso de software universal. LasLas
características de cada proyecto (equipo decaracterísticas de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el procesodesarrollo, recursos, etc.) exigen que el proceso
sea configurablesea configurable

¿Qué es un modelo del ciclo de vida¿Qué es un modelo del ciclo de vida
del software?del software?
Es una descripción de un proceso deEs una descripción de un proceso de
software que se presenta desde unasoftware que se presenta desde una
perspectiva particular.perspectiva particular.
Es una abstracción de un proceso real.Es una abstracción de un proceso real.
Existe una gran variedad de modelosExiste una gran variedad de modelos
diferentes “genéricos” o paradigmas dediferentes “genéricos” o paradigmas de
desarrollo de software.desarrollo de software.

Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclo de vida para el desarrolloModelos 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”.

Modelos de ciclos de vidaModelos de ciclos de vida
SECUENCIALSECUENCIAL
CASCADACASCADA
ESPIRALESPIRAL
MODELOS
CICLOS DESARROLLO
MODELOS CICLOS DE
VIDA DE SISTEMAS
INCREMENTALINCREMENTAL
EVOLUTIVOEVOLUTIVO
CASCADACASCADA
CONCURRENCIACONCURRENCIA
COMPONENTES COMERCIALES Y REUTILIZAZIÓNCOMPONENTES COMERCIALES Y REUTILIZAZIÓN
PROTOTIPADOPROTOTIPADO
MODIFICADORES

Modelos de ciclos de desarrolloModelos de ciclos de desarrollo
Lineal o secuencial
Requisitos
Diseño
Codificación
Pruebas
Integración
Operación y
mantenimiento
- Proyectos no muy complejos
- Metódico y ordenado
- Dirigido por documentos
- Discontinuas
- Esta identificado el producto
- Proporciona requerimientos anhelados
- Minimiza gastos de la planificación
- Personal poco cualificado y experto
También denominado:
“ciclo de vida clásico” o “paradigma clásico”
“orientado a fases”

Modelos de ciclo de desarrolloModelos 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.

Modelos de ciclo de desarrolloModelos 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.

Cascada
Requisitos
Diseño
Codificación
Pruebas
Integración
Operación y
mantenimiento
Algunos textos llaman “cascada” al modelo lineal, y
“cascada modificada” al modelo de cascada

Cascada

Modelos de ciclo de desarrolloModelos 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.

Modelos de ciclo de desarrolloModelos 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 SoftwareCiclo de vida del Software
Modelos de ciclo de desarrolloModelos de ciclo de desarrollo
Espiral
- Control de riesgos
- De pequeño a complejo.
- Dividido en 4 cuadrantes
- Tiene 6 fases
- Extremadamente complejo.
Hacia el final
del sistema
Planificación Análisis de riesgo
Evaluación del cliente Ingeniería
Análisis de riesgo
basado en los
requisitos iniciales
Análisis de riesgo
basado en la reacción
del cliente
Recolección de
requisitos y
planificación del
proyecto iniciales
Planificación
basada en los
comentarios del
cliente
Evaluación del
cliente
Prototipo inicial del
software
Prototipos de
siguiente nivel
- Reduce riesgos
- Cada iteración mas costoso.
- Combinable con otros modelos.
- Adaptable cualquier fase y cuadrante.

Modelos de ciclos de evoluciónModelos de ciclos de evolución
Incremental
REQUISITOSREQUISITOS
DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración
Operación
Mantenim.
Operación
Mantenim.
Sub-sistema
Operación
Mantenim.
Operación
Mantenim.
Sub-sistema
DiseñoDiseño CodificaciónCodificación PruebasPruebas ……
SISTEMA
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.

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.

Evolutivo
Operación
Mantenim.
Operación
Mantenim.
Sistema
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.
RequisitosRequisitos
Operación
Mantenim.
Operación
Mantenim.
SistemaRequisitosRequisitos
DiseñoDiseño ……RequisitosRequisitos

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 EvolutivaEntrega 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 EtapasEntrega 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 OOCiclo de vida OO
Booch 94 (Macroproceso)Booch 94 (Macroproceso)
Establecer requisitos
básicos
(conceptualización)
Desarrollar un modelo
del comportamiento
deseado (análisis)
Crear una arquitectura
(diseño)
Desplegar la implementación
(evolución)
Gestionar la
evolución tras la
entrega
(mantenimiento)
(Prototipo
desechable)
Interesa a la dirección técnica

Ciclo de vida OOCiclo de vida OO
Booch 94 (Microproceso)Booch 94 (Microproceso)
Especificar interfaces
e implantación de
clases y objetos
Identificar clases y
objetos
Identificar la
semántica de clases
y objetos
Identificar relaciones
entre clases y objetos
Interesa al programadorInteresa al programador

Ciclo de vida 00 - ProcesoCiclo de vida 00 - Proceso
UnificadoUnificado (Jacobson, Booch y Rumbaugh(Jacobson, Booch y Rumbaugh
99)99)
Soporte al estándar del OMG UML (LenguajeSoporte al estándar del OMG UML (Lenguaje
Unificado de Modelado)Unificado de Modelado)
Entre otros, integra los métodosEntre otros, integra los métodos
Grady Booch - Booch MethodGrady Booch - Booch Method
James Rumbaugh - Object Modeling TechniqueJames Rumbaugh - Object Modeling Technique
(OMT)(OMT)
Ivar Jacobson - Object Oriented SoftwareIvar Jacobson - Object Oriented Software
Engineering (OOSE)Engineering (OOSE)
Características principales:Características principales:
Dirigido por casos de usoDirigido por casos de uso
Centrado en la arquitecturaCentrado en la arquitectura
Iterativo e incrementalIterativo e incremental

introduccion a la ing.de software

Más contenido relacionado

Similar a introduccion a la ing.de software (20)

Último (9)

introduccion a la ing.de software

Notas del editor