INGENIERIA

de SOFTWARE

2019 Lic. Claudio Darío Fernandez - claudio.fernandez@usal.edu.ar

 INGENIERIA DE SOFTWARE

¡Bienvenidos!
Nos presentamos:
• Nombre y Apellidos.
• Especialidad y ciclo de estudios.
• ¿Trabaja, además de estudiar?
• ¿Qué espera del curso?
Lic. Claudio D. Fernández - 2019
 INGENIERIA DE SOFTWARE
OBJETIVOS
• Conocer la situación de los proyectos de construcción de
software.
• Comprender e incorporar las actividades de planificación,
coordinación, medición, seguimiento, control e información
en los proyectos de Desarrollo de Software.
• Entender la forma de realizar mediciones de tamaño,
esfuerzo, plazo y RRHH.
• Conocer y aplica una herramienta para dichos propósitos.
• Entender las estrategias y tareas para realizar la
organización de los controles de calidad.
 Contenidos Programáticos
❑ UNIDAD TEMATICA 1: La Ingeniería del Software
❑ UNIDAD TEMATICA 2: El proyecto de desarrollo de Software
❑ UNIDAD TEMATICA 3: Las Métricas
❑ UNIDAD TEMATICA 4: Los Riesgos
❑ UNIDAD TEMATICA 5: El Entorno
❑ UNIDAD TEMATICA 6: El Aseguramiento de la Calidad
Bibliografía
❑ Roger S. Pressman –
Ingeniería del Software Un enfoque Practico
Editorial Mc Graw Hill, 7ma. Edición 2010
❑ Ian Sommerville
Ingeniería de Software.
Pearson Educacion – 9na. Edición - 2011
❑ Carlos M. Zapata e Yris Olaya
Ingeniería de Software para Analistas.
Editorial Litonueve - 2007
Unidad 1 Contenidos Programáticos
❑ 1.1 Introducción a los problemas
de la producción del Software.
❑ 1.2 La Ingeniería del Software como disciplina.
❑ 1.3 Componentes de acuerdo al Ciclo de Vida.
❑ 1.4 Procesos de Mejora del Software.
❑ 1.5 Madurez de las Organizaciones.
❑ 1.6 Calidad del Software.
Y el software …
¿Dónde está?
 Cada vez es más amplio el impacto
en todos los aspectos de la sociedad
SKYNET esta cada vez mas cerca
 ¿Cómo
nos
afecta
el
software ?
 Ariane 5 Flight 501- European Space Agency
❑ Costo: 10 años y 7.000.000.000 U$D – 4 Junio 1996
❑ Llevaba 4 satélites para poner en orbita y realizaría un estudio de la
magnetosfera. No llevaba tripulación
❑ 37 segundos después del lanzamiento el cohete cambio el curso
❑ 39 segundos después del lanzamiento el cohete explotó
❑ CAUSA: ERROR DE SOFTWARE
▪ Una computadora dirigía el cohete – Reutilización de software
▪ Un bug en el software hizo pensar al cohete que necesitaba virar
▪ Fuerzas aerodinámicas dañaron el cohete
▪ El mecanismo de autodestrucción se disparó
 ¿Qué es ingeniería del software?
❑ Definición del Instituto de Ingeniería Electrica y
Electrónica (IEEE): Ingeniería de Software es la aplicación
de criterios sistemáticos, disciplinados y cuantificables al
desarrollo, operación y mantenimiento del software.
❑ Ingeniería de software es la aplicación práctica del
conocimiento científico al diseño y construcción de programas
de computadora y a la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce también como
desarrollo de software o producción de software (Bohem,
1976).
 ¿Qué es ingeniería del software?
❑ La ingeniería de software es una disciplina formada por
un conjunto de métodos, herramientas y técnicas que
se utilizan en el desarrollo de los programas
informáticos (software). Esta disciplina trasciende la
actividad de programación, que es el pilar fundamental
a la hora de crear una aplicación. (Pressman 2012)
 ¿Qué es ingeniería del software?
❑ La ingeniería de software se define como la disciplina
tecnológica preocupada de la producción sistemática y
mantenimiento de los productos de software que son
desarrollados y modificados en tiempo y dentro del
presupuesto definido. ... Se conoce también como
desarrollo de software de producción. (Pressman 2012)
Definamos “disciplina”
Disciplina: conjunto de reglas o normas cuyo
cumplimiento de manera constante conducen a
cierto resultado
Disciplina: es la coordinación de actitudes con las
cuales se instruye para desarrollar habilidades
mas rápido o para seguir un determinado código
de conducta u “orden”
 Aplicación de Ingeniería del Software

1. Requerimientos 6. Gerenciamiento de la configuración

2. Diseño 7. Gerenciamiento de los procesos
3. Construcción 8. Herramientas y métodos
4. Prueba 9. Gerenciamiento de la calidad
5. Mantenimiento
 Entonces podemos decir que:

La Ingeniería del software es una disciplina que provee

conocimientos, herramientas y métodos para:
❑ Gerenciar los proyectos de software
▪ Definir los requerimientos del software
▪ Realizar diseño del software
▪ Realizar construcción del software
▪ Realizar pruebas del software
▪ Realizar mantenimiento del software
El Navío
Vasa
(Wasa,​
Wasan o
Wasen)
(1626-1628)

https://es.wikipedia.org/wiki/Vasa
Rey Henrik
Gustavo II Adolfo de Hybertsson
Suecia
Algunos de los factores que contribuyeron al fracaso:

❑ Presión de tiempo irrazonable.

❑ Cambio de especificaciones y falta de "Los objetivos
documentación o plan de proyecto. de una
organización
❑ Sobre-ingeniería e innovación.
deben coincidir
❑ Falta de métodos científicos y de razonamiento. adecuadamente
❑ Cambio de director del proyecto (fallecimiento). con sus
❑ Poder de decisión.
capacidades "
 I ETAPA II ETAPA
