Gonzalo Mndez

Dpto. de Ingeniera de Software e Inteligencia Artificial

Facultad de Informtica
Universidad Complutense de Madrid
Curso 2008-2009
Proceso Software y
Ciclo de Vida
Presentacin de IS
Proyecto de IS
Introduccin a la IS
Proceso y Ciclo de Vida
Conceptos importantes
Personas

los que trabajan
los que trabajan
Producto

lo que se obtiene
lo que se obtiene
Proyecto

la pauta a seguir para desarrollar un producto
la pauta a seguir para desarrollar un producto
Proceso

la pauta a seguir para desarrollar un proyecto
la pauta a seguir para desarrollar un proyecto
Un traje
Personas

El sastre
El sastre
Producto

El traje
El traje
Proyecto:

el sastre, el traje, el presupuesto del traje, el traje en s
el sastre, el traje, el presupuesto del traje, el traje en s

, los
, los
pasos a dar para hacer el traje...
pasos a dar para hacer el traje...
Proceso

La secuencia de acciones para hacer un traje concreto
La secuencia de acciones para hacer un traje concreto
Una cena
Personas

Empleados de una empresa de catering
Empleados de una empresa de catering
Producto

La cena que se sirve
La cena que se sirve
Proyecto

El men
El men

, el presupuesto, lo que hay que hacer para

, el presupuesto, lo que hay que hacer para
conseguir el men
conseguir el men

, ...
, ...
Proceso

La secuencia de acciones de servir una cena
La secuencia de acciones de servir una cena
Una gama de automviles
Personas

Empleados de la marca
Empleados de la marca
Producto

Los autom
Los autom

viles
viles
Proyecto

Desarrollo de un modelo nuevo
Desarrollo de un modelo nuevo
Proceso

Las instrucciones de la empresa sobre c
Las instrucciones de la empresa sobre c

mo
mo
desarrollar un modelo nuevo
desarrollar un modelo nuevo
Para vosotros
Personas

vuestro grupo
vuestro grupo
Producto

la aplicaci
la aplicaci

n elegida
n elegida
Proyecto

parte pr
parte pr

ctica IS
ctica IS
Proceso

entregas mensuales + c
entregas mensuales + c

mo vosotros decid
mo vosotros decid

is
is
organizaros
organizaros
Capas de la IS
Capa de enfoque de calidad
Capa de proceso
Capa de mtodos
Capa de herramientas
Capas de la IS
Capa de calidad

Base de cualquier proceso de ingenier
Base de cualquier proceso de ingenier

a
a

La IS se basa en calidad
La IS se basa en calidad
Mejores tcnicas de construccin de software
Capa de proceso

Capa que une calidad y m
Capa que une calidad y m

todos
todos
Desarrollo racional de la IS

C
C
onjunto
onjunto
de actividades y resultados asociados que
de actividades y resultados asociados que
sirven para construir un producto software
sirven para construir un producto software
Capas de la IS
Capa de mtodos

Un m
Un m

todo incluye:
todo incluye:
Anlisis de requisitos
Diseo
Construccin de programas
Prueba
Mantenimiento

Suelen estar bastante ligados al proceso
Suelen estar bastante ligados al proceso
Capa de herramientas

Soporte autom
Soporte autom

tico o semiautom
tico o semiautom

tico para el proceso y los

tico para el proceso y los
m
m

todos
todos

Herramientas CASE
Herramientas CASE
Visin general de la IS
Con independencia del modelo de proceso hay
tres fases genricas:

Fase de definici
Fase de definici

n
n

Fase de desarrollo
Fase de desarrollo

Fase de mantenimiento
Fase de mantenimiento
Cada una de estas fases se descompone en un
conjunto de tareas
Fase de definicin/especificacin
Se identifican requisitos de sistema y software:

Informaci
Informaci

n a procesar
n a procesar

Funci
Funci

n y rendimiento deseados
n y rendimiento deseados

Comportamiento del sistema
Comportamiento del sistema

Interfaces establecidas
Interfaces establecidas

Restricciones de dise
Restricciones de dise

