SlideShare una empresa de Scribd logo
1 de 70
Descargar para leer sin conexión
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
……El SoftwareEl Software
¿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.
……El SoftwareEl Software
¿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.
Ingeniería de SoftwareIngeniería de Software
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 de SoftwareIngeniería de Software
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
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.
……Investigación preliminarInvestigación preliminar
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?.
……Investigación preliminarInvestigación preliminar
Estudio de factibilidadEstudio de factibilidad
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
Estudio de factibilidadEstudio de factibilidad
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”.
Ciclo de vida del softwareCiclo de vida del software
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
Ciclo de vida del softwareCiclo de vida del software
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”
Ciclo de vida del softwareCiclo de vida del software
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.
Ciclo de vida del softwareCiclo de vida del software
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.
Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclos de desarrolloModelos de ciclos de desarrollo
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
Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclos de desarrolloModelos de ciclos de desarrollo
Cascada
Ciclo de vida del softwareCiclo de vida del software
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.
Ciclo de vida del softwareCiclo de vida del software
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.
Ciclo de vida del softwareCiclo de vida del software
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
DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración
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.
Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclos de evoluciónModelos 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.
MSFMSF RUPRUP
Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclos de evoluciónModelos de ciclos de evolución
Evolutivo
DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración
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
DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración
Operación
Mantenim.
Operación
Mantenim.
SistemaRequisitosRequisitos
DiseñoDiseño ……RequisitosRequisitos
Ciclo de vida del softwareCiclo de vida del software
Modelos de ciclos de evoluciónModelos 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 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
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

Más contenido relacionado

La actualidad más candente

software
softwaresoftware
softwarealkosto
 
Trabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueTrabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueJosue Zelaya
 
Introduccion a la Ingenieria de Software
Introduccion a la Ingenieria de SoftwareIntroduccion a la Ingenieria de Software
Introduccion a la Ingenieria de SoftwareFabricio Sanchez
 
Diapositivas De Ingenieria De Software
Diapositivas De Ingenieria De SoftwareDiapositivas De Ingenieria De Software
Diapositivas De Ingenieria De Softwarerapa69
 
Inge de software por jophwa y yasuri
Inge de software por jophwa y yasuriInge de software por jophwa y yasuri
Inge de software por jophwa y yasuriyasurimarleni
 
U1T1 - Conceptos Básicos de Ingeniería del Software
U1T1 - Conceptos Básicos de Ingeniería del SoftwareU1T1 - Conceptos Básicos de Ingeniería del Software
U1T1 - Conceptos Básicos de Ingeniería del SoftwareLuis Eduardo Pelaez Valencia
 
Tema Ingenieria Del Software
Tema Ingenieria Del SoftwareTema Ingenieria Del Software
Tema Ingenieria Del Softwaregueste0af42
 
Introduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareIntroduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareLia IS
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_softwareuniv of pamplona
 
Trabajo diapositiva Software por Jhonatan Ruiz
Trabajo diapositiva  Software por Jhonatan RuizTrabajo diapositiva  Software por Jhonatan Ruiz
Trabajo diapositiva Software por Jhonatan Ruizjhonatanalex
 
Ingenieria de Software
Ingenieria de SoftwareIngenieria de Software
Ingenieria de Softwareem3marquez
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwarejuankexmisiodj
 
Tema 3 proseso de desarrollo del software
Tema 3 proseso de desarrollo del softwareTema 3 proseso de desarrollo del software
Tema 3 proseso de desarrollo del softwareLuis Garcia
 
Conceptos Básicos de Ingeniería del Software y Control de Proyectos
Conceptos Básicos de Ingeniería del Software y Control de ProyectosConceptos Básicos de Ingeniería del Software y Control de Proyectos
Conceptos Básicos de Ingeniería del Software y Control de Proyectosedwinlemmon
 
Unidad 1 Introducción a la Ingeniería de Software
Unidad 1 Introducción a la Ingeniería de SoftwareUnidad 1 Introducción a la Ingeniería de Software
Unidad 1 Introducción a la Ingeniería de SoftwareMary Carmen
 

La actualidad más candente (19)

software
softwaresoftware
software
 
Presentación2
Presentación2Presentación2
Presentación2
 
Trabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josueTrabajo diapositiva modulo 3 de josue
Trabajo diapositiva modulo 3 de josue
 
Introduccion a la Ingenieria de Software
Introduccion a la Ingenieria de SoftwareIntroduccion a la Ingenieria de Software
Introduccion a la Ingenieria de Software
 
Diapositivas De Ingenieria De Software
Diapositivas De Ingenieria De SoftwareDiapositivas De Ingenieria De Software
Diapositivas De Ingenieria De Software
 
Inge de software por jophwa y yasuri
Inge de software por jophwa y yasuriInge de software por jophwa y yasuri
Inge de software por jophwa y yasuri
 
U1T1 - Conceptos Básicos de Ingeniería del Software
U1T1 - Conceptos Básicos de Ingeniería del SoftwareU1T1 - Conceptos Básicos de Ingeniería del Software
U1T1 - Conceptos Básicos de Ingeniería del Software
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Tema Ingenieria Del Software
Tema Ingenieria Del SoftwareTema Ingenieria Del Software
Tema Ingenieria Del Software
 
Introduccion a la Ingeniería de Software
Introduccion a la Ingeniería de SoftwareIntroduccion a la Ingeniería de Software
Introduccion a la Ingeniería de Software
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software
 
Introducción a la ingeniería del software
Introducción a la ingeniería del softwareIntroducción a la ingeniería del software
Introducción a la ingeniería del software
 
Trabajo diapositiva Software por Jhonatan Ruiz
Trabajo diapositiva  Software por Jhonatan RuizTrabajo diapositiva  Software por Jhonatan Ruiz
Trabajo diapositiva Software por Jhonatan Ruiz
 
conceptos de ingenieria de software
conceptos de ingenieria de softwareconceptos de ingenieria de software
conceptos de ingenieria de software
 
Ingenieria de Software
Ingenieria de SoftwareIngenieria de Software
Ingenieria de Software
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.software
 
Tema 3 proseso de desarrollo del software
Tema 3 proseso de desarrollo del softwareTema 3 proseso de desarrollo del software
Tema 3 proseso de desarrollo del software
 
Conceptos Básicos de Ingeniería del Software y Control de Proyectos
Conceptos Básicos de Ingeniería del Software y Control de ProyectosConceptos Básicos de Ingeniería del Software y Control de Proyectos
Conceptos Básicos de Ingeniería del Software y Control de Proyectos
 
Unidad 1 Introducción a la Ingeniería de Software
Unidad 1 Introducción a la Ingeniería de SoftwareUnidad 1 Introducción a la Ingeniería de Software
Unidad 1 Introducción a la Ingeniería de Software
 

Similar a introduccion a la ing.de software

02 software clasificacin_y_funcionalidad
02 software clasificacin_y_funcionalidad02 software clasificacin_y_funcionalidad
02 software clasificacin_y_funcionalidadTito98Porto
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareSergio Sanchez
 
Ingeniería de software1429
Ingeniería de software1429Ingeniería de software1429
Ingeniería de software1429hugoctaviohm
 
Ingenieria del Software: Software a medida y generico.
Ingenieria del Software: Software a medida y generico.Ingenieria del Software: Software a medida y generico.
Ingenieria del Software: Software a medida y generico.usserp584
 
Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Robert Rodriguez
 
Ingeniería de Software
Ingeniería de Software Ingeniería de Software
Ingeniería de Software Luis Valeriano
 
SeccióN De TéCnicas De IngenieríA De Software(2007)
SeccióN De TéCnicas  De IngenieríA De Software(2007)SeccióN De TéCnicas  De IngenieríA De Software(2007)
SeccióN De TéCnicas De IngenieríA De Software(2007)denny osael lopez medina
 
6. is construcción del software
6. is construcción del software6. is construcción del software
6. is construcción del softwareNagut
 
Ingenieria de software final.
Ingenieria de software final.Ingenieria de software final.
Ingenieria de software final.Andrés Sorto
 
Ingenieria de software final.
Ingenieria de software final.Ingenieria de software final.
Ingenieria de software final.Andrés Sorto
 