(1946-1965) (1965-1972)
* Se trabajaba bajo la idea de “Codificar y * Se busca simplificar los códigos.
Corregir” * Aparición de multiprogramación y
* No existía un planeamiento previo. sistemas multiusuarios.
* No existía documentación de ningún tipo * Sistemas en tiempo real apoyan la
* Existencia de pocos métodos formales y toma de decisiones.
pocos creyentes en ellos. * Aparición de software como producto.
* Desarrollo a base de prueba y error. * Inicio de la Crisis del software.
* Procedimiento por lotes (batch). * Se busca procedimientos de desarrollo
* Distribución limitada. de software.
* Software a medida. * Bases de Datos.
Lenguajes: * Programación estructurada.
FORTRAN - ALGOL – LISP - COBOL * E-Mail.
APL – SIMULA BASIC - PL/I Lenguajes:
PROLOG - C
 III ETAPA
(1972-1985)
* Nuevo concepto: Sistemas distribuidos
* Complejidad en los sistemas de
información
* Aparición de las redes de área local y
global, además de las comunicaciones
digitales.
* Amplio uso de los microprocesadores
* Hardware de bajo costo.
* Workstation
* Incorporación de Inteligencia.
* Impacto en el consumo.
Lenguajes:
PASCAL - ADA SCHEMA MODULA -
SMALLTALK - OBJETIVE C
IV ETAPA
(1985-2000)
* Impacto colectivo del software.
* Sistemas personales potentes.
* Aparición de las redes de información.
* Aparición de redes neuronales,
sistemas expertos, SW de inteligencia
artificial.
* Tecnologías orientadas a Objetos.
* La información como valor
preponderante dentro de las
Organizaciones.
Lenguajes:
C++ - EIFFEL - PERL - TLC/TK - RUBY
PYTHON PHP - JAVA - JAVASCRIPT
 V ETAPA
(2000-HOY?)
* Omnipresencia en la web
* Reutilización de información
* Reutilización de software – App´s

Lenguajes:
C# - VISUAL BASIC – SCALA
GROOVY - GO
Principios generales de la Ingeniería de SW

Un sistema de software existe por una sola razón

DAR VALOR A SUS USUARIOS
Todas las decisiones deben tomarse
teniendo esto en mente, tenemos que preguntar:
¿esto agrega valor real al sistema?,
si la respuesta es «NO»
NO LO HAGA
Principios generales de la Ingeniería de SW

Diseño simple
Debe ser tan simple como sea posible porque esto hace
que sea comprensible fácilmente, mantenible y menos
propenso al error.
Otros consumirán lo que usted produce
Siempre otra persona usará, mantendrá o documentará el
sistema.
Tenga presente que alguien más tendrá que entender lo
que usted haga.
Principios generales de la Ingeniería de SW

Ábrase al futuro
Los sistemas deben ser fáciles de adaptar a los cambios
frecuentes de especificaciones y de hardware.
Reutilización
La planeación anticipada en busca de la reutilización
disminuye el costo e incrementa el valor tanto de los
componentes reutilizables como de los sistemas en los que
se incorpora.
 LEYES DE MURPHY "Si algo puede salir mal, saldrá
• Nada es tan fácil como parece. mal. (y en el peor momento
• Todo lleva mas tiempo del que Ud. piensa. posible) "
• Cualquier solución entraña nuevos problemas.
• Siempre es mas fácil hacerlo de la manera difícil.
• Toda promesa de plazos deberá multiplicarse por un factor de 2.0
• Los cambios mas importantes de diseño se solicitaran sobre la fecha de
entrega.
• Los problemas complejos, tienen soluciones erróneas sencillas y fáciles
de entender.
• Los usuarios no saben realmente lo que quieren pero saben con
certeza lo que no quieren.
• Es inútil hacer una cosa a prueba de tontos , estos son cada vez mas
ingeniosos.
 Mitos de la construcción del software
Mito: «Si nos atrasamos, podemos agregar más
programadores»

Realidad: «Agregar personal a un proyecto atrasado,

lo atrasará más» - Brooks.
A medida que se agregan personas las que ya se
encuentran trabajando deberán dedicar tiempo a
enseñar a los nuevos. Pueden agregarse individuos
pero de forma planeada y coordinada.
 Mitos de la construcción del software
Mito: «Para comenzar a escribir programas, es
suficiente el enunciado general de los objetivos –
podremos entrar en detalle más adelante»

Realidad: Un planeamiento de objetivos ambiguos es

un camino al fracaso. Los requerimientos que no son
ambiguos se desarrollan solo por medio de una
comunicación eficaz y continua entre el cliente y el
desarrollador.
 Mitos de la construcción del software
Mito: «Los requerimientos del software cambian
continuamente, pero el cambio se asimila con facilidad
debido a que el software es flexible»
Realidad: El efecto que los cambios tienen varía
según la época en la que se introducen. El efecto de
un cambio antes que se haya realizado el diseño o
la elaboración del código es relativamente
pequeño. Sin embargo, conforme pasa el tiempo el
costo aumenta con rapidez.
 Mitos de la construcción del software
Mito: «Una vez que escribimos el programa y
hacemos que funcione, nuestro trabajo ha
terminado»

Realidad: Los datos de la industria demuestran que

entre el 60 y el 80% de todo el esfuerzo dedicado al
software ocurrirá después de entregarlo al cliente
por primera vez.
 Mitos de la construcción del software
Mito: «Hasta que no se haga «correr» el programa,
no hay manera de evaluar su calidad»

Realidad: Desde la concepción del proyecto se

deben realizar revisiones técnicas.
 ¿Qué es un proyecto?

Por definición, según el estándar del PMI (Project

Management Institute) un proyecto es el esfuerzo
temporario realizado con el fin de crear un producto,
servicio o resultado único.
Entonces, todo proyecto:
 es temporario, es decir que tiene un inicio y un final
definido.
 es único, por más que compartan mucho del final
esperado.
 ¿Qué es gerenciar un proyecto?
Es la disciplina de organizar y gerenciar recursos en
orden de finalizar exitosamente el proyecto.

¿Qué significa exitosamente?

Exitosamente significa dentro de un alcance
definido, que cumple con las restricciones de
calidad, tiempo y costo.
Restricciones de un proyecto
Calidad

Proyecto
exitoso
ALCANCE
 Gerenciar proyectos de software

Es la disciplina de planificar, realizar el seguimiento y el

control de proyectos de software.

Planificar proyectos

Identificar el alcance, estimar el trabajo involucrado, y crear

el cronograma del proyecto
 Proceso del software

