Martes, 03 de Septiembre de 2002

LABORATORIO NACIONAL DE INFORMÁTICA AVANZADA A. C.

MAESTRÍA EN CIENCIAS DE LA COMPUTACIÓN
INGENIERÍA DE SOFTWARE
(CEL-MCC-OO2)

1. Información del curso

Inicio: 3 de septiembre del 2002.
Fin: 10 de diciembre del 2002.
Días de clase: Martes y Jueves Horario: 10:30 a 12:00
Salón: Salón Grande (Casa Rébsamen)
Profesor: Norma A. Bello Conde
Cubículo: Edificio Principal. Planta Baja
Teléfono: 8-41-61-00 Ext. 1010
Email : nbello@lania.mx; norma@rtv.ora.mx
Asesorías: martes y jueves de 12:00 a 14:00

2. Objetivo General
Al finalizar el curso el alumno tendrá conocimiento del conjunto de técnicas de
Ingeniería de Software que pueden ser aplicadas en proyectos de software para la creación
de sistemas eficientes y de mejor calidad

3. Objetivos Específicos
 Definir la Ingeniería de Software y explicar su importancia.
 Conocer cuales son las principales aplicaciones del software.
 Analizar todas las etapas del proceso de ingeniería de software.
 Discutir la planeación de proyectos y el proceso de planeación.
 Aplicar las diferentes métricas para la productividad y la calidad del
software.
 Aplicar las diferentes metodologías de análisis de requisitos del sistema
y del software.
 Aplicar las diferentes metodologías diseño e implementación del
software.
 Conocer y aplicar las diferentes estrategias para realizar las pruebas del
software.
 Investigar y desarrollar temas avanzados de la Ingeniería de Software.

4. Método de Enseñanza
 Exposición ante el grupo utilizando diversos métodos de presentación:
pizarrón, proyecciones con computadoras, etc.
  Exposición por parte de los alumnos de artículos de investigación y
materiales publicados en revistas o en sitios web.
 Exposición de algún profesor invitado.
 Presentación por parte de los alumnos de sus tareas y proyectos
realizados.

5. Evaluación
2 exámenes parciales 30% (15% c/u) (3 oct y 7 nov)
1 examen final 20% (10 diciembre)
Proyecto Final 25% ( 5 diciembre )
Participaciones en clase 10%
Tareas e investigaciones 15%
100%

6. Reglas Generales
 El estudiante con mas de tres faltas pierde el derecho a presentar el
examen.
 Las tareas se entregarán en clase o se enviarán por correo electrónico en
la fecha señalada. No se recibirán tareas después de la fecha determinada
para ello.
 Tareas / proyectos iguales o copiados se reparte la calificación.
 No se realizarán exámenes fuera de la fecha señalada para ello.

7. Bibliografía

Booch, G., Jacobson, I. and Rumbaugh, J. El lenguaje unificado de Modelado.

Addison Wesley
Pressman, Roger. Ingeniería de Software: Un enfoque práctico. Madrid.
McGraw-Hill.

Somerville, tan. Software Engineering. Fourth Edition. Addison-Wesley Standish,

Thomas. Data Structures, Algorithms & Software Principies in C.
Addison Wesley.

Yourdon E. Modern Structured Análisis. Englewood Cliffs, N. Prentice-Hall

Kobryn, C. UML:2001 : A Standardization Odyssey, Communications of ACM,
Volume 42, No.10 pp. 29-37
Software Engineering Resources by Roger S. Pressman & Associates

http://www.rspa.com/

Artículos en revistas especializadas y en internet

 Laboratorio Nacional de Informática Avanzada
A. C.

Maestría en Ciencias de la Computación

Ingeniería de Software

Objetivos
 Discutir la importancia del software y conocer su evolución.
 Conocer los conceptos de producto de software y proceso de software.
 Analizar la importancia de la ingeniería de software, su evolución y su relación
con otras áreas de la ciencia de la computación y disciplinas.

Software
 Actualmente, el software ha superado al hardware como la clave del éxito de