o
o

Tareas principales:
Tareas principales:
Planificacin del proyecto software
Ingeniera de sistemas o de informacin
Anlisis de requisitos
Fase de desarrollo
Se define:

C
C

mo dise
mo dise

ar las estructuras de datos

ar las estructuras de datos

C
C

mo implementar las funciones

mo implementar las funciones

C
C

mo caracterizar las interfaces

mo caracterizar las interfaces

C
C

mo traducir el dise
mo traducir el dise

o a programaci
o a programaci

n
n

C
C

mo validar el producto (pruebas, verificaci

mo validar el producto (pruebas, verificaci

n)
n)

Tareas principales:
Tareas principales:
Diseo del software
Generacin del cdigo
Pruebas del software
Fase de mantenimiento
Centrada en cambios que se pueda necesitar realizar
sobre un producto
Se vuelven a aplicar las fases de definicin y
desarrollo, pero sobre software ya existente
Pueden producirse cuatro tipos de cambio:

Correcci
Correcci

n
n
: Corregir los defectos
: Corregir los defectos

Adaptaci
Adaptaci

n
n
: Modificaciones por cambio externo
: Modificaciones por cambio externo

Mejora
Mejora
: Ampliar los requisitos funcionales originales, a
: Ampliar los requisitos funcionales originales, a
petici
petici

n del cliente
n del cliente

Prevenci
Prevenci

n
n
: Cambio para facilitar el cambio
: Cambio para facilitar el cambio
Visin general de la IS
Estas fases se complementan con las
actividades de soporte

No crean software
No crean software

Mejoran su
Mejoran su
calidad
calidad

Facilitan su desarrollo
Facilitan su desarrollo
Se aplican a lo largo de todo el proceso del
software
Visin general de la IS
Ejemplos de actividades de soporte

Documentaci
Documentaci

n
n

Gesti
Gesti

n de configuraci
n de configuraci

n
n

Seguimiento y control del proyecto de software
Seguimiento y control del proyecto de software

Revisiones t
Revisiones t

cnicas formales
cnicas formales

Garant
Garant

a de la calidad del software

a de la calidad del software

Gesti
Gesti

n de reutilizaci
n de reutilizaci

n
n

Mediciones
Mediciones

Gesti
Gesti

n de riesgos
n de riesgos
Proceso software
Conjunto estructurado de actividades y resultados
asociados requeridos para desarrollar un sistema de
software

Especificaci
Especificaci

n
n
: establecer requisitos y restricciones
: establecer requisitos y restricciones

Dise
Dise

o
o
: Producir un modelo en papel del sistema
: Producir un modelo en papel del sistema

Implementaci
Implementaci

n
n
: construcci
: construcci

n del sistema de software

n del sistema de software

Validaci
Validaci

n
n
:
:
verificar (por ejemplo mediante pruebas) que el
verificar (por ejemplo mediante pruebas) que el
sistema cumple con las especificaciones requeridas
sistema cumple con las especificaciones requeridas

Instalaci
Instalaci

n
n
: entregar el sistema al usuario
: entregar el sistema al usuario

Evoluci
Evoluci

n y mantenimiento
n y mantenimiento
:
:
cambiar/adaptar el software
cambiar/adaptar el software
seg
seg

n las demandas;
n las demandas;
reparar fallos en el sistema
reparar fallos en el sistema
Modelos de proceso
Un modelo de proceso, o paradigma de IS, es
una plantilla, patrn o marco que define el
proceso a travs del cual se crea software
Dicho de otra forma, los procesos son
instancias de un modelo de proceso
En esta asignatura los trminos proceso y
modelo de proceso se utilizan indistintamente
Modelos de proceso
Una organizacin podra variar su modelo de
proceso para cada proyecto, segn:

La naturaleza del proyecto
La naturaleza del proyecto

La naturaleza de la aplicaci
La naturaleza de la aplicaci

n
n

Los m
Los m

todos y herramientas a utilizar

todos y herramientas a utilizar