Un proceso es un conjunto de actividades, acciones y

tareas que se ejecutan en fin de lograr un objetivo.
En Ingeniería del Software este proceso no es rígido
sino que es un enfoque adaptable que permite a las
personas que realizan el trabajo elijan el conjunto de
tareas y acciones apropiadas.
Estructura general de un proceso de software

Un estructura de proceso general de software consta

de cinco actividades:
1. Comunicación
2. Planeación
3. Modelado
4. Construcción
5. Prueba y despliegue
1. Comunicación

Es crítico e imprescindible entender los objetivos de los diferentes

participantes del proyecto, y reunir los requerimientos que ayuden a
definir las características y funciones del software.
 1. Comunicación – Los 10 Principios
1. Escuchar.
2. Prepararse antes de comunicar.
3. Alguien debe facilitar la
actividad.
4. La comunicación cara a cara
es lo mejor.
5. Tomar notas y documentar las
decisiones.
6. Buscar la colaboración.
7. Conservar el enfoque, examinar
un módulo a la vez.
8. Si algo no está claro, se hace un
dibujo.
9. En todo momento se debe
continuar, si se llega a un
acuerdo, si no se llega a un
acuerdo, si algo no está claro y
no se puede clarificar de
momento.
10. La negociación no es un concurso
o un juego, funciona mejor
cuando ambas partes ganan.
 1.1. Requerimientos

Los requerimientos de software definen la funcionalidad del sistema:

❑ Responden a la pregunta ¿Qué?
❑ NO responden a la pregunta ¿Cómo?
❑ Define las restricciones del sistema

Dentro de los requerimientos existen dos tipos:

❑ Funcionales
❑ No Funcionales
1.2. Análisis de requerimientos

Los requerimientos se reciben en bruto, luego hay que especificarlos

y extenderlos.
❑ Prototipos: son usados a menudo, especialmente cuándo
existen interfaces de usuario
El producto del proceso es la Especificación de Requerimientos de
Software (SRS)
1.3. Especificación de Requerimientos
de Software (SRS)
El SRS es un documento formal de especificación de requerimientos
que describe en detalle los:
❑ Requerimientos Funcionales
▪ Procesos de Negocio.
▪ Actores y casos de uso.
❑ Requerimientos No Funcionales
▪ Escalabilidad, concurrencia, stress
1.3. Especificación de Requerimientos
de Software (SRS) … continuación …
Es difícil describir y documentar los requerimientos en forma
comprensiva y no ambigua
✓ Buenos requerimientos salvan tiempo y dinero

Los requerimientos pueden cambiar durante el proyecto

✓ Una buena especificación de requerimientos reduce los
cambios
✓ Buenos prototipos reducen los cambios significativamente
2. Planeación

La actividad de planeación crea un «mapa» que guía al equipo. Ese

mapa se denomina plan de proyecto del software y define:
❑ Tareas a realizar
❑ Riesgos probables
❑ Recursos que se requieren
❑ Productos del trabajo que se obtendrán
❑ Programación de las actividades
3. Modelado

Crea un bosquejo de la arquitectura, como se ajustan entre sí las

partes constituyentes.

El objetivo es entender mejor los requerimientos de software y el

diseño que lo satisfará.
3.1. Arquitectura

Es la descripción técnica acerca de como el sistema

implementará los requerimientos.
❑ La arquitectura del sistema describe:
▪ Cómo el sistema será descompuesto en módulos o
subsistemas
▪ Cuáles son las responsabilidades de cada modulo
▪ Cuál es la Interacción entre los módulos
▪ Cuáles serán las Plataformas y Tecnologías a utilizar
▪ Cuáles son las restricciones
A veces la figura se hace realidad…
Ejemplo de arquitectura
Ejemplo de arquitectura
3.2. Documento de diseño de software

El producto del Modelado o diseño es el Documento de

diseño de software (SDD) que es la descripción formal de la
arquitectura y diseño del sistema.
El SDD contiene:
❑ Diseño de la arquitectura (módulos y su interacción)
❑ Para cada modulo:
▪ Diseño de procesos
▪ Diseño de datos (DER)
4. Construcción

Esta actividad combina la generación de código y las pruebas que se

requieren.

Durante la construcción los desarrolladores crean el software,

alguna veces llamada implementación.
4. Construcción (… continuación)

La actividad construcción incluye:

✓ Diseño de métodos internos
✓ Escribir el código
✓ Escribir pruebas unitarias
✓ Probar y debugging

El código fuente es el producto de la actividad de

construcción.
5. Prueba y despliegue del software

El área de testing controla si el software cumple con

los requerimientos especificados.
El propósito de las pruebas es encontrar defectos
(bugs):
❑ Estrategias de caja negra y caja blanca
❑ Pruebas: Integración, de sistema, de aceptación,
regresión.
❑ Se pueden usar herramientas de automatización
5.1. Proceso de Prueba del Software

❑ Plan de pruebas
▪ Establecer el plan de pruebas durante la fase de
requerimientos y diseño
▪ Escenarios de prueba, casos de prueba, scripts
❑ Ejecución de las pruebas
❑ Informe de las pruebas
❑ Volver a probar los defectos
 5.2. Verificación y validación del software

¿Qué es la verificación y validación de software?

Controlar en todos los aspectos del desarrollo del software que se
conformen los requerimientos
Ejecutado por el equipo de Aseguramiento de calidad del
software (QA)

NO PUEDEN CERTIFICAR LA AUSENCIA DE DEFECTOS!

Solamente la disminución de la tasa de error
5.3. Despliegue

En esta actividad se entrega el software al consumidor que lo evalúa