Introducción Ingenieria de Software
Introducción Ingenieria de SoftwareIntroducción Ingenieria de Software
Introducción Ingenieria de SoftwareMarvin Romero
 
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Coesi Consultoria
 
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Luis Fernández
 
El_software_y_la_Ingenieria_de_Software.pdf
El_software_y_la_Ingenieria_de_Software.pdfEl_software_y_la_Ingenieria_de_Software.pdf
El_software_y_la_Ingenieria_de_Software.pdfpauly230688
 

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

02 software clasificacin_y_funcionalidad
02 software clasificacin_y_funcionalidad02 software clasificacin_y_funcionalidad
02 software clasificacin_y_funcionalidad
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De Software
 
Ingeniería de software1429
Ingeniería de software1429Ingeniería de software1429
Ingeniería de software1429
 
Ingenieria del Software: Software a medida y generico.
Ingenieria del Software: Software a medida y generico.Ingenieria del Software: Software a medida y generico.
Ingenieria del Software: Software a medida y generico.
 
Que es Ingenieria del Software?,
Que es Ingenieria del Software?,Que es Ingenieria del Software?,
Que es Ingenieria del Software?,
 
Ingeniería de Software
Ingeniería de Software Ingeniería de Software
Ingeniería de Software
 
SeccióN De TéCnicas De IngenieríA De Software(2007)
SeccióN De TéCnicas  De IngenieríA De Software(2007)SeccióN De TéCnicas  De IngenieríA De Software(2007)
SeccióN De TéCnicas De IngenieríA De Software(2007)
 
David valdiviezo ing.pdf
David valdiviezo ing.pdfDavid valdiviezo ing.pdf
David valdiviezo ing.pdf
 
Ingeniería del software
Ingeniería del softwareIngeniería del software
Ingeniería del software
 
6. is construcción del software
6. is construcción del software6. is construcción del software
6. is construcción del software
 
Is01
Is01Is01
Is01
 
Ingenieria de software final.
Ingenieria de software final.Ingenieria de software final.
Ingenieria de software final.
 
Ingenieria de software final.
Ingenieria de software final.Ingenieria de software final.
Ingenieria de software final.
 
Omar,luis,daniel
Omar,luis,danielOmar,luis,daniel
Omar,luis,daniel
 
Introducción Ingenieria de Software
Introducción Ingenieria de SoftwareIntroducción Ingenieria de Software
Introducción Ingenieria de Software
 
IS
ISIS
IS
 
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
 
1. introduccion
1. introduccion1. introduccion
1. introduccion
 
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?Sesión 1: Introduccion. ¿Qué es ingeniería de software?
Sesión 1: Introduccion. ¿Qué es ingeniería de software?
 
El_software_y_la_Ingenieria_de_Software.pdf
El_software_y_la_Ingenieria_de_Software.pdfEl_software_y_la_Ingenieria_de_Software.pdf
El_software_y_la_Ingenieria_de_Software.pdf
 

Último

Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfLeonardoOa4
 
03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdfRodrigo Cerón
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfdaa100407
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarjosuesj13
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...AlexaRamirez39
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfMiSpotify
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfjuanrubenc78
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdfRodrigo Cerón
 
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfdarosario3d
 

Último (9)

Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdf
 
03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizar
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdf
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdf
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf
 
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
 

