Procesos

giles
Introduccin (Modelos)
1959
MIL-Q 9858
1979
BS 5750
1987
ISO 9000
1997
TickIT
1991
ISO 9000-3
A
d
a
p
t
a
c
i
o
n
e
s

p
a
r
a

s
o
f
t
w
.

1995
ISO 12207
1995
Proy. SPICE
1993
CMM-SW
M
o
d
e
l
o
s

e
s
p
e
c

f
i
c
o
s

p
a
r
a

s
o
f
t
w
a
r
e
.

2003-05
ISO 15504
2001
CMMI
Modelos
CMM
TR 15504
M
o
d
e
l
o
s

y

e
s
t

n
d
a
r
e
s

d
e

c
a
l
i
d
a
d

Modelos genricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
AM
ISD
1995
2000
Manifiesto
gil
T

c
n
i
c
a
s

y

m

t
o
d
o
s

g
i
l
e
s

Por que Mtodos giles?
The CHAOS Report [1994]:
84% de proyectos fracasados
32 % de proyectos cancelados
52 % de proyectos fuera de presupuesto (189% mas)
16 % de proyectos exitosos
En tiempo y presupuesto, estos tienen solo 42% de la
funcionalidad originalmente pactada.
Introduccin
Contexto
Nandhakumar & Avison 1999
Metodologas tradicionales de desarrollo de sistemas de
informacin son tratadas principalmente como una ficcin
necesaria para presentar una imagen de control o para
proveer un estatus simblico.
Truex et al. 2000
Es posible que los mtodos tradicionales sean meramente
ideales inalcanzables y hipotticos straw-men que proveen
una gua normativa a situaciones de desarrollo utpicas.
McCauley 2001
La filosofa en la cual se basan los mtodos orientados a
procesos establece que los requerimientos de un proyecto
de software quedan congelados antes de que el diseo y
desarrollo del software comience.

Manifiesto gil
Estamos descubriendo mejores maneras de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A travs de esta experiencia hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software que funciona sobre documentacin exhaustiva
Colaboracin con el cliente sobre negociacin de
contratos
Responder ante el cambio sobre seguimiento de un plan

Esto es, aunque los elementos a la derecha tienen valor,
nosotros valoramos por encima de ellos los que estn a la
izquierda.

http://www.agilemanifesto.org
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y
ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin de los procesos y las herramientas por encima
El software que funciona de la documentacin exhaustiva por encima
La colaboracin con el cliente la negociacin contractual por encima
La respuesta al cambio seguimiento de un plan por encima
Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.
Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
(2001) http://agilemanifesto.org/
Manifiesto gil
Principios
Nuestra mayor prioridad es satisfacer al cliente a travs de la entrega
temprana y continua de software con valor.
Aceptamos requisitos cambiantes, incluso en etapas avanzadas.
Entregamos software frecuentemente.
Los responsables de negocio y los desarrolladores deben trabajar
juntos diariamente a lo largo del proyecto.
Construimos proyectos con profesionales motivados.
Conversacin cara a cara.
Software que funciona es la principal medida de progreso.
Los procesos giles promueven el desarrollo sostenible.
La atencin continua a la excelencia tcnica y los buenos diseos
mejoran la agilidad.
Simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de equipos que se
auto-organizan.
A intervalos regulares el equipo reflexiona sobre cmo ser ms
efectivo.

http://www.agilemanifesto.org/principles.html
Reflexiones
Highsmith & Cockburn 2001
lo que es nuevo en los procesos giles no
son las prcticas que usan, sino que
reconozcan a las personas como primeros
implicados en el xito de un proyecto,
adems de un intenso foco en la efectividad
y la manejabilidad. Esto genera una nueva
combinacin de valores y principios que
definen una visin gil del mundo.
Reflexiones (2)
Hawrysh & Ruprecht 2000
Una sola metodologa no puede funcionar para
todo el espectro de proyectos, en vez de eso el
administrador de cada proyecto debera
identificar la naturaleza especifica de cada
proyecto y seleccionar la mejor metodologa de
desarrollo aplicable.
McCauley 2001
Hay una necesidad de ambos mtodos [giles y
orientados a procesos] ya que no hay un modelo
de desarrollo que se ajuste a todos los
propsitos imaginables.
Cuando un mtodo es gil?
El desarrollo de software es
Incremental
liberaciones pequeas y ciclos rpidos.
Cooperativo
clientes y desarrolladores trabajando juntos.
Simple y Directo
el mtodo es fcil de aprender y modificar.
Adaptativo
es posible realizar cambios de ltimo momento.