y le da retroalimentación surgida de dicha evaluación.
Actividades sombrilla
Todas las actividades antes mencionadas son acompañadas por
actividades sombrilla que se aplican a lo largo del proyecto de
software, y nos ayuda a controlar la calidad, el cambio y el riesgo del
software. y generalmente son las siguientes:
❑ Seguimiento y Control del Proyecto del Software
❑ Gestión de Riesgo
❑ Aseguramiento de Calidad del Software
❑ Revisiones Técnicas Formales
❑ Medición
❑ Gestión de configuración del software
❑ Gestión de Reutilización
❑ Preparación y Producción del Producto de Trabajo
Actividades sombrilla
Seguimiento y Control del Proyecto del Software: Permiten al
equipo evaluar el progreso y tomar acciones correctivas para
mantener el plan, como así también solventar los diferentes
problemas que surgen. Además permite tomar las acciones
necesarias para apegarse al plan.
Gestión de Riesgo: Evalúan los efectos (riesgos) que pueden afectar
la calidad del producto o resultados del proyecto.
Aseguramiento de Calidad del Software: Actividades para
mantener la calidad del software.
Revisiones Técnicas Formales: Evalúa los productos de trabajo de
ingeniería para descubrir y eliminar errores antes que se propaguen
a la actividad siguiente.
Actividades sombrilla
Medición: Define y recoge medidas del producto, proyecto y
proceso para ayudar al producto del software a entregar un
producto que satisfaga las necesidades del cliente.
Gestión de configuración del software: Gestiona los efectos de
cambio en el software.
Gestión de Reutilización: Define el criterio para el reuso de
productos de trabajo y establece el mecanismo para la creación de
componentes reusables.
Preparación y Producción del Producto de Trabajo: Actividades
para crear modelos, documentos, informes, formularios, etc.
Chaos Report (Standish Group International)
120

100

16
27 26 28 29
34 35 32
80 37 39

Exitoso
60
53 33 Problematicos

46 Fracaso
49 44
53
51 46 42
40 43

20 40
31 28
23 24 21
18 19 18
15

0
1994 1996 1998 2000 2002 2004 2006 2008 2010 2012
 ¿Por qué fallan los proyectos?
Factores % de las respuestas
▪ Requisitos y especificaciones incompletas 13,1%
▪ Falta de involucramiento del usuario 12.4%
▪ La falta de Recursos 10.6%
▪ Expectativas poco realistas 9.9%
▪ Falta de Apoyo Ejecutivo 9.3%
▪ Cambios en los requisitos y especificaciones 8,7%
▪ Falta de Planificación 8.1%
▪ No se necesita mas 7.5%
▪ Falta de Gerencia Tecnológica 6.2%
▪ Objetivos poco claros 5,3%
▪ Incompetencia en la Tecnología 4.3%
▪ Otros 9,9%
 ¿Por qué fallan los proyectos?
▪ Metas poco realistas o no articuladas del proyecto
▪ Estimaciones erróneas de los recursos necesarios
▪ Requisitos del sistema mal definidos
▪ Deficiente información sobre el estado del proyecto
▪ Riesgos no administrados
▪ La falta de comunicación entre los clientes, desarrolladores y usuarios
▪ Incapacidad para manejar la complejidad del proyecto
▪ Prácticas de desarrollo descuidadas
▪ La mala gestión del proyecto
▪ Las presiones comerciales
 ¿Por qué es tan difícil?
❑ Muchas mas "partes” que en los dispositivos mecánicos
▪ Lavavajillas - 128 piezas // Automóvil - 14.000 piezas
▪ El transbordador espacial - 2,5 millones de piezas
❑ Red Hat Linux 7.1: 30 millones de líneas de código fuente
(SLOC)
❑ Mac Office - 30.000.000 SLOC
❑ El Boeing 777 tiene 4 millones de líneas de código y junto
con el Airbus A340 son totalmente dependientes del software.
❑ Un celular : 2.000.000 SLOC
 ¿Por qué es tan difícil?
❑ Red Hat Linux 7.1 30.000.000 SLOC
❑ Mac Office 30.000.000 SLOC
❑ El Boeing 777 4.000.000 SLOC
❑ Un celular 2.000.000 SLOC
❑ Un programador promedio x día = 100 SLOC
❑ 5 días x semana x 52 semanas x año = 26.000 SLOC x año
❑ Un equipo de 15 programadores = 390.000 SLOC x año
 ▪ El Ciclo de Vida de un sistema de información
(SDLC, Systems Development life cycle) es una
metodología usada para facilitar el desarrollo de
los sistemas.
Ciclo de ▪ Es un enfoque por fases para el análisis y el diseño

vida de cuya premisa consiste en que los sistemas se

desarrollan mejor utilizando un ciclo especifico de

desarrollo actividades del analista y el usuario. (Kendall &

Kendall).

software ▪ Ayudan a los gestores de proyecto con la

planificación y la puesta en marcha de un sistema
de información el cual debe cumplir con los
requisitos del usuario, debe ser completado a
tiempo y dentro de los límites del presupuesto.
 Etapas del Procesos de Desarrollo de Software
Metodología Kendall & Kendall
1. Identificación de 3. Análisis de las 5. Desarrollo y 7. Implantación y
problemas, oportunidades y necesidades del documentación del evaluación del
objetivos sistema software sistema

2. Determinación de los 4. Diseño del sistema 6. Pruebas y

requerimientos de recomendado mantenimiento del
información sistema
 FASE 1. Identificación de problemas, oportunidades y objetivos
SDLC, Systems Development En esta etapa se deberá descubrir lo que la organización intenta
realizar, luego determinar si el uso de los sistemas de información
apoyaría a la organización para alcanzar sus metas. Observación
FASES del Ciclo

directa del entorno.

life cycle

FASE 2. Determinación de los requerimientos de información

Esto se hace a partir de los usuarios particularmente involucrados,
para determinar los requerimientos de información dentro de una
organización pueden utilizarse diversos instrumentos, los cuales
incluyen: muestreo, el estudio de los datos y formas usadas para la
organización, la entrevista, los cuestionarios; la observación de la
conducta de quien tomó las decisiones.
 FASE 3. Análisis de las necesidades del sistema
SDLC, Systems Development Se analizan las necesidades propias del sistema. También se
analizan las decisiones estructuradas por realizar, que son
decisiones donde las condiciones, condiciones alternativas,
FASES del Ciclo

acciones y reglas de acción

life cycle

FASE 4. Diseño del sistema recomendado

Se usa la información recolectada con anterioridad y se
elabora el diseño lógico de sistemas de información, esta
etapa también incluye el diseño de los archivos o la base de
datos que almacenará aquellos datos requeridos por quien
toma las decisiones en la organización.
 FASE 5. Desarrollo y documentación del software