introduccion a la ing.de software

  • 1. 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
  • 2. 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..
  • 3. 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
  • 4. ……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
  • 5. ……El SoftwareEl Software ¿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.
  • 6. ……El SoftwareEl Software ¿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.
  • 7. …… 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.
  • 8. 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.
  • 9. ……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.
  • 10. ……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.
  • 11. 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.
  • 12. 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
  • 13. ……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).
  • 14. ……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.
  • 15. 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.
  • 16. Ingeniería de SoftwareIngeniería de Software 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”.
  • 17. ““ 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!!
  • 18. 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.
  • 19. ……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.
  • 20. ……La crisis delLa crisis del SoftwareSoftware
  • 21. 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
  • 22. 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.
  • 24. 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
  • 25. 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.
  • 26. 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.
  • 27. 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.
  • 28. 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.
  • 29. 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
  • 30. Historia del Desarrollo de SoftwareHistoria del Desarrollo de Software
  • 31. Historia del Desarrollo de SoftwareHistoria del Desarrollo de Software
  • 32. 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
  • 34. 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.
  • 35. 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
  • 36. 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.
  • 37. ……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.
  • 38. ……Investigación preliminarInvestigación preliminar 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?.
  • 39. ……Investigación preliminarInvestigación preliminar Estudio de factibilidadEstudio de factibilidad 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?.
  • 40. ……Investigador preliminarInvestigador preliminar Estudio de factibilidadEstudio de factibilidad 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.
  • 41. 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?
  • 42. 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.
  • 43. 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.
  • 44. 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.
  • 45. 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.
  • 46. 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.
  • 47. ……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.
  • 48. ¿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
  • 49. ¿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.
  • 50. 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”.
  • 51. Ciclo de vida del softwareCiclo de vida del software 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
  • 52. Ciclo de vida del softwareCiclo de vida del software 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”
  • 53. Ciclo de vida del softwareCiclo de vida del software 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.
  • 54. Ciclo de vida del softwareCiclo de vida del software 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.
  • 55. Ciclo de vida del softwareCiclo de vida del software Modelos de ciclos de desarrolloModelos de ciclos de desarrollo 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
  • 56. Ciclo de vida del softwareCiclo de vida del software Modelos de ciclos de desarrolloModelos de ciclos de desarrollo Cascada
  • 57. Ciclo de vida del softwareCiclo de vida del software 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.
  • 58. Ciclo de vida del softwareCiclo de vida del software 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
  • 59. 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.
  • 60. Ciclo de vida del softwareCiclo de vida del software 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 DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración 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.
  • 61. Ciclo de vida del softwareCiclo de vida del software Modelos de ciclos de evoluciónModelos 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.
  • 63. Ciclo de vida del softwareCiclo de vida del software Modelos de ciclos de evoluciónModelos de ciclos de evolución Evolutivo DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración 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 DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración Operación Mantenim. Operación Mantenim. SistemaRequisitosRequisitos DiseñoDiseño ……RequisitosRequisitos
  • 64. Ciclo de vida del softwareCiclo de vida del software Modelos de ciclos de evoluciónModelos 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.
  • 65. 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.
  • 66. 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?.
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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

