Presentación de IS

Proyecto de IS
Introducción a la IS
Proceso y Ciclo de Vida

Proceso Software y
Ciclo de Vida

Curso 2008-2009

Gonzalo Méndez
Dpto. de Ingeniería de Software e Inteligencia Artificial
Facultad de Informática
Universidad Complutense de Madrid
 Conceptos importantes
ƒ Personas
• los que trabajan
ƒ Producto
• lo que se obtiene
ƒ Proyecto
• la pauta a seguir para desarrollar un producto
ƒ Proceso
• la pauta a seguir para desarrollar un proyecto
 Un traje
ƒ Personas
• El sastre
ƒ Producto
• El traje
ƒ Proyecto:
• el sastre, el traje, el presupuesto del traje, el traje en sí, los
pasos a dar para hacer el traje...
ƒ Proceso
• La secuencia de acciones para hacer un traje concreto
 Una cena
ƒ Personas
• Empleados de una empresa de catering
ƒ Producto
• La cena que se sirve
ƒ Proyecto
• El menú, el presupuesto, lo que hay que hacer para
conseguir el menú, ...
ƒ Proceso
• La secuencia de acciones de servir una cena
 Una gama de automóviles
ƒ Personas
• Empleados de la marca
ƒ Producto
• Los automóviles
ƒ Proyecto
• Desarrollo de un modelo nuevo
ƒ Proceso
• Las instrucciones de la empresa sobre cómo
desarrollar un modelo nuevo
 Para vosotros
ƒ Personas
• vuestro grupo
ƒ Producto
• la aplicación elegida
ƒ Proyecto
• parte práctica IS
ƒ Proceso
• entregas mensuales + cómo vosotros decidáis
organizaros
 Capas de la IS
ƒ Capa de enfoque de calidad
ƒ Capa de proceso
ƒ Capa de métodos
ƒ Capa de herramientas
 Capas de la IS
ƒ Capa de calidad
• Base de cualquier proceso de ingeniería
• La IS se basa en calidad
• Mejores técnicas de construcción de software
ƒ Capa de proceso
• Capa que une calidad y métodos
• Desarrollo racional de la IS
• Conjunto de actividades y resultados asociados que
sirven para construir un producto software
 Capas de la IS
ƒ Capa de métodos
• Un método incluye:
• Análisis de requisitos
• Diseño
• Construcción de programas
• Prueba
• Mantenimiento
• Suelen estar bastante ligados al proceso
ƒ Capa de herramientas
• Soporte automático o semiautomático para el proceso y los
métodos
• Herramientas CASE
 Visión general de la IS
ƒ Con independencia del modelo de proceso hay
tres fases genéricas:
• Fase de definición
• Fase de desarrollo
• Fase de mantenimiento
ƒ Cada una de estas fases se descompone en un
conjunto de tareas
 Fase de definición/especificación
ƒ Se identifican requisitos de sistema y software:
• Información a procesar
• Función y rendimiento deseados
• Comportamiento del sistema
• Interfaces establecidas
• Restricciones de diseño
• Tareas principales:
• Planificación del proyecto software
• Ingeniería de sistemas o de información
• Análisis de requisitos
 Fase de desarrollo
ƒ Se define:
• Cómo diseñar las estructuras de datos
• Cómo implementar las funciones
• Cómo caracterizar las interfaces
• Cómo traducir el diseño a programación
• Cómo validar el producto (pruebas, verificación)
• Tareas principales:
• Diseño del software
• Generación del código
• Pruebas del software
 Fase de mantenimiento
ƒ Centrada en cambios que se pueda necesitar realizar
sobre un producto
ƒ Se vuelven a aplicar las fases de definición y
desarrollo, pero sobre software ya existente
ƒ Pueden producirse cuatro tipos de cambio:
• Corrección: Corregir los defectos
• Adaptación: Modificaciones por cambio externo
• Mejora: Ampliar los requisitos funcionales originales, a
petición del cliente
• Prevención: Cambio para facilitar el cambio
 Visión general de la IS
ƒ Estas fases se complementan con las
actividades de soporte
• No crean software
• Mejoran su calidad
• Facilitan su desarrollo
ƒ Se aplican a lo largo de todo el proceso del
software
 Visión general de la IS