muchos sistemas basados en computadoras.
 Cada día mas sistemas son controlados por software.
 El software es el factor que marca la diferencia.
 Las economías de los países desarrollados dependen en gran parte del
software.

Costos del software

 Los costos del software a menudo dominan al costo del sistema.
 Cuesta mas mantener el software que desarrollarlo. Para sistemas con una larga
vida, este costo se multiplica.
 La Ingeniería de Software concierne a un desarrollo efectivo en cuanto a costos
del software.
Costos de Eficiencia

Costos

Eficiencia
 Evolución

Multiusuario Tecnologías
Sistemas orientadas a
Sw a la medida Sist. de objetos
tiempo real distribuidos
Distribución limitada Incorporación Computación
Distribución paralela
amplia de “inteligencia”
Ejecución de
programas únicos Hardware de
bajo costo

1950 1960 1970 1980 1990 2000

Productos y Aplicaciones del software
 Genéricos o hechos a la medida
 Productos que son producidos por una organización para ser vendidos al
mercado.
 Sistemas que son desarrollados bajo pedido a un desarrollador específico.
 Clasificación
 Sistemas
 tiempo real
 gestión
 Ingeniería y científicos
 Empotrado
 Computadoras personales

Características de los productos de software

 Mantenibles.
 Debe ser posible que el software evolucione y que siga cumpliendo con sus
especificaciones.
 Confiabilidad.
 El software no debe causar danos físicos o económicos en el caso de fallos.
 Eficiencia.
 El software no debe desperdiciar los recursos del sistema.
 Utilización adecuada.
 El software debe contar con una interfaz de usuario adecuada y su
documentación.

Importancia de las características de producto

 La importancia relativa de las características depende en el 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 son requeridos altos niveles

de alguna característica.
 Ingeniería de Software
 Fue hasta el año 1968 en Garmisch, Alemania donde se muestra el interés
hacia los aspectos administrativos y técnicos del desarrollo.

 Los desarrollos de la IS comenzaron con la técnica de la programación y

después en otras etapas del ciclo de vida.

 Es un enfoque sistémico para desarrollo

 Abarca tres elementos clave : métodos, herramientas y procedimientos.

Evolución de la ingeniería de Software
69-71 Buenas prácticas de programación
Diseño descendente, refinamiento sucesivo, modularidad
72-73 Prog. Estructurada, concepto de ciclo de vida en el desarrollo de sw
Se proponen ayudas para la administración

Se inicia la noción de confiabilidad y calidad de sw

74-75
Pruebas sistemicas, noción de corrección formal, modelos de tolernacia a fallas

76-77
Se pone atención a las fases anteriores a la codificación
Surge la abstracción y se integran fases sucesivas en el desarrollo

86-95 Incremento en herramientas automatizadas

Cursos de ingeniería de SW
78-80 Inician herramientas para cada fase del ciclo de vida
Aparece el paradigma OO para desarrollos grandes.
80-85 Promueve abstracción, herencia, reus. Uso masivo de
herramientas

jueves, 05 de septiembre de 2002

 Ingeniería de Software
 El establecimiento y uso de principios de ingenieria robustos, orientados a
obtener software económico que sea fiable y funcione de manera eficiente sobre
máquinas reales.
 Fritz Bauer

 Conjunto de etapas parcialmente ordenadas con la intención de lograr un

objetivo, que es la obtención de un producto de software de calidad
 Jacobson

Ingeniería de Software
Tiene tres elementos clave :
 Métodos
 Tareas de planificación y estimación de proyectos, análisis, diseño de
estructuras de datos, procedimientos algorítmicos, codificación y pruebas
 Herramientas
 Soporte automático o semiautomático para los métodos
 Procedimientos
 Definen la secuencia en la que se aplican los métodos, los controles que
ayudan a asegurar la calidad y las directrices de evaluación.

Ciclo de vida del software

“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”
IEEE 1074

“Un marco de referencia que contiene los procesos, las actividades

y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización
de su uso”
ISO 12207-1
 Procesos del ciclo de vida del software

PROCESOS PRINCIPALES PROCESOS DE SOPORTE

DOCUMENTACIÓN