AD - Agile Database Techniques
AM - Agile Modeling
ASD - Adaptive Software Development
AUP - Agile Unified Process
Crystal
DSDM - Dynamic Systems Development Method
FDD - Feature Driven Development
ISD - Internet Speed Development
Lean Software Development
OSS Open Souurce Software
PP - Pragmatic Programming
Scrum
TDD - Test-Driven Design
XBreed
XP - eXtreme Programming

Algunos Mtodos giles
Qu es?
Cundo y cmo surge?
Ciclo de vida.
Fases e hitos.

AUP
Es una versin simplificada del RUP
Aplica tcnicas giles:
TDD: test driven development
(TFD+refactoring)
AMDD: agile model driven development
Agile requirements change management
Database refactoring

AUP Qu es?
1988: Objectory 1.0
1998: RUP 5.0
Feb/2004: EUP
Sep/2005: AUP
13/5/2006: v1.1 AUP
Cundo surge? AUP
Scott W. Ambler
1999: Cmo extender RUP?
2001: Cmo agilizar RUP?
2002: Publica Agile Modeling book
AM vs XP
AM vs RUP
2004: EUP
2005: AUP

Cmo surge? AUP

Ciclo de Vida AUP
Inicio
Elaboracin
Construccin
Transicin

Ciclo de vida AUP
Objetivos: Identificar el alcance inicial
del proyecto, proveer una arquitectura
potencial para el sistema, y obtener un
financiamiento inicial del proyecto y la
aceptacin de los stakeholders.
Ciclo de vida: Inicio AUP
Objetivos: Probar la arquitectura del
sistema; hacer un prototipo de
arquitectura que elimine los riesgos
tcnicos para probar que el proyecto es
factible.
Ciclo de vida: Elaboracin AUP
Objetivos: De forma regular e
incremental, construir software que
funcione y satisfaga las necesidades de
mayor prioridad de los stakeholders del
proyecto.
Ciclo de vida: Construccin AUP
Objetivos: Validar e instalar el sistema en
el ambiente de produccin.


Ciclo de vida: Transicin AUP

Fases e hitos AUP
Elab. Cons. Tran.
Objetivos
del ciclo de
vida (LCO)
Inicio
Arquitectura
del ciclo de
vida (LCA)
Capacidad
operacional
inicial (IOC)
Lanzamiento
del producto
(PR)
Inicio
Definir alcance del
proyecto
Estimar costos y plazos
Definir riesgos
Determinar factibilidad
del proyecto
Preparar el ambiente

Fases e hitos AUP
Objetivos del ciclo de vida
(LCO)
Acuerdo del alcance
Def. inicial de reqs.
Acuerdo del plan
Aceptacin de riesgos
Aceptacin del proceso
Factibilidad
Plan del proyecto
Conformidad de la lista

Elaboracin
Identificar arquitectura
Validar la arquitectura
Desarrollar el ambiente
el proyecto
Equipo del personal del
proyecto

Fases e hitos AUP
Arquitectura del ciclo
de vida (LCA)
Estabilidad de la visin
Estabilidad de la
arquitectura
Aceptacin de riesgos
Factibilidad
Plan de proyecto
Conformidad con la
empresa
Construccin
Modelado, construccin
y testeo del sistema
Creado de
documentacin de
apoyo