ƒ Ejemplos de actividades de soporte
• Documentación
• Gestión de configuración
• Seguimiento y control del proyecto de software
• Revisiones técnicas formales
• Garantía de la calidad del software
• Gestión de reutilización
• Mediciones
• Gestión de riesgos
 Proceso software
ƒ Conjunto estructurado de actividades y resultados
asociados requeridos para desarrollar un sistema de
software
• Especificación: establecer requisitos y restricciones
• Diseño: Producir un modelo en papel del sistema
• Implementación: construcción del sistema de software
• Validación: verificar (por ejemplo mediante pruebas) que el
sistema cumple con las especificaciones requeridas
• Instalación: entregar el sistema al usuario
• Evolución y mantenimiento: cambiar/adaptar el software
según las demandas; reparar fallos en el sistema
 Modelos de proceso
ƒ Un modelo de proceso, o paradigma de IS, es
una plantilla, patrón o marco que define el
proceso a través del cual se crea software
ƒ Dicho de otra forma, los procesos son
instancias de un modelo de proceso
ƒ En esta asignatura los términos proceso y
modelo de proceso se utilizan indistintamente
 Modelos de proceso
ƒ Una organización podría variar su modelo de
proceso para cada proyecto, según:
• La naturaleza del proyecto
• La naturaleza de la aplicación
• Los métodos y herramientas a utilizar
• Los controles y entregas requeridas
 Características del proceso
ƒ Entendible
ƒ Visibilidad: Grado en que las actividades del proceso
proporcionan resultados
ƒ Soportable por herramientas CASE
ƒ Aceptabilidad: Grado en que los desarrolladores aceptan y
usan el proceso
ƒ Fiabilidad: Capacidad de evitar o detectar errores antes de que
sean defectos
ƒ Robustez: Continuidad del proceso a pesar de los problemas
ƒ Mantenible: Capacidad de evolución para adaptarse
ƒ Rapidez: Velocidad en que el proceso puede proporcionar un
sistema a partir de una especificación
 Modelos Genéricos de Desarrollo de
Software
ƒ Modelo de Cascada
ƒ Prototipado
ƒ Desarrollo Evolutivo
ƒ En espiral
ƒ Desarrollo basado en componentes
ƒ Métodos Formales
 Modelo en cascada (waterfall)
ƒ Modelo de proceso clásico (desde los 70)
ƒ Basado en la mentalidad de línea de
ensamblaje (cartesiano)
ƒ Es sencillo y fácil de entender
ƒ El proyecto pasa a través de una serie de fases
• Al final de cada fase se revisan las tareas de
trabajo y productos
• Para poder pasar a la siguiente fase se tiene que haber
conseguido todos los objetivos de la fase anterior
• No hay apenas comunicación entre las fases
Modelo en cascada (waterfall)
Definición de
Requisitos

Diseño del Software

y del Sistema

Implementación y
Pruebas Unitarias

Integración y Prueba
del Sistema

Operación y
Mantenimiento
 Modelo en cascada (waterfall)
ƒ Fases:
• Conceptualización: Se determina la arquitectura de la
solución (división del sistema en subsistemas)
• Análisis de requisitos: Básicamente se definen los
requisitos funcionales y de rendimiento
• Diseño: Representación de la aplicación que sirve de guía a
la implementación
• Implementación: Transforma el diseño en código
• Prueba: Validación e integración de software y sistemas
• Instalación y comprobación: Se instala el software al
cliente, el cual comprueba la corrección de la aplicación
ƒ Se supone que sólo se baja en la cascada... pero
también se puede subir (aunque difícilmente)
 Modelo en cascada (waterfall)
ƒ Posibles ventajas:
• Sencillo: Sirve cuando el personal está poco cualificado
• Aplicable cuando el problema es estable y cuando se
trabaja con técnicas conocidas
ƒ Críticas:
• No se ve un producto hasta muy tarde en el proceso
• Un error grave detectado en las últimas fases puede ser letal
• Especificación de requisitos estable
• Impone una estructura de gestión de proyectos
• Fases muy rígidas
• Las revisiones de proyectos de gran complejidad son muy
difíciles
 Prototipado