ADQUISICIÓN GESTIÓN DE CONFIGURACIÓN

ASEGURAMIENTO DE CALIDAD
SUMINISTRO
VERIFICACIÓN

VALIDACIÓN

OPERACIÓN REVISIÓN CONJUNTA

DESARROLLO
AUDITORÍA
MANTENIMIENTO
RESOLUCIÓN DE PROBLEMAS

PROCESOS DE LA ORGANIZACIÓN
GESTIÓN INFRAESTRUCTURA

MEJORA FORMACIÓN

Documentación: documentar desde la parte administrativa del proyecto, así como su

desarrollo
Procesos del ciclo de vida del software

 Procesos Principales
 Son aquellos que resultan útiles a las personas que inician y realizan el
desarrollo, la operación o el mantenimiento del software durante sus ciclo de
 vida. Estas personas son los compradores, los suministradores, el personal
de desarrollo, los operadores y el personal de mantenimiento del software.

 Procesos de Soporte
 Estos procesos sirven como apoyo al resto y se aplican en cualquier punto
del ciclo de vida

 Procesos de la organización
 Estos procesos los emplea una organización para llevar a cabo funciones
tales como la gestión, la capacitación del personal o la mejora del proceso.
Ayudan a establecer, implementar y mejorar la organización consiguiendo
una organización más efectiva.

Proceso de desarrollo de software

 Análisis de Requisitos del Sistema
 Diseño de la Arquitectura del Sistema
 Análisis de los Requisitos del Software
 Diseño de la Arquitectura del Software
 Diseño Detallado del Software
 Codificación y Prueba del Software
 Integración del Software
 Prueba del Software
 Integración del Sistema
 Prueba del Sistema
 Instalación del Software
 Soporte del proceso de Aceptación del Software

Modelos Genéricos de Desarrollo de Software

 Modelo de Cascada
 Separar en distintas fases de especificación y desarrollo.
 Desarrollo Evolutivo
 La especificación y el desarrollo están intercalados.
 Prototipado
 Un modelo sirve de prototipo para la construcción del sistema final.
 Desarrollo basado en Reutilización
 El sistema es ensamblado a partir de componentes existentes.
 Transformación Formal
  Un modelo matemático del sistema se transforma formalmente en la
implementación.

Modelo de cascada

Definición de
Requerimientos

Diseño del Software

y del Sistema

Implementación y
Prueba de unidades

Integración y Prueba
del Sistema

Operación y
Mantenimiento

Modelo de cascada

 No refleja realmente el proceso de desarrollo del software

 Se tarda mucho tiempo en pasar por todo el ciclo
 Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
 El mantenimiento se realiza en el código fuente
 Las revisiones de proyectos de gran complejidad son muy
difíciles.
 Impone una estructura de gestión de proyectos
 Modelo en cascada
Actividad
Análisis de Requerimientos
Definición de Requerimientos
Especificación del Sistema.
Diseño Arquitectural
Diseño de Interfaces
Diseño Detallado
Codificación
Prueba de Unidades
Prueba de Módulos
Prueba de Integración
Prueba del Sistema
Prueba de Aceptación
Documentos Producidos
Documento de Requerimientos
Documento de Requerimientos.
Especificación Funcional, Plan de Pruebas
de Aceptación.
Especificación de la Arquitectura, y Plan de
Pruebas del Sistema
Especificación de la Interfaces y Plan de
pruebas de Integración.
Especificación del diseño y Plan de prueba
de Unidades.
Código de Programa
Reporte de prueba de unidades
Reporte de prueba de módulos
Reporte de prueba de integración y Manual
de usuario final
Reporte de prueba del sistema
Sistema final mas la documentación.
 Desarrollo Evolutivo
Actividades
Concurrentes

Versión
Especificación Inicial

Descripción Desarrollo Versiones

del sistema Intermedias

Versión
Validación
Final

Desarrollo Evolutivo

 Poca visibilidad en el proceso

 Los sistemas están pobremente especificados
 Se requieren habilidades especiales.
 Aplicabilidad para sistemas interactivos pequeños o
medianos.