Fases e hitos AUP
Capacidad operacional
inicial (IOC)
Estabilidad del sistema
Stakeholders preparados
Aceptacin de riesgos
Plan de proyecto
Conformidad con la
empresa
Transicin
Test del sistema
Test de usuarios
Retrabajo del sistema
Instalacin del sistema
Fases e hitos AUP
Lanzamiento del
producto (PR)
Aceptacin por los
stakeholders del
negocio
Aceptacin de
operaciones
Aceptacin de soporte
Aceptacin de costo y
estimaciones
Definen actividades que el equipo de desarrolladores
debe realizar para construir, validar y entregar un
software que satisfaga las necesidades de los
stakeholders.

Modelado
Implementacin
Testeo
Deployment
Configuration Management
Project Management
Environment

Disciplinas AUP
Modelado
El objetivo de esta disciplina es comprender el
negocio de la organizacin, comprender el
dominio del problema abordado por el
proyecto, e identificar una solucin al mismo
que sea viable.

Modelado AUP
No es necesario mucho detalle durante las fases de
inicio y elaboracin.
Model storming se realiza en el momento para obtener
los detalles necesarios.
El objetivo es crear modelos con la profundidad
necesaria para lo que se est haciendo.
La mayor parte de los modelos se descarta.
Siempre hay que tener en cuenta oportunidades de
reuso.
La participacin activa de los stakeholders es
fundamental para el xito.
Se recomienda la arquitectura en capas.

Recomendaciones AUP
Agile Model Driven Development
AUP
Modelado Fase a Fase
Inicio
Explorar la utilizacin del producto escribiendo casos
de uso.
Identificar los procesos de negocio por medio de la
creacin de diagramas de flujo de datos.
Identificar las principales entidades de negocio y sus
relaciones.
Identificar las principales reglas de negocio y los
principales requerimientos tcnicos.
Comenzar el desarrollo de un glosario que contenga los
trminos importantes tcnicos y del negocio.

AUP
Elaboracin

Identificar riesgos tcnicos.

Modelado de la arquitectura.

Realizar un prototipo de la interfaz de usuario.
Modelado Fase a Fase AUP
Construccin
Participacin activa del stakeholder y modelado
inclusivo.
Mostrar los detalles de los casos de uso.
Explorar reglas de negocios y requerimientos tcnicos
con la misma profundidad.
Aplicar model storming para el diseo.
Puede resultar til realizar diagramas de secuencia
UML, modelo de deployment, diagramas de clase UML,
modelo de seguridad frente a amenazas, modelos de
datos fsicos.
Documentar las decisiones de diseo crticas.

Modelado Fase a Fase AUP
Transicin

Aplicar model storming para intentar comprender la
causa de defectos detectados.

Finalizar la documentacin general del sistema.


Modelado Fase a Fase AUP
Implementacin
Objetivo
Transformar el modelo realizado en cdigo ejecutable y
realizar tests de nivel bsico, en particular tests unitarios.

Consejos
Programacin por pares
Desarrollo dirigido por tests (TDD)
Modelar antes de codificar
Seguir guas y estndares de codificacin
Rescribir el cdigo y los esquemas de base de datos
Tener ambientes de desarrollo separados (sandboxes)
AUP
Inicial
Prototipo Tcnico
Elaboracin
Probar la arquitectura
Construccin
Testear primero
Realizar builds continuamente
Desarrollar la lgica del dominio
Desarrollar la interfaz grafica
Desarrollar el esquema de datos
Desarrollar interfaces para sistemas externos
Escribir scripts para conversin de datos
Transicin
Corregir defectos

Implementacin - Fases AUP
Implementacin - TDD
Objetivo
Escribir cdigo claro y limpio

Enfoque
Se debe testear con un
propsito, y saber porque se
esta testeando y hasta que nivel
testearlo

TDD
Escribir el test
Escribir el cdigo para satisfacer
el test
Rescribir el cdigo
AUP
Objetivo
Realizar una evaluacin objetiva para asegurar la calidad.
Esto incluye buscar defectos, validar que el sistema funcione
como debera, y verificar que se cumplen los requerimientos.

