Lic.

Cesar Espinoza Jiménez

Objetivo de la Materia

Introducir al estudiante a las metodologías existentes
en la Industria del Software para asegurar la calidad de
los proyectos.

Desarrollar las habilidades del estudiante para medir
sus procesos personales de Software
Bibliografía Básica

Ingeniería del Software : Un enfoque práctico.
Roger S. Pressman. Mc Graw Hill 6ta Edición

Ingeniería del Software: orientado a objetos. Erick
Braude. Alfa-Omega 1era Edición

Ingeniería del Software.
Ian Sommerville Preston Education 8ta Edición
¿ Podemos iniciar?
Autodiagnóstico

De manera individual
defina los siguientes
conceptos:

Calidad
Metodología

Software
UML

Desarrollo
Madurez

Proceso
Capacidad

Paradigma
Modelo
Retroalimentación

En grupos de 4
personas discuta sus
definiciones y lleguen a
un consenso.
Contenido Temático
1. Ingeniería de Software y Calidad
1.1 Conceptos básicos de Calidad
1.2 Factores que determinan la calidad del Software
1.3 Características del Software
1.4 Modelos de desarrollo de Software
1.5 Importancia de las diferentes etapas en el Desarrollo
de Software
Contenido Temático
2. Métricas y Procesos (PSP)
2.1 Introducción al Personal Software Process (PSP)
2.2 Estructura del PSP
2.3 Métricas del PSP
Contenido Temático
3. CMM-I Capability Maturity Model - Integration
3.1 Inmadurez y madurez en los procesos de Creación de
Software
3.2 Los cinco niveles de madurez en los Procesos de
Creación de Software
3.3 Definición operacional del modelo CMM
3.4 ¿ Porqué usar el modelo CMM – I?
Ingeniería de Software y Calidad
Objetivo de la Unidad

Introducir al alumno en el análisis de los diferentes
modelos de desarrollo de Software, así como su
relación con los conceptos básicos de calidad en el
desarrollo de sistemas.
1.1 Conceptos Básicos de Calidad
1. 1 Conceptos básicos de calidad

Clasifique las siguientes marcas en base a su calidad:

1. 1 Conceptos básicos de calidad

Calidad
“Conjunto de propiedades y de características de un
producto o servicio, que le confieren aptitud para
satisfacer unas necesidades explícitas o implícitas”.
(Norma ISO 9000:8402)

“Característica o atributo de algo”( American Heritage
Dictionary).
1. 1 Conceptos básicos de calidad

Calidad

Características
mensurables: cosas que
se pueden comparar con
estándares conocidos
como: longitud , color,
maleabilidad.
1. 1 Conceptos básicos de calidad

Control de Calidad
“Conjunto de técnicas y actividades de carácter
operativo, utilizadas para verificar los
requerimientos relativos a la calidad del producto
o servicio”
1. 1 Conceptos básicos de calidad

¿ Qué control de
calidad aplicarías, por
ejemplo, para comprar
un par de zapatos
deportivos (tennis)?
1. 1 Conceptos básicos de calidad

Garantía de calidad
“Conjunto de acciones planificadas y sistemáticas
necesarias para proporcionar la confianza
adecuada de que un producto o servicio satisface
los requerimientos dados sobre calidad.”
1. 1 Conceptos básicos de calidad

Garantía de calidad
En software es un diseño de acciones planificado
y sistemático, que se requiere para asegurar la
calidad del software.
1. 1 Conceptos básicos de calidad

Calidad del Software
“Es el grado con el que un sistema, componente o
proceso cumple con los requerimientos y las
necesidades o expectativas del cliente o usuario”
(IEEE 610/1990)
1. 1 Conceptos básicos de calidad

Calidad del Software
“Concordancia del software producido con los
requerimientos explícitamente establecidos,
con los estándares de desarrollo prefijados y
con los requerimientos implícitos no
establecidos formalmente que desea el
usuario”.( Pressman, 2006).
1.2 Factores que determinan la calidad del SW
1. 2 Factores que determinan la calidad del
software

a) Factores que se pueden medir directamente (objetivo:

cualitativo)
b) Factores que se pueden medir indirectamente
(subjetivo)
1. 2 Factores que determinan la calidad del
software
Factores de Calidad de McCall

Características Operativas

Capacidad de soportar cambios

Adaptabilidad a nuevos entornos
Características Operativas

Corrección

¿ HACE LO QUE QUIERO?

Hasta donde satisface un programa una especificación
y logra los objetivos del cliente.
Características Operativas

Fiabilidad

¿ Lo hace de forma fiable

todo el tiempo?
Hasta donde se puede esperar que un programa lleve a
cabo su función pretendida con la exactitud requerida
Características Operativas

Eficiencia

¿ Se ejecutará en mi HW lo
mejor que se pueda?
La cantidad de recursos informáticos y código
necesaria para que un programa realice su función.
Características Operativas

Seguridad

¿ Es seguro?
Hasta donde se puede controlar el acceso al software o
a los datos por personas no autorizadas.
Características Operativas

Usabilidad

¿ Es fácil de manejar?
El esfuerzo necesario para aprender, operar , preparar
datos de entrada e interpretar salidas (resultados) de
un programa.
Capacidad de soportar cambios

Facilidad de mantenimiento

¿Puedo corregirlo?
El esfuerzo necesario para localizar y arreglar un error
en un programa.
Capacidad de soportar cambios

Flexibilidad

¿Puedo cambiarlo?
El esfuerzo necesario para modificar un programa
operativo.
Capacidad de soportar cambios

Facilidad de prueba