Prototipado
Prototipado
  No modifica el flujo del ciclo de vida
 Reduce el riesgo de construir productos que no satisfagan las
necesidades de los usuarios
 Reduce costos y aumenta la probabilidad de éxito
 Exige disponer de las herramientas adecuadas
 No presenta calidad ni robustez
 Suele utilizarse principalmente en dos áreas

Prototipado
 Debe ser un sistema con el que se pueda experimentar
 Debe ser comparativamente barato (< 10%)
 Debe desarrollarse rápidamente
 Énfasis en la interfaz de usuario
 Equipo de desarrollo reducido
 Herramientas y lenguajes adecuados

Los modelos genéricos son guías para el desarrollo del software.

Cascada
Diseño.- analizar el tipo de estructura de datos que es mejor para evitar
“redundancia”.
Implementación.- pseudocódigo  código
Integración.- unión de software probándolo para ver algún origen de problemas
Operación.- aquí, permite regresar a algunas de las etapas pasadas.

Evolutivo
Los sistemas pobremente especificados, decido a que los requerimientos fueron
especificados por personas que no va a usar el software
Habilidades especiales.- poder obtener la información que es requerida.

Prototipado
El cliente ve resultados de manera rápida
 jueves, 12 de septiembre de 2002
Modelo Espiral
Evalúe alternativas,
Determine objetivos identifique y resuelva
alternativas y riesgos
restricciones
Análisis de
Riesgos
Planificación Análisis de Análisis de
Riesgos riesgo
Análisis de
Riesgos
Prototipo
Prototipo Operacional
Análisis Prototipo
de Proto 2
Riesgos tipo 3
Plan de
Desarrollo Simulaciones, modelos y benchmarks
Plan de requerimientos
Concepto de
Plan del ciclo de vida
Operación
Requeri
Planea la mientos de Diseño Diseño
siguiente fase SW del Detallado
Validación de
Plan de Integración Requerimientos
Producto Codificación
y Prueba Prueba de
Diseño
Unidades Ingeniería
Prueba de
V &V
Integración
Prueba de
Aceptación Desarrolla y verifica
Evaluación del
Servicio el siguiente nivel
cliente del producto
 Modelo Espiral
 Definido por BOEHM en 1986
 Permite acomodar otros modelos
 Incorpora objetivos de calidad y gestión de riesgos
 Elimina errores y alternativas no atractivas al comienzo
 Permite iteraciones, vuelta atrás y finalizaciones rápidas
 Es difícil de adaptar a los contratos
 Depende de las personas
 Difícil de asegurar que las personas involucradas operan en
un contexto consistente

Fases del Modelo Espiral

 Planteamiento de Objetivos
 Se identifican los objetivos específicos para cada fase del proyecto.
 Identificación y reducción de riesgos.
 Los riesgos clave se identifican y analizan, y la información sirve para
minimizar los riesgos.
 Desarrollo y Validación.
 Se elige un modelo apropiado para la siguiente fase del desarrollo.
 Planeación.
 Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.

Modelo de Espiral
 Ventajas
 Centra su atención en la reutilización de componentes y eliminación de
errores en información descubierta en fases iniciales.
 Los objetivos de calidad son el primer objetivo.
 Integra desarrollo con mantenimiento.
 Provee un marco de desarrollo de hardware/software.

 Problemas
 El desarrollo contractual especifica el modelo del proceso y los resultados a
entregar por adelantado.
 Requiere de experiencia en la identificación de riesgos.
 Requiere refinamiento para uso generalizado.
Plantilla para una ronda del espiral
 Objetivos.
 Restricciones.
 Alternativas.
 Riesgos.
 Resolución de riesgos.
 Resultados.
 Planes.
 Garantías (commitments).

Reutilización

BIBLIOTECA
 Reutilización

Principios de la reutilización:
 Existen similitudes entre distintos sistemas de un mismo dominio de
aplicación
 El software puede representarse como una combinación de módulos
 Diseñar aplicaciones = especificar módulos + interrelaciones
 Los sistemas nuevos se pueden caracterizar por diferencias respecto a los