Dentro de las técnicas estructuradas para el diseño y documentación
SDLC, Systems Development del software se tienen: método HIPO, los diagramas de flujo, los
diagramas UML y el pseudocódigo. Es aquí donde se transmite al
programador los requerimientos de programación. Diseño y
FASES del Ciclo

Codificación.
life cycle

FASE 6. Pruebas y mantenimiento del sistema

Todo sistema de información debe probarse antes de ser utilizado, ya
que el costo es menor si se detectan los problemas antes de que entre
en funcionamiento.

FASE 7. Implantación y evaluación del sistema.

Esta es la última etapa del desarrollo del sistema, esto incluye el
adiestramiento que el usuario requerirá. Uno de los criterios
fundamentales que debe satisfacerse, es que el futuro usuario utilice el
sistema desarrollado.
 Un modelo de ciclo de vida de software es
una vista de las actividades que ocurren
durante el desarrollo de software, intenta
Modelos determinar el orden de las etapas
involucradas y los criterios de transición
de asociadas entre estas etapas.Describe las
Ciclo fases principales de Desarrollo de software.
Ayuda a administrar el progreso del
de Desarrollo, y prove un espacio de trabajo
para la definicion de un detallado proceso de
Vida Desarrollo.
 Es un proceso (normativo) que provee una
solución (modelo) para el desarrollo de un
sistema.
Modelos Identifica etapas y secuencia en el Desarrollo.
de Encapsula el conocimiento de casos pasados
Facilita el desarrollo de nuevos casos
Ciclo Etapas:
de Identificación de requerimientos, Diseño
(lógico y físico), implantación, testeo y Puesta
Vida en marcha, operación, y mantención
 Ventajas
• Evitar partir de cero en cada poyecto.
• Pone el énfasis en el proyecto mismo, en
Modelos vez de la forma de desarrollarlo
de • Comúnmente aceptado (lenguaje
común)
Ciclo Desventajas
• Inflexibilidad en la adaptación a casos
de particulares.
Vida • Bajo nivel de cuestionamiento al
adoptarlo.
Modelos
de Ciclo
de Vida
Modelos
de Ciclo
de Vida
 Modelos de Ciclo de Vida – Espiral
El modelo espiral de Boehm consta de una serie de ciclos. Cada uno empieza
identificando sus objetivos, alternativas y restricciones. hace especial hincapié en la
prevención de riesgos: Se evalúa las alternativas respecto a los objetivos tomando
en cuenta las restricciones. Una vez finalizado se plantea el próximo ciclo. Este
modelo define cuatro actividades principales:
▪ Planificación (determinar los objetivos, alternativas y restricciones del proyecto)
▪ Análisis de riesgos (análisis de alternativas e identificación/resolución de riesgos),
▪ Ingeniería (desarrollo del producto)
▪ Evaluación (revisión por parte del cliente y valoración de los resultados obtenidos
de cara a la siguiente iteración).
En cada iteración alrededor de la espiral se construyen versiones cada vez más
completas del software.
Modelos
de Ciclo de
Vida –
Espiral
Modelos de Ciclo de Vida – Espiral
Una vez realizado el primer ciclo se vuelve ha empezar.
Cada ciclo se completa con una revisión.
Las características del método Espiral son:
▪ Existe conocimiento explicito de las diferentes alternativas a
alcanzar
▪ La identificación de riesgos asociado a cada alternativa y como
resolverlos.
▪ División de proyecto en ciclos, y cada uno con un acuerdo final de
ciclo
▪ El modelo se adapta a cualquier tipo de actividad
 Modelos de Ciclo de Vida – Clásico o Cascada
El modelo de ciclo de vida clásico, también denominado "modelo en
cascada", se basa en intentar hacer las cosas bien desde el principio, de
una vez y para siempre. Es el modelo mas antiguo, propuesto por Winston
Royce en 1970. Es un modelo orientado en las actividades
Algunas Características:
✓Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con
éxito las tareas, de verificación y validación, propias de la etapa. Si
resulta necesario, únicamente se da marcha atrás hasta la fase
inmediatamente anterior.
✓Ayuda a prevenir que se sobrepasen la fecha de entrega y los costos
esperados
✓Al final de cada fase técnicos y usuarios tienen la oportunidad de
revisar el proceso del proyecto.
Modelos de Ciclo de Vida – Clásico o Cascada
Ciclo de Vida Clásico o Cascada - Fortalezas
❑ Fácil entendimiento e implementación
❑ Ampliamente utilizado y conocido (En teoría)
❑ Refuerza buenos hábitos: definir antes que diseñar,
diseñar antes que codificar
❑ Identifica entregables e hitos
❑ Orientado a documentos
❑ Funciona bien en productos maduros y equipos débiles
 Modelos de Ciclo de Vida – Clásico o Cascada
Ciclo de Vida Clásico o Cascada – Debilidades
▪ Los proyectos reales raramente siguen el flujo secuencial de actividades
que propone este modelo. (REALIDAD VS DISEÑO/ficción)
▪ No aprovecha la iteración, ni el desarrollo exploratorio
▪ Es difícil para el cliente establecer todos los requisitos al comienzo del
proyecto (entre otras cosas, porque hasta que no vea evolucionar el
proyecto no tendrá una idea clara de qué es lo que realmente quiere).
▪ Dificultar para integrar administración del riesgo
▪ La versión operativa del sistema se entrega en la etapa final del
proyecto, es decir hacer cambios es difícil y costoso, también esto hace
que se detecten errores graves muy tarde.
Modelos de Ciclo de Vida – Clásico o Cascada
FASE 1.
Identificación
FASE 2.
Determinación
FASE 3.
Análisis
FASE 4.
Diseño
FASE 5.
Desarrollo
FASE 6.
Pruebas
FASE 7.
Implantación
Modelos de proceso incremental

❑ Combina elementos de los flujos lineales y paralelos

❑ Aplica secuencias lineales en forma escalonada a medida que
avanza el calendario de actividades
❑ Cada secuencia produce “incrementos” de software susceptibles
a entregarse al cliente
Modelos de proceso incremental
Modelos de proceso incremental

Ejemplo: SOFTWARE DE PROCESAMIENTO DE TEXTOS

1. PRIMER INCREMENTO: Funciones básicas de administración de