¿Puedo probarlo?
El esfuerzo necesario para probar un programa y
asegurarse de que realiza la función pretendida.
Adaptabilidad a nuevos entornos

Portabilidad

¿Podré usarlo en otra

máquina?
El esfuerzo necesario para transferir el programa de un
entorno de sistema de HW y/o SW a otro.
Adaptabilidad a nuevos entornos

Reusabilidad
¿Podré reutilizar alguna parte
del software?
Hasta donde se puede volver a emplear un
programa (o partes de un programa) en otras
aplicaciones, en relación con el empaquetamiento y
alcance de las funciones que realiza el programa.
Adaptabilidad a nuevos entornos

Interoperabilidad

¿Podré hacerlo interactuar

con otro sistema?
El esfuerzo necesario para acoplar un sistema con otro.
1.3 Características del SW
1.3 Características del Software

Crisis del SW

Software

Características del SW
Crisis del Software
La industria del
software no ha
podido
satisfacer la
demanda.
La complejidad
del software
producido y
demandado se
incrementa
constantemente.
Crisis del Software

Síntomas

1. Baja Calidad del Software.

2. Tiempo y Presupuesto
Excedido.
3. Confiabilidad Cuestionable.
4. Altos Requerimientos de
Personal para desarrollo
y mantenimiento.
Crisis del Software

Factores de influencia

1. Aumento del poder computacional.

2. Reducción del costo del hardware.
3. Rápida obsolescencia de hardware y
software.
Crisis del Software
Factores de influencia

4. Aceptación de la computarización en las

empresas.
5. Incremento en el número de usuarios de los
sistemas de software.
6. Tipo de usuario no homogéneo aun en sistemas
hechos a la medida.
Crisis del Software
Factores de influencia

7. Personal de desarrollado y mantenimiento

diferente.
8. La magnitud del proyecto impacta en:
a. Tiempo costo y número de desarrolladores,
b. Control administrativo y detalles técnicos
9. Aumento en el conocimiento del problema.
Crisis del Software

Factores de influencia
10. Cambios en el entorno:
a. Tecnológicos (Internet,redes,ERP,CRM,SCM..)
b. Económicos (crisis económicas, globalización,..)
c. Sociales (nuevas necesidades, costumbres nuevas,..)
d. Ambientales (...)
e. ...
Preguntas
1. ¿Cómo desarrollar software?
2. ¿Cómo dar mantenimiento al creciente volumen de
software?
3. ¿Cómo poder mantenerse al corriente a la creciente
demanda de software?
4. ¿Porqué lleva tanto tiempo terminar los programas?
5. ¿Porqué tan caro?
6. ¿Porqué no podemos encontrar todos los errores?
7. ¿Porqué es tan difícil evaluar el avance?
Preguntas por equipo:
1. ¿Cómo desarrollan el software en las
organizaciones?
2. ¿Los desarrolladores de hoy en día están
concientes del problema del ciclo de software?
 1.3.1 Software
Programas
Estructura de datos + algoritmos
Producto de software
Conjunto de elementos de software (programas, tablas,
reportes, documentación, etc.) que tienen un propósito
específico y completo desde el punto de vista del usuario,
de tal manera que la sustracción de cualquiera de los
elementos del conjunto daría como resultado que el
propósito no se cumpliera.
 1.3.1 Software
a) Instrucciones (programas de computadora) que cuando
se ejecutan proporcionan la función y el rendimiento
deseados
b) Estructuras de datos que permiten a los programas
manipular adecuadamente la información
c) Documentos que describen la operación y uso de los
programas.
Productos de Software

Productos genéricos
(sw de mostrador)

Desarrollados por una
organización para ser
vendidos al mercado.
Productos de Software

Productos hechos a medida

Desarrollados bajo pedido a una empresa
desarrolladora de software.
Productos de Software

La mayor parte del gasto del software es en productos
genéricos, pero hay más esfuerzo en el desarrollo de los
sistemas hechos a medida.
1.3.2 Características del SW

Como
Producto

Como Proceso

Como
Proyecto
PRODUCTO

Tiene definidas una fecha

de inicio de desarrollo y
una fecha esperada o
estimada de terminación.

Apoya alguna función del

usuario hacia el cual está
dirigido.
Diferencias como producto

Se desarrolla y no se
fabrica como otros
productos.

No se estropea.

No se “desgasta”.

Hecho por humanos.
Atributos de los productos de SW

Facilidad de mantenimiento

Debe ser posible que el software evolucione y que siga cumpliendo
con sus especificaciones.

Confiabilidad

El software no debe causar daños físicos o económicos en el caso de
fallas.

Eficiencia

El software no debe desperdiciar los recursos del sistema.

Utilización adecuada

El software debe contar tanto con una interfaz de usuario adecuada
como con una documentación clara y precisa.
Importancia de los Atributos del Producto de
Software

La importancia relativa de las características depende del
tipo de producto y en el ambiente en el que será utilizado.

En algunos casos, algunos atributos pueden dominar.

En sistemas de seguridad críticos de tiempo real, los atributos clave
pueden ser la confiabilidad y la eficiencia.

Los costos tienden a crecer exponencialmente si se
requieren altos niveles de alguna característica.
Costos de eficiencia
Costos

Eficiencia
Metas de un producto

Productividad
• Mantenibilidad
• Usabilidad Calidad
• Confiabilidad
• Reusabilidad Costos
• Portabilidad
Tiempo
Clasificación del Software

Externas

Internas

Del
producto

Del
proceso
Propiedades del Software

Correctividad, Confiabilidad, Robustez.

Desempeño (performance)

Amigabilidad (Uso amigable)

Verificabilidad (Facilidad de verificar)