Los controles y entregas requeridas
Los controles y entregas requeridas
Caractersticas del proceso
Entendible
Visibilidad: Grado en que las actividades del proceso
proporcionan resultados
Soportablepor 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 evolucin para adaptarse
Rapidez: Velocidad en que el proceso puede proporcionar un
sistema a partir de una especificacin
Modelos Genricos de Desarrollo de
Software
Modelo de Cascada
Prototipado
Desarrollo Evolutivo
En espiral
Desarrollo basado en componentes
Mtodos Formales
Modelo en cascada (waterfall)
Modelo de proceso clsico (desde los 70)
Basado en la mentalidad de lnea de
ensamblaje (cartesiano)
Es sencillo y fcil de entender
El proyecto pasa a travs de una serie de fases

Al final de cada fase se revisan las tareas de
Al final de cada fase se revisan las tareas de
trabajo y productos
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
No hay apenas comunicaci

n entre las fases

n entre las fases
Modelo en cascada (waterfall)
Definicin de
Requisitos
Diseo del Software
y del Sistema
Implementacin y
Pruebas Unitarias
Integracin y Prueba
del Sistema
Operacin y
Mantenimiento
Modelo en cascada (waterfall)
Fases:

Conceptualizaci
Conceptualizaci

n
n
: Se determina la arquitectura de la
: Se determina la arquitectura de la
soluci
soluci

n (divisi
n (divisi

n del sistema en subsistemas)

n del sistema en subsistemas)

An
An

lisis de requisitos
lisis de requisitos
: B
: B

sicamente se definen los

sicamente se definen los
requisitos funcionales y de rendimiento
requisitos funcionales y de rendimiento

Dise
Dise

o
o
: Representaci
: Representaci

n de la aplicaci
n de la aplicaci

n que sirve de gu
n que sirve de gu

a a
a a
la implementaci
la implementaci

n
n

Implementaci
Implementaci

n
n
: Transforma el dise
: Transforma el dise

o en c
o en c

digo
digo

Prueba
Prueba
: Validaci
: Validaci

n e integraci
n e integraci

n de software y sistemas
n de software y sistemas

Instalaci
Instalaci

n y comprobaci
n y comprobaci

n
n
: Se instala el software al
: Se instala el software al
cliente, el cual comprueba la correcci
cliente, el cual comprueba la correcci

n de la aplicaci
n de la aplicaci

n
n
Se supone que slo se baja en la cascada... pero
tambin se puede subir (aunque difcilmente)
Modelo en cascada (waterfall)
Posibles ventajas:

Sencillo: Sirve cuando el personal est
Sencillo: Sirve cuando el personal est

poco cualificado
poco cualificado

Aplicable cuando el problema es estable y cuando se
Aplicable cuando el problema es estable y cuando se
trabaja con t
trabaja con t

cnicas conocidas
cnicas conocidas
Crticas:

No se ve un producto hasta muy tarde en el proceso
No se ve un producto hasta muy tarde en el proceso
Un error grave detectado en las ltimas fases puede ser letal

Especificaci
Especificaci

n de requisitos estable
n de requisitos estable

Impone una estructura de gesti
Impone una estructura de gesti

n de proyectos
n de proyectos
Fases muy rgidas

Las revisiones de proyectos de gran complejidad son muy
Las revisiones de proyectos de gran complejidad son muy
dif
dif

ciles
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 ms cuando la rapidez de
desarrollo es esencial
Prototipadoevolutivo: el prototipo inicial se refina
progresivamente hasta convertirse en versin final
Prototipadodesechable: de cada prototipo se extraen
ideas buenas que se usan para hacer el siguiente, pero
cada prototipo se tira entero
Prototipado
Escuchar
al cliente
El cliente
evala el
prototipo
Construir/
revisar
prototipo
Prototipado
Comienza con la recoleccin de requisitos

Cliente y desarrolladores definen los objetivos globales del
Cliente y desarrolladores definen los objetivos globales del
software.
software.

Adem
Adem

s, identifican los requisitos conocidos y aquellos que

s, identifican los requisitos conocidos y aquellos que
deben ser m
deben ser m