archivos, edición y producción de documento
2. SEGUNDO INCREMENTO: Herramientas más sofisticadas de
edición y producción de documentos
3. TERCER INCREMENTO: Revisión de ortografía
4. CUARTO INCREMENTO: Formato avanzado
Modelos de proceso incremental

❑ Para cualquier incremento puede incorporarse prototipos

❑ Frecuentemente el primer incremento es el producto
fundamental. Es decir aborda los requerimientos básicos.
❑ El cliente utiliza el producto fundamental o sea lo somete a una
evaluación, y como resultado pueden surgir
modificaciones para cumplir mejor las necesidades
❑ Cada incremento entrega un producto operativo
Modelos de Ciclo de Vida – en V
❑El mayor inconveniente del modelo de cascada es que solo se pasa a la
siguiente fase cuando se completa la anterior, por tanto no es posible volver
atrás si se encuentra algún error en las etapas posteriores. El Modelo V aporta
opciones de evaluación del software en cada etapa de manera inversa.
❑En cada etapa, se crea la planificación de las pruebas y los casos de pruebas
para verificar y validar el producto según los requisitos de la etapa. Por
ejemplo, en la etapa de recolección de requisitos, el equipo de evaluadores
prepara las pruebas de caso correspondientes a los requisitos. Más tarde,
cuando el producto se desarrolla y está preparado para ser evaluado, las
pruebas de caso en esta etapa verifican el software y su validez según sus
requisitos.
❑Esto hace que tanto la verificación como la validación vayan en paralelo. Este
modelo también se conoce como modelo de validación y verificación.
Modelos
de Ciclo de
Vida – en V
Modelos
de Ciclo de
Vida – en V
Modelos de Ciclo de Vida – Prototipado

Desarrollo de prototipos
El prototipado permite al cliente evaluar en forma temprana el producto, e
interactuar con los diseñadores y desarrolladores para saber si se está
cumpliendo con las expectativas y las funcionalidades acordadas. Esto en
manera especial si el cliente es capaz de definir un conjunto general de
objetivos para el sistema que hemos de construir, pero no identifica los
requisitos detallados. En otros casos, puede que nosotros no estemos seguros
de la eficiencia de un algoritmo, de la capacidad de nuestro diseño para
soportar los requerimientos del sistema o de la forma en que debe diseñarse la
interfaz de usuario.
Modelos de Ciclo de Vida – Prototipado

Desarrollo de prototipos
En cualquiera de estas situaciones, resulta adecuado construir un prototipo, ya
que da una idea concreta de lo que va a hacer el sistema, aunque no poseen la
funcionalidad total del sistema, y se aplica cuando la rapidez de desarrollo es
esencial.
De cada prototipo se extraen ideas buenas que se usan para el siguiente
prototipo (usar y tirar)
Modelos de Ciclo de Vida – Clásico o Cascada
Prototipos
FASE 1.
Identificación
FASE 2.
Determinación
FASE 3. Análisis

FASE 4. Diseño

PROTOTIPO
FASE 5. Desarrollo

FASE 6. Pruebas

PROTOTIPO PROTOTIPO FASE 7.

Implantación
Modelos de Ciclo de Vida – Prototipos
 Modelos de Ciclo de Vida – Iterativos
ANALISIS ANALISIS ANALISIS

DISEÑO DISEÑO DISEÑO

CODIFICACION CODIFICACION CODIFICACION

PRUEBAS PRUEBAS PRUEBAS

VERSION 1 VERSION 2 VERSION N

Los modelos iterativos consisten en descomponer un proyecto de desarrollo

de software en una serie de subproyectos de menor envergadura. Estos
subproyectos deben diseñarse de tal forma que cada uno de ellos aporte
funcionalidad nueva para el sistema desde el punto de vista del usuario final
del mismo.
Modelos de Ciclo de Vida – Iterativos

Promueven una mejor comunicación con el usuario/cliente, ya que

se dispondrá antes, de una versión operativa del sistema, aunque
sea de funcionalidad reducida. Estas versiones intermedias del
producto ayudan a la eliminación de malentendidos que pueden
surgir en la etapa de obtención de requerimientos. Además, ayudan
a que el usuario se forme una idea más clara de lo que realmente
necesita.
Modelos de Ciclo de Vida – ¿Cascada o Iterativos?
El modelo de desarrollo más adecuado para un proyecto dependerá del tipo de
sistema que se ha de construir:
▪En general, se elegirá un modelo cascada cuando los requerimientos se
conocen bastante bien y son estables, cuando el diseño será similar al de otros
sistemas con los que tenemos experiencia, cuando los integrantes del equipo
de desarrollo ya se conocen y están familiarizado con el entorno de desarrollo.
▪En la práctica, sin embargo, los modelos iterativos se adaptan mejor a la
realidad del desarrollo de software (especialmente en sistemas medianos y
grandes). Seleccionaremos un modelo iterativo cuando los requerimientos no
se conocen con exactitud o se prevé que puedan cambiar en el futuro, cuando
el diseño del sistema es complejo o no tiene precedentes para nosotros,
cuando el proyecto en sí es arriesgado económicamente y cuando podamos
controlar el costo de futuros cambios en el sistema.
Modelos de proceso especializado
❑ Desarrollo basado en componentes
❑ Construye aplicaciones a partir de fragmentos de software
prefabricados
❑ Las actividades de modelado y construcción comienzan con la
identificación de candidatos de componentes. Estos pueden
diseñarse como modulos, clases o paquetes
❑ Permite la reutilización del software que brinda la posibilidad
de reducer el tiempo de desarrollo y los costos
Modelos de Ciclo de Vida – Método Ágil - Scrum

La agilidad en el corazón de los proyectos

Ser ágil significa ser una persona con ligereza y
flexibilidad en los movimientos corporales, lo mismo
se aplica a los ciclos de vida
Modelos de Ciclo de Vida – Método Ágil - Scrum
Desde el punto de vista del usuario:
• Scrum es un proceso ágil que permite focalizar en la entrega del
mayor valor de negocio en el menor plazo.
• El negocio fija las prioridades. Los equipos se autogestionan para
determinar la mejor manera de entregar las funcionalidades de
mayor prioridad.
• Permite inspeccionar software listo para ser liberado en forma
rápida y continua.
• Al final de cada iteración se puede ver el software funcionando.
• Se decide liberarlo como está o continuar mejorándolo durante
otra iteración.
Modelos de Ciclo de Vida – Método Ágil - Scrum