Mantenibilidad. Facilidad de mantenimiento:

Para su reparación → REPARABILIDAD

Para su evolución → VIGENCIA

Reusabilidad

Portabilidad

Comprensibilidad (Comprehensibility): Facilidad de
entenderse

Interoperabilidad
Formas de categorizar el software:

Por tipo de Aplicación o Disciplina.

Por tipo de Arquitectura

Por área Funcional

Por nivel Jerárquico

Por tipo de Estructura Organizacional

Por Tiempo de Respuesta
Aplicación o disciplina

Para sistemas

Sistemas tiempo real

Negocios

Ingeniería/científico

Empotrado (Embebido)

PC´s

Inteligencia artificial

Aplicaciones Web.
Tipo de arquitectura

Stand Alone

Main Frame

Red: LAN, WAN

Internet

Intranet

Extranet
Niveles o áreas funcionales
Directivo

Administración

Conocimiento

Operacional

Contabilidad Finanzas Ventas Recursos Manufactura

Mercadotecnia Humanos
Niveles o áreas funcionales
Directivo Sistema Soporte Ejecutivo (SSE)

Administración Sistema Soporte de Decisiones (SSD)

Sistema Información Admo. (SIA)

Conocimiento Sistema de Automatización de Oficinas. (SAO) / Apoyo

Trabajadores del Conocimiento (SATC)

Operacional Sistema de Transacción de Operaciones

(STO)
Nivel Jerárquico

Sistema de Transacción de Operaciones

Sistema de Apoyo a Trabajadores del Conocimiento

Sistema para la Automatización de Oficinas

Sistema de Información Administrativo

Sistema para Soporte de Decisiones

Sistema de Soporte Ejecutivo

Sistema de Soporte de Grupo

Sistema de Soporte Inteligente
Actividad Soportada

Sistemas Operacionales

Orientado hacia transacciones
diarias.

Sistemas Tácticos

Orientados a apoyar actividades
de mandos intermedios:
Estadísticas/ Reportes de
excepción/Reportes
Periódicos/Análisis
Comparativos/Proyecciones/Detecci
ón Temprana de
Problemas/Decisiones Rutinarias.

Sistemas estratégicos
Estructura organizacional

Sistemas de
Información
Departamentales

Sistemas de
Información
Empresariales

Sistemas de
Información
Interorganizacionale
s
Tiempo de Respuesta

Tiempo
Real

En línea

Batch
Actividad

Proporcione ejemplos de sistemas:

operacionales,

soporte a trabajadores del
conocimiento,

administrativos,

directivos.

¿Qué utilidad tendrá el clasificar
los productos de software?

¿Cuál es el orden de importancia
de las propiedades de un sistema
de información?
PROCESO

Características
importantes:

Productividad

Calendarización

Visibilidad
PROYECTO DE SOFTWARE

Un proyecto está integrado por un conjunto de

actividades para lograr uno o más productos de
software. Puede dividirse en uno o más
subproyectos conformados por subconjuntos de
actividades.
Proyecto de Software

Características:

Tiene una fecha de inicio definida y una
fecha de terminación. Sin embargo en la
práctica, la fecha de terminación se
puede alargar.

Se calendarizan entregas de “productos”
concretos y específicos.

Número de personas variable en el
tiempo.

Su propósito es proporcionar un
conjunto de facilidades que apoyen a
un conjunto de actividades del usuario
que lógicamente están relacionadas
entre sí.
Mitos del Software

3 puntos de
vista
3 expectativas
3 intenciones
1. El Gestor
2. El Cliente o
Usuario
3. El
Desarrollador
Mitos del Software

Gestor

Se tienen libros llenos
de estándares y
procedimientos para
desarrollar software

Tienen lo mas avanzado
en cómputo; tienen super
computadoras.

Si se falla en la
planeación, se incluye
mas personal.
Mitos del Software

Cliente

Una declaración
general de objetivos
es suficiente para
empezar la
programación del
sistema.

Los requisitos cambian,
pero se pueden
acomodar con facilidad.
Mitos del Software
Desarrollador

Escrito y
funcionando el
programa ya
terminó el proyecto

Solo funcionando el
programa se puede
evaluar la calidad
del sistema.

Lo único que se
entrega es el
código funcionando.
Impacto del cambio
“Cuando se puede medir
y cuantificar aquello
sobre lo que uno habla
y expresarlo en
números, se sabe algo
acerca de eso; cuando
no puede ser
expresado en números
el conocimiento es
escaso e
insatisfactorio...”
Lord Kelvin
Actividad

Describir un proyecto de desarrollo

de software y catalogarlo de
acuerdo a la clasificación vista.

Ordene los mitos vistos de acuerdo
con la creencia popular de las
organizaciones

¿Qué acciones se deben realizar en
su organización para eliminar y/o
atenuar los mitos del software?
Ingeniería del Software

Definición

Importancia

Sistemas de Calidad

Ciclo de vida

Documentos asociados

Modelos de Desarrollo

Aseguramiento de
Calidad. Pruebas.
Verificación y
Validación
 Definición Propuesta de solución
Establecer y usar principios
robustos de ingeniería con el
fin de obtener
económicamente software
que sea fiable y que
funcione eficientemente
sobre máquinas reales

Ingeniería en Software (ISW)

Aplicación de un enfoque sistemático,
disciplinado y cuantificable hacia el
desarrollo, operación y mantenimiento
del software, esto es, la aplicación
de la ingeniería al software
Ingeniería del Software
La
Ingeniería
de
Software
pretende:
Analizar, diseñar, construir y
dar mantenimiento a grandes
y complejos sistemas de
software.
Importancia de la Ingeniería de Software