s definidos.
s definidos.
Aparece un diseo rpido centrado en los aspectos
visibles para el cliente (e.g. informacin de E/S)

El dise
El dise

o r
o r

pido lleva a la construcci

pido lleva a la construcci

n de un prototipo
n de un prototipo
El prototipo lo evala el cliente y lo utiliza para
refinar los requisitos
El proceso se itera... desechando el prototipo?
Prototipado
Ventajas

Permite identificar los requisitos incrementalmente
Permite identificar los requisitos incrementalmente

Permite probar alternativas a los desarrolladores
Permite probar alternativas a los desarrolladores

Tiene una alta visibilidad
Tiene una alta visibilidad

tanto clientes como

tanto clientes como
desarrolladores ven resultados r
desarrolladores ven resultados r

pidamente
pidamente
Inconvenientes

El cliente no entiende por qu
El cliente no entiende por qu

hay que desechar el prototipo
hay que desechar el prototipo
Si simplemente ha pedido unos ajustes...(?)

Riesgo de software de baja calidad
Riesgo de software de baja calidad
Compromisos de implementacin para que el prototipo funcione
rpidamente y que al final son parte integral del sistema
Utilizar un SO o lenguaje de programacin inadecuado pero conocido
Modelos evolutivos
Caractersticas:

Gestionan bien la naturaleza evolutiva del software
Gestionan bien la naturaleza evolutiva del software

Son iterativos: construyen versiones de software
Son iterativos: construyen versiones de software
cada vez m
cada vez m

s completas
s completas
Se adaptan bien:

Los cambios de requisitos del producto
Los cambios de requisitos del producto

Fechas de entrega estrictas poco realistas
Fechas de entrega estrictas poco realistas

Especificaciones parciales del producto
Especificaciones parciales del producto
Modelos evolutivos
Descripcin
del sistema
Versin
Inicial
Versiones
Intermedias
Versiones
Intermedias
Versin
Final
Especificacin
Desarrollo
Validacin
Actividades
Concurrentes
Modelos evolutivos. Incremental
Fusiona el modelo lineal secuencial con el de
construccin de prototipos
A
D C
P
1
er
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
Incremento: producto operacional de una parte del sistema
El primer incremento suele ser el ncleo

Requisitos b
Requisitos b

sicos
sicos

Muchas funciones suplementarias se dejan para despu
Muchas funciones suplementarias se dejan para despu

s
s
Se evala (p.ej., por el cliente) el producto entregado

Como resultado se desarrolla un plan para el siguiente
Como resultado se desarrolla un plan para el siguiente
Se itera

Hasta elaborar el producto completo
Hasta elaborar el producto completo
Modelos evolutivos. Incremental
Ventajas

Es interactivo
Es interactivo
Con cada incremento se entrega al cliente un producto operacional
al cliente, que puede evaluarlo

Personal
Personal
Permite variar el personal asignado a cada iteracin

Gesti
Gesti

n riesgos t
n riesgos t

cnicos
cnicos
Por ejemplo, disponibilidad de hardware especfico
Inconvenientes

La primera iteraci
La primera iteraci

n puede plantear los mismos problemas

n puede plantear los mismos problemas
que en un modelo lineal secuencial
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
Mltiples iteraciones sobre varias regiones de tareas

Vuelta a la espiral: ciclo
Vuelta a la espiral: ciclo

N
N

mero de iteraciones predeterminadas o calculadas

mero de iteraciones predeterminadas o calculadas
din
din

micamente
micamente
Se pueden variar las actividades de desarrollo: familia
de modelos de procesos
Modelo de Proceso de Espiral
Determine objetivos
alternativas y
restricciones
Evale alternativas,
identifique y resuelva
riesgos
Anlisis de
Riesgos
Anlisis de
Riesgos
Anlisis de
Riesgos
Anlisis
de
Riesgos
Planea la
siguiente fase
Desarrolla y verifica
el siguiente nivel
del producto
Prototipo
Operacional
Prototipo
3
Prototipo
2
Proto
tipo1
Plan de requerimientos
Plan del ciclo de vida
REVISIN
Plan de
Desarrollo
Plan de Integracin
y Prueba
Concepto de
Operacin
Simulaciones, modelos y benchmarks
Requeri
mientos

