Curso de Métricas Del Software y Métodos Ágiles

Curso de Mtricas
del Software y
Mtodos giles
Mgr. Artidoro Velapatio Castilla
Moquegua, Ilo, Tacna mayo-junio del 2010
Curso de
Actualizacin
en Informtica
06/02/2013
UPJCM - Curso de Mtricas del
Software - A. Velapatio C. 2
Contenido
4El proceso
4Gestin de proyectos
4Mtricas del software

06/02/2013
El Proceso
06/02/2013
Frases
Los ingenieros de software no son
precisamente buenos programadores
Los fsicos son esperados para ampliar
nuestros conocimientos, mientras que los
ingenieros de software son esperados para
desarrollar productos o tcnicas para la
produccin de software. Cada carrera atrae
distintos tipos de estudiantes. La mayora
de estudiantes elige Ingeniera de Software
porque les gusta construir las cosas
[Parnas]
06/02/2013
El Proceso Software
4Un conjunto estructurado de actividades y resultados que
conducen a la creacin de un producto de software, que
cubre las fases:
Especificacin: Definir la funcionalidad y las restricciones
en sus operaciones.
Diseo e implementacin: Producir software que cumple
la especificacin.
Validacin: Asegurar que hace lo que el cliente desea.
Evolucin: Seguir cumpliendo los cambios en las
necesidades del usuario.
06/02/2013
El Proceso Software
Marco de trabajo
Actividades del marco de trabajo
Actividades del marco de trabajo
Tareas
Hitos, entregas
Puntos SQA
06/02/2013
Modelos del proceso de
software
4Qu es un modelo de proceso de
software?
Una representacin simplificada de un proceso de
software presentada desde un punto de vista
especfico (una abstraccin de un proceso real).
Incluye
+ Actividades que son partes del proceso.
+ Productos que deben obtenerse.
+ Papel del personal involucrado.
06/02/2013
Modelos de procesos
genricos
4No son descripciones exhaustivas de los
procesos de software.
4Son abstracciones tiles que explican
diferentes enfoques utilizables a la hora de
desarrollar el software.
4Son marcos de trabajo del proceso, no
detallan las actividades especficas.
4Se denominan paradigmas del proceso.
06/02/2013
Paradigmas de procesos de
desarrollo de sistemas
4Existen actualmente diversos modelos de
desarrollo de sistemas de software, que podemos
dividir en 2 grandes grupos:
Los mtodos ortodoxos o clsicos:
Comienzan con el anlisis completo de los
requerimientos. Despus de interaccin con
clientes y usuarios se establecen
requerimientos funcionales y no funcionales. En
el diseo se define la arquitectura del sistema.
Luego los programadores implementan el
diseo y finalmente el sistema se prueba y se
entrega. Todos estos modelos tienen sus
fortalezas y debilidades.
06/02/2013
Paradigmas de procesos de
desarrollo de sistemas
Los mtodos heterodoxos o giles: Son
estrategias de desarrollo de software que
promueven prcticas que son adaptativas en
vez de predictivas, centradas en la gente o en
los equipos, iterativas, orientadas hacia
prestaciones y hacia la entrega, de
comunicacin intensiva con el cliente, y que
requieren que el negocio se involucre en forma
directa.
Estos mtodos han sido planteados y
desarrollados recientemente.
06/02/2013
Paradigmas de desarrollo
de software clsicos
Mtodos ortodoxos o clsicos:
+Modelo Code & Fix.
+Modelo lineal secuencial
+Modelo de construccin de prototipos
+Modelos evolutivos:
Modelo incremental
Modelo en espiral
Modelo WinWin
Modelo de desarrollo concurrente
Modelo de desarrollo basado en componentes
Proceso Unificado de Desarrollo de Software
+Modelo de mtodos formales
+Tcnicas de 4ta. Generacin.
+Modelo DRA (Desarrollo Rpido de Aplicaciones).
+Mtrica V3.

06/02/2013
de software giles
Mtodos heterodoxos giles
+eXtreme Programing (XP).
+Scrum
+Evo
+Crystal Methods
+Feature Driven Development
+RUP
+Dynamic Systems Development Methods
+Adaptative Software Development
+Agile Modeling
+Lean Development y Lean Software Development
+Microsoft Solutions Framework
+Open Source
+

06/02/2013
Modelos
Clsicos
06/02/2013
Modelos Clsicos
4 Los modelos ortodoxos clsicos:
Modelo Code & Fix
Modelo lineal secuencial
Modelo de construccin de prototipos
Modelos evolutivos:
Modelo incremental
Modelo en espiral
Modelo WinWin
Modelo de desarrollo basado en componentes
Proceso Unificado de Desarrollo
Modelo de mtodos formales
Tcnicas de cuarta generacin (T4G)
Modelo DRA (Desarrollo Rpido de Aplicaciones)
Mtrica V3

06/02/2013
Modelo Code & Fix
4Usado en los comienzos de la computacin, cuando
sta era una actividad personal y artesanal.
4Constaba de 2 etapas:
Codificar.
Eliminar errores en el cdigo.
4Era fuente de dificultades y deficiencias:
Luego de una secuencia de cambios, el cdigo era
tan enredado, que eliminar errores era una tarea
pesada y muy difcil de realizar.
Cuando el desarrollo de sistemas dej de ser una
actividad personal y artesanal, el modelo no poda
manejar la complejidad de los sistemas.
No aceptaba la rotacin de personal en un
proyecto.
06/02/2013
Modelo Code & Fix
06/02/2013
4Llamado tambin Ciclo de vida clsico
o Modelo en cascada.
4Tiene 5 fases:
Anlisis de requisitos.
Diseo
Generacin de cdigo.
Pruebas
Mantenimiento.
4Una fase no comienza hasta que se hayan
terminado las anteriores.
06/02/2013
Anlisis de
requisitos
Diseo
Cdigo
Pruebas
Mantenimiento
El cliente no
interviene en
el proyecto!!
06/02/2013
Problemas del modelo
lineal secuencial
4 Inflexibilidad al dividir el proyecto en estas fases. No se
puede pasar a la fase siguiente hasta finalizar una fase.
4 Los proyectos raramente siguen un flujo secuencial.
4 Los requerimientos son difciles de definir al principio del
proceso.
4 Los errores se detectan en forma tarda.
4 Es difcil responder a los cambios en los requisitos de los
usuarios.
4 El programa se mantiene por parchado, es decir
actualizaciones a la versin original.
4 Este modelo solo es apropiado cuando se conocen bien los
requisitos.
4 El mantenimiento se realiza en el cdigo fuente.
4 El cliente no interviene en el desarrollo del proyecto.
06/02/2013
Reivindicacin del modelo
de cascada
4 Ha habido una injusticia histrica con Winston Royce y su
modelo en cascada: en su versin original, como se ve en
la imagen, era claramente iterativo. Por alguna razn pas
a la posteridad como la encarnacin de una metodologa
secuencial.
06/02/2013
Modelo de construccin
de prototipos
4 Un prototipo es un sistema que sirve para probar ideas y
suposiciones que se tiene sobre un sistema. Permite
entradas, procesamiento y salida de informacin. Es decir es
la primera versin del sistema. El modelo de construccin
de prototipos fue inicialmente planteado por Brooks en
1975.
4 El modelo de construccin de prototipos tiene 5 fases:
Recoleccin de requisitos.
Diseo rpido.
Construccin del prototipo.
Evaluacin del cliente.
Refinamiento del prototipo
4 Se produce un proceso iterativo, en que el prototipo es
afinado hasta satisfacer los requerimientos del sistema, a la
vez que sirve para facilitar a los desarrolladores del sistema
una mejor comprensin de lo que se debe hacer.
06/02/2013
Modelo de construccin
de protipos
Recoleccin
de requisitos
Diseo rpido
Construccin
del prototipo
Evaluacin
del cliente
Refinamiento del
prototipo
Comunicacin
permanente con
el cliente!!
06/02/2013
Problemas de la
construccin de prototipos
4El cliente no comprende lo que significa la
primera versin de un prototipo (una
armazn de plastilina y alambres). Al
enterarse que se va reconstruir cree que con
algunos ajustes puede obtenerse el producto
final y va a querer agregar funciones no
previstas para aprovechar la oportunidad.
4El desarrollador asume algunos compromisos
para que el prototipo funcione y a veces elige
herramientas inadecuadas que ms tarde
pasan a formar parte del sistema.
06/02/2013
Modelos evolutivos
4 El software, como todo sistema complejo, evoluciona
con el tiempo.
4 Los requisitos del sistema cambian a menudo,
haciendo que el camino al producto final no sea real.
4 Las estrictas fechas tope del mercado hacen que sea
imposible finalizar un sistema completo, por lo que
debe entregarse una versin limitada para cumplir con
la presin competitiva.
4 Se comprende perfectamente el conjunto de
requisitos de productos centrales o del sistema, pero
todava se tienen que definir los detalles de
extensiones del sistema.
4 Estas razones llevaron a plantear los modelos
evolutivos que tratan de contrarrestar estos
problemas.
06/02/2013
Modelos evolutivos
4 Propuestos originalmente por Boehm.
4 Combinan la naturaleza iterativa de la construccin de
prototipos con los aspectos controlados y sistemticos
del modelo lineal secuencial.
4 Primeras iteraciones: modelo en papel o prototipo.
4 Ultimas iteraciones: versin ms completa de la
aplicacin.
4 Cada entrega es ms completa que la anterior hasta
llegar al producto final.
4 Se adaptan ms fcilmente a los cambios introducidos
a lo largo del desarrollo.
06/02/2013
Modelos evolutivos
06/02/2013
Modelo incremental
4 Propuesto por Mills en 1980.
4 Combina elementos del modelo lineal secuencial
(aplicados repetidamente) con la filosofa interactiva de
construccin de prototipos.
4 Cada secuencia lineal produce un incremento del
software.
4 Es iterativo por su propia naturaleza.
4 Prioriza los requisitos del usuario y los requisitos de ms
alta prioridad se incluyen en los incrementos ms
tempranos.
4 Las primeras versiones son incompletas pero
proporcionan al usuario la funcionalidad que precisa y
una plataforma para la evaluacin.

06/02/2013
Anlisis
Modelo incremental
Diseo Cdigo Prueba
Entrega del 1
incremento
Anlisis Diseo Cdigo Prueba
Entrega del 2
incremento
Entrega del 3
incremento
Entrega del 4
incremento
INCREMENTO 1
INCREMENTO 2
INCREMENTO 3
INCREMENTO 4
Ingeniera de
Sistemas
06/02/2013
Problemas del Modelo incremental
4 Difcil de evaluar el costo total.
4 Difcil de aplicar a sistemas transaccionales que
tienden a ser integrados y a funcionar como un
todo.
4 Requiere gestores experimentados.
4 Los errores en los requisitos se detectan tarde.
4 Prioriza los requisitos del usuario y los requisitos
de ms alta prioridad se incluyen en los
incrementos ms tempranos.
4 Las primeras versiones son incompletas pero
proporcionan al usuario la funcionalidad que
precisa y una plataforma para la evaluacin.
06/02/2013
Modelo en espiral
4 Propuesto por Boehm en 1988.
4 El proceso se representa como una espiral. Cada vuelta en
la espiral representa una fase en el proceso.
4 Combina la naturaleza iterativa de la construccin de
prototipos con los aspectos controlados y sistemticos del
modelo lineal secuencial.
4 No hay fases fijas como la especificacin y diseo. Cada
vuelta determina las actividades a realizar.
4 El radio del espiral marca el costo acumulado en el
proceso, mientas que la dimensin angular representa el
progreso dentro del proceso.
4 Las primeras iteraciones son prototipos y las ltimas
iteraciones presentan versiones cada vez mas completas
del sistema.

06/02/2013
Modelo en espiral
4 Las regiones de tareas son:
Comunicacin con el cliente: tareas requeridas para
establecer comunicacin entre el desarrollador y el cliente.
Planificacin: tareas requeridas para definir recursos, el tiempo
y otra informacin relacionada con el proyecto.
Anlisis de riesgos: tareas requeridas para evaluar riesgos
tcnicos y de gestin.
Ingeniera: tareas requeridas para construir una o ms
representaciones de la aplicacin.
Construccin y adaptacin: tareas requeridas para construir,
probar, instalar y proporcionar soporte al usuario.
Evaluacin del cliente: tareas requeridas para obtener la
reaccin del cliente segn la evaluacin de las representaciones
del software creadas durante la etapa de ingeniera e instaladas
durante la instalacin.

06/02/2013
Modelo en espiral
Planificacin
Anlisis de
riesgos
Ingeniera
Construccin y
adaptacin
Evaluacin del
cliente
Comunicacin
con el cliente
Producto
Final
06/02/2013
Problemas del Modelo
en espiral
4 Puede resultar difcil convencer a grandes
clientes de que el enfoque evolutivo es
controlable.
4 Requiere de una considerable habilidad para
evaluar un riesgo, esto es un buen
asesoramiento de especialistas.
4 Si un riesgo importante no es detectado y
gestionado a tiempo, indudablemente surgirn
problemas.
4 Todava es un modelo de cuya eficacia no hay
aun certeza absoluta.
06/02/2013
Modelo en espiral WINWIN
4 La comunicacin entre el cliente y el desarrollador casi nunca
termina con los requisitos definidos. Las mejores
negociaciones se esfuerzan en obtener Victoria-Victoria.
Eso significa que el cliente obtiene lo que necesita y el
desarrollador gana para conseguir presupuestos y una fecha
de entrega razonable.
4 El modelo en espiral WINWIN define un conjunto de
actividades de negociacin al principio de cada paso
alrededor de la espiral.
4 Se definen las siguientes actividades:
Identificacin del sistema o subsistemas claves de los
directivos.
Determinacin de las condiciones de victoria de los
directivos.
Negociacin de las condiciones de victoria de los
directivos, para reunirlas en un conjunto de condiciones
Victoria-victoria para todos los afectados

06/02/2013
Modelo en espiral WINWIN
2. Identificar las
condiciones de
victoria de los
directivos
3a. Reunir las
condiciones de victoria.
3b. Establecer los
objetivos, restricciones
y alternativas del
siguiente nivel.
4. Evaluar las
alternativas del
producto y del proceso
y resolucin de
riesgos.
5. Definir el siguiente
nivel del producto y del
proceso incluyendo
particiones.
6. Validar las
definiciones del
producto y del proceso
1. Identificar el
siguiente nivel para
los directivos
7. Revisin y
comentarios.
06/02/2013
Modelo de desarrollo
concurrente
4 Los gestores de proyecto que verifican el estado del
proyectos en trminos de fases principales (ciclo de vida
clsico) no saben cul es el estado actual del proyecto.
4 El modelo de desarrollo concurrente puede ser
presentado esquemticamente como un conjunto de
actividades, tareas y estados asociados. Fue planteado
por Davis y Sitaram en 1994. Diversas actividades
pueden ocurrir concurrentemente.
4 Es un modelo cclico con anlisis de estado.
4 Este modelo es aplicable a todo tipo de desarrollo de
software y proporciona una imagen acertada del estado
actual de los eventos.
4 Es adecuado para los sistemas Cliente / Servidor. Es
fcil de modificar. Posibilita el conocimiento del estado
del proyecto.
06/02/2013
Bajo
desarrollo
Bajo revisin
Bajo
modificacin
En lnea base
Retirada
Cambios en
espera
Representa un estado
de una actividad de
ingeniera de software
Actividad de
anlisis
Ninguna
Representacin
esquemtica de
la actividad de
anlisis en el
modelo
concurrente
06/02/2013
Modelo basado en componentes
4 El modelo de ensamblado de componentes incorpora varias
caractersticas del desarrollo en espiral.
4 Es evolutivo y tiene una aproximacin iterativa para la
creacin del software.
4 Est relacionada con la tecnologa orientada a objetos y
construye aplicaciones a travs de componentes de
software reutilizables.
4 La actividad de ingeniera empieza con la identificacin de los
componentes candidatas, es decir la informacin que va a ser
manipulada y los algoritmos que sern aplicados para
manipular.
4 Los componentes se almacenan en libreras o repositorios.
Cuando los componentes son identificados se buscan en las
libreras, si existen se los reutiliza y si no se los crea.
4 Conduce a la reutilizacin de cdigo lo que trae beneficios,
como la reduccin del 70% en el ciclo de desarrollo y un
reduccin de costos del 84%.
06/02/2013
Modelo basado en componentes
Planeacin

Construccin y
adaptacin de
la ingeniera

Anlisis
de riesgos
Buscar
componentes
en biblioteca
Extraer
componentes
si estn
disponibles
Crear componentes
si no estn
disponibles
Construir la
iteracin del
sistema
Poner nuevos
componentes en
la biblioteca
Identificar
componentes
candidatas
Evaluacin
del cliente
Comunicacin
con el cliente
06/02/2013
Planeacin

Ingeniera
Construccin y
rediseo

Anlisis
de riesgos
Buscando
clases en
libreras
Extrayendo
clases
si estn
disponibles
Ingeniera si las
clases no
disponibles
Construyendo
n - sima
versin del
sistema
Agregar
clase a las
libreras
Identificando
clases candidatas
Evaluacin
del cliente
Comunicacin
con el cliente
Modelo orientado a objetos
Anlisis OO
Diseo OO
CodificacinOO
Pruebas OO
06/02/2013
Proceso Unificado de
Desarrollo de Software
4 El Proceso unificado de desarrollo de
software define Quin debe hacer Qu,
Cundo y Cmo debe hacerlo.

4 No existe un proceso de software universal.
Las caractersticas de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso
sea configurable
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
06/02/2013
El Proceso Unificado de
Desarrollo del Software
4 El PUDS es un marco de trabajo genrico que puede
especializarse para una gran variedad de sistemas software,
a diferentes reas de aplicacin, diferentes tipos de
organizaciones, diferentes tipos de aptitud y diferentes
tamao de proyecto.
4 El PUDS est basado en componentes, lo que significa que
el sistema software en construccin est formado por
componentes software interconectados a travs de
interfaces. Un componente es un elemento del software
con funcin y limites claros.
4 El PUDS utiliza el UML (Lenguaje de Modelamiento
Unificado) para preparar todo los esquemas de un sistema
software. UML es parte esencial del PUDS (Sus desarrollos
fueron paralelos).
06/02/2013
PUDS: Fases
4 Inicio: Se define el mbito y objetivos del proyecto y se
definen las funcionalidades del producto.
4 Elaboracin: Se planifica el proyecto, con los recursos
disponibles y se define la arquitectura bsica y el
diseo inicial.
4 Construccin: Se implementa el producto en base a
iteraciones incrementales. Se refina la arquitectura.
Gran parte del trabajo es programacin y pruebas. Se
documenta tanto el sistema como el manejo del mismo.
4 Transicin: Se entrega el producto a los usuarios (por
ejemplo: productos beta). Se incluyen tareas de
marketing, empaquetado atractivo, instalacin,
configuracin, entrenamiento, soporte, mantenimiento,
etc. Los manuales de usuario se completan y refinan
con la informacin anterior.
06/02/2013
4 El ciclo de vida iterativo se basa en la
evolucin de prototipos ejecutables que se
muestran a los usuarios y clientes.
4 Las iteraciones hacen referencia a flujos de
trabajo y los incrementos al crecimiento al
producto. Para una efectividad mxima las
iteraciones deben estar controladas, es
decir, deben determinarse y ejecutarse
planificadamente.
PUDS: Proceso
Iterativo e Incremental
06/02/2013
PUDS: Dos dimensiones
06/02/2013
PUDS: Fases e Hitos
06/02/2013
4 Fases, iteraciones
4 Flujos del proceso:
Actividades
Pasos
4 Artefactos:
Actividades
Modelos
Documentos
4 Trabajadores:
Ingeniero
PUDS: Conceptos claves
Cundo tienen lugar?
Qu hay que hacer?
Qu se produce?
Quin lo hace?
06/02/2013
Modelo de mtodos formales
4 El modelo de mtodos formales incluye una serie de
actividades que conducen a la especificacin
matemtica del software.
4 Permiten al ingeniero de software especificar, desarrollar
y verificar un sistema basado en computadora aplicando
una notacin matemtica rigurosa.
4 Se pueden eliminar muchos de los errores que se
afrontan con dificultad con los otros modelos.
4 La ambigedad, inconsistencia y la falta de conclusin
son detectadas ms fcilmente con el anlisis
matemtico.
4 Permiten al desarrollador detectar errores que de otra
manera no lo seran. Promete software libre de errores
06/02/2013
Los 10 Mandamientos de los
mtodos formales
1. Seleccionars la notacin adecuada.
2. Formalizars, pero no demasiado.
3. Estimars los costos.
4. Poseers un experto en mtodos
formales a tu disposicin.
5. No abandonars tus mtodos formales.
6. Documentars suficientemente.
7. No comprometers estndares de
calidad.
8. No sers dogmtico.
9. Comprobars, comprobars y volvers a
comprobar.
10. Reutilizars cuanto puedas.
06/02/2013
Problemas de los
mtodos formales
4El desarrollo de un modelo formal
consume mucho tiempo.
4Se debe capacitar a los desarrolladores,
pues la mayora no estn entrenados en
mtodos formales.
4 Es difcil usar los modelos como
herramientas de comunicacin con los
consumidores que no estn tcnicamente
calificados.
06/02/2013
Tcnicas de cuarta
generacin (T4G)
4 Consiste en la utilizacin de una amplia gama de
herramientas que mediante la especificacin de algunas
caractersticas del software a alto nivel, generan cdigo
utilizable para crear aplicaciones.
4 A ms alto nivel de especificacin, ms rpido desarrollo
de la aplicacin.
4 Actualmente hay viabilidad para el desarrollo de
aplicaciones en ciertas reas.
4 El tiempo de desarrollo se reduce para aplicaciones
pequeas o intermedias.
4 Puede combinarse con el modelo de componentes y con
los otros modelos
06/02/2013
Tcnicas de cuarta
generacin (T4G)
4Herramientas:
Lenguajes no procidementales para
consultas de bases de datos.
Generacin de reportes.
Manipulacin de datos.
Definicin e interaccin de pantallas.
Generacin de cdigo.
06/02/2013
Recopilacin de
requisitos
Tcnicas de cuarta
generacin (T4G)
Estrategia de
diseo
Implementacin
en 4LG
Prueba
Herramientas
CASE
Prototipo
operativo
06/02/2013
Problemas de cuarta
generacin (T4G)
4A ms alto nivel de especificacin, menos
capacidad de especializacin del software.
4Si se usan para grandes aplicaciones se
necesita mucho ms anlisis, diseo y
pruebas para lograr el ahorro de tiempo
como resultado de la eliminacin de la
etapa de codificacin.
06/02/2013
Modelo DRA (Desarrollo
Rpido de Aplicaciones)
4 El DRA es un modelo lineal secuencial que enfatiza un
ciclo de desarrollo extremadamente corto. Originalmente
planteado por James Martin (1991) y desarrollado por
Kerr /Hunter (1994) y Steve McConnell (1996).
4 Es una adaptacin de alta velocidad del modelo
secuencial, que puede lograrse usando una
construccin basada en componentes.
4 Si se conoce bien los requisitos y se delimita el mbito
puede lograrse un sistema altamente funcional en un
plazo de 60 a 90 das.
4 Tiene las siguientes fases:
Modelado de gestin: Qu informacin conduce al proceso de
gestin?Que informacin se genera?Quin la genera?Dnde
va?Quin la procesa?
Modelado de datos: Se definen los atributos de los objetos y
las relaciones entre objetos.
06/02/2013
Modelo DRA (Desarrollo
Rpido de Aplicaciones)
Modelado del proceso: Las descripciones del proceso se
crean para aadir, modificar, suprimir o recuperar un
objeto de datos.
Generacin de aplicaciones: El DRA asume tcnicas de
cuarta generacin y hace uso de la reutilizacin de
componentes.
Pruebas y entrega: Como el DRA usa la reutilizacin, ya
se han probado muchas componentes. Esto reduce el
tiempo.
4 Si cada una de las funciones principales puede
completarse en menos de 3 meses, puede aplicarse
el DRA y c/u de las funciones puede afrontarse por
un equipo DRA y luego integrarse en un solo
conjunto.

06/02/2013
Modelado
de gestin
Modelado de
datos
Modelado de
procesos
Generacin de
aplicaciones
Pruebas y
entrega
Modelo DRA (Desarrollo Rpido
de Aplicaciones)
EQUIPO 1
Modelado de
gestin
Modelado
de datos
Modelado de
procesos
Generacin de
aplicaciones
Pruebas y
entrega
EQUIPO 2
Modelado
de gestin
Modelado
de datos
Modelado de
procesos
Generacin de
aplicaciones
Pruebas y
entrega
EQUIPO 3
60 a 90 das
06/02/2013
DRA: Los 4 pilares del DRA
06/02/2013
DRA: Mtodos orientados a
la Planificacin
4 Mtodos que mejoran la velocidad de desarrollo,
permitiendo entregar antes el software.
4 Mtodos que reducen el riesgo en la planificacin,
permitiendo evitar grandes retrasos de planificacin.
4 Mtodos que hacen visible el progreso, permitiendo disipar
la impresin de tener un desarrollo lento.
06/02/2013
DRA: Errores clsicos
4 Errores relacionados con las personas:
1. Motivacin dbil.
2. Personal mediocre.
3. Empleados problemticos incontrolables.
4. Hazaas.
5. Aadir ms personal a un proyecto retrasado.
6. Oficinas repletas y ruidosas.
7. Fricciones entre los clientes y desarrolladores.
8. Expectativas poco realistas.
9. Falta de un promotor efectivo.
10. Falta de participacin de los implicados.
11. Falta de participacin del usuario.
12. Poltica antes que desarrollo.
13. Ilusiones
06/02/2013
4 Errores relacionados con el proceso:
14. Planificacin excesivamente optimista.
15. Gestin de riesgos insuficiente.
16. Fallas de los contratados.
17. Planificacin insuficiente.
18. Abandono de la planificacin por presin.
19. Prdida de tiempo en el inicio difuso.
20. Escatimar en las actividades iniciales.
21. Diseo inadecuado.
22. Escatimar en el control de calidad.
23. Control insuficiente de la directiva.
24. Convergencia prematura o excesivamente frecuente.
25. Omitir tareas necesarias en la estimacin.
26. Planificar ponerse al da ms adelante.
27. Programacin a destajo.
06/02/2013
4 Errores relacionados con el producto:
28. Exceso de requerimientos.
29. Cambio de prestaciones.
30. Desarrolladores meticulosos.
31. Tiras y aflojas en la negociacin.
32. Desarrollo orientado a la investigacin.
4 Errores relacionados con la tecnologa:
33. Sndrome de la panacea.
34. Sobreestimacin de las ventajas del empleo de nuevas
herramientas o mtodos.
35. Cambio de herramientas a mitad del proyecto.
36. Falta de control automtico del cdigo fuente.
06/02/2013
06/02/2013
DRA: Bases de Desarrollo
4 Bases de Gestin
Los fundamento de gestin consiste en determinar
el tamao del producto, asignar los recursos
adecuados, crear un plan para aplicar esos
recursos y luego controlar los recursos para que no
se desven del plan.
4 Bases Tcnicas
Los bases tcnicas tienen que ver con la gestin
de requerimientos (mtodos para el anlisis,
mtodos para crear modelos, mtodos de
comunicacin, relacin entre la gestin y
requerimientos y los paradigmas de desarrollo del
software, diseo (conceptos, mtodos,
herramientas), construccin (mtodos, lenguajes),
gestin de configuracin del software.

06/02/2013
4 Bases de Control de Calidad
Los bases de control de calidad, proporcionan
un apoyo fundamental para obtener la mxima
velocidad de desarrollo. Un producto con
demasiado errores ocupa ms tiempo en
corregir que escribir el cdigo. Las pruebas,
depuraciones y revisin tcnicas permiten
minimizar los errores.
4 Seguir las instrucciones
Los proyectos software fallan simplemente
porque los programadores no siguen las
instrucciones, las bases de desarrollo.

06/02/2013
06/02/2013
DRA: Gestin de riesgos
4 La funcin de la gestin de riesgos del software es
identificar, estudiar y eliminar las fuentes del riesgo
antes de que empiecen a amenazar la finalizacin
satisfactoria de un proyecto de software.
06/02/2013
DRA: Desarrollo orientado
hacia el mejor Plan
06/02/2013
Problemas del modelo DRA
4 Para proyectos grandes el DRA requiere de recursos
humanos.
4 DRA requiere de clientes y desarrolladores
comprometidos en las rpidas actividades necesarias.
4 No todos los tipos de aplicaciones son apropiadas
para el DRA. Sin un sistema no puede modularizarse
adecuadamente la construccin de componentes
puede fracasar.
4 Los errores se detectan al final, en las pruebas, y se
resuelve con actualizaciones, al ser modelo lineal.
4 DRA no es adecuado cuando los riesgos tecnolgicos
son altos.
06/02/2013
Mtrica Versin 3
MTRICA versin 3 puede ser utilizada
libremente con la nica restriccin de citar la
fuente de su propiedad intelectual, es decir, el
Ministerio de Administraciones Pblicas de
Espaa.

06/02/2013
Mtrica Versin 3
Mtrica V3 presenta una nica estructura que
cubre distintos tipos de desarrollo de sistemas
como el estructurado y el orientado a objetos y
facilita a travs de las interfaces la realizacin de
procesos de apoyo y organizativos.
Mtrica V3 tiene una estructura de 3 niveles:
Cada proceso detalla actividades
Cada actividad implica tareas
Para cada tarea se indican:
+Las tcnicas y prcticas a aplicar.
+Los responsables de realizarlas.
+Sus productos de entrada y salida.
06/02/2013
Mtrica Versin 3: Objetivos
La metodologa MTRICA Versin 3 ofrece a las
Organizaciones un instrumento til para la
sistematizacin de las actividades que dan soporte al
ciclo de vida del software dentro del marco que permite
alcanzar los siguientes objetivos:
Proporcionar o definir Sistemas de Informacin que ayuden a
conseguir los fines de la organizacin mediante la definicin de
un marco estratgico para el desarrollo de los mismos.
Dotar a la organizacin de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al
anlisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y
Tecnologas de la Informacin y las Comunicaciones.
Facilitar la comunicacin y entendimiento entre los distintos
participantes en la produccin de software a lo largo del ciclo de
vida del proyecto, teniendo en cuenta su papel y responsabilidad.
Facilitar la operacin, mantenimiento y uso de los productos
software obtenidos.

06/02/2013
Mtrica Versin 3
Elementos fundamentales
Los elementos de Mtrica 3 son:
Procesos.
Interfaces.
Tcnicas y prcticas.
Roles o perfiles.

06/02/2013
Mtrica Versin 3: Procesos
Mtrica 3 est orientado a procesos.
Procesos principales de desarrollo en Mtrica 3.
Planificacin: Dirigida a obtener Sistemas de
Informacin flexibles.
Desarrollo: Que se subdivide en 5 procesos:
+Estudio de Viabilidad del Sistema (EVS).
+Anlisis del Sistema de Informacin (ASI).
+Diseo del Sistema de Informacin (DSI).
+Construccin del Sistema de Informacin (CSI).
+Implantacin y Aceptacin del Sistema (IAS).
Mantenimiento: De carcter correctivo, evolutivo
y perfectivo y ligado al proceso de desarrollo

06/02/2013
Mtrica Versin 3: Procesos
Planificacin de
Sistemas de
Informacin (PSI)
Mantenimiento de
Sistemas de
Informacin (PSI)
EVS
ASI
DSI
CSI
IAS
Desarrollo
Gestin de
Configuraciones
Aseguramiento
de Calidad
Seguridad
Gestin de
Proyectos
Interfaz
Interfaz
Interfaz
Interfaz
Aplicacin de
procedimientos
administrativos y
tcnicas durante e
ciclo de vida del
software
Actividades que
evalan la
calidad.
Realizadas por el
grupo de
aseguramiento de
calidad.
Incorporacin de
mecanismos de
seguridad en el
corazn mismo de los
sistemas de
informacin
Planificacin,
seguimiento y
control de las
actividades y
recursos.
06/02/2013
Mtrica Versin 3: Planificacin
Planificacin: Tiene como meta obtener un marco de
referencia para el desarrollo de SI que respondan a los
objetivos de la organizacin. Sus objetivos son:
Una descripcin de la situacin actual.
Un conjunto de modelos que definen la arquitectura
del sistema.
Una propuesta de proyectos a desarrollar en los
prximos aos y su prioridad.
Una propuesta de calendario para ejecutar los
proyectos.
La evaluacin de recursos necesarios para los
proyectos a desarrollar el prximo ao.
Un plan de seguimiento y control bajo una perspectiva
estratgica y operativa, o tecnolgica.

06/02/2013
Mtrica Versin 3: Planificacin
Planificacin del Sistema de Informacin:
+Esquema General de Actividades

PSI 1: Inicio
del Plan de
Sistemas de
Informacin
PSI 2:
Definicin y
Organizaci
n del PSI
PSI 3: Estado
de
Informacin
Relevante
PSI 7:
Definicin de
la
Arquitectura
Tecnolgica
PSI 8:
Definicin
del Plan de
Accin
PSI 9:
Revisin y
Aprobacin
Objetivo: Obtencin de un
marco de desarrollo del SI de
acuerdo a las expectativas de
la empresa.
PSI 5 Estudio
de los
Sistemas de
Informacin
Actuales
PSI 4:
Identificacin
de Requisitos
PSI 6: Diseo
del Modelo de
Sistema de
Informacin
06/02/2013
Mtrica Versin 3: EVS
Estudio de la Viabilidad del Sistema: Tiene como
objetivo el anlisis de un conjunto concreto de
necesidades para proponer una solucin a corto plazo
que tenga en cuentas las restricciones econmicas,
tcnicas, operativas, legales y temporales. Consta de los
siguientes puntos importantes:
La solucin obtenida puede ser la definicin de un
proyecto que afecte a los sistemas de informacin
actuales.
A partir de la situacin actual y los requisitos
planteados, se estudian las alternativas de solucin.
Se valora el impacto en la organizacin y la inversin a
realizar para cada una de las alternativas.
06/02/2013
Mtrica Versin 3: EVS
Estudio de la Viabilidad del Sistema
EVS 1:
Establecimiento
del Alcance del
Sistema
EVS 2:
Estudio de
la Situacin
Actual
EVS 4:
Estudio de
Alternativas
de Solucin
EVS 5:
Valoracin de
las
Alternativas
EVS 6:
Seleccin
de la
Solucin
Objetivo: Anlisis de un
conjunto concreto de
necesidades para proponer una
solucin a corto plazo que tenga
en cuentas las restricciones
econmicas, tcnicas, operativas,
legales y temporales.
EVS 3
Definicin de
los Requisitos
del Sistema
06/02/2013
Mtrica Versin 3: ASI
Anlisis del Sistema de Informacin: Tiene como
objetivo obtener una especificacin detallada del sistema
de informacin que satisfaga las necesidades de los
usuarios y sirve de base para el posterior diseo del
sistema.
Al cubrir Mtrica V3 tanto desarrollos estructurados y
orientados a objetos, las actividades de ambas
aproximaciones estn integradas en una estructura
comn.
La participacin activa de los usuarios es una condicin
imprescindible para el anlisis de sistemas de
informacin, ya que constituye una garanta de que los
requisitos identificados son comprendidos e incorporados
al sistema, y en consecuencia, este ser aceptado.
06/02/2013
Anlisis del Sistema de Informacin:
+Esquema General de Actividades (Anlisis Estructurado)
ASI 1:
Definicin del
Sistema
ASI 2:
Establecimiento de
Requisitos
ASI 3: Identificacin
de Subsistemas de
Anlisis
ASI 6: Elaboracin del
Modelo de Datos
ASI 7: Elaboracin del
Modelo de Productos
ASI 8: Definicin de
Interfaces de Usuario
ASI 9: Anlisis de
Consistencia
ASI 10:
Especificacin
del Plan de
Pruebas
ASI 11: Presentacin
y Aprobacin
Anlisis de Sistema
de Informacin
Objetivo: Obtencin de una
especificacin detallada del
sistema que satisfaga las
necesidades del usuario y
sirva de base para el posterior
diseo del sistema.
06/02/2013
Anlisis del Sistema de Informacin:
+Esquema General de Actividades (Anlisis Orientado a Objetos)
ASI 1:
Definicin del
Sistema
ASI 2:
Establecimiento de
Requisitos
ASI 3: Identificacin
de Subsistemas de
Anlisis
ASI 4: Anlisis de
Casos de Uso
ASI 5: Anlisis de
Clases
ASI 8: Definicin de
Interfaces de Usuario
ASI 9: Anlisis de
Consistencia
ASI 10:
Especificacin
del Plan de
Pruebas
ASI 11: Presentacin
y Aprobacin Anlisis
de Sistema de
Informacin
Objetivo: Obtencin de una
especificacin detallada del
sistema que satisfaga las
necesidades del usuario y
sirva de base para el posterior
diseo del sistema.
06/02/2013
Mtrica Versin 3: DSI
Diseo del Sistema de Informacin: Tiene
como objetivo es definir la arquitectura de
sistema y del entorno tecnolgico que le soporte
junto a la especificacin detallada de los
componentes del sistema de informacin.
A partir de esta informacin se generan:
Las especificaciones de construccin relativas
al propio sistema.
La descripcin tcnica del plan de pruebas.
La definicin de los requisitos de implantacin.
El diseo de la carga inicial y de los
procedimientos de migracin, si es necesario

06/02/2013
Mtrica Versin 3: Diseo
Diseo del Sistema de Informacin:
+Esquema General de Actividades (Diseo
Estructurado)
DSI 1: Definicin de
la Arquitectura del
Sistema
DSI 2: Diseo de la
Arquitectura de
Soporte
DSI 7:
Verificacin y
Aceptacin de la
Arquitectura del
Sistema
Objetivo: Definir la arquitectura del sistema, el
entorno tecnolgico y la especificacin detallada de
los componentes del sistema.
DSI 8: Generacin de
Especificaciones de
Construccin
DSI 9: Diseo de
Migracin y Carga
Inicial de Datos
DSI 10: Especificacin
Tcnica del Plan de
Pruebas
DSI 11: Establecimiento
de Requisitos de
Implantacin
DSI 12:
Aprobacin del
Diseo del
Sistema de
Informacin
DSI 6: Diseo Fsico
de Datos
DSI 5: Diseo de
Casos de Uso Reales
06/02/2013
Mtrica Versin 3: Diseo
Diseo del Sistema de Informacin:
+Esquema General de Actividades (Diseo Orientado a Objetos)
DSI 2: Diseo de la
Arquitectura de
Soporte
DSI 3: Diseo de
Casos de Uso Reales
DSI 7:
Verificacin y
Aceptacin de la
Arquitectura del
Sistema
Objetivo: Definir la arquitectura del sistema, el
entorno tecnolgico y la especificacin detallada de
los componentes del sistema.
DSI 8: Generacin de
Especificaciones de
Construccin
DSI 9: Diseo de
Migracin y Carga
Inicial de Datos
DSI 10: Especificacin
Tcnica del Plan de
Pruebas
DSI 11: Establecimiento
de Requisitos de
Implantacin
DSI 12:
Aprobacin del
Diseo del
Sistema de
Informacin
DSI 1: Definicin de
la Arquitectura del
Sistema
DSI 6: Diseo Fsico
de Datos
DSI 4: Diseo de
Clases
06/02/2013
Mtrica Versin 3: CSI
Construccin del Sistema de Informacin: Tiene
como objetivo generar el cdigo de loa componentes
del sistema de informacin y de todos loa
procedimientos de operacin y seguridad y de la
elaboracin de los manuales de explotacin y del
usuario final.
Adems se realizan las pruebas:
Pruebas unitarias.
Pruebas de integracin del sistema.
Pruebas del sistema.
4Asimismo se definen la formacin del usuario final, y,
si procede se construyen los procedimientos de
carga inicial y migracin de datos.

06/02/2013
Mtrica Versin 3: Construccin
Construccin del Sistema de Informacin:
Esquema General de Actividades
Objetivo:
Generar el cdigo de
los componentes,
desarrollar los
procedimientos de
operacin y
seguridad y elaborar
los manuales del
usuario final y
explotar.
CSI 5: Ejecucin
de las Pruebas
del Sistema
CSI 1:
Preparacin del
Entorno
Generacin y
Construccin
CSI 2: Generacin de
Cdigo de Componentes
y Procedimientos
CSI 3: Ejecucin
de Pruebas
Unitarias
CSI 4: Ejecucin de
Pruebas de
Integracin
CSI 6: Elaboracin
Manuales de Usuario
CSI 7: Definicin de
la Formacin de
Usuarios Finales
CSI 8: Construccin de Componentes
y Procedimientos de Migracin y
Carga Inicial de Datos
CSI 9:
Aprobacin del
del Sistema de
Informacin
06/02/2013
Mtrica Versin 3: IAS
Implantacin y Aceptacin del Sistema:
Tiene como objetivo principal la entrega y
aceptacin del sistema en su totalidad, y la
realizacin de todas las actividades
necesarias para su paso a la produccin.
Revisin de la estrategia de implantacin
determinada en el EVS.
La preparacin de la infraestructura necesaria,
la instalacin de los componentes, la
activacin de los procedimientos manuales y
automticos asociados a la migracin o carga
inicial de datos.

06/02/2013
Mtrica Versin 3: IAS
Implantacin y Aceptacin del Sistema:
Objetivo:
Entregar y
aceptar el
sistema en su
totalidad y
realizar las
actividades
necesarias para
producirlo
IAS 1:
Establecimiento
del Plan de
Implantacin
IAS 2:
Formacin
Necesaria para
la Implantacin
IAS 3 :
Incorporacin
del Sistema al
Entorno de
Operacin
IAS 5: Prueba
de
Implantacin
del Sistema
IAS 6: Prueba
de Aceptacin
del Sistema
IAS 9:
Presentacin y
Aprobacin del
Sistema
IAS 10: Paso a
Produccin
IAS 4 : Carga
de Datos al
Entorno de
Operacin
IAS 7: Preparacin del
Mantenimiento
IAS 8: Establecimiento del Acuerdo del Nivel
de Servicio
06/02/2013
Mtrica Versin 3: MSI
Mantenimiento del Sistema de Informacin: Tiene como objetivo
principal la obtencin de una nueva versin del sistema de
informacin en base a las peticiones de mantenimiento de los
usuarios realizan con motivo de un problema detectado en el
sistema, o por una necesidad de mejora del mismo.
Atendiendo a los fines, podemos establecer los siguientes tipos de
mantenimiento:
Correctivo: Para corregir errores del producto software.
Evolutivo: Para las incorporaciones, modificaciones y
eliminaciones necesarias en un producto software para su
expansin o cambio en las necesidades del usuario.
Adaptativo: Para las modificaciones que afectan a los entornos
en los que el sistema opera.
Perfectivo: Para mejorar la calidad interna de los sistemas en
cualquiera de sus aspectos: reestructuracin del cdigo,
definicin ms clara del sistema y optimizacin del rendimiento y
eficiencia.

06/02/2013
Mtrica Versin 3: MSI
Mantenimiento del Sistema de Informacin:
Objetivo: Obtencin de una nueva versin
del sistema de informacin en base a las
peticiones de mantenimiento de los
usuarios.
MSI 1:
Establecimiento
del Plan de
Implantacin
MSI 2:
Formacin
Necesaria para la
Implantacin
MSI 3 :
Incorporacin
del Sistema al
Entorno de
Operacin
MSI 4 Prueba de
Implantacin del
Sistema
06/02/2013
Mtrica Versin 3: Interfaces
4MTRICA, en su versin 3, proporciona tambin
cuatro interfaces que definen actividades
orientadas a la mejora y perfeccionamiento de los
procesos principales cara a garantizar la
consecucin del objetivo del desarrollo.
4Las interfaces son:
Gestin de proyectos (GP).
Seguridad (SEG).
Aseguramiento de la Calidad (CAL).
Gestin de la Configuracin (GC).
06/02/2013
Mtrica Versin 3: Interfaz de
Gestin de Proyectos
4Gestin de proyectos (GP): Tiene como finalidad
principal la planificacin, el seguimiento y control de las
actividades y de los recursos humanos y materiales que
intervienen en el desarrollo de un Sistema de
Informacin.
Las actividades de la GP son 3:
+Actividades de Inicio del Proyecto (GIP): Que
permiten estimar el esfuerzo y establecer la
planificacin del proyecto.
+Actividades de Seguimiento y Control (GSP):
Supervisando la realizacin de las tareas por parte
del equipo de proyecto y gestionando las
incidencias y cambios en los requisitos que puedan
presentarse y afectar a la planificacin del proyecto.
+Actividades de Finalizacin del Proyecto (GFP):
Cierre y registro de la documentacin de gestin.
06/02/2013
Seguridad
4Seguridad (SEG): Su objetivo es incorporar en
los sistemas de informacin mecanismos de
seguridad adicionales a los que se proponen en
la propia metodologa, asegurando el desarrollo
de cualquier tipo de sistema a lo largo de los
procesos que se realicen para su obtencin
4Se utilizar MAGERIT como metodologa de
anlisis y gestin de riesgos, en caso de que la
organizacin no disponga de sus propia
metodologa.

06/02/2013
Seguridad
4 MAGERIT: Es una metodologa de anlisis y gestin de
riesgos de los sistemas de informacin.
4 Objetivos:
Magerit persigue los siguientes objetivos:
1. Concienciar a los responsables de los sistemas de informacin
de la existencia de riesgos y de la necesidad de atajarlos a
tiempo.
2. Ofrecer un mtodo sistemtico para analizar tales riesgos.
3. Ayudar a descubrir y planificar las medidas oportunas para
mantener los riesgos bajo control.
4. Apoyar la preparacin a la Organizacin para procesos de
evaluacin, auditoria, certificacin o acreditacin, segn
corresponda en cada caso.

06/02/2013
Gestin de Configuracin
4 Gestin de configuracin (GC): El
objetivo es mantener la integridad de los
productos que se obtienen a lo largo del
desarrollo de los sistemas de informacin,
garantizando que no se realizan cambios
incontrolados y que todos los
participantes en el desarrollo del sistema
disponen de la versin adecuada de los
productos que manejan.

06/02/2013
Aseguramiento de Calidad
4 Aseguramiento de Calidad (CAL): Su
objetivo es proporcionar un marco comn de
referencia para la definicin y puesta en
marcha de planes especficos de
aseguramiento de calidad aplicables a
proyectos concretos.
4 Las actividades evalan la calidad y son
realizadas por un grupo de Asesoramiento
de la Calidad independiente de los
responsables de la obtencin de los
productos.
06/02/2013
Mtrica Versin 3: Tcnicas
4MTRICA, en su versin 3, distingue
entre:
Tcnicas de desarrollo (Casos de Uso,
Diagramas de Clases, Diagrama de flujo de
datos,...).
Tcnicas de gestin de proyectos (Tcnicas
de estimacin, Tamao de Personal,
Planificacin,...)
Prcticas (Anlisis de impacto,
Presentaciones, Prototipado,...)...

06/02/2013
Mtrica Versin 3: Perfiles
4MTRICA establece los siguientes perfiles para los
participantes en el proceso de desarrollo de un
sistema de informacin:
Directivo (Comit de Direccin, Directores de
Usuarios,...).
Jefe de Proyecto (Responsable de Implantacin,
Responsable de Seguridad,...).
Consultor (Consultor Informtico, Tcnico de
Sistemas).
Analista (Analista, Administrador de Bases de
Datos,...).
Programador.
06/02/2013
Resumen
4A la hora de crear un producto software se debe
conocer los modelos y tcnicas disponibles.
Cada modelo tiene sus propias peculiaridades
que hace que sean ms o menos eficientes
contra las particularidades del entorno o los
retos del proyecto a realizar.
4Ninguno de los modelos y tcnicas revisados
son excluyentes, de modo que se pueden
combinar los modelos ms adecuados para
cada situacin, creando un plan propio de
desarrollo y crecimiento de las aplicaciones.
06/02/2013
Resumen
4El modelo de cascada considera cada actividad
del proceso como actividad discreta.
4El modelo de desarrollo evolutivo considera
actividades del proceso en forma concurrente.
4El modelo en espiral se basa en el anlisis de
riesgos.
4La visibilidad del proceso involucra la creacin
de documentos o resultados de las actividades.
4Los ingenieros de software deben tener
responsabilidades ticas, sociales y
profesionales.
06/02/2013
Resumen
4Para sistemas bien comprendidos utilizar
el Modelo de Cascada. La fase de anlisis
de riesgos es relativamente fcil.
4Con requerimientos estables y sistemas
de seguridad crticos, utiliza modelos
formales.
4Con especificaciones incompletas, utiliza
el modelo de prototipado.
4Pueden utilizarse modelos hbridos en
distintas partes del desarrollo.
06/02/2013
Mtodos
giles
06/02/2013
Introduccin
06/02/2013
Proyecto Exitoso?
4Jefe de Proyecto: Por
qu va tan retrasado el
proyecto?
4Programador: Es que el
cliente ha vuelto a cambiar
las especificaciones y al
modificar el cdigo se
cometi errores en partes
que ya estaban terminadas.
4Jefe de Proyecto: Pero,
no sabes lo que nos
esta costando esto?
06/02/2013
xito o Fracaso en proyectos
de desarrollo de software
Proyectos de Software
32
30
28
26
27
16
17
20
23
28
40
31
51
50
49
46
33
53
0% 20% 40% 60% 80% 100%
2004
2002
2000
1998
1996
1994
xito
Fracaso
En problemas
06/02/2013
Los proyectos de desarrollo
4No haban seguido
mtodos formales
4Haban estimulado
la comunicacin y
las pruebas.
4No entendan sus
fallas si haban
cumplido con los
mtodos formales.
4En 1990 un estudio realizado en IBM:
Equipos exitosos Equipos con
problemas
06/02/2013
Los proyectos de desarrollo
4La experiencia se repiti por toda la
dcada, por todo el mundo y con
todas las herramientas

CONCLUSION
Menos nfasis en la
documentacin exhaustiva y ms
en versiones que corran y puedan
ser probadas.
06/02/2013
Esquema Tradicional
4Notaciones de modelado y las
herramientas (documentacin)
4Rigurosa definicin de
actividades, artefactos y roles.
4Efectivo en proyectos de gran
envergadura

06/02/2013
Desarrollos Actuales
4Contexto es muy cambiante.
4Se exige reducir tiempos pero
manteniendo una alta calidad.
4En la prctica, se prescinde del
buen hacer de la ingeniera del
software para ajustarse a estas
restricciones.
06/02/2013
Los mtodos giles
4Los mtodos giles (en adelante MAs)
constituyen un movimiento heterodoxo
que confronta con las metodologas
consagradas.
4Los MAs se expresaron a travs de
manifiestos y libros en tono de proclama,
rehuyendo (hasta hace poco) toda
especificacin formal.
4El efecto meditico de esos manifiestos
ha sido explosivo y ocasion que la
contienda entre ambas formas haya sido y
siga siendo enconada.
06/02/2013
Contienda enconada
Programadores del
Mundo Unos!
Un Fantasma Recorre Europa!Es Extreme!
06/02/2013
Los mtodos giles
4Los MAs no surgieron porque s,
sino que estuvieron motivados:
por una conciencia particularmente
aguda de la crisis del software.
por la responsabilidad que se
imputa a las grandes metodologas
en la gestacin de esa crisis y
por el propsito de articular
soluciones.
06/02/2013
de software
Mtodos
pesados
Mtodos
giles
Versus
06/02/2013
El desarrollo en cascada
4Algunos relacionan a los mtodos ortodoxos o
guiados por un plan con el desarrollo en
cascada tradicional porque ...
Los mtodos ortodoxos o guiados por un
plan surgieron cuando se intentaba construir
software con una aproximacin en cascada.
Los primeros interpretes del CMM (Modelo
de Capacidad de Madurez) adaptaron este
modelo a este ciclo de vida influenciado por el
tipo de ingeniera de sistemas que requeran
en aquel entonces el Departamento de
Defensa de EEUU, compaas como IBM,
Hitachi y Siemens, etc..

06/02/2013
El modelo en cascada
4El modelo en cascada
obedece a la mala adaptacin
de la planeacin predictiva al
desarrollo del software.
Salvo excepciones, el modelo
en cascada no funciona bien
en el desarrollo del software

06/02/2013
Lo que no funciona
Manufactura predecible
ideal
Desarrollo real de
producto nuevo
Es posible completar las
especificaciones y luego
construir el producto de manera
repetida.
Raramente es posible crear desde
el comienzo especificaciones que
no cambien.
Al comienzo, se pueden hacer
estimaciones de esfuerzo y costo.
Al comienzo no es posible
estimar. La confiabilidad crece en
medida que el proyecto avanza.
Es posible identificar, definir,
programar y ordenar todas las
actividades en detalle.
Al comienzo no es posible
hacerlo, pues se trata, casi
siempre, de un nuevo producto.
La adaptacin a cambios
impredecibles no es la norma,
pues la razn de cambios es baja.
La adaptacin a cambios es la
norma. La razn de cambios es
elevada.
06/02/2013
Consecuencia
4Lo que significa
Sobrecostos, proyectos muy largos en el tiempo, baja
calidad. En resumen: proyectos impredecibles.
Integracin en etapas finales y problemas tardos de
diseo.
Mucho retrabajo.
Software que no satisface necesidades de clientes y
usuarios.
Foco en documentos y reuniones formales de diseo.
Las aproximaciones basadas en planes producen
muchos documentos.
Insatisfaccin generalizada de los interesados.
Etc.
06/02/2013
Consecuencia
Y conducen a
+Prdida de dinero (sobrecostos,
necesidades del producto, etc. )
+Cuestionamiento al grupo de ingeniera
(interno o externo).
+Abordar el problema incorrectamente.
Hoy no triunfan las empresas ms
poderosas econmicamente, lo
hacen las ms rpidas e innovadoras
06/02/2013
Consecuencia
06/02/2013
Se persiste en lo que no
funciona
4Por qu se persiste en un modelo que no
funciona?
Para cada problema complejo, existe una
solucin simple, ordenada e incorrecta
(Mencken). Ejemplo: la tierra es plana, todo gira
alrededor de la tierra.
El desarrollo en cascada, atribuido a Royce [1970]
(En realidad Royce pregon el desarrollo iterativo),
tuvo una gran influencia, a partir de la ingeniera de
sistemas, y no de la ingeniera de software.
El desarrollo en cascada es fcil de explicar. El
desarrollo iterativo e incremental es ms complejo.
Puede dar la ilusin de un proceso ordenado,
predecible y medible.
06/02/2013
Se persiste en lo que no
funciona
4Porque no se quiere hacer de buscar
otras formas de desarrollo.
4Por presin de compradores, la cual a su
vez proviene de los CEO (Funcionario
Ejecutivo Principal) y CIO (Funcionario de
Informacin Principal), etc. Cunto
vale?Cunto se demora?, etc.
4Por la poltica de compras de los
gobiernos.
4Porque la ingeniera de software no es
fcil, aunque no es para seres especiales.
06/02/2013
Respuesta
4La respuesta a los problemas de
aproximacin en cascada y basadas en
documentos son las aproximaciones
denominadas giles.
Todas las aproximaciones
giles son un subconjunto de
las aproximaciones Iterativas.
06/02/2013
Respuesta
4El desarrollo Iterativo es:
Una aproximacin para
construir software (o cualquier
cosa), en la cual el ciclo de
vida se descompone en varias
iteraciones en secuencia. Cada
iteracin es un mini-proyecto
autocontenido.
06/02/2013
Respuesta
4El objetivo de cada iteracin es
Liberar un sistema parcialmente
completo, probado, integrado, y
estable. Algunas iteraciones
son internas, otras se liberan a
operaciones.
06/02/2013
Los mtodos giles
06/02/2013
Los mtodos giles
4En la dcada de los 80 se promovi el mtodo de la
cascada y los resultados fueron una serie de reveses.
A partir de 1987 se recomendaron los mtodos
evolutivos con resultados semejantes. El prestigioso
ISO 9000 tambin recibi duras crticas porque se
encontr correlaciones negativas entre la realidad y
los estndares.
4Ante esa evidencia, los expertos, en masa,
aconsejaron el abandono de los mtodos en cascada
y las normativas fuertes; eran nombres influyentes:
Harlan Mills, Tom Gilb, Barry Boehm, James
Martin, Tom DeMarco, Ed Yourdon y muchos ms
[Lar04]. Ya eran conocidos por diversos logros y
muchos de ellos estaban, adems, elaborando sus
propias alternativas dinmicas, iterativas, evolutivas y
en suma, giles.
06/02/2013
Los mtodos giles
4Para algunos tericos el surgimiento de los mtodos giles
fue considerado como una rebelin de aficionados adictos
al cdigo sin destreza en el desarrollo corporativo. Est
afirmacin est lejos de la realidad.
4Tanto los partidarios de los mtodos incrementales y los
futuros mtodos giles, tenan como en el CMM un comn
enemigo. Larman sostiene que muchos de los
certificadores en consultores en CMM tienen una fuerte
formacin en los valores de los mtodos de cascada y en
procesos prescriptivos, con poca experiencia en mtodos
iterativos e incrementales.
4Desarrollos posteriores como el Project Management
Institute (PMI), con su prestigioso Body of Knowledge
(PMBOK) pese a su aceptacin a nivel gerencial y que
reconoce el valor de los nuevos mtodos, no es aceptado
por los iconoclastas porque los contenidos ms tempranos
son marcadamente prescriptivos y tienen mucha confianza
en un plan y el desenvolvimiento de acuerdo a l.
06/02/2013
El Manifiesto de los
mtodos giles
4En marzo del 2001 en Salt Lake City se reunieron 17
especialistas para discutir los nuevos mtodos. Lo que
surgi de esta reunin Manifiesto gil de Desarrollo de
Software. Fue todo un acontecimiento, y aunque es
reciente marc un hito en la historia.
4El manifiesto de los MAs dice lo que sigue.
Estamos poniendo al descubierto formas mejores de
desarrollo de software, hacindole y ayudando a otros
que lo hagan. A travs de ste trabajo hemos llegado a
valorar:
Los individuos y la interaccin por encima de los
procesos y herramientas: La gente es el principal
factor de xito para un proyecto de software. Es ms
importante formar un buen equipo antes que construir el
entorno. El equipo una vez formado debe crear su
propio entorno de acuerdo a sus necesidades.
06/02/2013
mtodos giles
El software que funciona por encima de la documentacin
abarcadora: La regla a seguir es no producir documentos a
menos que sean necesarios de manera inmediata para
tomar una decisin importante. Estos documentos deben
ser cortos y centrarse en lo fundamental.
La colaboracin con el cliente por encima de la
negociacin contractual: Se propone que exista que una
interaccin entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la marcha del proyecto y la que
asegure su xito.
La respuesta al cambio por encima del seguimiento de un
plan: La habilidad de responder a los cambios que pueden
surgir a lo largo del proyecto (cambios en los requisitos, en la
tecnologa, en el equipo, etc.) determina tambin el xito o
fracaso del mismo. Por lo tanto la planificacin no debe ser
estricta, sino abierta y flexible.
06/02/2013
mtodos giles
4Los firmantes del Manifiesto fueron Kent Beck (XP),
Mike Beedle, Arie van Bennekum (DSDM), Alistair
Cockburn (Crystal), Ward Cunnimgham (XP), Martin
Fowler (XP), James Grenning (XP), Jim Highsmith
(ASD), Andrew Hunt (Pragmatic Programming), Ron
Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert
C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum),
Jeff Sutherland (Scrum) y Dave Thomas (Pragmatic
Programming). Hay predominio demogrfico de XP (6
sobre 17) y, considerando nuestra seleccin de diez
MAs, se percibe la falta de delegados de Evo, Agile
Modeling, Lean Development y RUP.
06/02/2013
Desarrollo de los mtodos giles
Metodologa Acrnimo Creacin Tipo de modelo Caracterstica
Adaptive Software
Development
ASD Highsmith 2000 Prcticas + Ciclo de
vida
Inspirado en sistemas
adaptativos complejos
Agile Modeling AM Ambler 2002 Metodologa basada en
la prctica
Suministra modelado gil
a otros mtodos
Crystal Methods CM Cockburn 1998 Familia de
metodologas
MA con nfasis en
modelo de ciclos
Agile RUP dX Booch, Martin, Newkirk
1998
Framework / Disciplina XP dado vuelta con
artefactos RUP
Dynamic Solutions
Delivery Model
DSDM Stapleton 1997 Framework / Modelo de
ciclo de vida
Creado por 16 expertos
en RAD
Evolutionary Project
Management
Evo Gilb 1976 Framework adaptativo Primer mtodo gil
existente
Extreme
Programming
XP Beck 1999 Disciplina en prcticas
de ingeniera
Mtodo gil radical
Feature-driven
development
FDD De Luca & Coad 1998
Palmer & Felsing 2002
Metodologa Mtodo gil de diseo y
construccin
Lean Development LD Charette 2001, Mary y
Tom Poppendieck
Forma de pensar
Modelo logstico
Metodologa basada en
procesos productivos
Microsoft Solutions
Framework
MSF Microsoft 1994 Lineamientos,
Disciplinas, Prcticas
Framework de desarrollo
de soluciones
Rapid Development RAD McConnell 1996 Survey de tcnicas y
modelos
Seleccin de best
practices, no mtodo
Rational Unified
Process
RUP Kruchten 1996 Proceso unificado Mtodo (gil?) con
modelado
Scrum Scrum Sutherland 1994 -
Schwaber 1995
Proceso (framework
de management)
Complemento de otros
mtodos, giles o no
06/02/2013
Principios de los mtodos
giles
1. Nuestra prioridad ms alta es satisfacer al cliente a
travs de la entrega temprana y continua de software
valioso.
2. Los requerimientos cambiantes son bienvenidos,
incluso cuando llegan tarde en el desarrollo. Los
procesos giles se pliegan al cambio en procura de
una ventaja competitiva para el cliente.
3. Entregar con frecuencia software que funcione, desde
un par de semanas hasta un par de meses, con
preferencia por las escalas de tiempo ms breves.
4. La gente de negocios y los desarrolladores deben
trabajar juntos cotidianamente a travs de todo el
proyecto.
06/02/2013
giles
5. Construir proyectos en torno de individuos motivados.
Darles la oportunidad y el respaldo que necesitan y
procurarles confianza para que realicen la tarea.
6. La forma ms eficiente y efectiva de comunicar
informacin de ida y vuelta dentro de un equipo de
desarrollo es mediante la conversacin cara a cara.
7. El software que funciona es la medida primaria de
progreso.
8. Los procesos giles promueven el desarrollo
sostenido. Los patrocinadores, desarrolladores y
usuarios deben mantener un ritmo constante
indefinidamente.
06/02/2013
giles
9. La atencin continua a la excelencia tcnica enaltece
la agilidad.
10. La simplicidad (el arte de maximizar la cantidad de
trabajo que no se hace) es esencial.
11. Las mejores arquitecturas, requerimientos y diseos
emergen de equipos que se auto-organizan.
12. A intervalos regulares, el equipo reflexiona sobre la
forma de ser ms efectivo, y ajusta su conducta en
consecuencia.
06/02/2013
Caractersticas mnimas de
los mtodos giles
a. Orientacin a las personas: Los clientes estn con el
equipo de desarrollo y pueden contestar a las
preguntas durante la marcha del proyecto.
Comunicacin directa, cara a cara entre los
desarrolladores.
b. Rechazo a la burocracia de los mtodos pesados:
Se rechaza exceso de documentacin y sta no
desempea papel fundamental en la construccin de
software de calidad.
c. Adaptacin a las circunstancias cambiantes de la
empresa: Se asume que los requisitos de software
evolucionan al mismo tiempo que se desarrolla; de
modo que se plantean prcticas dinmicas adaptables
a los cambios.
06/02/2013
los mtodos giles
d. Son mtodos ms adaptables que predictivos: Se
adaptan a los cambios y no se preocupan por lo que
pude ocurrir despus.
e. Rechazo a la especializacin: Los desarrolladores
no deben realizar las mismas tareas, deben rotar.
f. Desarrollo incremental e iterativo: El software
puede y debe ser desarrollado en incrementos e
iteraciones cuanto ms cortos mejor (das, semanas).
g. Orientacin al cdigo: El cdigo es lo nico esencial,
y el diseo est en el cdigo y no en los modelos
independientes del cdigo. La escritura del cdigo y
las pruebas son ms importantes que el anlisis y el
diseo.
h. Rechazo al diseo: Dado que los requisitos cambian
durante el proyecto, es innecesario el diseo
detallado.
06/02/2013
los mtodos giles
i. Uso de la refactorizacin: Modificar el cdigo para
modificar su estructura interna sin modificar su
estructura externa.
j. Rechazo a la reusabilidad: La reusabilidad no debe
guiar la construccin del software.
k. Reduccin de los costos de cambio: Se intenta que
los costos de los cambios no crezcan excesivamente
en el tiempo.
l. Se organizan a si mismos: Los equipos giles tienen
suficiente autonoma para organizarse y alcanzar los
objetivos del producto.
m. Son emergentes: La tecnologa y los requisitos
emergen en el ciclo de desarrollo del producto.
06/02/2013
Diferencia entre MAs y no giles
Mtodos giles Mtodos tradicionales
Basada en heursticas provenientes de las
prcticas de produccin del software.
Basada en normas provenientes de
estndares seguidos por el entorno de
desarrollo.
Especialmente preparados para cambios
durante el proyecto.
Cierta resistencia a los cambios.
Impuestos internamente por el equipo. Impuestas externamente.
Procesos menos controlados, con pocos
principios.
Proceso mucho ms controlado con
numerosas polticas /reglas.
No existe contrato tradicional, o al menos, es
bastante flexible.
Existe un contrato prefijado.
El cliente es parte del equipo de desarrollo. El cliente interacta con el equipo de
desarrollo mediante reuniones.
Grupos pequeos (< 10 integrantes) y
trabajando en el mismo sitio.
Grupos grandes y posiblemente distribuidos.
Pocos artefactos. Muchos artefactos.
Pocos roles. Ms roles.
Menos nfasis en la estructura del software La arquitectura del software es esencial, y se
expresa mediante modelos.
06/02/2013
Costo de los Cambios
Costo
del
cambio
Tiempo
Tradicional
Suposicin M. giles
06/02/2013
06/02/2013
Mtodos giles
Mtodos heterodoxos giles
+eXtreme Programing (XP).
+Scrum
+Evo
+Crystal Methods
+Feature Driven Development
+RUP
+Dynamic Systems Development Methods
+Adaptative Software Development
+Agile Modeling
+Lean Development y Lean Software Development
+Microsoft Solutions Framework
+Open Source
+

06/02/2013
eXtreme
Programing
06/02/2013
XP
4La Programacin Extrema (eXtreme Programing) XP
es el mtodo gil ms popular (38%) de entre los
modelos heterodoxos y el ms transgresor de ellos.
4Las fichas CRC (Clase-Responsabilidades-
Colaboradores) creadas por Beck y Cunningham
sirvieron de base para las tarjetas de historia de XP.
4Kent Beck fue empleado por la Chrysler para colaborar
en el sistema de liquidacin de sueldos de Smalltak,
conocido como el proyecto C3 (Chrysler
Comprehensive Compesation). Ms tarde se unieron
Ron Jeffries y Martin Fowler y trabajaron juntos en
donde no slo est la raiz de XP, sino el ncleo primitivo
de la comunidad gil. A similitud de los tres amigos de
UML (Booch, Rumbaugh y Jacobson) Beck, Jeffries y
Fowler son conocidos como los tres extremos.
06/02/2013
XP
4Los tres extremos de XP:
Martin Fowler
Kent Beck Ron Jeffries
06/02/2013
Evolucin de XP
06/02/2013
Valores de XP
4Los 4 valores que fomenta XP son:
Comunicacin: Es esencial mantener informados a
todos los miembros de lo que est sucediendo.
Simplicidad: La arquitectura debe ser una
herramienta que cualquiera pueda entender y
modificar sin necesidad de conocimientos especiales.
Esto significa que:
+El cdigo y pruebas revelan su intencin a
cualquiera.
+El sistema no contiene cdigo duplicado.
+El sistema contiene el mnimo nmero de clases y
mtodos.
06/02/2013
Valores de XP
Retroalimentacin: Para dirigir eficientemente
el esfuerzo, debe darse la retroalimentacin
concreta y eficiente del cliente, equipo y los
usuarios finales.
Coraje: Un programador XP debe ser lo
suficientemente valiente para:
+Comunicarse con los dems y exponer su propia
ignorancia.
+Desechar cdigo que no funciona y empezar de cero.
+Involucrarse plenamente en los proyectos.
+Mantener el sistema simple, dejando las decisiones
para despus.

06/02/2013
Caractersticas de XP
4 Est centrada en potenciar las relaciones interpersonales como
clave de xito en el desarrollo de software.
4 Propicia el aprendizaje continuo de los desarrolladores.
4 Promueve el trabajo en equipo y el buen clima de trabajo.
4 Se basa en la retroalimentacin continua entre el cliente y los
desarrolladores.
4 Propicia la comunicacin fluida entre todos los participantes.
4 Busca la simplicidad en las soluciones implementadas y coraje para
enfrentar los cambios.
4 Est orientada a quien produce y usa software.
4 Reduce el costo del cambio en todas las etapas del ciclo de vida del
sistema.
4 Combina las mejores prcticas de desarrollo de software y los lleva
al extremo.
4 Es especialmente adecuada para proyectos con requisitos
imprecisos, muy cambiantes, y con un alto riesgo tcnico.
4 Las caractersticas esenciales de XP se describen en artefactos,
roles, proceso y prcticas.
06/02/2013
Artefactos de XP
4Entre los artefactos que se usan en XP tenemos:
Las Historias del Usuario (User Stories), que son
tarjetas donde el cliente describe brevemente las
caracterstica que el sistema debe tener sean
funcionales o no. Se descomponen tareas de
programacin (task cards) que se asignan a los
programadores para ser implementadas en cada
iteracin.
El tratamiento debe ser dinmico y flexible. Cada
tarjeta debe ser lo suficientemente comprensible y
delimitada para que los programadores puedan
implementarla en unas cuantas semanas
Las Listas de tareas en papel o pizarra (jams en
computadora) y grficos visibles pegados en la
pared. Mensaje (M. Flower): Los eXPertos no
hacen diagramas

06/02/2013
Artefactos de XP
4Una ficha de Historia del Usuario
06/02/2013
Artefactos de XP
4Una ficha de Lista de Tareas
06/02/2013
Roles en XP
Programador
Encargada de
seguimiento
Entrenador
Encargada
de pruebas
Gestor
Cliente
Consultor
externo
Roles en XP
06/02/2013
Proceso XP
4El ciclo de desarrollo para cada iteracin en XP
consiste en los siguientes pasos:
1. El cliente define el valor del negocio a implementar.
2. El programador estima el esfuerzo necesario para la
implementacin.
3. El cliente selecciona qu construir de acuerdo a sus
prioridades y las restricciones de tiempo.
4. El programador construye ese valor del negocio.
5. Volver al paso 1.
4En cada iteracin aprenden tanto el cliente como el
programador. No se debe exigir al programador a
trabajar ms de lo estimado porque atenta contra la
calidad del software. El cliente se compromete a
manejar el mbito de entrega del producto para
asegurar que el sistema tenga el mayor valor posible
en cada iteracin.
06/02/2013
Prcticas en XP
1. Juego de planeamiento: Busca determinar rpidamente el
alcance de la versin siguiente con las prioridades del cliente
y las estimaciones tcnicas de los programadores del
esfuerzo necesario para implementar las historias del cliente
y este decide sobre el alcance y la agenda de las entregas.
Las historias se escriben en pequeas fichas que a veces se
tiran. Lo que quedan como requerimientos a una multitud de
pruebas de aceptacin.
2. Entregas pequeas y frecuentes: Se produce un pequeo
sistema rpidamente, al menos uno cada 2 o 3 meses.
Pueden liberarse nuevas versiones cada da, pero al menos
debe liberarse una cada mes.
3. Metforas del sistema: El sistema se define a travs de una
metfora o un conjunto de metforas, una historia
compartida por clientes, gerentes y programadores que
orienta todo el sistema describiendo como funciona. Una
metfora se interpreta como una arquitectura simplificada del
sistema. La concepcin de metfora que se aplica en XP
deriva de los estudios de Lakoff y Johnson.
06/02/2013
Prcticas en XP: Metforas
4Reemplaza a la arquitectura
4Historia compartida sobre cmo
funciona todo el sistema
4Lenguaje comn que todos puedan
entender
Cliente
Desarrolladores
4La metfora puede cambiar
permanentemente

06/02/2013
Prcticas en XP
4. Diseo simple: Consiste en disear la solucin ms simple
susceptible de ser implementada en el momento. Se
eliminan complejidades innecesarias y cdigo extra y se
define la menor cantidad posible de clases. Se urge a decir
todo una vez y slo una vez. En XP el diseo se reduce a
unas cuantas tarjetas elaboradas en sesiones de 20 a 30
minutos. Se aplica YAGNI(You Aint Gonna Need It). (No
implementar nada que no se necesite ahora). Minimizar
diagramas y documentos.
5. Prueba continua: El desarrollo est orientado por las
pruebas. Los clientes ayudan a escribir las pruebas
funcionales antes de escribir el cdigo. El propsito real del
cdigo es pasar las pruebas y no satisfacer requerimientos.
Hay 2 tipos de pruebas:
- Prueba unitaria: Verifica una sola clase o un grupo
pequeo de clases.
- Prueba de aceptacin: Verifica todo el sistema o gran
parte de ella.

06/02/2013
Prcticas en XP
6. Refactorizacin continua: Se refactoriza el sistema eliminando
duplicacin y agregar flexibilidad sin restar funcionalidad.
Consiste en pequeas modificaciones en la estructura interna
preservando la conducta aparente. Si funciona bien, arrglalo
de todos modos. Se recomiendan herramientas automticas.
Ken Orr recomienda GeneXus de ARTech, Uruguay, virtuoso
ejecutor de promesas no cumplidas por las herramientas CASE.
7. Programacin en pares: Todo el cdigo est escrito por pares
de personas, que se turnan en el uso del teclado y el ratn. El
que no escribe piensa desde un punto de vista estratgico y
revisa el cdigo en tiempo real. Los roles se intercambian varias
veces al da.
8. Propiedad colectiva del cdigo: Cualquiera puede cambiar
cualquier parte del cdigo en cualquier momento, siempre que
escriba antes la prueba correspondiente. desarrollo est
orientado por las pruebas. Los clientes ayudan a escribir las
pruebas funcionales antes de escribir el cdigo. Algunas veces
los clientes aplican el patrn organizacional CodeOwnerChip
de Coplien.
06/02/2013
Prcticas en XP
9. Integracin continua: Cada pieza se integra a la
base del cdigo apenas est lista, varias veces al
da. Debe correrse la prueba antes y despus de
la integracin. Hay una mquina dedicada a este
propsito.
10.Ritmo sostenido trabajando un mximo de 8
horas al da: En XP todo el mundo se va a casa
a las 5 p.m. Como la creacin de software es un
proceso creativo, estar fresco y descansado es
conveniente. Se motiva la rotacin, se evita la
rotacin de personal y se mejora la calidad del
producto. No hay hroes; se elimina el proceso
neurtico. Aunque excepcionalmente puede
haber horas extras, no se permiten dos semanas
seguidas de tiempo adicional.
06/02/2013
Prcticas en XP
11.Todo el equipo en el lugar: El cliente debe estar
presente y estar disponible a tiempo completo a
disposicin del equipo. Como esta regla pareca no
cumplirse, (si el cliente era muy joven no tena
experiencia y si era muy mayor no quera estar all), se
especific que el representante del cliente sea de
preferencia un analista.
12.Estndares de codificacin: Se deben seguir reglas
de codificacin y comunicarse a travs del cdigo.
Algunos practicantes prefieren la tradicin oral. Otros lo
resuelven ponindose de acuerdo en la notacin,
indentacin y nomenclatura, as como un valor
apreciado en la prctica, llamado cdigo revelador de
intenciones. Como en XP hay un purismo en la
codificacin, los comentarios no son bien vistos. Si el
cdigo necesita comentarios se debe reescribir o
refactorizar.
06/02/2013
Prcticas en XP
13.Espacio abierto: Es preferible una sala
grande con pequeos cubculos, o mejor aun,
sin divisiones. Los pares de programadores
estn en el centro. En la periferia se ubican las
mquinas privadas. En un encuentro de
espacio abierto la agenda no se establece
verticalmente.
14.Reglas justas: El equipo tiene sus reglas a
seguir, pero pueden cambiar en cualquier
momento. En XP se piensa que no hay un
proceso que sirva para todos los proyectos.; lo
que se hace habitualmente es adaptar una
serie de prcticas simples a las caractersticas
de cada proyecto.
06/02/2013
Prcticas en XP
4Las prcticas se refuerzan entre si:
Reglas
justas
Juego de
planificacin
Espacio
abierto
Cliente in
situ
Metfora
Refactorizacin
Programacin
por parejas
Propiedad
colectiva
Estndares de
codificacin
Integracin
continua
Versiones
pequeas
40 horas
semanales
Diseo
sencillo
Pruebas
06/02/2013
Ciclo de Vida de XP
4 El ciclo de vida de XP tiene 6 fases: Exploracin,
Planificacin de la entrega, Iteraciones, Produccin,
Mantenimiento y Muerte del proyecto.
Exploracin: Los clientes plantean a grandes rasgos las
Historias de usuario que son de inters para la primera
entrega del producto. El equipo de desarrollo se
familiariza con las herramientas, tcnicas y prcticas que
se utilizarn en el proyecto. Se prueban la tecnologa y
arquitectura del sistema construyendo un prototipo. Esta
fase dura pocas semanas o meses, dependiendo del
tamao y de la familiaridad que tengan los
programadores con la tecnologa.
Planificacin de la entrega (releases): El cliente
establece la prioridad de cada historia y, en
correspondencia, los programadores estiman el esfuerzo
necesario para c/u de ellas. Se discute el contenido de la
primera entrega y se elabora un cronograma con la
participacin del cliente. Cada entrega no debe pasar de
3 meses. Esta fase dura uso cuantos das.
06/02/2013
Ciclo de Vida de XP
Interacciones: Incluye varias iteraciones sobre el
sistema antes de entregarse. El Plan de entrega
est conformada por iteraciones de n ms de 3
semanas. En la primera entrega se intentar
establecer la arquitectura del sistema que se usar
en el resto del proyecto.
Los elementos para tomar en esta fase son cuatro:
Historias de usuario no abordadas, velocidad del
proyecto, pruebas de aceptacin no superadas en
la interaccin anterior y tareas no terminadas en la
interaccin anterior.
Todo el trabajo de iteracin es expresado en tareas
de programacin, cada una de las cuales es
asignada a un programador como responsable,
pero llevadas a cabos por pareja de
programadores.

06/02/2013
Ciclo de Vida de XP
Produccin: Requiere de pruebas adicionales y
revisiones de rendimiento antes que el sistema sea
trasladado al entorno del cliente. Al mismo tiempo debe
tomarse decisiones sobre la inclusin de nuevas
caractersticas a la versin actual, debido a cambios
durante esta fase.
Es posible que se baje el tiempo que toma cada iteracin
de 3 a 1 semanas. Las ideas y las sugerencias se
documentan para su posterior implementacin.
Mantenimiento: Mientras la primera versin se encuentra
en produccin, el proyecto XP debe mantener el sistema
en funcionamiento, al mismo tiempo que mantiene
desarrolla nuevas iteraciones. Para esto se requiere de
tareas de soporte para el cliente. De esta forma la
velocidad de desarrollo puede disminuir despus de la
puesta del sistema en produccin. La fase de
mantenimiento `puede requerir de nuevo personal en el
equipo y cambios en su estructura.
06/02/2013
Ciclo de Vida de XP
Muerte del proyecto: Es cuando el cliente
no tiene Historias de cliente para ser
incluidas en el sistema. Esto requiere que se
satisfaga los requerimientos del cliente en
otros aspectos como el rendimiento y
confiabilidad del sistema. Se genera la
documentacin final del sistema y no se
realiza ms cambios en la arquitectura.
La muerte del proyecto tambin ocurre
cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay
presupuesto para mantenerlo.
06/02/2013
Otros aspectos de XP
4La particularidad de XP es que no requiere de
ninguna herramienta fuera del ambiente de
programacin y pruebas. Demanda
comunicacin oral para los requerimientos y el
diseo. Beck ha llegado a decir Tambin yo
creo en el modelado; slo que lo llamo por
el nombre propio, mentir, y trato de
convertirlo en arte.
4Algunos autores sugieren implementar spikes
(pas o astillas) para estimar la duracin y
dificultad de una tarea inmediata. Un spike es
un prototipo de cdigo para determinar cmo
resolver un problema. Se llama as porque va
de punta en punta y es muy fino, con
bsquedas que priorizan la profundidad.
06/02/2013
Otros aspectos de XP
4Derechos del cliente:
Decidir qu se implementa.
Saber el estado real y el progreso del proyecto.
Aadir, cambiar o quitar requerimientos en cualquier
momento.
Obtener lo mximo por cada semana de trabajo.
Obtener un sistema funcionando cada 3 o 4 meses.
4Derechos del programador:
Decidir cmo se implementan las cosas.
Crear el sistema con la mayor calidad posible.
Pedir al cliente, en cualquier momento, aclaraciones
a los requerimientos.
Estimar el esfuerzo para implementar el sistema.
Cambiar las estimaciones con base en nuevos
descubrimientos.
06/02/2013
Visin optimista de XP
4Segn Kent Beck, la programacin extrema
es una forma ligera, eficiente, flexible,
predecible, cientfica y divertida de generar
software (Kent Beck, Extreme Programming
Explained).
4Esta metodologa ha surgido desde la
experiencia, como una forma de resolver los
problemas encontrados en los procesos de
desarrollo de software en los que se han visto
involucrados sus autores.
4Este tipo de desarrollos eran en general de
creacin de software a la medida del cliente y
hay numerosas opiniones que relatan el xito
de esta metodologa en este mbito.
06/02/2013
Visin optimista de XP
4En una encuesta realizada el ao 2000 por la
IBM donde se preguntaba sobre este mtodo
de programacin a un grupo de profesionales:
A. Lo he probado y no
me gusta nada.
B. Es una mala idea,
no puede funcionar
nunca.
C. Es una buena idea,
pero no funcionar.
D. Lo he probado y
me gusta mucho.
06/02/2013
Crticas a XP
4Las crticas ms comunes a XP son:
La fantasa de pretender que el cliente se quede en
el sitio y la resistencia de los programadores a
trabajar en pares.
Craig Larman seala como factores negativos la
ausencia de nfasis en la arquitectura durante las
primeras iteraciones (no hay arquitectos en XP) y la
consiguiente falta de diseo arquitectnico.
El 40 % de programadores encuestados no entiende
que son y para que sirven las metforas. Han sido
reemplazadas por Vocabulario Comn.
La beligerancia de su nombre (y sus acrnimos);
aunque Jim Highsmith la justifica puesto que a
nadie entusiasmara un libro titulado Programacin
Moderada. Las nuevas tecnologas se imponen con
giros radicales y coraje.

06/02/2013
Crticas sobre XP
Los programadores tienen un acusado sentimiento de
posesin del cdigo y esta postura no encaja con la filosofa
de X.P.
La programacin por pares no es adecuada en muchos casos.
Tiene en ocasiones rechazo de programadores y gestores. Es
la prctica ms abandonada. Resulta costoso pagar a dos
programadores en lugar de uno.
XP slo puede funcionar con buenos programadores capaces
de hacer un buen y sencillo diseo y fcilmente extensibles.
XP es ms una filosofa de trabajo que una metodologa. Las
prcticas no son aporte de XP, slo han sido reunidas por ella.
XP est diseada para grupos pequeos de programadores.
Hay problemas cuando hay ms de 20 programadores
Como no hay diseo, se gasta tiempo en la refactorizacin
con el peligro de introducir bugs.
Hay evidencias de proyectos XP, que han fracasado:
Proyecto C3.
06/02/2013
Conclusiones sobre XP
4XP es una metodologa joven. No es la
panacea, y no se garanta de xito aplicarlo,
indiscriminadamente a cualquier proyecto. Sin
embargo hay constancia de proyectos exitosos.
4XP es muy til en proyectos de mediana
complejidad con requisitos no muy claros y
cambiantes y requiere de entregas urgentes
Queda por ver si es posible aplicar la ideas de
XP tambin en procesos de desarrollo muy
diferentes, como el seguido por la comunidad
del software libre.
4Muchas de las prcticas proclamadas por XP,
son tambin propugnadas por la comunidad del
software libre.
06/02/2013
Elegir XP cuando
4Se tiene requisitos vagamente definidos o
voltiles.
4Se tiene o se puede desarrollar
habilidades y prcticas de ingeniera
potentes.
4Los clientes se pueden involucrar todos
los das (horas).
06/02/2013
Bibliografa sobre XP
4Kent Beck y Martin Fowler: Planning
Extreme Programing.
4Kent Beck: Extreme Programing Explained.
4Ron Jeffries: Essential XP: Junior / Senior
Pairing.
4Ron Jeffries: Manuals in Extreme
Programming.
4Martin Fowler, Kent Beck, John Brant,
William Opdyke y Don Roberts: Refactoring:
Improving the design of existing code.

06/02/2013
Sitios Web sobre XP
4 http://www.extremprogramming.org/
4 http://www.xprogramming.com/index.htm
4 http://www.martinfowler.com/
4 http://c2.com/cgi/wiki?ExtremeProgrammin
gRoadmap
4 http://www.xtreme-simplicity.net

06/02/2013
Scrum
06/02/2013
Scrum
4Scrum es el mtodo gil ms popular
despus de XP y que se recomienda
como complemento de l.
4La palabra scrum proviene del rugby, que
designa el acto de preparar el avance
conjunto de un equipo pasando la pelota
de jugador.
4Desarrollada por Ken Schwaber, Jeff
Sutherland y Mike Beedle. Se aplicaron
principios de desarrollo industriales y
experiencias de empresas como Microsoft,
Borland y Hewlett Packard.

06/02/2013
Scrum
4Los fundadores de Scrum:
Mike Beedle
Ken Schwaber Jeff Sutherland
06/02/2013
Valores de Scrum
4Los valores de Scrum son:
4Equipos auto-dirigidos y auto-
organizados: No hay jefes slo miembros:
cerdos y gallinas. La excepcin es el Scrum
Master que es 50 % programador y resuelve
problemas pero no manda. Los cerdos estn
dentro y por lo tanto comprometidos; mientras
que las gallinas son externos y pueden
observar, pero no interfieren ni opinan.
4Evitar trabajo extra: Una vez elegida la
tarea no se agrega trabajo extra y se agrega
algo se recomienda quitar alguna otra cosa
06/02/2013
Principios de Scrum
4Scrum tienen los siguientes principios:
Colaboracin estrecha con el cliente.
Predisposicin y respuesta al cambio.
Prefiere el conocimiento tctico de las personas
al explcito de los procesos.
Desarrollo incremental con entregas funcionales
frecuentes.
Comunicacin verbal frecuente entre los
implicados del proyecto.
Motivacin y responsabilidad de los equipos por
la auto-gestin, auto-organizacin y compromiso.
Simplicidad: supresin de artefactos innecesarios
en la gestin del proyecto.
06/02/2013
Valores de Scrum
4 Encuentros diarios con tres preguntas: Se
realizan en crculo, siempre en el mismo lugar y
se plantean tres preguntas:
1. Qu has hecho desde el ltimo encuentro?
2. Qu obstculos hay para cumplir la meta?
3. Qu hars antes del prximo encuentro?
4 Iteraciones de 30 das: Se admite que sean ms
frecuentes.
4 Demostraciones a participantes externos:
despues de cada iteracin.
4 Planeamiento adaptativo guiado por el cliente:
al principio de cada iteracin.

06/02/2013
Valores de Scrum
El equipo revisa los requisitos, considera la tecnologa disponible,
evala sus conocimientos, y de forma colectiva determina cmo
implementar la funcionalidad.
06/02/2013
Roles en Scrum
Equipo
Propietario
del Producto
Usuario
Scrum
Master
Cliente
Administrador
Roles en Scrum
06/02/2013
Roles en Scrum: Cerdos y Gallinas
COMPROMETIDOS EN
EL PROYECTO
Dueo del producto
Equipo
Scrum Master
IMPLICADOS EN EL
PROYECTO
Marketing
Comercial
Etc.
Scrum diferencia
claramente entre estos dos
grupos, para garantizar que
quienes tienen la
responsabilidad, tienen
tambin la autoridad
necesaria para poder lograr
el xito (cerdos); y que
quienes no tienen la
responsabilidad, slo
observan y no producen
interferencias innecesarias
(gallinas)
06/02/2013
Roles en Scrum: Cerdos y Gallinas
Un cerdo y una gallina caminaban
por la carretera: La gallina le dijo
al cerdo: Quieres abrir un
restaurante conmigo? El cerdo
consider la respuesta y
contest: Si me gustara, y
cmo lo llamaramos?. La gallina
le respondi: Huevos y
jamones
El cerdo se detuvo, hizo una
pausa y contest Pensndolo
mejor, creo que no voy a abrir
un restaurante contigo: Yo
estara realmente
comprometido; mientras que
tu solamente implicada.
06/02/2013
Ciclo de Vida de Scrum
4Las fases del ciclo de vida de Scrum son los
siguientes:
Pre - juego: Planeamiento: El propsito es
establecer la visin, definir expectativas y
asegurarse la financiacin. Las actividades son la
escritura de la visin, el presupuesto, el registro de
acumulacin o retraso (backlog) del producto inicial
y los tems estimados, as como la arquitectura de
alto nivel, el diseo exploratorio y los prototipos. El
registro de acumulacin es de un alto nivel de
abstraccin.
Pre juego: Montaje (Staging): El propsito es
identificar ms requisitos y priorizar tareas para la
primera iteracin. Las actividades son planificacin,
diseo exploratorio y prototipos.
06/02/2013
Juego o desarrollo: El propsito es
implementar un sistema listo para la
entrega en una serie de entregas de 30
das que se llaman sprints (carreras).
Las actividades son un encuentro de
planeamiento de carreras por cada
iteracin, la definicin del registro de
corridas por y los estimados; y los
encuentros diarios de Scrun.
Post juego: Liberacin (Release): El
propsito es el despliegue operacional.
Las actividades, documentacin,
entrenamiento, mercadeo y venta.
06/02/2013
4Ciclo de Scrum, basado en [Abr02]:
06/02/2013
Artefactos en Scrum
4 Scrum define 3 tipos de artefactos: Backlog del
Producto, Backlog del Sprint, Grfica de progreso
Backlog del Producto (Product Backlog): Listado
de requisitos del sistema:
+ Es responsabilidad del propietario del producto.
Contenido.
Priorizacin.
Disponibilidad.
+ Nunca llega a ser una lista completa y definitiva.
+ El empleado para planificar el proyecto es slo
una estimacin inicial de requisitos.
+ Es un documento dinmico que incorpora
constantemente las necesidades del sistema.
+ Se mantiene durante todo el ciclo de vida (hasta
la retirada del sistema)
06/02/2013
Artefactos en Scrum
4 Backlog del Producto (Product Backlog):
Backlog del
Producto
E
S
T
I
M
A
C
I

N
I
N
I
C
I
A
L
C
O
M
P
L
E
J
I
D
A
D
E
S
T
I
M
A
C
I
O
N
A
J
U
S
T
A
D
A
Trabajo
pendiente
Sprint
1 2 3 4
ID Elemento
1 Nuevo formulario para peticiones de clientes. 2 0.2 2.4 2.4 0 0 0
2 Configuracin de respuestas automticas. 3 0.2 3.6 3.6 0 0 0
3 Envo automtico de respuestas. 1 0.2 1.2 1.2 0 0 0
4 Consulta para los clientes de peticiones enviadas. 1 0.2 1.2 1.2 0 0 0
5 Modificacin de peticiones enviadas por el cliente. 2 0.2 1.2 2.4 0
6 Acceso a peticiones slo para clientes del portal jurdico. 5 0.2 2.4 6 0 0 0
7 Consulta de peticiones por parte del staff. 1 0.2 2.6 1.2 0 0 0
SPRINT 1 15 18 18 0 0 0
8 Insercin de comentarios y reasignacin de peticiones (staff). 2 0.2 1.2 1.2 1.2 0 0
9 Consultas por clientes, temas y fechas. 3 0.2 3.6 3.6 3.6 0 0
10 [Continua ]
06/02/2013
Artefactos en Scrum
Backlog del Sprint (Sprint Backlog):
+ Trabajo o tareas determinadas por el equipo
para realizar en un Sprint y lograr al final del
mismo un incremento de la funcionalidad.
+ Los miembros se postulan a las tareas.
+ Se recomienda que las tareas reflejadas
tengan una duracin comprendida entre las
4 y las 16 horas de trabajo.
+ La estimacin se actualiza da a da.
+ Las de mayor duracin deben intentar
descomponerse en sub-tareas de ese rango
de tiempo.
+ Si no est claro, un Sprint ms largo.
06/02/2013
Prcticas en Scrum
4 Aunque Scrum no define prcticas ni mtodos
especficos, requiere de ciertas prcticas y
herramientas administrativas para enfrentar la
impredictibilidad.
Lista de reserva de producto: Es una lista
priorizada y constantemente actualizada de
los requerimientos tcnicos y del negocio en
base al conocimiento actual. El propietario
del producto es el responsable de su
mantenimiento.
Estimacin del esfuerzo: Proceso iterativo
en que las estimaciones sobre los elementos
de lista de reserva son refinados a medida
que se tiene ms informacin disponible.
06/02/2013
Prcticas en Scrum
Sprint: Es el periodo de tiempo durante el cual se
desarrolla un incremento de funcionalidad. Constituye
el ncleo de Scrum que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeas
carreras.
+ Duracin mxima: 30 das.
+ Durante el sprint no se puede modificar el trabajo que
se ha acordado en el Backlog.
+ Slo es posible cambiar el curso de un sprint,
abortndolo, y slo lo puede hacer el Scrum Master
si decide que no es viable por alguna de las razones
siguientes:
La tecnologa acordada no funciona.
Las circunstancias del negocio han cambiado.
El equipo ha tenido interferencias.

06/02/2013
Prcticas en Scrum
Reuniones de planificacin del sprint: En
su primera fase se definen los objetivos y
funcionalidades (proporcionadas por el
Propietario) del siguiente sprint, mientras que
en la segunda el nfasis est en el como
producir el incremento del producto durante el
sprint.
Lista de reserva del sprint: Es una lista de
elementos de la lista de reserva del producto
que han sido seleccionados para ser
implementados en el siguiente sprint. Esta lista
es estable hasta que el sprint termina.
06/02/2013
Prcticas en Scrum
Reuniones diarias de Scrum: Reuniones diarias con
un mximo de 15 minutos con el objeto de llevar el
registro del progreso, planificacin diaria, discusin y
control de problemas y otras variables de inters:
+ Todos los das y a la misma hora.
+ Se recomienda que sea la primera actividad del
da.
+ Deben acudir todos los miembros del equipo.
+ Moderadas por el Scrum Master que pregunta a
todos los asistentes:
1. Qu has hecho desde el ltimo
encuentro?
2. Qu obstculos hay para cumplir la
meta?
3. Qu hars antes del prximo encuentro?
06/02/2013
Prcticas en Scrum
+ No se permite entrar en divagaciones o salirse del
guin.
+ Slo habla la persona que informa de su trabajo, el
resto escucha y no hay lugar para otras
conversaciones.
+ Cuando un miembro informa algo de inters para
otros, o necesita ayuda de otros, stos se renen al
terminar la reunin de revisin diaria.
+ Las gallinas no pueden intervenir ni distraer, y el
Scrum Master puede limitar el nmero de gallinas
asistentes si lo cree oportuno.
06/02/2013
Prcticas en Scrum
Reuniones de revisin de sprint: En el ltimo da del sprint,
se renen el equipo Scrum, el Scrum Master, el propietario del
producto con todas las personas implicadas en el proyecto
(incluyendo a las gallinas):
+ Duracin mxima: 4 horas.
+ Finalidad: Presentar al propietario del producto, a la
administracin, al consumidor y a las gallinas las
nuevas funcionalidades implementadas.
+ Las funcionalidades no implementadas no se presentan.
+ En la reunin, los miembros del equipo presentan las
nuevas funcionalidades.
+ Al final de la reunin se pregunta individualmente a
todos los asistentes para recabar impresiones,
sugerencias de cambio y mejora, y su relevancia.
+ El propietario del producto trata con los asistentes y con
el equipo las posibles modificaciones del Backlog.
06/02/2013
Prcticas en Scrum
Reunion retrospectiva: Acuden el equipo Scrum, el
Scrum Master y opcionalmente el propietario del producto:
+ Todos los miembros del equipo responden a dos
preguntas:
Qu cosas fueron bien en el ltimo sprint?
Qu cosas se pueden mejorar?
+ El Scrum Master anota toda las respuestas.
+ El equipo prioriza las mejores posibles.
+ El Scrum Master no proporciona respuestas, sino que
ayuda al equipo a encontrar la mejor forma de
trabajar con Scrum.
+ Las acciones de mejora localizadas que se pueden
implementar en el prximo sprint deben introducirse
en el Backlog como elementos no funcionales.
06/02/2013
El flujo de Scrum
06/02/2013
Crticas a Scrum
4No hay evidencia real de que el mtodo
sea superior a los mtodos tradicionales.
4No es adecuado para proyectos
complejos.
4Algunas prcticas no pueden llevarse a
cabo tal como lo propugna la teora
Scrum.
4La falta de documentacin no es suplida
por el dilogo diario.

06/02/2013
Elegir Scrum cuando
4Los requisitos son cambiantes y
emergentes.
4Si hay disposicin para que los equipos
se organicen solos.
4Se necesita un modelo de gestin ms
que un conjunto de prcticas ingenieriles.
4Se necesita un proceso gil probado y
escalable.
06/02/2013
Bibliografa sobre Scrum
4Ken Schwaber y Mike Beedle: Agile
Software Devolpment with Scrum.
4Ken Schwaber y Mike Beedle: Agile
Project Management with Scrum.
06/02/2013
Sitios Web sobre Scrum
4 http://www.mountaingoatsoftware.com/scrum
(XLS)
4 http://www.controlchaos.com
4 http://www.agilealliance.com

06/02/2013
Evolutionary
Project
Management (Evo)
06/02/2013
Evo
4Evo, fue creado por Tom Gilb, es el mtodo iterativo
gil ms antiguo. Se le llama tambin Evolutionary
Delivery, Evolutionary Management, Requeriments
Driven Project Management y Competitive
Engineering. Tuvo sus inicios en Europa.
4En 1981 Gilb public Evolutionary Development
(Desarrollo Evolutivo) y Evolutionary Delivery versus
the Waterfall Model (Entrega Evolutiva contra el
Modelo de Cascada).
4En la dcada de los 80 Gilb cay bajo la influencia de
los valores de W. Edward Deming y el mtodo PDSA
(Planear Hacer Estudiar Actuar) de Walter
Schewart que se convirtieron en los modelos
conceptuales subyacentes dentro de Evo.
06/02/2013
Evo
4El fundador de Evo y su hijo y colaborador
Kai:
Tom Gilb
Kai Gilb
06/02/2013
Evo
4El libro de Larman compara mtodos Evo,
incluyendo el Evo de Gilb (Captulo 10)
Craig Larman
06/02/2013
Evo
4En los 90 Gilb continu el desarrollo de
Evo, y tal vez fue ms importante por las
ideas que aport a XP, Scrum, e incluso a
UP que por su propio desarrollo.
4El texto de Microsoft Press, Rapid
Development de Steve McConnell, que
examina prcticas iterativas e
incrementales en desarrollo de software,
menciona ideas de Gilb en 14 secciones;
todas esas referencias estn ligadas a las
mejores prcticas.
06/02/2013
Valores de Evo: 5 al tope
4Aprender rpidamente por medicin realista.
4Entregar valor real para los participantes
tempranamente, frecuentemente, a cada paso.
4Ser humilde con un sistema complejo:
simplificar y atacar los problemas con un
pequeo paso en un momento dado.
4Delegar poder para enfrentar de cara,
enfocando en los resultados del extremo, y no
en los mtodos, o en la burocracia bien
pensada.
4Admirar, aplaudir y premiar un equipo basado
en el flujo de resultados medibles: el valor de
los participantes en relacin al costo.
06/02/2013
Definicin de Evo
Enfocado por completo a la entrega rpida
y temprana del valor de participante
Un proceso de gestin de proyecto
que entrega resultados evolutivos
primer-alto-valor que progresa
hacia metas deseadas, buscando
obtener y usar retroalimentacin
temprana y realista
06/02/2013
Caractersticas de Evo
4Entrega frecuente de los cambios del sistema
(pasos).
4Pasos entregados a participantes para uso real.
4Retroalimentacin obtenida de losa participantes para
determinar los prximos pasos.
4El sistema existente es usado como sistema base
inicial.
4Pasos pequeos (lo ideal es entre 2% y 5% del costo
financiero total del proyecto y del tiempo).
4Para decidir en el prximo paso una aproximacin a
los sistemas totales (cambiar algo ayuda).
4Orientado a resultados (entregar resultados es la
primera preocupacin).

06/02/2013
Ideas centrales de Evo
4Planeamiento adaptativo orientado al cliente y a la
entrega evolutiva: En breves iteraciones se efecta un
progreso a las mximas prioridades del cliente,
liberando algunas piezas tiles para que algunos
clientes apliquen su retroalimentacin.
4Clara definicin, cuantificacin, estimacin y
medida: de los requerimientos de rendimiento que
necesitan mejoras. El rendimiento incluye requisitos de
calidad tales como robustez y tolerancia y fallas, al lado
de estipulaciones cuantitativas de capacidad de carga y
ahorro de recursos.
4En Evo se espera que cada iteracin sea una re-
evaluacin de las soluciones en procura de la ms alta
relacin de valor contra costo, teniendo en cuenta tanto
la retroalimentacin como un amplio conjunto de
estimaciones mtricas.
06/02/2013
Ideas centrales de Evo
4Evo requiere igual que otras MAs, activa
participacin de los clientes. Todo debe
cuantificarse; se desalientan las apreciaciones
cualitativas o subjetivas como usable,
mantenible o ergonmico.
4A diferencia de otros MAs como Agile
Modeling, donde la metodologa es puntillosa
pero discursiva, pero discursiva, en Evo hay una
especificacin semntica y una pragmtica
rigurosa, completamente alejadas del sentido
comn, pero con la fundamentacin que tiene
por derivarse de prcticas productivas
suficientemente probadas.
06/02/2013
Principios fundamentales
de Evo
4 Evo tiene 10 principios fundamentales:
1. Se entregarn temprano y con frecuencia
resultados verdaderos, de valor para los
participantes reales.
2. El siguiente paso de entrega de Evo ser el
que proporcione el mayor valor para el
participante de ese momento.
3. Los pasos de Evo entregan los requerimientos
especificados de manera evolutiva.
4. No podemos saber cules son los
requerimientos por anticipado, pero podemos
descubrirlos ms rpidamente intentando
proporcionar valor real a participantes reales.
06/02/2013
de Evo
5. Evo es ingeniera de sistemas holstica (todos los
aspectos necesarios del sistema deben ser
completos y correctos) y con entrega a un ambiente
de participantes reales (no es slo sobre
programacin; es sobre satisfaccin del cliente).
6. Los proyectos de Evo requieren una arquitectura
abierta, porque hay que cambiar las ideas del
proyecto tan a menudo como se necesita a hacerlo,
para realmente valor a los clientes.
7. El equipo de proyecto de Evo concentrar su
energa como equipo hacia el xito del paso actual.
En este paso tendrn xito o fracasarn todos
juntos. No gastarn energas en pasos futuros hasta
que hayan dominado los pasos actuales
satisfactoriamente.
06/02/2013
de Evo
8. Evo tiene que ver con aprendizaje a partir de la
dura experiencia, tan rpido como se pueda: qu
es lo que verdaderamente funciona, qu es lo que
realmente entrega valor. Evo es una disciplina
que nos hace confrontar los problemas
tempranamente, pero que permite progresar
rpido cuando probadamente se ha hecho bien.
9. Evo conduce a una entrega temprana a tempo,
tanto porque se lo ha priorizado as desde el
inicio, y porque aprendemos desde el principio a
hacer bien las cosas.
10. Evo debera permitirnos poner a prueba nuevos
procesos de trabajo, y deshacernos
tempranamente de los que funciona mal.
06/02/2013
Elementos de Evo
06/02/2013
Elementos de Evo
4 El modelo Evo tiene 5 elementos:
Metas, Valores y Costos: Cunto y cuntos recursos. Las
metas y valores de los participantes se llaman tambin, segn
la cultura objetivos metas estratgicas, requerimientos,
propsitos, fines, ambiciones, cualidades e intenciones.
Soluciones: Banco de soluciones para alcanzar las metas y
valores dentro del rango de costos.
Estimacin de Impacto: Mapear las soluciones a metas y
costos para averiguar si se tienen las ideas adecuadas para
lograr las metas dentro de los costos.
Plan evolutivo: Inicialmente una idea general de la secuencia
a desarrollar y evolucionar hacia las metas. Los detalles
necesarios evolucionan junto con el resto del plan a medida
que se desarrolla el producto/servicio.
Funciones: Describe que hace el sistema. Son
extremadamente secundarias, ms de lo que se piensa, y
deben mantenerse al mnimo.
06/02/2013
Evo: Planguage
4 Planguage integra todas las disciplinas de solucin
del problema. Mediante l y usando el Mtodo
Planguage (PL) se pueden sujetar los medios a los
fines:
El mtodo consiste en un Lenguaje para
Planificacin.
Un conjunto de procesos para el trabajo:
Lenguaje de Procesos.
4 Proporciona un conjunto rico de formas de expresar
propsito, restricciones, estrategia, diseo, bondad,
inadecuacin, riesgo, logro y credibilidad. Se inspira
ampliamente en el ciclo Planear-Hacer-Estudiar-
Actuar (PDSA) que Walter Shewhart aplicara desde
1930 y su discpulo Walter Deming impusiera en
Japn.
06/02/2013
Evo: Planguage
4 El modelo de cascada, cuya idea subyacente de flujo
atraviesa incluso a los modelos que creen basarse en una
concepcin distinta. Gib, lo ilustra con un caso real:
Los ingenieros de Microsoft no usan su propia
herramienta de tipo PERT [MS Project], porque esta se
basa en el modelo de cascada; no pueden hacerlo
porque ellos tienen proyectos reales, con desafos,
incgnitas, requerimientos cambiantes, nuevas
tecnologas, competidores, etc. Ellos usan mtodos que
proporcionan retroalimentacin y aceptan cambios.
4 En Evo la concepcin que liga la evolucin con el
aprendizaje es esencial, que es consistente con las
modernas teoras evolutivas de John Holland y con las
teoras que rigen los sistemas adaptativos complejos. Los
ciclos de aprendizaje de Evo son exactamente lo mismo
que el ciclo Planear-Hacer-Estudiar-Actuar (PDSA).
06/02/2013
Evo: Planguage
4 Conceptos del Mtodo Planguage.
06/02/2013
Ciclos de Evo
4 En Evo se usan varios ciclos de aprendizaje:
El Ciclo de Tarea (TaskCycle): Es usado para
organizar el trabajo, optimizar la estimacin, planear y
rastrear. Constantemente verificamos si estamos
haciendo las cosas correctas, en el orden correcto al
nivel correcto de detalle. Optimizamos el trabajo con
efectividad y eficiencia. Lo Ciclos de Tarea nunca
toman ms de una semana.
El Ciclo de Entrega (DeliveryCycle): Es usado para
optimizar los requerimientos y revisar las asunciones.
Constantemente verificamos si estamos moviendo
hacia los resultados del producto correctos. Los Ciclos
de Entrega enfocan el trabajo organizado en los
Ciclos de Tarea. Los Ciclos de Entrega
normalmente toman no ms de dos semanas.
06/02/2013
Ciclos de Evo
Lnea de Tiempo (TimeLine): Es usado para guardar el
control sobre la duracin del proyecto. Nosotros
perfeccionamos el orden de Ciclos de la Entrega en la
Lnea de Tempo de tal una manera que nos acercamos
al resultado del producto en el tiempo ms corto, con un
poco retrabajo como sea posible.
Durante estos ciclos constantemente se optimiza:
+ El producto: Cmo arribar al mejor producto (de
acuerdo a la meta).
+ El proyecto: Cmo arribar a este producto efectiva y
eficientemente.
+ El proceso: Encontrando las maneras de incluso
hacerlo bien. Aprendiendo de otros mtodos y
absorbiendo esos mtodos que trabajan bien,
archivando esos mtodos que actualmente trabajan
eficazmente.
06/02/2013
Practicas de Evo: Planificando el
Ciclo de Tarea
4 A la salida del Ciclo de la Tarea semanal, esto es lo que
hace:
1. Determinar el nmero de horas que se tiene
disponible para este proyecto en el Ciclo de Tarea:
Las personas pueden trabajar menos de la semana
llena. As determinamos el nmero de horas
disponibles para lo primero del proyecto, porque
entonces conocemos cuando se puede detener la
adicin de Tareas.
2. Dividir el nmero grueso de horas disponibles en:
- Las Horas Planificarles disponibles (valor por omisin 2/3
de horas disponibles gruesas)
- Las Horas No Panificables disponibles (valor por omisin
1/3 de horas disponibles gruesas)

06/02/2013
Ciclo de Tarea
Slo planificamos esas areas que no se hacen a
menos que se hayan planificado. No planificamos
Tareas que se harn, incluso sin planificar.
3. Definir las Tareas para este ciclo usando los
Criterios de Seleccin de Tareas:
Enfocar en encontrar Tareas que son ahora muy
importantes y no perder tiempo en tareas menos
urgentes por el momento. Basndose en lo que
aprendemos de las tareas actuales, la definicin de
Tareas ms tardas podran cambiar, de que no se
planea demasiado adelantado. Usar la definicin de
Entrega para enfocar en qu trabajar en las Tareas.
4. Estimar el nmero de horas de esfuerzo necesarias
para lograr cada Tarea completamente:

06/02/2013
Ciclo de Tarea
Estimamos horas de esfuerzo. Pedir a las personas que
estimen en das, y que propongan el tiempo de
planificacin (tiempo entre empezar y terminar la Tarea).
Pedir a las personas que estimen en horas, y se
encuentra que normalmente proponen el esfuerzo (el
tiempo neto necesario para completar la Tarea). La razn
para guardar esfuerzo y tiempo de planificacin por
separado es que las causas de variacin son diferentes:
Si el esfuerzo se estima incorrectamente. es un problema
de valoracin de complejidad. Si hay menos tiempo que
el planificado, es un problema de gestin del tiempo.
Guardando stos por separado nos permite que
aprendamos.
5. Dividir la Tarea en ms de aproximadamente 6 horas
en la Tarea ms pequea:

06/02/2013
Ciclo de Tarea
Se divide el trabajo en porciones manejables. La
estimacin no es una ciencia exacta y as habr alguna
variacin en las estimaciones. No estamos limitados por
las horas exactas de esfuerzo estimadas. Slo estamos
limitados por el Resultado: al final de la semana, todos
los trabajos comprometidos se hacen. Si una tarea
toma un pedazo ms y otro un pedazo menos, quin se
preocupa? Si se tiene varias Tareas para hacer, las
variaciones pueden quedar fuera. Si se tiene una tarea
masiva de 27 horas, es ms difcil estimar y el truco del
promedio no puede salvarla ms.
6. Llenar las horas planificables disponibles con las
Tareas ms importantes:
Nunca seleccionar las Tareas menos importantes.
Siempre llenar las horas planificables disponibles
completamente.
06/02/2013
Ciclo de Tarea
7. Determinar de hecho cules son de hecho las Tareas ms
importantes para hacer y que se est seguro que el trabajo
puede hacerse en el tiempo estimado:
- Cualquier duda mina el compromiso, para que se asegura
que se puede entregar.
- Reconocer la aceptacin de la lista de tareas durante este
ciclo significa aceptar la responsabilidad del cada uno y su
equipo, y que estas tareas se habrn hecho
completamente, al final de ciclo.
En este punto, se tendr una lista de las Tareas que se harn.
Si no se puede aceptar la consecuencia de que algunas otras
Tareas no se harn, hay que hacer algo! Se pudo:
Reconsiderar las tareas.
Conseguir las ayudas adicionales para hacer algunas de
las Tareas. Tener cuidado, sin embargo que puede
costar algn tiempo transferir la Tarea a alguien ms. Si
no se planea este tiempo, no se tendr tiempo.
06/02/2013
Cules son los mayores
beneficios de Evo?
4 Control de gestin de valor.
4 Control de gestin de costos.
4 Da fuerza al pensamiento comercial en
lugar del pensamiento tcnico.
4 Flexibilidad en la gestin para re-priorizar
proyectos y gastar.
4 Mejora la cultura de mantenimiento de
sistema. Porque se mantiene a cada
paso. El riesgo es muy bajo para
hacerlo y se ve si funciona.
06/02/2013
Cules son los cambios de
tecnologa mayores de Evo?
4 Se necesita los requerimientos claros,
cuantificados para evolucionar "hacia los
requerimientos de la "vista de
participantes .
4 Proceso de pruebas: cambios rpidos,
tempranos.
4 Integracin continua del usuario.
4 Los trabajos en equipo hacia un resultado del
usuario.
4 Arquitectura Final Abierta para Evo en la
gestin Backroom (Servicios de organizacin
de datos) y Frontroom (Servicios de consulta).

06/02/2013
Cmo se maneja mejor Evo?
4 Motivar el equipo de desarrollo por
resultados.
4 Autorizar al participante para pensar en
valor.
4 Entrenar el desarrollo en Evo.
4 Equipar con herramientas de Evo.
4 Soporte para aconsejar (nuevos)
equipos.
4 Dar el presupuesto a los equipos con el
mejor valor.
06/02/2013
Cules son las trampas en
Evo?
4 No enfocando el valor real.
4 No usando la prioridad costo/valor.
4 El fracaso para entrenar y en el soporte
despus de entrenar.
4 Rindindose demasiado temprano y
recurriendo a los hbitos viejos.
4 Falta de compromiso de direccin.
4 Falta de soporte de gestin.
4 Derrotismo: rindindose en lugar de
demoler problemas.
06/02/2013
Cules son los prerrequisitos
en Evo?
4 Poltica de direccin clara.
4 Herramientas Evo (Estndares).
4 Direccin de proyecto entrenada.
4 Estructura de recompensa.
4 Objetivos cuantificados de largo plazo.
4 Plan Evo para mtodo Evo.
4 Proyectos de voluntarios aficionados.
4 La arquitectura abierta es til, pero no
es condicin inicial!
06/02/2013
Cuando no se necesita Evo
1. Los requerimientos estn claros y no habr cambios. Esto es
produccin, no desarrollo.
2. Los requerimientos son fcilmente reunidos con los recursos
disponibles. Todava Evo puede hacer que logre buenos
resultados en el tiempo ms corto.
3. El cliente puede esperar hasta que usted est listo. Por qu
pierde su tiempo mientras si puede hacer cosas ms
interesantes?.
4. El cliente no se preocupa del resultado. Nosotros debemos
contemplar este proyecto? l va a pagar?.
5. No hay que preocuparse del costo o tiempo. Pueda ser una
aficin o una vacacin.
6. El jefe no se preocupa del costo o tiempo. l probablemente no
sabe qu hacer con su dinero.
7. La gestin no sabe qu hacer con el tiempo ahorrado. Tenga
cuidado, ellos pueden frustrar su proyecto.
8. No hay Sentido de Urgencia.
06/02/2013
Resumen de Evo
4 A diferencia de otros MAs que son ms
experimentales, que no tienen mucho respaldo de
casos sistemticamente documentados, Evo es una
metodologa probada desde hace mucho tiempo, en
numerosos clientes corporativos: la NASA, Lockheed
Martin, Hewlett Packard, Douglas Aircaff, la marina
britnica. Slo DSDM y RUP han logrado un
reconocimiento comparable.
4 En Evo no hay, por ltimo, ni la sombra del carcter
ldico y la pintura de brocha gorda que se encuentran
con frecuencia en Scrum o en XP. Se trata, por el
contrario, de una metodologa que impresiona por la
precisin, relevancia o imaginacin de sus
fundamentaciones.
06/02/2013
Resumen de Evo
06/02/2013
Bibliografa sobre Evo
06/02/2013
Bibliografa sobre Evo
4 Tom Gilb: Principles of Software Engineering Management.
Addison - Wesley, 1988.
4 Tom Gilb: The Evolutionary Project Manager Handbook. Evo
Mini- Manuscript.
4 Tom Gilb: Competitive Engineering.
4 Tom Gilb: Software metrics. Chartwell - Bratt, 1976.
4 Kai Gilb: Evolutionary Project Management & Product
Development.
4 Craig Larman: Agile & Iterative Development. A Managers
Guide. Addison-Wesley 2004.
4 F Redmill: Software Projects: Evolutionary versus Big Bang
Delivery. John Wiley & Sons, 1977.
4 Tom Gilb and D. Graham: Software Inspection. Addison-
Wesley 1933.
06/02/2013
Sitios Web sobre Evo
4 http://www.Gilb.com
4 http://www.craiglarman.com
4 http://www.software.mag/archive/1999dec/Success.
html
4 http://www.gilb.com/Download/EvoProjectMan.pdf,
2003.

4 http://www.malotaux.nl/nrm/Evo
06/02/2013
Crystal
Methods
06/02/2013
Crystal Methods
4 Las metodologas Crystal fueron creadas por el
antroplogo de proyectos Alistair Cockburn, el
autor ms utilizado e influyentes en su libro Writing
effective Use Cases. Cockburn discrepa de los que
piensan que el desarrollo de software es una actividad de
ingeniera. Sostiene que ese punto de vista es de hecho
ms pernicioso que til, y lleva en una direccin
equivocada.
4 Contra esa visin ingieneril a lo Bertrand Meyer donde
interesan las especificaciones y modelos que segn l
es una perdida de tiempo, Cockburn ha alternado
diversas visiones despreocupadamente contradictorias
que lo condujeron a adoptar radicalmente XP, a
sinergizarse con DSDM o LSD, a concebir el desarrollo
de software como una forma comunitaria de poesa o a
elaborar su propia familia de Metodologas Crystal.
06/02/2013
Alistair Cockburn, creador
de Crystal Methods
Crystal Methods
06/02/2013
Crystal Methods
4 La familia Crystal dispone un cdigo de color para
marcar la complejidad de una metodologa: cuanto ms
oscuro un color, ms pesado es el mtodo. Cuanto ms
crtico es un sistema, ms rigor se requiere. El cdigo
cromtico se aplica a una forma tabular elaborada por
Cockburn que se usa en muchos MAs para situar el
rango de complejidad al cual se aplica una metodologa.
4 En la figura se muestra una evaluacin de las prdidas
que puede ocasionar la falla de un sistema y el mtodo
requerido segn este criterio. Los parmetros son
Comodidad (C), Dinero Discrecional (D), Dinero
Esencial (E) y Vidas (L). En otras palabras, la cada de
un sistema que ocasione incomodidades indica que su
nivel de criticalidad es C, mientras que si causa prdidas
de vidas su nivel es L. Los nmeros del cuadro indican el
nmero de personas afectadas a un proyecto, 20%.

06/02/2013
Crystal Methods
4 La familia de Crystal Methods
06/02/2013
Crystal Methods
4 Los mtodos se llaman Crystal evocando las facetas de
una gema: cada faceta es otra versin del proceso, y
todas se sitan en torno a un ncleo idntico. Hay cuatro
variantes de metodologas: Crystal Clear (Claro como el
cristal) para equipos de 8 o menos integrantes; Amarillo,
para 8 a 20; Naranja, para 20 a 50; Rojo, para 50 a 100.
Se promete seguir con Marrn, Azul y Violeta. La ms
exhaustivamente documentada es Crystal Clear (CC).
4 CC puede ser usado en proyectos pequeos de categora
D6, aunque con alguna extensin se aplica tambin a
niveles E8 a D10. El otro mtodo elaborado en
profundidad es el Naranja, apto para proyectos de
duracin estimada en 2 aos, descrito en Surviving
Object - Oriented Projects. Los otros dos an se estn
desarrollando. Como casi todos los otros mtodos, CC
consiste en valores, tcnicas y procesos.
06/02/2013
Crystal Methods: Crystal Clear
06/02/2013
Crystal Methods: Valores de CC
4 Los 7 valores de CC son:
1. Entrega frecuente: Consiste en entregar software a
los clientes con frecuencia, no solamente en compilar
cdigo. La frecuencia depender del proyecto, pero
puede ser diaria, semanal, mensual o lo que fuere.
La entrega puede hacerse sin despliegue, si es que
se consigue algn usuario corts o curioso que
proporcione retroalimentacin.
2. Comunicacin osmtica: Todos juntos en el mismo
cuarto. Otra variante de disponer de un diseador
senior; eso se llama Experto al Alcance de la
Oreja. Una reunin por separado para que los
concurrentes se concentren mejor, se llama El Cono
del Silencio.
06/02/2013
3. Mejora reflexiva: Tomarse un pequeo tiempo
(unas pocas horas cada semana, o una vez al mes)
para pensar bien que se est haciendo, cotejar
notas, reflexionar, discutir.
4. Seguridad personal: Hablar cuando algo molesta:
por ejemplo; decirle al manager que la agenda no es
realista, o a un colega que su cdigo necesita
mejorarse, o que sera conveniente que se bae ms
seguido. Es importante porque ayuda al grupo
descubrir sus debilidades. No es conveniente
encubrir por conciliacin y falso espritu de grupo.
La experiencia ha demostrado que estas cuestiones
se han caracterizado como una variable de confianza
y ya son parte de la literatura concerniente.
06/02/2013
5. Foco: Saber lo que se est haciendo y tener la
tranquilidad y el tiempo para hacerlo. Lo primero debe
derivarse de la comunicacin sobre direccin y
prioridades, normalmente con el Patrocinador Ejecutivo.
Lo segundo de un ambiente en que la gente no se ve
obligada a hacer otras cosas incompatibles.
6. Fcil acceso a usuarios expertos: Se ha demostrado
hace tiempo, con fuerte respaldo estadstico, la
importancia del contacto directo con expertos en el
desarrollo de un proyecto. No hay un dogma de vida o
muerte en esto , como si lo hay en XP. Un encuentro
semanal o cada 2 semanas, con llamadas telefnicas
adicionales puede ser una buena pauta. Otra variante s
que los programadores se entrenen para ser usuarios
durante un tiempo. El equipo de desarrollo, incluye de
todas maneras, un Experto en Negocios.
06/02/2013
7. Ambiente tcnico con prueba automatizada,
gestin de configuracin e integracin
frecuente: Microsoft estableci la idea de los
builds cotidianos y no es una mala prctica.
Muchos equipos giles compilan e integran
varias veces al da.
06/02/2013
Crystal Methods: Estrategias
4 Crystal Clear no requiere de estrategia o tcnica, pero
conviene tener unas cuantas para empezar. Las
estrategias comunes a otros MAs y documentadas son:
1. Exploracin de 360: Verificar o tomar una muestra del
valor de negocios del proyecto, los requerimientos, el
modelo del dominio, la tecnologa, el plan del proyecto y
el proceso. La exploracin es preliminar al desarrollo y
equivale a la fase de incepcin del RUP. Mientras que en
RUP pude tomar algunas semanas o meses, en Crystal
Clear debe tomar unos pocos das, como mucho 2
semanas. El muestreo de valor de negocios se puede
hacer verbalmente, con casos de uso u otros
mecanismos de lista; pero debe centrarse en los casos
de uso esenciales del sistema. Respecto a la tecnologa
conviene correr unos experimentos en base a lo que
Cunningham y Beck han llamado spikes
(http://c2.com/cgi/wiki?ApikeSolution).
06/02/2013
2. Victoria temprana: Es mejor buscar pequeos triunfos
iniciales que aspirar a una gran victoria tarda. La
fundamentacin de esta teora proviene de estudios
sociolgicos especficos. Normalmente la primera victoria
consiste en la construccin de un Esqueleto Ambulante.
Conviene no utilizar la tcnica de lo peor primero de
XP, porque puede bajar lo primero. La preferencia de
Cockburn es lo ms fcil primero, lo ms difcil
segundo.
3. Esqueleto ambulante: Es una transaccin que debe ser
simple pero completa. Podra ser una rutina de consulta y
actualizacin de un sistema cliente/servidor, o la
ejecucin de una transaccin en un sistema transaccional
de negocios. Un Esqueleto Ambulante no suele ser
robusto, slo camina, y carece de la carne de la
funcionalidad de la aplicacin real, que se agregar
incrementalmente.
06/02/2013
Es diferente de un Spike, porque este es la ms
pequea implementacin que demuestra un xito
tcnico plausible y despus se tira, porque puede ser
desprolijo y peligroso; un Spike slo se usa para saber si
se est yendo por un camino correcto. El Esqueleto
debe construirse con buenos hbitos produccin y
pruebas de regresin y est destinado a crecer con el
sistema.
06/02/2013
4. Rearquitectura incremental: Se ha demostrado que no
es inconveniente interrumpir el desarrollo para corregir la
arquitectura. Ms bien la arquitectura debe evolucionar
en etapas, manteniendo el sistema en ejecucin mientras
ellas se modifica.
5. Radiadores de informacin: Es una lamina pegada en
un lugar que el equipo puede observar mientras trabaja o
camina. Tiene que ser comprensible para el observador
casual, entendida de un vistazo y renovada
peridicamente para que valga la pena visitarla. Podra
mostrar el conjunto de la iteracin actual, el nmero de
las pruebas pasadas o pendientes, el nmero de casos
de uso o historias entregado, el estado de los servidores,
los resultados del ltimo Taller de Reflexin. Una variante
creativa es un sistema de semforos implementado por
Freeman, Benson y Borning.
06/02/2013
Crystal Methods: Tcnicas
4 En cuanto a las tcnicas se favorecen:
1. Entrevistas de proyectos: Se suele entrevistar a ms de
un responsable para tener visiones ms ricas. Cockburn ha
elaborado una til plantilla de dos pginas con entrevistas
que prob ser til en diversos proyectos. La idea es
averiguar cules son las prioridades, obtener una lista de los
rasgos deseados, saber cules son los requerimientos ms
crticos y cules son los ms negociables. Si se trata de una
actualizacin o correccin, saber cules son las cosas que
se hicieron bien, y merecen preservarse y los errores que no
se quieren repetir.
2. Talleres de reflexin: El equipo debe detenerse treinta
minutos o una hora, para reflexionar sobre sus
convenciones de trabajo, discutir inconvenientes y mejoras y
planear para el periodo siguiente. De aqu puede salir
materia para poner un pster como Radiador de
Informacin.
06/02/2013
3. Planteamiento Blitz: Una tcnica puede ser el Juego de
Planeamiento de XP. En este juego se ponen tarjetas indexadas en
una mesa, con una historia de usuario o funcin visible en cada una.
El grupo finge que no hay dependencias entre tarjetas y las alinea
en secuencias de desarrollo preferidas: Los programadores escriben
en cada tarjeta el tiempo estimado para desarrollar cada funcin. El
patrocinador o embajador del usuario escribe la secuencia de
prioridades, teniendo en cuenta los tiempos referidos y el valor de
negocio de cada funcin.
Las tarjetas se agrupan en periodos de tres semanas llamadas
iteraciones que se agrupan en iteraciones (releases), usualmente no
ms largas de 3 meses. Puede usarse tarjetas CRC . Cockburn
plantea otras variantes de juego como la Jam Session de
Planeamiento del Proyecto1. Las diferencias entre la versin de
Cockburn y el juego de XP son varias: en XP las tarjetas tienen
historias, en CC lista de tareas; el juego de XP asume que no hay
dependencias, el de CC que si las hay; en XP hay iteraciones de
duracin fija, en CC no se presupone nada sobre la longitud de las
iteraciones.
06/02/2013
4. Estimacin Delphi con estimaciones de pericia: La
tecnologa se llama as por analoga con el orculo de Delfos.
Fue descrita por Cockburn por primera vez en el clsico
Surving Object-Oriented Projects, considerado como uno de
los mejores libros sobre el paradigma de objetos. En el
proceso Delphi se renen los expertos responsables y
proceden como en un remate para proponer el tamao del
sistema, su tiempo de ejecucin, las fechas de entrega segn
dependencias tcnicas y de negocios y para equilibrar las
entregas en paquetes del mismo tamao. L descripcin de
remate est en el libro (3 a 4 pginas).
5. Encuentros diarios de a pie: La palabra clave es
brevedad, cinco a diez minutos como mximo. No se trata
de discutir problemas, sino de identificarlos: Los problemas
slo se discuten en otros encuentros posteriores, con la gente
que tiene ver con ellos. La tcnica se origina en Scrum. Se
deben hacer de pie para que la gente no escriba en su
notebooks, garabatee papeles o se quede dormida.
06/02/2013
6. Miniatura de procesos: La Hora Extrema fue inventada
por Peter Merel para introducir a la gente en XP en 60
minutos (http://c2.com/cgi/wiki?ExtremeHour) y
proporciona lineamientos cannicos que pueden usarse
para articular esta prctica. Una forma de presentar Crystal
Clear puede consumir entre 90 minutos y un da. La idea es
que la gente pueda degustar la nueva metodologa.
7. Grficos de quemado: Su nombre viene de los grficos de
quemado de calora de los regmenes dietticos, se usan
tambin en Scrum. Se trata de una tcnica de graficacin
para descubrir demoras y problemas tempranamente en el
proceso, evitando que se descubra demasiado tarde que
todava no se sabe cunto falta.
Para ello se hace una estimacin del tiempo faltante para
programar lo que resta con el ritmo actual, lo cual sirve para
tener dominio de proyectos en los cuales las prioridades
cambian bruscamente y con frecuencia.
06/02/2013
8. Programacin lado a lado: Mucha gente siente que la
programacin por pares de XP involucra una presin
excesiva; la versin de Crystal Clear establece proximidad,
pero cada quien se aboca a su trabajo asignado, prestando
un ojo a lo que hace su compaero, quien tiene su propia
mquina. Esta es una ampliacin de Comunicacin
Osmtica en el contexto de la programacin.
06/02/2013
Roles en CC
Diseador
Principal
Patrocinador
Usuario
Experto
Experto en
Negocios
Diseador
Programador
Crystal Methods: Roles en CC
Coordinador
Escritor
Verificador
06/02/2013
Crystal Methods: Roles en CC
4 CC tiene los 8 roles siguientes:
Patrocinador, Usuario Experto,
Diseador Principal, Diseador
Programador, Experto en negocios,
Coordinador, Verificador, Escritor.
4 En Cristal Naranja se agregan los roles:
Diseador de Interfaz de Usuario,
Diseador de Base de Datos, Experto en
Uso, Facilitador Tcnico,
Analista/Diseador de Negocios,
Arquitecto, Mentor de Diseo, Punto de
Reutilizacin.
06/02/2013
Crystal Methods: Artefactos en
CC
A pesar que no contempla el desarrollo de software
propiamente dicho, CC involucra unos 20 productos
de trabajo o artefactos. Mencionamos los ms
importantes:
1. Declaracin de la misin: Documento de un
prrafo a un pgina, describiendo el propsito.
2. Estructura del equipo: Lista de equipos y
miembros.
3. Metodologa: Comprende roles, estructura y
proceso, productos de trabajo que mantienen
mtodos de revisin.
4. Secuencia de entrega: Declaracin o diagrama de
dependencia; muestra el orden de las entregas y lo
que hay en cada una.
5. Cronograma de visualizacin y entrega: Lista,
planilla de hoja de clculo o herramienta de gestin
de proyectos.
06/02/2013
Crystal Methods: Artefactos en
CC
6. Lista de riesgos: Descripcin de riesgos por orden
descendente de prioridad.
7. Estatus del proyecto: Lista hitos, fecha prevista,
fecha efectiva y comentarios.
8. Lista de actores - objetivos: Lista de dos
columnas, planilla de hoja de clculo, diagrama de
caso de uso o similar.
9. Casos de uso anotados: Requerimientos
funcionales.
10. Archivo de requerimientos: Coleccin de
informacin indicando qu se debe construir,
quienes han de utilizarlo, de que manera
proporciona valor y qu restricciones afectan al
diseo.
06/02/2013
Crystal Methods: Resumen
4 Los mtodos Crystal no prescriben las
prcticas de desarrollo, las herramientas o los
productos que pueden usarse, pudiendo
combinarse con otro mtodos como Scrum,
XP y Microsoft Solutions Framework.
Cockburn confiesa que cuando imagin CC
pensaba proporcionar un mtodo ligero;
comparando con XP, sin embargo resulta, CC
resulta muy pesado. CC es ms fcil de
aprender e implementar; a pesar de su jerga
chocante XP es ms disciplinado, piensa
Cockburn, pero si un equipo ligero pueda
tolerar sus rigores, lo mejor ser que se mude
a XP.
06/02/2013
Bibliografa sobre Crystal
Methods
06/02/2013
Bibliografa sobre Crystal
Methods
4Alistair Cockburn: Crystal Clear: A Human-Powered
Methodology for Small Teams. Addison - Wesley
Professional - 2004.
4Alistair Cockburn: Agile Development Series: The
Cooperative Game. Addison - Wesley Professional -
2006.
4Alistair Cockburn: Agile Development Series: The
Cooperative Game. Addison - Wesley Professional -
2006.
4Alistair Cockburn: Writing Effective Use Cases.
Addison - Wesley Professional - 2000.
4Alistair Cockburn: Surviving Obejct - Oriented
Projects. Addison - Wesley Professional - 1997.

06/02/2013
Sitios Web sobre Crystal
Methods
4 http://alistair.cockburn.us/index.php/Main_P
age
4 http://alistair.cockburn.us/index.php/C
rystal_methodologies_main_foyer
4 http://members.aol.com/acockburn/
4 http://www.crystalmethodologies.org

06/02/2013
Feature
Driven
Development
06/02/2013
Feature Driven Development (FDD)
4 Feature Oriented Programming (FOP) es una tcnica de
programacin guiada por rasgos o caractersticas (features)
y centrada en el usuario, no en el programador; su objetivo
es sintetizar un programa conforme a los rasgos requeridos.
4 En un desarrollo en trminos de FOP, los objetos se
organizan en mdulos o capas conforme a rasgos. Feature
Driven Development (FDD) en cambio es un mtodo gil,
iterativo y adaptativo.
4 A diferencia de otros MAs, FDD no cubre todo el ciclo de
vida, sin solo fases de diseo o construccin y se considera
adecuado para proyectos mayores o de misin crtica.
4 FDD es, adems, marca registrada de una empresa,
Nebulon Pty. Aunque hay coincidencias con la
programacin orientada por rasgos y el desarrollo guiado
por rasgos, FDD no necesariamente implementa FOP.
06/02/2013
4 FDD no requiere de un modelo especfico de un
proceso y se complementa con otras metodologas.
Enfatiza cuestiones de calidad y define claramente
entregas tangibles y formas de evaluacin del
progreso.
4 Se le report por primera vez en un libro de Peter
Coad, Eric Lefebvre y Jeff De Luca, Java Modeling
in Color with UML; luego fue desarrollado con
amplitud en un proyecto mayor desarrollado por De
Luca, Coad y Stephen Palmer.
4 Su implementacin de referencia fuel el Singapore
Project; luego de dos aos, 3500 pginas de
documentacin y ninguna de cdigo. Naturalmente el
proyecto basado en FDD no fue un xito, y permiti
fundar el mtodo en un caso real de misin crtica.
06/02/2013
Eric Lefebvre Peter Coad
Stephen
Palmer
Jeff
De Luca
06/02/2013
FDD: Principios
4 Los principios de FDD son pocos y simples:
Se requiere de un sistema para construir sistemas, si
se pretende escalar a proyectos grandes.
Un proceso simple y bien definido trabaja mejor.
Los pasos deben ser lgicos y su mrito
inmediatamente obvio para cada miembro del equipo.
Vanagloriarse del proceso puede impedir el trabajo
real.
Los buenos procesos van hasta el fondo del asunto,
de modo que los miembros del equipo se pueden
concentrar en los resultados.
Los ciclos cortos, iterativos, orientado por rasgos
(features) son mejores.

06/02/2013
FDD: Roles
4 Hay 3 categoras de rol en FDD: roles claves, roles de
soporte y roles adicionales.
Se requiere de un sistema para construir sistemas, si
se pretende escalar a proyectos grandes.
Un proceso simple y bien definido trabaja mejor.
Los pasos deben ser lgicos y su mrito
inmediatamente obvio para cada miembro del equipo.
Vanagloriarse del proceso puede impedir el trabajo
real.
Los buenos procesos van hasta el fondo del asunto,
de modo que los miembros del equipo se pueden
concentrar en los resultados.
Los ciclos cortos, iterativos, orientado por rasgos
(features) son mejores.

06/02/2013
Roles en FDD
4 Hay 3 categoras de roles en FDD: roles claves, roles de soporte
y roles adicionales:
Roles claves:
Administrador del proyecto.
Arquitecto jefe.
Gerente de desarrollo.
Programador jefe.
Propietarios de clase.
Experto de dominio.
Roles de soporte:
Administrador de entrega.
Abogado /gur del lenguaje.
Ingeniero de construccin.
Herramentista.
Administrador del sistema
Roles adicionales:
Verificadores.
Gerentes del despliegue.
Escritores tcnicos.
06/02/2013
Roles de soporte en FDD
Gerente de
Desarrollo
Administrador
del Proyecto
Programador
Jefe
FDD: Roles claves
Propietarios
de Clase
Experto de
Dominio
Arquitecto
Jefe
06/02/2013
Roles claves en FDD
Ingeniero de
Construccin
Administrador
de Entrega
Herramentista
FDD: Roles de soporte
Administrador
del Sistema
Abogado /gur
del lenguaje
06/02/2013
Roles adicionales en FDD
Encargados de
Despliegue
Verificadores
FDD: Roles adicionales
Escritores
Tcnicos
06/02/2013
FDD: Roles
Un miembro del equipo
de FDD que asume un
rol puede tener otros
roles y un solo rol
puede ser compartido
por varios miembros
del equipo.
06/02/2013
FDD: Prcticas
4 FDD consiste en un conjunto de mejores prcticas
que distan de ser nuevas, pero se combinan de manera
original. Las prcticas cannicas son:
1. Modelado de objetos del dominio: Resultante en un
framework (armazn) cuando se agregan los rasgos.
Esta forma de modelado descompone un problema
mayor en problemas menores; el diseo y la
implementacin de cada clase y objeto o un objeto es un
problema pequeo a resolver. Cuando se combinan las
clases completas, constituyen la solucin al problema
mayor. Una forma particular de la tcnica es el modelado
en colores [CLDOO], que agrega una dimensin
adicional de visualizacin. Si bien se puede modelar en
blanco y negro, en FDD el modelado basado en objetos
es imperativo. Sus modelos principales son los
Diagramas de Clase y los Diagramas de Secuencia.
06/02/2013
FDD: Prcticas
2. Desarrollo por rasgo: Hacer simplemente que las
clases y objetos funcionen no refleja lo que el cliente
pide. El seguimiento del progreso se realiza mediante
examen de pequeas funcionalidades descompuestas
y funciones valoradas por el cliente. Un rasgo en FDD
es una funcin pequea expresada en la forma
<accin> <resultado> <por | para | de | a > <objeto>
con los operadores adecuados entre los trminos. Por
ejemplo, calcular el importe total de una venta;
determinar la ltima operacin de un cajero; validar la
contrasea de un usuario.
3. Propiedad individual de una clase (cdigo): Cada
clase tiene una sola persona nominada como
responsable por su consistencia, funcionamiento e
integridad conceptual.

06/02/2013
FDD: Prcticas
4. Equipo de Rasgos: Pequeos y dinmicamente
formados. La existencia de un grupo garantiza que un
conjunto de mentes se apliquen a cada decisin y se
tomen en cuenta mltiples alternativas.
5. Inspeccin: Se refiere al uso de los mejores
mecanismos de deteccin de fallas conocidos. FDD es
tan escrupuloso en materia de inspeccin, como lo es
Evo.
6. Construcciones regulares: Siempre se tiene un
sistema disponible. Las construcciones forman la base
a partir de la cual se van agregando nuevos rasgos.
7. Administracin de configuracin: Permite realizar
seguimiento histrico de las ltimas versiones
completas del cdigo fuente.
8. Reporte del progreso: Se comunica a todos los
niveles organizacionales necesarios.

06/02/2013
FDD: Practicas
9. Informe del avance de tareas
El Administrador de Entrega se rene con los
Programadores Jefe para que stos reporten como est el
avance de las tareas. En esta reunin, que tiene una duracin
de 30 minutos o menos, cada Programador Jefe informa de
manera verbal el avance de sus rasgos. Hacer esto de manera
verbal es bueno para que cada uno de los Programadores
Jefe se tome el tiempo de escuchar a los otros y saber dnde
estn situados los dems en el proceso de desarrollo.
Al final de la entrevista, el administrador de entrega anota los
resultados, actualiza la base de datos, y genera los informes.
El administrador de entrega informa los resultados obtenidos
semanalmente, tanto para el equipo, para el cliente, y para el
Administrador del Proyecto. Para los clientes y gerentes, el
informe debe incluir el porcentaje de avance de cada rasgo.
Para el equipo se informa cul es el desempeo del mismo.
06/02/2013
FDD: Proceso
4 FDD consiste en 5 fases secuenciales durante las cuales
se disea y se construye el sistema. La parte iterativa
soporta desarrollo gil con rpidas adapataciones a cambio
de requerimientos y necesidades del negocio. Cada fase
del proceso tiene un criterio de entrada, tareas, pruebas y
criterio de salida. Tpicamente la iteracin de un rasgo
insume de una a tres semanas. Las fases son:
1. Desarrollo de un modelo general (Develop an overall
model): Al comenzar el proceso, los Expertos del
dominio, ya estn al tanto de la visin, el contexto y de los
requerimientos del sistema a construir. A estas alturas, se
espera que existan requerimientos como casos de uso y
especificaciones funcionales (FDD no cubre este aspecto).
Los Expertos del dominio presentan un ensayo
(walkthrough) en el que los miembros del equipo y el
Arquitecto principal se informan de la descripcin de alto
nivel del sistema.
06/02/2013
FDD: Proceso
El dominio general se divide subdivide en reas ms
especficas y se define un ensayo ms detallado para cada
miembro del dominio. Luego de cada ensayo, un equipo de
desarrollo trabaja en pequeos grupos para producir
modelos de objeto de cada rea del dominio.
Simultneamente se construye un gran modelo general para
todo el sistema.
2. Construccin de la lista de rasgos (Build a feature list):
Los ensayos, modelos de objeto y documentacin de
requerimientos proporcionan la base para construir una
amplia lista de rasgos. Los rasgos son pequeos tems tiles
a los ojos del cliente. Son similares a las tarjetas de historias
de XP y se escriben en un lenguaje que todas las partes
puedan entender. Las funciones se agrupan conforme a
diversas actividades en reas del dominio especficas. La
lista de rasgos es revisada por los usuarios y patrocinadores
para asegurar su validez y exhaustividad. Los rasgos que
requieran ms de 10 das se descomponen en otras ms
pequeas.
06/02/2013
FDD: Proceso
3. Planeamiento por rasgos (Plan by feature): Incluye la
creacin de un plan de alto nivel, en el que el conjunto de
rasgos se ponen en secuencia segn su prioridad y
dependencia, y se asigna a los Programadores jefe.
Las listas se priorizan en secciones que se llaman
paquetes de diseo. Luego se asignan las clases
definidas en la seleccin del modelo general a
programadores individuales o sea Propietarios de
clase. Se pone fecha para los conjuntos de rasgos.
4. Diseo por rasgo (Feature design): El Programador
principal toma el prximo rasgo a ser diseado,
identifica las clases involucradas y se pone en contacto
con el Propietario de clase respectivo. Luego el equipo
de trabajo en la construccin de los diagramas de
secuencia respectivos. El Propietario de clase hace una
descripcin de la clase y sus mtodos.
06/02/2013
FDD: Proceso
5. Construccin por rasgo (Feature build): En esta etapa
cada Propietario de clase construye los mtodos de la
clase para cada rasgo correspondiente y luego realiza
pruebas unitarias para cada una de las clases. A su vez
realiza una inspeccin de cdigo y lego que el cdigo ha
sido implementado e inspeccionado el Propietario de
clase realiza un registro al CMS (Configuration
Mangement System) que es un repositorio donde se
almacena toda la informacin del sistema. Luego se
realiza una construccin principal en la cual se integra la
funcionalidad antes realizada. Tambin se realizan las
pruebas de integracin correspondiente.
Pueden haber grupos trabajando paralelamente y cada
iteracin puede tomar una duracin de dos semanas
como mximo.
06/02/2013
FDD: Proceso
06/02/2013
FDD: Artefactos
4 FDD proporciona un rico conjunto de artefactos para
la planificacin y el control de proyectos: formularios y
tablas con informacin real de implementacin de
FDD:
Desarrolladores:
+ Vistas de desarrollo.
Administradores de proyecto y administradores
de desarrollo:
+ Vista del plan
+ Informe sumario
+ Informe de tendencia
Informes
+ Reuniones de 30 minutos o menos Rasgos de PJ
+ Administradores de entregas Informes
06/02/2013
FDD: Herramientas
4 FDD Manager es un esfuerzo que
apunta a proporcionar todo lo que
los gerentes necesitan rastrear y
divulgar proyectos de software de
informe usando la metodologa de
software FDD ( Desarrollo Manejado
por Rasgos). Tiene soporte desde
octubre del 2006.
06/02/2013
FDD: Herramientas
4FDD Manager
06/02/2013
FDD: Herramientas
4 FDDPMA (FDD Project Management
Application). Es una aplicacin
OpenSource, para entorno Web,
multiusuario e independiente de plataforma;
que proporciona un entono de trabajo para
agilizar las tareas de gestin de proyectos
con metodologa FDD.
4 Proporciona informes grficos de evolucin
y agrupa toda la documentacin de cada
proyecto.
06/02/2013
FDD: Herramientas
4FDD Project Management Application
06/02/2013
FDD: Herramientas
4 FDD Tools ( Herramientas de FDD): El proyecto FDD
Tools apunta a producir una fuente abierta, equipo de
herramientas de plataforma cruzada que apoye la
metodologa FDD.
4 El primer Conjunto de Rasgos Mayor, una descara Alfa
0.5, ya ha sido levantada a SourceForge y ha estado
disponible para inmediata descarga. Este descarga apoya
la generacin de Proyecto que Rastrea Mapas
(Diagramas de parque de estacionamiento) desde un
archivo CSV (Valor Separado por Comas). El archivo
CSV puede crearse a mano, o, cuando usado la
herramienta generada de una exportacin MS Project que
usa un mapa especializado. Una muestra de archivo MS
Project y muestra des archivos CSV tambin estn
disponibles para descarga. Los diagramas de Project
Tracking pueden imprimirse o pueden exportarse a
formato .png o .jpg.
06/02/2013
FDD: Herramientas
4 FDD Tracker es una solucin a FDD (
Desarrollo Manejado por Rasgos) y a
Project Management (Gestin de
Proyecto). FDD Tracker apunta a
supervisar el correcto progreso de los
proyectos bajo al nivel del rasgo que
rastrea contra un plan del proyecto
global y y corrigiendo el curso cuando
sea necesario.
06/02/2013
FDD: Herramientas
4FDD Tracker
06/02/2013
FDD: Herramientas
4FDD Viewer es una utilidad para desplegar e
imprimir parques de estacionamiento .
06/02/2013
FDD: Resumen
4 FDD se utiliz por primera vez en grandes
aplicaciones bancarias de la dcada de los 90.
Los autores sugieren su uso cuando hay:
Encima de 500 desarrolladores.
Proyectos crticos.
Proyectos grandes.
Ms desarrolladores principiantes.
Ambientes que demandan la Cascada.
Proyectos nuevos o actualizaciones de sistemas
existentes, y recomiendan adaptarlo gradualmente.
4 Se asegura, aunque no hay evidencia amplia que
documente sus xitos, las grandes consultoras
suelen recomendarlo incluso para proyectos
delicados de misin crtica.
06/02/2013
FDD: Conclusiones
4 FDD es un proceso que ayuda al equipo a producir
resultados peridicos y tangibles.
4 Esta metodologa utiliza pequeos bloques que
contienen la funcionalidad del sistema, llamados
rasgos (features).
4 Organiza los bloques que estn relacionados entre s,
en una lista llamada conjunto de rasgo (feature set).
4 Hace nfasis de obtencin de resultados cada dos
semanas.
4 Incluye estrategias de planificacin, que hacen que los
rasgos puedan desarrollarse en esos lapsos.
4 Ilustra valores de negocio que el usuario final puede
entender inmediatamente.
4 FDD rastrea el progreso de un proyecto con precisin.
06/02/2013
Bibliografa sobre FDD
4Coad, P.; Lefebvre, E.; De Luca, J.: Java Modeling
in Color With UML: Enterprise Components and
Process. Prentice Hall International 1999.
4Palmer, S.R.; Felsing, J.M: A Practical Guide to
Feature - Driven Development. Prentice Hall - 2002.
4Highsmith, J: Agile Software Development
Ecosystems. Addison Wesley - 2002.

06/02/2013
Sitios Web sobre FDD
4 http://www.featuredrivendevelopment.com/
4 http://dmoz.org/Computers/Programming/Meth
odologies/Agile/Feature_Driven_Development/
4 http://www.nebulon.com/fdd/index.html
4 http://www.step-
10.com/process/APracticalGuideToFDD.html
4 http://www.sitepoint.com/article/successful-
development
4 http://www.agilemodeling.com/essays/fdd.htm

06/02/2013
Rational
Unified
Process (RUP)
06/02/2013
06/02/2013
Rational Unified Process (RUP)
4 Preguntas legtimas:
Qu hace RUP en el contexto de los MAs?
No es ms bien representativo de la filosofa a la
que el manifiesto se opone?
Estn tratando los mtodos clsicos de cooptar a
los mtodos nuevos?
4 El hecho es que existe una polmica aun en
curso respecto de si los mtodos asociados al
Proceso Unificado, y en particular RUP,
representan tcnicas convencionales y
pesadas, o si por lo contrario son adaptables a
los MAs.
06/02/2013
4 Algunos autores no admiten a esta concesin. En un
interesante anlisis crtico, Wolfang Hesse, de la
Universidad de Marburg ha sealado aunque el RUP
se precia de sus cualidades iterativas, incrementales y
centradas en la arquitectura, de hecho responde
subterrneamente a un rgido modelo de fases, no
posee capacidades recursivas suficientes y sus
definiciones dinmicas son demasiado engorrosas y
recargadas como para ser de utilidad en un contexto
cambiante.
4 El proceso de ciclo de vida del RUP se divide en 4
fases, bien conocidas llamadas Incepcin,
Elaboracin, Construccin y Transicin. Estas fases
se dividen en iteraciones, cada una de estas produce
una pieza de software demostrable. La duracin de
cada fase puede extenderse de 2 semanas a 6 meses.
06/02/2013
4 Philippe Kruchten, impulsor del famoso modelo de
vistas 4 +1 de RUP, ha participado en el famoso
debate de los gures, afirmando que RUP es
particularmente apto para ambas clases escenarios.
4 Recprocamente, 4 + 1 tiene cabida en cabida casi en
todos los mtodos basados en arquitectura
desarrollados recientemente por el SEI (Software
Engineering Insitute).
4 Highsmith, comentando la movilidad de RUP de un
campo a otro, seala que nadie, en apariencia, est
dispuesto a conceder agilidad a sus rivales; RUP
pretende ser gil y tal vez lo sea. De hechos los
principales textos que analizan los MAs, acostumbran
a incluir a RUP como uno de los ms representativos, o
como un mtodo que no se puede ignorar.
06/02/2013
Modelo de Arquitectura: 4 + 1
vistas
4Los modelos son instrumentos para visualizar,
especificar, construir y documentar la arquitectura
del sistema.
4Cada vista es parte de un modelo
Vista
Lgica
Vista de
Realizacin
Vista de
Procesos
Vista de
Despliegue
Vista de
Casos de Uso
06/02/2013
06/02/2013
RUP: Fundadores
Grady Booch Ivar Jacobson James Rumbaugh
Philippe Kruchten
Kent Hartman
06/02/2013
Proceso Unificado Rational
Pruebas funcionales
Pruebas de desempeo
Gestin de requisitos
Gestin de cambios y
configuracin
Ingeniera de Negocio
Ingeniera de datos
Diseo de interfaces
Objectory Process
1987 - 1996
Rational Objectory Process
1996 - 1997
Rational Unified Process
1998
UML
Enfoque Ericsson
06/02/2013
RUP: Principios
4 RUP est basado en 6 principio clave:
Adaptar el proceso: El proceso debe adaptarse a las
caractersticas propios del proyecto y/o organizacin.
El tamao, el tipo y las regulaciones que lo conducen
influirn en el diseo especfico.
Balancear prioridades: Los requerimientos de los
diversos inversores pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe
encontrarse un balance que satisfaga los deseos de
todos.
Colaboracin entre equipos: desarrollo de software
no lo hace una nica persona sino mltiples equipos.
Debe haber una comunicacin fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes,
resultados, etc.
06/02/2013
RUP: Principios
Demostrar valores iterativamente: Los proyectos se
entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la
estabilidad y calidad del producto, y se refina la direccin del
proyecto.
Elevar el nivel de abstraccin: Este principio dominante
motiva el uso de conceptos reutilizables tales como patrones
del software, lenguajes 4GL o esquemas (frameworks) por
nombrar algunos. Esto previene a los ingenieros de software
de ir directamente de los requisitos a la codificacin de
software a la medida del cliente. Un nivel alto de abstraccin
tambin permite discusiones sobre diversos niveles
arquitectnicos. stos se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con
UML.
Enfocarse en la calidad: El control de calidad no debe
realizarse al final de cada iteracin, sino en todos los aspectos
de la produccin.
06/02/2013
RUP: Caractersticas
4 RUP tiene 3 caractersticas esenciales:
Esta dirigido por los Casos de Uso.
Est centrado en la arquitectura.
Es iterativo e incremental.
+ Proceso dirigido por Casos de Uso: Los Casos de Uso
son una tcnica de captura de requerimientos en trminos
de importancia para el usuario y no slo en trminos de
funciones. Se define un Caso de Uso como un fragmento
de funcionalidad del sistema que proporciona al usuario un
valor aadido. Los Casos de Uso representan los
requerimientos funcionales del sistema.
En RUP los Casos de Uso no son slo una herramienta
para especificar los requisitos del sistema. Tambin guan
su diseo, implementacin y prueba. Los Casos de Uso
constituyen un elemento integrador y una gua del trabajo
como se muestra en la figura siguiente:
06/02/2013
RUP: Proceso dirigido por Casos
de Uso
Los Casos de Uso integran el trabajo
06/02/2013
RUP: Proceso centrado en la
arquitectura
+ Proceso centrado en la arquitectura: La arquitectura de un
sistema es la organizacin o estructura de sus partes ms
relevantes, lo que permite tener una visin comn entre todos
los involucrados (desarrolladores y usuarios) y una perspectiva
clara del sistema completo, necesaria para controlar el
desarrollo.
La arquitectura involucra los aspectos estticos y dinmicos
ms significativos del sistema, est relacionada con la toma de
decisiones que indican cmo tiene que ser construido el
sistema y ayuda a determinar en qu orden. Adems la
definicin de la arquitectura debe tomar en consideracin
elementos de calidad del sistema, rendimiento, reutilizacin y
capacidad de evolucin por lo que debe ser flexible durante
todo el proceso de desarrollo. La arquitectura se ve
influenciada por la plataforma software, sistema operativo,
gestor de bases de datos, protocolos, consideraciones de
desarrollo como sistemas heredados. Muchas de estas
restricciones constituyen requisitos no funcionales del sistema.

06/02/2013
RUP: Proceso iterativo e
incremental
+ Proceso iterativo e incremental: El equilibrio correcto entre los
Casos de Uso y la arquitectura es algo muy parecido al equilibrio de
la forma y la funcin en el desarrollo del producto, lo cual se consigue
con el tiempo. Para esto, la estrategia que se propone en RUP es
tener un proceso iterativo e incremental en donde el trabajo se
divide en partes ms pequeas o mini proyectos. Permitiendo que el
equilibrio entre Casos de Uso y arquitectura se vaya logrando
durante cada mini proyecto, as durante todo el proceso de
desarrollo. Cada mini proyecto se puede ver como una iteracin (un
recorrido ms o menos completo a lo largo de todos los flujos de
trabajo fundamentales) del cual se obtiene un incremento que
produce un crecimiento en el producto.
Una iteracin puede realizarse por medio de una cascada como se
muestra en la figura. Se pasa por los flujos fundamentales
(Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin
existe una planificacin de la iteracin, un anlisis de la iteracin y
algunas actividades especficas de la iteracin. Al finalizar se realiza
una integracin de los resultados con lo obtenido de las iteraciones
anteriores
06/02/2013
incremental
Requerimientos
Anlisis y Diseo
Implementacin
Pruebas
Evaluacin
Cada iteracin
produce un
producto
ejecutable
06/02/2013
incremental

Una iteracin RUP
06/02/2013
incremental

Proceso iterativo e incremental
06/02/2013
RUP: Estructura del proceso
4 El proceso puede ser descrito en dos dimensiones o
ejes:
Eje horizontal: Representa el tiempo y es
considerado el eje de los aspectos dinmicos del
proceso. Indica las caractersticas del ciclo de vida del
proceso expresado en trminos de fases, iteraciones
e hitos. Se puede observar en la figura que RUP
consta de cuatro fases: Inicio, Elaboracin,
Construccin y Transicin. Como se mencion
anteriormente cada fase se subdivide a la vez en
iteraciones.
Eje vertical: Representa los aspectos estticos del
proceso. Describe el proceso en trminos de
componentes de proceso, disciplinas, flujos de trabajo,
actividades, artefactos y roles.
06/02/2013
RUP: Estructura del proceso
06/02/2013
RUP: Estructura dinmica
4 RUP se repite a lo largo de una serie de ciclos que constituyen
la vida de un producto. Cada ciclo concluye con una
generacin del producto para los clientes. Cada ciclo consta
de cuatro fases: Inicio, Elaboracin, Construccin y Transicin.
Cada fase se subdivide a la vez en iteraciones, el nmero de
iteraciones en cada fase es variable.
4 Cada fase se concluye con un hito bien definido, un punto en
el tiempo en el cual se deben tomar ciertas decisiones crticas
y alcanzar las metas clave antes de pasar a la siguiente fase,
ese hito principal de cada fase se compone de hitos menores
que podran ser los criterios aplicables a cada iteracin. Los
hitos para cada una de las fases son: Inicio Objetivos del
Ciclo de vida; Elaboracin Arquitectura del Ciclo de
vida; Construccin Capacidad de Operacin Inicial;
Transicin Lanzamiento del Producto. Las fases y sus
respectivos hitos se ilustran en la figura.
06/02/2013
RUP: Estructura dinmica
06/02/2013
RUP: Fases
4 RUP divide el proceso en cuatro fases, dentro de las
cuales se realizan varias iteraciones en nmero variable
segn el proyecto y en las que se hace un mayor o menor
hincapi en los distintas actividades:
Inicio (incepcin): Durante la fase de inicio se define
los objetivos del ciclo de vida del proyecto y las
necesidades de cada participante, se define el modelo
del negocio y el alcance del proyecto. Se identifican
todos los actores y Casos de Uso, y se disean los
Casos de Uso ms esenciales (aproximadamente el
20% del modelo completo). Se desarrolla, un plan de
negocio para determinar que recursos deben ser
asignados al proyecto.
Tpicamente es una fase breve que puede durar unos
pocos das o pocas semanas.
06/02/2013
RUP: Fase de elaboracin
Elaboracin: El propsito de la fase de elaboracin es analizar el
dominio del problema, establecer los cimientos de la arquitectura,
desarrollar el plan del proyecto y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema
final. Este prototipo debe contener los Casos de Uso crticos
identificados en la fase de inicio. Tambin debe demostrarse que se
han evitado los riesgos ms graves.
Se establecen criterios de evaluacin que habr de cumplir al final:
+ Respecto a los requisitos:
Se han identificado? Se han detallado lo suficiente?
+ En cuanto a la arquitectura:
+ Satisface los requisitos? Es robusta?
+ Los riesgos:
+ Se han eliminado los crticos? Se ha completado la lista?
+ Evaluar el proyecto:
+ Se puede fijar un precio y una fecha de entrega?

06/02/2013
RUP: Fase de elaboracin
Elaboracin: El propsito de la fase de elaboracin es analizar el
dominio del problema, establecer los cimientos de la arquitectura,
desarrollar el plan del proyecto y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema
final. Este prototipo debe contener los Casos de Uso crticos
identificados en la fase de inicio. Tambin debe demostrarse que se
han evitado los riesgos ms graves.
Se establecen criterios de evaluacin que habr de cumplir al final:
+ Respecto a los requisitos:
Se han identificado? Se han detallado lo suficiente?
+ En cuanto a la arquitectura:
Satisface los requisitos? Es robusta?
+ Los riesgos:
Se han eliminado los crticos? Se ha completado la lista?
+ Evaluar el proyecto:
+ Se puede fijar un precio y una fecha de entrega?

06/02/2013
RUP: Fase de construccin
Construccin: La finalidad principal de esta fase es
alcanzar la capacidad operacional del producto de
forma incremental a travs de las sucesivas
iteraciones. Durante esta fase todos los
componentes, caractersticas y requisitos deben ser
implementados, integrados y probados en su
totalidad, obteniendo una versin aceptable del
producto.
RUP considera que esta fase es un proceso de
manufactura, en el que se deponer nfasis en la
administracin de recursos, y el control de costos,
agenda y calidad. Los resultados de esta fase
(versiones alfa, beta y otras versiones de prueba).
Se debe compilar tambin una versin de entrega.
Es la fase ms prolongada de todas.
06/02/2013
RUP: Fase de Transicin
Transicin: La finalidad de la fase de transicin
es poner el producto en manos de los usuarios
finales, para lo que se requiere desarrollar
nuevas versiones actualizadas del producto,
completar la documentacin, entrenar al usuario
en el manejo del producto, y en general tareas
relacionadas con el ajuste, configuracin,
instalacin y facilidad de uso del producto.
La fase consiste en la una prueba beta piloto,
despacho del producto a mercadeo, distribucin
y ventas.
Se llama transicin porque transfiera a manos del
usuario, pasando del entorno de desarrollo al de
produccin.
06/02/2013
RUP: Estructura esttica
4 Un proceso de desarrollo de software
define quin hace qu, cmo y cundo.
RUP define cuatro elementos:
Los roles, que responden a la pregunta
Quin?
Las actividades que responden a la pregunta
Cmo?
Los productos que responden a la pregunta
Qu? y
Los flujos de trabajo de las disciplinas que
responde a la pregunta Cundo?
06/02/2013
RUP: Estructura esttica
4Artefactos

4Roles

4Actividades

4Flujos de trabajo

06/02/2013
Flujos, Trabajadores,
Actividades y Artefactos
Detalle de flujo:
Anlisis del Problema
Flujo de trabajo:
Requerimientos
Actividades
Trabajadores
Artefactos
06/02/2013
RUP: EE: Artefactos
4 Un artefacto es cualquier tipo de informacin producida,
modificada o usada por los desarrolladores. Son las
entradas y salidas de las actividades. Se construye en
forma incremental.
Tipos de artefactos: Un artefacto puede ser un
documento, un modelo o un elemento de modelo:
+ Diagramas UML.
+ Cdigo fuente.
+ Ejecutables.
+ Casos de prueba
+ Etc.
Los modelos son los artefactos bsicos que producen
los flujos (incluyen otros artefactos).
06/02/2013
RUP: EE: Roles
4 Un rol define el comportamiento y responsabilidades
de un individuo, o de un grupo de individuos
trabajando juntos como un equipo. Una persona
puede desempear diversos roles, as como un
mismo rol puede ser representado por varias
personas.
4 Las responsabilidades de un rol son tanto el llevar a
cabo un conjunto de actividades como el ser el
dueo de un conjunto de artefactos.
4 RUP define grupos de roles, agrupados por
participacin en actividades relacionadas. Estos
grupos son:

06/02/2013
Roles de soporte en RUP
Gestores
Analistas
Personal de
Apoyo
RUP: Roles
Probadores
Otros roles
Desarrolladores
06/02/2013
RUP: EE: Actividades
Una actividad es una unidad tangible de trabajo que se asigna
a un rol en un flujo de trabajo. Ej.: Crear o modificar un
artefacto. Las actividades tienen un objetivo concreto,
normalmente expresado en trminos de crear o actualizar
algn producto.
Una actividad lleva entre un par de horas y un par de das,
involucra un solo trabajador y un nmero pequeo de
artefactos.
Las actividades se consideran en la planificacin y evaluacin
del progreso del proyecto.
Ejemplos:
+ Planificar una iteracin: Administrador de proyecto.
+ Encontrar actores y casos de uso: Especificador de
casos de uso.
+ Revisar el diseo: Revisor de diseo.
+ Ejecutar pruebas de rendimiento: Probador.

06/02/2013
RUP: EE: Actividades
4 Un actividad dentro de un flujo de trabajo:
Implica responsabilidad bien definida para un rol.
Produce un resultado bien definido (artefactos).
Representa una unidad de trabajo con lmites
bien definidos.
4 Conjuntos de Actividades
Captura del vocabulario comn.
Desarrollo del Plan de Gestin de
Requerimientos.
Bsqueda de Actores y Casos de Uso.
Desarrollo de Visin.
Prototipar Interfaz.
06/02/2013
Asignacin de Actividades
Recurso
Rol Actividad
Pedro
Diseador Diseo de Objetos
Mara
Autor de Casos de Uso Detallar un Caso de Uso
Juan
Diseador de Casos de Uso Disear un Caso de Uso
Jos
Revisor de Diseo Revisar el Diseo
Luca
Arquitecto Anlisis de Arquitectura
Diseo de Arquitectura
06/02/2013
Una lista de actividades,
trabajadores y artefactos
constituye un proceso.
Un flujo de trabajo es
una secuencia de
actividades que produce
un resultado valioso.
No siempre es posible
representar flujos de
trabajo.
RUP: EE: Flujos de trabajo
06/02/2013
4Organizan las actividades fundamentales de
gestin y desarrollo del proyecto
Flujos de desarrollo: Modelado del
negocio, requerimientos, anlisis y diseo,
implementacin, pruebas, despliegue.
Flujos de gestin y soporte: Gestin del
proyecto, gestin de configuraciones,
entorno.
4Al contrario de lo que ocurre con las fases, las
distintas actividades del equipo de desarrollo
se pueden solapar en el tiempo.
06/02/2013
Flujos de Desarrollo
Flujos de Gestin
y soporte
Organizacin
a lo largo del
Contenido
Organizacin a lo largo del Tiempo
06/02/2013
RUP: EE: Flujos de Trabajo
Modelado del Negocio: Con este flujo de
trabajo pretendemos llegar a un mejor
entendimiento de la organizacin donde se va a
implantar el producto. Los objetivos del
modelado de negocio son:
+ Entender la estructura y la dinmica de la
organizacin para la cual el sistema va ser
desarrollado (organizacin objetivo).
+ Entender el problema actual en la
organizacin objetivo e identificar potenciales
mejoras.
06/02/2013
+ Asegurar que clientes, usuarios finales y
desarrolladores tengan un entendimiento comn
de la organizacin objetivo.
+ Derivar los requisitos del sistema necesarios para
apoyar a la organizacin objetivo.
4 Para lograr estos objetivos, el modelo de negocio
describe como desarrollar una visin de la nueva
organizacin, basado en esta visin se definen
procesos, roles y responsabilidades de la organizacin
por medio de un modelo de Casos de Uso del
negocio y un Modelo de Objetos del Negocio. Como
complemento a estos modelos, se desarrollan otras
especificaciones tales como un Glosario.
06/02/2013
+ Asegurar que clientes, usuarios finales y
desarrolladores tengan un entendimiento comn
de la organizacin objetivo.
+ Derivar los requisitos del sistema necesarios para
apoyar a la organizacin objetivo.
Para lograr estos objetivos, el modelo de negocio
describe como desarrollar una visin de la nueva
organizacin, basado en esta visin se definen
procesos, roles y responsabilidades de la organizacin
por medio de un modelo de Casos de Uso del
negocio y un Modelo de Objetos del Negocio. Como
complemento a estos modelos, se desarrollan otras
especificaciones tales como un Glosario.
06/02/2013
Requerimientos: Este es uno de los flujos de
trabajo ms importantes, porque en l se establece
qu tiene que hacer exactamente el sistema que
se construye. En esta lnea los requerimientos son
el contrato que se debe cumplir, de modo que los
usuarios finales tienen que comprender y aceptar
los requisitos que especifiquemos.Los objetivos del
flujo de datos Requerimientos es:
+ Establecer y mantener un acuerdo entre clientes
y otros stakeholders sobre lo que el sistema
podra hacer.
+ Proveer a los desarrolladores de un mejor
entendimiento de los requerimientos del sistema.
06/02/2013
+ Definir el mbito del sistema.
+ Proveer una base para la planeacin de los contenidos
tcnicos de las iteraciones.
+ Proveer una base para estimar costos y tiempo de
desarrollo del sistema.
+ Definir una interfaz de usuarios para el sistema, enfocada
a las necesidades y metas del usuario.
Los requerimientos se dividen en dos grupos:
+ Los requerimientos funcionales representan la
funcionalidad del sistema. Se modelan mediante
diagramas de Casos de Uso.
+ Los requerimientos no funcionales representan
aquellos atributos que debe exhibir el sistema, pero que
no son una funcionalidad especfica. Por ejemplo
requerimientos de facilidad de uso, fiabilidad, eficiencia,
portabilidad, etc.

06/02/2013
Anlisis y Diseo: El objetivo de este flujo de trabajo es
traducir los requisitos a una especificacin que describe
cmo implementar el sistema. Los objetivos del anlisis y
diseo son:
+ Transformar los requisitos al diseo del futuro sistema.
+ Desarrollar una arquitectura para el sistema.
+ Adaptar el diseo para que sea consistente con el
entorno de implementacin, diseando para el
rendimiento.
El anlisis consiste en obtener una visin del sistema que
se preocupa de ver qu hace, de modo que slo se
interesa por los requisitos funcionales. Por otro lado el
diseo es un refinamiento del anlisis que tiene en
cuenta los requisitos no funcionales, en definitiva cmo
cumple el sistema sus objetivos.
06/02/2013
Implementacin: En este flujo de trabajo se
implementan las clases y objetos en archivos fuente,
binarios, ejecutables y dems. Adems se deben hacer
las pruebas de unidad: cada implementador es
responsable de probar las unidades que produzca. En
cada iteracin habr que hacer lo siguiente:
+ Planificar qu subsistemas deben ser implementados y
en que orden deben ser integrados, formando el Plan
de Integracin.
+ Cada implementador decide en que orden implementa
los elementos del subsistema.
+ Si encuentra errores de diseo, los notifica.
+ Se prueban los subsistemas individualmente.
+ Se integra el sistema siguiendo el plan.
06/02/2013
Pruebas: Este flujo de trabajo es el encargado de
evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el
producto al final del proceso de desarrollo, sino que debe
ir integrado en todo el ciclo de vida. Esta disciplina brinda
soporte a las otras disciplinas. Sus objetivos son:
+ Encontrar y documentar defectos en la calidad del
software.
+ Generalmente asesora sobre la calidad del software
percibida.
+ Provee la validacin de los supuestos realizados en el
diseo y especificacin de requisitos por medio de
demostraciones concretas.
+ Verificar las funciones del producto de software segn lo
diseado.
+ Verificar que los requisitos tengan su apropiada
implementacin.
06/02/2013
Despliegue: El objetivo de este flujo de trabajo es producir
con xito distribuciones del producto y distribuirlo a los
usuarios. Este flujo de trabajo se desarrolla con mayor
intensidad en la fase de transicin, ya que el propsito del flujo
es asegurar una aceptacin y adaptacin sin complicaciones
del software por parte de los usuarios. Su ejecucin inicia en
fases anteriores, para preparar el camino, sobre todo con
actividades de planificacin, en la elaboracin del manual de
usuario y tutoriales Las actividades implicadas incluyen:
+ Probar el producto en su entorno de ejecucin final.
+ Empaquetar el software para su distribucin.
+ Distribuir el software.
+ Instalar el software.
+ Proveer asistencia y ayuda a los usuarios.
+ Formar a los usuarios y al cuerpo de ventas.
+ Migrar el software existente o convertir bases de datos.
06/02/2013
Gestin del proyecto: La Gestin del proyecto es el arte
de lograr un balance al gestionar objetivos, riesgos y
restricciones para desarrollar un producto que sea acorde
a los requisitos de los clientes y los usuarios. Los
objetivos de este flujo de trabajo son:
+ Proveer un marco de trabajo para la gestin de
proyectos orientados al software.
+ Proveer guas prcticas realizar planeacin,
contratar personal, ejecutar y monitorear el
proyecto.
+ Proveer un marco de trabajo para gestionar riesgos.
La planeacin de un proyecto posee dos niveles de
abstraccin: un plan para las fases y un plan para
cada iteracin.
06/02/2013
Configuracin y control de cambios: La finalidad de
este flujo de trabajo es mantener la integridad de todos
los artefactos que se crean en el proceso, as como de
mantener informacin del proceso evolutivo que han
seguido.
Entorno: La finalidad de este flujo de trabajo es dar
soporte al proyecto con las adecuadas herramientas,
procesos y mtodos. Brinda una especificacin de las
herramientas que se van a necesitar en cada momento,
as como definir la instancia concreta del proceso que se
va a seguir. En concreto las responsabilidades de este
flujo de trabajo incluyen:
+ Seleccin y adquisicin de herramientas
+ Establecer y configurar las herramientas para que
se ajusten a la organizacin.
06/02/2013
+ Configuracin del proceso.
+ Mejora del proceso.
+ Servicios tcnicos
El principal artefacto que se usa en este flujo de
trabajo es el caso de desarrollo que especifica para
el proyecto actual en concreto, como se aplicar el
proceso, que productos se van a utilizar y como van
a ser utilizados. Adems se tendrn que definir las
guas para los distintos aspectos del proceso, como
pueden ser el modelado del negocio y los Casos de
Uso, para la interfaz de usuario, el diseo, la
programacin, el manual de usuario.
06/02/2013
RUP: Prcticas
4 RUP identifica 6 buenas prcticas con las que
define una forma efectiva de trabajar para los
equipos de desarrollo de software:
1. Administracin de requerimientos: RUP brinda
una gua para encontrar, organizar, documentar, y
seguir los cambios de los requisitos funcionales y
restricciones. Utiliza una notacin de Caso de Uso
y escenarios para representar los requerimientos.
2. Desarrollo de iterativo de software: Desarrollo
del producto mediante iteraciones con hitos bien
definidos, en las cuales se repiten las actividades
pero con distinto nfasis, segn la fase del
proyecto. Permite identificar riesgos y problemas
tempranamente, y en consecuencia, reaccionar
frente a ellos.
06/02/2013
RUP: Prcticas
3. Desarrollo basado en componentes: La creacin de sistemas
orientados al software requiere dividir el sistema en componentes
con interfaces bien definidas, que posteriormente sern
ensamblados para generar el sistema. Esta caracterstica en un
proceso de desarrollo permite que el sistema se vaya creando a
medida que se obtienen o se desarrollan sus componentes. La
reutilizacin de componentes permite asimismo ahorros
substanciales en tiempo, esfuerzo y recursos.
4. Modelado visual del software: UML es un lenguaje para
visualizar, especificar, construir y documentar los artefactos de un
sistema software. Es un estndar de la OMG. Utilizar
herramientas de modelado visual facilita la gestin de dichos
modelos, permitiendo ocultar o exponer detalles cuando sea
necesario. El modelado visual tambin ayuda a mantener la
consistencia entre los artefactos del sistema: requerimientos,
diseos e implementaciones. En resumen, el modelado visual
ayuda a mejorar la capacidad del equipo para gestionar la
complejidad del software.
06/02/2013
RUP: Prcticas
5. Verificacin continua de la calidad: Es importante que la calidad
de todos los artefactos se evale en varios puntos durante el proceso
de desarrollo, especialmente al final de cada iteracin. En esta
verificacin las pruebas juegan un papel fundamental y se integran a
lo largo de todo el proceso. Para todos los artefactos no ejecutables
las revisiones e inspecciones tambin deben ser continuas.
6. Gestin de cambios y trazabilidad: El cambio es un factor de
riesgo crtico en los proyectos de software. Los artefactos software
cambian no slo debido a acciones de mantenimiento posteriores a
la entrega del producto, sino que durante el proceso de desarrollo,
especialmente importantes por su posible impacto son los cambios
en los requisitos. Por otra parte, otro gran desafo que debe
abordarse es la construccin de software con la participacin de
mltiples desarrolladores, posiblemente distribuidos geogrficamente,
trabajando a la vez en un lanzamiento (release), y quizs en
distintas plataformas. La ausencia de disciplina rpidamente
conducira al caos. La Gestin de Cambios y de Configuracin es
la disciplina de RUP encargada de este aspecto.
06/02/2013
RUP: Conclusiones
4 RUP se basa en Casos de Uso para describir lo
que se espera del software y est muy orientada a
la arquitectura del sistema, con bastante
documentacin y se basa en UML (Lenguaje
Unificado de Modelamiento) .
4 La metodologa RUP es ms apropiada para
proyectos grandes, dado que requiere un equipo
de trabajo capaz de administrar un proceso
complejo en varias etapas. En proyectos
pequeos, es posible que no sea posible cubrir los
costos de dedicacin del equipo de profesionales
necesario.
4 RUP es un proceso grande y genrico. Para poder
usarlo hay que adaptarlo a las caractersticas de
la empresa. Existen versiones reducidas de RUP.
06/02/2013
RUP: Conclusiones
4 A RUP se le imputa que es demasiado locuaz, pero
que carece de lineamientos claros para la
implementacin, en comparacin a otros MAs como
Crystal que tiene documentacin detallada y roles
segn diversas escalas del proyecto. En RUP muchas
decisiones quedan a criterio del usuario.
4 Al tener RUP el nmero de artefactos y herramientas
el recortarlo y adaptarlo no es una tarea fcil. El
proceso de implementacin es complejo.
4 Existe una versin reducida de RUP, dX de Robert
Martin, en la cual se ha tomado experiencias de otros
MAs, reduciendo al mnimo indispensable los
artefactos de RUP y (en acto heroico) usando tarjetas
de fichaje en lugar de UML imitando a XP.
4 RUP ha sido combinado con EVO, Scrum, MSF y
cualquier metodologa imaginable.
06/02/2013
Bibliografa sobre RUP
4 Jacobson, I.; Booch, G.; Rumbaugh J.: El Proceso Unificado
de Desarrollo de Software. Addison Wesley 2000.
4 Kruchten, P.: The Rational Unified Process: An Introduction.
Addison Wesley - 2000.
4 Ambler, Scott W.; Nalbone, John; Vizdos Michael J.: The
Enterprise Unified Process: Extending the Rational Unified
Process Prentice Hall PTR - 1999.
4 Eeles, Peter; Houston, Kelli; Kozaczynski, Wojtek: Building
J2EE Applications with the Rational Unified Processby.
Addison Wesley Professional 2002.
4 Rational Software Corporation: Product: Rational Software
Corporation 2002.
4 Rational Software Corporation: Rational Unified Process.
Best Practices for Software Development Teams 1998.
4 Augustine, Liz: Using the Rational Unified Process (RUP)
Successfully for Small Development Projects. Rational
Software 2001.

06/02/2013
4 Augustine, Liz: Using the Rational Unified Process (RUP)
Successfully for Small Development Projects. Rational
Software 2001.
4 Gibbs, Dennis R.: Project Management with the IBM
Rational Unified Process: Lessons from the Trenches.
IBM Press 2006.
4 Kroll, Per; Kruchten, Philippe: The Rational Unified
Process Made Easy: A Practitioner's Guide to the RUP.
Addison Wesley Professional - 2003.
4 Pollice, Gary: Using the Rational Unified Process for Small
Projects: Expanding upon eXtreme Programming. Rational
Software 2001.
4 Arlow, Jim; Neustadt, Ila: UML 2 and the Unified Process:
Practical Object - Oriented Analysis and Design (Second
Edition). Addison-Wesley 2005.

06/02/2013
06/02/2013
Sitios Web sobre RUP
4 http://www.rational.com/products/rup/whitepapers.jsp
4 http://www-306.ibm.com/software/awdtools/rup/
4 http://en.wikipedia.org/wiki/Rational_Unified_Process
4 http://www.ciao.es/Rational_Rose_Enterprise_Edition__34
4797
4 http://www.humbertocervantes.net/intranet/rup/index.htm
4 http://www-306.ibm.com/software/rational/
4 http://www-128.ibm.com/developerworks/rational/library/
05/1206_ibmstaff/

06/02/2013
Dynamic
Systems
Development
Method (DSDM)
06/02/2013
Dynamic Systems
Development Method (DSDM)
4 En base a los trabajos de Jennifer Stapleton
directora del DSDM Consortium; DSDM
(Mtodo Dinmico de Desarrollo de
Sistemas) se ha convertido en el framework
del Desarrollo Rpido de Aplicaciones
(DRA) ms popular en Gran Bretaa y se ha
llegado a promover como el estndar de facto
para el desarrollo de soluciones de negocios
sujetos a mrgenes de tiempo estrechos. Se
calcula que uno de cada 5 desarrolladores en
Gran Bretaa utilizan DSDM y que de 500
empresas mayores lo han adaptado.
06/02/2013
Dynamic Systems
4 Adems de un mtodo, DSDM proporciona una
estructura (framework) completa para controles de
RAD y lineamientos para su uso. DSDM se puede
complementar con otros MAs como XP, RUP o
Microsoft Solutions Framework o combinacin de
ellas.
4 DSDM es relativamente antiguo en el campo de los
MAs y constituye una metodologa madura que ya va
por su cuarta versin. Se dice ahora que DSDM
significa Dynamic Systems Delivery Method. Ya no
se habla de sistemas sino de soluciones y en lugar de
priorizar el desarrollo se prefiere enfatizar la entrega.
El libro ms reciente que sintetiza la prcticas se llama
DSDM: Business Focused Development.
06/02/2013
Dynamic Systems
4 DSDM es el acrnimo que da nombre a un modelo de
procesos para el desarrollo de sistemas de software,
desarrollado y concebido por el denominado DSDM
Consortium, que se fund en Inglaterra en 1994, y
que actualmente tiene presencia en Inglaterra, EE.UU.
Benelux, Dinamarca, Francia y Suiza; y con inters y
contactos para futuras representaciones en Australia,
India y China
4 Es un modelo que estuvo representado en la firma del
Manifiesto gil. Arie van Bennekum, firmante del
manifiesto, era miembro del consorcio en Benelux,
consultor y formador de DSDM. En 2001, ao del
Manifiesto gil, DSDM public la versin 4.1 de su
modelo, y se consider una metodologa gil; y
aunque mantuvo las siglas, cambi la denominacin
original (Dynamic Systems Development Method)
por Framework for Business Centred Development.

06/02/2013
DSDM: Fundadores
Jennifer Stapleton Arie van Bennekum
06/02/2013
Dynamic Systems
4 DSDM utiliza la participacin comprometida
del usuario en un desarrollo iterativo y una
aproximacin incremental que responde a
requerimientos cambiantes para desarrollar un
un sistema de software que satisfaga los
requerimientos de un negocio en tiempo y
presupuesto.
4 DSDM fue desarrollado en Gran Bretaa en
los aos 90 por el consorcio DSDM de
vendedores y expertos en desarrollo de
sistemas de informacin. DSDM tiene carcter
no lucrativo. La primera versin fue entregada
en enero de 1995. La versin 4.2 actualmente
en funcin fue entregada en abril del 2006.
06/02/2013
DSDM: Principios
4 DSDM tiene 9 principios que son piedras angulares de
su desarrollo:
1. Es imperativo el compromiso activo del usuario: para
el funcionamiento de un proyecto eficiente y eficaz, donde
los usuarios y los reveladores comparten un lugar de
trabajo, para poder tomar las decisiones con exactitud.
2. Los equipos de DSDM deben tener el poder de tomar
decisiones: que son importantes para el progreso del
proyecto, sin necesidad de la aprobacin de alto nivel que
se espera.
3. DSDM se centra en la entrega frecuente de productos:
asumiendo que entregar algo bastante bueno es
siempre mejor que entregar todo perfectamente en el
extremo. Entregando el producto con frecuencia en una
fase temprana del proyecto, puede ser probado y ser
repasado, donde pueden tenerse en cuenta el registro de
prueba y documento de revisin para la prxima iteracin o
fase.
06/02/2013
DSDM: Principios
4. El criterio esencial para la aceptacin de los
entregables es la adecuacin a a los propsitos de
negocios: No tanto se dirige a entregar un sistema
perfecto que trata todas las necesidades posibles del
negocio, sino enfocando los esfuerzos en la
funcionalidad crtica.
5. El desarrollo es iterativo e incremental: conducido
por regeneracin de los usuarios para converger en
una solucin eficaz del negocio.
6. Todos los cambios durante el desarrollo son
reversibles.
7. El alcance y los requisitos de alto nivel deben ser
la lnea de base antes de que el proyecto comience.
Esto permite que los requerimientos de detalle
cambien segn se necesiten y que los esenciales se
capten tempranamente.
06/02/2013
DSDM: Principios
8. La prueba se realiza a travs del ciclo de vida del
proyecto: La prueba es tambin incremental. Se
recomienda particularmente la prueba de regresin, de
acuerdo con el estilo evolutivo del desarrollo.
9. Es esencial una estrategia colaborativa y
cooperativa entre todos los participantes: Las
responsabilidades son compartidas y la colaboracin
entre usuarios y desarrolladores no deben tener
fisuras.

DSDM tambin se basa en otros principios asumidos:
1. No se construye ningn sistema perfectamente en el
primer intento
2 La entrega del proyecto debe estar a tiempo, con el
presupuesto y con buena calidad
06/02/2013
DSDM: Principios
3. DSDM requiere solamente que cada paso del
desarrollo sea terminado suficientemente sin tener en
cuenta que el paso siguiente comience.
4. Las tcnicas de gerencia y de desarrollo de proyecto
se incorporan en DSDM.
5. DSDM se puede tambin utilizar en nuevos proyectos
y para ampliar sistemas actuales.
6. La valoracin de riesgo debe centrarse en la funcin
del negocio que es entregada, no en el proceso de la
construccin, ni en los artefactos del proceso del
desarrollo (tales como requerimientos y documentos
del diseo).
7. La gerencia recompensa la entrega del producto ms
bien que la terminacin de la tarea.
8. La valoracin se debe basar en funcionalidad del
negocio en vez de lneas del cdigo.
06/02/2013
DSDM: Tcnicas centrales
4 La idea dominante detrs de DSDM es inversa a la que
existen en otras metodologas y resulta al principio
contraria a la intuicin: en lugar de ajustar tiempo y
recursos para lograr cada funcionalidad, en esta
metodologa tiempo y recursos se mantienen constantes
y sa ajusta a la funcionalidad de acuerdo con ello.
4 Esto se expresa a travs de algunas tcnicas centrales
como las siguientes:
Timeboxing (Uso de Cajas de Tiempo):
Timeboxing es una de las tcnicas del proyecto
DSDM. Se utiliza para apoyar las metas principales de
DSDM para realizar el desarrollo de una IS en el tiempo,
dentro de presupuesto y con la calidad deseada. La idea
principal detrs de timeboxing es dividir el proyecto en
porciones, cada uno con un presupuesto fijo y una fecha
de expedicin.
06/02/2013
Para cada porcin se seleccionan un nmero de
requerimientos que se dan la prioridad segn el
principio de MoSCoW. Dado que el tiempo y el
presupuesto son fijos, las nicas variables
restantes son los requerimientos. Tan es as que
si un proyecto est funcionando con el tiempo o
dinero disponibles, los requerimientos con la
prioridad ms baja se omiten.
MoSCoW:
MoSCoW representa una manera de dar la
prioridad a artculos. En el contexto de DSDM la
tcnica de MoSCoW se utiliza para dar la
prioridad a requerimientos. Son las siglas en las
cuales se basa:

06/02/2013
1. MUST have (Debe tener): Son los requerimientos
fundamentales del sistema. Todos los rasgos que
son clasificados en este grupo debe llevarse a
cabo. Estos rasgos son un botn de muestra que
si ellos no se entregan, el sistema simplemente no
trabajar.
2. SHOULD have (Debera tener): Son los
requerimientos importantes para los que habr
una solucin a corto plazo. Los rasgos de esta
prioridad son importantes para el sistema y
contribuyen con un valor significativo, pero puede
omitirse si las restricciones de tiempo ponen en
peligro la entrega de cualquier rasgo "Debe
tener.

06/02/2013
3. COULD have (Podra tener): Podran quedar
fuera del sistema si no hay ms remedio. Estos
rasgos refuerzan al sistema con artculos
funcionales que pueden reasignarse fcilmente
a una caja de tiempo ms tarde.
4. WANT to have but wont have this time
around (Se desea que tenga pero no se
tendr en esta vuelta): Son los requerimientos
valorados pero pueden esperar. Normalmente
estos rasgos slo sirven un grupo limitado de
usuarios y son de pequeo valor.
06/02/2013
Prototyping (Prototipado):
Esta tcnica se refiere a la creacin de prototipos del
sistema bajo desarrollo en una fase temprana del
proyecto. Permite el descubrimiento temprano de defectos
en el sistema y permite a los usuarios futuros al
manejo de prueba del sistema. Esta manera de
comprometer al usuario, es uno de los factores
dominantes de xito de DSDM, o de cualquier proyecto de
desarrollo del sistema para esa materia.
Testing (Prueba):
Un tercer aspecto importante de la meta de DSDM es la
creacin de una IS con la calidad buena. Para
comprender una solucin de calidad buena, DSDM
defiende la comprobacin a lo largo de cada iteracin.
Desde que DSDM es una herramienta y tcnica el mtodo
independiente, el equipo del proyecto es libre escoger su
propio mtodo de direccin de prueba, por ejemplo TMap.
06/02/2013
Workshop (Taller):
Es una de las tcnicas del proyecto DSDM que
tiene como objetivo reunir a los diferentes
stakeholders (involucrados) del proyecto para
juntos discutir requerimientos, funcionalidades y la
comprensin mutua. En un taller los stakeholders
vienen juntos y discuten el proyecto.
Modeling (Modelamiento):
Esta tcnica es esencial y es intencionalmente
utilizada visualizar la representacin diagramtica
de un aspecto especfico del sistema o del rea
comercial que se est desarrollando. El
modelamiento da una comprensin mejor para el
equipo del proyecto DSDM sobre un dominio del
negocio.
06/02/2013
Configuration Management (Gestin de la
Configuracin):
Una buena puesta en prctica de esta tcnica de
Gestin de la Configuracin es importante para
la naturaleza dinmica de DSDM. Puesto que hay
ms de una cosa que se maneja en seguida
durante el proceso de desarrollo del sistema, y los
productos frecuentemente estn entregndose en
una proporcin muy rpida, los productos
necesitan, por consiguiente, ser controlados
estrictamente cuando ellos logran la realizacin
(parcial).
06/02/2013
DSDM: Proceso
4 A diferencia de otros Mas, DSDM ha
desarrollado sistemticamente el
proceso de su propia implementacin en
una empresa. El proceso de Examen
de Salud (Health Check) de DSDM se
divide en dos partes que interrogan
sucesivamente sobre la capacidad de
una organizacin para adoptar el mtodo
y la forma como ste responde a la
necesidades una vez que el proyecto
est encaminado. Un Examen de Salud
puede consumir entre tres das y un mes
de trabajo de consultora.
06/02/2013
DSDM: Fases
4 DSDM consiste en tres fases secuenciales: el
preproyecto, el ciclo vital del proyecto y el post
projecto. La fase del proyecto de DSDM es la ms
elaborada de las tres fases. y se ajusta a la
funcionalidad de acuerdo con ella:
Fase 1: El Preproyecto: En esta fase del
preproyecto se identifican los proyectos, se observa
el financiamiento del proyecto y se asegura la
comisin del proyecto. La manipulacin de estas
ediciones en un primer tiempo evita problemas en
fases posteriores del proyecto.
Fase 2: El ciclo vital del proyecto: Est
representada por 5 etapas de Ingeniera de
Software. Las primeras dos etapas, el estudio de
viabilidad y el estudio del negocio son las fases
secuenciales que se complementan el uno con el
otro.
06/02/2013
DSDM: Fases
Despus de que se hayan concluido estas fases,
el sistema se desarrolla iterativo e incremental en
las etapas la iteracin, el diseo y de la iteracin y
de la puesta en prctica modelo funcionales de la
estructura.
Fase 3: El Post proyecto: La fase de post projecto
asegura el sistema funciona con eficacia y
eficientemente. Esto se observa por el mantenimiento,
los perfeccionamientos y los arreglos segn principios
de DSDM. El mantenimiento se puede ver como
desarrollo de continuacin basado en la naturaleza
iterativa e incremental de DSDM. En vez de acabar el
proyecto en un ciclo el proyecto puede volver
generalmente a las fases o a las etapas anteriores
para poder refinar el paso anterior y los productos
entregables.
06/02/2013
DSDM: Etapas del CV
4 La fase del ciclo de vida de DSDM consiste en 5
etapas que son:
1. Estudio de factibilidad: Se evala el uso de
DSDM o cualquier otra metodologa conforme al
tipo de proyecto, variables organizacionales y de
personal. Si se opta por DSDM se analizan las
posibilidades tcnicas y riesgos. Se preparan
como productos un informe de viabilidad y un
plan sumario para el desarrollo. Si la tecnologa
no se conoce bien, se construye un pequeo
prototipo para ver que pasa. No se espera que el
estudio completo consuma ms de unas pocas
semanas. Es mucho para un mtodo gil, pero
menos de lo que demandan algunos mtodos
clsicos.
06/02/2013
DSDM: Etapas del CV
2. Estudio del negocio: Se analizan las caractersticas del
negocio y la tecnologa. La estrategia recomendada
consiste en el desarrollo de talleres. Donde se espera
que los expertos del cliente consideren las facetas del
sistema y acuerden sus prioridades de desarrollo. Se
describen los procesos del negocio y las clases de
usuario en una Definicin del rea de Negocios. Se
espera as reconocer e involucrar a gente clave de la
organizacin en una etapa temprana. La definicin utiliza
descripciones de alto nivel, como diagramas Entidad
Interrelacin o modelos de objetos de negocios. Otros
productos son la Definicin de la Arquitectura y el Plan
de Bosquejo del Prototipado. La definicin
arquitectnica es un primer bosquejo y se admite que
cambie en el curso del proyecto DSDM. El plan debe
establecer la estrategia del prototipado de las siguientes
etapas y un plan para la gestin de configuracin.
06/02/2013
DSDM: Etapas del CV
3. Iteracin del modelo funcional: En cada iteracin se
planea el contenido y la estrategia, se realiza la iteracin y
se analizan los resultados pensando en los siguientes. Se
realiza tanto el anlisis como el cdigo; se construyen los
prototipos y en base a la experiencia se mejoran los
modelos del anlisis. Los prototipos no se descartan por
completo, sino son gradualmente mejorados hacia la
calidad que debe tener el producto final. Se produce como
resultado un Modelo Funcional, conteniendo el cdigo del
prototipo y sus modelos de anlisis. Se realizan pruebas
constantemente. Hay otros 4 productos emergentes:
(1) Funciones Priorizadas que es una lista de funciones
entregadas al fin de cada iteracin;
(2) los Documentos de Revisin del Prototipado
Funcional que renen los comentarios de los usuarios
sobre el incremento actual para ser considerados en
iteraciones posteriores;

06/02/2013
DSDM: Etapas del CV
(3) los Requerimientos Funcionales que son listas
que se construyen para ser tratadas en fases
siguientes;
(4) el Anlisis de Riesgo de Desarrollo Ulterior que
es un documento importante en la fase de iteracin del
modelo, porque en adelante los problemas que se
encuentren sern ms difciles de tratar.
4. Iteracin de diseo y construccin: Aqu es donde se
construye la mayor parte del sistema. El producto es un
Sistema Probado, que cumple con por lo menos el
mnimo de requerimientos acordados conforme a las
reglas MoSCoW. El diseo y la construccin son
iterativos y el diseo y los prototipos funcionales son
revisados por los usuarios. El desarrollo ulterior se
atiene a sus comentarios.
06/02/2013
DSDM: Etapas del CV
5. Implementacin: El sistema se transfiere del ambiente de
desarrollo al de produccin. Se entrenan a los usuarios que
ponen las manos en el sistema. Eventualmente la fase puede
llegarse a iterarse. Otros productos son el Manual del Usuario y
el Reporte de Revisin del Sistema. A partir de aqu hay cuatro
cursos de accin posibles:
(1) Si el sistema satisface todos los requerimientos el desarrollo
ha terminado.
(2) Si quedan muchos requerimientos sin resolver se puede
correr el proceso nuevamente desde el comienzo.
(3) Si se ha dejado de lado alguna prestacin no crtica, el
proceso se puede correr desde la iteracin funcional del modelo
hacia adelante.
(4) Si algunas cuestiones tcnicas no pudieron resolverse por
falta de tiempo se puede iterar desde la fase de diseo y
construccin.
06/02/2013
DSDM : Naturaleza iterativa e
incremental
4 Junto al timeboxing y la priorizacin de requerimientos, el DSDM
tambin proporciona un acercamiento iterativo e incremental para
el desarrollo de la IS. Cada iteracin se orienta hacia un conjunto
de nuevas funcionalidades, y cada incremento puede retrocederse
cuando/si es necesario. Si una funcionalidad grande se ha
descubierto durante el desarrollo y que no podra llevarse a cabo,
podra ser posible volver a empezar definiendo los nuevos
requerimientos en el Estudio Comercial. Otro podra ser el caso
cuando la funcionalidad tuvo que ser omitida durante la Iteracin
del Modelo Funcional anterior, debido al tiempo y/o restriccin del
presupuesto. Slo cuando se encuentran todos los requerimientos,
necesarios para completar el proyecto y las metas comerciales, el
proyecto pasa a la fase del post - proyecto.
4 Debido a la naturaleza iterativa de DSDM, es esencial mantener
una buena gestin de los requerimientos y la direccin de la
configuracin en su lugar a lo largo del proyecto entero. Esto
asegura que el proyecto lleva a cabo los requerimientos deseados
de la manera deseada ,como se decidi en las fases tempranas
del proyecto.

06/02/2013
Roles de soporte en DSDM
Usuario
Embajador
Programadores
Visionario
DSDM: Roles principales
Patrocinador
Ejecutivo
Facilitador
Coordinador
tcnico
Escriba
06/02/2013
DSDM : Factores crticos para
el xito
4 Dentro de DSDM se identifican varios factores que
son de gran importancia asegurar proyectos
exitosos.
Factor 1: Primero hay la aceptacin de DSDM
por direccin mayor y otros empleados. Esto
asegura que diferentes actores del proyecto
son motivados para iniciar y permanecer
involucrados a lo largo del proyecto.
Factor 2: El segundo factor que sigue
directamente de esto y es el compromiso de la
direccin para asegurar el compromiso del
usuario final. La aproximacin del prototipado
requiere un compromiso fuerte y especializado
del usuario final para probar y juzgar los
prototipos funcionales.
06/02/2013
el xito
Factor 3: Este factor es entonces el equipo del
proyecto. Este equipo tiene que ser compuesto de
miembros hbiles que forman una unin estable.
Un problema importante es el fortalecimiento del
equipo del proyecto. Esto significa que el equipo
(o uno o ms de sus miembros) tiene el poder y
posibilidad de tomar las decisiones importantes
con respecto al proyecto sin tener que comunicar
las propuestas formales a direccin ms alta y
puede utilizar bien el tiempo consumido. Para que
el equipo del proyecto pueda ejecutar un proyecto
exitoso, tambin necesitan la tecnologa correcta
para dirigir el proyecto. Esto significa un ambiente
de desarrollo, herramientas de gestin del
proyecto, etc.
06/02/2013
el xito
Factor 4: Finalmente DSDM tambin formula que se
requiere de una relacin a favor entre cliente y
vendedor. Esto va por ambos proyectos que se
realizan internamente dentro de las compaas o por
los contratistas externos. Una ayuda que asegura una
relacin de apoyo podra ser ISPL (Information
Services Procurement Library).
06/02/2013
DSDM : Resumen
4 Desde mediados de la dcada de los 90 hay
abundantes estudios de casos, sobre todo en Gran
Bretaa, y la adecuacin de DSDM para desarrollo
rpido est suficientemente probada. El equipo mnimo
de DSDM es de 2 personas y puede llegar a 6, pero
pude haber varios equipos en un proyecto. El mnimo
de dos personas involucra que un equipo consiste en
un programador y un usuario. El mximo de 6 es el
valor que se encuentra en la prctica. DSDM se ha
aplicado a grandes y pequeos. La precondicin para
su uso en sistemas grandes es su particin en sus
componentes que pueden ser desarrollados por
equipos normales.
4 Se ha elaborado una particular combinacin de DSDM
y XP, y se ha llamado a esta mixtura EnterpriseXP,
termino acuado por Mike Griffiths de Quadrus
Development (http://www.enterprisexp.org).

06/02/2013
DSDM : Resumen
4 Se atribuye a Kent Beck haber afirmado que la
comunidad de DSDM, ha constituido una imagen
corporativa mejor que la del mundo de XP, y que sera
conveniente aprender de esa experiencia. Tambin hay
documentos conjuntos de DSDM y Rational, con
participacin de Jennifer Stapleton, que demuestran la
compatibilidad del modelo DSDM con RUP, a despecho
de sus fuertes diferencias terminolgicas.
4 En el sitio del DSDM Consortion hay documentos
especficos sobre la conveniencia de la metodologa
con Microsoft Solutions Framework; se trata
detalladamente sobre el MSF y los MAs. Tambin hay
casos de xito (particularmente el de Fujitsu European
Repair Center) en que se emplearon Visual Basic
como lenguaje, SQL Server como gestor de BD, y
Windows como plataforma de desarrollo e
implementacin (http://www.dsdm.org).
06/02/2013
Bibliografa sobre DSDM
4Stapleton, Jennifer: DSDM: Business Focused
Development. DSDM Consortium 2003.
4Stapleton, Jennifer: DSDM Dynamic Systems
Development Method: The Method in Practice.
Addison Wesley 1997.
4Stapleton, Jennifer; Constable, Peter: DSDM: A
framework for business centered development.
Addison Wesley 1997.
4Stapleton, Jennifer; Williams, Shirley: Experiences of
introducing a CASE tool into undergraduate teaching
of systems analysis and design . John Wiley & Sons,
Inc. 1992.
4Stahl, Vlter: Desarrollo de Software Dirigido Por
Modelos. Wiley 2006.
4DSDM Consortium: Handbook: DSDM V4.2 2003
4DSDM Consortium: DSDM Altern Pocket Book 2007

06/02/2013
06/02/2013
Sitios Web sobre DSDM
4 http://www.dsdm.org
4 http://www.enterprisexp.org
4 http://www.linkedin.com/in/jenniferstapleton
4 http://www.dsdm.nl/en/products/version_4_front_page.asp
4 http://archive.bita-center.com/2003/bennekum.htm
4 http://www.navegapolis.net/content/view/361/59/

06/02/2013
Adaptive
Software
Development
(ADS)
06/02/2013
Adaptive Software
Development (ASD)
4 ASD es un proceso de desarrollo de software que
creci fuera de trabajo de desarrollo rpido de
aplicaciones, trabajo de Jim Highsmith y SAM
Bayer. ASD incorpora el principio que la
adaptacin continua del proceso al trabajo actual
es la situacin normal.
4 ASD substituye el ciclo tradicional de la cascada
por una serie de repeticin de especula,
colabora, y aprende ciclos. Este ciclo dinmico
prev aprendizaje continuo y la adaptacin al
estado emergente del proyecto. Las
caractersticas de un ciclo vital de ASD son que
es misin enfocada, basada en rasgo, iterativo,
cajas de tiempo, gestin de riesgo, y tolerancia de
cambios.

06/02/2013
Adaptive Software
Development (ASD)
4 Jim Highsmith consultor de Cutter
Consortion, desarroll ASD hacia el ao 2000
con la intencin primaria de ofrecer una
alternativa a la idea, propia de CMM nivel 5, de
que la optimizacin es la nica solucin para
problemas de complejidad creciente. Este
mtodo gil pretende abrir una tercera va entre
el desarrollo monumental de software y el
desarrollo accidental o entre la burocracia y
la adhocracia. Highsmith afirma que
deberamos buscar el rigor estrictamente
necesario ; para ello hay que situarse en
coordenadas apenas un poco fuera del caos y
ejerce menos del control que el se cree
necesario.

06/02/2013
ASD: Fundadores
Sam Bayer
Jim Highsmith
06/02/2013
Adaptive Software
Development (ASD)
4 Jim Highsmith ha pasado muchos aos trabajando
con metodologas predictivas. Por la experiencia
adquirida en ellas concluy que son profundamente
defectuosas: particularmente para los negocios
modernos.
4 Su reciente libro Adaptive Software Development:
Collaborative Approach to Managing Complex
Systems enfoca en la naturaleza adaptable de las
nuevas metodologas, con un nfasis particular en
aplicar las ideas que se originaron en el mundo de los
sistemas complejos adaptables (normalmente
conocida como teora del caos). No proporciona el
tipo de prcticas detalladas como lo hace XP, pero
proporciona la base fundamental de por qu el
desarrollo adaptable es importante y las
consecuencias a los ms profundos niveles de la
organizacin y la gerencia.
06/02/2013
ASD: Prediccin y Adaptacin
Gestin predictiva y adaptable: premisas
Predictiva Adaptable
El prototipado y el retrabajo son
ms caros que el valor que
aportan.
El prototipado y el retrabajo
aportan ms valor de lo que
cuestan.
Es posible saber con detalle que
es lo que se quiere construir.
Sistemas o productos nuevos o
con gran componente de
innovacin.
Estabilidad relativa del entorno y
por tanto de los requerimientos.
Entorno tecnolgico o de mercado
de innovacin muy rpida.
La materia prima en poca o nada
maleable.
La naturaleza de los componentes
permite modificar el producto.
Producto de escasa economa de
escala: el beneficio esperado ms
de la eficiencia que del valor.
Buena economa de escala.
06/02/2013
ASD: Prediccin y Adaptacin
Gestin: Predictiva - Adaptable
Predictiva Adaptable
Requisitos detallados. Visin general del
producto.
Planificacin. Adaptacin.
Requerimientos estables. Evolucin sobre prototipos
incrementales.
Seguimiento y control. Autogestin.
Divisin y especializacin. Equipo multi - disciplinar.
06/02/2013
ASD: Objetivos
4 As pues tenemos una metodologa con 4
objetivos claros (independientemente de que el
proyecto sea un xito):
1. Concienciar a la organizacin de que debe
esperar cambio e incertidumbre y no orden y
estabilidad.
2. Desarrollar procesos iterativos de gestin del
cambio.
3. Facilitar la colaboracin y la interaccin de las
personas a nivel interpersonal, cultural y
estructural.
4. Marcar una estrategia de desarrollo rpido de
aplicaciones pero con rigor y disciplina.
06/02/2013
ASD: Metas
4 Para ayudar a las organizaciones a lograr el xito,
el Desarrollo del Software Adaptable (ASD)
Highsmith propone seis metas primarias:
1. La Cultura Adaptable:
La primera meta es ofrecer una alternativa a la
creencia que la optimizacin es la nica
solucin a los problemas complejos en
aumento. Las culturas perfeccionistas creen
que ellas estn en el mando, que ellos pueden
imponer el orden en la incertidumbre alrededor
de ellos. El orden impuesto es el producto de la
disciplina de una ingeniera rigurosa y
determinstica, los procesos manejados por
causa-y-efecto.
06/02/2013
ASD: Metas
La idea alternativa es la de una cultura adaptable o
bsqueda para ver a las organizaciones como
sistemas adaptables complejos, y de crear un orden
emergente fuera de una red de individuos
interconectados. Un aumento en las aproximaciones
al reconocimiento de un mundo incierto y complejo
permite pasar de ser el toque de difuntos de la
muerte de un gerente a ser parte de una estrategia
reconocida y aceptada.
2. Estructuras Adaptables:
La segunda meta es ofrecer una serie de
estructuras o modelos para ayudar a una
organizacin a emplear los principios adaptables.

06/02/2013
ASD: Metas
Por ejemplo, el Ciclo de Vida de Desarrollo Adaptable
es un estructura que refuerza los conceptos y
proporciona una manera prctica de pasar del
conceptual a lo prctico. Mientras hay otros tipos de
ciclos de vida iterativos, que no se basan en los
conceptos adaptables sino en el determinismo del
corto-ciclo
Hay una cierta sinergia que une la iteracin con las
ideas adaptables para combatir la complejidad. Las
estructuras se complementan por una discusin de
varias tcnicas (los grupos de enfoque de cliente, por
ejemplo). Sin embargo, el enfoque est en las
estructuras, no en un compendio de tcnicas.
06/02/2013
ASD: Metas
3. La Colaboracin Adaptable:
La tercera meta es establecer colaboracin
- la interaccin de las personas con similar y
a veces los intereses dismil, para crear e
innovar conjuntamente - como el vehculo
orgnico por generar las soluciones
emergentes a los problemas de desarrollo
del producto. Ser eficaz al equipo de rasgo,
al equipo de producto, y en los niveles de
empresa, la colaboracin debe dirigirse a
las relaciones interpersonales, culturales, y
estructurales.
06/02/2013
ASD: Metas
4. La Escala Adaptable:
La cuarta meta de Desarrollo del Software Adaptable es
mantener un camino para organizaciones que necesitan
usar un acercamiento adaptable en proyectos ms
grandes. Porque en el Desarrollo de la Aplicacin
Rpido (RAD) las aproximaciones tenan una reputacin
de evitar toda disciplina y rigor, fueron relegados por
muchos diseadores para ser usados en solamente
proyectos no crticos. En los proyectos reales que requieren
rigor y disciplina; RAD era para jugar. El desarrollo
adaptable trabaja en situaciones de la vida real en que la
incertidumbre y complejidad crean la necesidad por un
acercamiento que es adaptable y escalable. Un
componente mayor para este desafo es la habilidad de
moverse desde un flujo de trabajo del ciclo de vida de
desarrollo orientado a procesos, hacia uno basado en una
estacin de trabajo e informacin.
06/02/2013
ASD: Metas
5. La Direccin Adaptable:
Las circunstancias son definidas por la cultura. La
cultura de direccin del Control - Mando se ha vuelto
anticuada, en parte debido a las tendencias culturales
ms amplias hacia los estilos de direccin flexibles,
participacin ms amplia para decidir actuando, y
fortalecimiento, pero tambin debido a un solo hecho
pragmtico: La direccin del control - mando no puede
procesar conocimiento e informacin lo bastante
rpido en la nueva economa. As que, la ltima meta
es ofrecer un nuevo, adaptable estilo de direccin que
Highsmith llama la Direccin - Colaboracin, para
reemplazar el Control - Mando. La habilidad de
adaptarse y moverse rpidamente requiere que esa
"direccin" reemplace el "orden" y "colaboracin"
reemplazan el "mando.
06/02/2013
ASD: Metas
6. El Rigor Adaptable:
En una cultura perfeccionista, el rigor creciente (la
mejora del proceso) y la estabilizacin es la meta final.
Las culturas perfeccionistas tienden a ver el mundo
como negro o blanco, con una pequea sala para el
gris. Si no es riguroso, debe ser catico (o inmaduro,
para usar el lenguaje del Instituto de Ingeniera de
Software).
Una cultura adaptable reconoce el gris. Los
investigadores han acuado una frase para esta rea
gris turbulenta entre el orden y el caos al borde del
caos. Est en esta variable, enredada, el polglota
excitante que la emergencia pasa. En el campo de la
biologa evolutiva, por ejemplo, los cientficos postulan
que esos adelantos evolutivos mayores ocurren en
esta regin compleja al borde de caos.

06/02/2013
ASD: Metas
En una cultura adaptable, la meta de rigor es
mantener el equilibrio en este borde, proporcionando
justamente bastante estabilidad que obligan a
mantenerse fuera del caos - pero nada ms. Las
organizaciones adaptables entienden la necesidad
simplemente por mayor rigor. Este equilibrio no viene
de un compromiso de principios, pero si de una
comprensin de cmo las fuerzas de optimizacin
dibujan las mismas fuentes de energa necesarias
para alimentar la emergencia. Demasiado poco rigor
produce el caos. Demasiada emergencia e innovacin
se ahogan.
06/02/2013
ASD: Aspectos claves
4 ASD presupone que las necesidades del cliente son
siempre cambiantes. La iniciacin de un proyecto involucra
definir una misin para l, determinar las caractersticas y
las fechas y descomponer el proyecto en una serie de
pasos individuales, cada uno de los cuales puede abarcar
entre 4 y 8 semanas: los pasos iniciales deben verificar el
alcance del proyecto; los tardos tienen que ver con el
diseo de una arquitectura, la construccin del cdigo, la
ejecucin de las pruebas finales y el despliegue.
4 Los aspectos claves de ASD son:
1. Un conjunto no estndar de artefactos de misin
(documentos para ti y para mi), incluyendo una visin
del proyecto, una hoja de datos, un perfil de la misin
del producto y un esquema de su especificacin.
2. Un ciclo de vida inherentemente iterativo.
3. Cajas de tiempo, con tiempos cortos de entrega
orientados por el riesgo.
06/02/2013
ASD: Ciclo de vida
4 Un ciclo de vida es una iteracin, este ciclo se
basa en componentes y no en tareas, es limitado
en el tiempo, orientado a riesgos y tolerante al
cambio. Basado en componentes significa
concentrarse en el desarrollo de software que
trabaje, construyendo pieza por pieza. En este
paradigma el cambio es bienvenido y necesario,
pues se concibe como la oportunidad de aprender
y ganar as una ventaja competitiva; de ningn
modo es algo que puede ir en detrimento del
proceso y sus resultados.
4 Highsmith introdujo un nuevo vocabulario para el
manejo de proyectos, por ejemplo, el ciclo de vida
deber contar con tres fases solapadas no lineales:
especular, colaborar y aprender.
06/02/2013
ASD: CV: Especular
4 Especular
Highsmith prefiere usar especular en vez de
planificar ya que piensa que la palabra
"planificacin" se usa cuando se sabe
exactamente hacia dnde nos encaminamos, pero
en la realidad de los CAS (Sistemas Adaptables
Complejos) tenemos una visin apasionada pero
poco clara de lo que queremos, ya que los
resultados son naturalmente imprevisibles. En la
planificacin tradicional, las desviaciones del plan
son errores que deben corregirse. En un ambiente
adaptable, en cambio, las desviaciones nos guan
hacia la solucin correcta. Segn l, descubrimos
lo que necesitamos mientras se desarrolla el
trabajo.

06/02/2013
ASD: CV: Especular
4 En esta fase se fija un rumbo a ser seguido en funcin
a las entregas que se irn realizando. En cada
iteracin se aprendern nuevas funcionalidades, se
entendern viejas cuestiones y cambiarn los
requerimientos. Gracias a la especulacin ASD,
permite administrar proyectos de alto cambio y
desarrollo rpido, que se encuentran al borde del
caos. El carcter adaptativo permite pequeas
desviaciones en un sentido por lo que Highsmith
sugiere que cada ciclo se componga de una mixtura
de entre funcionalidades crticas, tiles y opcionales
previendo los posibles retrasos que pueden existir
mediante el movimiento de las funcionalidades de
menor prioridad a futuros ciclos - y grandes
desviaciones en otro, las cuales son utilizadas para
explorar el dominio y de la aplicacin, que pueden
llevar a cambiar el rumbo del proyecto.
06/02/2013
ASD: Ciclo de vida
El Ciclo de Vida de Highsmith
06/02/2013
ASD: CV: Colaborar
4 Colaborar
Highsmith usa la palabra colaborar en vez de
construir ya que opina que la actividad ms
importante de un equipo es trabajar juntos, y no
contar con una lista de tareas a ejecutarse. Sostiene
que el poder del equipo no consiste en las fortalezas
individuales de sus miembros, sino ms bien en la
cooperacin abierta y generosa para lograr el
objetivo ms importante: el cumplimiento de la
misin del proyecto. En este ambiente imprevisible
se necesita que las personas colaboren de la mejor
manera para tratar con la incertidumbre. La atencin
de la gerencia es menor en lo que tiene que hacer la
gente, y mayor sobre la comunicacin alentadora
para que las personas puedan proponer, ellas
mismas, las respuestas creativas.
06/02/2013
ASD: CV: Colaborar
4 ASD define un Componente como un grupo de
funcionalidades o entregables a ser desarrollados durante
un ciclo iterativo. Durante cada iteracin el equipo colabora
intensamente a fin de liberar la funcionalidad deseada.
Existe tambin la posibilidad de explorar nuevas alternativas,
realizar pruebas de concepto, pudiendo alterar el rumbo del
proyecto profundamente. ASD no propone tcnicas ni
prescribe tareas para la construccin, sugiriendo que todas
las prcticas que apoyen la colaboracin son tiles. El
nfasis est en que las personas deben estar lo
suficientemente dispuestas para generar una propiedad
imprescindible en los organismos complejos: la emergencia.
La emergencia es una propiedad de los sistemas
adaptativos complejos, que crea alguna propiedad ms
grande del todo (comportamiento del sistema) a partir de la
interaccin de las partes (comportamiento auto- organizativo
de los agentes). Gracias a esta propiedad los grupos sacan
lo mejor de s, aun al borde del caos
06/02/2013
ASD: CV: Aprender
4 Aprender
Finalmente, Highsmith elige la palabra aprender en
vez de retroalimentar debido a que desde un punto
de vista de ingeniera la idea de retroalimentar es
obtener informacin sobre el rendimiento especfico.
Pero en un sistema complejo, no se busca lo ptimo
sino la adaptacin a condiciones siempre cambiantes:
la idea de algo ptimo tiene sentido solamente cuando
existen condiciones estables, en donde tambin hay
lmites preestablecidos a alcanzarse. Entonces el
objetivo es aprender cules son los lmites actuales,
cules partes de su comportamiento ayudarn en
dichas circunstancias y qu partes se debern
cambiar. Entonces, no hace falta solamente la
retroalimentacin, sino el aprendizaje.
06/02/2013
ASD: CV: Aprender
4 En un ambiente adaptable, aprender desafa a todos -
desarrolladores y sus clientes - a examinar sus
presunciones y usar los resultados de cada ciclo de
desarrollo para adaptar el siguiente. El aprendizaje
como tal es un rasgo continuo e importante, que
asume que los planes y los diseos deben cambiar
conforme avanza el desarrollo.
4 Se analizan 4 categoras de clases para aprender:
Calidad del resultado desde la perspectiva del
cliente.
Calidad del resultado desde la perspectiva tcnica.
El funcionamiento del equipo de desarrollo y las
prcticas que este utiliza.
El estado del proyecto
06/02/2013
ASD: CV: Aprender
Para analizar la calidad desde el punto de vista del
cliente se sugiere utilizar grupos de enfoque en el
cliente, mediante los cuales se explora un modelo se
la aplicacin y se anotan los requerimientos de cambio
en el cliente.
Para la perspectiva tcnica hay que revisar el diseo,
el cdigo y las pruebas para aprender sobre la calidad
de los mismos. El nfasis hay que poner en aprender
cules son los errores o desvos y poder resolverlos y
no en buscar culpables. Tambin se revisarn las
exploraciones que se hayan hecho para adquirir la
capacidad de modificar la arquitectura, o si se ha
encontrado algn camino que se ajusta mejor a las
necesidades del usuario, o si se han cambiado los
requerimientos.
06/02/2013
ASD: CV: Aprender
El tercer proceso de retroalimentacin con la
interaccin entre las partes, la dinmica del grupo y
las tcnicas empleadas. Para medir el rendimiento y el
grado de cohesin, se podrn realizar al final de cada
ciclo reuniones postmorten, donde tambin se
discuten los aspectos del proceso que contribuyen al
desarrollo y aquellos que deben ser descartados por
su influencia negativa.
En relacin al estado del proyecto se realizan
revisiones para determinar el estado del mismo en
relacin al planificado. En ese momento, se detectarn
posibles diferencias que pueden surgir de la
exploracin, y que cambiarn el rumbo al que
apuntaba el proyecto.
06/02/2013
ASD: CV: Aprender
En la grfica que sigue se muestra el ciclo de vida y la
importancia del bucle de aprendizaje (flecha en sentido
inverso las tres fases).
Este bucle es algo crtico en ASD, ya que rompe el
esquema tradicional de la vista de un sistema donde se
tenia un bucle de control para detectar y corregir errores.
Es decir tradicionalmente las diferencias respecto a lo
planificado eran vistas como errores que deban ser
corregidos par cumplir con lo planificado. ASD y los
mtodos giles plantean que la retroalimentacin
necesaria ser para aprender y nos dar la posibilidad
de entender mejor el dominio y construir la aplicacin
que mejor satisfaga las necesidades del cliente.
Highsmith lo expone claramente como sigue: En
ambientes complejos, el seguir un plan al pie de la
letra produce el producto que pretendamos, pero no
el producto que necesitamos
06/02/2013
ASD: CV: Aprender
Actividades del Ciclo de Vida de Highsmith
Especular Colaborar

Aprender

Iniciacin
del
Proyecto
Plan
Adaptativo
de Ciclo
Revisin
del
Calidad
Q/A Final y
Entrega
Ingeniera
Concurrente
de
Componentes
Bucle de Aprendizaje
06/02/2013
ASD: Resumen
4 ASD se concentra ms en los componentes que en las
tareas, en la prctica, esto se traduce ms en la calidad
que en los procesos usados para producir un resultado.
En los ciclos adaptativos de la fase de Colaboracin, el
planeamiento es parte del proceso iterativo, y las
definiciones de los componentes se refinan
continuamente. La base para ciclos posteriores (el bucle
de Aprendizaje) so obtiene a travs de repetidas
revisiones de calidad con presencia del cliente como
experto, constituyendo un grupo de foco para el cliente.
Esto slo ocurre al final de las fases, por lo que la
presencia del cliente se suple con sesiones de desarrollo
conjunto de aplicaciones (JAD). Una sesin JAD, comn
en el RAD, es un taller en el que los programadores y
representantes del cliente se encuentran para discutir
rasgos del producto no en trminos tcnicos, sino de
negocios.
06/02/2013
ASD: Resumen
4 El mtodo de Highsmith, es por naturaleza,
complementario a cualquier concepcin dinmica del
mtodo, y por ser adaptable admite y promueve
integracin con otros modelos y marcos. Un estudio de
Dirk Riehle compara ASD con XP, encontrando
similitudes y diferencias de principios que pueden
conciliarse con relativa facilidad, al lado de otras
variables que son incompatibles. La actitud de ambos
mtodos frente a la redundancia de cdigo, por ejemplo
es distinta; mientras que en XP se debe hace todo una
y vez y slo una vez, mientras que en ASD la
redundancia puede ser un subproducto tctico inevitable
en un ambiente competitivo y debe aceptarse en tanto
que el producto se suficientemente bueno. En
materia de tcnicas ASD, las considera ms importantes,
pero no ms que eso; para XP, en cambio, los patrones y
la refactorizacin son balas de plata.
06/02/2013
ASD: Resumen
4 Hay ausencia de estudios de casos del mtodo
adaptativo, aunque las referencias a sus principios son
abundantes. Como ASD no constituye un mtodo de
ingeniera de ciclo de vida, sino una visin cultural o
epistemologa, no califica como un framework
(estructura) suficiente para articular un proyecto. Ms
visible es la participacin de Highsmith en el respetable
Cutter Consortium en el cual es director de Agile
Project Mangement Advisory Service. Entre las
empresas que han requerido consultora adaptativa, se
cuentan, AS Bank de Nueva Zelandia, CNET,
GlaxoSmithKline, Landmark, Nextel, Nike, Phoenix
International Health, Thoughworks y Microsoft. Los
consultores que se vinculan a los lineamientos giles de
Cutter Consortium son muchos. Jim Highsmith es
citado en un epgrafe referido a los mtodos giles en la
documentacin de Microsoft Solutions Framework.
06/02/2013
Bibliografa sobre ASD
4Highsmith III, James A. ; Orr, Ken: Adaptive Software
Development: Collaborative Approach to Managing
Complex Systems. DORSET HOUSE PUBLISHING CO.
INC. 2000.
4Highsmith, James A.: Adaptive Software
Development: An Evolutionary Approach to Managing
Complex Systems. DORSET HOUSE PUBLISHING CO.
INC. 2001.
4Highsmith, Jim: Agile Software Development
Ecosystems. Addison - Wesley 2002.
4Highsmith, Jim: Agile Project Management: Creating
Innovative Products . Addison - Wesley 2004.

06/02/2013
06/02/2013
Sitios Web sobre ASD
4 http://www.adaptivesd.com/
4 http://www.asd.com/

06/02/2013
Agile
Modeling
(AM)
06/02/2013
Agile Modeling (AM)
4 Agile Modeling (AM) (Modelamiento gil) fue
propuesto por Scott Ambler no tanto como un
mtodo gil cerrado en s mismo, sino como
complemento de otras metodologas. En el caso
de XP los practicantes podran definir mejor los
procesos de modelado que en ellos faltan, y en
el caso de RUP el modelado gil permite hacer
ms ligeros los procesos que ya usan. AM es
una estrategia de modelado (de clases, de
datos, de procesos) pensada para contrarrestar
la sospecha de que los mtodos giles no
modelan y no documentan. Se lo podra definir
como un proceso de software basado en
prcticas cuyo objetivo es orientar el modelado
de una manera efectiva y gil.
06/02/2013
AD: Fundadores
Scott Ambler
06/02/2013
Agile Modeling (AM)
4 Qu es Agile Modeling?
AM es un proceso cardico (catico y
ordenado simultneamente) , basado en
prcticas para modelamiento y
documentacin.
AM es una coleccin de prcticas basadas
en diferentes valores y probados
principios de ingeniera de software.
AM quiere estar a la medida de otros
procesos como XP, RUP, etc.
www.agilemodeling.com

06/02/2013
Agile Modeling: Valores
4 Los 5 valores de AM son:
Comunicacin: Los modelos promueven la
comunicacin entre el equipo y los stakeholders
(involucrados) del proyecto as como entre
desarrolladores del equipo.
Simplicidad: Es importante que los desarrolladores
entiendan que los modelos son crticos para simplificar
el software y el proceso. Es mucho ms fcil para
explorar una idea, y mejorar su comprensin creciente,
dibujando uno o dos diagramas en lugar de escribir
decenas o incluso ciento de lneas de cdigo.
Retroalimentacin: Kent Beck lo dice en su bien
Explicada Programacin Extrema: El optimismo es
un riesgo profesional de la programacin, la
retroalimentacin es el tratamiento. Comunicando
las ideas a travs de los diagramas, se gana
rpidamente en retroalimentacin, permitiendo actuar
siguiendo este consejo.
06/02/2013
Agile Modeling: Valores
Coraje: El valor es importante porque se necesita tomar
decisiones importantes y poder cambiar la direccin o
desechando o refactorizando el trabajo cuando algunas
de las decisiones demuestran ser inadecuadas.
Humildad: Los mejores desarrolladores tienen la
humildad para reconocer que ellos no lo saben todo, que
sus compaeros desarrolladores, sus clientes, y de
hecho todos los stakeholders del proyecto tambin
tienen sus propias reas de especializacin y tienen
valores para agregar a un proyecto. Un acercamiento
eficaz es asumir que todos estn comprometidos con el
proyecto y tienen igual valor y por consiguiente deben
tratarse con respeto. Huet Landry sugiere el concepto
de "Otra Estima", en lugar de "Misma Estima" dnde
cada uno trata las opiniones de los otros como si estas
tuvieran ms valor que el suyo. Con este acercamiento
la primera reaccin frente a otra idea ser muy positiva.

06/02/2013
AM: Principios
4 Los principales objetivos de AM son:
Definir mostrar de que manera se debe
poner en prctica una coleccin de valores,
principios y prcticas que conducen al
modelado de peso ligero.
Enfrentar el modelo de aplicacin de
tcnicas de modelado en procesos giles de
desarrollo como XP, DSMD, SCRUM, etc.
Enfrentar el problema de las tcnicas de
modelado independientemente del proceso
de software que se utilice.
06/02/2013
AM: Alcances
4 Los valores de AM incluyen a los de XP:
comunicacin, simplicidad, retroalimentacin y
coraje, aadiendo humildad. Una de las mejores
caracterizaciones de los principios subyacentes
de AM, est en la definicin de sus alcances:
1. AM es una actitud, no un proceso
prescriptivo. Comprende una coleccin de
valores a los que los modeladores giles
adhieren, principios en los que creen y
prcticas que aplican. Describe un estado de
modelado; no es un recetario de cocina.
2. AM es suplemento de otros mtodos. El
primer foco es el modelado y el segundo la
documentacin.
06/02/2013
AM: Alcances
3. AM es una tarea de conjunto de los participantes.
No hay logar al yo en AM.
4. La prioridad es la efectividad. AM ayuda a crear
un modelo o proceso cuando se tiene un
propsito claro y se comprueban las necesidades
de la audiencia; contribuye a aplicar los artefactos
correctos para afrontar la situacin inmediata, y a
crear los modelos ms simples que sea posible.
5. AM es algo que funciona en la prctica, no una
teora acadmica. Las prcticas han sido
discutidas desde el ao 2001 en comunidad.
Visitar:
http://www.agilemodeling.com/feedback.htm

06/02/2013
AM: Alcances
6. AM nos es bala de plata.
7. AM es para el programador promedio, pero
no reemplaza a la gente competente.
8. AM es el ataque a la documentacin. La
documentacin debe ser mnima y
relevante.
9. AM no es un ataque a las herramientas
CASE.
10. AM no es para cualquiera.
06/02/2013
AM: Principios centrales
4 Los principios de AM especificados por Ambler
incluyen:
1. Asumir la simplicidad: La solucin ms simple es
la mejor.
2. Bienvenido el cambio: Aceptar que los
requerimientos cambian.
3. Permitir el prximo esfuerzo es la meta
secundaria: Garantizar que el sistema es lo
suficientemente robusto para admitir mejoras
ulteriores; debe se un objetivo, pero no el primordial.
4. Cambio incremental: No esperar hacerlo bien la
primera vez.
5. Planear con un propsito: Si no se puede identificar
para qu se esta haciendo algo?, para qu
molestarse ?
06/02/2013
AM: Principios centrales
6. Modelos mltiples: Mltiples paradigmas en
convivencia, segn se requiera
7. Maximizar la inversin en los stakeholders:
Hay que prestar la debida atencin a todos los
involucrados en el proyecto.
8. Trabajo de calidad: La calidad debe estar
presente en todo momento.
9. Retroalimentacin rpida: No esperar que sea
demasiado tarde.
10. El software es su meta principal: Debe ser de
alta calidad y coincidir con lo que el usuario
espera.
11. Viajar con poco equipaje: No crear ms modelos
ms de los necesarios.
06/02/2013
AM: Principios adicionales
4 Adems Ambler incluye estos principios
adicionales
1. El contenido es ms importante que la
representacin: Pueden ser notas, pizarras o
documentos formales. Lo que importa no es el
soporte fsico o la tcnica de representacin,
sino el contenido.
2. Todo el mundo puede aprender de algn
otro: Reconocer que nunca se domina
realmente algo.
3. Conocer tus modelos: Conocer cules son
las fortalezas y las debilidades.
4. Adaptacin local: Producir slo el modelo
que resulte suficiente para el propsito.
06/02/2013
AM: Principios adicionales
5. Comunicacin abierta y honesta: Es
indispensable, como en toda metologa gil la
comunicacin abierta y sincera entre todos los
involucrados.
6. Trabajar con los instintos de la gente:
Tener en cuenta la creatividad y las
particulares habilidades e ideas de la gente
que participa en el proyecto.
7. Conocer las herramientas: Conocer todas
las herramientas que sean tiles, incluyendo
las CASE.
06/02/2013
AM: Prcticas centrales
4 Lo ms concreto en AM son su rico conjunto
de prcticas, cada una de la cules se asocia
a lineamientos, decididamente narrativos,
articulados con minuciosidad, pero muy lejos
de los rigores del aparato cuantitativo de Evo:
1. Activa participacin de los stakeholders.
2. Aplicacin los artefactos correctos.
3. Propiedad colectiva de todos los elementos.
4. Considerar la disponibilidad de prueba.
5. Creacin de diversos modelos en paralelo.
6. Creacin de contenidos simples.
7. Disear modelos de manera simple.
06/02/2013
AM: Prcticas centrales
8. Presentar los modelos pblicamente.
9. Iterar sobre otros artefactos.
10. Modelar en incrementos pequeos.
11. Modelar con otros.
12. Demostrar con el cdigo.
13. Usar las herramientas ms simples (CASE,
o mejor tarjetas, pizarras, post its).
06/02/2013
AM: Prcticas adicionales
4 Ambler considera tambin estas prcticas
incluye estos principios adicionales
1. Aplicacin de estndares de modelado.
2. Aplicacin patrones a gusto.
3. Descartar los modelos temporales.
4. Formalizar los modelos contractuales.
5. Modelar para comunicar.
6. Modelar para aprender.
7. Reutilizar cdigo existente.
8. Actualizar slo cuando duela.

06/02/2013
AM: Artefactos
Artefacto de Modelamiento
Software
Prueba de Aceptacin
Fitnesse
Regla de Negocios
Procesador de texto
Caso de Cambio
Procesador de texto
Modelo CRC (Clase Responsabilidad Colaborador)
Restriccin
Procesador de texto
Modelo de Contrato
Necesario
DFD (Diagrama de Flujo de Datos)
CASE
Modelo de Dominio
CASE
Caso de Uso Esencial/Abstracto
Procesador de texto
Prototipo de Interfaz de Usuario Esencial/Abstracto
Rasgo
Hoja de clculo
Diagramas de Forma Libre
Herramienta de Diagramacin
Diagrama de Flujo
Diagramacin o CASE
Glosario
Procesador de texto
Modelo Lgico de Datos
CASE
06/02/2013
AM: Artefactos
Software
Diagrama de Red
Diagramacin
Diagrama de Modelo de Rol de Objeto
Personas
Procesador de texto
Modelo Fsico de Datos
CASE
Diagrama de Robustez
Modelo de Amenaza de Seguridad
Caso de Uso de Sistema
Procesador de texto
Requerimientos Tcnicos
Procesador de texto
Diagrama de Actividad de UML 2
CASE
Diagrama de Clase de UML 2
CASE
Diagrama de Colaboracin de UML 2
CASE
Diagrama de Componentes de UML 2
CASE
Diagrama de Estructura Compuesta de UML 2
CASE
Diagrama de Despliegue de UML 2
CASE
Diagrama de Interaccin de Visin Global de UML 2
CASE
06/02/2013
AM: Artefactos
Software
Diagrama de Objetos de UML 2
CASE
Diagrama de Paquetes de UML 2
CASE
Diagrama de Secuencia de UML 2
CASE
Diagrama de Mquina de Estado de UML 2
CASE
Diagrama de Coordinacin de UML 2
CASE
Diagrama de Casos de Uso de UML 2
CASE
Escenario de Uso
Procesador de texto
Organigrama de Interfaz de Usuario
Diagramacin
Prototipo de Interfaz de Usuario
Herramienta de prototipo o IDE
Historia de Usuario
Hoja de clculo
Mapa de Corrientes de Valor
06/02/2013
AM: Modelos giles
Modelamiento de Uso
Pruebas de aceptacin
Casos de Uso Esenciales
Rasgos
Casos de Uso del Sistema
Escenario de Uso
Historias de Usuario
UML: Diagrama de Casos de Uso
Desarrollo de Interfaz de Usuario
Prototipo de Interfaz de Usuario Esencial
Diagrama de Flujo de Interfaz de Usuario
Prototipo de Interfaz de Usuario
Modelamiento del Proceso
Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo
UML: Diagrama de Actividad
Mapa de Corriente de Valor
Diagrama de Flujo de Trabajo
Modelamiento de la Arquitectura
Casos de Cambio
Diagrama de Forma Libre
Modelado de Amenaza a la Seguridad
UML: Diagrama de Componentes
UML: Diagrama de Despliegue
UML: Diagrama de Paquetes
Modelamiento de Objeto Dinmico
UML: Diagrama de Comunicacin
UML: Diagrama de Estructura Compuesta
UML: Diagrama de Vista Global de Interaccin
UML: Diagrama de Secuencia
UML: Diagrama de Mquina de Estados
UML: Diagrama Cronomtrico
Modelamiento Estructural Detallado
Especificacin de Interfaz Externa (EI)
Modelo Fsico de Datos (PDM)
UML: Diagrama de Clases
UML: Diagrama de Objetos

Modelamiento del Dominio Conceptual
Tarjetas CRC (Clase-Responsabilidad-Colaborador)
Modelo Lgico de Datos (LDM)
Diagrama de Modela de Rolas de Objeto (ORM)
Diagrama de Robustez
UML: Diagrama de Clases
Modelamiento de Requerimientos Suplementarios
Reglas de Negocios
Casos Conceptuales
Restricciones
Glosario
Requerimientos Tcnicos
06/02/2013
AM: Las pruebas como
artefactos primarios
4 Las pruebas de aceptacin se consideran
para ser los artefactos de requerimientos
primarios
Se puede reducir la documentacin de
requerimientos dramticamente no grabando
dos veces la misma informacin.
4 Se considera que las pruebas de unidad
son los artefactos del diseo detallado
Se puede reducir la documentacin del diseo
dramticamente y aumenta la oportunidad de
que los artefactos del diseo detallados se
guardan actualizados por los el codificadores.
06/02/2013
AM: Documentacin gil
4 Razones para documentar
Razones vlidas
+ Los stakeholders del proyecto requieren de l.
+ Para definir un modelo de contrato.
+ Para soportar comunicacin con grupos externos.
+ Para pensar en algo a travs de ellos.
Razones no vlidas
+ El solicitante quiere ser visto en el control.
+ El solicitante quiere justificar su existencia.
+ El solicitante no sabe nada bueno.
+ El proceso dice crear para documentar.
+ Alguien quiere la certeza de que el proyecto est bien.
+ Se est especificando el trabajo para otro grupo.
+ Sus contratos de desarrollo estn rutinariamente sujetos al
recompeticin.
06/02/2013
AM: Participacin Activa de
los Stakeholders
4 Los Stakeholders son los Expertos,
Ellos no Deben Planear?
Los stakeholders del proyecto deben:
- Proporcionar informacin de una manera
oportuna.
- Tomar decisiones de una manera oportuna.
- Participar activamente en el modelamiento
orientado a negocios.
06/02/2013
Agile Modeling
4 Por qu AM?
Si se sigue los principios y prcticas de AM, por
definicin se est planeando y s est
documentando de la manera ms eficaz posible.
AM ha demostrado que trabaja en la prctica.
Con un AMDD se gana los beneficios de
modelamiento sin los inconvenientes de la
burocracia:
- Durante el ciclo 0 se identifica el paisaje.
- Durante los ciclos 1 + , se modela un poco,
implementar mucho, luego iterar.

06/02/2013
Agile Modeling
4 Cundo AM quiere trabajar para ti?
Se est tomando una (razonablemente) aproximacin
gil para el desarrollo AM ha demostrado que
trabaja en la prctica.
Se est trabajando iterativa e incrementalmente.
Requerimientos inciertos y voltiles.
Requerimientos inciertos y voltiles.
Se tiene soporte activo de los stakeholders y
envolvimiento.
El equipo de desarrollo tiene (razonable) control de su
destino.
Se tiene desarrolladores responsables y motivados
06/02/2013
Agile Modeling
4 Cundo AM no quiere trabajar
para ti?
Uno o ms de los factores anteriores no
estn all.
La cultura organizacional se engrana
hacia una cultura prescriptiva.
Se tiene un equipo grande y/o
distribuido.
06/02/2013
Agile Modeling
4 Reconocer esto:
Modelo != Documento.
El modelamiento es una parte importante de
todo proceso de software, incluyendo a XP.
El modelamiento es una importante tcnica de
comunicacin.
Se necesita pensar fuera de la caja UML.
Reconocer que probablemente se est
haciendo un 90% de AM, y ese 10% extra
mejorar la productividad dramticamente.

06/02/2013
Agile Modeling: Resumen
4 Como AM se debe usar como complemento de otras
metodologas, nada se especifica sobre mtodos de
desarrollo, tamao de equipo, roles, duracin de
iteraciones, trabajo distribuido y criticalidad, todo lo cual
depender del mtodo que se utilice. Los principios y
prcticas que hemos citado pueden dar la impresin de
puro sentido comn, slo que en variante cardica; en
realidad los aspectos atinentes a uso de herramientas
de modelado y documentacin, as como la articulacin
con metodologas especficas, las tcnicas de bases de
datos y el uso de artefactos, estn especificados
cuidadosamente, como se puede constatar en el sitio
de AM, y en los textos ms extensos de Ambler.
06/02/2013
Agile Modeling: Resumen
4 Los diagramas de UML y los artefactos del
Proceso Unificado, por ejemplo, han sido
explorados en extremo detalle, describiendo
cmo debera ser su tratamiento en un proceso
gil EUP (Enterprise Unified Process), regido
por principios cardicos. EUP es simplemente
UP + AM. Se han documentado algunos
estudios de casos AM en proyectos de
mediano calado. Aun cuando uno no pretenda
integrase al bando de los MAs, puede que
valga la pena echar una mirada a ese material
y considerar la razonabilidad, de algunas de
sugerencia.
06/02/2013
Bibliografa sobre AM
4Ambler, Scott W.: Agile Modeling Effective Practices
for Extreme Programming and the Unified Process.
John Wiley & Sons. 2000-2007.
4Ambler, Scott W.: The Object Primer 3rd Edition Agile
Model Driven Development with UML 2 Cambridge
University Press. 2004.
4Ambler, Scott W.: Agile Database Techniques
Effective Strategies for the Agile Software Developer.
John Wiley & Sons. 2003-2007.
4Ambler, Scott W.; Saladage, Pramod J. : Agile
Database Techniques Effective Strategies for the
Agile Software Developer. Addison Wesley
Professional. 2005-2007.
4Larman, C.: Agile and Iterative Development: A
Managers Guide. Addison Wesley Longman 2004.

06/02/2013
Bibliografa sobre AM
06/02/2013
Sitios Web sobre AM
4 http://www.agilemodeling.com/
4 http://www.agiledata.org/
4 http://www.agilealliance.com/
4 http://www.ronin-intl.com/
4 http://www.modelingstyle.info/
4 http://www.ambysoft.com/agileModeling.html
4 http://www.ambysoft.com/scottAmbler.html
4 http://www.enterpriseunifiedprocess.com

06/02/2013
Lean Development
(LD)
y Lean Software
Development (LSD)
06/02/2013
Lean Development (LD) y Lean
Software Development (LSD)
4 Lean Development (LD) (Desarrollo Delgado)
es el mtodo menos conocido entre los
reconocidamente importantes. La palabra lean
significa delgado, magro, enjuto. En su sentido
tcnico apareci por primera vez en 1990, en el
libro de James P. Womack, La Mquina que
Cambi al Mundo. LD iniciado por Robert N.
Charette, se inspira en el xito del proceso
industrial Lean Manufacturing, bien conocido en
la produccin automotriz y en manufactura desde
la dcada de 1980. Este proceso tiene como
principio la eliminacin de los residuos a travs de
la mejora constante, haciendo que el producto
fluya a instancias del cliente para hacerlo lo ms
perfecto posible.
06/02/2013
4 Los procesos a la manera norteamericana corran con
sus mquinas al 100% de capacidad y mantenan
inventarios gigantescos de productos y suministros en
planta para un solo da; Toyota, en contra de la
intuicin, resultaba ms eficiente manteniendo
suministros en planta para un solo da, y produciendo
slo lo necesario para cubrir las rdenes pendientes.
Esto es lo que se llama Just In Time Production. Con
JIT se evita adems que el inventario degrade o se
torne obsoleto, o empiece a actuar como freno para el
cambio. Toyota aplicaba adems tcnicas innovadoras
Total Quality Management (TQM) de Eward
Deming, que solo algunos matemticos y empresarios
de avanzada conocan en Estados Unidos. Hasta hoy
en da la foto de Deming es ms grande y
esplendorosa que la del fundador Kiichiro Toyoda.
06/02/2013
4 Dado que LD, es ms una filosofa de manejo
que un proceso de desarrollo no hay mucho
que decir del tamao del equipo, la duracin
de las iteraciones, los roles o la naturaleza de
sus etapas. ltimamente LD ha evolucionado
como Lean Software Development (LSD); su
figura de referencia es Mary Poppendieck.
4 Mary y Tom Poppendieck, son los autores
del libro Lean Software Development - una
caja de herramientas gil para los gerentes del
06/02/2013
LD y LSD: Fundadores
Mary
Poppendieck
Tom
Poppendieck
James P.
Womack
Robert N.
Charette
06/02/2013
Lean Development (LD)
4 Lean Development (Desarrollo Delgado)
se centra en la creacin del software
tolerante al cambio. Esta metodologa
incorpora la nocin de la estabilidad
dinmica, por lo cual puede ser puede
considerar que similarmente a Scrum
abraza el caos controlado. Bob Charette,
el autor, escribe que la meta mensurable
del LD es construir software con una mitad
del esfuerzo humano, una mitad de las
horas del desarrollo y una mitad de la
inversin con respecto a qu organizacin
del nivel 3 de SEI CMM alcanzara.

06/02/2013
4 "Lean" es un trmino acuado por Womack y
Jones para describir un mtodo de gestin usado
principalmente a Toyota y conocido en Japn
como la "Va Toyota" (a veces llamado el
"Sistema de Produccin Toyota). Bob
Charette es el ms conocido por haber intentado
aplicar estas tcnicas al software con lo que l
llama "Lean Development" ("Desarrollo
Delgado). Mary Poppendieck tambin ha
publicado el trabajo en "Lean Programming" (
"Programacin Delgada ) en Software
Development Magazine (Revista de Desarrollo
de Software) y tiene un libro llamado "Lean
Development" - una herramienta para gerentes
para gerentes de desarrollo de software.

06/02/2013
4 El Dr. Roberto Charette desarroll los principios
del desarrollo delgado (LD) en los tempranos
aos 90 como una consecuencia de la gestin de
riesgo orientada al software de los sistemas del
proyecto de la Corporacin ITABHI, la gestin
de programa y los esfuerzos de gestin de riesgos
de empresa. Mientras que ninguno de los
principios bsicos del desarrollo delgado son
nuevos por s mismos, su integracin coherente
debajo de la bandera y las metas del LD los
hacen particularmente de gran alcance. De hecho,
es la propiedad emergente del ciclo virtuoso,
resultado de la interaccin del conjunto total de
sus principios, donde reside el poder del
desarrollo delgado.
06/02/2013
4 Para Mary y Tom Poppendieck el desarrollo
delgado es como crear una receta y la produccin
es como seguir esa receta. Un cocinero al crear
una receta prueba muchas variantes y elige la
mejor. El software se crea tambin sobre el ensayo
y el error.
4 Los Poppendieck tambin afirman que para
resolver problemas complejos hay que aplicar el
mtodo cientfico: observar, crear hiptesis, inventar
experimentos para probar las hiptesis. Para
aumentar el aprendizaje al mximo es necesario
tener un 50% de probabilidad de fracaso; es decir si
la hiptesis son correctas, no se aprende mucho, es
fallando cuando ms se aprende. Esto habla en bien
de la experimentacin en el desarrollo de software:
crear prototipos o (mejor aun) escribir cdigo real.
06/02/2013
4 El desarrollo delgado (LD) es una estrategia, as como
la aproximacin tctica del negocio para sistemas
orientados a la creacin de software comercial
tolerante a cambios por ejemplo sistemas que
pueden adaptarse o ayudar rpidamente en la
creacin de cambios del negocio - en:
1/3 del esfuerzo humano.
1/3 de las horas del desarrollo.
1/3 del tiempo.
1/3 de la inversin en herramientas y mtodos.
1/3 del esfuerzo de adaptarse a un ambiente de
nuevo mercado.
que las aproximaciones convencionales por
ejemplo., organizaciones clasificadas del nivel 3 de
SEI CMMI/CMM para el desarrollo de sistemas
orientados al software.
06/02/2013
4 Por qu objetivos de 1/3?
Porque estas metas se significan desafiar el
status quo que piensa de la naturaleza del
desarrollo del software. Sin metas audaces,
algunas que parecen imposibles de alcanzar,
el software y los gerentes de negocio no se
incomodarn en pensar en los problemas del
desarrollo del software de maneras
enteramente diversas.
06/02/2013
LD: Valores
4 Lean Development se inspira en 12 valores de gestin:
1. Satisfacer al cliente es la mxima prioridad.
El equipo de desarrollo delgado debe centrarse en la
determinacin de la proposicin del valor de negocio del
cliente. La meta est maximizando la satisfaccin de cliente
a travs de crear el valor de negocio real a un nivel
aceptable de calidad tcnica. No resolver expectativas del
valor del cliente se ve como fracaso.
2. Proporcionar siempre el mejor valor para la
inversin.
Los sistemas orientados al software deben ayudar a
eliminar el riesgo de un cliente, a solucionar un problema o
a proporcionar una nueva oportunidad a un costo
razonable. El valor es la meta, no perfeccin. El valor es
una combinacin de las caractersticas de producto que
satisfacen las necesidades de un cliente en un momento
especfico, en una situacin especfica, para un precio
especfico.
06/02/2013
3. El xito depende de la activa participacin del
cliente.
La participacin activa es un esfuerzo de
colaboracin, comn, no los equipos integrados
bajo el smbolo del producto. La participacin del
cliente es ms que slo comprar en; la
participacin activa es esencial para adaptarse al
cambio y tomar decisiones de negocio en tiempo
real y de intercambio de la tecnologa.
4. Cada proyecto LD es un esfuerzo del equipo.
Los equipos multidisciplinarios antes que los
individuos aislados son necesarios porque la
diversidad es crtica a innovadora, el desarrollo
del tiempo del ciclo - rpido.

06/02/2013
5. Todo se puede cambiar.
Para que los sistemas orientados al software sean tiles,
deben resolver condiciones de negocio rpidamente
cambiantes. El desarrollo delgado asume que los
cambios de los requerimientos sern continuos y ese
aprendizaje para adaptarse a los cambios, es una
estrategia mejor que intentar controlarlos. Las preguntas
constantes hechas en un esfuerzo LD son, Qu clases
de cambios podan ocurrir? Qu haramos si ellos ya
ocurrieron? Cmo podemos construir el sistema para
ser ms tolerantes de este tipo de cambios?
6. Soluciones del dominio, no puntos.
Los sistemas de software Oneof-a-kind son demasiado
costosos en la mayora de los casos. Los sistemas
orientados al software que son aplicables a travs de las
compaa de dominio mltiple, mercados, el costo de
extender el producto y en esto contribuyen a la ecuacin
del valor.
06/02/2013
7. Completar, no construir.
La construccin de los sistemas de software
desperdicia tiempo, es costosa y est cargada de
errores. La compra, en lugar de la construccin,
ha sido de largo una estrategia viable para la
mayora de los grupos del desarrollo de
aplicaciones. Siempre que sea posible, utilizar los
elementos preexistentes o prefabricados del
software, reducir al mnimo costos de oportunidad
de la organizacin.
8. Una solucin al 80% hoy, en vez de una al
100% maana.
Los mercados se estn moviendo demasiado
rpido para proporcionar soluciones al 100% del
cliente.

06/02/2013
9. El minimalismo es esencial.
El desarrollo delgado elimina gastos indirectos
y el desperdicio innecesario. LD intenta
eliminar el desperdicio reduciendo al mnimo el
papeleo, manteniendo a equipos de desarrollo
pequeos y colocalizados, y manteniendo el
alcance del producto enfocado.
10. Las necesidades determinan la tecnologa.
Elegidos los objetivos del desarrollo delgado
entonces est la tecnologa para apoyarla,
pero no viceversa. Las opciones de la
tecnologa son hoy tan extensas, que es ms
fcil pasar ms tecnologas cambiantes en el
tiempo, que creando negocio y valor del
cliente.

06/02/2013
11. El crecimiento del producto es el incremento
de sus prestaciones, no de su tamao.
El factor crtico en LD est entregando
caractersticas tolerantes al cambio. Al evaluar
nuevas caractersticas, el equipo debe considerar
cmo las prcticas de negocio podran cambiar y
efectuar o ser efectuadas siempre por la
aplicacin del software. El tamao no es el
problema.
12. Nunca empujar a LD ms all de sus lmites.
El desarrollo delgado apunta al desarrollo para
aumentar el rdito, para reducir costes y para
aumentar beneficios, creando valor creciente del
cliente. Si hay maneras mejores de hacer esto
que con el desarrollo delgado, utilizarlos.

06/02/2013
4 Hay un decimotercero principio no escrito, pero
importante del desarrollo delgado, que tambin
apoya el concepto del humanware. Realizando
estudios de lecciones-aprendidas, el japons
descubri que las mejoras del proceso y de la
tecnologa en el piso de la fbrica contribuyen
solamente en el 25% de a las mejoras totales que
la fabricacin delgada crea. Los problemas de
Humanware explican el resto. Como la
fabricacin delgada, el desarrollo delgado
depende de una ideologa que compromete a
aquellos implicados en l mental y
emocionalmente. Aquellos que usando el
desarrollo delgado, necesitan alcanzar la
satisfaccin a travs de su trabajo.
06/02/2013
Beneficios de Lean Development
Crea
productos
decisivos
Lanza nuevos
productos a
tiempo / cada
vez
Desarrolla ms
productos con
los mismos
recursos
06/02/2013
Lean Software Development
(LSD)
4 Lean Software Development (Desarrollo
Delgado de Software) es una traduccin de
principios industriales delgados y prcticas al
dominio de desarrollo de software.
4 Mary y Tom Poppendieck son los autores del
libro Lean Software Development - An Agile
Toolkit for Software Development Managers
(Desarrollo Delgado de Software - Una Caja de
Herramientas gil para los gerentes del
Desarrollo del Software). Este libro presenta un
juego de 22 herramientas. Estas herramientas
que sern relativamente desconocidas a la gente
involucrada en desarrollo gil del software
incluyen:

06/02/2013
Lean Software Development
(LSD)
Ver el desperdicio.
Mapear el flujo de valor.
Desarrollo fijado.
Tirar los sistemas.
Teora de colas.
Motivacin.
Medidas.
4 Aunque las herramientas pueden ser poco
conocidas, las implicaciones estn muy
familiarizadas. Por ejemplo, Workcells un
principio principal de Lean, se presenta en los
mtodos giles como los equipos de funcionalidad
cruzada.

06/02/2013
LSD: Siete Principios
4 El desarrollo delgado de software podra ser
resumido en los siguientes siete principios, que
deben ser seguidos sabiamente segn el
ambiente y el caso especfico, con uso fuerte del
sentido comn:
Eliminar el desperdicio.
Construir la integridad adentro.
Ampliar el aprendizaje.
Diferir el compromiso.
Entrega rpida.
Comprometer la inteligencia de los
trabajadores.
Optimizar el Total.
Velocidad
06/02/2013
LSD: 1 Principio: Eliminar el
desperdicio
4 El desperdicio es algo que no agrega el valor del cliente
(cdigo adicional y funcionalidades, tardanza en el
proceso de desarrollo de software, requerimientos
inciertos, burocracia, comunicacin interna lenta).
Basado en un entendimiento profundo de cual es el
valor del cliente (reconocerlo y verlo).
4 La prdida es algo que se ha empezado
Pero no se est usando en la produccin.
4 La prdida es algo que retrasa el desarrollo
O mantiene personas esperando.
4 La prdida es cualquier rasgo extra
Eso no se necesita ahora.
4 La prdida es una cosa mal hecha.
O est haciendo mal la cosa.
06/02/2013
LSD: 1 Principio: Eliminar el
desperdicio Mito 1
La especificacin temprana reduce el
desperdicio
Raramente o nunca
usado = 80 %
A menudo o siempre
usado = 20 %
Rasgos o Funciones
usados en un Sistema
Tpico
06/02/2013
LSD: 2 Principio: Construir la
integridad adentro
Los Equipos de Producto Integrados
Refactorizacin
Desarrollo Manejado por Pruebas
Tiempo
C
o
m
u
n
i
c
a
c
i
n

Por qu se est haciendo esto?
Qu necesita ser hecho?
Cmo lo construimos?
Cmo lo apoyamos?
Tiempo
P
r
o
d
u
c
t
i
v
i
d
a
d
Con Factorizacin Sin Factorizacin
Requerimientos Retroalimentacin Refactorizacin Mantenimiento
Cliente
Desarrollador
Necesidades
del Negocio
Actuales
Intento del
Diseo
Actual
Comparacin
SISTEMA
Cdigo
Capacidad
Actual
06/02/2013
LSD: 2 Principio: Construir la integridad
adentro: Desarrollo controlado por Pruebas
Requerimientos

Retroalimentacin

Refactorizacin

Mantenimiento

Cliente
Desarrollador
Necesidades
del Negocio
Actuales
Intento del
Diseo
Actual
Comparacin
SISTEMA
Cdigo
Capacidad
Actual
06/02/2013
LSD: 3 Principio: Ampliar el
aprendizaje
4 El desarrollo del software es un proceso de
aprendizaje continuo con el desafo adicional para
los equipos del desarrollo y los tamaos del
producto final. La mejor aproximacin para
mejorar un ambiente del desarrollo del software es
ampliar el aprendizaje. La acumulacin de
defectos debe ser prevenida ejecutando las
pruebas tan pronto como se escriba el cdigo. En
vez de agregar ms documentacin o planificar
con detalle diversas ideas, podan ser probadas
escribiendo cdigo y construyendo. El proceso de
acopio de los requerimientos del usuario poda
simplificarse presentando a los usuarios finales,
pantallas de usuario y consiguiendo su entrada.
06/02/2013
LSD: 3 Principio: Ampliar el
aprendizaje
Un cuento de dos proyectos Un ao despus
Pobre productividad
Pobre aceptacin de
mercado
Pobre tasa de calidad
del experto
Gran xito de mercado
Alan McCormack
Harvard Business School

06/02/2013
LSD: 4 Principio: Diferir el
compromiso
4 La tecnologa cambia rpidamente
4 La situacin de negocios evoluciona
4 El software debe cambiar!
Productos de software
- Mejora con la edad.
- Se espera que la arquitectura cambie con el
tiempo.
Software del cliente
- Se pone dbil con la edad.
- No se espera que la arquitectura cambie.
- Pero el 60 - 70% de desarrollo del software
ocurre despus del lanzamiento inicial de la
produccin.
06/02/2013
LSD: 4 Principio: Diferir el
compromiso
4 Pilotos:
En el entrenamiento de piloto, nosotros
aprendimos que cuando tenamos que
tomar una decisin, debemos decidir
primero cuando debe tomarse la
decisin , entonces cuando viene el
momento, hay que tomar la decisin
basada en la informacin disponible.
4 Militares:
Una de la cosas ms importantes que
yo les ense a los reclutas jvenes es
que cuando ellos sean amenazados,
deben decidir en el la caja de tiempo
para una respuesta. y no responde hasta
el final de la caja de tiempo.
06/02/2013
LSD: 5 Principio: Entrega rpida
4 Las organizaciones ms disciplinadas son aqullas
que responden a la demanda del cliente
Rpidamente.
Fiablemente.
Repetidamente.

4 Madurez del Desarrollo de Software
La velocidad con la que se convierte, fiablemente y
repetidamente, las demandas de cliente al software
desplegado
Someter la
Demanda
Desplegar
el Cdigo
Medir el Tiempo de Ciclo Promedio
Tiempo Ms Corto = Ms Madurez
06/02/2013
Principios de Velocidad
4 Arrancar de la demanda del cliente.
Arrancar en un orden.
No empujar con un horario.
4 Hacer el trabajo auto dirigindose.
Lugar de Trabajo Visual
4 Confiar en la sealizacin local y en el
compromiso
Kanban.
Las Reuniones de Scrum.
4 Usar Lotes Pequeos.
Limitar la cantidad de trabajo en la tubera.
06/02/2013
Kanban
4 Qu es Kanban?
Kanban es un sistema de produccin donde cada
operacin jala (pull) el material que necesita de la
operacin anterior. Kanban significa en japons,
tarjeta de instrucciones, y es la seal que autoriza
mover o producir.
Su principal funcin es ser una orden de trabajo, es
decir, un dispositivo de direccin automtico que nos
da informacin acerca de que se va ha producir, en
que cantidad, mediante que medios y como
transportarlo.
Cuenta con dos funciones principales: control de la
produccin y mejora de procesos. Por control de la
produccin se entiende la integracin de los diferentes
procesos y el desarrollo de un sistema JIT.
06/02/2013
LSD: 6 Principio: Comprometer la
Inteligencia de los Trabajadores
4 1982 - GM cerr la Planta CA de Fremont
Productividad ms baja
Ausentismo ms alto
4 1983 - volvi a abrir como NUMMI (Toyota &
GM)
La misma fuerza obrera.
Los trabajos de oficina cambian por apoyo a
la direccin.
Equipos de trabajo pequeos entrenados
para disear, medir, estandarizar y
perfeccionar su propio trabajo.
4 1985
La productividad y la calidad doblados
excediendo a todas las otras plantas.
El abuso de la droga y del alcohol
desaparecieron
El ausentismo virtualmente detenido.
Tiempo para extender la planta.
06/02/2013
Inteligencia de los Trabajadores
4 La crisis en nuestra Planta de Video Casete
La Competencia que vende casetes por menos que nosotros
podramos hacerlo.
4 Nuestra Respuesta
Produccin Justo en el Tiempo (JIT).
4 La Gran Simulacin de la Taza de Caf
Gerente de Planta, Gerente de Control de Materiales, Gerente
de TI (JIT).
Agregar a los Gerentes Generales de Produccin.
Agregar a los Supervisores Generales
Agregar a los Supervisores de Cambio
Agregar a los Obreros de Cambio
4 El Resultado
La planta entera cambi para lanzar la planificacin sobre un fin
de semana .
El lleno total fue de 60 a 95% la primera semana .
Los empleados dijeron que sta era la mejor cosa que pas a la
planta.
06/02/2013
Inteligencia de los Trabajadores:
Valorar aquello que Agrega Valor
4 Quin decide lo que ellos hacen luego?
4 Quin disea los procesos?
Decisin que Toma la
Autoridad
Recursos
Ellos Creen que
Toman las Decisiones?
06/02/2013
Inteligencia de los Trabajadores:
Compromiso del Equipo
1. Equipo Pequeo
2. Misin Clara
3. Horario Corto
4. Provisto de personal con las habilidades
necesarias
4 Expertos en Tecnologa.
4 Experiencia en el Dominio.
5. Bastante informacin para determinar la
viabilidad
6. Asegurar los recursos de ser necesarios
7. Libertad para tomar las decisiones
8. El ambiente bsico para la buena
programacin
4 Estndares de Codificacin.
4 Herramienta de Control de Versin.
4 Proceso de Construccin
Automatizado.
4 Pruebas Automatizadas.
Propsito
Clientes
06/02/2013
Inteligencia de los Trabajadores: Kaizen
4 Kaizen es un sistema enfocado en la mejora continua de
toda la empresa y sus componentes, de manera armnica y
activa. La palabra proviene de dos vocablos japoneses, Kai,
que significa "cambio", y Zen, que se interpreta como lo
mejor en un sentido tanto espiritual como fsico.
4 El desarrollo del Kaizen fue paralelo con el desarrollo de los
crculos de control de calidad, pero no fue limitada por el
aseguramiento de calidad.
4 Los objetivos de Kaizen incluyen la eliminacin del
desperdicio (Muda), entrega justo a tiempo (JIT),
estandarizacin del trabajo y equipo adecuado de trabajo,
entre otros.
4 Una definicin ms cercano al significado de la palabra en
japons es el de "desarmarlo completamente y volverlo
a armar de una mejor manera". Lo que usualmente es
desarmado es un proceso, un sistema, un producto o un
servicio.
06/02/2013
LSD: 7 Principio: Optimizar
el Total
4 Crculo Vicioso # 1
Un cliente quiere algunas nuevas caractersticas ayer.
Los desarrolladores oyen: Hazle ayunar a toda costa!
Resultado: Se hacen los cambios sucios para el cdigo
base.
Resultado: Crece la complejidad del cdigo base.
Resultado: Crece el nmero de defectos del cdigo base.
Resultado: Crecimiento exponencial del tiempo de
agregar caractersticas.
4 Crculo Vicioso # 2
La prueba se sobrecarga con el trabajo.
Resultado: La prueba ocurre mucho tempo despus de
codificar.
Resultado: Los desarrolladores no consiguen la
retroalimentacin inmediata.
Resultado: Los desarrolladores crean ms defectos.
Resultado: La prueba tiene ms trabajo. Los sistemas
tienen ms defectos.
Resultado: La retroalimentacin para desarrolladores si
tarda mucho. Repetir ciclo.
Nosotros no
hemos
encontrado al
enemigo. El
est en
nosotros.
06/02/2013
LSD: 7 Principio: Optimizar el Total
4 Descomposicin
Se consigue lo que se
mide.
No se puede medir todo.
El material se cae entre
crujidos.
Se agregan ms medidas.
Se obtiene sub -
optimizacin local.
Medir Abajo
4 Agregacin
Se consigue lo que se
mide.
No se puede medir todo.
El material se cae entre
crujidos.
Se mide a un nivel UP.
Se obtiene optimizacin
global.
Medir Arriba
4 Espacio de Control
Sostener a las personas
responsables para lo que
ellos pueden controlar.
Medir a nivel individual.
La competencia adoptiva.
4 Espacio de Influencia
Sostener a las personas
responsables para lo que
ellos pueden influenciar.
Medir a nivel de equipo.
La colaboracin adoptiva.
06/02/2013
LSD: Atributos
4 Jeffrey L. Dutton y Richard S. McCabe de Systems
and Software Consortium definen 12 atributos para
LSD:
La Calidad redefinida
Compromiso del Usuario /Cliente
La idea de Iteraciones
La Gestin de la Iteracin y la Convergencia
El Pensamiento de las Opciones
Decidir tan tarde como posible
Entregar tan rpido como posible
Conocimiento Tcito (vs. Proceso) y Aprendizaje Rpido
Concurrencia y Comunicacin (IPT)
El Soporte de la Ingeniera Agil
La Gestin del Proyecto Delgado/gil
Gasto en el Desarrollo Delgado/gil
06/02/2013
LSD: Atributos
4 La Calidad redefinida
La variacin no es (necesariamente) mala.
Tambin los procesos detallados pueden
ser restrictivos.
El desarrollo del software es un proceso
creativo.
Hazlo bien primera vez es una MALA
idea.
El desarrollo rpido conduce fuera de los
requerimientos correctos.
El desarrollo rpido produce errores - qu
son la base (misma) para el aprendizaje,
el producto ( calidad) y el valor.

06/02/2013
LSD: Atributos
4 Compromiso del Usuario /Cliente
El acercamiento a la retroalimentacin
continua y el acoplamiento firme al
usuario / cliente es un requerimiento
duro de desarrollo delgado/gil.
El "despertar" del usuario /cliente
ocurre sobre diferentes iteraciones del
software.
La falta de acoplamiento usuario/cliente
reduce drsticamente la efectividad de
la aproximacin delgada/gil.

06/02/2013
LSD: Atributos
4 La idea de Iteraciones
Idea bsica: Las iteraciones rpidas manejan
la claridad de los requerimientos y llevan a
codificar "bien" ms rpidamente y con
menos recursos.
Iteraciones = "flujo de trabajo" delgado.
Iteraciones no son prototipos.
Las iteraciones rpidas habilitan "decidir tan
tarde como posible.
Las iteraciones rpidas habilitan "pensar en
opciones.
Rpido significa horas o das, quizs un
mes o aos.
06/02/2013
LSD: Atributos
4 La Gestin de la Iteracin y la
Convergencia
La agilidad pura conduce a riesgo
significativo de soluciones fuera de lmites.
La convergencia confa en:
- La confianza en la arquitectura del software como un
"punto de vista".
- Diseo de alto nivel como un adjunto a la
arquitectura del software.
- Practicantes experimentados.
- Direccin experimentada en tcnicas de proyectos.

06/02/2013
LSD: Atributos
4 El Pensamiento de las Opciones
Idea basada en la raz de las dificultades de la toma de
decisiones.
- Lneas de base de requerimientos completos directos" .
- Diseo detallado completo temprano en ciclo de vida
- Arquitectura congelada.
Las opciones incluyen:
- Requerimientos o rasgos.
- Diseo detallado.
- Diseando en tolerancia a cambios.
- Diseando en la aceptacin de la evolucin.
- Muchas otras.

06/02/2013
LSD: Atributos
4 Decidir tan tarde como posible
Tardar las decisiones para el "ltimo momento responsable" =
alto valor comercial.
Las aproximaciones primeras profundas fuerzan decisiones de
bajo nivel prematuras.
El desarrollo de requerimientos
Las decisiones tempranas basaron en la "criticalidad".
- Duro de hacer.
- Los desafos tcnicos.
- Las necesidades de usuario de alta prioridad.
Las decisiones de requerimientos en espiral (carrera corta)
evolucionan como la curva de aprendizaje acelerado.
Las decisiones de arquitectura temprana son necesarias
Restricciones tcnicas.
Necesidades de usuario crticas.
Restricciones del diseo del sistema.

06/02/2013
LSD: Atributos
4 Entregar tan rpido como posible
La entrega rpida fuerza a la codificacin rpida.
La entrega rpida habilita decisiones tardas.
La entrega rpida requiere de cerca la integracin
continua.
La entrega rpida requiere de cerca pruebas
continuas (manejo temprano de defectos
externos).
La entrega rpida habilita entregar rpidamente
alto valor, productos de alta calidad y bajo costo.
La entrega rpida lleva a un flujo de trabajo de
"estado permanente" (y eficiencia y
productividad creciente).

06/02/2013
LSD: Atributos
4 Conocimiento Tcito (vs. Proceso) y
Aprendizaje Rpido
Conocimiento Tcito = proyecto /dominio
/conocimiento de habilidades en las cabezas
de los miembros del equipo.
El equilibrio del conocimiento tcito con el
entrenamiento y el proceso definido es clave.
El desarrollo delgado/gil requiere de un rpido
entorno de trabajo
- Habilidades.
- Dominio.
- Tecnologa
- Mejora para procesos de alto - nivel (delgado).

06/02/2013
LSD: Atributos
4 Concurrencia y Comunicacin (IPT)
Desarrollo delgado/gil = crisol para la
concurrencia y comunicacin.
Concurrencia = todos los miembros del
equipo y los stakeholders tienen un acceso
de ofensiva de tiempo real cercano a toda
la informacin del proyecto.
La comunicacin de empuje continuo es
crtica
- Tecnologas.
- Conjunto de habilidades de comunicacin.

06/02/2013
LSD: Atributos
4 El Soporte de la Ingeniera gil
Soporte de ingeniera delgado/gil = CM, AQ, Mtricas.
Gestin de configuracin gil
- Registro /Puesta a punto gil.
- La contabilidad del estado gil y auditorias de la
configuracin.
- Sistema CM gil.
- Gestin de cambio gil.
La seguridad de calidad gil
- Agregar valor por reduccin de riesgo o defectos en
horas o un da.
- Acoplamiento firme para proyectar las actividades.
Mtricas giles
- Etiqueta de instruccin (Kanban) o visualizacin de
"tirn" para todos los miembros del equipo.
- Progreso del proyecto y convergencia del diseo.
06/02/2013
LSD: Atributos
4 La Gestin del Proyecto Delgado/gil
Habilidades en aproximaciones (NO) "basadas en Plan" (tal como el
CMMI tradicional):
- La planificacin de detalle temprana.
- Requerimientos tempranos de "entendimiento" y estabilidad.
- Enfocado en la supervisin del proyecto en comparacin del plan.
Habilidades en la gestin del proyecto delgado/gil:
- Viendo prdidas.
- Mapeo del flujo de valor.
- Retroalimentacin.
- Iteracin de la direccin /gestin.
- Pensamiento de opciones.
- ltima fabricacin de decisin de momento responsable.
- Sistemas de Tiro /Seal y dimensiones.
- Costo del conocimiento de retraso.
- El mismo fortalecimiento de determinacin /equipo.
- Motivacin y direccin.
- Especializacin tcnica.
- Refactorizacin (el diseo contra la arquitectura ms estable).
06/02/2013
LSD: Atributos
4 Gasto en el Desarrollo Delgado/gil
Trabajar parcialmente.
Extra procesos.
Extra rasgos.
Tarea cambiante.
Esperando.
Movimiento.
Defectos.
Actividades de vigilancia/control
tradicional.
06/02/2013
Bibliografa sobre LD, LSD
4Poppendieck, Mary; Poppendieck Tom: Lean
Development Software. John Wiley & Sons. 2003.
4Ohno, Taichii: Toyota Production System: Beyond
Large - Scale production. Productivity Press. 1999.
4Goldratt, Eliyahu; Cox, Jeff: The Goal. Nort River
Press. 2002.
4Womack, James; Jones, Daniel: Lean Thinking.
Ediciones Gestin. 2000-2006.
4Kennedy, Michael: Product Development in the Lean
Enterprise. The Oaklea Press. 2003.
4Liker, Jeffrey: The Toyota Way. McGraw Hill. 2003.
4Japan Mangement Association: Kanban: Just In Time
At Toyota - Productivity Press - 1998.

06/02/2013
Bibliografa sobre LD y LSD
06/02/2013
Sitios Web sobre AM
4 http://www.strategosinc.com/principles.html
4 http://www.poppendieck.com/ld.htm
4 http://www.cutter.com/consultants/charetter.html
4 http://www.itabhi.com/
4 http://www.shmula.com/183/12-questions-with-mary-
poppendieck

06/02/2013
Microsoft
Solutions
Framework (MSF)
y los Mtodos
giles
06/02/2013
Microsoft Solutions
Framework (MSF)
4 Los mtodos giles de desarrollo de software
tienen una larga tradicin en las prcticas de
software. Uno de los textos clsicos de RAD
(Rapid Applications Development) de Steve
McConell, se remonta a una tradicin ms
temprana de los MAs contemporneos; al igual
que stos, reconocen como mejores prcticas
al modelo de ciclo evolutivo, a los encuentros y
talleres de equipo, las revisiones frecuentes, el
diseo para el cambio, la entrega evolutiva, la
reutilizacin, el prototipado evolutivo, la
comunicacin intensa, el desarrollo iterativo e
incremental.
06/02/2013
Microsoft Solutions
Framework (MSF)
4 MSF se encuentra en estrecha comunin de
principios con los mtodos giles, algunas de
cuyas intuiciones y prcticas han sido anticipadas
en las primeras versiones de su canon en 1994.
4 MSF reconoce la naturaleza cardica (una mezcla
de caos y orden, segn lo acuara Dee Hock,
fundador y anterior CEO de Visa International)
de los proyectos de tecnologa. Toma como punto
de partida el supuesto de que debe esperarse el
cambio continuo y que es imposible aislar un
proyecto de solucin de estos cambios. Adems
de los cambios procedentes del exterior, MSF
aconseja a los equipos que esperen cambios
originados por los participantes, e incluso por el
mismo equipo.
06/02/2013
MSF: Modelo del Proceso
4 Microsoft Solutions Framework (MSF) es una
flexible e interrelacionada serie de conceptos,
modelos y prcticas de uso que controlan la
planificacin, el desarrollo y la gestin de
proyectos tecnolgicos. MSF se centra en los
modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnolgicas.
Originalmente creado en 1994 para conseguir
resolver los problemas a los que se enfrentaban
las empresas en sus respectivos proyectos, se ha
convertido posteriormente en un modelo prctico
que facilita el xito de los proyectos tecnolgico
MSF se compone de varios modelos y disciplinas
encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto.
06/02/2013
Microsoft Solutions
Framework (MSF)
4 Los componentes de MSF pueden aplicarse individualmente o
colectivamente para mejorar las proporciones de xito para los
siguientes tipos de proyectos:
Proyectos de desarrollo de software, incluyendo mvil,
aplicaciones para Web y e-comercio, servicios de Web,
mainframes y n capas.
Proyectos de despliegue de infraestructura, incluyendo
despliegue de escritorio, actualizacin de sistemas
operativos, despliegue de mensajera de empresa,
despliegue de sistemas de gestin de configuracin y
operaciones.
Los proyectos de integracin de aplicacin empaquetados,
incluyendo suites de productividad personal, planificacin
de recursos de empresa (ERP), solucin de gestin de
proyectos de empresa.
Cualquier combinacin compleja de lo anterior.

06/02/2013
Microsoft Solutions
Framework (MSF)
4 En los ltimos aos han aparecido estrategias de
desarrollo de software que buscan maximizar el
principio de agilidad y la preparacin para el cambio.
MSF alienta estas estrategias all donde sea
apropiado. Los mtodos giles como Lean
Development, eXtreme Progaming, Adaptative
Software Development, son estrategias de desarrollo
de software que alientan prcticas que son
adaptativas en lugar de predictivas, centradas en la
gente y el equipo, iterativas, orientadas a las
prestaciones, de comunicacin intensiva y que
requieren que el negocio se involucre directamente.
MSF y los mtodos giles estn muy alineadas tanto
en los principios como en la prctica en ambientes que
requieren alto grado de adaptabilidad.
06/02/2013
Microsoft Solutions
Framework - Orgenes
4 Microsoft Solutions Framework
Establecida en 1991, se hizo pblico en
1993 (v. 1), revisada completamente en
1998 (v. 2), Enero 2003 (v. 3) y una nueva
en Marzo 2006 (v. 4), con Core formalmente
publicado en Octubre del 2006.
4 Relacionado con MOF, Microsoft
Operational Framework
Qu se concentra en la gestion de la
infraestructura de las TI.
Noticias: MOF probablemente formar
parte de MSF en el futuro.
06/02/2013
MSF: Qu es un
Framework?
4 Al contrario de una metodologa, un
framework (marco, estructura) es un
juego de herramientas conceptuales y
las mejores prcticas.
4 En MSF v.4 se ve frameworks y
metodologas en accin.
La palabra framework ya no es
precisa.
06/02/2013
Entrega de Soluciones: El
xito no ha venido fcilmente
Fallado Exitoso Desafo
2003
2000
1998
1995
1994
15%
23%
28%
40%
31%
34%
28%
26%
27%
16%
51%
49%
46%
33%
53%
Los grficos pintan el resultado de las 30000 aplicaciones en
grandes, medianas y pequeas compaas de industria cruzada
de EEUU probadas por el Standish Group desde 1994
06/02/2013
Cmo volverse exitoso?
4 Entender direcciones comerciales, metas, y
oportunidades.
4 Asegurar que las metas del proyecto apoyen
las metas comerciales.
4 Dilogo frecuente con los involucrados y
patrocinadores.
4 Organizar los equipos para que puedan
trabajar eficazmente.
4 Tomar una vista ms larga para resolver los
desafos: aprender & mejorar.
4 Direccin proactiva de riesgos y problemas.
4 Entrega incremental de solucin.
06/02/2013
MSF: Modelos prescriptivos
y descriptivos
4Un modelo de ciclo de vida de desarrollo de software
descriptivo documenta el proceso pasivamente,
desde el punto de vista de un observador. Son muy
tiles como base de conocimiento y mejora de
procesos de desarrollo de software.
4Un modelo prescriptivo describe el proceso en
trminos de los involucrados, la secuencia de
actividades, y el producto final.
4Un modelo descriptivo se puede traducir en uno o
ms modelos prescriptivos, y a stos se los pone en
accin.
06/02/2013
MSF: Versiones 3 y 4
4MSF 3.0:
Describe las mejores prcticas en trminos de
principios bsicos, modelos conceptuales, y
disciplinas.
Provee las bases descriptivas desde las cuales puede
derivar cualquier metodologa especfica.
4MSF 4.0:
Tambin un framework descriptivo similar en muchos
aspectos, pero la gran diferencia es incluye dos
metodologas prescriptivas:
-MSF para el desarrollo de Aplicaciones giles.
-MSF para el proceso de mejora CMMI.
MSF 4.0 se denomina metamodelo, para evitar
confusiones.
06/02/2013
MSF: Principios
4 MSF 3.0:
Promueve 8 principios bsicos:
1. Promover comunicaciones abiertas.
2. Trabajar hacia una visin compartida.
3. Otorgar poder a los miembros del equipo.
4. Establecer responsabilidades claras y compartidas.
5. Concentrarse en la entrega de valor de negocios.
6. Permanecer gil, y esperar el cambio.
7. Invertir en calidad.
8. Aprender de todas las experiencias.
06/02/2013
MSF: Principios
4 MSF 4.0:
Agrega 2 principios ms:
1. Compaerismo con los clientes.
2. Crear siempre productos entregables.
06/02/2013
MSF: Caractersticas
4 Adaptable: Es parecido a un comps, con el
cual podemos sealar un lugar dentro de un
mapa, y aplicarlo a ese lugar especfico.
4 Escalable: Puede organizar equipos tan
pequeos entre 3 o 4 personas, as como
tambin, proyectos que requieren 50
personas a ms.
4 Flexible: Es utilizada en el ambiente de
desarrollo de cualquier cliente.
4 Tecnologa Agnstica: Porque puede ser
usada para desarrollar soluciones basadas
sobre cualquier tecnologa.

06/02/2013
MSF: Modelos y Disciplinas
Modelos
Modelo de Equipo
Modelo de Proceso
Gestin de Proyectos
Gestin de Riesgos
Disciplinas
Gestin de Preparacin
Calidad de Servicio
Seguridad
Desempeo
Tolerancia a fallas
06/02/2013
MSF: Principios y hbitos
4 Prcticas
probadas
4 Principios
Los valores
que gobiernan
el equipo.
4 Hbitos
Atributos
individuales.

Hbitos
Principios
La Calidad es
Definida por el
Cliente
Calidades
de Servicio
Sostener
Comunicac
in Abierta
Permanecer gil,
Adaptarse al
Cambio
Voluntad para
Aprender
Compaerismo
con los Clientes
Equipos de
pares
La Calidad es
Trabajo Diario de
Todos
Orgullo de
Habilidad
Conseguir algo
Especfico
Tempranamente
Trabajar hacia
una Visin
Compartida
Ciudadana
Hacer del Despliegue
un Hbito
Entrega
Frecuente
Flujo de
Valor
06/02/2013
MSF: Capas del Modelo de
Proceso
4 Hbitos: Orientar a los
miembros de equipo para ver
cmo deben acercarse a la
entrega de la solucin.
4 Principios: Guiar cmo el
equipo debe trabajar en
conjunto para entregar la
solucin.
4 Actividades: Cmo realizar la
solucin (i.e. procesar la
promulgacin).
4 Proceso: Optimizar las
ventajas de los recursos del
proyecto, balancear las
restricciones del proyecto, y
organizar y realizar el trabajo
del proyecto para entregar la
solucin.

Proceso
Actividades
Principios
Hbitos
06/02/2013
Microsoft Solutions
Framework (MSF)
4 MSF ha diseado tanto su Modelo de Equipo como su
Modelo de Proceso para anticiparse al cambio y
controlarlo.
El Modelo de Equipo alienta la agilidad para hacer frente a
nuevos cambios, involucrando a todo el equipo en las
decisiones fundamentales, asegurndose as que lo exploran
y lo revisan los elementos de juicio desde todas las
perspectivas crticas.
El Modelo de Proceso a travs de su estrategia iterativa en
la construccin de productos del proyecto, suministra una
imagen ms clara del estado de los mismos en cada etapa
sucesiva. El equipo puede identificar con mayor facilidad el
impacto de cualquier cambio y lidiar con l efectivamente
minimizando los efectos colaterales negativos mientras
optimiza los beneficios.
06/02/2013
MSF: Modelo de Equipo
Arquitectur
a
Gestin del
Programa
Gestin del
Producto
Experiencia
del Usuario
Lanzamiento /
Operaciones
Prueba
Desarrollo
Diseo de Solucin
Construccin de Solucin
Verificacin de Solucin
Validacin de Solucin
Despliegue de Solucin
Usabilidad de Solucin
Definicin de Solucin
Entrega de Solucin
06/02/2013
MSF: Modelo de Proceso para
Desarrollo de Aplicaciones
Desarrollando
MSF
Entrega Completa
Visin /Alcance
Aprobados
Plan de Proyecto
Aprobado
Alcance
Completo
Versin
Aprobada
06/02/2013
MSF: Proceso Guiado por Hitos
4 Los hitos:
Son puntos de revisin y sincronizacin, no
puntos de congelamiento.
Permitir a los equipos demostrar el avance y
corregir a tiempo.
4 El modelo utiliza dos tipos de hitos:
Mayores (acuerdo por continuar).
Intermedios.
4 Los entregables son la evidencia
fsica que el hito se cumpli.

06/02/2013
MSF: Modelo de Proceso -
Iteracin
Iteracin 0 Iteracin 1
Iteracin n
Repetir mientras
sea necesario
Plan de
Configuracin
del Proyecto
Desarrollo del
Plan y
Retroalimentacin
de Prueba
Desarrollar y
probar
producto de
Lanzamiento
Desarrollo del
Plan y
Retroalimentacin
de Prueba
06/02/2013
MSF: Modelo de Proceso
con un enfoque Iterativo
Minimizacin de riesgo partiendo de un proyecto en
mltiple versiones
Tiempo
F
u
n
c
i
o
n
a
l
i
d
a
d

Versin 1
Versin 2
Versin 3
06/02/2013
MSF: Beneficios del Versionado
4 Fuerza el cierre de temas pendientes.
4 Establece objetivos a corto plazo.
4 Maneja la incertidumbre y los cambios
del Alcance.
4 Alienta la liberacin de funcionalidad
de incrementos.
4 Mejora el Tiempo para Comerciar.

06/02/2013
MSF: Guas para el Versionado
4 Mentalidad de producto y plan
multiversin.
4 Ciclos rpidos para mantener el
inters del Cliente y ejercitar la
liberacin en el Equipo de Trabajo.
4 Liberar primero lo bsico, de modo tal
que se pueda construir sobre l.
4 No construir versiones que no
agreguen valor para el negocio.
06/02/2013
MSF: Desafos del Proceso
4 Ningn proceso simple o producto de
metodologa ha satisfecho las necesidades de
una organizacin entera.
4 Procesar la personalizacin de la Metodologa y
la expansin es la norma.
4 Guas del proceso no automatizada con el flujo
de trabajo
4 El entrenamiento del proceso es caro.
4 La recoleccin de los datos del Ciclo de Vida es
un intruso para enganchar el da de recursos a
las tareas del da.
06/02/2013
MSF: Disciplina de Gestin
de Proyectos
4 La administracin de proyectos incluye
estas reas de conocimiento:
Integracin de proyectos.
Alcance de proyectos.
Tiempo de proyectos.
Costo de proyectos.
Recursos humanos del proyecto.
Comunicaciones de proyectos.
Riesgos de proyectos.
Obtencin de proyectos.
Calidad de proyectos.
06/02/2013
MSF: Proceso de
Administracin de Riesgos
06/02/2013
MSF: Tringulo de Negociacin
manejar el Alcance
El tringulo representa la relacin variable entre
Recursos Calendario y Funcionalidad
Funcionalidad
06/02/2013
manejar el Alcance
Matriz de Negociacin entre el Equipo y los
Usuarios
Fijar Elegir Adecuar
Recursos
-
Calendario
-
Funcionalidad
-
06/02/2013
manejar el Alcance
Matriz de Negociacin del Proyecto
Fijar Elegir Adecuar
Recursos -
Calendario -
Funcionalidad -
Funcionalidad
Dado Recursos fijos, podemos elegir el Calendario y
adecuar la Funcionalidad cuando sea necesario.
06/02/2013
MSF para el Desarrollo gil
de Software
4 Iterativo e incremental.
4 Manejado por escenarios.
4 Equipos pequeos (los grandes proyectos utilizan el equipo de
aproximacin de equipos).
4 Mentalidad de Servicio de Calidad.
4 Utiliza un contexto manejado por la aproximacin de pruebas
(basado en los principios de mtrica de pruebas).
1. Objetivos Revisados (Reuniremos la mnima aceptacin
de nivel de funcionalidad?).
2. Progreso Accedido (Estamos haciendo el progreso
necesario para hallar nuestra fecha lmite?).
3. Principios de Prueba Evaluados (Estamos manteniendo
un nivel apropiado de calidad?).
4. Identificacin de Riesgos Mitigado (Estamos dirigiendo
el proyecto y el riesgo tcnico?).
5. Despliegue Listo (Hemos diseado y creado una solucin
que est lista para desplegar?).
06/02/2013
MSF y Desarrollo de Software
4 Sin duda, el nfasis de MSF v 4 est en el
El equipo de MSF es ahora firmemente una
parte del grupo de Visual Studio dentro de
Microsoft.
4 La ligazn de la estructura a las herramientas
(VSTS) era el golpe maestro que le dio un
futuro muy prspero a MSF.
Y viceversa: el mtodo agrega el valor a las
herramientas, ms all de lo que cualquier
competidor de Microsoft podra ofrecer hoy.
06/02/2013
MSF para Despliegue de
Infraestructura
4 El aspecto de MSF v 3 que puede integrarse en MOF
(Microsoft Operations Framework).
O, quizs, MSF v 5 toma una mirada atrs al
Despliegue de Infraestructura / Soluciones
Comerciales (todava hoy, con otra metodologa).
4 Entretanto, por favor considerar el uso de MSF v 3 o
MOF puramente para proyectos orientados a
despliegue de la infraestructura.
Funciona muy muy bien.
Las habilidades delicadas, como las ideas buenas,
en cualquier caso, slo envejecen como el vino.

06/02/2013
MSF: Estado del material
lanzado
4 MSF v3 ha sido oficialmente retirado
El curso MOC (Microsoft Official Course) #1846 ser retirado,
pero todava estar disponible.
4 MSF v4 Core ha sido lanzado
Libro de referencia: Microsoft Solutions Framework
Essentials de Mike Turner.
El nuevo de MSF v4 Essentials est en estado RC.
4 MSF v4 para Desarrollo de Aplicaciones (gil y
CMMI) ha sido enviado en marzo del 2006
Se puede bajar la guia de www.microsoft.com/msf
4 Plantillas para SCRUM (desde Conchango) y RUP
(desde Osellus) disponible desde junio del 2006
No hay, por su puesto, MSF, pero MSF 4.0 Core resume bien
esas aproximaciones.
06/02/2013
MSF: Estado del material
todava por venir
4 MSF v4 para Despliegue de Infraestructura
Bajo desarrollo en la actualidad (das tempranos).
4 MSF v 4 Core para Consulta
Debatindose.
4 MSF v 4 para Gestion de Operaciones
Bajo consideracin como un complemento o sucesor de
MOF.
E iguala quizs a CIR (Continuous Improvement
Roadmap, Mapa de Carretera de Mejoramiento Continuo).
4 Los condimentos interiores de MSF tambin se estn
desarrollando.
Noticias realmente buenas para la comunidad
06/02/2013
MSF + MOF +MRF
06/02/2013
Bibliografa sobre MSF
4Turner, Michael S.V.: Microsoft Solutions
Framework Essentials . Microsoft Corp. 2006.
4Lory, Geoffrey; Campbell, Derick: Microsoft
Solutions Framework 3.0. Microsoft Corp. 2003.
4Snyder, Mike; Steger, Jim: Working with Microsoft
Dynamics CRM 3.0. Microsoft Corp. 2006.
4Wiegers, Karl E.: More About Software
Requirements: Thorny Issues and Practical Advice.
Microsoft Corp. 2005.
4Hansen, John Erick; Thomsen, Cartsen: Enterprise
Development with Visual Studio .Net, UML, and MSF.
Apress. 2004.

06/02/2013
Bibliografa sobre LD y LSD
06/02/2013
Sitios Web sobre MSF
4 http://www.microsoft.com/msf
4 http://www.msdn.microsoft.com/visualstudio/enterpris
e/msf
4 http://www.microsoft.com/technet/solutionaccelerator
s/msf/default.mspx
4 http://msdn2.microsoft.com/en-us/teamsystem/aa7187
95.aspx
4 http://www.microsoft.com/mof
4 http://msmvps.com/blogs/ffagas/default.aspx
4 http://msdn.microsoft.com/vstudio/teamsystem/team
4 http://www.microsoft.com/downloads/details.aspx?Fa
milyID=9f3ea426-c2b2-4264-ba0f-35a021d85234&Disp
layLang =en
4 http://catalog.vsipmembers.com/catalog

06/02/2013
Open
Source
06/02/2013
Open Source
06/02/2013
Open Source
4 Cdigo abierto (del ingls open source) es el trmino con el
que se conoce al software distribuido y desarrollado libremente.
Fue utilizado por primera vez en 1998 por algunos usuarios de la
comunidad del software libre, tratando de usarlo como
reemplazo al ambiguo nombre original en ingls del software libre
(free software).
4 En la actualidad open source es utilizado para definir un
movimiento nuevo de software (la Open Source Initiative),
diferente al movimiento del Software Libre, incompatible con
este ltimo desde el punto de vista filosfico, y completamente
equivalente desde el punto de vista prctico, de hecho, ambos
movimientos trabajan juntos en el desarrollo prctico de
proyectos.
4 El significado obvio de "cdigo abierto" es que "se puede mirar
el cdigo fuente, que es un trmino ms dbil y flexible que el
del software libre; un programa de cdigo abierto puede ser
software libre, pero tambin puede ser semilibre o incluso
completamente propietario; pero tambin, un programa de cdigo
abierto puede ser y de hecho es software libre, como tambin un
programa Software Libre es Open Source.
06/02/2013
Open Source: Cronologa
4 22 enero 1998: Netscape anuncia que liberar el cdigo
fuente del Navigator.
4 3 febrero 1998: En la reunin de Palo Alto se acua el
trmino 'open source' y durante la semana siguiente Bruce
Perens and Eric S. Raymond lanzan opensource.org/.
4 31 marzo 1998: El cdigo del Navigator ya est
disponible: en unas horas, mejoras del programa invaden la
red.
4 7 mayo 1998: Corel Computer Corporation anuncia el
Netwinder, una computadora econmica que corre bajo
Linux.
4 11 mayo 1998: Corel anuncia sus planes de adaptar
WordPerfect y el resto de sus programas de ofimtica a
Linux.
4 28 mayo 1998: Sun Microsystems y Adaptec se unen a
Linux International (las primeras grandes empresas
vendedoras de equipos y sistemas operativos en hacerlo).
06/02/2013
4 13-17 julio 1998: Oracle e Informix anuncian que
conectarn sus bases de datos a Linux.
4 10 agosto 1998: Sun Microsystems ofrece Solaris a
usuarios individuales e instituciones educativas o sin
nimo de lucro.
4 1 noviembre 1998: Se publican los Halloween
Documents: planes de Microsoft contra Linux y otros
proyectos open source.
4 16 diciembre 1998: IDG anuncia que la cuota de mercado
del Linux se increment un 212% en 1998.
4 1-5 marzo 1999: LinuxWorld: primera exposicin sobre
Linux. HP, IBM, SAP inician el comienzo del apoyo de las
firmas comerciales.
4 15 marzo 1999: Apple lanza Darwin bajo licencia open
source.
4 4 junio 1999: Microsoft afirma que Linux vende ms que
Windows 98 en las grandes superficies.
06/02/2013
4 Entre 1998 y 2000 se observ un gran crecimiento en
la popularidad de Linux y de la formacin de muchas
empresas pro software de cdigo abierto.
06/02/2013
Open Source: Declogo
4 El movimiento Open Source tiene un declogo que
debe cumplir un cdigo para poder llamarse "Open
Source" (estas 10 premisas son completamente
equivalentes con las 4 libertades o principios del
Software Libre):
1. Libre redistribucin: El software debe poder ser
regalado o vendido libremente.
2. Cdigo fuente: El cdigo fuente debe estar
incluido u obtenerse libremente.
3. Trabajos derivados: La redistribucin de
modificaciones debe estar permitida.
4. Integridad del cdigo fuente del autor: Las
licencias pueden requerir que las modificaciones
sean redistribuidas slo como parches.
5. Sin discriminacin de personas o grupos: Nadie
puede dejarse fuera.
06/02/2013
Open Source: Declogo
6. Sin discriminacin de reas de iniciativa: Los
usuarios comerciales no pueden ser excluidos.
7. Distribucin de la licencia: Deben aplicarse los
mismos derechos a todo el que reciba el programa
8. La licencia no debe ser especfica de un
producto: El programa no puede licenciarse solo
como parte de una distribucin mayor.
9. La licencia no debe restringir otro software: La
licencia no puede obligar a que algn otro software
que sea distribuido con el software abierto deba
tambin ser de cdigo abierto.
10. La licencia debe ser tecnolgicamente neutral:
No debe requerirse la aceptacin de la licencia por
medio de un acceso por clic de ratn o de otra
forma especfica del medio de soporte del software.

06/02/2013
Open Source: Caractersticas
4 La intencin de la definicin de Open Source es
establecer ciertos criterios que contengan la esencia
de lo que los programadores quieren que signifique:
que aseguren que los programas distribuidos con
licencia open source estarn disponibles para su
continua revisin y mejora para que alcancen niveles
de fiabilidad que no pueda conseguir ningn programa
comercial cerrado.
4 Un programa Open Source va unido algunas
caractersticas importantes:
4 FLEXIBILIDAD: Si el cdigo fuente est disponible,
los desarrolladores pueden aprender y modificar los
programas a su antojo, adaptndolo para realizar
tareas especficas. Adems, se produce un flujo
constante de ideas que mejora la calidad de los
programas.
06/02/2013
Open Source: Caractersticas
4 FIABILIDAD Y SEGURIDAD: Con varios
programadores a la vez mirndose el mismo trabajo,
los errores se detectan y corrigen antes, por lo que el
producto resultante es ms fiable y eficaz que el
comercial.
4 RAPIDEZ DE DESARROLLO: Las actualizaciones y
ajustes se realizan a travs de una comunicacin
constante va Internet. Menores tiempos de desarrollo
debido a la amplia disponibilidad de herramientas y
libreras.
4 RELACIN CON EL USUARIO: El programador se
acerca mucho ms a las necesidad real de su cliente,
y puede crear un producto especfico para l.
4 LIBRE: Es de libre distribucin, cualquier persona
puede regalarlo, venderlo o prestarlo.
4 COMBATE EFECTIVAMENTE LA PIRATERA DE
SOFTWARE.
06/02/2013
Open Source
4 Cdigo abierto, como puede verse, es un estilo de
software, no tanto un proceso. Sin embargo hay una
manera definida de hacer las cosas en la comunidad de
cdigo abierto, y mucho de sus principios se aplican
tanto a proyectos de cdigo cerrado como a los de
cdigo abierto. En particular su proceso encaja en
equipos fsicamente distribuidos, lo qu es importante
porque la mayora de los procesos adaptables exigen
equipos locales.
4 El cdigo abierto tiene uno o ms mantenedores. Un
mantenedor es la nica persona autorizada para
integrar los cambios en la base del cdigo fuente. Sin
embargo otras personas pueden modificar el cdigo
fuente, pero deben enviarlo al mantenedor para que lo
revise y lo integre a la base del cdigo fuente.
Normalmente este cambios se hacen a travs de los
parches. El mantenedor coordina los parches y se
encarga de mantener el diseo del software.
06/02/2013
Open Source
4 En una Sociedad de la Informacin donde todos los
sistemas estn interconectados entre s, es de suma
importancia conocer hasta el ltimo detalle del flujo de la
informacin para garantizar no exista filtraciones
expresamente programadas como los "troyanos.
4 Tambin es importante prevenir la ausencia de errores en el
funcionamiento del software, puesto que esos errores pueden
convertirse en agujeros que los atacantes puede utilizar para
conseguir informacin reservada.
4 Cuando el cdigo es abierto, la industria local puede
examinarlo para mejorarlo y adaptarlo a las sus necesidades
particulares, segn cada caso. Para crear y modificar cdigo
no se requiere de gran infraestructura de hardware; basta una
computadora y el suficiente conocimiento.
4 As, para que la industria local pueda participar, basta con
tener acceso al cdigo y el permiso legal para poderlo
modificar y ampliar. El resultado son nuevos productos o
nuevas versiones de programas que ya existen.

06/02/2013
Herramientas de OS: Linux
4 Linux es la denominacin de
un sistema operativo tipo
Unix y el nombre de un ncleo.
Es uno de los paradigmas ms
prominentes del Software
Libre y del desarrollo del
Cdigo Abierto, cuyo cdigo
fuente est disponible
pblicamente, para que
cualquier persona puede
libremente usarlo, estudiarlo,
redistribuirlo y, con los
conocimientos informticos
adecuados, modificarlo.
06/02/2013
Herramientas de OS: Apache
4 El servidor HTTP Apache es un
software (libre) servidor HTTP de
cdigo abierto para plataformas
Unix (BSD, GNU/Linux, etc.),
Windows, Macintosh, y otras, que
implementa el protocolo HTTP/1.1 y
la nocin de sitio virtual. Cuando
comenz su desarrollo en 1995 se
bas inicialmente en cdigo del
popular NCSA HTTPd 1.3, pero
ms tarde fue reescrito por
completo. Su nombre se debe a que
originalmente Apache consista
solamente en un conjunto de
parches a aplicar al servidor de
NCSA. Era, en ingls, a patchy
server (un servidor "parcheado ).
06/02/2013
Herramientas de OS: PHP
4 PHP es un lenguaje de programacin
usado frecuentemente para la creacin
de contenido para sitios Web con los
cuales se puede programar las
paginas Html y los cdigos fuente.
PHP es un acrnimo recursivo que
significa PHP Hypertext Pre-
processor" (inicialmente PHP Tools, o,
Personal Home Page Tools), y se
trata de un lenguaje intrprete usado
para la creacin de aplicaciones para
servidores, o creacin de contenido
dinmico para sitios Web. ltimamente
tambin para la creacin de otro tipo
de programas incluyendo aplicaciones
con interfaz grfica usando las libreras
Qt o GTK+ .
06/02/2013
Herramientas de OS: Perl
4 Perl, Lenguaje Prctico para la
Extraccin e Informe es un lenguaje
de programacin diseado por Larry
Wall creado en 1987. Perl toma
caractersticas del C, del lenguaje
interprete shell (sh), AWK, sed, Lisp
y, en un grado inferior, muchos otros
lenguajes de programacin.
4 Estructuralmente, Perl est basado en
un estilo de bloques como los del C o
AWK, y fue ampliamente adoptado por
su destreza en el procesado de texto y
no tener ninguna de las limitaciones de
los otros lenguajes de script.
06/02/2013
Herramientas de OS: MySQL
4 MySQL es un Sistema de Gestin
de Base de Datos Relacional,
multihilo y multiusuario con ms de
seis millones de instalaciones.
MySQLAB desarrolla MySQL como
software libre en un esquema de
licenciamiento dual. Por un lado lo
ofrece bajo la GNU GPL, pero,
empresas que quieran incorporarlo
en productos privativos pueden
comprar a la empresa una licencia
que les permita ese uso.
06/02/2013
Herramientas de OS: CVS
4 CVS; Sistema Concurrente de Versiones,
es una forma de trabajo, habitualmente
destinada a almacenar cdigo fuente de
grandes proyectos de software. CVS
almacena todas las versiones de todos los
archivos de manera que nunca se pierde nada
y su utilizacin por varias personas es
registrada. Tambin proporciona una forma de
combinar cdigo de dos o ms personas que
estn trabajando simultneamente en el
mismo archivo. Todo el cdigo y sus versiones
son almacenadas en un solo servidor: Puede
encontrarse un versin completa de CVS en el
libro Open Source Development with CVS.
06/02/2013
Herramientas de OS: CVS
4 Mdulos CVS
Dentro de CVS, la palabra mdulo hace
referencia a colecciones separadas de cdigo.
Por ejemplo, Moodle tiene los siguientes
mdulos en su repositorio:
Moodle: el cdigo principal de Moodle.
Contrib: contribuciones de los usuarios y todo tipo
de cdigo de desarrollo.
Mysql: un PhpMyAdmin personalizado para
trabajar con la base de datos Moodle.
Windows- cron: un pequeo paquete que hace
posible el funcionamiento de cron en Windows.
Docs: variada documentacin extra generada por
los usuarios.

06/02/2013
Bibliografa sobre Open Source
4Fogel, Karl; Bar, Moshe: Open Source Development
with CVS . Paraglyph Press. 2003.
4Dibona, Chis; Stone, Mark; Cooper, Danese: Open
Sources Voices from the Open Source Revolution.
OReilly 1999.
4Dibona, Chis; Stone, Mark; Cooper, Danese: Open
Sources 2.0 The Continuing Evolution. OReilly
2005.
4Raymond, Eric S.: The Cathedral and the bazaar:
musing and Linux and Open Source by an accidental
revolutionary. OReilly 2005.

06/02/2013
Bibliografa sobre Open Source
06/02/2013
Sitios Web sobre Open Source
4 http://opensource.org/
4 http://www.itrainonline.org/itrainonline/spanis
h/opensource.shtml#top
4 http://www.opensourceworldconference.com/
malaga06/es/modules/news/
4 http://www.opensourcecms.com/
4 http://www.todoexpertos.com/categorias/tecn
ologia-e-internet/desarrollo-de-sitios-
web/respuestas/1131372/open-source - 30k
06/02/2013
Ventajas y
Desventajas de
los Mtodos
giles
06/02/2013
Ventajas y Desventajas de
los Mtodos giles
4Ventajas de las metodologas giles
Las metodologas giles presentan diversas
ventajas como:
Rpida respuesta a cambios de requisitos a lo
largo del desarrollo.
Entrega continua y en plazos cortos de software
funcional.
Trabajo conjunto entre el cliente y el equipo de
desarrollo.
Minimiza los costos frente a cambios.
Importancia de la simplicidad, al eliminar el
trabajo innecesario.
06/02/2013
los Mtodos giles
4Ventajas
Atencin continua a la excelencia tcnica y al buen
diseo.
Mejora continua de los procesos y el equipo de
desarrollo.
Evita malentendidos de requerimientos entre el
cliente y el equipo.
El equipo de desarrollo no malgasta el tiempo y
dinero del cliente desarrollando soluciones
innecesariamente generales y complejas que en
realidad no son un requisito del cliente.
Cada componente del producto final ha sido
probado y satisface los requerimientos.
06/02/2013
los Mtodos giles
4Desventajas de las metodologas giles
Como en cualquiera otra metodologa, tambin hay desventajas
y problemas que surgen a la hora de implementarlas:
Falta de documentacin del diseo. El cdigo no puede
tomarse como una documentacin. En sistemas de tamao
grande se necesitar leer los cientos o miles de pginas del
listado de cdigo fuente.
Problemas derivados de la comunicacin oral. Este tipo de
comunicacin resulta difcil de preservar cuando pasa el
tiempo y est sujeta a muchas ambigedades.
Falta de calidad. Probar el cdigo de forma constante no
genera productos de calidad, slo revela falta de anlisis y
diseo.
Problemas derivados de la comunicacin oral. Este tipo de
comunicacin resulta difcil de preservar cuando pasa el
tiempo y est sujeta a muchas ambigedades.

06/02/2013
los Mtodos giles
4Desventajas .
Fuerte dependencia de las personas. Como se evita en lo
posible la documentacin y los diseos convencionales, los
proyectos giles dependen crticamente de las personas.
Falta de procesos de revisin del cdigo. Con mtodos como
el PSP o TSP se han conseguido reducciones de errores que
oscilan entre el 60 y el 80%. La programacin en parejas tiene
resultados del 20 al 40%, que no es mucho frente al 10 y el
25% de un programador.
Falta de reusabilidad. La falta de documentacin hacen difcil
que pueda reutilizarse el cdigo gil.
Sobre costos y retrasos derivados de la refactorizacin
continua. Para un sistema de ciertas proporciones, los costos y
retrasos derivados de la refactorizacin no pueden
despreciarse.
Restricciones en cuanto a tamao de los proyectos
abordables.
06/02/2013
los Mtodos giles
4Desventajas .
Rigidez. Algunos mtodos giles son muy rgidos:
deben cumplirse muchas reglas de una forma
estricta para garantizar el xito del proyecto. Por
ejemplo XP exige en realidad mucho esfuerzo,
concentracin y orden.
Cambios. Los modelos de datos son pesados y no
pueden cambiarse as como as solo porque el
cliente que ira incorporar ms funciones al sistema.
Problemas derivados del fracaso de los proyectos
giles. Si un proyecto gil fracasa no hay
documentacin o hay muy poca; lo mismo ocurre
con el diseo. La comprensin del sistema se queda
en las mentes de los desarrolladores.
06/02/2013
los Mtodos giles
4Conclusin
No existe una metodologa universal para hacer
frente con xito a cualquier proyecto de desarrollo
de software.
Toda metodologa debe ser adaptada al contexto del
proyecto (recursos tcnicos y humanos, tiempo de
desarrollo, tipo de sistema, etc.) Histricamente, las
metodologas tradicionales han intentado abordar la
mayor cantidad de situaciones de contexto del
proyecto, exigiendo un esfuerzo considerable para
ser adaptadas, sobre todo en proyectos pequeos y
con requisitos muy cambiantes.
Las metodologas giles ofrecen una solucin casi a
medida para una gran cantidad de proyectos que
tienen estas caractersticas.
06/02/2013
Ventas y Desventajas de
los Mtodos giles
4Conclusin
Una de las cualidades ms destacables en una metodologa gil
es su sencillez, tanto en su aprendizaje como en su aplicacin,
reducindose as los costos de implantacin en un equipo de
desarrollo.
Esto ha llevado hacia un inters creciente en las metodologas
giles. Sin embargo, hay que tener presente una serie de
inconvenientes y restricciones para su aplicacin, tales como:
estn dirigidas a equipos pequeos o medianos (Beck sugiere que
el tamao de los equipos se limite de 3 a 20 como mximo, otros
dicen no ms de 10 participantes), el entorno fsico debe ser un
ambiente que permita la comunicacin y colaboracin entre todos
los miembros del equipo durante todo el tiempo, cualquier
resistencia del cliente o del equipo de desarrollo hacia las
prcticas y principios puede llevar al proceso al fracaso (el clima
de trabajo, la colaboracin y la relacin contractual son claves), el
uso de tecnologas que no tengan un ciclo rpido de
realimentacin o que no soporten fcilmente el cambio, etc.
06/02/2013
Ventas y Desventajas de
los Mtodos giles
4Conclusin
Falta an un cuerpo de conocimiento consensuado
respecto de los aspectos tericos y prcticos de la
utilizacin de metodologas giles, as como una mayor
consolidacin de los resultados de aplicacin. La
actividad de investigacin est orientada hacia lneas
tales como: mtricas y evaluacin del proceso,
herramientas especficas para apoyar prcticas giles,
aspectos humanos y de trabajo en equipo.
Entre estos esfuerzos destacan proyectos como
NAME11 (Network for Agile Methodologies Experience).
Aunque en la actualidad ya existen libros asociados a
cada una de las metodologas giles existentes y
tambin abundante informacin en Internet, es XP la
metodologa que resalta por contar con la mayor
cantidad de informacin disponible y es con diferencia la
ms popular.
06/02/2013
Conclusiones
sobre los
Mtodos giles
06/02/2013
Agilidad y Disciplina
4Se oponen estos dos conceptos? Ser
cierto que algo gil no puede ser
disciplinado y algo disciplinado no pueda
ser gil?

Agilidad: Rapidez y buena
coordinacin

Disciplina: Apego a
procedimientos establecidos.
Auto control
06/02/2013
06/02/2013
4No se oponen. Se complementan
Jerrquica
Gran
organizacin
Burocrtica
Nueva
organizacin
(Startup)
D
i
s
c
i
p
l
i
n
a

Agilidad
Baja Alta
Alta
Baja
06/02/2013
4La disciplina es la base de cualquier esfuerzo
exitoso. Los atletas entrenan, los msicos practican
, los ingenieros aplican procesos. Sin estos
fundamentos, puede darse el xito ocasional, pero la
consistencia profesional y el xito a largo plazo son
limitados.
4Donde la disciplina arraiga y fortalece, la agilidad
libera e inventa. Le permite a los atletas hacer la
jugada inesperada, a los msicos improvisar y a
los ingenieros a adaptarse a los cambios en
tecnologa ...
Versin: Barry Bohem and Richard Turner: Balancing Agility
and discipline.
06/02/2013
Mritos de la Agilidad
reconocidos por los crticos
4La comunicacin entre Programadores,
Clientes y Desarrolladores.
4El hincapi en la refactorizacin.
4El nfasis en las pruebas que debe
pasar el software.
4La importancia que se a los estndares
en la escritura del cdigo.

06/02/2013
Cundo aplicar las
metodologas giles?
4Procesos ms simples son ms fciles, cuando no se usa
ningn proceso.
4Las metodologas giles trabajan:
Equipos de menos de 50 personas.
Cuando no hay requerimientos estables.
Cuando los desarrolladores son buenos, responsables y
altamente motivados.
Clientes se involucran en el desarrollo.
4Las metodologas tradicionales trabajan en:
Equipos grandes de personas.
Alcance fijado por contrato.

06/02/2013
Fbula del cazador de
dragones
Se cuenta de un joven chino que
dedic toda su vida a aprender el arte de
cazar dragones, hasta que estuvo
seguro que ya dominaba todas las
tcnicas de cmo cazar dragones. En
ese momento se dio cuenta que no
haban en el mundo dragones que
pudieran ser cazados.
Y el joven se dedic a ensear cmo
cazar dragones
06/02/2013
Mensaje final sobre
paradigmas
Ninguna metodologa
har el trabajo por ti;
porque ninguna
metodologa trabaja
sola.
06/02/2013
Factores
del
software
06/02/2013
Factores crticos de xito
4 Los proyectos de software se retrasan, gastan ms de lo
presupuestado y son impredecibles.
4 Una revisin a las tcnicas de administracin de
proyectos nos harn ver que todava queda mucho
camino que recorrer.
4 Han transcurrido casi 50 aos de la industria del
software. Han pasado 4 generaciones de lenguajes, 3
paradigmas mayores de desarrollo de software, se ha
avanzado, pero existen aun muchos problemas
relacionados a este desarrollo.
4 La supremaca de la complejidad del software, segn
el criterio de muchos sigue siendo el problema bsico de
la computacin. Los desarrolladores de software tienen
que lidiar con problemas complejos y con requerimientos
de usuario cambiantes.

06/02/2013
Factores de xito para
proyectos de TI
En el mundo de las Tecnologas de la Informacin (TI)
una pregunta bsicas es: Cmo tener un proyecto
de xito?.
El xito de un proyecto de TI consiste en tener un
proyecto a tiempo, con un costo y expectativas de
ambas partes:
Con el cliente satisfecho por el alcance,
funcionalidad y servicio del producto.
Con el proveedor para obtener la remuneracin
econmica esperada, adems de ganar experiencia
con el proyecto.
06/02/2013
proyectos de TI
06/02/2013
proyectos de TI
Negociacin:
La etapa de negociacin es la parte medular de
un proyecto, puesto que se podr evaluar
rpidamente si el proyecto tiene las condiciones
s para ser exitoso, o est en riesgo para
obtener las las expectativas de ambas partes.
Esta etapa se subdivide en dos partes: la
negociacin interna con el cliente) y la
negociacin con el proveedor del producto.
06/02/2013
proyectos de TI
Negociacin interna:
Esta negociacin tiene que ver con todo lo involucrado en
el proyecto, y donde se define la duracin y el presupuesto
asignado al proyecto:
+Para la duracin, puede aceptarse lo planificado por el
proveedor o negociarlo con el usuario. El error ms
comn es sealar una fecha tope, sin importar cuando
se empiece, sin tener los requisitos mnimos para
empezar a la brevedad dicho proyecto.
+Para el presupuesto, este puede ser aprobado de la
manera tradicional, con propuestas alternativas y elegir
la que ofrezca el mejor costo /beneficio. Lo ms
frecuente, sin embargo es elegir la alternativa ms
econmica y esto atenta contra el producto a
obtenerse.
06/02/2013
proyectos de TI
Negociacin externa:
+Esta negociacin se da entre el intermediario con el
usuario final y el departamento de TI de la empresa o el
proveedor de TI.
+En esta etapa el proveedor analiza los requerimientos
del proyecto y hace una estimacin de costo y tiempo,
por diferentes factores. Pueden existir diferencias entre
los precios de varios proveedores y es aqu donde las
restricciones en tiempo y presupuesto para el proyecto
toman la mayor importancia.
+En un escenario sano, decidir por la mejor propuesta en
costo-beneficio-tiempo suele ser la ms acertada. Pero
lamentablemente, lo ms comn, es que se toma la
propuesto de menor costo y ofrece el tiempo ms corto
de desarrollo.
06/02/2013
proyectos de TI
RECOMENDACIN:

06/02/2013
proyectos de TI
Tecnologa:
Otra de las preguntas bsicas para el xito del proyecto es, Qu
tecnologa hay que usar?
La seleccin de la tecnologa a usar se basa en los siguientes factores:
a) Costo (definido en la negociacin interna): El costo cuando es una
restriccin importante hace que la tecnologa dependa de l. En
este caso puede optarse por una tecnologa de Cdigo Abierto o
una de renombre y tener en cuenta los otros factores.
b) Infraestructura o polticas de la empresa: La infraestructura o
polticas de la empresa definen que tecnologas deberan usarse,
muchas veces independientemente del tipo de proyecto.
c) Propuesta del proveedor seleccionado: El proveedor
seleccionado puede hacer una recomendacin de tecnologa que
va en funcin a su propuesta econmica, esto en determinados
momentos podr marcar una pauta importante en si no es una
tecnologa estndar podr generar dependencia por mucho
tiempo con dicho proveedor.
06/02/2013
proyectos de TI
RECOMENDACIN:
La seleccin de la tecnologa es el siguiente factor en
importancia, ya el desarrollo se har sobre cierta plataforma
tecnolgica, para lo cual se debe considerar lo siguiente:
Hay que seleccionar tecnologas que nos garanticen apoyo y
asesoramiento, adems de costos manejables y que no
signifiquen s generar una dependencia total con el proveedor
y resulten ms caras que una tecnologa estndar.
Por decir un ejemplo, en Mxico, encontrar apoyo para
aplicaciones .Net de Microsoft es mucho ms fcil y
econmico que encontrar el mismo apoyo para tecnologas
como JAVA. Esto no necesariamente significa que una
tecnologa sea mejor que otra,

06/02/2013
proyectos de TI
Metodologa:
Una vez decididas las variables de presupuesto,
tiempo y tecnologa, hay que decidir que metodologa
de trabajo se va a usar para cumplir con las
expectativas.
Entenderemos por metodologa el conjunto de reglas,
polticas, tcnicas y procedimientos en el desarrollo
de un proyecto. Existen muchas metodologas, como
se ha visto y podemos elegir entre las tradicionales,
giles o combinacin de ellas.
La negociacin de tiempo y presupuesto pueden
indicar la metodologa a seguir. Para elegir una
metodologa hay que tener una metodologa hay que
tener el presupuesto y tiempo adecuados.
06/02/2013
proyectos de TI
RECOMENDACIN
+En proyectos grandes y con presupuesto y tiempo
suficiente se puede elegir una metodologa tradicional
como DRA o PUDS. En proyectos donde el presupuesto
y tiempo son pequeos (o muy castigados en la
negociacin), se recomienda el uso de metodologas
giles como Scrum o RUP.
+Aunque la metodologa no tiene una dependencia
directa con la tecnologa seleccionada, es necesario
aclarar que ciertas tecnologas se adaptan mejor a
ciertas metodologas de desarrollo de software.
Tambin es necesario tener en cuenta las
caractersticas propias de cada software, por ejemplo a
un software matemtico le cae perfectamente la
metodologa de modelos formales.
06/02/2013
proyectos de TI
Recursos:
El ltimo factor del cual depende el xito de un proyecto
son los recursos que estarn involucrados, es decir, las
personas y sus respectivos perfiles de conocimientos y
experiencia en el tipo de proyecto, metodologa de
trabajo y tecnologa.
La asignacin de recursos a un proyecto se puede dar
de diferentes maneras, iniciamos por la dependencia
con cada factor previamente visto.
En la negociacin se define las 2 variables principales:
el tiempo y el costo. Esto determinar la cantidad de
recursos que se dispondr para el proyecto, y ms
importante an ser el perfil y experiencia que se pueda
costear con el presupuesto asignado. Para esto se debe
tener en cuenta:
06/02/2013
proyectos de TI

el nivel y la cantidad de
recursos asignados a un
proyecto ser directamente
proporcional al presupuesto
del proyecto,
independientemente del
tiempo que tengamos para
dicho proyecto
06/02/2013
proyectos de TI
RECOMENDACIN
+La seleccin de los recursos deber ser en funcin a los
factores de negociacin, tecnologa y metodologas, es
decir, los perfiles y experiencia de los recursos, debern
ser los adecuados a las variables del proyecto, si por
alguna razn los recursos no dominan la tecnologa.
+Un caso comn es que algunas empresas prefieren
tener una mayor cantidad de personal joven
practicantes que reduzcan costos y por cantidad de
recursos puedan tener el proyecto a tiempo.
Lamentablemente estos casos son difcilmente ejemplos
de xito; es posible que el proyecto se termine, pero la
calidad dejar mucho que desear y en muchos casos el
re-trabajo costar ms que hacerlo bien a la primera,
donde aplica el conocido refrn lo barato, sale caro.

06/02/2013
Factores que influencian
en el resultado
4 Tamao
4 Tiempo de entrega
4 Presupuestos y costos
4 Dominio de la aplicacin
4 Tecnologa a ser implantada
4 Restricciones del sistema
4 Requerimientos del usuario
4 Recursos disponibles
06/02/2013
Factores de xito en
Proyectos de Software segn
los gerentes del proyecto
06/02/2013
Factores que
influencian el resultado
Desempeo de Proyectos de TI
Standish Group - Reino Unido
Ao
Proyectos
abandonados
Proyectos
terminados con
problemas
Proyectos terminados
con xito
1995 53% 46% 51%
1999 31% 28% 15%
2003 16% 16% 34%
Total 100% 100% 100%
06/02/2013
Retos de la IS
4Mantener y tratar con sistemas legados.
4Tratar con una mayor diversidad de sistemas
con mayores demandas de computo y menores
tiempos de entrega.
Sistemas legados: Sistemas antiguos que deben ser
mantenidos y mejorados.
Heterogeneidad: Sistemas que incluyen una mezcla
de software y hardware.
Entrega: Existe una presin incremental por una
entrega a tiempo de los productos de software.
Formalidad: Existe una gran demanda de que haya
formalidad en el proceso de desarrollo de software.
06/02/2013
Retos de la IS
4Por qu no podemos desarrollar
sistemas de software con tcnicas
formales como lo hacen los
Ingenieros en Electrnica, los Ing.
Qumicos o los Ingenieros Civiles ?
06/02/2013
Soluciones
4Administracin de Proyectos de Software.
4Revisiones Tcnicas Formales.
4Aseguramiento de la Calidad del Software.
4Administracin de la Configuracin del Software.
4Preparacin y Produccin de Documentos.
4Administracin del Reuso.
4Mtricas.
4Administracin de Riesgos.
06/02/2013
Responsabilidad
profesional
4Los Ingenieros de software no solo deben considerar
aspectos tcnicos. Deben tener una visin mas amplia, en
lo tico, social y profesional.
4No existe estatutos para ninguno de estos aspectos.
Desarrollo de sistemas militares.
Piratera.
Que es mejor para la profesin de Ingeniero de
Software.
4Aspectos ticos:
Confidencialidad.
Competencia.
Derechos de propiedad intelectual.
Mal uso de la computadora.

06/02/2013
Gestin de
Proyectos
06/02/2013
Las 4 P de un proyecto de
software
4 Para una gestin eficaz de un
proyecto de software concurren
las 4 P:
Personal
Producto
Proceso
Proyecto

+ Herramientas
06/02/2013
Las 4 P de la gestin del
software
Proceso
Proyecto
Producto
Personal
Herramientas
Participantes
Plantilla
Resultado
Automatizacin
06/02/2013
El Personal
4El factor humano en un proyecto de software es
primordial. El Instituto de Ingeniera de Software
ha creado el Modelo de Madurez de la
Capacidad de Gestin del Personal (MMCGP)
que define las siguientes reas clave para el
personal que desarrolla software:
Reclutamiento.
Seleccin.
Gestin de rendimiento.
Entrenamiento.
Retribucin.
Desarrollo de la carrera.
Diseo de la organizacin y del trabajo.
Desarrollo cultural y de espritu de equipo.
06/02/2013
El Personal: Los participantes
4Gestores superiores: Definen los aspectos de
negocios que tienen una influencia significativa
en el proyecto.
4Gestores tcnicas del proyecto: Deben
planificar, motivar, organizar y controlar a los
profesionales que realizan el trabajo de
software.
4Profesionales: Proporcionan las capacidades
tcnicas necesarias para la ingeniera de un
producto o aplicacin.
4Clientes: Especifican los requisitos para la
ingeniera de software y otros elementos que
tienen menor influencia en el resultado.
4Usuarios finales: Interaccionan con el software
una vez que se ha entregado para la
produccin.
06/02/2013
El Personal: Los jefes de equipo
4Jerry Weinberg sugiere el modelo de gestin MOI:
Motivacin: Habilidad para motivar al personal
tcnico para que produzca con sus mejores
habilidades.
Organizacin: Habilidad para amoldar procesos
existentes o inventar nuevos que permita al
concepto inicial transformarse en un producto
final.
Ideas o innovacin: Habilidad para renovar al
personal para crear y sentirse creativos, incluso
cuando hay lmites establecidos para un producto
o aplicacin de software particular.
4El gestor de proyectos debe concentrarse en
entender el problema, gestionar el flujo de ideas y al
mismo tiempo convencer a los miembros del equipo
que la calidad es importante y debe estar presente.
06/02/2013
El Personal: Los jefes de equipo
06/02/2013
El Personal: Motivacin
06/02/2013
El Personal: El equipo de software
4Existen muchas estructuras de organizacin de
personal para el desarrollo del software. Las
siguientes opciones pueden aplicarse a un proyecto
con n personas durante k aos:
n individuos son asignados a m tareas funcionales.
Hay poco trabajo en conjunto. La coordinacin es
responsabilidad del gestor de software.
n individuos son asignados a m tareas funcionales
(m<n), de manera que se establecen equipos
informales. La coordinacin de los equipos es
responsabilidad del gestor de software.
n individuos se organizan en t equipos. A cada
equipo se le asigna una o ms tareas funcionales.
Cada equipo tiene una estructura especfica que se
define para todos los equipos. La coordinacin des
controlada por el equipo y por el gestor proyecto de
software.
06/02/2013
4Mantei sugiere tres organigramas de equipos
genricos:
Descentralizado democrtico (DD): Este
equipo de IS no tiene un jefe permanente. Se
nombra coordinadores de tarea a corto plazo y
se sustituyen por otro para diferentes tareas. Las
decisiones sobre problemas y enfoques se hacen
por consenso. La comunicacin entre los
miembros del equipo es horizontal.
Descentralizado controlado (DC): Este equipo
de IS tiene un jefe definido que coordina tareas
especficas, y jefes secundarios que tienen
responsabilidades sobre subtareas. La resolucin
de problemas es una actividad de grupo, pero la
implementacin de soluciones se reparte entre
subgrupos. La comunicacin entre subgrupos e
individuos es horizontal. Tambin hay
comunicacin vertical a lo largo de la jerarqua
de control.
06/02/2013
Centralizado Controlado (CC): El jefe del equipo se
encarga de la resolucin del problema a alto nivel y la
coordinacin interna del equipo.. La comunicacin entre
el jefe y los miembros del equipo es vertical.
4Mantei describe 7 factores a tener en cuenta para
el organigrama de los equipos del software:
La dificultad del problema que hay que resolver.
El tamao de los programas resultantes en lneas de
cdigo o puntos de funcin.
El tiempo que el equipo estar junto (tiempo de vida del
equipo).
El grado en que el problema puede ser modularizado.
La calidad requerida y fiabilidad del sistema que se va a
construir.
La rigidez de la fecha de entrega.
El grado de sociabilidad requerido par el proyecto.
06/02/2013
4Constantine sugiere 4 paradigmas de organizacin para
equipos de IS:
El paradigma cerrado: Un equipo con jerarqua tradicional
de autoridad. Trabajan bien cuando producen software similar
a otros anteriores, pero pueden ser menos innovadores.
El paradigma aleatorio: Un equipo libre que depende de la
iniciativa individual de los miembros del equipo. Cuando se
requiere innovacin son excelentes; pero pueden chocar
cuando se requiere un rendimiento ordenado.
El paradigma abierto: Un equipo con algunos controles
asociados al paradigma cerrado y mucho de la innovacin del
paradigma aleatorio. Son adecuados para la resolucin de
problemas complejos, pero el rendimiento pude no ser muy
eficiente.
El paradigma sincronizado: Se basa en la
compartimentacin natural de un problema y organiza a los
miembros del equipo para trabajar en partes del problema con
poca comunicacin activa entre ellos.

06/02/2013
06/02/2013
El Producto
4Antes de planificar el proyecto, hay que
definir los objetivos y el mbito del producto;
se debe considerar soluciones alternativas e
identificar las dificultades tcnicas y de
gestin.
4Los objetivos identifican las metas
generales del proyecto sin considerar el
cmo.
4El mbito identifica los datos primarios,
funciones y comportamientos que
caracterizan al producto. Intenta abordar
estas caractersticas de manera cualitativa.

06/02/2013
El Producto: El mbito
4El mbito se define respondiendo a:
Contexto: Cmo encaja el software a construir
en un sistema, producto o contexto de negocios
mayor y qu limitaciones se imponen como
resultado del contexto?
Objetivos de informacin: Qu objetos de
datos visibles al cliente se obtienen del
software?Que objetos de datos son requeridos
de entrada?
Funcin y rendimiento: Qu funcin realiza el
software para transformar la informacin de
entrada en salida?Hay caractersticas de
rendimientos especiales que abordar?

06/02/2013
El Producto: Descomposicin del
problema
4La descomposicin, llamada tambin
particionado o elaboracin del problema es
una actividad que se presenta en el ncleo del
anlisis de requisitos.
4La estrategia es conocida Divide et impera: Un
problema complejo se parte en problemas mas
pequeos que son ms manejables. Se aplica al
inicio de la planificacin del proyecto.
4La descomposicin se aplica en dos reas:
La funcionalidad qu debe entregarse.
El proceso que se emplea para entregarla.

06/02/2013
El Producto
Tipos de Software
Software de
computador
Software de
Sistemas
Software de
aplicacin
Administracin y
respaldo de
operaciones de
sistemas y redes
Procesamiento de
informacin para
usuarios finales
Programas de
aplicacin de
propsito general
Programas
especficos de
aplicaciones
- Exploradores Web
- Correo electrnico
- Procesamiento de palabras
- Hojas de clculo
- Administradores de BD
- Grficos de presentacin
- Paquetes integrados
- Groupware
Programas de
administracin de
sistemas
Programas de
desarrollo de
sistemas
- Procesamiento de transacciones:
-Contabilidad, ventas, compras,
inventarios, administracin de
personal, etc.
- Comercio electrnico
- Ciencia e ingeniera
- Educacin
- Entretenimiento
- Sistemas operativos
- Programas de redes
- SBBD
- Utilitarios
- Monitoreo de rendimiento
y seguridad
- Lenguajes de programacin
- Editores y herramientas de
programacin
- Paquetes CASE
06/02/2013
El Proceso
4Un proceso de ingeniera de software es una definicin
del conjunto completo de actividades necesarias para
transformar los requisitos de usuario en un producto.
4Hay un grupo bsico de actividades estructurales
aplicables a cualquier proyecto de software sin tener en
cuenta el tamao y la complejidad.
4Las tareas, hitos, productos del trabajo y puntos de
garanta de calidad permiten a las actividades
estructurales a las caractersticas del proyecto de
software y a los requisitos del equipo.
4Las actividades protectoras tales como la garanta de
calidad del software, gestin de la configuracin y la
medicin cubren el modelo de proceso.

06/02/2013
El Proceso
4El problema es seleccionar el modelo de
proceso apropiado para la ingeniera de
software. Hay variedad de paradigmas ya
sealados anteriormente.
4El gestor del proyecto debe decidir qu modelo
es el ms adecuado para
Los clientes que han solicitado el proyecto y
la gente que realizar el trabajo.
La caractersticas del producto en s.
El entorno del proyecto en el que trabaja el
equipo de software.

06/02/2013
El Proceso
4 Los principales factores que influyen en la diferencia de
procesos son:
Factores organizativos: La estructura organizativa, la
cultura de la empresa, la organizacin y gestin del proyecto,
las aptitudes y habilidades disponibles, experiencias previas
y sistemas software existentes.
Factores del dominio: El dominio de la aplicacin, procesos
de negocio que se deben soportar, la comunidad de usuarios
y las ofertas disponibles de la competencia.
Factores del ciclo de vida: El tiempo de salida al mercado,
el tiempo de vida esperado del software, la tecnologa y la
experiencia de las personas en el desarrollo del software, y
las versiones planificadas y futuras.
Factores tcnicos: Lenguaje de programacin,
herramientas de desarrollo, base de datos, marcos de trabajo
y arquitecturas estndar subyacentes, comunicaciones y
distribucin.

06/02/2013
El Proceso
06/02/2013
Maduracin del producto y
del proceso
4 Las actividades estructurales del proceso comunes son:
Comunicacin con el cliente: Obtencin de requisitos eficiente
entre el proveedor y el cliente.
Planificacin: Tareas requeridas para definir los recursos, la
planificacin temporal del proyecto y cualquier informacin sobre
l.
Anlisis del riesgo: Tareas requeridas para valorar los riesgos
tcnicos y de gestin.
Ingeniera: Tareas requeridas para construir uno o ms
representaciones de la aplicacin.
Construccin y entrega: Tareas requeridas para construir,
probar, instalar y proporcionar asistencia al usuario.
Evaluacin y entrega: Tareas requeridas para obtener
informacin de la opinin del cliente basadas en la evaluacin de
las representaciones de software creadas durante la fase de
ingeniera e implementadas durante la fase de instalacin.
06/02/2013
Maduracin del producto y
del proceso
06/02/2013
Descomposicin del proceso
4 La ECP (estructura comn del proceso) es invariable y sirve como
base para todo el trabajo de software realizado por una
organizacin.
4 La descomposicin del proceso comienza cuando el gestor del
proyecto pregunta Cmo vamos a realizar esta actividad
ECP?
4 Tareas para la actividad Comunicacin con el cliente para un
proyecto pequeo:
Desarrollar la lista de los aspectos que se han de clarificar.
Reunirse con el cliente para resolver los aspectos que se han
de clarificar.
Desarrollar conjuntamente una exposicin del mbito del
proyecto.
Revisar el alcance del proyecto con todos los implicados.
Modificar el alcance del proyecto cuando se requiera.
06/02/2013
El Proceso
4 Existen actualmente diversos modelos de desarrollo de
sistemas de software, que podemos dividir en 2 grandes
grupos:
Los mtodos ortodoxos o clsicos: Comienzan con el
anlisis completo de los requerimientos. Despus de
interaccin con clientes y usuarios se establecen
requerimientos funcionales y no funcionales. En el diseo
se define la arquitectura del sistema. Luego los
programadores implementan el diseo y finalmente el
sistema se prueba y se entrega. Todos estos modelos
tienen sus fortalezas y debilidades.
Los mtodos heterodoxos o giles: Son estrategias de
desarrollo de software que promueven prcticas que son
adaptativas en vez de predictivas, centradas en la gente o
en los equipos, iterativas, orientadas hacia prestaciones y
hacia la entrega, de comunicacin intensiva con el cliente,
y que requieren que el negocio se involucre en forma
directa.
06/02/2013
Descomposicin del proceso
4 Tareas para la actividad comunicacin con el cliente para un proyecto ms
complejo:
Revisar la peticin del cliente.
Planificar y programar una reunin formal con el cliente.
Realizar una investigacin para definir soluciones propuestas y enfoques
existentes.
Preparar un documento de trabajo y una agenda para la reunin formal.
Realizar la reunin.
Desarrollar conjuntamente mini - especificaciones que reflejen la
informacin, funcin y caractersticas de comportamiento del software.
Revisar todas las mini especificaciones para comprobar su correccin,
su consistencia, la ausencia de ambigedades.
Ensamblar las mini especificaciones en un documento de alcance al
proyecto.
Revisar este documento general con todo lo que pueda afectar.
Modificar el documento de alcance del proyecto cuando se requiera.

06/02/2013
El Proyecto
4Para dominar la complejidad del software se
requiere de proyectos de software planificados y
controlados.
4El porcentaje de proyectos de software que han
fracasado o desbordado al tiempo y al costo es
alto.
4Un proyecto de desarrollo da como resultado
una nueva versin del producto. El primer
proyecto dentro del ciclo de vida (proyecto
inicial o innovador ) da como resultado el
sistema o producto inicial.
06/02/2013
El Proyecto
4A travs del ciclo de vida, un equipo de proyecto
debe tener en cuenta:
Una secuencia de cambio: Cada ciclo lleva a
una versin, y ms all de una serie de ciclos, el
cambio continua por generaciones.
Una serie de iteraciones: Cada iteracin
implanta un conjunto de casos de uso
relacionado o atena los riesgos.
Un patrn organizativo: Debe proporcionarse
un patrn que indique los tipos de trabajadores
que el proyecto necesita y los artefactos sobre
los cuales hay que trabajar.
06/02/2013
El Proyecto: seales de
peligro
4 John Reel define 10 seales que un proyecto de
software est en peligro:
1. La gente del software no comprende las necesidades de los
clientes.
2. El mbito del producto est pobremente definido.
3. Los cambios estn mal realizados.
4. La tecnologa elegida cambia.
5. Las necesidades del negocio cambian o estn mal definidas.
6. La fechas de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierden los patrocinadores o nunca se obtuvieron
adecuadamente.
9. El equipo del proyecto carece del personal con las habilidades
apropiadas.
10. Los gestores y los desarrolladores evitan buenas prcticas y
sabias lecciones.
06/02/2013
El proyecto: Conjurar peligros
4Para conjurar estos peligros Reel plantea
5 factores para la administracin exitosa
de proyectos de software:
1.Empezar con el pie derecho.
2.Mantener el mpetu.
3.Controlar (o estar al tanto de) el
progreso.
4.Tomar decisiones inteligentes.
5.Institucionalizar los anlisis post-
morten.
06/02/2013
Empezar con el pie derecho: Obtener la
configuracin (set up) del proyecto es uno de los
factores ms importantes. No se puede alcanzar
xito sobre un proyecto mal planificado. Tom
Field dio 10 indicios o seales de falla de un
proyecto de ingeniera de software y son:
1. Los administradores del proyecto no entienden
las necesidades del usuario.
2. El mbito del proyecto no esta mal definido.
3. Los cambios del proyecto son pobremente
administrados.
4. Las tecnologas elegidas cambian.
5. Las necesidades del negocio cambian.

06/02/2013
Mantener el mpetu: Si se empieza bien, con objetivos
definidos y equipo adecuado. Ahora se debe mantener y
mejora este mpetu. Construir este impulso inicial es fcil,
pero reconstruirlo es harto difcil. Este impulso cambia
muchas veces en el proceso de desarrollo del software.
Estos cambios aumentan rpidamente y es crucial
reaccionar rpidamente para compensar cambios
negativos por positivos.
Hay 3 elementos clave para mantener o reconstruir el
mpetu:
Roce o friccin: Reducirlo al mnimo.
Calidad: Monitorearla desde el principio y establecer
expectativas de excelencia.
Administracin: Administrar el producto ms que la
gente.

06/02/2013
Controlar el progreso: Como se sabe el software es
intangible, pero sus manifestaciones fsicas son tangibles.
El desarrollo del software parte del modelo conceptual y
termina en una aplicacin; aqu no hay manifestacin
fsica de software que pueda ser tocada y medida, en
especial en la etapa de construccin,
Uno de los grandes problemas es la planificacin del
proyecto. Y preguntas como cunto se ha avanzado del
proyecto?cunto tiempo llevar terminar los mdulos P,
Q y R? cunto costar el mdulo X?cunto esfuerzo
costar el modulo X? no son fciles de responder; pero
hay que direccionarlas.
Existen metodologas, tcnicas y herramientas para esto,
hay que elegir algunas de ellas y tratar de seguirla.

06/02/2013
Tomar decisiones inteligentes: Tomar decisiones
inteligentes muchas veces separa los proyectos exitosos
de los fracasados. No debera ser difcil reconocer una
mala decisin.
Generalmente se toman malas decisiones en las
seleccin de tecnologas. Debera hacerse un anlisis
financiero y tcnico de la tecnologa. Si la tecnologa no
est vigente en el mercado es posible que se est
trabajando sobre un terreno pantanoso.
Es recomendable encapsular la interfaz de las nuevas
tecnologas, ya que estas son propensas al cambio y hay
que mantener la independencia con los lenguajes de
programacin.
Habr muchas oportunidades de tomar decisiones
importantes mientras se negocia los requerimientos del
software con los usuarios.
06/02/2013
Anlisis Post-mortem: Pocas empresas institucionalizan un proceso
para aprender de los errores. No se toma un tiempo para analizar lo
bueno, lo malo y lo feo de un proyecto y se est condenado a repetirlo.
Neal Whitten en su libro Administrando Proyectos de Desarrollo
ofrece 6 pasos para el anlisis post-mortem:
1. Declarar el propsito: Anunciar al comienzo del proyecto que se
har una revisin.
2. Seleccionar los participantes: Elegir gente representante de cada
grupo involucrado en el proyecto.
3. Preparar la revisin: Una vez completado el proyecto asignar la
gente para reunir datos. Incluye mtricas, asignacin de personal y
comunicacin.
4. Dirigir la revisin: La revisin no debe de requerir de muchos
das. Todos los participantes deben presentar sus conclusiones y
experiencias.
5. Presentar los resultados: Los participantes deben presentar sus
resultados al equipo de desarrollo y a la direccin ejecutiva.
6. Adoptar las recomendaciones: La empresa debe adoptar las
recomendaciones en los prximos proyectos.
06/02/2013
Herramientas
4El proceso est fuertemente influenciado por las
herramientas. Las herramientas automatizan los
procesos repetitivos, mantienen las cosas estructuradas,
gestionan grandes cantidades de informacin y guan a
lo largo del camino de un desarrollo concreto.
4Sin el soporte de herramientas ser difcil mantener
actualizados los modelos de implantacin. El proceso
iterativo e incremental ser ms difcil porque requerir
de una gran cantidad de trabajo manual para actualizar
los documentos y mantener la consistencia. Esto puede
bajar la productividad del equipo significativamente.
4La tecnologa CASE (Computer Aided Software
Engineering) reemplaza al papel y al lpiz por la
computadora para transformar la actividad de desarrollar
software en un proceso automatizado.
06/02/2013
Herramientas: Objetivos
4Permitir la aplicacin prctica de metodologas, lo que
resulta muy difcil sin emplear herramientas.
4Facilitar la realizacin de prototipos y el desarrollo
conjunto de aplicaciones.
4Simplificar el mantenimiento del software.
4Mejorar y estandarizar la documentacin.
4Aumentar la portabilidad de las aplicaciones.
4Facilitar la reutilizacin de componentes de software.
4Permitir un desarrollo y un refinamiento -visual- de las
aplicaciones, mediante la utilizacin de controles
grficos (piezas de cdigo reutilizables).

06/02/2013
Herramientas CASE: Tipos
4Herramientas de planificacin de sistemas de gestin:
Sirven para modelizar los requisitos de informacin.
Proporcionan un "metamodelo" del cual se pueden obtener
sistemas de informacin especficos. Su objetivo principal es
ayudar a comprender mejor cmo se mueve la informacin
entre las distintas unidades organizativas.
4Herramientas de Anlisis y Diseo: Permiten al
desarrollador crear un modelo del sistema que se va a
construir y tambin la evaluacin de la validez y
consistencia de este modelo. Proporcionan un grado de
confianza en la representacin del anlisis y ayudan a
eliminar errores con anticipacin. Entre ellas podemos
encontrar:
Herramientas de anlisis y diseo (Modelado).
Herramientas de creacin de prototipos y de simulacin.
Herramientas para el diseo y desarrollo de interfaces.

06/02/2013
4Herramientas de programacin: Se engloban aqu los
compiladores, los editores y los depuradores de los
lenguajes de programacin convencionales. Ejemplos de
estas herramientas son:
Herramientas de codificacin convencionales.
Herramientas de codificacin de cuarta generacin
(asociadas a SGBD)
Herramientas de programacin orientadas a objetos.
4Herramientas de integracin y prueba: Sirven de
ayuda a la adquisicin, medicin, simulacin y prueba de
los equipos lgicos desarrollados. Entre las ms
utilizadas estn:
Herramientas de anlisis esttico.
Herramientas de generacin de casos de prueba.

06/02/2013
4Herramientas de mantenimiento: La categora de
herramientas de mantenimiento se puede subdividir en:
Herramientas de Ingeniera Inversa.
Herramientas de reestructuracin y anlisis de
cdigo.
Herramientas de reingeniera.
4Herramientas de mantenimiento: La categora de
herramientas de mantenimiento se puede subdividir en:
Herramientas de Ingeniera Inversa.
Herramientas de reestructuracin y anlisis de
cdigo.
Herramientas de reingeniera.

06/02/2013
4Herramientas de gestin de proyectos: La mayora de
las herramientas CASE de gestin de proyectos, se
centran en un elemento especfico de la gestin del
proyecto. Utilizando un conjunto seleccionado de las
mismas se puede: realizar estimaciones de esfuerzo,
coste y duracin, hacer un seguimiento continuo del
proyecto, estimar la productividad y la calidad, etc. Se
incluyen dentro de las herramientas de control de
proyectos las siguientes:
Herramientas de planificacin de proyectos.
Herramientas de seguimiento de requisitos.
Herramientas de gestin y medida.
06/02/2013
Herramientas CASE:
Componentes
4 Herramientas de soporte: Se engloban en
esta categora las herramientas que recogen las
actividades aplicables en todo el proceso de
desarrollo, como las que se relacionan a
continuacin:
Herramientas de documentacin.
Herramientas para software de sistemas.
Herramientas de control de calidad.
Herramientas de bases de datos.
06/02/2013
Herramientas CASE:
Elementos
4Generalmente una herramienta CASE tiene los siguientes
elementos:
Repositorio (diccionario): donde se almacenan los
elementos definidos o creados por la herramienta y que se
basa en un SGBD o en un sistema de gestin de archivos.
Metamodelo (no siempre visible): que define las tcnicas
y metodologas soportadas por la herramienta.
Generador de informes: que permite obtener toda la
documentacin que describe el sistema de informacin
desarrollado, asociada a tcnicas y metodologas.
Herramientas de carga/descarga de datos: que permite
cargar el repositorio de datos provenientes de otros
sistemas y generar esquemas de bases de datos,
programas, etc.
06/02/2013
Herramientas CASE:
Elementos
4Interfaz de usuario: que consta de editores
de texto y herramientas de diseo grfico que
permiten mediante el uso de ventanas,
mens, componentes, etc., y con la ayuda del
ratn construir diagramas, esquemas,
matrices, etc.,.que incluyen las metodologas
4Comprobacin de errores: facilidades que
permiten llevar a cabo un anlisis la exactitud,
integridad y consistencia de los esquemas
generadas por por la herramienta.

06/02/2013
Herramientas CASE: Elementos
Repositorio
G
e
n
e
r
a
d
o
r

d
e

I
n
f
o
r
m
e
s

C
a
r
g
a
/
D
e
s
c
a
r
g
a

d
e

D
a
t
o
s

Interfaz de Usuario
Metamodelo
Asignacin_Recurso
Num_clase: char(4)
Cod_recurso: char(5)
Fecha: datetime
Hora: char(5)
Aula: char(5)
Estado_entrega: char(15)
Estado_devolucin: char(5)
Detalles: Text
Clase
Num_clase: char(4)
Cod_curso: char(3)
Cod_profesor: char(5)
Fecha: datetime
Hora: char(5)
Aula: char(5)
Duracin: numeric(5,2)
Curso
Cod_curso: char(3)
Denominacin: char(120)
Sumilla: text
Horas: int
Requerimientos: char(20)
Mantenimiento
ID_mantenimiento: int
Tipo: int
Descripcin: text
Fecha_ingreso: datetime
Fecha_salida: datetime
Responsable: char(60)
Costo: money
Factura: char(15)
Profesor
Cod_profesor: char(5)
Apellido: char(40)
Nombre: char(35)
Sexo: bit
Fecha_nac: datetime
DNI: char(8)
Telfono: char(6)
Direccin: char(50)
E_mail: char(35)
Asesor: char(5)
Grado: int
Condicin: char(10)
Recurso
Nom_recurso: char(80)
Descripcin: text
Marca: char(50)
Fecha_ingreso: datetime
Disponible: bit
Precio: money
Reparaciones: text
Estado_actual: int
Comprobacin
de errores
06/02/2013
Herramientas CASE: Ejemplos
BPWIN
ERWIN
PROJECT
RATIONAL
ROSE
06/02/2013
Administracin de proyectos
4Trata de las actividades que hay que
realizar para asegurar que el software:
Se entregar a tiempo.
Segn el plan.
De acuerdo con los requisitos de la
organizacin.
4Es necesaria porque el desarrollo del
software debe estar siempre sujeto a las
restricciones presupuestarias y
temporales que fije la organizacin.

06/02/2013
Administracin
de Proyectos
de Software

06/02/2013
Administracin de
proyectos

Si no haces un plan, tu plan
fracasar
Si no sabes donde vas, cualquier
camino es bueno
Si no sabes donde vas cmo hars
para saber cundo has llegado?
Es posible que hayamos llegado
aqu en naves diferentes, pero ahora
estamos todos en el mismo barco
06/02/2013
Administracin de proyectos
4Trata de las actividades que hay que
realizar para asegurar que el software:
Se entregar a tiempo.
Segn el plan.
De acuerdo con los requisitos de la
organizacin.
4Es necesaria porque el desarrollo del
software debe estar siempre sujeto a las
restricciones presupuestarias y
temporales que fije la organizacin.

06/02/2013
Qu es un proyecto?
4 Un proyecto es un trabajo que realiza una organizacin
con el objeto de conseguir una situacin deseada. Es un
conjunto de actividades orientadas a un fin comn que
tiene un inicio y un final.
4 Un proyecto es un esfuerzo temporal emprendido para
crear un producto o un servicio nico (PMI).
4 Un proyecto (cadenas crticas) es un conjunto de
actividades orientadas al logro de un objetivo especfico
y que tienen un punto de partida, medio y final claros
(Goldrat).
4 Un proyecto es una combinacin de recursos humanos
y no humanos reunidos en una organizacin temporal
para conseguir un propsito determinado (Cleland &
King)
06/02/2013
Caractersticas de un proyecto
4Un proyecto queda definido por las caractersticas
siguientes:
Complejas y numerosas actividades.
Singularidad: Conjunto de actividades nicas y no
repetitivas.
Finitud: Con una fecha inicial y una fecha final.
Limitaciones: Con recursos y presupuesto limitados.
Intervienen varias personas, por lo general de diversas
reas funcionales de una organizacin.
Secuencialidad y paralelismo: Sus actividades son
secuenciales o paralelas.
Est orientada a objetivos.
Competencia: Coexiste con otros proyectos y compite por
los recursos.
Debe dar como resultado un producto o servicio final.
06/02/2013
Qu es un proyecto de
sistemas?

4En toda organizacin existen, en todas las
reas, situaciones que necesitan del auxilio
sistemas de informacin para cumplir con la
misin asignada. Parte de 3 objetivos generales:
Resolver un Problema: Cuando las
actividades, procesos o funciones actuales o
en perspectivas no cumplen con los
estndares establecidos o con las
expectativas.
+Ejemplo: Facilitar la administracin de un
Cine Club.
06/02/2013
sistemas?

Aprovechar una Oportunidad: Cuando surge un
cambio para ampliar o mejorar el rendimiento
econmico de la empresa y su competitividad. Entre
estas posibilidades de mejorar se pueden mencionar:
La aceleracin de un proceso
La simplificacin de procesos mediante la
eliminacin de pasos innecesarios o duplicados.
La combinacin de procesos.
La reduccin de errores de captura por
modificaciones de los formatos y las pantallas de
acceso.
06/02/2013
sistemas?

La eliminacin de salidas redundantes.
Una memoria en la integracin de los
sistemas y los subsistemas.
La mejora en la aceptabilidad del sistema
por parte de los usuarios.
La mejor relacin del cliente /proveedor
/vendedor con el sistema.
+Ejemplo: Ofrecer a una videoteca un sistema
que muestre a los clientes ayuda audiovisual
para la seleccionar las pelculas que va a
alquilar o comprar.
06/02/2013
sistemas?

Dar respuestas a Directivos: Cuando
se debe:
Proporcionar informacin en respuesta a
rdenes, solicitudes o mandatos por parte
de una autoridad legislativa o
administrativa.
Llevar a cabo las tareas de una
determinada manera.
Cambiar la informacin o el desempeo.
+Ejemplo: Computarizar la contabilidad de
una empresa para presentar a la SUNAT.
06/02/2013
sistemas?

4 Para cumplir con estos objetivos las
organizaciones emprenden proyectos
por una o ms de las razones
siguientes:
Capacidad
Control
Comunicacin
Costos
Competitividad
06/02/2013
sistemas?

4Capacidad
Mayor velocidad de procesamiento: Uso ptimo
de la capacidad de la computadora para efectuar
la operaciones de clculo, ordenacin,
recuperacin de datos y efectuar repetidamente la
misma tarea con mucha mayor velocidad que las
personas.
Incremento en el volumen: Capacidad para
procesar una mayor cantidad de actividades para
aprovechar las oportunidades comerciales.
Recuperacin ms rpida de la informacin:
Localizacin y recuperacin de la informacin de
donde se encuentren almacenadas. Capacidad de
realizar bsquedas complejas.
06/02/2013
sistemas?

4Control
Mayor exactitud y mejor consistencia: Realizar las
operaciones con exactitud y siempre de la misma forma.
Garantizar la integridad y seguridad: Resguardando los
datos de su corrupcin o prdida y dando acceso slo a
personas autorizadas.
4Comunicacin
Mejoras en la comunicacin: Acelerar el flujo de la
informacin y mensajes dentro de las oficinas y entre
localidades remotas.
Integracin de las reas de la empresa: Coordinar las
actividades de una empresa que se realizan en diversas
reas a travs de la captura y distribucin de la informacin.
06/02/2013
sistemas?

4Costos:
Monitoreo de los costos: Seguimiento de los costos de mano de
obra, bienes e instalaciones para determinar su evolucin de
acuerdo a lo planeado.
Reduccin de costos: Uso de la capacidad de los medios
computacionales para procesar datos con un menor costo pero
garantizando un desempeo ptimo.
4Competitividad:
Atraer Clientes: Modificar los servicios prestados y la relacin con
los clientes de modo que permanezcan fieles a la empresa.
Dejar fuera a la competencia: Disminuir las posibilidades de la
competencia de acceder al mismo mercado, por la forma ptima en
que la empresa maneja sus sistemas de informacin.
Mejores acuerdos con los proveedores: Cambios de precios,
servicios, condiciones de entrega entre los proveedores y la
organizacin para lograr un mayor beneficio para la empresa.
Desarrollo de nuevos productos: Introducir nuevos productos con
caractersticas que utilizan o estn influenciadas por la tecnologa
de la informtica.
06/02/2013
sistemas?

4Fuentes de solicitud de proyectos
La solicitud de proyectos tiene las
siguientes fuentes primarias:
Jefes de departamentos
Altos ejecutivos
Analista de sistemas
Grupos externos
06/02/2013
sistemas?

4 Jefes de departamento: Buscan ayuda especfica para actividades
cotidianas que puede tener implicaciones que afecten a otros
departamentos y a la empresa en su conjunto.
4 Altos ejecutivos: Los altos ejecutivos tienen que tomar decisiones
y es usual que tengan informacin general de la organizacin y
tienen un mbito mucho mayor a los presentados por los jefes de
departamento; en consecuencia son ms difciles de manejar y
controlar. Los proyectos de los jefes de departamento tienen
mayores posibilidades de xito, sobre todo si los usuarios tienen
participacin activa.
4 Analistas de sistemas: Los analistas buscan reas crticas donde
existen deficiencias y presentan propuestas y cuentan con mtodos,
herramientas y equipo de la tecnologa informtica actualizada.
4 Grupos externos: Tambin los sistemas pueden ser solicitados por
grupos externos como el gobierno u organismos internacionales.
Por lo general demandas nuevos sistemas o modificacin de los ya
existentes.
06/02/2013
sistemas?

4 Solicitud del proyecto
La propuesta del proyecto por los usuarios a analistas ante el
comit de seleccin es un aspecto crtico para el desarrollo del
proyecto. Aunque los formatos varan segn las empresas, hay
puntos bsicos que todo proyecto de sistemas debe contener:
Cul es el problema?
Detalles del problema
Importancia del problema
Cul cree el usuario que es la solucin?
En que forma ser de ayuda un sistema de
informacin?
Que otras personas tienen conocimiento del
problema y puede ser consultados?
La propuesta debe ser clara y precisa, para que con una
investigacin preliminar se tenga los elementos para obtener
informacin suficiente.
06/02/2013
sistemas?

4Seleccin de estrategia
Una vez definido el problema, hay que elegir un
mtodo de desarrollo del proyecto, que puede
ser cualquiera de los paradigmas que hemos
mencionado.
Por lo general, como se ha dicho, se eligen
estrategias mixtas, dependiendo de la
naturaleza del sistema a construir, podemos
elegir mtodo ortodoxos o mtodos giles, con
apoyo de herramientas CASE
06/02/2013
Particularidades de un
proyecto de sistemas
4El producto: software, es intangible.
4No existen procesos de software
estndares.
4A menudo, los grandes proyectos de
software son nicos.

06/02/2013
Objetivos
4Definir la administracin de
proyectos de software y sus
caractersticas.
4Discutir la planeacin de proyectos y
el proceso de planeacin.
4Demostrar como la presentacin
grfica de la planificacin se utiliza en
la administracin de proyectos.
06/02/2013
Actividades
4Redaccin de la propuesta: Describe los
objetivos y cmo se llevan a cabo.
4Planificacin y calendarizacin del
proyecto: Tareas a realizar y plan de trabajo
4Estimacin del costo del proyecto.
4Supervisin y revisin del proyecto: Para
comparar los progresos y costos reales y
hacer ajustes.
4Seleccin y evaluacin del personal.
4Redaccin y presentacin del informe.
06/02/2013
Planificacin
4Es la actividad que ms tiempo consume en
la administracin del proyecto.
4Es un proceso iterativo que se completa slo
cuando el proyecto termina.
4El plan del proyecto debe ser revisado
regularmente a la vista de la evolucin del
mismo.
4Es imposible planificar sin estimar.
06/02/2013
Estimacin del costo del
software
4Se trata de predecir los recursos que se
requieren para un determinado proceso de
desarrollo de software.
4Las estimaciones se hacen para descubrir
cunto cuesta producir un sistema de
software
4Cunto esfuerzo se requiere para
completar una actividad?
4Cunto tempo de calendario se necesita
apara completar una actividad?
4Cual es el costo total de una actividad?
06/02/2013
Productividad del
programador
4Se intenta determinar una medida de
la cantidad de software y de
documentacin asociada que produce
un programador individual.
4Hay que tener en cuenta que existen
muchas soluciones software con
distintas caractersticas: ms eficiente,
ms mantenible,
4Hay varias propuestas de mtricas
para medir diversos aspectos del
software.
06/02/2013
Mtricas de la productividad
4Mtricas relacionadas con el tamao:
Basadas en el tamao de salida de una
actividad del proceso: nmero de lneas de
cdigo fuente, nmero de instrucciones de
cdigo fuente, nmero de pginas de
documentacin,
4Mtricas relacionadas con la funcin:
Basadas en una estima de la funcionalidad
del software entregado: puntos de funcin.
06/02/2013
Calidad y productividad
4Las mtricas basadas en volumen /
unidad de tiempo (lneas
/programador mes) son
imperfectas porque tienen en cuenta
factores como la fiabilidad, el
mantenimiento,
4La productividad se puede
aumentar generalmente a costa de la
calidad.

06/02/2013
Tcnicas de estimacin
4No hay una forma simple de hacer una estimacin
exacta del esfuerzo requerido para desarrollar un
sistema del software.
Las estimaciones iniciales se basan en
informacin poco precisa que aportan los
usuarios.
El software puede tener que ejecutarse en
computadoras no conocidas o utilizar tecnologa
nueva.
El personal del proyecto es nuevo.
4Las estimaciones de los costo del proyecto tienden
a autorealizarse.
La estimacin determina el presupuesto y el
producto se ajusta par cumplir el presupuesto.

06/02/2013
4Modelo algortmico de costos
Se analizan los costos de otros proyectos
realizados anteriormente: Tamao del proyecto,
nmero de programadores,...
Se utiliza una frmula matemtica para predecir
los costos del proyecto actual.
4Opinin de expertos
Se consulta a varios expertos en las tcnicas de
desarrollo que se van a utilizar y en el dominio
de aplicacin afectado. Entre ellos acuerdan una
estimacin.

06/02/2013
4Estimacin por analoga
Se estima por analoga con otros proyectos
completados sobre el mismo dominio de
aplicacin.
4Ley de Parkinson
El trabajo se extiende para llenar el tiempo
disponible.
El costo se determina segn los recursos
disponibles.
4Precio por ganar
Se acuerda la funcionalidad aceptable para el
sistema teniendo en cuenta el costo acordado.

06/02/2013
Mtodos de estimacin
4La estimacin se deber realizar
utilizando varias tcnicas.
4Si no se obtiene aproximadamente el
mismo resultado, es porque hay un poco
informacin.
4Se debe buscar ms informacin y
repetir el proceso hasta que las distintas
informaciones converjan.
4Precio para ganar es a veces la
nica tcnica aplicable.
06/02/2013
Estructura de un plan de
proyecto
4En el se fijan los recursos disponibles,
se divide el trabajo, y se crea un
calendario de trabajo. Debe incluir:
Introduccin: Objetivos del proyecto y
restricciones econmicas y temporales.
Organizacin del proyecto:
Organizacin del equipo, personas
involucradas y sus tareas.
Anlisis de riegos: Posibles riesgos con
su probabilidad y estrategias de reduccin
de riesgos propuestas.
06/02/2013
Estructura de un plan de
proyecto
4Requisitos de recursos de software y
hardware: Precios de lo que hay que
comprar y fechas de entrega.
4Divisin del trabajo: Divisin del trabajo
en actividades, marcar hitos, y productos a
entregar.
4Calendario del proyecto: Dependencias
entre actividades, tiempo estimado
requerido y asignacin de personal.
4Mecanismos de supervisin e informe:
Cuando y que tipo de informe debe
producirse.

06/02/2013
Organizacin de las
actividades
4Las actividades en un proyecto se deben
organizar de modo que produzcan salidas
tangibles que posibiliten juzgar el
progreso realizado.
4Los hitos son puntos finales de una
actividad, informes muy cortos con los
logros alcanzados.
4Los productos a entregar son resultados
del proyecto que se entrega a los clientes.

06/02/2013
Planificacin del proyecto
4Partir el proyecto en tareas y estimar el
tiempo y recursos necesarios para
terminar cada tarea.
4Organizar las tareas concurrentemente
para hacer un uso ptimo de la mano de
obra.
4Minimizar las dependencias entre tareas
para evitar retrasos producidos cuando
una tarea espera a otra para terminar.
4Depende de la intuicin y la experiencia
de los administradores del proyecto.

06/02/2013
Problemas de la planificacin
4Estimar la dificultad de los problemas, y,
por lo tanto el costo de desarrollar una
solucin es difcil.
4La productividad no es proporcional al
nmero de personas que trabajan en una
tarea.
4Aadir personal al final del proyecto
produce ms retraso por la sobrecarga en
la comunicacin.
4Lo inesperado siempre ocurre.

06/02/2013
Diagrama de barras y redes
de actividades
4Las notaciones graficas ilustran la
planificacin del proyecto.
4Muestran la descomposicin del
proyecto en tareas. Las tareas no deben
ser demasiado pequeas.
4Los diagramas de actividades muestran
las dependencia entre las tareas y el
camino crtico.
4Los diagramas de barras muestran la
planificacin sobre el calendario.

06/02/2013
Pasos para el control de
proyectos de software
4Partes:
Planeacin
Ejecucin
4Fases:
Definir
Planear
Organizar
Controlar
Concluir
4Pasos: 25, que se detallan en la tabla.
4Entregas: Documentos que se entregan al final de
cada fase y que se detallan en la tabla:
06/02/2013
Pasos para el control de
Planear Ejecutar
1 2 3 4 5
Definir Planear Organizar Controlar Concluir
Enunciar el problema Identificar las actividades
del proyecto
Determinar las
necesidades del personal
Definir el estilo de
direccin
Obtener aceptacin del
cliente
Identificar la meta del
proyecto
Estimar el tiempo y el costo Reclutar al gerente del
proyecto
Establecer las herramientas
de control
Realizar entregas
Listar los objetivos Establecer la secuencia de
las actividades del proyecto
Reclutar el equipo del
proyecto
Elaborar informes del
estado del proyecto
Documentar el proyecto
Determinar los recursos
preliminares
Identificar las actividades
crticas
Organizar el equipo del
proyecto
Revisar el programa del
proyecto
Emitir el informe final
Identificar las
suposiciones y riesgos
Escribir la propuesta del
proyecto
Asignar los paquetes de
trabajo
Emitir cambios de rdenes Realizar la revisin post
ejecucin
Entregas
-Panorama del
proyecto
-EDT
-Red del proyecto
-Camino(s) crtico(s)
-Propuesta del
proyecto
-Criterios de reclutamiento
-Descripcin de los paquetes de
trabajo
-Asignacin de los paquetes de
trabajo
-Informes de desviaciones
-Informes del estado del proyecto
-Informes de asignacin de
personal
-Informe final
-Informe de revisin
06/02/2013
Desarrollo del Panorama
4 El panorama es un documento preliminar que define un proyecto
que debe ser presentado por un grupo de personas involucradas en
el proyecto y firmado por el gerente. En nuestro caso: Un grupo de
4 alumnos, que van a desarrollar el proyecto de Ingeniera de
Software. Uno de ellos debe asumir el papel de Gerente.
Enunciado del problema: Una descripcin breve de lo que el
proyecto pretende realizar. Para esto debe responder a:
Cul es el problema/oportunidad?
La necesidad surge de un problema o situacin interno o externo
que amenaza a una empresa o presenta una oportunidad valiosa.
Puede tratarse de
Un nuevo producto o servicio.
Un proceso o sistema novedoso.
Desarrollo de nuevos mercados.
Se requiere reducir o ampliar el tamao e una divisin.
06/02/2013
Identificar la meta del proyecto: Todo
proyecto debe tener una sola meta y algunos
objetivos para alcanzar dicha meta.
Define el resultado en trminos de un
producto o servicio final. La expresin de la
meta debe indicar una accin y ser breve,
sencilla, directa y clara tanto como se pueda.
06/02/2013
Listar los objetivos: Para alcanzar la meta hay que dar
pasos importantes en el proyecto. Estos pasos son los
objetivos que vienen a ser hitos en el proyecto. George
Doran sugiere un acrnimo para el enunciado de las meta y
los objetivos: EMART
Especfico: Hay que ser especfico en el enunciado.
Medible: Hay que establecer indicadores medibles.
Asignable: Hay que asignar la meta u objetivo a alguien.
Realista: Hay que enunciar lo que realmente se puede
obtener dentro del tiempo y el presupuesto
establecidos.
Temporal: Hay que expresar cundo se va a alcanzar la
meta u objetivo. Es decir su duracin.
06/02/2013
Enunciar criterios de xito para evaluar el proyecto: Al
inicio del proyecto el equipo de desarrollo y las personas
involucradas pueden hacer un enunciado de los posibles
criterios de xito contra los cuales hay que medir los
resultados del proyecto. Estos criterios se revisan conforme
avanza el proyecto.
Determinar los recursos del proyecto: En los recursos
preliminares se incluyen los recursos humanos y materiales y
el financiamiento:
Personas: Cuntos, quines, cundo y por cunto
tiempo.
Equipo: Cul, cundo y por cunto tiempo.
Espacio: Dnde se va a trabajar.
Presupuesto: Clculo inicial del costo del proyecto.
Este clculo slo es aproximado.
06/02/2013
Identificar suposiciones y riesgos: Es necesario que el
producto o servicio tenga aceptacin y confianza y al mismo
tiempo ser realistas para identificar riesgos. La identificacin
de las suposiciones y riesgos hace ver que hay personas
comprometidas en el planeamiento y realizacin del proyecto.
Puede plantearse preguntas como:
- Qu problemas especiales se tiene que enfrentarse?
- Qu recursos extras se requieren para completar en
forma realista el objetivo?
- Qu problemas y retrasos pueden presentarse para el
logro de un objetivo?
- Qu efectos tendrn estos retrasos en el presupuesto,
en el programa y el plan global del proyecto?
- Cules son los probables gastos extras de tiempo,
dinero y personal que exigir la conclusin del proyecto?
- Qu medidas es posible para tomar para corregir en la
conclusin de un objetivo dentro del marco de las
limitaciones y recursos establecidos?
06/02/2013
Ejemplo de Panorama
PANORMA DEL
PROYECTO
Nombre del proyecto: Sistema de
administracin del Cine Club
ORSON WELLES
Gerente del proyecto:
Alumno: Jenny CABANA CASTRO
Problema/Oportunidad
No existe un control efectivo en la administracin del Cine
Club ORSON WELLES. Un Sistema de Informacin
Orientado a Objetos con GUI y arquitectura Cliente/Servidor
que administre el CCOW puede optimizar la solucin el
problema.
Meta:
Optimizar la administracin del Cine Club ORSON WELLES un periodo de
4 meses.
Objetivos:
1. Realizar entrevistas a los administradores y usuarios del Cine Club
ORSON WELLES y recabar toda la informacin pertinente en un
plazo de 6 das.
2. Definir el problema y los requerimientos en un plazo de 3 das.
06/02/2013
Ejemplo de Panorama
Objetivos:
3. Construir el modelo de Anlisis en un plazo de 10 das.
4. Construir el modelo de Diseo en un plazo de 12 das.
5. Construir el prototipo inicial en plazo de 6 das
6. Implantar la Base de datos un plazo de 8 das.
7. Construir la Interfaz de Usuario en un plazo de 10 das.
8. Implantar los Consultas, Reportes y el Sistema de Ayuda en un plazo de 16
das.
9. Implantar el Plan de Pruebas en un plazo de 10 das.
10. Documentar el proyecto en un plazo de 30 das.
11. Instalar el sistema en un plazo de 2 das.
Criterios de xito:
1. Hay varios cineclubs en las universidades e institutos culturales del
pas.
2. Hay proyectos informticos similares de administracin de institutos.
3. Existe el software, el hardware y el personal adecuados para construir el
sistema.
4. Existe gran disposicin de la Direccin de los institutos.
06/02/2013
Ejemplo de Panorama
Recursos preliminares:
Personal: Un analista, 2 entrevistadores, 1 diseador, 1 programador.
Equipo: Una red de al menos 2 computadoras: Servidor: Pentium IV 3 Ghz,
512 Mb. de RAM, DD de 80, Cliente: Pentium IV 1,8Ghz., 256 Mb.
de RAM, DD de 80 Gb., Fax Mdem . Una impresora HP 985.
Software: Word XP, Rational Rose 2003, Erwin4.1, C++ Builder 6,0,
SQLServer 2000.
Presupuesto inicial: S/ 3000.
Suposiciones y riesgos:
1. Hay inters cada vez ms creciente por desarrollar software para
problemas concretos en Tacna.
2. Es posible que haya cierta resistencia de parte de los administradores de
universidades e institutos culturales.
3. Es posible que el sistema de vuelva obsoleto si no se renueva y actualiza
constantemente de acuerdo al avance de la tecnologa informtica y con
proyeccin al futuro.
Presentado por los estudiantes:
Jenny Cabana Castro
Carmeluz Cohaila Gutirrez
Roxana Chauca Vildoso
Jess Muante Pea
Fecha: 05/03/07
Aprobado por:

Nombre, firma y sello.
Fecha: 10/03/07
Hoja 1 de 1
06/02/2013
Estructura de Desglose de Trabajo
para un proyecto de software (EDT)
4 Una vez que se ha presentado el panorama del proyecto, ha
sido revisado y aprobado, el siguiente paso es construir un
organigrama llamado Estructura de Desglose de Trabajo
(EDT).
4 La EDT muestra como identificar las actividades que van a
llevarse a cabo para desarrollar el proyecto. La tcnica de la
EDT permite reducir cualquier proyecto en actividades que
es posible planear y ejecutar.
4 Cada objetivo conducir a un nmero de actividades
distintas que hay que identificarlas por separado. Las
actividades definen el trabajo que debe llevarse a cabo para
lograr los objetivos. Deben ser formuladas y especificadas
de manera que sean medibles y que se pueda comprobar su
realizacin y responder a la pregunta:
Qu actividades debe llevarse a cabo para completar
el proyecto?
06/02/2013
4 Esta descomposicin jerrquica de las actividades contina hasta
que el proyecto se exhiba como una red de actividades identificadas
por separado y que no se traslapan.
4 Todas las actividades deben tener un propsito nico, una duracin
especfica, ser administrables y asignarse inequvocamente la
responsabilidad de su realizacin.
4 Una actividad bien definida tiene las siguientes caractersticas.
Su estado y conclusin se mide con facilidad.
Posee un evento inicial y uno final definido.
Es familiar (puede haberse realizado antes) y el tiempo para
concluirla, as como sus costos, pueden estimarse fcilmente a
partir de experiencias previas.
Comprende asignaciones de trabajo que son administrables,
medibles integrables e independientes de otras actividades.
Deber construirse normalmente una corriente de trabajo de
principio a fin.
06/02/2013
Pasos para construir una EDT:
Paso 1: Dividir el proyecto en sus objetivos principales de
manera que el proyecto quede claramente definido por
ellos.
Paso 2: Fragmentar cada objetivo en las actividades que
es necesario llevar a cabo para alcanzarlo.
Paso 3: En el caso de actividades que carezcan de una o
ms caractersticas dividirlas en las subactividades que las
compongan.
Paso 4: Repetir el Paso 3 hasta que todas las
subactividades posean las caractersticas deseadas.
Paso 5: Las subactividades de ms bajo nivel en jerarqua
constituir la base para los paquetes de trabajo que
debern realizarse para completar el proyecto.
06/02/2013
4 Ejemplo de una EDT:
Vamos a mostrar una Estructura de Desglose de Trabajo para un
proyecto de software de : Sistema de uso de recursos
audiovisuales en los institutos superiores.
El proyecto original es el siguiente:
PROYECTO ORIGINAL
administracin del Cine Club ORSON
WELLES
Gerente del Proyecto:
Alumno: Jenny CABANA
CASTRO
Actividad N Descripcin de la actividad
1 Realizar entrevistas a los dirigentes de los Cine Clubs y
recabar toda la informacin pertinente en un plazo de 6 das.
2 Definir el problema y los requerimientos en un plazo de 3 das.
06/02/2013
Actividad N Descripcin de la actividad
3 Construir el modelo de Anlisis en 10 das.
4 Construir el modelo de Diseo en 12 das.
5 Construir el Prototipo Inicial en 6 das.
6 Implantar la Base de datos en 8 das.
7 Construir la Interfaz de Usuario en 10 das.
8 Implantar los Consultas, Reportes y el Sistema de Ayuda en 16
das.
9 Implantar el Plan de Pruebas en 10 das.
10 Documentar el Sistema en 30 das.
11 Instalar el Sistema en 2 das.
Preparada por los estudiantes:
Jenny Cabana Castro.
Carmeluz Cohaila Gutirrez.
Roxana Chauca Vildoso.
Jess Muante Pea.
Fecha: 12/03/04
Aprobado por:

(Nombre, sello y firma)
Fecha: 12/03/07
Hoja: 1 de 1
06/02/2013
HOJA DE
TRABAJO
DE LA EDT
Nombre del proyecto:
Sistema de administracin del
Cine Club ORSON WELLES
Alumno: Jenny CABANA
CASTRO
Actividad N Descripcin de la actividad Caractersticas
1 2 3 4
1 Realizar entrevistas a los dirigentes de los
Cine Clubs y recabar toda la informacin
pertinente en un plazo de 6 das.
1.1
Redactar el Panorama del proyecto. S S S S
1.2
Realizar entrevistas. S S N N
1.3
Realizar la lectura de documentos S S S S
2

Definir el problema y los requerimientos en
un plazo de 3 das.
2.1 Formular el Plan general. S S N N
4Y la EDT sera:
06/02/2013
Actividad N Descripcin de la actividad Caractersticas
1 2 3 4
2.2 Definir de requerimientos. S S S S
2.3
Estimar el proyecto N S N N
3
Construir el modelo de Anlisis en 10 das.
3.1 Construir los Diagramas de Casos de Uso. S S S S
3.2 Especificar los CU y Actores. S S S S
3.3 Construir Diagramas de Actividades para los CU S N S N
4 Construir el modelo de Diseo en 12 das.
4.1 Construir los Diagramas de Interaccin S S S N
4.2 Identificar las clases y objetos S S S N
4.3 Construir el Diagrama de Clases. S N S N
4.4 Construir los Diagramas de Comportamiento. S N S N
4.5 Construir los Diagramas de Despliegue S N S N
06/02/2013
Actividad Nro. Descripcin de la actividad Caractersticas
1 2 3 4
5 Construir el Prototipo Inicial en 6 das.
5.1 Construir en Men Principal del sistema. S S S N
5.2 Describir los mdulos del sistema. S S S N
6 Implementar la Base de datos.
6.1 Crear del esquema de bases de datos a partir del
Diagrama de Clases.
S S S N
6.2 Construir el Diagrama del Modelo de Datos. S S S N
6.3 Generar la BD en SQL Server 2000. S S S N
7 Construir la Interfaz de Usuario en 10
das.
7.1 Implantar las clases base y los formularios. S S S N
7.2 Construir el mdulo de datos. S S S N
Hoja: 1 de 2
06/02/2013
1 2 3 4
8 Construir los Consultas, Reportes y el
Sistema de Ayuda en 16 das.
8.1 Construir las Consultas. S S S N
8.2 Construir los Informes para impresora.
S S S N
8.3 Construir el Sistema de Ayuda.
S S S N
9 Implantar el Plan de Pruebas en 10 das
9.1 Realizar las pruebas de unidad.
S S S N
9.2 Realizar las pruebas de integracin.
S S S N
9.3 Realizar la prueba del sistema S S S N
10 Documentar el Sistema en 30 das.
10.1 Redactar el Informe del Sistema.
S S S S
10.2 Redactar el Manual del Usuario. S S S S
06/02/2013
1 2 3 4
11 Instalar el sistema en 2 das.
11.1 Instalar el sistema. S S S S
11.2 Capacitar bsicamente al personal. S S S S
Jess Muante Pea.
Fecha: 27/05 /04
Clave para las caractersticas:
1. Estado /conclusin medibles.
2. Eventos inicial final claramente definida
3. Facilidad para estimar tiempos y costos
4. Asignaciones administrables, medibles,
integrables independientes.
Jess Muante Pea.
Fecha: 14/03/07
Aprobado por:

Fecha: 15/03/07
Hoja: 2 de 2
06/02/2013
Planificacin del proyecto de
software detallado (PSD)
4 Una vez construida la EDT, hay que detallar la
planificacin del proyecto, teniendo en cuenta:
Secuencia de las actividades del proyecto y el
camino crtico: Una vez hecho el listado de las
actividades y estimados los tiempos de las actividades
es necesario aplicar tcnicas para definir la secuencia
de las actividades y determinar la duracin del
proyecto. Para estos existen tcnicas como.
Los diagramas GANTT
El PERT (Program Evaluation and Review
Technique)
El CPM (Criticall Path Method)
06/02/2013
PROYECTO DETALLADO
administracin del Cine Club
ORSON WELLES
Alumno: Jenny CABANA CASTRO
Actividades (Tareas)
# Descripcin Duracin Predecesoras
1 Panorama del proyecto 2
2 Entrevistas 2 1
3 Lectura de documentos 2 1
4 Plan general 1 2, 3
5 Definicin de requerimientos 1 4
6 Estimacin del proyecto 1 5
7 Diagrama de Casos de Uso 4 6
8 Especificacin de CU y Actores 2 6
9 Diagrama de Actividades para CU 4 6
06/02/2013
10 Diagramas de Interaccin 2 7, 8, 9
11 Identificacin de Clases y Objetos 2 10
12 Diagrama de Clases 4 11
13 Diagramas de Comportamiento 2 12
14 Diagramas de Despliegue 2 13
15 Men Principal 2 14
16 Descripcin de mdulos 4 14
17 Esquema de Base de Datos 2 15, 16
18 Diagrama del Modelo de Datos 4 17
19 Generacin de BD 2 18
20 Clases base y formularios 4 19
21 Mdulo de datos 6 19
22 Consultas 4 20,21
06/02/2013
23 Informes para impresora 4 22
24 Sistema de Ayuda 8 23
25 Pruebas de unidad 3 24
26 Pruebas de integracin 3 25
27 Pruebas de sistema 4 26
28 Informe del Sistema 20 3
29 Manual del usuario 10 27,28
30 Instalacin 1 29
31 Capacitacin 1 30
Jess Muante Pea.
Fecha: 16/03/07
Aprobado por:

Fecha: 18/03/07
Hoja: 1 de 1

06/02/2013
EL Diagrama GANTT
El diagrama GANTT es una descripcin de las
actividades de un proyecto. Consiste en una
representacin grfica de las actividades que
componen un proyecto. La lnea vertical
representa las actividades del proyecto y la lnea
horizontal representa el tiempo. Las actividades
estn representadas por barras cuya longitud
indica la duracin de la actividad en la unidad de
tiempo utilizada.
En la lnea horizontal se coloca una escala del
tiempo con fechas par visualizar el avance del
proyecto. La calendarizacin puede ser en das,
semanas, meses, etc.
06/02/2013
La red PERT
La red PERT es un grafo donde los nodos representan
las tareas del proyecto y las flechas indican la secuencia
de las tareas y los caminos. En la red PERT se visualiza
los caminos posibles y el (los) camino (s) Crtico (s).
Un camino es una sucesin de nodos a lo largo de la
red entre el nodo inicial y modo final. Una red tiene por lo
general varios caminos. La notacin para los caminos es
C
i
= [1, 2, 3,, N]
donde 1, 2,, N representan las tareas. Para una red
pueden existir muchos caminos.
Def. 1. Se llama Tiempo de camino (TC) a la suma de
los tiempos de las actividades que forman dicho camino.
Def. 2. Se llama Camino crtico (CC) al mayor de los
tiempos de camino. En una red puede haber ms de un
camino crtico.
06/02/2013
Planificacin del PSD: Construccin
del Diagrama GANTT

Reglas para construir el diagrama GANTT:
1. En el extremo izquierdo se coloca el nmero y
descripcin de cada actividad (tarea).
2. En la parte superior del lado derecho se coloca una fila
que representa el transcurso del tiempo calendarizado.
3. Las actividades van representadas con rectngulos al
costado izquierdo de la columna donde estn los
nmeros y descripcin de las actividades y debajo de la
fila del tiempo.
4. Las actividades se representa con el siguiente convenio:
Las actividades se representan con rectngulos
sombreados.
El estado de avance de las actividades se representa
con un sombreado oscuro.
06/02/2013
del diagrama GANTT
Actividades
# Descripcin Duracin
1 Panorama del proyecto 2
2 Entrevistas 2
3 Lectura de documentos 4
4 Plan general 1
5 Definicin de requerimientos 1
6 Estimacin del proyecto 1
7 Diagramas de CU 4
8 Especificac. de CU y Actores 2
9 Diagramas de Act. para CU 4
10 Diagrama de Interaccin 2
Marzo 2007
1 2 3 4 5 6 7 8 9 10 11 12 13
06/02/2013
del diagrama GANTT
Actividades
16 Descripcin de mdulos 4
17 Esquema de BD 2
18 Diagr. del Mdulo de Datos 2
19 Generacin de la BD 2
Actividades
11 Identific. de Clases y Objetos 2
12 Diagrama de Clases 4
13 Diagramas de Componentes 2
14 Diagrama. de Despliegue 2
15 Men Principal 2
Marzo 2007
14 15 16 17 18 19 20 21 22 23 24 25 26
Marzo 2007 Abril 2007
24 25 26 27 28 29 30 31 1 2 3 4 5
06/02/2013
del diagrama GANTT
Actividades
23 Informes para impresora 4
24 Sistema de Ayuda 8
Actividades
20 Clases base y formularios 4
21 Mdulo de datos 6
22 Consultas 4
Abril 2007
6 7 8 9 10 11 12 13 14 15 16 17 18
Abril 2007
19 20 21 22 23 24 25 26 27 28 29 30
06/02/2013
del diagrama GANTT
Mayo 2007
07 08 09 10 11 12 13 14 15 16 17 18 19
Mayo 2007
01 02 03 04 05 06 07 08 09 10 11 12 13
Actividades
25 Pruebas de unidad 3
26 Pruebas de integracin 3
27 Pruebas de Sistema 4
Actividades
28 Informe del Sistema 20
06/02/2013
del diagrama GANTT
Mayo 2007
07 08 09 10 11 12 13 14 15 16 17 18 19
Actividades
29 Manual del Usuario 10
30 Instalacin 1
31 Capacitacin 1
Leyenda:
Actividad no ejecutada:
Actividad concluida:
Avance de la actividad:
06/02/2013
Planificacin del PSD:
Construccin de la Red PERT
Reglas para construir la red PERT:
1. Comenzar la red con un modo que tiene el nmero 1
(Inicio) y terminar con un otro nodo N (Final).
2. La secuencia de los nodos va de izquierda a derecha.
Las actividades predecesoras deben estar a la
izquierda de las actividades sucesoras.
3. No debe haber ciclos ni flujos hacia atrs.
4. Todos los nodos, a excepcin del inicial y final, tiene
un nodo predecesor y otro sucesor.
5. No puede haber nodos aislados; todos deben estar
conectados.
6. Se hallan todos los posibles caminos y se calculan los
tiempos de camino y luego el camino o los caminos
crticos.
06/02/2013
Construccin de la red
4 De acuerdo a la informacin dada tenemos que
la red es la siguiente. Las tareas estn
numeradas en rojo y las duraciones estn dadas
en azul :
2: 2
5: 1
4: 1
3: 2
6: 1
7: 4
10: 2
9: 4
8: 2 1: 2
06/02/2013
4 Esta es la red PERT. Con la informacin dada
procederemos a hallar el camino crtico:
11: 2 13: 2 12: 4 11: 2 14: 2
15: 2
16: 4
06/02/2013
18: 4 17: 2
19: 2
20: 4
21: 6
22: 4 23: 4
06/02/2013
29: 10
25: 3 24: 8
28: 20
27: 4 26: 3
30: 1
31: 1
06/02/2013
Caminos
4 La red dada tiene 25 posibles caminos:
C
1
= [1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
2
= [1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
3
= [1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
4
= [1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
5
= [1, 2, 4, 5, 6, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
6
= [1, 2, 4, 5, 6, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
7
= [1, 2, 4, 5, 6, 8, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
8
= [1, 2, 4, 5, 6, 8, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
9
= [1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
10
= [1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
11
= [1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
12
= [1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
13
= [1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
14
= [1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
15
= [1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
16
= [1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
17
= [1, 3, 4, 5, 6, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
18
= [1, 3, 4, 5, 6, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
19
= [1, 3, 4, 5, 6, 8, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
20
= [1, 3, 4, 5, 6, 8, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]

06/02/2013
Planificacin del PSD: Tiempo
de Caminos
C
21
= [1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
22
= [1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
23
= [1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
24
= [1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
25
= [1, 3, 28, 29, 30, 31]

06/02/2013
Caminos
4 Los tiempos de camino respectivos son:
T(C
1
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
2
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
3
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 77
T(C
4
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79
T(C
5
) = 2+2+1+1+1+2+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 73
T(C
6
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
7
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
8
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
9
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
10
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
11
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 77
T(C
12
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79
T(C
13
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
14
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
15
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 77
T(C
16
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79
T(C
17
) = 2+2+1+1+1+2+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 73
T(C
18
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
19
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
20
) = 2+2+1+1+1+2+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77

06/02/2013
Caminos
4 Los tiempos de camino respectivos son:
T(C
21
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 75
T(C
22
) = 2+2+1+1+1+4+2+2+4+2+2+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 77
T(C
23
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+4+4+4+8+3+3+4+10+1+1 = 77
T(C
24
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79
T(C
25
) = 2+2++20+10+1+1 = 36

06/02/2013
Camino Crtico
4 Tenemos que:
Max(T(Ci)) = 79
que corresponde a los caminos C
4
, C
12
, C
16
y C
24

4 En consecuencia C
4
, C
12
, C
16
y C
24
son caminos
crticos:
T(C
4
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79*
T(C
12
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79*
T(C
16
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79*
T(C
24
) = 2+2+1+1+1+4+2+2+4+2+4+2+2+4+2+6+4+4+8+3+3+4+10+1+1 = 79*

Y estos caminos son:
C
4
= [1, 2, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
12
= [1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
16
= [1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
C
24
= [1, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 22, 23, 24, 25, 26, 27, 29, 30, 31]
y deben ser sealados en la red.

06/02/2013
4 Las tareas (actividades) crticas estn sealadas
con borde rojo y tambin los caninos crticos:
2: 2
5: 1
4: 1
3: 2
6: 1
7: 4
10: 2
9: 4
8: 2 1: 2
06/02/2013
13: 2 12: 4 11: 2 14: 2
15: 2
16: 4
06/02/2013
18: 4 17: 2
19: 2
20: 4
21: 6
22: 4 23: 4
06/02/2013
29: 10
25: 3 24: 8
28: 20
27: 4 26: 3
30: 1
31: 1
06/02/2013
Uso de MS Project para
4 El MS - Project es una excelente herramienta
que nos permite planificar cualquier tipo de
proyectos, y en particular proyectos informticos.
Con el MS Project podemos:
Planificar el proyecto por tareas (actividades).
Obtener los diagramas GANTT y PERT
Calendarizar el proyecto.
Asignar recursos.
Estimar el costo del proyecto.

06/02/2013
Software para administrar
proyectos
4 MS Project: Es el ms conocido software para gestionar
proyectos, Permite asistir a administradores de proyectos en el
desarrollo de planes, asignacin de recursos a tareas, dar
seguimiento al progreso, administrar presupuesto y analizar cargas
de trabajo. La primera versin fue lanzada en 1984.
4 Primavera Project Planner: Es una herramienta robusta para
planificar, administrar y ejecutar proyectos, programas y portafolios.
4 HPM (Harvard Project Manager): Lanzado en 1983. Fue el
primero en generar diagramas de Gantt y PERT y varios tipos de
diagramas y tablas.
4 Project Scheduler: Permite administrar proyectos como planes
independientes o para formar un proyecto maestro que contiene
muchos proyectos con dependencia entre ellos.
06/02/2013
Software para administrar
proyectos
4 Texim Project: Proporciona una nueva manera de organizar y
desarrollar los planes de proyecto. Permite combinar direccin de
tareas, recursos y costos.
4 Time Line: Es una utilidad escrita en JavaScript que permite crear
un grfico de tiempo en la que se puede agregar /mostrar eventos
ocurridos en determinado momento.
4 Milestone Planner: Es una sencilla herramienta online que
permite la planificacin y seguimiento de la evolucin de hasta tres
proyectos simultneamente.
4 Phpaga: Es un sistema Web para administrar proyectos, tareas y
facturacin Open Source desarrollado en PHP.
4 GanttPV: Es una aplicacin Open Source para gestionar
proyectos, controlar tareas, prever fechas, etc.
06/02/2013
4 MS-PROJECT es que simultneamente, nos permite
manejar:
La hoja de datos que contiene:
Un nmero que identifica a la tarea, para todos sus efectos.
Indicador (). dan diferentes tipos de informacin sobre cada
tarea.
Nombre de la tarea (actividad).
Duracin (por defecto es en das).
Fechas de comienzo y fin de la actividad.
Actividades predecesoras.
Nombre de recursos.
Recursos.
06/02/2013
El diagrama de GANTT con las tareas y sus vnculos y
los recursos si se desea. Puede sealarse el avance de
las tareas en % con ayuda del ratn.
Recursos que se asigna a cada recurso.
El diagrama PERT con la red del proyecto y el (los)
camino (s) crtico (s).
Diagrama de Red que permite manipular las tareas.
El calendario del proyecto.
Grfico de recursos.
Hoja de recursos.
Tablas de resumen.
Presentaciones.
Informes del proyecto.
06/02/2013
Hoja de datos
06/02/2013
Diagrama GANTT
06/02/2013
Diagrama PERT
06/02/2013
Diagrama PERT
06/02/2013
Diagrama PERT
06/02/2013
Asignacin de recursos al
proyecto
4 Los recursos se asignan a cada tarea del proyecto. Los recursos
pueden ser personas o equipos. Es evidente que las mismas
personas y equipos pueden ser asignadas a varias tareas.
4 Procedimiento:
Elegir en el men Herramientas la opcin Asignacin de
recursos (o [Alt] +[F10] o el botn respectivo en la barra de
herramientas). Debe aparecer un cuadro de dilogo semejante a:
06/02/2013
proyecto

4 Entonces daremos el nombre del recurso (por ejemplo
Analista) y el nmero de unidades (por ejemplo 1) y
los asignaremos a c/u de las tareas con el botn
Asignar . Si queremos quitar un recurso se una tarea le
quitaremos con el botn Quitar. Con el botn Grficos
se puede visualizar un grfico de barras con eje en el
calendario.

06/02/2013
proyecto
Nota: MS-Project asigna los recursos en porcentajes por omisin, pero
vamos a cambiarlo a unidades:
Antes de esto, primero vamos a definir la moneda a usar: Ir al men
Herramientas/Opciones, poner en la ficha Vista del cuadro Moneda la
siguiente informacin:
Smbolo: $
Aceptar por omisin, Posicin y Decimales.

Pasar a la ficha Programacin y en
Mostrar las unidades de asignacin
como: elegir Valores decimales. Confirmar
todo con el botn Aceptar.
06/02/2013
proyecto
Tarea Nombre de los recursos
1 Analista[1];Encuestador[2]; Computadora[1]; Libros[2]
2 Analista[1]; Secretaria[1]; Computadora[1]
3 Analista[1]; Programador[2]; Computadora[1]
4 Diseador[2]; Computadora[1]; Mesa [1]
5 Analista[2]; Computadora[1]
6 Analista[2]; Contador[1]; Computadora[1]
Asignamos
los
siguientes
recursos
06/02/2013
proyecto
15 Programador[1]; Analista[2]; Computadora[3]
Asignamos
los
siguientes
recursos
06/02/2013
proyecto
30 Probador de sistemas[1]; Programador[1]; Computadora[2]
32 Analista[1]; Programador[1]; Secretaria[1]Computadora[3]
36 Programador[1];Computadora[2]
Asignamos
los
siguientes
recursos
06/02/2013
proyecto

Asignando
estos recursos
obtenemos otra
vista del GANTT
06/02/2013
Detalle de los recursos al
proyecto

4 Para detallar informacin sobre los recursos. Para esto ir al
cuadro de dilogo de Asignacin de recursos y hacer doble
clic veces sobre el nombre del recurso. Por ejemplo: Analista.
Debe aparecer un cuadro de dilogo semejante a la figura:
06/02/2013
proyecto: General

4 Podemos llenar los datos de la ficha General
para cada recurso, por ejemplo para Analista,
segn la siguiente informacin:
Datos Valor Explicacin
Nombre (por omisin) Nombre del recurso.
Iniciales ANA Buscar las iniciales adecuadas.
Grupo Personal Grupo al que pertenece el recurso.
Cdigo PA001 Es el cdigo del recurso.
Correo electrnico itel@hotmail.com E-mail.
Grupo de trabajo (por omisin) Comunicacin entre los miembros del proyecto.
Disponibilidad de recurso Durante todo el proyecto Por omisin
Desde... Hasta Hay que indicar fechas
Unidades mximas disponibles 3 Mxima capacidad del recurso
06/02/2013
proyecto: General

4 Debemos obtener algo semejante a la figura:
06/02/2013
proyecto: Horario de trabajo

4 Para la Horario de trabajo, se llena a criterio personal y
sentido comn para cada recurso haciendo que los sbados
sean laborables y que quede semejante a la figura.
06/02/2013
proyecto: Costos

4 Podemos llenar los datos de la ficha Costos
para cada recurso, por ejemplo para Analista,
segn la siguiente informacin:
Datos Valor Explicacin
Nombre (por omisin) Nombre del recurso.
Tasa estndar $3, 00/h Suponemos que el analista cobra 3 dlares por hora.
Tasa de horas extra $2, 00/h Suponemos que el analista cobra 2 dlares por hora extra.
Costo por uso Para recursos materiales como computadora.
Fecha efectiva Fecha efectiva para pagar el recurso.
B, C, D y E
Tasas alternativas a la predeterminada.
Acumulacin de costos Prorrateo Por omisin.
Hay 3 opciones:
Comienzo: Acumula los costos al iniciarse la tarea que usa el recurso.
Fin: Acumula los costos al terminar la tarea que usa el recurso.
Prorrateo: Acumula los costos conforme avanza la tarea que usa el
recurso.
06/02/2013
proyecto: Costos

4 Debemos obtener algo semejante a la figura:
06/02/2013
proyecto: Notas

4 Pasar a la ficha Notas, y llenar un texto a criterio
personal donde se describa los datos personales del
analista y lo que hace en el proyecto. Se puede insertar
grficos como su foto. Ver figura
06/02/2013
Costo del proyecto
4 MS-Project maneja un tipo de costo que es el costo fijo, que es un
costo establecido para una tarea que permanece constante,
independiente de la duracin y de los costos de los recursos
humanos y materiales. Para esto hay que ir al men Ver y elegir la
opcin Tabla: Entrada y cambiarla a Tabla: Costo haciendo uso de
las opciones del men contextual. Vamos a suponer que los costo
fijos para nuestro proyecto son:
Tarea Costo
1 4
2 5
3 5
4 4
5 5
6 10
7 10
8 15
9 13
10 20
11 15
Tarea Costo
12 20
13 10
14 20
15 20
16 25
17 15
18 30
19 15
20 5
21 8
Tarea Costo
22 4
23 5
24 5
25 4
26 5
27 10
28 10
29 15
30 13
31 20
06/02/2013
Costo del proyecto
4 La Tabla: Costo es semejante a:
06/02/2013
Costo del proyecto
4 El campo Acumulacin de costos fijos ofrece opciones
para cmo y cundo se deben cargar los costos fijos o
acumulados , al costo de la tarea. Las opciones son:
Comienzo: Los costos se cargan el primer da.
Prorrateo: Los costos se reparten equitativamente los
das que dura la tarea.
Fin: Los costos se cargan el ltimo da.
4 Ejemplo: Para la tarea Panorama del proyecto existe
un costo fijo de $ 4. La tarea tendr lugar el martes,
mircoles, jueves, viernes y sbado. Si hacemos clic en
Comienzo en el campo Acumulacin de costos fijos,
los $ 4 se cargarn el martes para esa tarea. Si hace
clic en Fin, los $ 4 se cargarn el sbado. Si hace clic en
Prorrateo, se cargarn $ 0,8 el martes, mircoles, jueves,
viernes y sbado.
06/02/2013
Costo del proyecto
4 El campo Costo total muestra el costo total programado de
una tarea, a partir de los costos contrados por el trabajo
realizado por todos los recurso asignados a la tarea, as como
de los costos planeados para el trabajo restante de la
asignacin.
4 Ejemplo: Para la tarea Panorama del proyecto considerando 8
horas de trabajo (estndar), tenemos que hay:
Un analista que cobra $3 por hora: 3*8 = 24
2 encuestadores que cobran $ 2 por hora: 2*2*8 = 32
Uso de una PC a $ 0,5 la hora: 0,5*8 = 4
Total por da 60
Como la tarea dura 5 dias: 60*5: 300
Mas costo fijo: 4
Costo total: 304

06/02/2013
Costo del proyecto
4 El campo Costo previsto muestra el costo total
planeado de una tarea.
4 El costo previsto se calcula como la suma de los costos
planeados de todos los recursos asignados ms
cualquier Costo fijo asociado con la tarea. El valor de
este campo es igual al del campo Costo total cuando
se guarda la lnea base (Es nuestro caso).
Costo previsto = (Trabajo * Tasa estndar) + (Trabajo
de horas extra * Tasa de horas extra) + Costo por uso
del recurso + Costo fijo de la tarea
Nota: Para guardar la lnea base ir a
Herramientas/Seguimiento, hacer clic en Guardar
lnea de base y, a continuacin, hacer clic en Guardar
lnea de base. Los costos totales actuales de las tareas
se copiarn en el campo Costo previsto.

06/02/2013
Costo del proyecto
4 El campo Variacin de costo muestra la diferencia
entre el Costo previsto y el Costo total de una
tarea. El Costo total es la estimacin actual de
costos realizada a partir de los costos reales y los
costos restantes.
4 La Variacin de costo se calcula como sigue:
Variacin de costo = Costo total Costo previsto
4 El campo Costo real muestra los costos contrados
por el trabajo realizado por todos los recursos en
una tarea, junto con cualquier otro costo registrado
que est asociado a la tarea. Puede especificar
todos los costos reales o dejar que Microsoft Project
los calcule.
06/02/2013
Costo del proyecto
4 El campo Costo restante muestra el gasto
programado restante de una tarea que se
producir cuando todos los recursos asignados a
la tarea completen el trabajo programado
restante.
4 Cuando se crea una tarea por primera vez, el
contenido del campo Costo restante es igual al
del campo Costo total. Una vez que los
recursos asignados comienzan a trabajar en la
tarea y notifican trabajo real, Microsoft Project
calcula el costo restante como sigue:
Costo restante = (Trabajo restante * Tasa
estndar) + Costo de horas extra restante
06/02/2013
Manejo de riesgos
4El manejo de riesgos consiste en la identificacin de
riesgos y la escritura de planes para minimizar el efecto
de estos en el proyecto.
4Un riesgo se relaciona con la probabilidad de que
ocurra alguna circunstancia adversa al proyecto.
Los riesgos de un proyecto afectan a la planificacin
o a los recursos.
Los riesgos del producto afectan a la calidad o al
desempeo del software por desarrollarse.
Los riesgos del negocio son aquellos que afectan a
la organizacin que desarrolla el software.

06/02/2013
Riesgos del software
Riesgo Tipo de riesgo Descripcin
Produccin del personal Proyecto El personal experimentado dejar el proyecto
antes de que est acabado.
Cambio de gestin Proyecto Habr un cambio de direccin organizacional,
con las prioridades diferentes.
Indisponibilidad del hardware Proyecto Hardware que es esencial para el proyecto no
se entregar en el horario.
Cambio de requisitos Proyecto y producto Habr un gran nmero de cambios a los
requisitos que se anticip.
Retraso en las especificaciones Proyecto y producto

Las especificaciones de las interfaces
esenciales no estn disponibles en el plan .
Tamao subestimado Proyecto y producto El tamao del sistema se ha subestimado.
Bajo desempeo de las
herramientas CASE
Producto Las herramientas CASE que apoyan el
proyecto no rinden como se anticipado.
Cambio de tecnologa Negocios La tecnologa subyacente con la que se
construye el sistema se reemplaza por la
nueva tecnologa.
Competicin del producto Negocios U producto competitivo se comercializa antes
que el del sistema se complete.
06/02/2013
El proceso de manejo de
riesgos
4Identificacin de riesgos:
Identifica riesgos en el proyecto, en el producto y
en el negocio.
4Anlisis de Riesgos:
Calculo de la posibilidad de que ocurran estos
riesgos y de sus consecuencias.
4Planeacin de Riesgos:
Trazar planes para evitar o minimizar el efecto de
los riesgos.
4Monitorizacin de Riesgos:
Monitorizar los riesgos durante el proyecto.
06/02/2013
Proceso de manejo de
riesgos
Identificacin
del riesgo
Anlisis del
riesgo
Planeacin del
riesgo
Monitoreo del
riesgo
Identificacin
del riesgo
Anlisis del
riesgo
Planeacin del
riesgo
Monitoreo del
riesgo
06/02/2013
Identificacin de riesgos
Riesgos en la tecnologa
Riesgos en la gente
Riesgos organizacionales
Riesgos en los requerimientos
Riesgos de estimacin

06/02/2013
Tipos de riesgos
Tipo de riesgo Posibles riesgos
Tecnologa
La base de datos usada en en el sistema no puede procesar s tantas
transacciones por segundo como de espera.
Las componentes del software que deben reusarse contienen defectos que
limitan su funcionalidad.
Gente Es imposible reclutar al personal con las habilidades requeridas.
El personal importante est enfermo e indisponible en los tiempos crticos.
El entrenamiento requerido para el personal no est disponible.
Organizacional La organizacin se reestructura para que la diferente direccin sea
responsable del proyecto.
Los problemas financieros organizacionales obligan a las reducciones en el
presupuesto del proyecto.
Herramientas El cdigo generado por las herramientas CASE es ineficaz.
Las herramientas CASE no pueden integrarse.
Requerimientos

Los cambios a requisitos que requieren el repaso del plan mayor propuesto
propone.
Los clientes no entienden el impacto de los cambios de requisitos.
Estimacin Se subvalora el tiempo exigido desarrollar el software.
Se subvalora la tasa de reparacin.
Se subvalora el tamao del software.
06/02/2013
Anlisis de riesgos
4Determina la probabilidad y la
seriedad de cada riesgo.
4Las probabilidades pueden variar
entre muy alta, alta, moderada, baja
o muy baja.
4Los efectos de los riesgos pueden
ser: catastrficos, serios, tolerables o
insignificantes.
06/02/2013
Anlisis de riesgos
Riesgo Probabilidad Efecto
Los problemas financieros organizacionales
obligan a las reducciones en el presupuesto del
proyecto.
Bajo Catastrfico
Es imposible reclutar al personal con las
habilidades requeridas para el proyecto.
Alto Catastrfico

El personal importante est enfermo en los
tiempos crticos del proyecto.
Moderado Serio
Los componentes del software que deben
reusarse contienen defectos que limitan su
funcionalidad.
Moderado Serio
Se proponen cambios a requisitos que requieren
el repaso del plan mayor.
Moderado Serio
La organizacin se reestructura para que la
direccin diferente sea responsable del proyecto.
Alto Serio
06/02/2013
Anlisis de riesgos
Riesgo Probabilidad Efecto
La base de datos usada en el sistema no puede
procesar tantas transacciones por segundo como
se espera.
Moderado Serio
El tiempo exigido para desarrollar el software se
subvalora.
Alto Serio
No pueden integrarse las herramientas CASE.. Alto Serio
Los clientes no entienden el impacto de cambios
de requisitos.
Moderado Tolerable
El entrenamiento requerido para el personal no
est disponible.
Moderado Tolerable
La tasa de reparacin del defecto se subvalora. Moderado Tolerable
El tamao del software se subvalora. Alto Tolerable
El cdigo generado por las herramientas CASE
es ineficaz.
Moderado Insignificante
06/02/2013
Planeacin de riesgos
4Determina la probabilidad y la
seriedad de cada riesgo.
4Las probabilidades pueden variar
entre muy alta, alta, moderada, baja
o muy baja.
4Los efectos de los riesgos pueden
ser: catastrficos, serios, tolerables o
insignificantes.
06/02/2013
Anlisis de riesgos
4Considera cada riesgos y desarrolla una estrategia
para manejarlo.
Estrategias de evasin:
La probabilidad de que el riesgo se presente se
minimizara.
Estrategias de minimizacin:
El impacto del riesgo en el producto o en el proyecto
se reducir.
Planes de contingencia:
Si el riesgo se presenta, el plan de contingencia se
encargara de tratar este riesgo
06/02/2013
Estrategias de manejo de
riesgos
Riesgo Estrategia
Problemas financieros
organizacionales
Preparar un documento de la sesin de informacin para la alta direccin
que muestre cmo el proyecto est haciendo una contribucin muy
importante a las metas del negocio.
Los problemas de
contratacin
El cliente alerta de dificultades potenciales y la posibilidad de retrasos,
investigar compra-de los componentes.
La enfermedad del
Personal
Reorganizar el equipo para que haya ms comparticin de trabajo y las
personas por consiguiente entiendan el trabajo de los otros.
Los componentes
defectuosos
Reemplazar los componentes potencialmente defectuosos comprando
componentes de fiabilidad conocida.
Los requisitos cambian Derivar la informacin de la traceabilidad para evaluar el impacto de los
cambios en los requisitos, aumentando al mximo la informacin que
esconde en el plan.
La reestructuracin de la
Organizacin
Preparar un documento de la sesin de informacin para la alta direccin
que muestre cmo el proyecto est haciendo una contribucin muy
importante a las metas del negocio.
La actuacin de la base de
datos
Investigar la posibilidad de comprar una base de datos del alto
desempeo.
El tiempo de desarrollo
subvalorado
Investigar la compra en los componentes, investigar el uso de un
generador del programa.
06/02/2013
Estrategias de manejo de
riesgos
Tipo de riesgo Indicadores potenciales
La tecnologa
Tarda la entrega de hardware o software de apoyo, muchos
informaron los problemas de tecnologa.
Las personas Pobre moral personal, las pobres relaciones entre miembros
del equipo, la disponibilidad del trabajo.
Organizacional Los chismes organizacionales, falta de accin de la alta
direccin.
Las herramientas La renuencia de los miembros del equipo para usar las
herramientas, las quejas sobre las herramientas CASE, las
demandas para las estaciones de trabajo de alta potencia.
Los requisitos Muchas demandas de cambio de requisitos, las quejas del
cliente.
Estimacin Fracaso para reunirse en el horario convenido, fracaso para
aclarar los defectos informados.
06/02/2013
Monitorizacin de riesgos
4Determina regularmente cada riesgo
identificado y decide si es probable o no
que se presente.
4 Determina si los efectos de que
producira el riesgo, han cambiado.
4 Cada riesgo clave debe discutirse en
las reuniones de avance del proyecto.
06/02/2013
Resumen
4 La Ingeniera de Sistemas es difcil. Nunca habr una
respuesta fcil en la solucin de problemas de desarrollo
de sistemas complejos.
4 Los Ingenieros de Software no tienen respuesta a todas
las preguntas, pero entienden el funcionamiento del
sistema.
4Se debe de reconocer el papel que juega cada disciplina
y cooperar entre todas en el proceso de Ingeniera de
Sistemas.
4 La Ingeniera de Sistema involucra a mltiples
disciplinas.
4 El Proceso de I.S sigue a menudo el modelo de
cascada.
06/02/2013
Mtricas del
software
06/02/2013
El Problema de la Estimacin

Un gestor de proyectos es
una persona con la habildad
de saber qu es lo que va ir
mal antes de que ocurray
con el coraje para hacer
estimaciones cuando el
futuro no est claro
06/02/2013
4 La estimacin del software es difcil, porque el
desarrollo del software es evolutivo. Se comienza
con una imagen borrosa de lo que se desea
construir, que luego se intenta ir aclarando a travs
del proceso.
4 La estimacin del tiempo y del esfuerzo necesarios
para construir el software es tambin borrosa,
debido a la imagen borrosa del software.
Una estimacin es la
prediccin ms optimista
con una probabilidad
distinta de 0 de que sea
cierta.
06/02/2013
4 La estimacin de recursos, costos y
planificacin temporal de un desarrollo de
software requiere de experiencia, buena
informacin histrica y el coraje de confiar en
datos cuantitativos cuando todo lo que existe
son datos cualitativos.
La complejidad del proyecto incertidumbre.
El tamao del proyecto falta de precisin y
eficiencia en las estimaciones.
El grado de incertidumbre estructural
riesgo en la estimacin.
06/02/2013
El PE : Complejidad
4Para la complejidad del software, Brooks se
basa en las tres categoras de programacin:
Programas de aplicacin: Procesamiento de
datos (transacciones, aplicaciones de ingeniera,
aplicaciones cientficas).
Programas de apoyo: Compiladores,
enlazadores y sistemas de inventarios complejos.
Programas de sistema: Sistemas operativos,
sistemas de tiempo real, sistemas de bases de datos.
4Los programas de apoyo son 3 veces ms
difciles que los de aplicacin, y los de sistema,
son a su vez, 3 veces ms difciles que los
programas de apoyo.
06/02/2013
El PE : Categoras por
Tamao
Categora Nmero de
programadores
Duracin Tamao del
producto
Trivial 1 1-4 Sem. 0,5 KLDC
Pequeo 1 1-6 Mes. 1-2 KLDC
Mediano 2-5 1-2 Aos 1-50 KLDC
Grande 5-20 2-3 Aos 50-100 KLDC
Muy grande 100-1000 4-5 Aos 1 MLDC
Extremadamente
grande
2000-3000 5-10 Aos 1-10 MLDC
06/02/2013
Proceso de Estimacin
4El proceso de estimacin de desarrollo de un proyecto
de software tiene 4 pasos:
Estimacin del tamao del producto: Se mide en
nmero de Lneas de Cdigo (LDC) o Puntos de
Funcin (PF).
Estimacin el esfuerzo (personas-mes): Si se tiene
una estimacin exacta del tamao y los datos previos
de proyectos similares, es fcil realizar esta
estimacin.
Estimacin del tiempo de desarrollo del proyecto:
Una vez estimados el tamao y el esfuerzo, estimar
el tiempo es casi trivial.
Estimacin del costo del proyecto: Teniendo los
datos anteriores y otros costos adicionales es posible
estimar el costo del proyecto
06/02/2013
Cuando puedas medir lo que ests diciendo y
expresarlo en nmeros, sabrs algo acerca de ello;
pero cuando no puedas medirlo, cuando no puedas
expresarlo en nmeros, tus conocimientos sern
escasos y deficientes: puede ser el comienzo del
conocimiento, pero en tus pensamientos apenas ests
avanzando hacia el escenario de la ciencia
Lord Kelvin
Lo que no sea medible, hazlo medible
Galileo Galilei
No se puede controlar lo que no se puede medir
Tom De Marco
No se puede predecir lo que no puede medir
Norman Fenton
La necesidad de medir
06/02/2013
Las 4 razones para medir los
procesos de software, los
productos y recursos
4 Caracterizar
4 Evaluar
4 Predecir
4 Mejorar

La medicin es
fundamental
para cualquier
disciplina, el
software no es la
excepcin
06/02/2013
La medicin permite:
4Proporciona requerimientos verificables en trminos
medibles.
4Proporciona evidencia cuantificable para apoyar las
decisiones.
4Hace ms visible el desarrollo y permite identificar
problemas anticipadamente.
4Permite hace predicciones de costo y tiempo.
4Recomienda estrategias de prueba e identifica los
mdulos problemticas.
4Permite valorar los efectos en la productividad y en
la calidad.

06/02/2013
Medidas, mtricas e
indicadores
4 Medida: En Ingeniera de Software, una medida
proporciona una indicacin cuantitativa de la extensin,
cantidad, dimensin, capacidad o tamao de algunos
atributos de un proceso o producto.
4Medicin: Es el proceso en el que se asignan nmeros
o smbolos a atributos del software.
4Mtrica: Medida individual sobre algn aspecto del
software. Medida cuantitativa del grado en un sistema,
componente o proceso posee un atributo dado.
4 Indicador: Es una mtrica o combinacin de mtricas
que proporciona una visin profunda del proceso, proyecto
o del producto.
06/02/2013
Medidas, mtricas e
indicadores
4Los indicadores del proceso permiten:
Al gestor, evaluar lo que funciona y lo que no.
A la organizacin tener una visin profunda de un proceso ya
existente.
4Los indicadores del proyecto permiten al gestor:
Evaluar el estado del proyecto en curso.
Seguir la pista de los riesgos potenciales.
Detectar reas de problemas antes de que se vuelvan crticas.
Ajustar el flujo y las tareas del trabajo.
Evaluar la habilidad del equipo del proyecto en controlar la calidad
de los productos
Los indicadores del producto permiten avaluar su calidad.
06/02/2013
Medidas, mtricas e
indicadores
06/02/2013
El PE : Incertidumbre
Estructural
4Grado en que los requisitos se
han definido.
4Facilidad de subdivisin de las
funciones.
4Naturaleza jerrquica de la
informacin a procesarse.
06/02/2013
Alternativas
4 Dejar la estimacin para el final.
4 Usar la descomposicin para obtener
estimaciones del costo, el esfuerzo y el
tiempo.
4 Desarrollar un modelo emprico para
estimar el costo, el esfuerzo y el tiempo.
4 Usar herramientas automticas de
estimacin.
06/02/2013
Para qu medir el software?
4 Para indicar la calidad del producto.
4 Para evaluar la productividad de las personas.
4 Para evaluar los beneficios derivados del uso
de nuevos mtodos y herramientas.
4 Para establecer una lnea de base en la
estimacin.
4 Para justificar el uso de nuevas herramientas y
la necesidad de formacin.
06/02/2013
Mtodo de Medicin
Identificar los atributos de las
entidades del domino
Identificar las relaciones
empricas para los atributos
Identificar las relaciones
numricas correspondientes
a cada relacin emprica
Definir la correspondencia
entre entidades y los
nmeros
Verificar que la
semntica de las
relaciones empricas
se preservan en las
relaciones numricas
06/02/2013
Mtodo de Medicin
4Seleccin de escala de medicin:
Cmo sabemos cuando una representacin
numrica es mejor que otra?
4Problema de representacin:
Cmo sabemos si un sistema de relacin
emprica tiene una representacin numrica?
4Problema de unicidad:
Qu hacemos cuando contamos con varias
representaciones diferentes en el mismo
sistema numrico?

06/02/2013
Asistencia de las Mtricas
en el Software
4Entender y modelar procesos de
ingeniera de software y productos.
4 Asistencia en la administracin de
proyectos de software.
4 Guiar mejoras en procesos de
ingeniera de software.
06/02/2013
Entender y modelar
4Poder comparar lneas de base con evoluciones
posteriores permite determinar la relacin entre
los atributos de un producto y una posible mejora.
4Debemos poder predecir el efecto de introducir
un cambio en un parmetro.
4Cunto esfuerzo consume el desarrollo de
software?
4 En qu fases del proceso de software
consumimos ms recursos?
4 Qu tipos de error y cambios son tpicos en
nuestros proyectos?
06/02/2013
Administrar proyectos
4Poder usar datos histricos para
hacer estimaciones.
4Poder aprender la relacin existente
entre parmetros.
4Poder dar seguimiento.
4Poder validar las mismas mtricas.
06/02/2013
Administrar proyectos
4Resumen
Estimar costo, horario y
propiedades del personal.
Dar seguimiento basado en
estimaciones.
Validar el modelo de estimacin y
mejorar futuras mediciones.
06/02/2013
Alcance de mtricas del
software
4Modelos de estimacin del costo y el
esfuerzo.
4Modelos de productividad.
4Modelos de recoleccin de datos.
4Modelos de mtricas de calidad.
4Modelos de confiabilidad.
4Modelos de evaluacin de performance.
4Modelos de estructura y calidad.
4Evaluacin de mtodos y herramientas.
06/02/2013
Alcance de modelos de
productividad
4Un modelo de productividad en funcin del
valor y costo.
Productividad
Valor
Costo
Calidad Cantidad Calidad Cantidad Cantidad
Confiabilidad
Defectos
Tamao
Funcionalidad
Tiempo
Dinero
Hardware
Software
Restricciones
ambientales
Dificultad de
problema
06/02/2013
Alcance de la Recoleccin
de Datos
4Debe formar parte integral de todos los
procesosincluso del Producto.
4Cada artefacto que es medido posee
una forma particular de informarnos.
Debemos ser capaces de capturar esta
informacin.
06/02/2013
Alcance: Modelos
mtricos de calidad
La velocidad con la cual se
construy un producto no tiene
sentido en si mismo si no est
relacionada con un modelo de
calidad.
06/02/2013
Alcance de modelos de calidad
Fiabilidad
Operacin
de Producto
Usabilidad
Mantenabilidad
Reusabilidad
Eficiencia de dispositivos
Accesibilidad
Comunicabilidad
Consistencia
Exactitud
Independencia de dispositivos
Completitud
Concisin
Estructuralidad
Legibilidad
Revisin de
Producto
Eficiencia
Probabilidad
Portabilidad
Independencia de dispositivos
Autodescriptividad

M
E
T
R
I
C
A
S

Localizabilidad
06/02/2013
QIP (Paradigma de
mejoramiento de calidad)
QIP
(Quality Improvement
Paradigm)
GQM
(Goal Quality Metric)
EF
(Experience Factory)
Paso de la
formulacin de la
meta
Competencias en la
construccin del
software y obtencin
del proyecto
06/02/2013
QIP (Paradigma de
mejoramiento de calidad)
Planeamiento
Anlisis y
Empaque
Ejecucin
Paso de
formulacin
de la meta
Anlisis
Postmorte
m
Paso de
construccin y
generacin de
datos
06/02/2013
GQM (Mtrica de la meta de
calidad)
4 Todo proceso de ingeniera requiere de
retroalimentacin y evaluacin.
4 La construccin de software es una
actividad de ingeniera y como tal debe
poseer disciplinas de medicin.
La medicin debe poseer un foco basado en
modelos y objetivos.
Debemos entonces establecer objetivos
medibles y dirigidos por el modelo apropiado.
06/02/2013
GQM: Metas
4 Existen una variedad de perspectivas que
pueden definir un objetivo: El cliente, la
corporacin, e incluso el proyecto.
4Ejemplos:
Objetivo del cliente: Satisfaccin del usuario.
Objetivo del Proyecto: Entrega en trmino.
Objetivo de la Corporacin: Continua mejora del
proceso de desarrollo.

06/02/2013
GQM: Atributos
Atributo
Interno
Externo
Posibilidad de
analizarlos en
forma aislada
Dependen del
entornoSe requiere
integrar antes de poder
analizarlos
06/02/2013
GQM: Prediccin
4Los atributos externos son indirectos y se
deducen en funcin de los atributos
internos.
4En el proceso de prediccin de atributos
externos, se debe poder calcular y/o
obtener los atributos internos esperados
para acertar en la prediccin.
06/02/2013
GQM: Objetos
Proceso
Producto
Recurso
Atributos internos reducidos:
Tiempo de duracin de una actividad
Productividad de un recurso:
Calidad de gerenciamiento de un lder
Atributos externos:
Estabilidad
Atributos internos:
Los productos son concretos =
Fcilmente medibles
Atributos externos:
Mantenibilidad
06/02/2013
GQM: Paradigma
Definir objetivos
corporativos y de
proyecto
Proveer de un marco de
trabajo para interpretar los
datos y entender el enfoque
sobre los objetivos
Rastrear qu datos
hablan de este
objetivo
06/02/2013
GQM: Paradigma
4Los objetivos son definidos en forma
operacional y refinados a travs de una
serie de preguntas cuantificables.
4 Estas preguntas son utilizadas par
obtener la informacin necesaria se los
modelos.
4 Las mtricas son asignadas a las
respuestas y la recoleccin de datos que
responden a esas preguntas nos otorgan el
universo de interpretacin.
06/02/2013
GQM: Proceso
4El flujo de los objetivos hacia las mtricas en
GQM puede ser visto como un grafo dirigido.
Objetivo 1
Pregunta 1
Pregunta 2
Pregunta 3
M 1
M 2 M 3
D
e
f
i
n
i
c
i
n

I
n
t
e
r
p
r
e
t
a
c
i
n

06/02/2013
GQM: Proceso
4Ejemplo: Efectividad de usar estndares para la
codificacin.
Meta: Evaluar efectividad de
codificacin estndar
Quin est
usando el
estndar?
Cul es la
calidad del
cdigo?
Cul es la
productividad
del codificador?
Proporcin del codificador:
Usando el estndar
Usando otro lenguaje
Experiencia de codificadores:
Con el estndar
Con otro lenguaje
Con lenguaje del entorno
Tamao
Errores
Esfuerzo
06/02/2013
GQM: Proceso
Desarrollar el conjunto de
objetivos corporativos, de
divisin y proyecto
Construir preguntas para cada
objetivo que lo definen en la forma
ms completa posible
Especificar las mtricas requeridas
para contestar las preguntas.
Construir los procesos de
recoleccin de datos
Recolectar, validar y analizar los
datos obtenidos
06/02/2013
EF: Factor Experiencia
4 La disciplina software es evolucionaria y
experimental.
4 El software es desarrollo, no produccin.
4 Est basado en lo humano.
4 El proceso y la meta son variables.
Las experiencias empaquetadas
reusables requieren recursos
adicionales dentro de la organizacin
a fin de ser utilizadas
06/02/2013
EF: El Proceso
Organizacin del Proyecto
Factor
Experiencia
Caracterizar
las metas
fijas que
eligen el
proceso
Ejecutar
Proceso
Proyecto /Caractersticas
del entorno
Metas acomodables, herramientas de
proceso, modelos de recursos,
modelos de defectos,desde
proyectos similares.
Datos, lecciones aprendidas,
Anlisis del proyecto, modificacin
del proyecto,
06/02/2013
EF: El Proceso
Organizacin
del Proyecto
Factor Experiencia

Analizar

Soporte
del
Proyecto
Datos,
lecciones
aprendidas,

Base de
experiencia

Paquete
Generalizar
Formalizar
Acomodar
Regeneracin
directa del
proyecto
Productos,
lecciones
aprendidas,
modelos
Caractersticas
del producto
Modelos,
herramientas,
lneas base
06/02/2013
CMM: Valoracin
Inicial (Nivel 1)
Repetible (Nivel 2)
Gestin de configuracin del software
Seguridad de la Calidad del Software
Gestin de Subcontratos de Software
Seguimiento del Proyecto de Software y vigilancia
Planificacin del Proyecto de Software
Gestin de requerimientos
Definicin (Nivel 3)
Mirar revisiones
Coordinacin intergrupos
Ingeniera de Produccin de Software
Gestin de Software Integrado
Entrenamiento del Programa
Organizacin de la Definicin del Proceso
Organizacin del Enfoque del Proceso
Manejo (Nivel 4)
Gestin de la Calidad del Software
Gestin del Proceso Cuantitativo
Manejo (Nivel 5)
Gestin de Cambio del Proceso
Gestin de Cambio de Tecnologa
Prevencin de Defectos
06/02/2013
CMM: Valoracin (Nivel 2)
Input:
Requerimientos
Repetible (Nivel 2)
Gestin de configuracin del software
Seguridad de la Calidad del Software
Gestin de Subcontratos de Software
Seguimiento del Proyecto de Software y vigilancia
Planificacin del Proyecto de Software
Gestin de requerimientos
Control:
Personal
Herramientas
Control:
Presupuesto
Horario
Estndares
Output:
Cdigo
Documentacin
Construye
ndo el
Sistema
Se debe definir
mtricas para
cada aspecto
visible:
Requerimientos
Cdigo
Recuperacin
06/02/2013
CMM: Valoracin (Nivel 3)
Mtodo de
Diseo
Define
Diseo

Definicin (Nivel 3)
Mirar revisiones
Coordinacin intergrupos
Ingeniera de Produccin de Software
Gestin de Software Integrado
Entrenamiento del Programa
Organizacin de la Definicin del Proceso
Organizacin del Enfoque del Proceso
Cdigo,
Prueba
de
unidad
Integr
a do

Criterio de
Inspeccin
Plan de
Diseo
Herramientas
de Personal
Herramientas
de Personal
Herramientas
de Personal
Requeri-
mientos
Sistema
de
Software
Diseo del
Sistema
Prueba de
Mdulos
Se debe definir mtricas para
cada aspecto visible:
Atributos del Producto
Diseo del Sistema
Mdulos de Pruebas de Calidad
06/02/2013
Qu se mide con las
mtricas?
4 La medicin y las mtricas nos van a servir para
entender mejor el proceso tcnico de desarrollo de un
producto y el mismo producto. Un proceso se mide para
intentar mejorarlo y el producto se mide para intentar
aumentar la calidad.
4 Cuando se planifica un proyecto de software, se tiene
que obtener estimaciones sobre:
El tamao del software, generalmente en lneas de
cdigo
El esfuerzo humano, normalmente en personas -
mes.
La duracin del proyecto, normalmente en meses.
El costo del proyecto, normalmente en dlares.
06/02/2013
Qu se mide con las
mtricas?
Duracin del proyecto Esfuerzo humano
Costo del proyecto
Tamao del software
06/02/2013
Tipos de mtricas
4Entre las medidas podemos establecer dos
tipos de medidas:
Directas: aquellas que se obtienen por
medicin directa con un instrumento de
medicin.
Indirectas: aquellas que no pueden medirse
directamente, sino a travs de estimaciones
basndose en medidas directas.
06/02/2013
Mtricas del Software
Medidas directas Medidas indirectas
Costo Funcionalidad
Esfuerzo humano Calidad
Lneas de cdigo Complejidad
Velocidad de ejecucin Eficiencia
Tamao de memoria Fiabilidad
Nmero de defectos Facilidad de uso
Etc. Etc.
06/02/2013
Clasificacin de mtricas
4Por su orientacin en
Orientadas al tamao: Se usan para
obtener medidas directas del resultado y la
calidad de la ingeniera de software.
Orientadas a la funcin: Proporcionan
medidas indirectas.
Orientadas a las personas: Proporcionan
informacin sobre la gente que desarrolla
software y sobre el punto de vista humano de
la efectividad de herramientas y mtodos.
06/02/2013
06/02/2013
4Por su cualidad en
Mtricas de productividad: Se centran en el
rendimiento del proceso ingeniera del
software.
Mtricas de calidad: Indican cmo se ajusta
el software a los requisitos implcitos y
explcitos.
Mtricas tcnicas: Se centran en las
caractersticas del software en si.
06/02/2013
06/02/2013
Caractersticas de las
mtricas del software
4Simple y fcil de calcular.
4Emprica e intuitiva.
4Sin ambigedades y objetiva.
4Consistente en el empleo de unidades y
tamaos .
4Independiente del lenguaje de
programacin.
4Eficaz para aumentar la calidad del
software.

06/02/2013
Mtricas orientadas al tamao
4Son medidas directas del software y del proceso que lo
desarrolla.
4Como paradigma tenemos al LDC (lneas de cdigo) y
como extensin KLDC (miles de lneas de cdigo)
Indica el nmero de lneas de cdigo.
Entre sus ventajas puede sealarse que es fcil de
calcular porque todos los procesadores de textos
cuentan con contadores de lnea.
Entre las desventajas puede sealarse que
dependen del lenguaje de programacin, que no se
adaptan fcilmente a lenguajes no procedimentales y
que cuando se usa en la estimacin requiere un nivel
de detalle que no es fcil de conseguir (El
planificador debe estimar antes de realizar las etapas
de anlisis y diseo).
06/02/2013
KLDC
Esfuerzo
humano
(Personas-mes)
Costo en $
Pginas de
documentacin
Nmero de errores
(defectos))
Calidad = N de errores /KLDC
Costo = Dlares /KLDC
Documentacin = Pginas /KLDC
Productividad = KLDC /Personas-mes
06/02/2013
4Con esta mtrica se puede obtener:
Productividad = KLDC/Esfuerzo
(Esfuerzo:= persona x mes)
Calidad = Errores/KLDC
Costo = Costo_medio /KLDC
Documentacin = Pginas de
documentacin/KLDC.
4Adems puede obtenerse:
Errores / Esfuerzo
LDC / Esfuerzo
Dlares / Pginas de documentacin
06/02/2013
Mtricas orientadas al tamao:
Ejemplo
Proyecto Costo
Medio
KLDC Pginas de
documentacin
Errores
Planillas 500 2,8 80 45
Administracin
de hostal
800 3,4 120 50
Contabilidad 450 5,2 90 75
Para el proyecto Contabilidad, por ejemplo:
Calidad = 75/5,2 = 14,42 (14,42 errores por cada mil
lneas de cdigo).
Costo = 450/5,2 = 86,54(86,54 dlares por cada mil lneas de
cdigo).
Documentacin = 90/5,2 = 17,31 (17,31 pginas de
documentacin por cada mil lneas de cdigo).
06/02/2013
Mtricas orientadas a la
funcin
4Son medidas indirectas del software y del
proceso Se centran en la "funcionalidad" o
"utilidad" del producto.
4Fueron propuestas por ALBRECHT, con el
mtodo denominado punto de funcin.
4Los puntos de funcin (PF) se obtienen
estableciendo una relacin emprica basada en
medidas cuantitativas del dominio de
informacin del software y valoraciones
subjetivas de la complejidad del software.
06/02/2013
Mtricas orientadas a la funcin:
Dominio de Informacin
4En el dominio de informacin se consideran los
siguientes parmetros:
Nmero de entradas del usuario: Se cuenta cada
entrada del usuario que proporciona datos al
programa, orientados a la aplicacin. Se hace
referencia a pantallas, formularios, cuadros de
dilogo, controles, mensajes a travs de los cuales
el usuario puede realizar las tres operaciones bsicas
de aadir, borrar o modificar datos .
Nmero de salidas del usuario: Se cuenta cada
salida que proporciona informacin orientada a la
aplicacin. Se hace referencia a pantallas,
formularios, informes por impresora (reportes y
etiquetas), grficos, mensajes de error, etc.
06/02/2013
Nmero de consultas del usuario: Una consulta se
define como una entrada interactiva del usuario al
programa, para producir una salida interactiva. Se
cuenta cada consulta por separado.
Nmero de archivos internos: Se cuenta cada
archivo maestro de base de datos lgico (puede ser
una gran base de datos, o archivos independientes).
Es decir son todas las tablas maestras que se han
creado para el software.
Nmero de archivos de interfaz externos: Se
cuentan todas los archivos controlados por otros
programas con los cuales el programa interacta,
hace referencia a grupos de datos o informacin de
control que entra o sale del programa.
06/02/2013
Complejidad del software
4Se considera un nico parmetro:
Valores de ajuste: Se refiere a un
cuestionario de 14 factores de valoracin
sobre aspectos de funcionalidad y
complejidad del software en si. Cada una se
evala de 0 a 5. Para asignar estos valores
hay que tener bastante cuidado.
06/02/2013
Tabla del dominio de informacin
Parmetro de
medida
Cuenta Factor de ponderacin Total
Simple Medio Complejo
N de entradas del
usuario
3 4 6
N de salidas del usuario
4 5 7
N de peticiones del
usuario
3 4 6
N de archivos
7 10 15
N de archivos de interfaz
externos
5 7 10
CUENTA TOTAL
06/02/2013
Tabla de valores de ajuste
Evaluar cada factor de 0 a 5
Sin
influencia
Incidental Moderado Medio Significativo Esencial
0 1 2 3 4 5
FACTORES
1 Comunicacin de datos
2 Procesamiento distribuido
3 Objetivos de rendimiento
4 Configuracin de uso intensivo
5 Tasa de transacciones
6 Entrada de datos en lnea
7 Eficiencia con el usuario final
8 Actualizacin de datos en lnea
06/02/2013
Tabla de valores de ajuste
Evaluar cada factor de 0 a 5
Sin
influencia
Incidental Moderado Medio Significativo
Esencial
0 1 2 3 4
5
CUESTIONARIO
9 Procesamiento complejo
10 Reusabilidad
11 Facilidad de instalacin y conversin
12 Facilidad operacional
13 Instalaciones mltiples
14 Versatilidad
06/02/2013
1. Comunicacin de datos: Este factor concierne a la
transmisin de datos o informacin de control, enviados o
recibidos por algn sistema de comunicacin.
Ejemplo: Un programa acadmico universitario que ha de
gestionar transferencias de notas de alumnos de todas las
facultades de la universidad.
Evaluacin:
0: Sistema aislado del exterior.
1: Lotes, usa perifricos E o S remotos.
2: Lotes, usa perifricos E y S remotos.
3: Captura de datos en lnea o teleproceso que pasa los
datos o sistema de consulta.
4: Varios teleprocesos con mismo protocolo.
5: Varios protocolos. Sistema Abierto y con interfaces de
todo tipo al exterior.

06/02/2013
2. Procesamiento distribuido: Concierne si una aplicacin
es monousuario y se ejecuta en un nico procesador o la
aplicacin es distribuida y se ejecuta en dos o ms
procesadores.
Ejemplo: Un programa para elecciones que ejecuta el
conteo de votos en muchos servidores que operan en
conjunto.
Evaluacin:
0: Sistema totalmente centralizado.
1: Sistema realiza procesos en un equipo, salidas usadas
va software por otros equipos.
2: Sistema captura, los trata en otro.
3: Proceso distribuido, transaccin en una sola direccin.
4: dem, transferencia en ambas direcciones.
5: Procesos cooperantes ejecutndose en distintos
equipos.

06/02/2013
3. Objetivos de rendimiento: Concierne si el rendimiento es un
requisito del sistema. Es decir es crtico algn factor como tiempo
de respuesta o cantidad de operaciones por hora.
Ejemplo: Un programa de control de atencin al pblico debe
indicar a las personas la ventana donde debe ser atendido. Ni bien
es atendido el cliente, la ventana debe est disponible para el
prximo cliente.
Evaluacin:
0: Rendimiento normal ( no se da nfasis ).
1: Se indican requisitos, no medida especial.
2: Crtico en algunos momentos. Procesos acabados antes de
aproxima sesin de trabajo.
3: Tiempo de respuesta es crtico.
4: En el diseo hace anlisis del rendimiento en tiempo de respuesta
o cantidad operacin /hora.
5: Uso de herramientas para alcanzar el rendimiento demandado por
el usuario

06/02/2013
4. Configuracin de uso intensivo: Indica si se va a
utilizar un entorno operativo utilizado de manera
intensiva en el que coexistir con otros, compitiendo por
los recursos.
Ejemplo: Un programa acadmico universitario donde
cientos de estudiantes hacen consultas
simultneamente.
Evaluacin:
0: No se indican restricciones
1: Existen las restricciones usuales
2: Caractersticas de seguridad o tiempo.
3: Restricciones en algn procesador.
4: El software deber funcionar con restricciones de uso
en algn procesador.
5: Restricciones especiales para aplicacin en los
componentes distribuidos del sistema.

06/02/2013
5. Tasa de transacciones: Concierne al volumen de
transacciones. Una alta tasa de transacciones traer
problemas que es necesario tenerlos en cuenta.
Ejemplo: Un programa bancario que ejecuta millones
de transacciones para cerrar las operaciones diarias.
Evaluacin:
0: No se prevn picos
1: Se prevn picos poco frecuentes (mensual)
2: Se prevn picos semanales
3: Se prevn horas punta, diarias
4: Tasa de transacciones tan elevada que en diseo se
hace anlisis de rendimiento.
5: Anlisis de rendimiento en diseo, implementacin e
instalacin.

06/02/2013
6. Entrada de datos en lnea: La entrada de datos ser
directa desde el usuario a la aplicacin, en forma
interactiva.
Ejemplo: Un programa de matrcula donde los
empleados introducen los datos de los alumnos
extrados de las fichas de matrcula.
Evaluacin:
0: Todo es por lotes.
1: 1%<=entradas interactivas <=7%.
5: Entradas interactivas >30%

06/02/2013
7. Eficiencia con el usuario final: Se demanda eficiencia
para el usuario en su trabajo, es decir se tiene que disear
e implementar la aplicacin con interfaces fciles de usar y
con ayudas integradas en mltiples pantallas y variadas
operaciones. Incluye:
- Mens
- Uso de ratn
- Ayudas en lnea
- Movimiento automtico del cursor
- Efectos de desplazamiento (scroll)
- Teclas de funcin predefinidas
- Lanzamiento de procesos por lotes desde las transacciones en lnea
- Seleccin mediante cursor de datos de la pantalla
- Pantallas con muchos colores y efectos
- Posibilidad de copia impresa, ventanas de "pop-up
- Aplicacin bilinge y multilinge

06/02/2013
Ejemplo: Un programa para registrarse como un
usuario de servicio de Internet donde se debe
responder a una larga encuesta.
Evaluacin:
0: No se da nfasis al tema.
1: 1 a 3 de los factores.
2: 4 a 5 de los factores.
3: 6 o ms factores, sin requerir eficiencia.
4: Con requerimientos que implican estudio de los
factores humanos en el diseo.
5: Se demandan prototipos y herramientas para
verificar que se alcanzaran los objetivos .

06/02/2013
8. Actualizacin de datos en lnea: Los archivos maestros y las
bases de datos son modificadas directamente de forma
interactiva.
Ejemplo: Sistema para hacer reservas o comprar boletos para
asistir a un campeonato de ftbol internacional como la Copa
Amrica.
Evaluacin:
0: No hay.
1: De 1 a 3 archivos con informacin de control. Cantidad baja y
archivos recuperables.
2: Pero con 4 o ms archivos de control.
3: Actualizacin de archivos importantes.
4: Esencial la proteccin ante prdidas.
5: Gran cantidad de actualizaciones interactivas. Sistemas de
recuperacin muy automatizados.
06/02/2013
9. Procesamiento complejo: La complejidad interna en un proceso
esta en funcin de las siguientes caractersticas:
Especificaciones de algoritmos matemticos complejos.
Proceso con lgica compleja.
Especificacin de muchas excepciones, consecuencia de
transacciones.
Manejo de mltiples dispositivos de entrada/salida.
Se incorporaran sistemas de seguridad y control .
Ejemplo: Un programa de un centro veterinario, donde a partir de
los sntomas que presenta una mascota se llega a una serie de
decisiones que conducen a un diagnstico.
Calificacin:
0: Ninguna de las caractersticas.
1: 1 Caracterstica.
2: 2 Caractersticas.
...
5: Las 5 caractersticas.

06/02/2013
10. Reusabilidad: Indica si gran parte de la funcionalidad del sistema
est pensado para el uso intensivo en otras aplicaciones.
Ejemplo: Un programa de navegacin en una tabla puede ser usado
en muchas aplicaciones ya que el funcionamiento es el mismo: ir al
registro siguiente, al anterior, al primero, al ltimo, a determinado
registro, buscar un registro, etc.
Evaluacin:
0: No se prev
1: Reutilizar cdigo en la misma aplicacin.
2: Menos de un 10% de la aplicacin tiene en cuenta las
necesidades de mas de 1 usuario.
3: El 10 % o ms ...
4: Aplicacin preparada para ser reutilizable a nivel de cdigo.
5: Aplicacin preparada para ser reutilizable por medio de
parmetros

06/02/2013
11. Facilidad de instalacin y conversin: Se refiere a que si es
necesario un esfuerzo especial para instalar el sistema y pruebas
para que la conversin del sistema antiguo sean fciles de realizar
durante la puesta en marcha del sistema nuevo.
Ejemplo: Un sistema de ventas en arquitectura Cliente /Servidor
que debe instalarse en una empresa.
Evaluacin:
0: No se requiere conversin.
1: Se solicita facilidad de instalacin.
2: Se solicitan procesos de conversin e instalacin, no importantes para
el proyecto.
3: Si son importantes.
4: 2, y herramientas conversin e instalacin.
5: 3, y herramientas conversin e instalacin. Sistema crtico para la
empresa .

06/02/2013
12. Facilidad de operacin: Hace referencia a trabajos
asignados al centro de proceso de datos como arranque,
parada, recuperacin ante fallos, copias de seguridad o
minimizacin de las actividades manuales en el CPD.
Ejemplo: Un programa para procesamiento e un examen de
admisin donde el sistema debe procesar informacin
minimizando el nmero de veces que debe leerse las
tarjetas de respuestas.
Evaluacin:
0: Nada, en todo caso, back-up.
1 a 4: Suma de tems:
Arranque, back-up y recuperacin.
Idem., sin intervencin de operador.
Minimizar necesidad de dispositivos externos de almacenamiento.
Minimiza necesidad de manejar papel.
5: Sistema automtico sin intervencin humana.
06/02/2013
13. Instalaciones mltiples: El sistema incluir los
requerimientos de diversas empresas o departamentos
en donde se ejecutar (incluso en diferentes
plataformas).
Ejemplo: Un programa para administrar el sistema
acadmico se debe instalar en todas las facultades de
una universidad.
Evaluacin:
0: 1 solo lugar.
1: Mltiples lugares, con el mismo hardware y software.
2: En diseo se tiene en cuenta el caso (1).
3: En diseo se tiene en cuenta mltiples entornos de
hardware y software.
4: Se documenta y planea para (1) y (2).
5: Idem, para (3).

06/02/2013
14. Versatilidad: Indica si el sistema ha sido construido para
facilitar cambios y fcil de adaptar a las necesidades del
usuario.
Items a tener en cuenta:
Consultas flexibles del usuario:
Simples con condiciones lgicas And /Or que
implican un nico archivo lgico.
Medias con condiciones lgicas sobre ms de 1
archivo lgico.
Complejas con condiciones lgicas complejas
que afectan a varios archivos lgicos.
Parmetros de la aplicaciones con tablas ajenas al
cdigo:
El cambio se hace efectivo al arrancar el sistema.
El cambio es interactivo.

06/02/2013
Ejemplo: El programa de administracin de una centro
veterinario transformable a una arquitectura Cliente
/Servidor al agregarse sucursales.
Evaluacin:
0: No se especifica nada.
1: Un tem de valor 1.
2: Items por valor 2.
3: ...
5: Items por valor 5.

06/02/2013
Mtricas orientadas a la
funcin: Clculo de PF
PF = Cuenta total x [0,65 + 0,01x ]
=
14
1 i
i F
Punto de Funcin
Suma de valores de la tabla del dominio de informacin
Suma de valores de ajuste
06/02/2013
Mtricas orientadas a la funcin
PF
Esfuerzo
humano
(Personas-mes)
Costo en $
Pginas de
documentacin
Nmero de errores
(defectos))
Calidad = N de errores /PF
Costo = Dlares /PF
Documentacin = Pginas /PF
Productividad = PF /Personas-mes
06/02/2013
4Ejemplo:
Vamos a suponer que un proyecto sobre
PLANILLAS tiene
15 entradas de datos.
25 salidas de datos.
18 consultas (peticiones).
3 Tablas (Datos_Personales, Planilla,
Descuento_Comerciales)
3 interfaces externas.

06/02/2013
4Suponemos que los factores de ponderacin son medios;
en consecuencia tenemos:

Valor de parmetros Ponderacin media TOTAL
15 15*4 60
25 25*5 125
18 18*4 72
3 3*10 30
3 3*7 21
CUENTA TOTAL 308
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Suma
4 4 0 3 3 5 4 4 3 3 2 3 4 5 47
06/02/2013
4En consecuencia:

PF = Cuenta total x [0,65 + 0,01x ]
PF = 308 x [0,65 + 0,01x47] = 344,96
=
14
1 i
i
F
Para el proyecto Administracin de una empresa
constructora , tenemos:
Calidad = 45/344,96 = 0,1384 errores por cada PF.
Costo = 500/344,96 = 1,45 dlares por cada PF.
Documentacin = 80/344,96 = 0,2319 pginas por
cada PF.
06/02/2013
Ventajas y desventajas
4 Entre sus ventajas puede sealarse:
Se ha convertido en el estndar de medicin (ISO
14143).
Hay estadsticas que validan el modelo.
Existen ampliaciones del modelo.
Son independientes de los lenguajes.
Se deducen del anlisis y diseo.
4 Entre las desventajas puede sealarse:
Exige mayor preparacin que las LDC.
Es una medida indirecta.
Puede variar enormemente si no se utiliza
adecuadamente.

06/02/2013
Estimacin del Esfuerzo y el
Tiempo con KLDC
4El esfuerzo en personas mes (PM) y el tiempo de
desarrollo de de un proyecto (TDP) puede calcularse
con las frmulas, propuestas por Boehm:

PM = a*(KLDC^b)
TDP = c*(PM^d)
Donde:
PM = Personas por mes
TDP = Tiempo de desarrollo del proyecto
KLDC = Miles de lneas de cdigo
06/02/2013
Estimacin del Esfuerzo y el
Tiempo con KLDC
4Los valores de los coeficientes son:

4Ejemplo: Para un proyecto de Contabilidad con 5,2
KLDC
PM = a*(KLDC^b) =2,4*( 5,2^1,05) = 13,55.
TDP = c*(PM^d) = 2,5*(13,55^0,38) = 6,73 meses.
NP = PM/TDP = 13,55/6,73 = 2,01 ~ 2 personas.

Programas a b c d
Aplicacin 2,4 1,05 2,5 0,38
Apoyo 3 1,12 2,5 0,35
Sistema 3,6 1,2 2,5 0,32
06/02/2013
Otras estimaciones del Esfuerzo
con KLDC
4Otras estimaciones del esfuerzo son las siguientes:
PM = 5,2*(KLDC^0,91) (Waltson - Felix)
PM = 5,5*0,73*(KLDC^1,16) (Waltson - Felix)
PM = 5,288*(KLDC^1,047) [KLDC>=10] (Doty)
4Nota: Como puede verse, los resultados van a salir
muy diferentes, hay que calibrarlos de acuerdo a la
naturaleza de cada aplicacin.
06/02/2013
Estimacin del Esfuerzo con PF
4El esfuerzo en personas mes (PM) y el tiempo de
desarrollo de de un proyecto (TDP) puede calcularse
con las frmulas:

PM = -13,19 + 0,0545*PF (Albrecht y Gaffney)
PM = 60,62*7,28*(10^-8)*(PF^3) (Keremer)
PM = 587+15,12*PF (Matson, Mellichamp, Barnett)
4Nota: Como puede verse, los resultados van a salir
muy diferentes, hay que calibrarlos de acuerdo a la
naturaleza de cada aplicacin. Nosotros vamos a
aplicar la primera sugerida por Albrecht y Gaffney.
06/02/2013
Estimacin del Esfuerzo con PF:
Ejemplo
4 Para el proyecto Planillas, tenemos:

PM = -13,19 + 0,0545*344,96
PM = 5,61
4 Es decir; 5, 61 personas mes.
06/02/2013
Estimacin de la Productividad
4La productividad se define por la formula:

Productividad = KLDC/PM
Productividad = PF/PM

Ejemplo: Para un proyecto de Contabilidad con 5,2 KLDC
Productividad = KLDC/PM = 5,2/ 13,55 = 0,3838, es
decir 383,8 lneas de cdigo por persona-mes.

Ejemplo: Para un proyecto de Planillas con 5,61 PM
Productividad = PF/PM = 344,96 / 5,61 = 61,49, es
decir 61,49 puntos de funcin por persona-mes.
06/02/2013
Equivalencia entre KLDC y PF
Leguaje o entorno LDC/PF
4GL 40
ADA 95 53
APL 32
Visual Basic 32
C 128
C++ 29
Clipper 19
Delphi 29
Ensamblador (Macro) 213
Forth 64
Fortran 77 105
FoxPro 2,6 34
Generador de informes 80
Leguaje o entorno LDC/PF
Hoja de clculo 6
Java 53
Modula 2 80
Oracle 2000 23
Paradox 36
Pascal 91
Power Builder 16
Prolog 64
Visual C++ 34
Cobol 106
Visual Cobol 20
Smalltalk 22
SQL 12
06/02/2013
Equivalencia entre KLDC y PF
4La tabla de equivalencia entre KLDC y PF puede sernos
de bastante utilidad, para hacer estimaciones del esfuerzo
PM y el tiempo de desarrollo del proyecto para un
proyecto del que no tenemos informacin sobre lneas de
cdigo.
Ejemplo: Para un proyecto de Administracin de una
empresa constructora donde hemos obtenido 344,96
PF. Para estimar PM y TDP podemos hallar su
equivalencia EN KLDC. Suponemos que se va a utilizar
el Visual Basic como lenguaje:
Por la tabla tenemos LDC/FP = 32, entonces LDC 0
32*344,96 = 11038,72; es decir 11,039 KLDC.
Entonces
PM = a*(KLDC^b) =2,4*( 11,039^1,05) = 29,87.
TDP = c*(PM^d) = 2,5*(29,87^0,38) = 9,09 meses.
NP = PM/TDP = 29,87/9,09 = 3,28 ~ 3 personas.

06/02/2013
Calidad del software
4Concordancia con:
Los requisitos explcitos: funcionales y
de rendimiento.
Los estndares de desarrollo.
Las caractersticas implcitas que debe
reunir cualquier software.
06/02/2013
Calidad del software
06/02/2013
Factores que influyen en la
calidad del software
4 Operacin del producto: su uso.
4 Revisin del producto: su
modificacin.
4 Transicin del producto: su
portabilidad.
06/02/2013
Medidas de calidad
4 Correccin: adecuacin del
software a la funcin requerida.

4 Facilidad de mantenimiento:
facilidad para corregir un error,
adaptar un programa a los cambios
en los requisitos, y mejorarlo.
N de defectos por KLDC
TMEC (Tiempo Medio Entre Cambios)
06/02/2013
Medidas de calidad
4Integridad: capacidad para resistir
ataques provocados o no, contra su
seguridad.
4 Amenaza: probabilidad de que cierto tipo
de ataque ocurra en un tiempo.
4 Seguridad: probabilidad de que se
puede contrarrestar un cierto tipo de
ataque.
Integridad = E[(1- Amenaza)*(1-Seguridad)]
06/02/2013
Medidas de calidad: Ejemplo
4Supongamos que en el transcurso de 72 horas
tenemos las amenazas de 3 virus :
Michelangello, Viva Chile y Madona y de otro
lado que falle la computadora y las
probabilidades son del 10, 8, 5 y 4 %
receptivamente. Pero contamos con antivirus y
la probabilidad de combatir los tres virus son del
99, 95, 95 % y la probabilidad de reparar la falla
es del 97%.
06/02/2013
Medidas de calidad: Ejemplo
4Los trminos de la sumatoria son:

4Se espera que en los casos que haya n amenazas y n
seguridades la integridad tienda a n.

[1 - 0,10 x (1 - 0,99)] = 0,999
[1 - 0,08 x (1 - 0,95)] = 0,996
[1 - 0,05 x (1 - 0,95)] = 0,9975
[1 - 0,04 x (1 - 0,97)] = 0,9988
Total: 3,9913
06/02/2013
Medidas de calidad
4Facilidad de uso: amistad con el
usuario.
Habilidad intelectual y/o fsica para aprender
a utilizar el sistema.
Tiempo necesario para llegar a dominar su
uso.
Aumento neto en productividad.
Valoracin subjetiva de la predisposicin de
los usuarios hacia el sistema.
06/02/2013
Medidas de calidad
4Podemos valorar estos 4 aspectos en una
escala de 0 a 5:
Calificacin Valor
Nulo 0
Bajo 1
Regular 2
Bueno 3
Muy Bueno 4
Excelente 5
06/02/2013
Medidas de calidad
4Eficiencia: recursos y cdigo necesarios
para que un programa realice su funcin.
4Reusabilidad: facilidad para volver a
utilizar partes de un programa en otras
aplicaciones.
Modularidad, independencia del
hardware y del sistema,
generalidad,

4Interoperatividad: esfuerzo necesario
para acoplar un sistema con otro.

06/02/2013
Mtricas de fiabilidad
4Probabilidad de fallo en demanda:
probabilidad de que un sistema se
comporte de manera rara ante una
peticin.
4Tasa de fallos: frecuencia de
comportamientos inesperados.

06/02/2013
4Tiempo medio de fallos (TMDF): tiempo
promedio de operatividad del sistema
antes que aparezca un fallo.
4Tiempo medio de reparacin (TMDR):
tiempo promedio para reparar un fallo.
4Tiempo medio entre fallos (TMEF):
tiempo promedio que es la suma del
tempo promedio de fallos y el tiempo
promedio de reparacin.

06/02/2013

4Disponibilidad: probabilidad de que
el sistema se halle disponible para su
uso.
TMEF = TMDF + TMDR
Disponibilidad = [TMDF/(TMDF + TMDR)]*100 %
06/02/2013
Mtricas de fiabilidad: Ejemplo
4Supongamos que en sistema cada dos
horas hay amenaza un virus que hace que
falle el sistema. El tiempo de reparacin
es de 5 minutos. En consecuencia
tenemos:
TMDF = 120; TMDR = 5
TMEF = TMDF + TMDR = 120 + 5 = 125
Disponibilidad = (120/125)*100 = 96%.

06/02/2013
4Para estimar el costo, y el esfuerzo hay varias opciones:
Postergar la estimacin, lo ms tarde posible, a fin
de lograr una aproximacin ms exacta. (Esta opcin
no es prctica, la estimacin se necesita antes de
iniciar el proyecto).
Usar tcnicas tradicionales y de descomposicin:
dividir el problema a fin de facilitar la estimacin.
Desarrollar un modelo emprico d = f(v) con datos
histricos donde d es el valor estimado (esfuerzo,
costo, tiempo de desarrollo del proyecto) y v es una
mtrica calculada con datos histricos (LDC, PF,
etc.).
Hacer uso de herramientas automatizadas que se
basan en la descomposicin o modelos empricos.
06/02/2013
Tcnicas de estimacin:
Mtodos tradicionales
4Para estimar el costo, siempre hay que basarse en
experiencias anteriores. Los datos histricos sirven para
identificar factores de costo y determinar la importancia
de los diversos factores
4Existen 2 mtodos fundamentales para la estimacin de
costos:
TOP DOWN(Estimacin descendente):
Comienza a nivel de sistema y evala la totalidad de
funcionalidades y cmo estas se subdividen en
subsistemas.
BUTTOM UP(Estimacin ascendente):
Comienza a nivel de componente y estima el
esfuerzo requerido por cada componente. Dichos
esfuerzos se agregan a la estimacin final.
06/02/2013
4Estimacin descendente
Los clculos se hacen en el siguiente orden:
Costos genricos al nivel de sistemas.
Costos de control de calidad.
Costos de integracin del sistema.
Costos de entrenamiento.
Costos de documentacin.
Costos de personal.
Observaciones:
Se puede usar sin conocer la arquitectura del sistema,
ni los componentes que forman parte del sistema.
Puede infraestimarse costos relacionados con la
resolucin de problemas tcnicas de bajo nivel, difciles
de resolver.

06/02/2013
4Estimacin ascendente
Se sigue el orden:
Se estiman los costos de cada mdulo o
subsistema.
Se integran estos costos para obtener el costo
general.
Observaciones:
Se puede usar cuando la arquitectura del sistema
es conocida y los componentes han sido
identificados.
Proporciona estimaciones bastante exactas si el
sistema ha sido diseado con detalle.
Puede infraestimarse costos relacionados al
sistema tales como integracin y documentacin.

06/02/2013
TE: Mtodos tradicionales
Modelos
4 Existen varios modelos que se adaptan tanto al
diseo descendente o ascendente. Los ms
conocidos son:
EJuicio experto.
E Estimacin por analoga.
E DELFI.
E Ley de Parkinson.
E Pricing to win.
E WBS.

06/02/2013
TEC: Juicio experto
4Es una de las tcnicas de estimacin de costos
ms usadas. Es del tipo ascendente. Se basa
en la experiencia y en el sentido comercial de
uno o ms individuos de la organizacin. Se
realizan iteraciones hasta alcanzar consenso.
4Ventajas
Relativamente es barato. Si los expertos
tiene experiencia en un proyecto similar la
aproximacin puede ser casi exacta.
4Desventajas
Es impreciso si no se encuentra los expertos
adecuados.
06/02/2013
TEC: Juicio experto
4 Observaciones:
La mayor ventaja que es la experiencia, puede
convertirse en una desventaja, puesto que el
experto puede confiarse en un proyecto anterior
como el dado en el ejemplo, sin considerar que
pueden existir factores que ocasionen que el
nuevo proyecto sea significativamente diferente
y que el experto no tenga experiencia en este
tipo de situaciones.
Influye tambin la capacidad que tenga el
experto para comunicarse con el personal, su
personalidad, su poder de persuasin, etc. Hay
que tener en cuenta tambin las polticas y el
marco legal en la que se desarrolla el proyecto.
06/02/2013
TEC: Estimacin por analoga

4El costo de un proyecto se calcula por comparacin con
proyectos similares con el mismo dominio de aplicacin.
4Ventajas
Bastante preciso si se dispone de datos de proyectos
parecidos.
Es realista puesto que se basa en experiencias
reales.
4Desventajas
Es difcil establecer el grado de similitud entre dos
proyectos.
Imposible si los proyectos no son compatibles.
Necesita mantenimiento sistemtico de una base de
datos.
06/02/2013
4Ejemplo:
Supongamos que debemos estimar el costo del
proyecto Administracin de la mina Luvina.
Sabemos que un proyecto anterior similar para la
mina Tawaawi de la misma compaa minera dur
10 meses y costo 125 mil dlares.
El proyecto anterior de la mina Tawaawi permiti
obtener buenas utilidades aunque no una gran
ganancia. Entonces se mantendr el esquema bsico
del proyecto con las modificaciones necesarias para
mejorarlo.
06/02/2013
Tericamente habr un incremento del 25% ms de
actividades, con lo que el costo y el TDP se incrementa en
el mismo porcentaje. Por lo tanto:
Costo = 125000 + (0,25*125000) = 156250 dlares
TDP = 10 + (0,25*10) = 12,5 meses
Pero el proyecto se va a desarrollar casi con el mismo
equipo y personal por lo que es posible disminuir el costo y
tiempo en un 40 %. Por lo tanto:
Costo = 156250 - (0,4*156250) = 93750
TDP = 12,5 - (0,3*12,5) = 7,5 meses
Pero la administracin de la mina est dispuesta a pagar
hasta 125000 dlares, entonces se recomienda
presupuestar 110000 dlares. Y como puede esperar hasta
10 meses, puede estimarse el tiempo en 8,5 meses.
06/02/2013
TEC: DELFI
4 Fue usada por la corporacin RAND en 1948, con el fin
de conseguir consenso en los expertos, sin contar con
los efectos negativos de las reuniones de grupo. Esta
tcnica ha sido adaptada a la estimacin de costos de
proyectos de software por Boehm como sigue:
El coordinador proporciona a cada experto la
documentacin con la definicin del sistema y una
papeleta para que cada experto escriba su
estimacin.
Cada experto estudia la definicin y determina su
estimacin en forma annima. Los expertos pueden
consultar con el coordinador pero no entre ellos.
06/02/2013
TEC: DELFI
El coordinador prepara y distribuye el resumen de las
estimaciones efectuadas incluyendo cualquier
razonamiento extrao efectuado por algn experto.
Los expertos realizan una segunda ronda de
estimaciones otra vez annimas, utilizando los
resultados de la estimacin anterior. En los casos de
que una estimacin difiera mucho de las dems, se
podr solicitar que, tambin en forma annima, el
experto justifique su estimacin.
El proceso se repite cuantas veces sea necesario
impidiendo la discusin grupal durante todo el
proceso.
06/02/2013
TEC: DELFI de banda ancha
4 Es una variante introducida por el mismo
Boehm que consiste en introducir 2 pasos ms
a los mencionados , con lo que se obtienen
mejores resultados:
Despus de entregar la documentacin y la
papeleta, el coordinador rene a los expertos para
que intercambien puntos de vista sobre el proyecto.
Luego se procede como antes.
Despus de hacer la primera estimacin annima y
recibir el resumen hecho por el coordinador, el
coordinador rene a los expertos para que discutan
las razones de Las diferencias entre sus
estimaciones.
06/02/2013
TEC: DELFI
4 Observaciones:
Es posible que despus de varias rondas no se llegue a un
consenso. En este caso el coordinador deber analizar los
aspectos relacionados con cada experto para determinar las
causas de todas las diferencias. Puede ser que el coordinador
tenga que recabar informacin adicional, presentarlas a los
expertos a fin de resumir los diferentes puntos de vista.
4 Ventajas:
Produce juicios de consenso en reas problemticas
Es rpido y eficaz en obtener informacin de un grupo de
expertos.
Es un mtodo estructurado que permite anticipar sucesos
futuros.
Permite ver diferencias entre experiencias anteriores y el actual,
difciles de detectar sin el auxilio de expertos
4 Desventajas:
Subjetividad e inexperiencia de los expertos participantes.
El diseo del cuestionario es a veces poco cuidado
Es vulnerable porque la seleccin de expertos es dirigida y no
aleatoria.

06/02/2013
DELFI : Ejemplo
Administracin de la mina Luvina. Proyecto: Fecha: 25/02/2007
3 Estimacin N:
Su estimacin del esfuerzo es (personas mes): 35
Su estimacin del tiempo de desarrollo (meses): 10
Su estimacin del costo es (dlares): 110000
Justificacin:
Parece que es un sistema normal de transacciones y control
de procesos. Nuestra gente tiene experiencia en proyectos
similares. Se espera que no haya problemas. He decidido
considerar mi estimacin teniendo en cuenta el uso del
procesador Intel Pentium IV MMX 2.8 GH.
4 Proyecto: Administracin de la mina Luvina.
Estimacin en la 3. Vuelta.
06/02/2013
TEC: Ley de Parkinson
4 Los costos del proyecto estn en funcin de los
recursos disponibles y utilizando el tempo
permitido. Hay que emplear el precio para ganar
para negociar con el cliente para obtener el
contrato.
4 Ventajas:
Se obtiene un presupuesto realista. No hay
presupuesto abultado.
4 Desventajas:
Ms que una tcnica de estimacin es un
objetivo impuesto.
Por lo general no se termina de construir el
sistema.

06/02/2013
TEC: Pricing to win
4 Los costos del proyecto estn en funcin
de lo que el cliente est dispuesto a
pagar.
4 Ventajas:
La empresa desarrolladora del proyecto
asegura el contrato.
4 Desventajas:
La probabilidad de que el cliente
obtenga el sistema que desea es
pequea. Los costos no reflejan
realmente el trabajo requerido.

06/02/2013
Estructura de desglose del trabajo
(WBS= Work Breakdown Structure)

4 El WBS consiste en la descomposicin del
proyecto en subproyectos y actividades. La
WBS se aplica junto a la RBS (Risk Breakdown
Structure = Estructura de desglose de riesgos).
4 Los subproyectos se dividen en actividades o
tareas que hay que cumplir para alcanzar la
meta y objetivos. A cada actividad tiene una
duracin y se le asignan recursos tanto
humanos como materiales.
4 Para estimar los costos se puede hacer uso del
MS PROJECT, que nos permitir calcular el
costo total del proyecto como lo hemos
mostrado en el captulo anterior..
06/02/2013
Estructura de divisin del trabajo
(WBS= Work Breakdown Structure)

4 Es un mtodo del tipo BUTTOM UP. La
WBS es un organigrama funcional donde se
representan las diferentes partes del sistema.
Presenta la jerarqua de procesos o sistemas.
4 WBS del Producto
Mtodo de
lectura
Producto
Ayuda
Herramientas Sistema de
reportes
Sistema de
procesamiento
Sistema de entrada
de datos
Analizador sintctico y
ortogrfico
Validacin de
datos
Clculo de
resultados
Reporte para
pantalla
Reporte para
impresora
06/02/2013
Estructura de divisin del
trabajo (WBS)

4 WBS del Proceso
Proyecto: Sistema de uso de
recursos audiovisuales en
los institutos
5. Diseo:de BD, Interfaz
externa y componentes
internos
3. Construir los
tres modelos del
anlisis
4. Prototipo de
Interfaz y el Modelo
Arquitectnico
2. Definir el
problema
1. Recopilar
informacin
11 Panorama
del Proyecto
6. Construccin del
producto
1.2 Entrevistas
1.3 Lectura de
Documentacin
21 Plan
General
2.3 Estimacin
3.2 Modelo de
Eventos
31 Modelo de
Contexto
3.3 Modelo de
Informacin
2.2.
Requerimientos
4.1 Prototipo de
Interfaz
4.2Modelo
Arquitectnico
5.1 Diseo de
Base de Datos
5.3 Diseo de
Componentes
Internos
5.2 Diseo de
Interfaz Externa
6.1
Documentacin
6.3 Pruebas 6.2 Construccin
del Sistema
6.4 Instalacin
06/02/2013
(WBS): Ejemplo
Supongamos que los costos son:
Panorama del Proyecto: 304
Entrevistas: 117
Lectura de Documentacin 61
Plan General: 80
Requerimientos 180
Estimacin: 266
Modelo de Contexto: 320
Modelo de Eventos: 280
Modelo de Informacin: 350
Prototipo de Interfaz: 520
Modelo Arquitectnico: 800
Diseo de Base de Datos: 850
Diseo de Interfaz Externa: 960
Diseo de Componentes Internos: 750
06/02/2013
(WBS): Ejemplo

Documentacin: 800
Construccin del Sistema: 1200
Pruebas: 1000
Instalacin: 150
Total: 8988
El costo estimado es de 8988 soles ( $2568)
06/02/2013
(WBS): Observacin
4 Cuando utilizamos MS-PROJECT y calculamos el
costo del proyecto, estamos aplicando en realidad
el mtodo WBS del proceso, porque aproximamos el
costo del proyecto, asignado recursos y costos a
c/u de las actividades del proyecto.

06/02/2013
Descomposicin
4Cuando un problema es complejo, la solucin es conocida
Divide et impera (Divide y vencers). Es lo que se va a
utilizar en las tcnicas que a continuacin se describen.
Tcnicas de estimacin con LDC y PF
En esta tcnica la descomposicin funcional es esencial.
Se construye una tabla bsica en la que se trabaja con
datos histricos.

Tamao en LDC /PF Estimaciones
Funcin Optimista Probable Pesimista Estimado DL/
DPF
LM/
PFM
Costo PM/
PFM
06/02/2013
Descomposicin
donde:
El tamao estimado (E) se calcula en base al tamao pesimista
(P), tamao optimista (O) y el tamao ms probable (M):

Los dlares por lnea (DL) o dlares por PF (DPF) es la media
de proyectos similares anteriores.
Las lneas por mes (LM) o puntos de funcin por mes (PFM)
recoge el nmero de lneas o puntos de funcin por mes de
proyectos similares anteriores.
El Costo se obtiene multiplicando Estimado*DL o Estimado *
DPF.
El nmero total de Personas-Mes se obtiene dividiendo
Estimado/LM o Estimado/PFM.

6
4 P M O
E
+ +
=
06/02/2013
Descomposicin
4Ejemplo: Vamos a tomar el caso de un proyecto para un
sistema de administracin de una biblioteca estimando con
LDC.

4Total de LDC = 10333, Costo = $ 49341, Persona -mes =
52,62

Tamao en LDC Estimaciones
Funcin O M P E DL LM Costo Meses
Interfaz de usuario
Procedimientos
Gestin de BD
Control de perifricos
Ayuda
1500
2100
2350
1500
400
2100
3200
2800
1600
500
2350
5400
3000
1950
650
2042
3383
2758
1642
508
3
5
5
7
2
300
190
220
180
80
6126
16915
13790
11494
1016
6,81
17,81
12,54
9,12
6,35
TOTAL
10333 49341 52,62
06/02/2013
Descomposicin
4Estimacin del esfuerzo: Matriz de costos
Es una de las tcnicas ms usadas para calcular el costo
de un proyecto. La estimacin del esfuerzo se hace
delimitando las funciones del software obtenidas del
ambiente. Para cada funcin debe realizarse tareas de
ingeniera del software como se ve en la tabla:

Tareas
Funciones Total
Total Esfuerzo
Tarifa ($)
Costo ($) Costo Proyecto
06/02/2013
Descomposicin
donde:
Tareas: Son tareas de ingeniera de software como
Anlisis, Diseo, Codificacin, Prueba, etc.
Funciones: Las funciones que se deben realizar en el
proyecto como Interfaz de usuario, Controles, etc.
Total (Horizontal): N de personas por mes para cada
funcin.
Total (Vertical): N de personas por mes para cada
tarea.
Tarifa: Se pone los costos profesionales y los gastos
adicionales por persona-mes. Se da en dlares.
Costo: Es el costo total por tarea, resulta de Tarifa*Total.

Costo Proyecto: Es el costo total del proyecto.

06/02/2013
Descomposicin
4Ejemplo: Vamos a retomar el caso de un proyecto para un sistema
de administracin de una biblioteca estimando con LDC.
Tareas
Funciones Anlisis Diseo Cdigo Prueba Total
Interfaz de usuario
Procedimientos
Gestin de BD
Control de perifricos
Ayuda
1,0
2,0
2,0
1,5
1,0
2,0
8,0
6,0
4,0
2,0
0,5
3,5
3,0
2,5
2,0
3,5
4,5
2,0
1,0
1,0
7
18
13
9
6
Total
7,5 22,0 11,5 12,0
53
Tarifa ($)
1000 1100 800 900
Costo ($)
7500 24200 9200 10800
51700
4Costo total = $ 51700, Personas mes = 53 .
06/02/2013
Modelos empricos
4Un modelo emprico de estimacin de costos utiliza
frmulas derivadas empricamente a partir de datos
histricos para obtener los datos necesarios para
planificar un proyecto de software.
4Como los datos para estos modelos se obtienen a partir
de una cantidad de casos, hay que aplicarlos con
cuidado. Un mismo modelo no es adecuado para todo
tipo de software ni para todos los entornos de desarrollo.
4Estos modelos pueden clasificarse en:
Modelo simple
Modelo multivariable
Esttico
Dinmico
06/02/2013
Modelos empricos
4Modelos simple esttico: que usa datos histricos
para establecer relaciones y toma la forma exponencial
(los costos no crecen en forma lineal).
E = A * (Tamao^B)*M
donde
E:= esfuerzo en personas mes ( hora, semana,
ao, etc.)
A, B son constantes tcnicas obtenidas de la
experiencia
Tamao:= en KLDC o PF. Se puede PF a LDC con
la tabla de equivalencia dada.
El modelo bsico es el COCOMO.

06/02/2013
Modelos empricos
4Modelos multivariable esttico: que toma la forma
multilineal.

donde
a
i
,

b
i
:= son constantes tcnicas obtenidas de la
experiencia
v
i
:= son datos histricos.
4Modelos multivariable dinmico: que proyecta los
recursos en funcin del tiempo.
Como prototipo podemos sealar el modelo SLIM de
Putnam.

=
=
n
i
i v a
i
b
E
i
1
06/02/2013
COCOMO (Modelo de
Costo Constructivo)

4 El COCOMO (COnstructive COst MOdel) es el modelo
de estimacin de costos porque es el ms
completo y detalladamente documentado de los
modelos de estimacin del esfuerzo (Conte).Fue
desarrollado por Barry W. Boehm Se basa en el
tamao del software en KLDC y en base a l se
calcula:
Esfuerzo = PM en personas mes.
Tiempo de desarrollo del proyecto = TDP en meses
Personas necesarias para realizar el proyecto = PP
Costo total del proyecto = CTP en dlares.
06/02/2013
COCOMO (Modelo Bsico)

4 El COCOMO( COnstructive COst MOdel ) es un modelo que
sirve para estimar un proyecto. Existen 2 submodelos:
Modelo bsico: Para calcular PM y TDP usa las frmulas:
PM = a*(KLDC^b)
TDP = c*(PM^d)
PP = PM/TDP
CTP =PM * Sueldo_promedio_personal
donde:

Programas a b c d
Aplicacin 2,4 1,05 2,5 0,38
Apoyo 3 1,12 2,5 0,35
Sistema 3,6 1,2 2,5 0,32
06/02/2013
COCOMO (Modelo Intermedio)

Modelo intermedio: Tiene en cuenta KLDC y los factores de
ajuste de esfuerzo (FAE):
Estos factores se evalan con un rango de calificaciones y es
necesario contar con gente de bastante experiencia, para que
la subjetividad se de en forma reducida, ya que es imposible
eliminarla totalmente. Esta evaluacin se hace segn la tabla
que sigue:
Leyenda: MB = Muy bajo; B = Bajo; N = Normal; A = Alto;
MA = Muy alto; EA = Extremadamente alto.

# Atributos
Rango de calificaciones
Producto
MB B N A MA EA
1
Fiabilidad requerida del software.
0,75 0,88 1 1,15 1,4
2
Tamao de la base de datos.
0,94 1 1,08 1,16
3
Complejidad del producto.
0,7 0,85 1 1,15 1,3 1,65
06/02/2013

# Atributos
Hardware
MB B N A MA EA
4 Restricciones del rendimiento en
tiempo de ejecucin.
1 1,11 1,3 1,66
5 Restricciones de memoria.
1 1,06 1,21 1,56
6 Volatilidad del entorno de la mquina
virtual.
0,87 1 1,15 1,3
7 Tiempo de retorno requerido del
CPU.
0,87 1 1,07 1,15
Personal MB B N A MA EA
8 Capacidad de anlisis.
1,46 1,19 1 0,86 0,71
9 Capacidad en ingeniera de
software.
1,42 1,17 1 0,86 0,7
06/02/2013

# Atributos
Personal MB B N A MA EA
10 Experiencia en aplicaciones.
1,29 1,13 1 0,86 0,71
11 Experiencia en mquina virtual.
1,21 1,10 1 0,9
12 Experiencia en lenguajes de
programacin.
1,21 1,07 1 0,91 0,82
Proyecto
MB B N A MA EA
13 Utilizacin de herramientas de
software.
1,24 1,10 1 0,91 0,82
14 Aplicacin de mtodos de ingeniera
de software.
1,24 1,10 1 0,91 0,83
15 Planificacin temporal del desarrollo
requerido.
1,23 1,08 1 1,04 1,10
06/02/2013

Estos factores pueden tomarse parcialmente o en su
totalidad. De manera que PM y TDP pueden variar
segn el factor o factores que intervengan.
Para calcular los valores nominales de PM y TDP
usaremos las frmulas:
PM

= a * (KLDC ^ b)
TDP = c * (PM
I
^ d)
donde:

Programas a B c d
Aplicacin 3,2 1,05 2,5 0,38
Apoyo 3 1,12 2,5 0,35
Sistema 2,8 1,2 2,5 0,32
06/02/2013
Y se calcula PM
I
y TDP
I
afectados por el factor

de
ajuste

o los factores de ajuste:
PM
I
= a * (KLDC ^ b) *
TDP
I
= c * (PM
I
^ d)
donde el productorio puede tomar valores de ajuste
entre 1 a 15.
Ejemplo:
Retomamos el caso de Administracin de la mina
Luvina. Supongamos que KLDC es 3,5 . Supongamos que
el sueldo habitual de un tcnico desarrollador de software es
$ 900.
Daremos algunos casos de los FAE que van numerados
FAEi. Tambin puede usarse siglas especficas para cada
factor, por ejemplo:
FRQ = Fiabilidad Requerida del Software.
TBD = Tamao de Base de Datos. etc.
[
=
15
1 i
FAEi
06/02/2013
Los factores de ajuste que vamos a considerar son:
N Factor de ajuste Valor Rango
1 Fiabilidad requerida del software 1,15 Alto
2 Tamao de la base de datos 1,00 Normal
3 Complejidad del producto 0,85 Bajo
4 Restricciones de tiempo de ejecucin 1,11 Alto
5 Restricciones de almacenamiento principal 1,00 Normal
6 Volatilidad de la mquina virtual 1,00 Normal
7 Tiempo de respuesta de la computadora 0,87 Bajo
8 Capacidad del analista 0,86 Alto
9 Experiencia en la aplicacin 0,82 Muy alto
10 Capacidad de los programadores 0,70 Muy alto
06/02/2013
Continua

Por lo tanto el FAE queda calculado por
HFAE
i
= 1,15*1,00*1,11*1,00*1,00*1,07*0,86*0,82
*0,70*1,00*0,95*1,00*0,91*1,08 = 0,5350848
N Factor de ajuste Valor Rango
11 Experiencia en S.O. utilizado 1,00 Normal
12 Experiencia en el lenguaje de programacin 0,95 Alto
13 Prcticas en programas modernas 1,00 Normal
14 Utilizacin de herramientas software 0,91 Alto
15 Limitaciones de planificacin del proyecto 1,08 Bajo
06/02/2013
Ahora vamos a calcular los valores de PM, TDP, PP y CTP:
PM

= 3,2 * (KLDC ^1,05) = 3,2* (3,5^1,05) = 11,92 .
TDP = 2,5 * (PM

^ 0,38)= 2,5*(11,92^0,38) =6,41 meses.
PP = PM/TDP = 11,92/6,41 = 1,86
CTP =PP * Sueldo_promedio_personal = 1,86 * 1500 = 2790
$.
Y los valores con las estimaciones finales sern:
PM
I
= PM * UHS = 11,92*0,5351 = 6,38
TDP
I
= 2,5 * (PM
I
^ 0,38) = 2,5*(6,38^0,38) =5,05 m.
PP
I
= PM
I
/TDP
I
= 6,38/5,05 = 1,26
CTP
I
=PP
I
* Sueldo_promedio_personal = 1,26 * 1500 =
1890 $
Es decir se estima 6,38 PM; 5,05 meses y $ 1890 para
desarrollar el proyecto.
06/02/2013
COCOMO (Modelo Detallado)
Modelo detallado: Este modelo puede procesar
todas las caractersticas para construir una
estimacin. Introduce dos factores principales:
+ Multiplicadores de esfuerzo sensitivo a la fase:
Hay fases que se ven afectadas ms que otras por
los atributos. Este modelo proporciona un conjunto
de multiplicadores de esfuerzo por cada atributo.
Esto permite tambin para una mejor asignacin de
personal para cada fase del proyecto.
+ Jerarqua del producto a tres niveles: Se define
tres niveles de producto: Mdulo, subsistema y
sistema. La cuantificacin se realiza a nivel
apropiado, es decir aquel ms susceptible a la
variacin.
06/02/2013

Fase de desarrollo: El desarrollo del software
en 4 fases:
Fases % de PM % de TDP
Requerimientos /Planes 6% - 8% 10% - 40%
Diseo del producto 16% -18% 19% - 38%
Programacin 48% - 68% 24% - 64%
Prueba /Integracin 16% - 34% 18% - 34%
06/02/2013

Principio de estimacin de esfuerzo:
+ Tamao equivalente: El factor de ajuste A se estima
partes del Diseo (D), de cdigo (C) y de integracin
(I):
A = 0,4D + 0,3C + 0,3I
El tamao equivalente se calcula
KLDC
Equ
= A(KLDC)/100
+ Calculo del esfuerzo: El tamao equivalente se
calcula por cada mdulo. El esfuerzo asignada a cada
mdulo se obtiene a travs de:
- Seleccionar los valores apropiados de los atributo de costo
de cada fase.
- Multiplicar los atributos de costo para cada mdulo y fase.
- Multiplicar los atributos globales por esfuerzo nominal de
cada fase y sumarlos para obtener el esfuerzo total estimado.

06/02/2013
COCOMO: Pasos
4 Los pasos a seguir son los siguientes:
1. Identificar todos los subsistemas y los mdulos del
producto.
2. Estimar el tamao de cada modulo y calcular el tamao de
cada subsistema y del sistema (Utilizando el KLDC
esperado sobre la base de proyectos anteriores similares).
3. Especificar los factores de ajuste para cada mdulo:
E Capacidad del programador
E Complejidad del producto
E Tamao del producto
E Tiempo disponible
E Complejidad requerida
E Nivel tecnolgico
06/02/2013
COCOMO: Pasos

4. Calcular el esfuerzo (PM) para cada mdulo y el TDP con el
COCOMO bsico. Usar las frmulas dadas y describir los
factores relacionados con cada mdulo.
5. Especificar los otros factores de ajuste de cada subsistema.
6. De los pasos 4 y 5 calcular el esfuerzo (PM) y el TDP para
cada subsistema con el COCOMO intermedio.
7. Del paso 6 calcular PM y TDP para el sistema.
8. Calcular los costos de personal en el proyecto.
9. Sumar los otros ingredientes al costo del desarrollo como la
planificacin, el anlisis, programacin y pruebas que no se
han incluidos antes.
10. Comprobar la estimacin a partir de la tcnica DELPHI con las
otras estimaciones.
06/02/2013
El modelo SLIM de Putnam
4 SLIM (Software Lifecycle Model) (Modelo del ciclo de
vida del software) fue desarrollado por Larry Putnam en
1979. La estimacin de SLIM se basa en lneas de
cdigo fuente, la estimacin inicial del tamao del
proyecto se modifica mediante el modelo de la curva de
Rayleigh para estimar el esfuerzo.
4 El modelo se obtuvo a partir de la experiencia de
distribucin de mano de obra en grandes proyectos (Se
obtuvo con los datos obtenidos de ms de 200 proyectos
con 1200 personas: entre 20 y 1000 personas -ao). Sin
embargo se puede extrapolar para proyectos pequeos.
06/02/2013
4 La ecuacin del software
La ecuacin del software que describe SLIM es un
modelo multivariante dinmico que distribuye el esfuerzo
a lo largo de la vida de un proyecto. El modelo se ha
obtenido a partir de los datos de unos 4000 proyectos de
software:

donde:
t
B
E
P LDC
3
4
3
1
* *
|
.
|
\
|
=
06/02/2013
P (parmetro de productividad): se obtiene por
calibracin con datos histricos de un proyecto.
E (esfuerzo): en hombres-ao.
t (tiempo): duracin del proyecto en aos.
B (parmetro de habilidad): depende del tamao del
producto (ver tabla).

El factor de habilidad B en
funcin del tamao del sistema
Tamao B
5-15K 0,16
20K 0,18
30K 0,28
40K 0,34
50K 0,37
> 70K 0,39
06/02/2013
4 Ejemplo: Supongamos que tenemos un programa de
aplicacin codificado en C++ con 25000 LDC, realizado
en 18 meses y con un esfuerzo de 156 personas-mes.
Estimar el parmetro de habilidad:

3925 , 11185
3925363 , 11185
25000
5 , 1
23 , 0
13
3
4
3
1
3
4
3
1
=
= = =
|
.
|
\
|
|
.
|
\
|
t
B
E
LDC
P
06/02/2013
4 ndice de productividad
El ndice de productividad (IP) es una escala de enteros
asociada a los valores del P obtenidos para bases de
datos. Este IP se comporta exponencialmente (ver tabla).
El rango de los 10 tipos de aplicaciones oscila entre 2 y
16.
En el rango IP:
Los valores bajos estn asociados a: entornos primitivos,
herramientas pobres, personal poco preparado, poca gestin y
direccin dbil, mtodos poco efectivos, productos muy
complejos.
Los valores altos estn asociados buenos entornos, personal
experimentado, productos poco complejos.
06/02/2013
4 Algunos valores de Parmetro de productividad (P) y
el ndice de productividad (IP) :
ndice de
productividad (IP)
Productividad
(P)
Tipo de aplicacin
1 754
2 987 Para pequeos programas.
3 1220
4 1597 Para programas grabados en la ROM
5 1974 Software empotrado de tiempo real.
6 2584
7 3194 Sistema de radar.
8 4181 Comandos y controles.
9 5186 Procesos de control
10 6756
06/02/2013
4 Continua
ndice de
productividad (IP)
Productividad
(P)
Tipo de aplicacin
11 8362 Telecomunicaciones.
12 10946
13 13530 Software de sistemas / cientfico.
14 17711
15 21892
16 28680 Sistemas de negocios
17 35422
18 46368
19 57314
20 75025
06/02/2013
4 Clculo e interpretacin de IP
Ejemplo: Calcular IP para un sistema de
abastecimientos con los datos siguientes:
Tamao = 25000 LDC B = 0,23 (tabla) Tiempo = 18 meses (1,5
ao) Esfuerzo = 72 permes (6 perao)

P = 11185,3925 entonces IP=13 (tabla de la pgina 961)
3925 , 11185
25000
5 , 1
23 , 0
13
3
4
3
1
= =
|
.
|
\
|
P
06/02/2013
4 En general se recomienda tomar los siguientes valores
para P:
6,500 para un medio ambiente de desarrollo pobre (no
hay mtodo, documentacin insuficiente, revisiones y
ejecuciones en modo de proceso por lotes.
10,000 para un buen medio de desarrollo (buen
mtodo. Documentaciones y revisiones apropiadas,
modo interactivo.
12,500 para medio ambiente excelente (herramientas
y tcnicas automatizadas).

06/02/2013
SLIM: Estimaciones deducidas
de la ecuacin del software
4 Putnam y Myers sugieren frmulas deducidas de la
ecuacin del software para estimar el tiempo mnimo y el
esfuerzo mximo en aos y meses:
4 Tiempo mnimo:

meses
aos
P
LDC
t
P
LDC
t
|
.
|
\
|
|
.
|
\
|
=
=
43 , 0
min
43 , 0
min
14 , 8
68 , 0
06/02/2013
4 Esfuerzo mximo:

mes personas B
ao personas B
t E
t E
=
=
3
max
3
max
180
15
06/02/2013
4 Ejemplo: Estimar el tiempo mnimo y el esfuerzo
mximo para un programa de sistemas con 25000 LDC.

4 El valor P = 13530 se ha tomado de la tabla respectiva
(pag. 958)

meses meses
aos aos
P
LDC
t
P
LDC
t
6 , 10 14 , 8 14 , 8
885 , 0 68 , 0 68 , 0
13530
25000
13530
25000
43 , 0 43 , 0
min
43 , 0 43 , 0
min
= = =
= = =
|
.
|
\
|
|
.
|
\
|
|
.
|
\
|
|
.
|
\
|
06/02/2013
4 Y el esfuerzo es:

4 El valor B = O,23 se ha obtenido por interpolacin en la
tabla respectiva (pag. 958)

mes personas B
ao personas B
t E
t E
= = =
= = =
696 , 28 * 23 , 0 * 180 180
39 , 2 * 23 , 0 * 15 15
885 , 0
885 , 0
3
3
max
3
3
max
06/02/2013
SLIM: La curva de Rayleigh
4 La cantidad de personal requerido a travs del ciclo de
vida de un proyecto no es constante: en la planeacin y
el anlisis el grupo es pequeo; en el diseo
arquitectnico es algo mayor; en el diseo detallado el
grupo se hace grande; en el mantenimiento al inicio
puede requerir un grupo grande y luego disminuir. Ver
grfico.

Especificacin
de requisitos
Diseo y
Codificacin
Prueba y
Validacin
Mantenimiento
Gestin
06/02/2013
4 La curva de Rayleigh est dado por la frmula:

donde
E:=Esfuerzo por unidad de tiempo.
PM:= Personas mes (rea bajo la curva).
t:= Tiempo del proyecto.
t
d
:= Tiempo en donde la curva alcanza su mximo
valor.

( )
e
t
t
t
t PM
E
d
d
2
2
2
=
06/02/2013
4 La curva de Rayleigh toma la forma:

Curva de Rayleigh
0
2
4
6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Tiempo
E
s
f
u
e
r
z
o
Esf uerzo
( )
e
t
t
d
t
d
t PM
E
2
2
2
=
06/02/2013
4 Nordem inform que los proyectos de software siguen el
ciclo de vida y demostr que la suma de las reas bajo
las curvas puede aproximarse a la curva de Rayleigh
como se muestra en la figura:

Especificacin de
requisitos
Diseo y
Codificaci
n
Prueba y
Validacin
Mantenimient
o
Gestin
Acumulacin del
proyecto
t
d
06/02/2013
4 Boehm seala que la curva de Rayleigh es un buen estimador de los
requisitos de personal a tiempo completo para el ciclo de vida de
desarrollo desde el diseo arquitectnico hasta las pruebas del
sistema siempre y cuando s use la porcin de curva entre 0,3t
d
y
1,7t
d
. La ecuacin de Rayleigh toma la forma:

donde
PTC:= Personal a tiempo completo.
PM:= Personas mes (rea bajo la curva).
TDP:= Tiempo de desarrollo del proyecto.
t:= Tiempo del proyecto en meses.

( )
( )
e
TDP
TDP
0,5
t TDP
t TDP
PM PTC
|
.
|
\
|
+
|
|
.
|
\
|
+
=
2
2
7 , 0 15 , 0
25 , 0
7 , 0 15 , 0
2
06/02/2013
4 Grfica de la curva de Rayleigh para un proyecto de
45 KLDC con 130,64 PM y 16 meses de duracin:

Curva de Rayleigh
0
5
10
15
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Tiempo (Meses)
P
T
C
PTC
( )
( )
e
TDP
TDP
0,5
t TDP
t TDP
PM PTC
|
.
|
\
|
+
|
|
.
|
\
|
+
=
2
2
7 , 0 15 , 0
25 , 0
7 , 0 15 , 0
2
06/02/2013
Comparando modelos
4 Cada modelo tiene, como se ha visto, ventajas y
desventajas.
4 La estimacin debe basarse en varios modelos.
4 Entre los modelos matemticos para estimar el costo y el
esfuerzo propuestos por Boehm (COCOMO), Albrecht
(Punto Funcin) y Putnam (SLIM) los 2 primeros son
estticos y el ltimo es dinmico.
4 Si el resultado de aplicar varios modelos difiere mucho,
significa que no se tiene suficiente informacin.
4 Muchas veces el modelo Pricing to win es el nico
aplicable.
4 Hay que afinar y mejorar modelos y ecuaciones,
consultando con expertos a travs de los resultados
previos obtenidos.
06/02/2013
Mtricas
Orientadas a
Objetos
06/02/2013
El paradigma orientado a
objetos
4El paradigma orientado a objetos tiene sus propias
caractersticas; en consecuencia las mtricas aplicadas en
otros paradigmas como el de la programacin estructurada
pueden no ser vlidas para la orientacin a objetos.
4Aparecen entonces nuevas mtricas que pretenden
adecuarse a las nuevas caractersticas del software como el
encapsulamiento, ocultamiento de informacin, abstraccin,
polimorfismo, reutilizacin, etc.
4El paradigma OO tiene beneficios como:
Desarrollo ms rpido.
Reutilizacin del trabajo anterior.
Arquitectura modular.
Gestin de complejidad en proyectos de gran tamao.
06/02/2013
Caractersticas del software
orientado a objetos
4Las caractersticas (Rumbaugh , Henderson - Sellers) orientado
a objetos son:
Objetos: Los datos se organizan entidades descritos
llamadas objetos que tienen 3 propiedades fundamentales:
EEstado: Est definido por los atributos y los valores que estos
toman.
EComportamiento: Est definido por los mtodos que activan
al objeto.
EIdentidad: Cada objeto tiene su propia identidad que lo
distingue de otro, aunque tengan los mismo estado y
comportamiento.
Clases: Es una abstraccin que describe propiedades
(estado y comportamiento) relevantes de un conjunto de
datos para una determinada aplicacin.
Clasificacin: Los objetos con las mismos atributos
(estado) y comportamiento se agrupan en clases.

06/02/2013
orientado a objetos
Polimorfismo: Permite que una operacin pueda ejecutarse de
forma diferente en clases diferentes. Estado: Est definido por los
atributos y los valores que estos toman.
EUna operacin es una accin o transformacin que acta sobre
los datos de un objeto.
EUn mtodo es la implementacin especfica de una operacin en
una clase.
Herencia: Es un mecanismo que permite compartir atributos y
operaciones de una subclase de una clase de la cual hereda ciertas
propiedades y aade otras definiendo una jerarqua entre clases.
Reutilizacin: Es un mecanismo que permite reutilizar diseo y
cdigo basado en la herencia. Esta es una de las ventajas de la
orientacin a objetos.
Abstraccin: Una clase abstracta es aquella que no tiene objetos
directos pero cuyas clases descendientes (clases concretas) si
pueden tener objetos directos. Una clase abstracta contienen
caractersticas comunes a muchas clases. Est relacionada con la
herencia.

06/02/2013
orientado a objetos
Encapsulamiento: Inclusin dentro de un mismo objeto del estado
(atributos y sus valores) y comportamiento (mtodos y acceso al
estado). Se usa el objeto con una interfaz bien definida y el resto del
objeto queda protegido por el estar encapsulado dentro del objeto.
Ocultamiento de informacin: Consiste en no mostrar detalles de la
implementacin de las rutinas a los elementos del programa
exteriores al objeto. Esto permite realizar cambios en la
implementacin (que no impliquen cambios en la funcionalidad) sin
afectar a las clases cliente.
Cohesin: Un objeto tiene un alto nivel de cohesin si ejecuta una
tarea sencilla y requiere poca interaccin con mtodos que se
ejecutan con otros objetos. Es una extensin del ocultamiento de
informacin. Un objeto coherente tericamente debe hacer una sola
cosa.
Acoplamiento: Es una medida de interaccin entre objetos. Indica en
qu medida una clase utiliza mtodos y/o atributos de otra.

06/02/2013
orientado a objetos
4Jerarqua de las propiedades de los objetos (Schach)
Objetos con alta cohesin y bajo acoplamiento
Objetos
Ocultamiento de informacin
Tipos abstractos de datos
Encapsulamiento de datos
Mdulos con alta cohesin y bajo acoplamiento
Mdulos
06/02/2013
Mtricas orientadas a
Objetos
4Los objetivos primarios para las
MOO son similares a otras del
software convencional:
Para entender mejor la calidad dl
software.
Para evaluar la efectividad del proceso.
Para mejorar la calidad del trabajo
llevado a cabo al nivel del proyecto.
06/02/2013
Objetos
4Berard define 5 caractersticas que regulan las MOO:
Localizacin: indica la manera en que la informacin
se concentra en un programa. Las mtricas deben
aplicarse a la clase (objeto) como a una entidad
completa.
Encapsulamiento: empaquetamiento de una
coleccin de objetos. Influye en las mtricas
cambiando el enfoque de las mediciones de un
mdulo simple a un paquete de datos (atributos) y
mdulos de procedimientos (operaciones).
Ocultamiento de informacin: oculta los detalles
operacionales de un componente de un programa.
Por esa razn las mtricas que indican el grado de
ocultamiento logrado dan un indicio de calidad del
software.

06/02/2013
Objetos
Herencia: es un mecanismo que habilita
responsabilidades de un objeto para propagarse a
otros. Las mtricas referentes a ellas son de mucha
importancia.
Tcnicas de abstraccin de objetos: es un
mecanismo que permite concentrarse en los detalles
esenciales de un componente del programa. Las
mtricas OO representan abstracciones en trminos
de medicin de una clase.
06/02/2013
Perspectiva tridimensional
de las MOO
4Las MOO pueden verse desde las 3
dimensiones siguientes:
Caracterstica o atributo del software a
medir (cohesin, complejidad,
reutilizacin, etc.)
Etapa del ciclo de vida en que se mide
(anlisis, diseo, implementacin,
pruebas, etc.)
Nivel de granularidad en la que se
mide (nivel de sistema, de programa, de
clase, de mtodo o de variable).
06/02/2013
Mtricas OO
4Chidamber y Kemerer (1994)
establecen 6 mtricas para medir 5
atributos bsicos en el diseo
orientado a objetos:
Acoplamiento,
Complejidad,
Reutilizacin,
Cohesin,
Herencia y
Tamao.
06/02/2013
Acoplamiento
4El acoplamiento se ve como una medida del incremento
de la complejidad, reduciendo el encapsulamiento y su
posible reutilizacin, limita por lo tanto la facilidad de
comprensin y mantenimiento del programa.
Acoplamiento entre objetos CBO (Coupling Between
Objects):
CBO de una clase es el nmero de clases a las cuales est ligada
una clase sin tener con ella relaciones de herencia.
Valoracin: los autores sugieren que sea un indicador del esfuerzo
necesario para el mantenimiento y las pruebas.
Nivel de granularidad: clase, programa, sistema.
Ciclo de vida: diseo.
Proporcin de acoplamiento COF (Coupling Factor):
COF: es la proporcin entre el nmero real de acoplamientos no
imputables a la herencia y el mximo nmero posible de
acoplamientos en el sistema, es decir, indica la comunicacin
entre clases.

06/02/2013
Acoplamiento
4Formula:

4La relacin cliente / servidor (C
C
C
S
) , significa que la
C
C
(clase cliente) contiene al menos una referencia no
basada en la herencia una caracterstica a la clase C
S

(clase servidor).
06/02/2013
Acoplamiento
4La relaciones cliente / servidor pueden tener distintas formas:
Paso de mensajes regular.
Paso de mensajes forzado.
Iniciacin y destruccin de objetos.
Asociaciones semnticas entre clases ( 1:1, 1:n, n:m).
4Valoracin: COF puede ser una medida indirecta de los
atributos con los cuales est relacionado: complejidad, falta
de encapsulamiento, carencia de reutilizacin, facilidad de
comprensin, poca facilidad de mantenimiento. Al
incrementar el acoplamiento entre clases, se incrementa la
densidad de defectos, y disminuye la facilidad de
mantenimiento.
4Nivel de granularidad: clase, programa, sistema.
4Ciclo de vida: diseo.
4Relacionado con: complejidad, encapsulamiento,
reutilizacin.

06/02/2013
Cohesin
4Falta de cohesin en los mtodos LCOM (Lack of
Cohesion in Methods):
LCOM es el nmero de grupos de mtodos
locales que no acceden a atributos comunes.
Valoracin: indica la calidad de la abstraccin
hecha en la clase. Usa el concepto de grado de
similitud de mtodos. Si no hay atributos comunes
el grado de similitud es 0. Una baja cohesin
incrementa la complejidad y por lo tanto la
facilidad de cometer errores durante el proceso de
desarrollo. Estas clases podran ser divididas en 2
o ms subclases aumentado la cohesin de las
clases resultantes.
Nivel de granularidad: clase.
Ciclo de vida: diseo, implementacin.
06/02/2013
Complejidad
4Respuesta para una clase RFC (Response For a
Class):
RFC es el cardinal del conjunto de todos los mtodos que se
pueden invocar como respuesta a un mensaje, a un objeto
de la clase o como respuesta a un mtodo de la clase. Esto
incluye a todos los mtodos accesibles dentro de la jerarqua
de la clase. RFC es el nmero de mtodos locales a una
clase ms el nmero de mtodos llamados por los mtodos
locales.
Valoracin: RFC es una medida de la complejidad de una
clase a travs del nmero de mtodos y de su comunicacin
con otras, pues incluye los mtodos llamados desde fuera de
la clase. Cuanto mayor es RFC, ms complejidad tiene el
sistema, ya que es posible invocar ms mtodos como
respuesta a un mensaje, exigiendo mayor nivel de
comprensin, que implica mayor esfuerzo y tiempo de
prueba y depuracin.
Relacionado con: acoplamiento.
06/02/2013
Complejidad
4Mtodos ponderados por clase WMC (Wheigted
Methods per Class):
WMC. Def.- Dada una clase C
i
con los mtodos M
1
,
M
2
,,M
n
y c
1
, c
2
,,c
n
la complejidad de los mtodos,
WMC se define como la sumatoria de todas las
complejidades de cada mtodo de una clase. Si todos
los mtodos son considerados de la misma
complejidad, entonces c
i
= 1 y WMC = n (nmero de
mtodos)
Valoracin: Describe la complejidad algortmica de
una clase en trminos de las complejidades de todos
sus mtodos. Est ligada a la calidad de la definicin
de la complejidad de un mtodo. Puede servir como un
indicador de que una determinada clase necesita una
descomposicin adicional en varias clases.

06/02/2013
Complejidad
4Complejidad ciclomtica media v(G):
Def.- Es la complejidad ciclomtica media de los
mtodos de una clase. La complejidad ciclomtica
media v(G) de un mtodo es el nmero de
caminos independientes a lo largo del mtodo. En
los mtodos estructurados, v(G) es el nmero de
nodos de decisin ms 1.
Valoracin: Se ofrece como una medida de la
complejidad estructural. Una medida que se
concentra en los mtodos ms complejos es la
complejidad ciclomtica mxima (Maximum v(G)).
Es un indicador til de la dificultad de prueba y
mantenimiento de un programa. Se sugiere un
valor mximo de 10.
Ciclo de vida: implementacin.

06/02/2013
Encapsulamiento
4Proporcin de mtodos MHF (Method Hiding
Factor):
Def.- Es la proporcin entre la suma de los grados de
invisibilidad de los mtodos en todas las clases, y el
nmero total de los mtodos definidos en el sistema. El
grado de invisibilidad de un mtodo es el porcentaje sobre
el nmero total de clases desde las cuales un mtodo no es
visible. Es decir, MHF es la proporcin entre los mtodos
definidos como protegidos o privados y el numero total de
mtodos.
Formula:

06/02/2013
Encapsulamiento
Valoracin: MHF se propone como una medida de
encapsulamiento, cantidad relativa de informacin oculta.
Cuando se incrementa MHF, la densidad de los defectos y el
esfuerzo necesario para corregirlos debera disminuir. No se
consideran los mtodos heredados.

06/02/2013
Encapsulamiento
4Proporcin de atributos ocultos AHF (Attribute
Hiding Factor):
Def.- Es la proporcin entre la suma de los grados de
invisibilidad de los atributos en todas las clases, y el
nmero total de los atributos definidos en el sistema. El
grado de invisibilidad de un atributo es el porcentaje sobre
el nmero total de clases desde las cuales un atributo no es
visible. Es decir, MHF es la proporcin entre los atributos
definidos como protegidos o privados y el numero total de
atributos.
Formula:

06/02/2013
Encapsulamiento
4Valoracin: Idealmente el valor de esta mtrica siempre
debera valer 100%, intentando ocultar todos los atributos.
Las pautas del diseo sugieren que no hay que emplear
atributos pblicos, ya que se considera que esto viola los
principios de encapsulamiento al exponer la implementacin
de las clases.
4Nivel de granularidad: clase.
4Ciclo de vida: implementacin.
06/02/2013
Herencia
4El uso de la herencia debe entenderse
como un compromiso entre la facilidad de
reutilizacin y la facilidad de comprensin y
mantenimiento del sistema, que en general
estn a la inversa.
Altos niveles de herencia indican objetos
complejos, los cuales pueden ser difciles de
probar y reutilizar.
Bajos niveles de herencia pueden sealar que el
cdigo est escrito en un estilo funcional, sin
aprovechar el mecanismo de herencia
proporcionado por la orientacin a objetos.
06/02/2013
Herencia
4Proporcin de mtodos heredados MIF (Method
Inheritance Factor):
MIF es la proporcin entre la suma de los mtodos
heredados en todas las clases, y el nmero total de los
mtodos (localmente definidos ms los heredados) en todas
las clases.
Formula:

06/02/2013
Herencia
4Valoracin: MIF es un indicador del
nivel de reutilizacin. Tambin se
propone como ayuda para evaluar la
cantidad de recursos necesarios a la
hora de probar.
4Nivel de granularidad: clase,
programa, sistema.
4Ciclo de vida: implementacin.
4 Relacionado con: reutilizacin.
06/02/2013
Herencia
4Proporcin de atributos heredados AIF (Method
Inheritance Factor):
MIF es la proporcin entre el nmero de atributos
heredados y el nmero total de atributos.
Formula:

06/02/2013
Herencia
4Valoracin: AIF es un indicador de
la capacidad de reutilizacin en un
sistema al igual que MIF.
4Nivel de granularidad: clase,
programa, sistema.
4Ciclo de vida: diseo,
implementacin.
4 Relacionado con: reutilizacin.
06/02/2013
Herencia
4ndice de especializacin por clase SIX
(Specialisation Index per Class):
SIX muestra en que medida las subclases redefinen erl
comportamiento de sus superclases.
Formula:

Valoracin: Esta frmula pondera ms las redefiniciones
que ocurren en los niveles ms profundos del rbol la
herencia, ya que, cuanto ms especializada es una clase,
menos probabilidad existe que su comportamiento sea
reemplazado. SIX se propone como medida de calidad en
la herencia.

06/02/2013
Herencia
4Profundidad del rbol de herencia DIT (Depth of
Inheritance Tree):
DIT mide el mximo nivel de jerarqua de herencia.
Se trata de la cuenta directa de los niveles de
jerarqua en la herencia. En el nivel 0 de la jerarqua
se halla la clase raz.
Valoracin: Chidamber y Kemerer proponen el DIT
como medida de complejidad de una clase, la
complejidad del diseo, y la reutilizacin potencial, lo
que se debe a que cuanto ms profunda se encuentre
una clase en la jerarqua. Mayor es la probabilidad de
heredar mtodos, . Esta es una medida de cuntos
ancestros pueden afectar a una clase. Las diferentes
caractersticas de la herencia pueden afectar y
dificultar la claridad de esta mtrica,

06/02/2013
Polimorfismo
4Proporcin de polimorfismo POF (Polimorphism
Factor):
POF es la proporcin entre el nmero real de posibles
situaciones polimorfas para una clase C
i
, y e mximo
nmero posible de situaciones polimorfas en C
i
. Es decir, es
el nmero mximo de mtodos heredados redefinidos
dividido entre el mximo nmero de situaciones polimorfas
distintas posibles.
Formula:

06/02/2013
Polimorfismo
4El numerador representa el nmero de
mtodos heredados redefinidos. El
denominador representa el mximo
nmero de situaciones polimorfas
distintas de la clase C
i
.
Valoracin: POF es una medida del
polimorfismo y una medida indirecta de la
asociacin dinmica de un sistema. El
polimorfismo se debe a la herencia.
Ciclo de vida: diseo, implementacin.
Relacionado con: herencia.
06/02/2013
Reutilizacin
4Nmero de hijos NOC (Number of
Children):
NOC es el nmero de clases subordinadas a una clase
en la jerarqua, es decir, la cantidad de subclases que
pertenecen a una clase.
Valoracin: Es un indicador del nivel de reutilizacin, la
posibilidad de haber creado abstracciones errneas, y
es un indicador del nivel de pruebas requerido. Un
mayor nmero de hijos, requiere un ms pruebas de los
mtodos de esa clase y mayor dificultad para modificar
una clase pues afecta a todas las hijas de la clase. Es un
potencial indicador de la influencia ejercida por una clase
al diseo.

06/02/2013
Tamao
4Lneas de cdigo LOC (Lines of Code
per Method):
LOC es el nmero de lneas activas de cdigo
(lneas ejecutables) en un mtodo.
Valoracin: El tamao de un mtodos se
emplea para evaluar la facilidad de comprensin,
la capacidad de reutilizacin, y y la facilidad de
mantenimiento del cdigo. Depende del lenguaje
de programacin y de la complejidad del mtodo.
No es recomendada Para OO.
Nivel de granularidad: mtodo, clase,
programa, sistema.

06/02/2013
Tamao
4Nmero de mensajes enviados NOM (Number of
Messages):
NOM mide el nmero de mensajes enviados en
un mtodo, segregados por el tipo de mensajes.
Los tipos incluyen:
Unarios: mensajes sin argumentos.
Binarios: mensajes con un argumento que pertenecen
a tipos especiales.
Clave: mensaje con uno o ms argumentos.
Valoracin: NOM cuantifica el tamao de un
mtodo de una manera relativamente no
sesgada. Un alto valor puede indicar un estilo
funcional y/o una coleccin pobre de
responsabilidades.
Nivel de granularidad: mtodo.

06/02/2013
Mtricas giles
06/02/2013
Mtricas giles
4Aunque las mtodos giles por lo general afirman que el uso
de las mtricas no tiene sentido puesto que se basan en la
predictibilidad y en la planificacin, algunos de los mtodos
giles como Scrum propician el uso de ciertas mtricas:
4Xavier Albaladejo plantea que La mtrica ms importante
en un proyecto gil como Scrum es el valor que se est
dando al cliente. Mediante esta mtrica, el cliente puede
conocer la velocidad con que retorna su inversin y
saber cundo ya no es necesario seguir con el proyecto,
por que los beneficios pendientes de obtener ya no
compensan sus costes.
4Pero advierte que dar demasiado nfasis a las personas o
equipos y centrase slo en ello puede hace que se descuide
otros aspectos como la calidad, los costos, los riesgos y la
sostenibilidad de la velocidad con que se logran los objetivos.
06/02/2013
Mtricas giles
06/02/2013
Mtricas giles del cuadro de
mandos
4 La mayora de las mtricas ms importantes derivan de las
herramientas propias de Scrum:
+Lista de requisitos priorizada
+Lista de tareas de la iteracin
+Grficos de trabajo pendiente
+Retrospectiva de iteracin
4 En las gestiones giles carecen de sentido algunas mtricas
propias de paradigmas tradicionales, por ejemplo:
+Porcentaje de completitud de un objetivo o requisito: en un
proyecto gil, para poder determinar cuando se completa
un requisito o entrega se utiliza concepto de esfuerzo
pendiente, as como qu objetivos estn completados o
cules no (al cliente no le interesan los que estn en curso
ya que no puede hacer uso de ellos)
+Diagramas de Gantt: no aportan ms informacin que la que
aportan las herramientas propias de Scrum.

06/02/2013
mandos
+Lista de requisitos priorizada:
La lista de objetivos/requisitos priorizada representa la visin y
expectativas del cliente respecto a los objetivos y entregas del
producto o proyecto. El cliente es el responsable de crear y gestionar
la lista (con la ayuda del Facilitador y del equipo, quien proporciona el
coste estimado de completar cada requisito). Dado que reflejar las
expectativas del cliente, esta lista permite involucrarle en la direccin
de los resultados del producto o proyecto.
Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que
se suelen expresar en forma de historias de usuario. Para cada
objetivo/requisito se indica el valor que aporta al cliente y el coste
estimado de completarlo.
En la lista se indican las posibles iteraciones y las entregas (releases)
esperadas por el cliente (los puntos en los cuales desea que se le
entreguen los objetivos/requisitos completados hasta ese momento), en
funcin de la velocidad de desarrollo del (los) equipo(s) que trabajar(n) en
el proyecto.
La lista tambin tiene que considerar los riesgos del proyecto e incluir los
requisitos o tareas necesarios para mitigarlos.

06/02/2013
La lista de objetivos/requisitos
priorizada
06/02/2013
mandos
+Lista de tareas de la iteracin:
Lista de tareas que el equipo elabora en la reunin
de planificacin de la iteracin (Sprint planning) como
plan para completar los objetivos/requisitos
seleccionados para la iteracin y que se compromete
a demostrar al cliente al finalizar la iteracin, en forma
de incremento de producto preparado para ser
entregado.
Esta lista permite ver las tareas donde el equipo est
teniendo problemas y no avanza, con lo que le permite
tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran
sus tareas, el esfuerzo pendiente para finalizarlas y la
autoasignacin que han hecho los miembros del
equipo.

06/02/2013
La lista de tareas de la iteracin
06/02/2013
mandos
+Grficos de trabajo pendiente:
Un grfico de trabajo pendiente a lo largo del tiempo muestra la
velocidad a la que se est completando los
objetivos/requisitos. Permite extrapolar si el Equipo podr
completar el trabajo en el tiempo estimado.
Se pueden utilizan los siguientes grficos de esfuerzo
pendiente:
Das pendientes para completar los requisitos del producto
o proyecto (product burndown chart), realizado a partir de la
lista de requisitos priorizada (Product Backlog).
Horas pendientes para completar las tareas de la iteracin
(sprint burndown chart), realizado a partir de la lista de
tareas de la iteracin (Iteration Backlog).
Este tipo de grfico permite realizar diversas simulaciones:
ver cmo se aplazan las fechas de entrega si se le aaden
requisitos, ver cmo se avanzan si se le quitan requisitos o
se aade otro equipo, etc.
06/02/2013
Grficos de trabajo pendiente
06/02/2013
mandos
+Retrospectiva de iteracin:
4Con el objetivo de mejorar de manera continua su
productividad, el equipo analiza cmo ha sido su manera de
trabajar durante la iteracin:
Qu cosas han funcionado bien.
Cuales hay que mejorar.
Qu cosas quiere probar hacer en la siguiente iteracin.
Qu ha aprendido.
4Cuales son los problemas que podran impedirle progresar
adecuadamente. El Facilitador se encargar de ir eliminando
los obstculos identificados que el propio equipo no pueda
resolver por s mismo.
06/02/2013
mandos
+Retrospectiva de iteracin:
4 Esta reunin se realiza despus de la reunin de demostracin al cliente
de los objetivos conseguidos en la iteracin, para poder incorporar su
feedback y cumplimiento de expectativas como parte de los temas a tratar
en la reunin de retrospectiva
4 Beneficios
Incrementa la productividad en el proyecto y el aprendizaje del equipo de
manera sistemtica, iteracin a iteracin, con resultados a corto plazo.
Aumenta la motivacin del equipo dado que participa en la mejora de proceso,
se siente escuchado, toma decisiones consensuadas (y ms sostenibles) para ir
eliminando lo que le molesta y le impide que sea ms productivo.
4 Restricciones
En necesario que el Equipo y el Facilitador dispongan de autoridad,
mecanismos y recursos para ir mejorando su forma de trabajar y el contexto
del proyecto. Es frustrante encontrar sistemticamente los mismos obstculos y
no poder solucionarlos.

06/02/2013
Mtricas de productividad y
efectividad de la entrega
4Velocidad con que se completan objetivos/requisitos
en cada iteracin (en funcin de su estimacin al inicio
de la iteracin). Permite ir extrapolando la fecha de
finalizacin del proyecto en funcin de cuando se vaya a
completar todo su alcance.
4Tiempo de entrega de un requisito tras su peticin
(responsividad a necesidades del cliente, Time to
Market, tiempo de servicio), en funcin del tipo del tipo
de requisito (urgente, etc.) y cumplimiento de los
Acuerdos de Nivel de Servicio (ANS / SLA).
4Urgencias y prioridad/valor de los requisitos
completados, para comprobar si existe desalineamiento
con los objetivos del proyecto y/o la estrategia de la
organizacin.
06/02/2013
Mtricas de resultados del
proyecto
4 Velocidad con que se aporta valor al negocio (desde el punto de
vista del cliente).
4 Valor acumulado.
4 Requisitos completados en la iteracin.
4 Prximos requisitos a desarrollar.
4 Cambios y requisitos aadidos sobre el alcance del proyecto.
4 Nmero de requisitos completados respecto al total de
requisitos (mtrica que tambin permite observar cambios de
alcance).
4 Das de trabajo ideales pendientes (mtrica que permite proyectar
la fecha de finalizacin del proyecto).
4 Desviacin de resultados de proyecto respecto a planificacin
inicial.

06/02/2013
Mtricas de situacin
financiera
4Retorno de Inversin (ROI) pendiente,
el valor pendiente respecto al coste
pendiente, para saber cundo finalizar el
proyecto
4Presupuesto disponible y/o presupuesto
gastado.
4Desviacin financiera respecto a la
planificacin inicial.
06/02/2013
Mtricas de calidad
4Expectativas:
Satisfaccin del cliente / usuario, respecto a los
resultados del proyecto y a la colaboracin con el
equipo.
Ambiente en el equipo
4Calidad funcional:
Incidencias (defectos encontrados por el cliente o
usuarios del producto), por estado y por criticidad.
Errores (defectos detectados internamente, bugs),
por estado y por criticidad.
Cobertura de las pruebas.
Trazabilidad.
06/02/2013
Mtricas de calidad
4Mantenibilidad:
Cumplimiento de estndares de codificacin,
normativas, regulaciones, etc.
Comentarios en el cdigo.
Complejidad ciclomtica del producto.
Tamao de las operaciones.
4Calidad de la documentacin
Existencia y cobertura de la documentacin:
Funcional
Tcnica
De pruebas
De implantacin
Operativa
Etc.

06/02/2013
Mtricas de riesgos, impedimentos,
proceso y mejora continua
4Riesgos (severidad y mitigaciones) e impedimentos:
considerando las dependencias o sinergias con otros
equipos o proyectos, la implicacin del cliente, los problemas
tecnolgicos, el resultado de las retrospectivas, etc.
4Lecciones aprendidas.
4Actividades de mejora a planificar (comunicaciones,
formaciones, soporte, herramientas, etc.).
4Uso de prcticas especficas: nmero de integraciones,
tiempo de refactorizacin, de TDD, revisiones expertas, etc.
4Situaciones anmalas: sobreesfuerzo, requisitos no
completados, terminaciones anormales de iteracin,
interrupciones, sospechas de mala aplicacin del proceso
(por ejemplo, si el cliente se muestra sorprendido en la
demostracin de la iteracin), etc.
4% de personas que no intervienen en las reuniones
diarias de sincronizacin.
06/02/2013
Conclusiones sobre el estado del
proyecto
4 Este apartado debe contener un resumen con las mtricas
ms importantes y las relaciones entre ellas, as como las
lecciones aprendidas y prximas acciones de mejora (tras
un anlisis causal de problemas como, por ejemplo, el que
se realiza en una retrospectiva), de manera que el cliente
pueda tomar decisiones informadas y dirigir los resultados
del proyecto.
4 Hay que recordar que muchos de los problemas detectados
y disfuncionalidades de la organizacin ya estaban ah
antes de utilizar una gestin gil de proyectos como Scrum,
no son el resultado de aplicarla. La transparencia que
proporciona Scrum los hace ms visibles, lo cual ayuda a
priorizar y tomar decisiones (de manera conjunta con las
personas implicadas para consensuar la mejor solucin).
Para ello es necesario disponer del mximo apoyo de la
Direccin para alinear comportamientos, recursos y
resultados con la estratgia de la organizacin.
06/02/2013
Resumen
4Las mtricas del software proporcionan
una manera cuantitativa de valorar la
calidad de los atributos internos del
producto, permitiendo al ingeniero valorar
la calidad antes de construir el producto.
4Las mtricas proporcin la visin interna
necesaria crear modelos efectivos de
anlisis y diseo, un cdigo slido y
pruebas minuciosas.

06/02/2013
Resumen
4Aun estamos muy lejos de un sistema de
mtricas formales, que midan lo que
pretenden y sean aceptadas
universalmente.
4El problema de la crisis del software, se
extiende a las mtricas, y su origen es le
mismo: la complejidad del software y el
gran desconocimiento de los conceptos
formales que se les puede aplicar.

06/02/2013
Medir o no medir?
4Ante este panorama, solo queda decidir
si seguir adelante:
Medir (aunque no se pueda formalizar).
No medir.
4Esta claro que una medida equivocada
es ms peligrosa que la propia intuicin.
Slo queda utilizar el sentido comn y
utilizar las mtricas disponibles en forma
controlada y supervisada.

06/02/2013
Y entonces
4Las lneas de investigacin en mtricas
deberan comenzar por identificar propiedades
invariantes y claramente definidas en los
sistemas de software; estudiarlas
profundamente y con este conocimiento
intentar medirlas.
4Mientras tanto debe pensarse muy bien en qu
mtricas se desarrollan o inventan, y como
norma general, desconfiar de aquellas mtricas
que no somos capaces de definir o nombrar, y
de aquellas cuyos valores somos incapaces de
asignarles unidades.
06/02/2013
Bibliografa
4PRESSMAN, Roger S: Ingeniera del software.
4SOMMERVILLE, Ian: Ingeniera de software.
4THORIN, Marc: Ingeniera de software.
4FAIRLEY, Richard: Ingeniera de software.
06/02/2013
Programa
06/02/2013
Sbado 29
408:00-10:30: Exposicin 1: El Proceso
410:30-13:00: Taller 1: Requisitos y
Planificacin
415:00-17:00: Laboratorio 1: Requisitos
y Planificacin
417:00-19:00: Exposicin 2: Gestin de
Proyectos
419:00-21:00: Taller 2: Anlisis
06/02/2013
Domingo 30
408:00-10:30: Laboratorio 2: Anlisis
410:30-13:00: Exposicin 3: Mtricas
del software
415:00-17:00: Taller 3: Diseo
417:00-19:00: Laboratorio 3: Diseo y
Prototipo
Exposiciones a cargo del profesor
Talleres en grupo de 4 participantes
Prcticas en el laboratorio

06/02/2013

Curso de Métricas Del Software y Métodos Ágiles

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curso de Métricas Del Software y Métodos Ágiles

Încărcat de

Drepturi de autor:

Formate disponibile

Curso de Mtricas

S-ar putea să vă placă și