LA INDUSTRIA DEL SOFTWARE,

UNA NUEVAS AREA DE
OPORTUNIDAD (PARA MEXICO)
Entorno Internacional
Mercado Mundial $541 mmusd.

Principales Mercados:
OTROS 14 % NORTEAMÉRICA 48 %

JAPÓN 12 %

EUROPA 26 %
Entorno Internacional
Principales Segmentos:
Administración de Negocios
Servicios de Administración
Servicios de Integración y Desarrollo de Sistemas
Servicios de Consultoría
Servicios de Mantenimiento y Soporte

Principales Proveedores:
India China
USA Rusia
Irlanda Pakistán
Israel Filipinas
Otros
Entorno Internacional

Crecimiento cercano al 15 % anual en los

próximos 5 años.
Severa escasez de personal capacitado en
Tecnologías de la Información.
770,000 en USA1
1,000,000 en Europa1
1,000,000 en Japón1
1 Puestos vacantes
Entorno Internacional
Intensa competencia entre los países de mayor
oferta por los mercados mas importantes.
Fuerte tendencia hacia servicios E-Commerce:
Integración de aplicaciones en Internet
Conversión a modelos basados en Internet
Desarrollo y mantenimiento de sitios WEB
Tendencia hacia la demanda de servicios
integrales.
Mercado total $1,584.2 musd
Sectores Principales:
Financiero
Gubernamental
Industrial
Industrial
Educación
Otros
Principales Servicios:
Desarrollo de aplicaciones Aplicaciones de
Mantenimiento de Internet.
sistemas. Soluciones e-business.
Servicios de consultoría. Aplicaciones
Integración de sistemas. empaquetadas.
 No. DE EMPRESAS 257

TIPO DE EMPRESA
 Nivel Internacional 15
 Con estructura formal 75
 Sin estructura formal 167
MEDIANAS 3.2%
GRANDES 2.8% PEQUEÑAS 4.0%

CERTIFICACIONES
MICRO 90% ☺ Certificación ISO 5
☺ Certificación CMM 5
Oportunidades

• Mercado viable en Norteamérica de $20,000

mdd.

• Potencial para atraer entre 500 y 1,000 nuevas

empresas.

• Creación de nuevos polos de desarrollo.

• Creación de un flujo neto de divisas positivo.

Sistema de Calidad del Software

Estándares

Revisiones

Pruebas

Análisis de defectos

Administración de la
configuración

Seguridad

Educación

Administración de
contrataciones
Ingeniería de Software: Elementos

Herramientas
Procesos

Métodos
ELEMENTOS
Métodos

Los métodos indican cómo construir técnicamente el software.

Tareas que componen los métodos.

Planificación; Estimación de proyectos.

Análisis de requerimientos del software y hardware.

Diseño de estructuras de datos, Arquitectura de los programas.

Procedimientos algorítmicos.

Codificación , prueba y mantenimiento.

Herramientas y procesos

Las herramientas son un soporte automático o semiautomático para el
proceso y los métodos.

Microsoft Project ( Planificación).

UML ( Modelado).

RationalRose, visio (Modelado soportan UML).

Designer 2000.

Erwin (Bases de datos).

MAGERI (Seguridad).

Los procesos son los encargados de integrar los métodos y herramientas,

además de definir la secuencia en la que se aplican los métodos, las entregas
que requieren, los controles de calidad y las guías para el desarrollo.
Fases Genéricas de la ISW
 1. La totalidad de
características de un producto

de calidad
que surgen de su habilidad de
satisfacer necesidades dadas 
cumplir con las especificaciones.
Enfoque

2. Grado en que el software

posee una combinación deseada
de atributos.
3. Grado en que un cliente o
usuario percibe que el software
alcanza sus expectativas
compuestas.

4. Las características compuestas del

software que determinan el grado en
que el software en uso cumple con
las expectativas del cliente.

ANSI/IEEE Std 729-1983 “IEEE Standard Glossary of Software

Engineering Terminology
1.4 Modelos de Desarrollo de Software
El Proceso de Software
Conjunto estructurado de
actividades requeridas para
desarrollar un sistema de
software.
Especificación.
Diseño.
Validación.
Debe estar
Evolución.
explícitamente
modelado para
ser bien
administrado.
Modelo de Ingeniería del Proceso
Especificación: Establecer los
Especificación
requerimientos
y restricciones del sistema.
Diseño:
Diseño Producir un modelo en papel
del
sistema.
Manufactura:
Manufactura Construir el sistema.
Prueba:
Prueba Verificar que el sistema
cumpla con las especificaciones
requeridas.
Instalación:
Instalación Entregar el sistema al
usuario y asegurar su
operacionalidad.
Mantenimiento:
Mantenimiento Reparar fallos en el
sistema cuando sean descubiertos;
mejorar el sistema; adaptar el
sistema.
Proceso de Desarrollo

Definición

Desarrollo

Mantenimiento
Definición

Ingeniería del sistema

Definición de Objetivos

Análisis

Especificación de
Requerimientos
Desarrollo

Diseño:

Preliminar

Detallado

Externo

Interfaz

Interno

Codificación

Pruebas:

Modulares

Integración
Mantenimiento

Pruebas de
Validación

Manual de
Operación

Manual de Usuario

Código fuente,
objeto y
ejecutable
Documentación asociada a cada etapa del ciclo
de vida

Tipos de
Documentos

Previos al desarrollo

Enmarcando al
desarrollo

Para cada una de las
fases o etapas del
desarrollo.
Definición

Desarrollo

Mantenimiento
Documentos para la etapa de DEFINICIÓN

Definición de objetivos

Análisis del sistema:
Factibilidad