de
SW
Validacin de
Requerimientos
Diseo
V &V
Servicio
Prueba de
Aceptacin
Prueba de
Integracin
Prueba de
Unidades
Codificacin
Diseo
Detallado
Diseo
del
Producto
Modelo de Proceso en Espiral
El modelo en espiral es bastante adecuado para
la gestin de riesgos
Se puede aadir una actividad de gestin de
riesgos
De hecho, el modelo original de Boehm:

Fijar objetivos
Fijar objetivos

Gestionar y reducir riesgos
Gestionar y reducir riesgos

Desarrollo y validaci
Desarrollo y validaci

n
n

Planificar siguiente ciclo
Planificar siguiente ciclo
Modelos Evolutivos. Espiral Boehm
Fijar objetivos

Definir objetivos del ciclo
Definir objetivos del ciclo

Identificar restricciones del proceso y producto
Identificar restricciones del proceso y producto

Desarrollar plan de gesti
Desarrollar plan de gesti

n
n

Identificar riesgos
Identificar riesgos

Identificar estrategias alternativas
Identificar estrategias alternativas
Gestionar y reducir el riesgo

RSGR para cada riesgo identificado
RSGR para cada riesgo identificado
Modelos Evolutivos. Espiral Boehm
Desarrollo y validacin

Elegir modelo de desarrollo
Elegir modelo de desarrollo

Algunos autores lo denominan metamodelo
Algunos autores lo denominan metamodelo

Yo prefiero llamarlo modelo
Yo prefiero llamarlo modelo
param
param

trico
trico
Planificacin

Revisi
Revisi

n del proyecto
n del proyecto

Decisi
Decisi

n de una nueva vuelta

n de una nueva vuelta
Modelos de Proceso en Espiral
Ventajas

Enfoque realista
Enfoque realista

Gesti
Gesti

n expl
n expl

cita de riesgos
cita de riesgos

Centra su atenci
Centra su atenci

n en la reutilizaci
n en la reutilizaci

n de
n de
componentes y eliminaci
componentes y eliminaci

n de errores en
n de errores en
informaci
informaci

n descubierta en fases iniciales

n descubierta en fases iniciales

Los objetivos de calidad son el primer objetivo
Los objetivos de calidad son el primer objetivo

Integra desarrollo con mantenimiento
Integra desarrollo con mantenimiento
Modelos de Proceso en Espiral
Inconvenientes

Convencer cliente enfoque controlable
Convencer cliente enfoque controlable

Requiere de experiencia en la identificaci
Requiere de experiencia en la identificaci

n de
n de
riesgos
riesgos

Requiere refinamiento para uso generalizado
Requiere refinamiento para uso generalizado
Desarrollo Basado en Componentes
Desarrollo de sistemas en poco tiempo
Adaptacin a alta velocidad de la cascada

Equipos trabajando en paralelo
Equipos trabajando en paralelo

Aplicando tecnolog
Aplicando tecnolog

a de componentes
a de componentes
A
D
C
P
Equipo 1
A
D
C
P
Equipo 2
A
D
C
P
Equipo n
............
60-90 das
Desarrollo Basado en Componentes
Ventajas

Rapidez
Rapidez

V
V

lido para aplicaciones

lido para aplicaciones
modularizables
modularizables
Inconvenientes

Exige conocer bien los requisitos y delimitar el
Exige conocer bien los requisitos y delimitar el

mbito del
mbito del
proyecto
proyecto

N
N

mero de personas
mero de personas

Clientes y desarrolladores comprometidos
Clientes y desarrolladores comprometidos

Gesti
Gesti

n riesgos t
n riesgos t