ƒ Se usa un prototipo para dar al usuario una idea
concreta de lo que va a hacer el sistema
ƒ Se aplica cada vez más cuando la rapidez de
desarrollo es esencial
ƒ Prototipado evolutivo: el prototipo inicial se refina
progresivamente hasta convertirse en versión final
ƒ Prototipado desechable: de cada prototipo se extraen
ideas buenas que se usan para hacer el siguiente, pero
cada prototipo se tira entero
 Prototipado

Escuchar
al cliente
Construir/
revisar
prototipo
El cliente
evalúa el
prototipo
 Prototipado
ƒ Comienza con la recolección de requisitos
• Cliente y desarrolladores definen los objetivos globales del
software.
• Además, identifican los requisitos conocidos y aquellos que
deben ser más definidos.
ƒ Aparece un diseño rápido centrado en los aspectos
visibles para el cliente (e.g. información de E/S)
• El diseño rápido lleva a la construcción de un prototipo
ƒ El prototipo lo evalúa el cliente y lo utiliza para
refinar los requisitos
ƒ El proceso se itera... ¿desechando el prototipo?
 Prototipado
ƒ Ventajas
• Permite identificar los requisitos incrementalmente
• Permite probar alternativas a los desarrolladores
• Tiene una alta visibilidad Æ tanto clientes como
desarrolladores ven resultados rápidamente
ƒ Inconvenientes
• El cliente no entiende por qué hay que desechar el prototipo
• Si simplemente ha pedido unos ajustes...(¿?)
• Riesgo de software de baja calidad
• Compromisos de implementación para que el prototipo funcione
rápidamente y que al final son parte integral del sistema
– Utilizar un SO o lenguaje de programación inadecuado pero conocido
 Modelos evolutivos
ƒ Características:
• Gestionan bien la naturaleza evolutiva del software
• Son iterativos: construyen versiones de software
cada vez más completas
ƒ Se adaptan bien:
• Los cambios de requisitos del producto
• Fechas de entrega estrictas poco realistas
• Especificaciones parciales del producto
 Modelos evolutivos
Actividades
Concurrentes

Versión
Especificación Inicial

Descripción Versiones
del sistema
Desarrollo Versiones
Intermedias
Intermedias

Validación Versión
Final
 Modelos evolutivos. Incremental
ƒ Fusiona el modelo lineal secuencial con el de
construcción de prototipos

A D C P 1er incremento

A D C P 2º incremento

..................... N-ésimo incremento

 Modelos evolutivos. Incremental
ƒ Cada secuencia lineal secuencial produce un
incremento del software
• Incremento: producto operacional de una parte del sistema
ƒ El primer incremento suele ser el núcleo
• Requisitos básicos
• Muchas funciones suplementarias se dejan para después
ƒ Se evalúa (p.ej., por el cliente) el producto entregado
• Como resultado se desarrolla un plan para el siguiente
ƒ Se itera
• Hasta elaborar el producto completo
 Modelos evolutivos. Incremental
ƒ Ventajas
• Es interactivo
• Con cada incremento se entrega al cliente un producto operacional
al cliente, que puede evaluarlo
• Personal
• Permite variar el personal asignado a cada iteración
• Gestión riesgos técnicos
• Por ejemplo, disponibilidad de hardware específico
ƒ Inconvenientes
• La primera iteración puede plantear los mismos problemas
que en un modelo lineal secuencial
 Modelo de Proceso en Espiral
ƒ Original: Boehm, 1988
ƒ IEEE Std. 1490-1998
ƒ Tratar primero las áreas de mayor riesgo
ƒ Múltiples iteraciones sobre varias regiones de tareas
• Vuelta a la espiral: ciclo
• Número de iteraciones predeterminadas o calculadas
dinámicamente
ƒ Se pueden variar las actividades de desarrollo: familia
de modelos de procesos
 Modelo de Proceso de Espiral
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 tipo1
Simulaciones, modelos y benchmarks
Plan de requerimientos Concepto 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
Aceptación Desarrolla y verifica
siguiente fase
Servicio el siguiente nivel
del producto
 Modelo de Proceso en Espiral