Especificación de
requerimientos
Definición

Desarrollo

Mantenimiento
Documentos fase de DESARROLLO

Diseño:

Preliminar

Detallado

Interfaz

Externo

Interno

Codificación

Pruebas:

Modulares

Integración
Definición

Desarrollo

Mantenimiento
Documentos para la etapa de MANTENIMIENTO

Pruebas de
Validación

Manual de
Operación

Manual de Usuario

Código fuente,
objeto y
ejecutable
Modelos de Desarrollo

Tipos de modelos

Lineal o secuencial

Construcción de
Prototipos

Desarrollo Rápido de
Aplicaciones (DRA ó
RAD)

Procesos Evolutivos

Métodos Formales

Técnicas de 4ª
Generación

Modelos que incluyen
a un 3ero
Modelo Lineal Secuencial o Cascada

Ingeniería de
Sistemas/Información

Análisis Diseño Código Prueba

Modelo lineal secuencial
(ciclo de vida básico, cascada)

Sugiere un enfoque
sistemático, secuencial
de desarrollo de
software que comienza
en un nivel de sistemas
y progresa con el
análisis, diseño,
codificación, pruebas y
mantenimiento
Etapa de análisis

Análisis de los requerimientos del software: es la fase
en la cual se reúnen todos los requisitos que debe
cumplir el software.
Etapa de diseño:

Es una etapa dirigida hacia la estructura de datos, la
arquitectura del software, las representaciones de la
interfaz y el detalle procedimental (algoritmo).
Etapa de código:

Es la etapa en la cual se traduce el diseño para que sea
comprensible por la máquina. Esta etapa va a depender
estrechamente de lo detallado del diseño.
Etapa de Prueba

El proceso de pruebas se centra en los procesos
lógicos internos del software, asegurando que
todas las sentencias se han comprobado, y en los
procesos externos funcionales; es decir realizar las
pruebas para la detección de errores y asegurar que
la entrada definida produce resultados requeridos.
Etapa de mantenimiento

Se producirán cambios porque se han encontrado
errores, porque el software debe adaptarse para
acoplarse a los cambios de su entorno externo (por
ejemplo se requiere un cambio debido a un sistema
operativo o dispositivo periférico nuevo), el cliente
requiere mejoras funcionales o de rendimiento.
Evolución 1
Ingeniería y Análisis del
Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento
Evolución 2
Los planes de prueba son el nexo entre OPERACION
el desarrollo y la verificación Y MANTENIMIENTO

ANALISIS DE Plan de Pruebas PRUEBA DE

REQUERIMIENTOS de Aceptación ACEPTACION

VALIDAD REQUERIMIENTOS

DISEÑO DEL Plan de Pruebas

del Sistema PRUEBA DEL
SISTEMA
SISTEMA

VERIFICAR DISEÑO

DISEÑO Plan de Pruebas PRUEBA DE

DETALLADO de Integración INTEGRACION

IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA UNITARIA
Documentación

Producto Producto
Proceso
Entrada Salida
Requerimientos Especificación de
Ingenieria de Requerimientos
Comunicados requerimientos (documentos)
Especificación de Especificación de Diseño (
Diseño
requerimientos (documentos) documento)
Especificación de Diseño ( Modulos ejecutables de
Programación
documento) Software
Modulos ejecutables de Producto de Software
Integración
Software Integrado
Producto de Software Producto de Software
Entrega
Integrado Entregado
Producto de Software
Mantenimiento Requerimientos para cambio
Entregado
¿POR QUÉ FALLA ALGUNAS VECES EL MODELO
LINEAL?

1.- Como resultado, los cambios pueden causar confusión cuando el

equipo del proyecto comienza.
2.-El modelo lineal secuencial requiere dificultades a la hora de afrontar la
incertidumbre natural al comienzo de muchos proyectos.
3.-Un grave error puede ser desastroso si no se detecta hasta que se revisa
el programa.

Cada uno de estos errores es real. Tiene un lugar definido e importante en

el trabajo de la ingeniería del software proporciona una plantilla en la
que se encuentran métodos para análisis, diseño, codificación, y
mantenimiento.
Modelo de construcción de prototipos

Escuchar Construir/
al cliente revisar
maqueta

El cliente
prueba
la maqueta
 Modelo de construcción de prototipos

Problemas de su
construcción:

El cliente ve lo que parece
ser una versión de trabajo
del software.

Con la prisa de hacer que
funcione no se ha tenido en
cuenta la calidad del
software global o la
factibilidad de mantenimiento
a largo plazo.

El desarrollador a menudo
hace compromisos de
implementación para hacer que
el prototipo funcione
rápidamente.
Modelo de construcción de prototipos
¿ Por qué se usar este modelo?

El cliente no puede especificar todos los
requerimientos al principio.

Existen dudas de alguna parte del sistema.

Facilita un modelo al programador
Tipos de prototipos

Totales

Parciales

Interfases

Modelos

Estructuras de datos
Problemas del modelo

El cliente lo quiere , aunque no es un producto de SW.

Módulos ineficientes se convierten en parte del
sistema.
Modelo RAD (Rapid Application
Development)
Development)

El modelo RAD es una
adaptación de “alta velocidad”
de modelo lineal secuencial en
el que se logra el desarrollo
rápido utilizando un enfoque de
construcción basado en
componentes.

Modelado de la aplicación

Modelado de datos

Modelado de proceso

Generación de aplicaciones