cnicos altos
cnicos altos
Uso de nueva tecnologa
Alto grado de interoperabilidad con sistemas existentes
Identificar
componentes
candidatos
Buscar
componentes
en biblioteca
Extraer
componentes
disponibles
Construir
componentes
que falten
Aadir
componentes
a biblioteca
Construir
iteracin N
del sistema
Desarrollo Basado en Componentes
Desarrollo con mtodos formales
Se basaen la transformacinde una
especificacinformal a lo largo de varias
representacioneshastallegar a un programa
ejecutable
Las transformacionespreservanla correccin

Permiten
Permiten
comprobar
comprobar
f
f

cilmente
cilmente
que
que
el
el
programa
programa
es
es
conforme
conforme
a la
a la
especificaci
especificaci

n
n
Desarrollo con mtodos formales
Requirements
definition
Formal
specification
Formal
transformation
Integration and
system testing
Transformaciones formales
R2
Formal
specification
R3
Executable
program
P2 P3
P4
T1
T2 T3 T4
Proofs of transformation correctness
Formal transformations
R1
P1
Desarrollo formal de sistemas
Problemas

Hace
Hace
falta
falta
una
una
formaci
formaci

n
n
especializada
especializada
para
para
aplicar
aplicar
la
la
t
t

cnica
cnica

Muchos
Muchos
aspectos
aspectos
de los
de los
sistemas
sistemas
reales
reales
son
son
dif
dif

ciles
ciles
de
de
especificar
especificar
formalmente
formalmente
Interfaz de usuario
Requisitos no funcionales
Aplicabilidad

Sistemas
Sistemas
cr
cr

ticos
ticos
en los
en los
que
que
la
la
seguridad
seguridad
y
y
fiabilidad
fiabilidad
debe
debe
poder
poder
asegurarse
asegurarse
antes de
antes de
poner
poner
el
el
sistema
sistema
en
en
operaci
operaci

n
n
Visibilidad de Procesos
Los sistemas de software son intangibles por lo que
los administradores necesitan documentacin para
identificar el progreso en el desarrollo
Esto puede causar problemas

El tiempo planeado para entregar resultados puede no
El tiempo planeado para entregar resultados puede no
coincidir con el necesario para completar una actividad
coincidir con el necesario para completar una actividad

La necesidad de producir documentos restringe la iteraci
La necesidad de producir documentos restringe la iteraci

n
n
entre procesos
entre procesos

Tiempo para revisar y aprobar documentos significativo
Tiempo para revisar y aprobar documentos significativo
El modelo de cascada es an 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
iteracin
Modelos Formales Buena visibilidad, en cada fase
deben producirse documentos
Desarrollo orientado a la
reutilizacin
Visibilidad moderada. Importante
contar con documentacin 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 anlisis de riesgos es
relativamente fcil
Con requisitos estables y sistemas de seguridad
crticos, se recomienda utilizar modelos formales
Con especificaciones incompletas, el modelo de
prototipadoayuda a identificarlos y va produciendo
un sistema funcional
Pueden utilizarse modelos hbridos en distintas partes
del desarrollo
Ejemplos
Dos modelos de proceso concretos:

Proceso Unificado de
Proceso Unificado de
Rational
Rational
(pesado)
(pesado)

Extreme
Extreme
Programming
Programming
(
(

gil)
gil)
Proceso Unificado
Los autores de UML

Booch
Booch
: m
: m

todo
todo
Booch
Booch

Rumbaugh
Rumbaugh
: OMT
: OMT

J acobson: proceso
J acobson: proceso
Objectory
Objectory
Tambin conocido como RUP: Rational
Unified Process
Proceso Unificado
Es un proceso de desarrollo de software
Dirigido por casos de uso Dirigido por casos de uso
Centrado en la arquitectura Centrado en la arquitectura
Iterativo e incremental Iterativo e incremental
Utiliza UML para definir los modelos del sistema software
El sistema software en construccin estformado por
componentes componentes software software
interconectados a trav interconectados a trav s de s de interfaces interfaces
Proceso de
desarrollo de
software
Requisitos
de usuario
Sistema
software
Los requisitos cambian
y el sistema software evoluciona
Proceso Unificado
Elaboration Construction Transition Inception
Phases
Requirements Capture
Analysis &Design
Implementation
Test
Management
Environment
Deployment
Process Components
Supporting Components
Iterations
preliminary
iteration(s)
iter.
#1
iter.
#2
iter.
#n
iter.
#n+1
iter.
#n+2
iter.
#m
iter.
#m+1
Organi zati on
along content
Organization along t ime
Extreme Programming (XP)
Modelo de proceso de Kent Beck
Un modo ligero, eficiente, de bajo riesgo, flexible,
Un modo ligero, eficiente, de bajo riesgo, flexible,
predecible, cient
predecible, cient