Consejos
Realizar test durante el ciclo de vida (FLOOT)
Desarrollo dirigido por tests (TDD)
Automatizar el test suite
Realizar practicas que promuevan la revisin continua
Si vale la pena crearlo, vale la pena validarlo
Realizar test de aceptacin para los requerimientos y los
artefactos de testeo
Test AUP
Test - FLOOT AUP
Inicio
Plan de testeo inicial
Realizar una revisin de los artefactos iniciales de la
administracin del proyecto
Realizar una revisin de los modelos iniciales
Elaboracin
Validar la arquitectura
Desarrollar el modelo de testeo
Construccin
Testear el software
Desarrollar el modelo de testeo
Transicin
Validar el sistema
Validar la documentacin
Finalizar el modelo de testeo
Test - Fases AUP
Objetivo
Planificar la liberacin del sistema.

Sugerencias:

Desarrollar los scripts de instalacin/desinstalacin
durante la fase de construccin.

Tener un rea de pre-produccin donde poder
validar el sistema antes de la liberacin.


Deployment AUP
Tener en mente los periodos de pausa en la
organizacin, ya que en estos periodos no se
podr realizar la liberacin.

Definir puntos de decisin (seguir/no seguir)
.

Ser capas de desinstalar el sistema si surgen
problemas.

Realizar testeo de scripts
instalacin/desinstalacin.


Deployment AUP
Deployment



AUP
Deployment Fases

Inicial:
- Identificar la liberacin potencial.
- Comienzo de la planificacin de la
liberacin.
Elaboracin:
- Actualizar el plan de liberacin.

AUP
Deployment Fases
Construccin:
- Desarrollo de los scripts.
- Desarrollo de las notas de
liberacin.
- Desarrollo inicial de la
documentacin.
- Actualizacin del plan.
- Liberacin pre-produccin.


AUP
Deployment Fases
Transicin:
- Finalizacin del empaquetado del
sistema.
- Finalizacin de la documentacin.
- Anuncio de la liberacin.
- Entrenamiento del personal.


AUP
AUP define los siguientes:

DBA, administrador de bases de datos

Agile Modeler, responsable de crear y desarrollar
modelos.

Configuration Manager, responsable de proveer
toda la infraestructura necesaria para el equipo de
desarrollo.

Deployer, responsable de la liberacin del sistema.

Roles y Responsabilidades 1 AUP
Developer, escribe, realiza pruebas unitarias
y construye el software.

Process Engineer, desarrolla, adapta y mantiene el
proceso de software de la organizacin.

Project Manager

Reviewer, evalua los artefactos generados por el
proyecto.


Roles y Responsabilidades 2 AUP
Stakeholder

Technical Writer, responsable de producir la
documentacin para los stakeholders,
documentacin operacional, de soporte y para
usuarios.

Test Manager, responsable de la planificacin del
testeo del sistema.

Tester, responsable de escribir y ejecutar las
pruebas.



Roles y Responsabilidades 3 AUP
Tool Specialist, responsable de seleccionar,
adquirir, configurar las herramientas a utilizar.

Un mismo rol puede ser asumido por varias
personas.

Una persona puede asumir varios roles.




Roles y Responsabilidades 4 AUP
Entregables
Consejos
Mantener los entregables tan simples y concisos
como se pueda.
Se necesita mucha menos documentacin de la que
se piensa.
Trabajar conjuntamente con la gente que crea los
entregables, para producir slo lo necesario.
Documentos giles son justo lo suficientemente
buenos.
Producir documentos es la peor manera de
comunicar la informacin.
Utilizar pizarrones, papel y Wikis para modelar y
capturar la documentacin.

AUP
Entegables Minimos
Sistema
Cdigo Fuente
Casos de Testeo
Scripts de Instalacin
Documentacin del Sistema
Release Notes
Modelo de Requerimientos
Test de Aceptacin, Procesos de Negocio, Dominio,
Casos de Uso, Interfaz de Usuario
Modelo de Diseo
El mejor lugar para documentar el diseo es en los
test unitarios y en el cdigo fuente