Pruebas y entrega
Equipo # 1 Equipo # 2 Equipo # 3
Modelado de Modelado de Modelado de
gestión
gestión gestión
Modelado de
Modelado de
Modelado de datos
datos
datos Modelado de
Modelado de procesos
Modelado de procesos
Generación de
procesos Generación de aplicaciones
aplicaciones
Generación de Modelado de
gestión
aplicaciones Pruebas y
volumen
Pruebas y
volumen
De 60 a 90 días
Modelado de gestión:

El flujo de información entre las funciones de gestión
se modela de forma que responda a las siguientes
preguntas:

¿Qué información conduce el proceso de gestión?
¿Qué información se genera? ¿Quién la genera? ¿A
dónde va la información? ¿Quién la proceso?
Modelado de datos:

El flujo de información definido como parte de la fase
de modelado de gestión se refina como un conjunto de
objetos de datos necesarios para apoyar la empresa.

Se definen las características (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos
objetos.
Modelado de proceso:

Los objetos de datos definidos en la fase de
modelado de datos quedan transformados para
lograr el flujo de información necesario para
implementar una función de gestión.

Las descripciones del proceso se crean para añadir,
modificar, suprimir, o recuperar un objeto de
datos. Es la comunicación entre los objetos.
Generación de Aplicaciones

El DRA asume la utilización de técnicas de cuarta
generación. En lugar de crear software con lenguajes de
programación de tercera generación, el proceso DRA
trabaja para volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear componentes
reutilizables (cuando sea necesario). En todos los casos se
utilizan herramientas automáticas para facilitar la
construcción del software.
Pruebas de entrega

Como el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas.
Esto reduce tiempo de pruebas. Sin embargo, se deben
probar todos los componentes nuevos y se deben ejercitar
todas las interfases a fondo. Obviamente la limitación de
tiempo impuestas en un proyecto DRA demanda "ámbito en
escalas". Si una aplicación de gestión puede modularse se
forma que permita completarse cada una de las funciones
principales en menos de tres meses (utilizando el enfoque
descrito anteriormente), es un candidato del DRA. Cada una
de las funciones pueden ser afrontadas por un equipo DRA
diferente y ser integradas en un solo conjunto.
Desventajas

Al igual que todos los modelos de proceso, el enfoque DRA
tiene inconvenientes:

Para proyectos grandes aunque por escalas, el DRA requiere
recursos humanos suficientes como para crear el numero
correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en
las rápidas actividades necesarias para completar un
sistema en un marco de tiempo abreviado.

Si no hay compromiso, por ninguna de las partes
constituyentes, los proyectos DRA fracasarán.
Desventajas

No todos los tipos de aplicaciones son apropiados para
DRA. Si un sistema no se puede modularizar
adecuadamente , la construcción de los riesgos técnicos
son altos.

DRA no es adecuado cuando los riesgos técnicos son altos.

Esto ocurre cuando una nueva aplicación hace uso de
tecnologías, nuevas ,o cuando el software nuevo requiere
un alto de interoperatividad con un programa de
computadora ya existente.
 Modelos de procesos
evolutivos de software

Se reconoce que el software al igual
que todos los sistemas complejos,
evoluciona con el tiempo.

Los requisitos del sistema a menudo
cambian conforme a que el desarrollo
proceda haciendo que el camino que
lleva al producto final no sea real.

Las estrictas fechas tope del
mercado hacen que sea imposible
finalizar un sistema completo, por lo
que se debe introducir una versión
limitada para cumplir la presión
competitiva.

Se comprende perfectamente el
conjunto de requisitos de productos
centrales o del sistema, pero todavía
se tienen que definir los detalles de
extensiones del sistema.
Modelo Incremental

Combina elementos del modelo
lineal con la filosofía de
creación de prototipos

El primer incremento a menudo
es un producto esencial que
el cliente utiliza o evalúa

A partir de la evaluación se
planea el siguiente incremento
y así sucesivamente

Es interactivo por naturaleza

Es útil cuando el personal no
es suficiente para la
implementación completa.
Modelo Incremental
Incremento 1
Entrega de
Análisis Diseño Código Pruebas
1.er incremento

Incremento 2
Entrega de
Análisis Diseño Código Pruebas
2.o incremento

Incremento 3
Entrega de
Análisis Diseño Código Pruebas
3.er incremento

Incremento 4
Entrega de
Análisis Diseño Código Pruebas
4.o incremento

Tiempo de calendario
Modelo Incremental
Modelo en Espiral

Es un modelo de proceso de
software evolutivo que acompaña
la naturaleza interactiva de
construcción de prototipos con
los aspectos controlados y
sistemáticos del modelo lineal
secuencial.

Durante las primeras iteraciones,
la versión incremental podría ser
un modelo en papel o un
prototipo.

Durante las últimas iteraciones,
se producen versiones cada vez
más completas de ingeniería de
sistemas.
 Evalúe alternativas,
Determine objetivos identifique y resuelva
alternativas y riesgos
restricciones Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos Prototipo
Prototipo Operacional
Análisis Prototipo 3
de Proto 2
REVISIÓN Riesgos tipo 1
Simulaciones, modelos y benchmarks
Plan de requerimientosConcepto de
Plan del ciclo de vida Operación
Requeri-
mientos de Diseño Diseño
SW del Detallado
Plan de Validación de Producto Codificación
Desarrollo Requerimientos
Prueba de
Plan de Integración Diseño Unidades
Prueba de
y Prueba V &V
Prueba de Integración
Planea la Desarrolla y verifica
Aceptación
siguiente fase el siguiente nivel
Servicio
del producto
Las tareas requeridas

Comunicación con el cliente:
cliente: Para
establecer comunicación entre el
desarrollador y el cliente.

Planificación:
Planificación: Para definir los recursos, el
tiempo y otras informaciones relacionadas
con el proyecto.

Análisis de riesgos:
riesgos: Para evaluar riegos
técnicos y operativos.

Ingeniería:
Ingeniería: Para construir una o más
representaciones de la aplicación.

Construcción y adaptación:
adaptación: Para construir,
probar, instalar y proporcionar soporte al
usuario (documentación y práctica).

Evaluación del cliente:
cliente: Para obtener la
reacción del cliente según la evaluación de
las representaciones del software creadas
durante la etapa de ingeniería e
implementada durante la etapa de
instalación.
Espiral avanzado
Etapas
PLANIFICACIÓN
ANÁLISIS DE RIESGO
INGENIERÍA
EVALUACIÓN DEL CLIENTE
 Planificación

Recolección de requisitos y planificación del proyecto

inicial

Planificación basada en los comentarios del cliente

Evaluación del cliente

EVALUACION DEL CLIENTE

Análisis de Riesgo

Análisis de riesgo basado en los requisitos iniciales

Análisis de riesgo basado en la reacción del cliente

Decisión de seguir o no

Hacia el sistema final

Prototipo inicial del software

Prototipo del siguiente nivel

Sistema de ingeniería

INGENIERIA
Ventajas

Si es necesario repetir algún proceso, sólo se pierde el esfuerzo de una
iteración y no el valor del producto completo.

Reduce el riesgo de no tener el producto en el mercado en la fecha de

entrega pactada al comienzo del proyecto. Mediante la planificación de
los riesgos más altos en las primeras fases del desarrollo, el tiempo
consumido en resolverlos se invierte al principio del proceso cuando el
equipo está menos apresurado.

Acelera el ritmo del desarrollo global ya que los desarrolladores

trabajan de forma más eficiente cuando ven objetivos a corto plazo.

Acepta el hecho de que las necesidades de los usuarios y por tanto los
requisitos, no se pueden definir completamente desde el principio, sino
que son refinados en iteraciones sucesivas.
Modelo de ensamble de componentes

El modelo utiliza el marco de

trabajo técnico del paradigma
orientado a objetos

Incorpora muchas
características del modelo en
espiral

La actividad de ingeniería
comienza con la identificación
de clases candidatas

Según estudios realizados
este modelo:
✔ reduce el tiempo de
desarrollo en un 70%
✔ reduce el costo del
proyecto en un 84%
Modelo de ensamble de componentes

Identificar
componentes
candidatos
Construir n Buscar
interacciones componentes
del sistema en biblioteca

Poner Extraer
componentes componentes
nuevos en la si están
biblioteca disponibles
Construir
componentes
si no están
disponibles
Modelo de desarrollo concurrente

Bajo
desarrollo

Cambios
en espera Actividades
Cambios
en espera de análisis
Bajo
revisión
En línea
base

Hecho

Representa un estado de una

actividad en ingeniería del software
Modelo del proceso orientado a objetos

Identificando
clases candidatas
Planeaciónn Análisis
i de riesgo Construyendo n-
esima versión Buscando
del sistema clases en
Customer
Comunicación librerías
Communication
con el cliente

Agregar Extrayendo clases

clase a las si están
librerías disponibles

Ingeniería si
las clases no
Customer
Evaluación Ingeniería disponibles
Evaluation
del cliente Construcción Análisis OO
y rediseño Diseño OO
CodificaciónOO
Pruebas OO
1.5 Importancia de las diferentes etapas del SW.
Ingeniería de SW VS Programación

La ingeniería de software es el proceso de construir
aplicaciones de tamaño o alcance prácticos, en las que
predomina el esfuerzo del software y que satisfacen los
requerimientos de funcionalidad y desempeño. La
programación es una de las actividades de la ingeniería de
software. La diferencia entre la programación y la
ingeniería de software se parece a la diferencia entre crear
una mesa de jardín y crear un puente. Estos difieren mucho
en el orden de magnitud y el conocimiento profesional
requerido.
Actividades comunes para un proyecto de
Ingeniería de SW
1.- Primero, es necesario entender la naturaleza del
proyecto. Esto parece obvio, pero casi siempre lleva
tiempo entender que desean los clientes, en
especial cuando ellos mismo no saben por
completo que quieren. Debe entenderse la
magnitud general del tiempo, los fondos y el
personal disponible. Esto ayuda a aclarar el alcance
del proyecto.
Actividades comunes para un proyecto de
Ingeniería de SW
2.- Los proyectos requieren documentación desde el
principio; es muy probable que esta documentación sufra
muchos cambios. Por esta razón, desde el principio debe
identificarse en un medio para mantener el control de los
cambios tanto en los documentos como en el código. Este
proceso, es conocido como administración de la
configuración. En seguida hay que desarrollar el plan global
para el proyecto incluyendo la programación del
calendario, este plan se va refinando durante la vida del
proyecto conforme se conoce más de los requerimientos y
el diseño.
Actividades comunes para un proyecto de
Ingeniería de SW
3.- El siguiente paso es reunir los requerimientos para la
aplicación. Gran parte de esta actividad consiste en
conversar con los interesados, quienes tienen un
interés en su resultado.
Actividades comunes para un proyecto de
Ingeniería de SW
4.- El paso que sigue es el diseño e implementación del
producto. Dependiendo del proceso de desarrollo que
se use, es posible que los pasos 3 y 4 se repitan varias
veces.
Actividades comunes para un proyecto de
Ingeniería de SW
5.- El producto inicial y el producto final deben
probarse en forma exhaustiva de varias maneras.
Actividades comunes para un proyecto de
Ingeniería de SW
6.- Una vez entregado el producto, entra el modo de
mantenimiento, que incluye reparaciones y mejoras. El
mantenimiento llega a consumir hasta el 80% de los
recursos de ingeniería de software.
1.5.1. Análisis de Sistemas
El análisis de sistemas implica determinar las necesidades del
cliente y /o usuario para poder especificar los requerimientos que
sirvan como base para el desarrollo de un sistema o software
siendo el "que" de un sistema informático. Esto se lleva a cabo
teniendo en cuenta ciertos principios:
a) Debe presentarse y entenderse el dominio de la información de
un problema.
b) Definir las funciones que debe realizar el Software.
c) Representar el comportamiento del software a consecuencias de
acontecimientos externos.
d) Divida en forma jerárquica los modelos que representan la
información, funciones y comportamiento.
1.5.1. Análisis de Sistemas
Un análisis de sistemas se lleva a cabo teniendo en cuenta los
siguientes objetivos en mente: Identificar las necesidades
del cliente, evaluar los conceptos que tiene el cliente del
sistema para establecer su viabilidad, realice un análisis
técnico y económico, asignar funciones al hardware,
software, personal, base de datos, y otros elementos del
sistema, establezca las restricciones de presupuestos y
planificación temporal y crear una definición del sistema
que forme el fundamento de todo el trabajo de ingeniería.
1.5.2 Diseño de Sistemas