fico y divertido de producir software

fico y divertido de producir software
Caractersticas

Alta visibilidad debido a ciclos muy cortos
Alta visibilidad debido a ciclos muy cortos

Planificaci
Planificaci

n incremental
n incremental

Se adapta a cambios de negocio
Se adapta a cambios de negocio
Extreme Programming (XP)
Basado en pruebas automatizadas escritas por
desarrolladores y clientes (test-driven)
Alta comunicacin
Diseo evolutivo
Colaboracin 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
atpica
Actividades en XP
Prueba Evaluacin Diseo
Codificacin
Extreme Programming (XP)
Las cuatro actividades estn soportadas por doce prcticas:
El juego de planificaci El juego de planificaci n n
Peque Peque as entregas as entregas
Met Met fora fora
Dise Dise o simple o simple
Prueba Prueba
Refactoring Refactoring
Programaci Programaci n en pareja n en pareja
Propiedad colectiva Propiedad colectiva
Integraci Integraci n continua n continua
Semana de cuarenta horas Semana de cuarenta horas
Cliente en el lugar de desarrollo Cliente en el lugar de desarrollo
Codificaci Codificaci n est n est ndar ndar
Extreme Programming (XP)
Ventajas:

Bueno para especificaciones cambiantes
Bueno para especificaciones cambiantes

Fundamentaci
Fundamentaci

n pr
n pr

ctica
ctica
Inconvenientes:

Poco probado
Poco probado

Poco compatible con especificaciones/dise
Poco compatible con especificaciones/dise

os
os
totales
totales

S
S

lo funciona con equipos peque

lo funciona con equipos peque

os (hasta diez
os (hasta diez
personas)
personas)
Extreme Programming (XP)
Diferencias fundamentales (hay ms que ya se
vern)

No hay requisitos expl
No hay requisitos expl

citos sino que el cliente

citos sino que el cliente
participa en el desarrollo
participa en el desarrollo

Se empieza por automatizar las pruebas
Se empieza por automatizar las pruebas

Se desarrolla siempre la versi
Se desarrolla siempre la versi

n m
n m

s simple posible
s simple posible
que resuelva el problema
que resuelva el problema

Se ejecutan todas las pruebas todos los d
Se ejecutan todas las pruebas todos los d

as
as

Se cambia el dise
Se cambia el dise

o (aunque sea radicalmente)

o (aunque sea radicalmente)
siempre que haga falta
siempre que haga falta
Calidad del proceso de software
Cmo medir la calidad del
proceso de software de una
empresa ?
La empresa ideal
El Dpto. de la Defensa de los US fundel Software
EngineeringInstitute(SEI) asociado con la
Universidad de Carnegie Mellon(CMU).
Desarrollan el Software CapabilityMaturityModel
(SW CMM) a mediados de 1980s, refinado en los
inicios de l990s.
Este modelo define una serie de reas clave de
proceso (ACP)

Un
Un

rea clave de proceso es, b

rea clave de proceso es, b

sicamente, una actividad de