ƒ El modelo en espiral es bastante adecuado para
la gestión de riesgos
ƒ Se puede añadir una actividad de gestión de
riesgos
ƒ De hecho, el modelo original de Boehm:
• Fijar objetivos
• Gestionar y reducir riesgos
• Desarrollo y validación
• Planificar siguiente ciclo
 Modelos Evolutivos. Espiral Boehm
ƒ Fijar objetivos
• Definir objetivos del ciclo
• Identificar restricciones del proceso y producto
• Desarrollar plan de gestión
• Identificar riesgos
• Identificar estrategias alternativas
ƒ Gestionar y reducir el riesgo
• RSGR para cada riesgo identificado
 Modelos Evolutivos. Espiral Boehm
ƒ Desarrollo y validación
• Elegir modelo de desarrollo
• Algunos autores lo denominan metamodelo
• Yo prefiero llamarlo modelo paramétrico
ƒ Planificación
• Revisión del proyecto
• Decisión de una nueva vuelta
 Modelos de Proceso en Espiral
ƒ Ventajas
• Enfoque realista
• Gestión explícita de riesgos
• 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
 Modelos de Proceso en Espiral
ƒ Inconvenientes
• Convencer cliente enfoque controlable
• Requiere de experiencia en la identificación de
riesgos
• Requiere refinamiento para uso generalizado
Desarrollo Basado en Componentes
ƒ Desarrollo de sistemas en poco tiempo
ƒ Adaptación a “alta velocidad” de la cascada
• Equipos trabajando en paralelo
• Aplicando tecnología de componentes
Equipo 1 Equipo 2 Equipo n
A A A
D D ............ D
C C C
P P P

60-90 días
Desarrollo Basado en Componentes
ƒ Ventajas
• Rapidez
• Válido para aplicaciones modularizables
ƒ Inconvenientes
• Exige conocer bien los requisitos y delimitar el ámbito del
proyecto
• Número de personas
• Clientes y desarrolladores comprometidos
• Gestión riesgos técnicos altos
• Uso de nueva tecnología
• Alto grado de interoperabilidad con sistemas existentes
Desarrollo Basado en Componentes

Identificar
componentes
candidatos

Construir Buscar
iteración N componentes
del sistema en biblioteca

Añadir Extraer
componentes componentes
a biblioteca disponibles

Construir
componentes
que falten
 Desarrollo con métodos formales
ƒ Se basa en la transformación de una
especificación formal a lo largo de varias
representaciones hasta llegar a un programa
ejecutable
ƒ Las transformaciones preservan la corrección
• Permiten comprobar fácilmente que el programa es
conforme a la especificación
 Desarrollo con métodos formales

Requirements Formal Formal Integration and

definition specification transformation system testing
 Transformaciones formales

Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

 Desarrollo formal de sistemas
ƒ Problemas
• Hace falta una formación especializada para aplicar la
técnica
• Muchos aspectos de los sistemas reales son difíciles de
especificar formalmente
• Interfaz de usuario
• Requisitos no funcionales
ƒ Aplicabilidad
• Sistemas críticos en los que la seguridad y fiabilidad debe
poder asegurarse antes de poner el sistema en operación
 Visibilidad de Procesos
ƒ Los sistemas de software son intangibles por lo que
los administradores necesitan documentación para
identificar el progreso en el desarrollo
ƒ Esto puede causar problemas
• El tiempo planeado para entregar resultados puede no
coincidir con el necesario para completar una actividad
• La necesidad de producir documentos restringe la iteración
entre procesos
• Tiempo para revisar y aprobar documentos significativo
ƒ El modelo de cascada es aún el modelo basado en
resultados mas utilizado
 Visibilidad de Procesos
Modelo de Proceso Visibilidad del Proceso

Modelo de Cascada Buena visibilidad, cada actividad

produce un documento o
resultado
Desarrollo Evolutivo Visibilidad pobre, muy caro al
producir documentos en cada
iteración
Modelos Formales Buena visibilidad, en cada fase
deben producirse documentos

Desarrollo orientado a la Visibilidad moderada. Importante

reutilización contar con documentación de
componentes reutilizables