Scrum desde el punto del equipo de trabajo:

• Equipos autoorganizados.
• Usa reglas generativas para crear un entorno ágil para la
ejecución de proyectos.
• No se prescriben prácticas de ingeniería.
• El producto avanza en una serie de iteraciones o (“sprints”)
de 1 a 4 semanas.
• Los requerimientos son capturados como ítems en la lista
“Product backlog”.
• Es uno de los “procesos ágiles”.
Scrum, un mix de métodos inspirados en sus primos:
Los elementos de Lean Management: Los elementos de Kanban:
• Adaptación • Escritura de las necesidades del
• Introspección cliente en una etiqueta
• Uso de post-it • Visualización del workflow del
• Gran interés por la calidad trabajo actual
• Enfoque empírico
Los elementos del método eXtreme Programming (XP):
• Realizar entregas frecuentes
• Implementar un ritmo de trabajo duradero
• Hace que el cliente sea una parte integrante del proyecto
• Responsabilizar al equipo
• Implementar las pruebas
• Utilizar un Planning Poker para la estimación.
 Modelos de Ciclo de Vida – Método OO

 El modelo de desarrollo basado en componentes incorpora las

siguientes etapas:
1. De acuerdo al tipo de aplicación del que se trate, se investiga y
se evalúan los productos disponibles basados en componentes
2. Se consideran los aspectos de integración de componentes
3. Se diseña una arquitectura de software para que reciba los
componentes
4. Se integran los componentes a la arquitectura
5. Se efectúan pruebas exhaustivas para comprobar el correcto
funcionamiento
Proceso Unificado

◼ Reconoce la importancia de la comunicación con el cliente y

los métodos directos para describir su punto de vista respecto
de un sistema (el caso de uso)
◼ En 1990 Rumbaugh, Booch y Jacobson lanzaron el “modelo
unificado” que combinaria lo mejor de cada uno de sus
métodos individuales de análisis y diseño orientado a objetos.
El resultado fue el Lenguaje de Modelado Unificado (UML)
 Proceso
Unificado
Proceso Unificado – Fase de concepción

 La fase de concepción agrupa las actividades de comunicación y

planeación permitiendo identificar los requerimientos del
negocio. Luego se obtiene una arquitectura aproximada para el
sistema
 Los requerimientos fundamentales del sistema se describen por
medio de un conjunto de casos de uso preliminares
 La planeación identifica y evalúa los riesgos potenciales, los
recursos disponibles, define un programa de actividades.
Proceso Unificado – Fase de elaboración

 En la fase de elaboración se crea una linea base de la

arquitectura que demuestra la viabilidad de ésta, pero no
proporciona todas las características y funciones que se
requieren para usar el sistema.
 Es frecuente que en este momento se hagan modificaciones al
plan
Proceso Unificado – Fase de construcción

 Con el modelo de arquitectura como entrada, en esta fase se

desarrolla o adquiere los componentes de software que hará
que cada caso de uso sea operativo para los usuarios finales.
 Se implementan en código fuente todas las características y
funciones necesarias para el incremento de software
 A medidas que se implementan los componentes se deben
realizar pruebas unitarias y pruebas de aceptación
Proceso Unificado – Fase de transición
 Incluye las últimas actividades de la etapa de construcción y la
primera parte de la etapa de despliegue (entrega y
retroalimentación).
 Se entrega el software a los usuarios finales para que estos lo
evalúen y reporten incidentes o cambios necesarios.
 El equipo debe generar la documentación necesaria como
manuales, guías de solución de problemas, procedimientos de
instalación, etc.
 Al finalizar la etapa de transición el software se convierte en un
producto utilizable que se lanza
Proceso Unificado – Fase de producción
 Coincide con la actividad de despliegue del proceso general.
Durante esta fase se vigila el uso que se le da al software, se
brinda apoyo y se reportan defectos o solicitudes de cambio
para su evaluación.

Producto y Proceso
 Siel proceso es deficiente el producto seguramente sufrirá, pero
también es importante no generar una dependencia absoluta del
proceso
 Procesos de Mejora del Software.
Conceptos de proceso
• Se puede definir como un “conjunto coordinado de actividades que proporcionan un
valor añadido al cliente, entregándole un resultado (el producto o servicio que se trate)
que le satisfaga, partiendo de una serie de entradas al proceso y con la utilización de una
serie de recursos” .
• Un proceso es “un conjunto de actividades interrelacionadas, que persiguen la creación
de valor y que su salida final es la conformación de un bien o servicio para un cliente que
puede ser interno o externo a la organización”.
• Una vez analizados los diferentes conceptos se define a un proceso como, un conjunto
de actividades o tareas que se relacionan entre sí, y que se ejecutan siguiendo un orden
lógico con el propósito de alcanzar un resultado específico a partir de las entradas de
recursos e información. Los procesos constituyen uno de los principales problemas
dentro de las organizaciones productoras de software, que impiden el incremento de la
productividad y la calidad, de ahí la necesidad de trazar estrategias para mejorarlos.
Procesos de Mejora del Software.
Conceptos de mejora
• La palabra mejora está vigente en diferentes esferas de la vida, sobre todo en
ambientes empresariales donde ha dejado de ser una opción para
convertirse en una imperiosa necesidad.
• Mejora proviene del verbo mejorar que implica cambiar, se define que
mejora no es más que mejorar algo haciéndolo pasar a un estado superior.
• Muchas organizaciones entre ellas las productoras de software, se han dado
cuenta de que no basta con incrementar su productividad, sino que es
necesario lograr productos con calidad, pues la competencia en el mercado
es cada vez mayor, preocupación que contribuyó al surgimiento de la
iniciativa de mejorar los procesos como una solución a esto.
Procesos de Mejora del Software.
• En esencia, la Mejora del Proceso del Software es simple, consiste en aplicar
las prácticas que proporcionan buenos resultados y cambiar o eliminar las
prácticas que causan problemas. Es innegable el valor que tiene la Mejora del
Proceso, pues según estudios realizados muchas empresas implicadas en la
mejora del Proceso Software, han logrado reducir los costos de producción,
mejorar la calidad del producto y ajustarse a las necesidades de los clientes.
• Otros beneficios han sido lograr un entorno de trabajo más estable, una
reducción de la tasa de rotación del personal y una mejora en las relaciones
de trabajo con los clientes. En fin son múltiples los beneficios que se pueden
obtener al llevar a cabo una Mejora de Procesos, por esto se necesita que los
grupos encargados de llevarlo a cabo se sientan comprometidos, para lograr
el CMMI.
Procesos de Mejora del Software.
CMMI como modelo para la Mejora de Procesos
Uno de los modelos de mejora de procesos más usados en las organizaciones es
el CMMI: “Capability maturity model Integration” (Integración de modelos de
madurez de capacidades)
El CMMI, es un modelo que ayuda a: integrar las funciones de la organización,
conducir la mejora de los procesos, proporciona una guía de calidad de los
procesos y puntos de referencia para la evaluación de estos. El propósito del
modelo es proveer una guía para mejorar los procesos de la organización y la
capacidad para gestionar el desarrollo, la adquisición y el mantenimiento de
productos y servicios.
 Procesos de Mejora del Software.