antiguos
Reduce tiempos y costos de desarrollo
Aumenta la fiabilidad
Dificultad para reconocer los componentes
potencialmente reutilizables
Dificultad de catalogación y recuperación
Problemas de motivación
Problemas de gestión de configuración

Planificar (ver cuanto va a costar, el personal con que se cuenta, herramientas que haría
falta)

Administración (4 p’s)
1. Producto
2. Precio
3. Plaza (donde se va a ubicar)
4. Promoción (cómo se va a vender).

martes, 17 de septiembre de 2002

Exposiciones de herramientas CASE

jueves, 19 de septiembre de 2002

Visión genérica de la Ingeniería del Software.
 Definición. ¿Qué?
 Análisis del sistema.
Establecer el ámbito del software.
 Análisis de requisitos del sistema software.
Definición detallada de la función del software.
 Planificación.
Análisis de riesgos.
Asignación de recursos.
Definición de tareas.
Estimación de costos.

Visión genérica de la Ingeniería del Software.

 Desarrollo. ¿Cómo?
 Diseño.
Arquitectura de la aplicación.
Estructura de los datos.
Estructura interna de los programas.
Diseño de las interfaces.
 Codificación.
 Pruebas.

Mantenimiento.El cambio.
Corrección de errores.
Cambios en el entorno.
Cambios en los requisitos.
 Gestión de proyectos de Software
 Conceptos básicos sobre gestión
 Procesos de software y métricas

 Planificación de proyectos de software

 Análisis y la gestión del riesgo

 Seguimiento

 Gestión de la configuración del software

Gestión de proyectos de Software

 La gestión eficaz de un proyecto de software se basa en :
 Personal
 Producto
 Proceso
 Proyecto
 La gestión de proyectos, implica planificación, supervisión y
control del personal, del proceso y de los eventos que ocurren
mientras evoluciona

Personal
 Las personas son lo más importante en la organización

 Las tareas de un administrador son esencialmente orientar a

las personas. Debe comprenderse al personal, para poder
administrarlo exitosamente

 La Ingeniería de Software es una actividad primariamente de

percepción. Las limitaciones de conocimiento efectivo limitan
el proceso de software.

Producto
 El término producto es usado para abarcar cualquier software
que será construido a petición de otros.
 Para planificar un proyecto, se deben establecer los objetivos
y el ámbito del producto.

 Los objetivos indican las metas generales del proyecto

 El ámbito identifica los datos primarios, funciones y

comportamientos, que caracterizan al producto.

Proceso
 Proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software.

 Incluye actividades estructurales

 Tareas
 Productos del trabajo

 Incluye actividades protectoras (de soporte)

 Gestión de la configuración del software

Proyecto
 Para gestionar un proyecto de software con éxito, debemos
comprender que puede ir mal y como hacerlo bien.

 Los proyectos deben tener éxito :

 Empezar con el pie derecho
 Mantenerse
 Seguir el progreso
 Tomar decisiones inteligentes
 Realizar un análisis postmortem
 Gestión de proyectos de Software
 Conceptos básicos sobre gestión
 Procesos de software y métricas

 Planificación de proyectos de software

 Análisis y la gestión del riesgo

 Seguimiento

 Gestión de la configuración del software

Gestión de proyectos de Software

 La gestión eficaz de un proyecto de software se basa en :
 Personal
 Producto
 Proceso
 Proyecto
 La gestión de proyectos, implica planificación, supervisión y
control del personal, del proceso y de los eventos que ocurren
mientras evoluciona

Personal
 Las personas son lo más importante en la organización

 Las tareas de un administrador son esencialmente orientar a

las personas. Debe comprenderse al personal, para poder
administrarlo exitosamente

 La Ingeniería de Software es una actividad primariamente de

percepción. Las limitaciones de conocimiento efectivo limitan
el proceso de software.

Producto
 El término producto es usado para abarcar cualquier software
que será construido a petición de otros.
 Para planificar un proyecto, se deben establecer los objetivos
y el ámbito del producto.

 Los objetivos indican las metas generales del proyecto

 El ámbito identifica los datos primarios, funciones y

comportamientos, que caracterizan al producto.