Modelo de Espiral Buena visibilidad, cada segmento

y cada anillo del espiral debe
producir un documento
 ¿Qué modelo utilizar?
ƒ Para sistemas bien conocidos se puede utilizar el
Modelo de Cascada. La fase de análisis de riesgos es
relativamente fácil
ƒ Con requisitos estables y sistemas de seguridad
críticos, se recomienda utilizar modelos formales
ƒ Con especificaciones incompletas, el modelo de
prototipado ayuda a identificarlos y va produciendo
un sistema funcional
ƒ Pueden utilizarse modelos híbridos en distintas partes
del desarrollo
 Ejemplos
ƒ Dos modelos de proceso concretos:
• Proceso Unificado de Rational (pesado)
• Extreme Programming (ágil)
 Proceso Unificado
ƒ Los autores de UML
• Booch: método Booch
• Rumbaugh: OMT
• Jacobson: proceso Objectory
ƒ También conocido como RUP: Rational
Unified Process
 Proceso Unificado
ƒ Es un proceso de desarrollo de software
• Dirigido por casos de uso
• Centrado en la arquitectura
• Iterativo e incremental
ƒ Utiliza UML para definir los modelos del sistema software
ƒ El sistema software en construcción está formado por
• componentes software
• interconectados a través de interfaces

Proceso de
Requisitos desarrollo de Sistema
de usuario software software

Los requisitos cambian

y el sistema software evoluciona
 Proceso Unificado
Organization along time

Phases
Process Components Inception Elaboration Construction Transition

Requirements Capture

Analysis & Design

Implementation
Organization Test
along content
Supporting Components
Management
Environment
Deployment
preliminary iter. iter. iter. iter. iter. iter. iter.
iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
 Extreme Programming (XP)
ƒ Modelo de proceso de Kent Beck
Un modo ligero, eficiente, de bajo riesgo, flexible,
predecible, científico y divertido de producir software
ƒ Características
• Alta visibilidad debido a ciclos muy cortos
• Planificación incremental
• Se adapta a cambios de negocio
 Extreme Programming (XP)
ƒ Basado en pruebas automatizadas escritas por
desarrolladores y clientes (test-driven)
ƒ Alta comunicación
ƒ Diseño evolutivo
ƒ Colaboración entre programadores
ƒ Busca equilibrio entre las necesidades a corto
plazo de los programadores y las de largo
plazo del proyecto
 Extreme Programming (XP)
ƒ La estructura del proceso, si la hay, es un poco
atípica

Codificación Prueba Evaluación Diseño

Actividades en XP
 Extreme Programming (XP)
ƒ Las cuatro actividades están soportadas por doce prácticas:
• El juego de planificación
• Pequeñas entregas
• Metáfora
• Diseño simple
• Prueba
• Refactoring
• Programación en pareja
• Propiedad colectiva
• Integración continua
• Semana de cuarenta horas
• Cliente en el lugar de desarrollo
• Codificación estándar
 Extreme Programming (XP)
ƒ Ventajas:
• Bueno para especificaciones cambiantes
• Fundamentación práctica
ƒ Inconvenientes:
• Poco probado
• Poco compatible con especificaciones/diseños
totales
• Sólo funciona con equipos pequeños (hasta diez
personas)
 Extreme Programming (XP)

ƒ Diferencias fundamentales (hay más que ya se

verán)
• No hay requisitos explícitos sino que el cliente
participa en el desarrollo
• Se empieza por automatizar las pruebas
• Se desarrolla siempre la versión más simple posible
que resuelva el problema
• Se ejecutan todas las pruebas todos los días
• Se cambia el diseño (aunque sea radicalmente)
siempre que haga falta
Calidad del proceso de software

¿ Cómo medir la calidad del

proceso de software de una
empresa ?
 La empresa ideal
ƒ El Dpto. de la Defensa de los US fundó el Software
Engineering Institute (SEI) asociado con la
Universidad de Carnegie Mellon (CMU).
ƒ Desarrollan el Software Capability Maturity Model
(SW CMM) a mediados de 1980s, refinado en los
inicios de l990s.
ƒ Este modelo define una serie de áreas clave de
proceso (ACP)
• Un área clave de proceso es, básicamente, una actividad de
IS
 Software Capability Maturity Model