El Diseño del Software es un proceso y un
modelado a la vez. El proceso de Diseño es un
conjunto de pasos repetitivos que permiten al
diseñador describir todos los aspectos del Sistema
a construir. A lo largo del diseño se evalúa la
calidad del desarrollo del proyecto con un
conjunto de revisiones técnicas.
Etapas del diseño de sistemas

La etapa del Diseño del Sistema consta de cuatro
etapas:

El diseño de los datos. Trasforma el modelo de dominio de la
información, creado durante el análisis, en las estructuras de
datos necesarios para implementar el Software.
Etapas del diseño de sistemas

El Diseño Arquitectónico. Define la relación entre
cada uno de los elementos estructurales del
programa.

El Diseño de la Interfaz. Describe como se comunica
el Software consigo mismo, con los sistemas que
operan junto con el y con los operadores y usuarios
que lo emplean.
Etapas del diseño de sistemas

El Diseño de procedimientos. Transforma
elementos estructurales de la arquitectura del
programa. La importancia del Diseño del
Software se puede definir en una sola palabra
Calidad, dentro del diseño es donde se fomenta
la calidad del Proyecto. El Diseño es la única
manera de materializar con precisión los
requerimientos del cliente.
1.5.2 Diseño de Sistemas

El diseño debe implementar todos los requisitos explícitos
contenidos en el modelo de análisis y debe acumular todos
los requisitos implícitos que desea el cliente.