CMMI como modelo para la Mejora de Procesos
Este modelo consta de cinco niveles de madurez que clasifican a la organización, estos
niveles sirven para conocer la madurez de los procesos que se realizan para producir
software.
Los niveles de madurez de una organización en CMMI son :
1. Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
5. Optimizado.
Cada nivel comprende un conjunto de áreas de proceso estas cubren desde el
desarrollo de los productos y de los servicios hasta el mantenimiento de los mismos.
Independientemente de la disciplina a cual esté enfocada la organización, las áreas de
proceso se subdividen en grupos distintos los cuales dependen de cada
representación ya sea la continua o por etapas.
Procesos de Mejora del Software. CMMI
“Capability maturity model Integration”
(Integracion de modelos de madurez de capacidades)

OPTIMIZADO

GESTIONADO
CUANTITATIVAMENTE

DEFINIDO

GESTIONADO

INICIAL
 Procesos de Mejora del Software. CMMI
5. Optimizado: Se centra en mejorar continuamente el rendimiento de sus procesos mediante
mejoras incrementales de proceso y tecnológicas. La organización se interesa en tratar
causas comunes de variación del proceso y cambia el proceso para mejorar el rendimiento.
4. Gestionado cuantitativamente: La organización y los proyectos establecen objetivos
cuantitativos en cuanto al rendimiento de calidad. Los objetivos los utilizan como criterios de
gestión. El rendimiento de calidad y del proceso se mide en términos estadísticos.
3. Definido: Los procesos son bien caracterizados y se describen en estándares,
procedimientos, herramientas y métodos. Un proceso definido establece claramente el
propósito, entradas, actividades, roles, medidas, etapas de verificación, salidas y criterios de
salida.
2. Gestionado: Los proyectos de la organización han asegurado que los procesos se planifican y
realizan de acuerdo a políticas. Los procesos se realizan y gestionan de acuerdo a sus planes
documentados.
1. Inicial: los procesos son generalmente ad-hoc y caóticos. La organización no proporciona un
entorno estable para dar soporte a los procesos. A menudo se producen productos y
servicios que funcionan, sin embargo, exceden sus presupuestos y no cumplen sus
calendarios.
Procesos de Mejora del Software.
Riesgos en la implantación de Proceso de Mejora de Software
Los procesos de mejora en el desarrollo de software, trae cambios muy
profundos en las organizaciones que desean implementar estos modelos, los
administradores o jefes de proyectos deben asumir estas transformaciones
oportunamente, para evitar catástrofes que incluso pueden llevar a la
frustración en la implementación de modelos de mejora.
Para que un Proceso de Mejora de desarrollo del software tenga éxito, se
requiere que los encargados de llevarlo a cabo estén dispuestos y preparados
para asumir los cambios que estos modelos traen para las organizaciones.
Dos tercios de los proyectos de mejora no concluyen con éxito tras una
evaluación formal, pues existen riesgos que pueden conducir al fracaso de estas
iniciativas.
 Procesos de Mejora del Software.
Riesgos en la implantación de Proceso de Mejora de Software
Entre los riesgos que atentan contra la implantación exitosa de Procesos de Mejora se
encuentran:
• Comunicación poco efectiva por parte de los gestores de proyectos o dentro de los
mismos equipos de desarrollo de software.
• Poca comprensión de los equipos de desarrollo de los verdaderos objetivos y
alcances de los procesos de mejora, esto los puede hacer sentir desmotivados,
pues existen cambios organizacionales que para el equipo de desarrollo pueden
ser bastante incómodos.
• Problema de “entendimiento” entre las partes involucradas que conllevan al
fracaso del proceso.
• Falta de una cultura organizacional, lo que incide negativamente en la organización
pues es como un grupo de personas que no pueden comunicarse entre sí. La
creencia de que el software se puede mejorar sólo con estándares, métricas y
buenas prácticas, puede hacer fracasar la iniciativa de mejora.
Madurez de las Organizaciones
Calidad del Software.

• El objetivo general de la ingeniería de software es la producción

de software de calidad.
• La calidad del software puede ser considerada desde dos
perspectivas diferentes; la óptica del desarrollador y la del cliente
o usuario final.
• Los factores que afectan al desarrollador se denominan Internos
y los del cliente Externos
• El nivel de calidad esta definido por la ISO 25010
Calidad del Software.
Calidad del Software.
Calidad del Software.
 Calidad de • ¿Cuantos requisitos se han modificado?
• ¿Cuántos se han añadido? ¿Cuántos se han eliminado?
Análisis
Calidad del Software?
Calidad de • ¿Cuantos cambios se han producido en el diseño técnico?
¿Cómo se mide la

Diseño
• ¿Cuantos cambios de arquitectura se han producido?
Calidad de
Arquitectura

Calidad de • ¿Cuantos Defectos se han detectado en pruebas unitarias?

Desarrollo
• ¿Cuántos defectos ha detectado el cliente en producción vs
Calidad de defectos encontrados en pruebas en general? ¿Cuál es el ratio nº
Pruebas defectos encontrados vs hs. Invertidas en pruebas?
 ¿Cómo se mide la
Calidad del Software?
ISO 25010