AUP
Otros
Oportunidades de Automatizacin
Una lista
Reportes de Defectos
Un mail o una planilla Excel
Modelo de Interfaz de Usuario
Un papel o una pizarra

AUP
AUP
Filosofa
Los integrantes saben lo que hacen.
Simple
Todo es Conciso
gil
Mantener el foco en las actividades de alto
valor.
Independiente de la Herramienta
Brinda soporte a herramientas CASE
Customizable
AUP
Y Entonces
Casos de xito ?

AUP no es para todos, ningn proceso
lo es. AUP es adecuado si se busca
una versin gil y racionalizada del
Unified Process.
AUP
Factor Discriminadores giles Discriminadores formales
Tamao
Dependencia y escalabilidad limitada por
el porcentaje alto de conocimiento tcito.
Apropiado para equipos y productos
pequeos.
Escalabilidad y conocimiento explcito.
Apropiado para productos y equipos
grandes. Duro de mantener en pequeos
proyectos.
Criticidad
La simplicidad en la documentacin y el
diseo dificulta los planes de pruebas.
No aconsejado para sistemas con niveles
de criticidad altos (IEEE 1012)
Rigor de requisitos y diseo adecuados
para procesos de pruebas, verificacin y
validacin.
Duros de gestionar en proyectos de
escasa criticidad
Dinamismo
Re-factorizar desde un diseo bsico
hasta el producto final es un mtodo
ideal para entornos dinmicos e in-
novadores, pero muy caro por el re-
trabajo para entornos estables o
conocidos
En sistemas estables y conocidos, partir
de requisitos completos y diseos
detallados permite trazar y seguir un plan
completo y hacerlo bien a la primera.
Personal
Los mtodos de trabajo giles requieren
una masa crtica de tcnicos con niveles
de experiencia medios-altos, capaces de
comprender y adaptar los mtodos y las
tcnicas empleadas.
Aunque es aconsejable contar con
personas expertas en las fases de
definicin del proyecto, luego pueden
ejecutarse con menor masa crtica de
expertos.
Cultura
Ms apropiado para culturas de
empowerment responsabilidad y
horquilla de decisin y libertad personal.
Ms apropiado en culturas en las que las
personas se sienten seguras con un
marco de tareas y responsabilidades bien
definido.
Adaptado de Barry Bohem y Richard Turner
Balancing Agility and Discipline
Conclusiones
Enfoque formal o gil?
Personal
Criticidad
Dinamismo
Tamao
Cultura
% Junior % Senior y Master
Prdidas posibles
Nmero de personas
% Modific. Requisitos / mes
% adaptacin a entornos caticos
1
5
10
30
50
10
30
50
70
90
300
100
30
10
3
0
10
20
30
40
35
30
25
20
15
Conclusiones
Pgina oficial CMMI del Software Engineering Institute. (http://www.sei.cmu.edu/cmmi/cmmi.html)
Pgina para descarga de los modelos CMMI. (http://www.sei.cmu.edu/cmmi/models/models.html)
SWEBOK: reas de conocimiento de la Ingeniera del software (http://www.swebok.org/)

Modelos basados en procesos
Agile Alliance (http://www.agilealliance.org/)
Scrum (http://www.controlchaos.com/)
Exreme Programming (http://www.extremeprogramming.org/)
DSDM (http://www.dsdm.org/)
Rational Unified Process (http://www-306.ibm.com/software/rational/)
(http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf)
Agile Modeling (http://www.agilemodeling.com/)
Feature Driven Development (http://www.featuredrivendevelopment.com/)
Internet Speed Development (http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr020.pdf)
Modelos giles
Referencias
Nevegapolis: Juan Palacio (http://www.navegapolis.net)
Manifiesto gil (http://www.agilemanifesto.org/)
Wikipedia (http://es.wikipedia.org/wiki/Scrum)
Fuentes
Preguntas ?