sicamente, una actividad de
IS
IS
Software Capability Maturity Model
Level 3
Defined
Level 2
Repeatable
Level 1
Initial
Level 4
Managed
Level 5
Optimizing
reas clave del proceso
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 i o n
S o f t w a re q u a l i t y m a n a g em e n t
Q u a nt i t a t i v e p r o ce s s m a n a g em e n t
P e e r r e v i e w s
I n t e r g ro u p c o o r d i n at i o n
S o f t w a r e p r o d u ct e n g i n e e r i n g
I n t e g r a t e d s o f t w ar e m a n a g e m e n t
T r a i n i n g p r o g r a m m e
O r g a n i z a t i o n p r oc e s s d e f i n i t i o n
O r g a n i z a t i o n p r oc e s s f o c u s
S o f t w a r e c o n f i g u ra t i o n m a n a g em e n t
S o f t w a r e q u a l i t y a s s u r a n c e
S o f t w a r e s u b c o n t r a c t m a n a g em e n t
S o f t w a r e p ro j e c t t r a c k i n g a n d o v e r s i g h t
S o f t w a r e p ro j e c t p l a n n i n g
R e q u i r e m e n t s m a n a g e m e n t
I n i t i a l
R e p e a t a b l e
D e f i n e d
M a n a g ed
O p t i m i zi n g
Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31.
CMM
Los niveles son acumulativos
Nivel 1: Inicial

El proceso de software se caracteriza seg
El proceso de software se caracteriza seg

n el caso
n el caso

Se definen poco procesos
Se definen poco procesos

El
El

xito depende del esfuerzo individual

xito depende del esfuerzo individual
CMM
Nivel 2: Repetible

Se incluye seguimiento del coste, la planificaci
Se incluye seguimiento del coste, la planificaci

n y la
n y la
funcionalidad
funcionalidad

Se repiten t
Se repiten t

cnicas de proyectos anteriores con buenos

cnicas de proyectos anteriores con buenos
resultados
resultados

Las ACP son:
Las ACP son:
Planificacin del proyecto de software
Seguimiento y supervisin del proyecto de software
Gestin de requisitos
Gestin de la configuracin software (GCS)
Garanta de calidad del software (SQA)
Gestin de la subcontratacin
CMM
Nivel 3: Definido

Nivel 2
Nivel 2

Las actividades se documentan, estandarizan e integran en
Las actividades se documentan, estandarizan e integran en
un proceso a nivel organizaci
un proceso a nivel organizaci

n
n

Existe un proceso documentado
Existe un proceso documentado

Las ACP son:
Las ACP son:
Definicin y enfoque del proceso de la organizacin
Programa de formacin
Revisiones peridicas
Coordinacin entre grupos
Ingeniera de productos software
Gestin de integracin del software
CMM
Nivel 4: Gestionado

Nivel 3
Nivel 3

Se recopilan medidas del proceso del software y de
Se recopilan medidas del proceso del software y de
la calidad del producto
la calidad del producto

Estas medidas sirven para gestionar el proceso
Estas medidas sirven para gestionar el proceso

Las ACP son:
Las ACP son:
Gestin de la calidad del software
Gestin cuantitativa del software
CMM
Nivel 5: Optimizacin

Nivel 4
Nivel 4

En base a la experiencia y m
En base a la experiencia y m

tricas se optimiza el
tricas se optimiza el
proceso
proceso

Las ACP son:
Las ACP son:
Gestin de cambios del proceso
Gestin de cambios de tecnologa
Prevencin de defectos
CMM
Un nivel razonable es el definido (nivel 3)
Un nivel deseable es optimizacin (nivel 5)
Con independencia del CMM, ACPsmnimas:

Planificaci
Planificaci

n del proyecto
n del proyecto

Seguimiento y supervisi
Seguimiento y supervisi

n del proyecto
n del proyecto

Gesti
Gesti

n de requisitos
n de requisitos

GCS
GCS

SQA
SQA

Definici
Definici

n del proceso
n del proceso

Revisiones peri
Revisiones peri

dicas
dicas

Coordinaci
Coordinaci

n entre grupos
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
Modelos de proceso
Pressman 17-46, Sommerville 42-67

Proceso Unificado
Proceso Unificado
J acobson, Krutchen

SW CMM
SW CMM
Pressman Cap. 2, Sommerville Cap. 25
http://www.sei.cmu.edu/cmm/obtain.cmm.html

Material
Material
Pablo Gervs
J uan Pavn y J orge Gmez
Natalia J uristo