Level 5
Optimizing

Level 4
Managed

Level 3
Defined

Level 2
Repeatable

Level 1
Initial
 Áreas clave del proceso
O p t i m i zi n g
P r o ce s s c h a n g e m a n a g em e n t
T e c h n o l o g y c h a n g e m a n a g em e n t
D e f e c t p r e v e n t io n

M a n a g ed
S o f tw a re q u a l it y m a n a g e m e n t
Q u a nt it a t iv e p r o c e s s m a n a g e m e n t

D e fin e d
P e e r r e v ie w s
I n t e r g ro u p c o o r d in a t io n
S o f tw a r e p r o d u c t e n g i n e e r i n g
I n t e g r a t e d s o f tw a r e m a n a g e m e n t
T ra ining p rog ra m m e
O r g a n i z a ti o n p r oc e s s d e f in it io n
O r g a n i z a ti o n p r oc e s s f o c u s

R e p e atab le
S o f tw a r e c o n f i g u ra t io n m a n a g e m e n t
S o f tw a r e q u a l it y a s s u r a n c e
S o f tw a r e s u b c o n tr a c t m a n a g e m e n t
S o f tw a r e p ro je c t tr a c k i n g a n d o v e r s ig h t
S o f tw a r e p ro je c t p l a n n in g
R e q u ir e m e n ts m a n a g e m e n t

I n it i a l

©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31.

 CMM
ƒ Los niveles son acumulativos
ƒ Nivel 1: Inicial
• El proceso de software se caracteriza según el caso
• Se definen poco procesos
• El éxito depende del esfuerzo individual
 CMM
ƒ Nivel 2: Repetible
• Se incluye seguimiento del coste, la planificación y la
funcionalidad
• Se repiten técnicas de proyectos anteriores con buenos
resultados
• Las ACP son:
• Planificación del proyecto de software
• Seguimiento y supervisión del proyecto de software
• Gestión de requisitos
• Gestión de la configuración software (GCS)
• Garantía de calidad del software (SQA)
• Gestión de la subcontratación
 CMM
ƒ Nivel 3: Definido
• Nivel 2
• Las actividades se documentan, estandarizan e integran en
un proceso a nivel organización
• Existe un proceso documentado
• Las ACP son:
• Definición y enfoque del proceso de la organización
• Programa de formación
• Revisiones periódicas
• Coordinación entre grupos
• Ingeniería de productos software
• Gestión de integración del software
 CMM
ƒ Nivel 4: Gestionado
• Nivel 3
• Se recopilan medidas del proceso del software y de
la calidad del producto
• Estas medidas sirven para gestionar el proceso
• Las ACP son:
• Gestión de la calidad del software
• Gestión cuantitativa del software
 CMM
ƒ Nivel 5: Optimización
• Nivel 4
• En base a la experiencia y métricas se optimiza el
proceso
• Las ACP son:
• Gestión de cambios del proceso
• Gestión de cambios de tecnología
• Prevención de defectos
 CMM
ƒ Un nivel razonable es el definido (nivel 3)
ƒ Un nivel deseable es optimización (nivel 5)
ƒ Con independencia del CMM, ACPs mínimas:
• Planificación del proyecto
• Seguimiento y supervisión del proyecto
• Gestión de requisitos
• GCS
• SQA
• Definición del proceso
• Revisiones periódicas
• Coordinación entre grupos
 Datos Agosto 2000
ƒ Inicial 34,9%
ƒ Repetible 38,2%
ƒ Definido 18,5%
ƒ Gestionado 5,5%
ƒ Optimizado 2,9%

ƒ Resultados de 901 empresas desde 1996.

 Referencias
• Modelos de proceso
• Pressman 17-46, Sommerville 42-67
• Proceso Unificado
• Jacobson, Krutchen
• SW CMM
• Pressman Cap. 2, Sommerville Cap. 25
• http://www.sei.cmu.edu/cmm/obtain.cmm.html
• Material
• Pablo Gervás
• Juan Pavón y Jorge Gómez
• Natalia Juristo