Debe ser una guía que puedan leer y entender los que
construyan el código y los que prueban y mantienen el
Software y debe proporcionar una completa idea de lo que
es el software, enfocando los dominios de datos, funcional
y comportamiento desde el punto de vista de la
implementación.
1.5.3 Prueba de sistemas

La prueba es un conjunto de actividades que se puede planificar
por adelantado y llevar acabo sistemáticamente. Por esta razón se
debe definir en el proceso de la ingeniería de software una
plantilla para la prueba de software: un conjunto de pasos en los
que podamos situar los métodos de diseño de caso de prueba.

La prueba es un proceso de ejecución de un programa con la
intención de descubrir un error. Un buen caso de prueba es aquel
que tiene una falta de probabilidad de mostrar un error no
descubierto hasta entonces. Una prueba tiene éxito si descubre
un error no detectado hasta entonces.
1.5.3 Prueba de sistemas
En el proceso de prueba existen dos conceptos que hay que
diferenciar: verificación y validación:

VERIFICACIÓN: Se refiere al conjunto de actividades que
asegure que el software se implementa correcta mente una
función específica. ¿Estamos construyendo el producto
correctamente?

VALIDACIÓN: Se refiere a un conjunto diferente de
actividades que aseguran que el software construido se
ajusta a los requisitos del cliente. ¿Estamos construyendo el
producto correcto?
1.5.4 Mantenimiento de Sistemas

Cuando un sistema es instalado en un ambiente que cambia, el ambiente
produce cambios en los requerimientos. Los sistemas deben tener
mantenimiento si se quiere que sean útiles en el ambiente.

El mantenimiento se puede dar a lo largo de todo el ciclo de vida utilizando
una metodología de desarrollo para sistemas evolutivos, esto es debido a
que usualmente es mas caro añadir funcionalidad después de que el
sistema ha sido desarrollado, en vez de hacerlo cuando el sistema se esta
diseñando; el personal de mantenimiento a menudo no tiene experiencia o
no esta familiarizado con el dominio de la aplicación; los programas
pueden estar pobremente estructurados y difíciles de entender y porque
además los cambios pueden introducir nuevas fallas si el sistema se hace
más complejo. También es importante mencionar que el mantenimiento
debe darse a lo largo de todo el proceso de desarrollo porque la estructura
del software puede degradarse debido a cambios continuos y puede no
haber documentación disponible que describa el software.
1.5.4 Mantenimiento de Sistemas

El mantenimiento se debe o se invoca debido a cambios
pedidos por los clientes o por los requerimientos del
mercado. Los cambios normalmente se atienden en orden
de pedido y se implementan en una nueva versión del
sistema. Los programas algunas veces necesitan ser
reparados sin que se realice una iteración completa del
proceso, lo cual provoca problemas ya que la
documentación y los programas se desactualizan.
Fin de la Unidad !!!
Evaluación

25 puntos por fin de semana

exposición (15 exponer + 10 presentación digital)

Firmas por actividad