Notas del editor

  1. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.
  2. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.
  3. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.
  4. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.
  5. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.
  6. Poner una analogía con el Hw. “Elemento lógico”: lo hace más difícil de medir. “No se estropea, se deteriora”: discutir en la pizarra las figuras p. 8-9 (Pressman 98)(Pressman 01): Curva de fallos del Hw. Curva de fallos del Sw. (idealizada y real). Poco ensamblaje de componentes: diferencias con el Hw.
  7. Poner una analogía con el Hw. “Elemento lógico”: lo hace más difícil de medir. “No se estropea, se deteriora”: discutir en la pizarra las figuras p. 8-9 (Pressman 98)(Pressman 01): Curva de fallos del Hw. Curva de fallos del Sw. (idealizada y real). Poco ensamblaje de componentes: diferencias con el Hw.
  8. Poner una analogía con el Hw. “Elemento lógico”: lo hace más difícil de medir. “No se estropea, se deteriora”: discutir en la pizarra las figuras p. 8-9 (Pressman 98)(Pressman 01): Curva de fallos del Hw. Curva de fallos del Sw. (idealizada y real). Poco ensamblaje de componentes: diferencias con el Hw.
  9. Son atributos de calidad externa e interna.
  10. Son atributos de calidad externa e interna.
  11. Son atributos de calidad externa e interna.
  12. Son atributos de calidad externa e interna.
  13. Son atributos de calidad externa e interna.
  14. Son atributos de calidad externa e interna.
  15. Son atributos de calidad externa e interna.
  16. Son atributos de calidad externa e interna.
  17. Son atributos de calidad externa e interna.
  18. 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.
  19. Mitos de los administradores. Los administradores con responsabilidades sobre el sw, al igual que sus pares en la mayoría de las disciplinas, a menudo están bajo presión por mantener los presupuestos, evitar que los itinerarios se extiendan y mejorar la calidad. De la misma forma que una persona a punto de ahogarse se aferra a un tronco, con frecuencia el administrador del software se aferra a un mito si siente que esta creencia reducirá la presión (aun en forma temporal). Mito. Tenemos ya un libro que esta lleno de estándares y procedimientos para construir software, ¿no le proporciona ya a mi gente todo lo que necesita saber? Realidad. Esta muy bien que el libro exista, pero ¿se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las practicas modernas de desarrollo de software?, ¿es completo?, ¿esta diseñado para mejorar el tiempo de entrega mientras mantiene un enfoque de calidad? En muchos casos, la respuesta a todas estas preguntas es “no”.   Mito. Mi gente dispone de las herramientas de desarrollo de software mas avanzadas, después de todo, les compramos las computadoras más modernas. Realidad. Se necesita mucho más que el último modelo de computadora grande o de PC. Para hacer desarrollo de software de gran calidad. Las herramientas de Ingeniería del Software Asistida por Computadora (CASE) son mas importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores del software todavía no las utilice eficazmente.   Mito. Si fallamos en la planificación, se puede añadir mas programadores y adelantar el tiempo perdido (el llamado algunas veces “concepto de la horda Mongoliana”). Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks: “añadir gente a un proyecto de software retrasado lo retrasara aun mas”. Al principio, esta declaración puede parecer una confusión. Sin embargo, cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero solo de una manera planificada y bien coordinada. Mito 3. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compañía lo construya.
  20. El cliente que solicita un software de computadora puede ser la persona del escritorio de al lado, un grupo técnico en el piso de abajo, el departamento de ventas o de mercadotecnia, o una compañía externa que ha solicitado el software bajo contrato. En muchos casos, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformación. Los mitos conducen a expectativas falsas (del cliente) y en definitiva a la insatisfacción con el desarrollador. Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Realidad. Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse solo después de una exhaustiva comunicación ente el cliente y el desarrollador.   Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varia según el momento en que se introduce. La figura 2.3 ilustra el impacto de los cambios. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el costo. Cuando los cambios se solicitan durante el diseño del software, el impacto en el costo crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño; es decir, costo adicional. Los cambios en la función, rendimiento, interfaz u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante sobre el costo. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.
  21. Los mitos que aún subsisten entre los desarrolladores del software han permanecido a través de 50 años de cultura de programación. Durante los primeros años del software, la programación era vista como una forma de arte; por ello, las viejas formas y actitudes son difíciles de eliminar. Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: “cuanto mas pronto se comiencen a escribir código, mas se tardara en terminarlo”. Los datos industriales indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa “ejecutándose”, realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un filtro de calidad que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos del software.   Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando. Realidad. Un programa que funciona es solo una parte de una configuración de software que incluye muchos elementos. La documentación proporciona el fundamento para un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software. Mito. 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.
  22. Son atributos de calidad externa e interna.
  23. Extraído de (Pressman 98): Década 50-60 De la producción artesanal: Continuo cambio del hardware, mientras que el software se considera un añadido. Características: Falta de documentación. Fuerte dependencia del software sobre el hardware. Desarrollo artesanal de los programas. Programas de aplicación concreta. Una sola persona lo desarrolla todo. Lenguaje de programación de bajo nivel (ensamblador) Década 60-70 De los lenguajes de programación y compiladores: Avances en el hardware (reducción del coste de procesamiento). El interés se centra en aplicaciones más complejas y más difíciles de mantener. Se detecta lo que se dio en llamar una “crisis del software”. Causas: Incremento de la complejidad de las aplicaciones. Necesidad de fiabilidad del producto. Falta de adecuación de los lenguajes de programación y ausencia de metodologías para el desarrollo de las aplicaciones. Factores donde se manifiesta la “crisis”: Incremento del coste del software. Falta de calidad del software. Década 70-80: De la Ingeniería del Software: Intento de solución de la crisis del software mediante la programación estructurada/desarrollo estructurado. Mayor potencia expresiva de los lenguajes y TAD Década 80-90 De los nuevos paradigmas: Se impulsan nuevos paradigmas en la producción de programas. Década 90’s - actualidad Hay una auténtica “explosión tecnológica”. Análisis/Diseño OO. “Guerra de los métodos” UML (1997) Tecnología CASE (2ª generación) Métodos ágiles Componentes y reutilización Interoperabilidad (CORBA, .NET...). Internet Comercio electrónico