Proceso
 Proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software.

 Incluye actividades estructurales

 Tareas
 Productos del trabajo

 Incluye actividades protectoras (de soporte)

 Gestión de la configuración del software

Proyecto
 Para gestionar un proyecto de software con éxito, debemos
comprender que puede ir mal y como hacerlo bien.

 Los proyectos deben tener éxito :

 Empezar con el pie derecho
 Mantenerse
 Seguir el progreso
 Tomar decisiones inteligentes
 Realizar un análisis postmortem

Administración del Proyecto de Software

 Son las actividades que permiten asegurar que el software se
lleva a cabo a tiempo y de acuerdo a la planificación. Así
como de acuerdo a los requerimientos del software.
 Actividades de la Administración
 Escritura de la propuesta.
 Estimación del costo del proyecto.

 Planeación del proyecto y planificación de tiempos.

 Monitorización del proyecto y revisiones.

 Selección del personal y evaluación.

 Escritura de reportes y presentaciones.

Jueves, 26 de septiembre de 2002

Producto
 Para planificar un proyecto, se deben establecer los objetivos
y el ámbito del producto. Que va a hacer? Hasta donde va a
llegar? Quien lo va a operar?

 Los objetivos indican las metas generales del proyecto Hasta

donde?

 El ámbito identifica los datos primarios, funciones y

comportamientos, que caracterizan al producto. Que va a
hacer? Que tiempo? Usuarios secundarios?

Ámbito
Es la descripción del control y los datos a procesar, la función, el
rendimiento, las restricciones, las interfaces y la viabilidad.
 Rendimiento

 Requisitos de tiempo de respuesta y de procesamiento que tiene que hacer?

Entradas y salidas?
 Restricciones
 Límites originados por el hardware externo, por la memoria disponible y por
otros sistemas existentes. no hay hardware adecuado; forma parte de otro
sistema
 Ámbito
 Debe ser unívoco y entendible a niveles de gestión y técnico.
No lo va a establecer la persona que lleva el producto, sino
todos los niveles.

 Los datos cuantitativos se deben establecer explícitamente.

Numero de reportes, número de interfaces.

Viabilidad
 Una vez identificado el ámbito es razonable preguntarse
 ¿Podemos construir el software de acuerdo a este ámbito?

 ¿Es factible el proyecto?

 Tecnología en cuanto a Hw y lenguajes

 Financiación recursos como empresa para entrarle al proyecto
 Tiempo si se puede realizar en determinado tiempo
 Recursos máquinas

Proceso
 Es seleccionar el modelo de proceso apropiado para la
ingeniería de software que debe aplicar el equipo del
proyecto. Espiral, prototipo, cascada, etc. Para el proyectop
que se esta haciendo

 Debe elegirse el modelo del proceso en base a :

 Los clientes que han solicitado el producto y la gente que realizará el trabajo
el cliente va a decidir como quiere el proceso (rápido)
 Las características del producto en sí si esta definido, los requisitos
 El entorno del proyecto en el que trabaja el equipo de software. En donde
esta ubicado, el tiempo para realizarlo, donde lo voy a desarrollar

Proceso
 Cuando se selecciona un modelo de proceso se define
entonces un plan de proyecto preliminar basado en un
conjunto de actividades estructurales. Plan para el proyecto
 Comunicación con el cliente cuestionarios, entrevistas
 Planificación
 Análisis del riesgo
 Ingeniería
 Construcción y entrega medir riesgo y tratar de eliminarlo
 Evaluación del cliente

Proyecto
 Diez señales que indican que un proyecto de sistemas está en
peligro [John Reel]
 La gente del software no comprende las necesidades de los clientes
 El ámbito del producto está definido pobremente
 Los cambios están mal realizados
 La tecnología elegida cambia
Proyecto
 Las necesidades del negocio cambian o están mal definidas
 Las fechas de entrega no son realistas

 Los usuarios se resisten

 Se pierden patrocinadores o no se tuvieron

 El equipo carece del personal con las habilidades apropiadas

 Los gestores y desarrolladores evitan buenas prácticas y

sabias lecciones.