Propuesta mejora proceso desarrollo Software (2002) (Diaz Arnesto, Araújo)

Propuesta para la mejora del proceso de
desarrollo de software en pequeñas empresas

Curso Ingeniería de Software
Docente: Fernando Brum
Setiembre 2002

Centro de Postgrados y Actualización Profesional
Instituto de Computación
Facultad Ingeniería
Universidad de la República

Patricia Diaz Arnesto
Alejandro Araújo Perez

Objetivo
Plantear formas de mejorar el proceso de desarrollo de software en pequeñas empresas a
efectos de obtener los resultados previstos en cuanto a costo, tiempo y calidad.

“– Process improvement should be done to help
the business — not for its own sake.”

¿Cuál es la razón de referirnos a pequeñas empresas?
La información disponible en cuanto a la cantidad de personal de las empresas de
software en Uruguay es escasa, parcial y está dispersa. De la misma forma tampoco se
tiene información acertada de la cantidad de empresas que actualmente existen.
De acuerdo a un informe del Banco
170 Personas
Interamericano de Desarrollo (TC-99-10-
Sin datos
05-6-UR) del año 1999, en Uruguay hay
70 66 Hasta 4 250 empresas dedicadas al desarrollo de
80
De 5 a 20 software y consultoría en informática.1
Más de 20 La figura 1 muestra, de acuerdo a la
34
Empresas información disponible (170 empresas), la
distribución respecto al personal empleado.
Figura 1 – Personal empleado Si bien en la encuesta no fueron
considerados los "centros de cómputos"
(públicos ni privados) tenemos la impresión que aún considerándolos debemos hablar en
Uruguay de centros de desarrollo pequeños en general.

Procesos de mejora
Considerando la definición de proceso: “un conjunto de prácticas y mecanismos de
integración de personas, procedimientos, métodos, herramientas, y equipamientos para
producir un resultado final deseado”, encontramos que la tendencia al principio muchas
veces ha sido poner el énfasis en las herramientas (la búsqueda de la bala de plata)
debiéndose focalizar también en los procedimientos, en los métodos y en las personas para
lograr el balance adecuado.

Si buscamos metodologías para mejorar el proceso de desarrollo de software
encontramos que puede efectuarse la siguiente clasificación:
Orientadas a los procesos
Monumentales
Predictivas

Orientadas hacia las personas
Agiles
Adaptativas

1
Sería muy importante también contar con mayor granularidad en los informes ya que es común ver que las estadísticas no discriminan
entre producción de software y consultoría.

Propuesta para la mejora del proceso de desarrollo de software en pequeñas empresas Pág. 2

La calificación de Monumentales se reconoce como introducida por J.HighSmith y se
refiere en general a las metodologías tradicionales consideradas ‘rigurosas’ tales como
CMM, SPICE y Rational Unified Process. En tanto que la calificación de Ágiles ha sido
introducida por los propios proponentes de las nuevas metodologías en sustitución del
termino ‘livianas’.
Las metodologías tradicionales están basadas en la idea de controlar y optimizar. Se
establecen planes para luego controlarlos y se espera que los procesos avancen según lo
planificado. Una vez que se ha realizado un proceso el foco pasa a su optimización.
En las metodologías ágiles se considera que no es posible elaborar un plan detallado ni
capturar en forma temprana todos los requerimientos, debiéndose responder rápidamente a
diferentes cambios durante un proyecto.
Se han escrito numerosos artículos sobre la “guerra” entre estos dos tipos de
metodologías, en los cuales se analizan los pros y contras de cada una. Pero la realidad no
es tan simple, no se puede aplicar universalmente una u otro tipo de metodología, pues
depende de otros factores, como por ejemplo: tipo y tamaño del proyecto, personal
involucrado, tiempos, etc.

¿Que camino seguir?

Propuesta:

Combinar metodologías ágiles, monumentales y propias
• Utilizar las mejores prácticas de las metodologías ágiles, combinando las mismas,
adaptándolas y usándolas en forma disciplinada pero siempre considerando el entorno en el
cual se aplican.

• Adoptando estas metodologías se pueden cumplir objetivos de las áreas de proceso del
modelo Capability Maturity Model Integrationsm (CMMIsm)2 (representación continua), así
como de otros modelos de certificación, aunque la meta planteada no es la certificación
sino la mejora en el proceso de desarrollo y la calidad final del producto.

• No es una receta , es un camino ….
Empresas distintas / Productos distintos / Proyectos distintos

La siguiente frase de Alistair Cockburn aplica a esta propuesta:

“ After ten years of working with methodologies, I was finally forced to
conclude that each organization must develop its own way of working, and
each project must get its own tailored methodology, dealing with culture,
location, criticality, and technology. This is not an option, it is a requirement.”

2
CMMI and Capability Maturity Model Integration are registered service marks of Carnegie-Mellon University.


¿CMM3 para pequeñas empresas?
Pensamos que lo interesante de los modelos de capacidad es que pueden constituir un
marco para realizar en forma disciplinada un proceso de mejora. La figura 2 muestra la
representación histórica del modelo CMM
CMM Niveles de Maduración con sus 5 niveles de maduración.
Optimizado
Al hablar de implantar CMM en pequeñas
Administrado
empresas se plantean muchos problemas:

Definido • Gran cantidad de Roles
• Documentación excesiva
Repetible • Procedimientos rígidos
• Manuales extensos
Inicial
• Costos de implementación
The Capability Maturity Model for Software, Mark Paulk, Mary Beth Chrissis, Charles Weber, and Jeff
Perdue September 16, 1997 Software Engineering Institute Carnegie Mellon University Sponsored by the
U.S. Department of Defense © 1997 by Carnegie Mellon University (www.sei.edu)
• Cursos
Figura 2 – CMM Niveles de Maduración • etc.

Estos problemas no implican necesariamente que no se consideren al menos las buenas
prácticas que el modelo plantea. Recordemos que:

El modelo muestra QUE hacer, NO COMO hacerlo ni QUIEN lo hace

Hoy los distintos modelos de CMM se han integrado en el modelo CMMI, en el cual
existen dos diferentes representaciones, la continua y la estratificada (figura 3).
La representación continua usa niveles de capacidad para medir la mejora en los
procesos, mientras que la representación estratificada utiliza los niveles de maduración.

En la representación continua hay 6 niveles de capacidad, numerados del 0 al 5, los
cuales indican el grado de
mejora que la organización CMMI - Comparando la representación de
tiene en cada área de proceso. los modelos
Niveles de Capacidad:
Contínua Estratificada
0- Incompleto
ML5
5
Process Area

1- Ejecutado
Capability
4

ML4
2- Administrado
3

ML3
3- Definido
1 2

ML2
4- Cuantitativamente
ML 1
Administrado
0

PA PA PA
5- Optimizado
CMMI Tutorial Mar 25, 2002
Mike Phillips, CMMI Program Manager

Figura 3 – CMMI representaciones

3
CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office


En la representación estratificada hay 5 niveles de madurez los cuales indican la
madurez de toda la organización. Cada nivel de madurez comprende un conjunto de áreas
de proceso.

Niveles de Madurez:
1- Inicial
2- Administrado
3- Definido
4- Cuantitativamente Administrado
5- Optimizado

¿Porqué utilizar CMMI continuo?

• Permite flexibilidad para enfocar áreas específicas de acuerdo a las metas y objetivos de
la organización.

• Es un modelo para la mejora en toda la organización.

Representación continua de CMMI – Conceptos
Los componentes que resumen la representación continua del modelo CMMI son las
áreas de proceso (PA). Un área de proceso es un conjunto de prácticas relacionadas que
ejecutadas colectivamente cumplen metas consideradas importantes para lograr una
significativa mejora en esa área.
Las Areas de Proceso
identifican
“que se hace”

Process Area 1
Process Area 1 Process Area 2
Process Area 2 Process Area n
Process Area n

Specific Goals
Specific Goals Generic Goals
Generic Goals

Specific Practices Generic Practices
Capability Levels

Los Niveles de Capacidad
identifican
“que tan bien se hace”

Figura 4 - Componentes del modelo CMMI


Para cada área de proceso hay metas específicas que son implementadas por prácticas
específicas. Cada área de proceso tiene sus propias metas y prácticas específicas.
También existen metas genéricas que se implementan por prácticas genéricas pero a
diferencia de las específicas éstas se aplican a varias áreas de proceso.
Cada práctica (específica o genérica) corresponde a solo un nivel de capacidad.
Se definen 5 metas genéricas, una para cada nivel de capacidad (1-5), que describen el
grado de institucionalidad que una organización debe alcanzar en ese nivel. Las 5 metas
genéricas aparecen en cada área de proceso.
Los niveles de capacidad de la representación continua proveen un orden para la mejora
de los procesos en cada área
de proceso. Esta mejora se
Niveles de Capacidad realiza pasando de un nivel a
otro pero sin saltear ninguno
• Los valores en el eje de las ordenadas describen y las áreas de proceso
cuan bien se ejecuta un proceso.
pueden estar a distintos
niveles como lo indica la
Optimizado 5 Proceso bien realizado y continuamente mejorado
figura 5.
Cuant.Administrado 4 Para que un área de
Capability

3
Definido proceso tenga por ejemplo
Administrado 2
Proceso no
Sin saltos nivel de capacidad 2, se
Ejecutado 1 realizado deben satisfacer las metas
Incompleto 0 específicas, las prácticas
Process Process Process Process Process
Area 1 Area 2 Area 3 Area 4 Area n específicas de nivel 2 y las
Procesos
CMMI Tutorial Mar 25, 2002
metas genéricas de nivel 2
para esa área de proceso.
Figura 5 – Niveles de Capacidad

La siguiente tabla muestra las 22 áreas de proceso agrupadas en 4 categorías:

Categoría Areas de Proceso
Process Management Organizational Process Focus
Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment
Project Management Project Planning
Project Monitoring and Control
Supplier Agreement Management
Integrated Project Management
Risk Management
Quantitative Project Management
Engineering Requirements Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Support Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Decision Analysis and Resolution
Causal Analysis and Resolution

Para mas información del modelo CMMI referirse a www.sei.cmu.edu/cmmi


Por último, la figura 6 muestra una comparación entre las KPA (key process area) de
CMM y las PA (process area) de CMMI. En ella se aprecia una mayor granularidad de las
áreas de proceso, sobre todo en el nivel 3, lo cual permite focalizar mejor el esfuerzo.
También aparece la gestión de riesgos como un área concreta y a nivel 2 se agrega el
Measurement y Analysis.

SW-CMM v1.1 vs. CMMI
Process Areas
De fe ct P re ve ntion Ca us a l Ana lys is a nd Re s olution
LEVEL 5 Te chnology Cha nge Mgmt Orga niza tiona l Innova tion & De ployme nt
OPTIMIZING
P roce s s Cha nge Ma na ge me nt
LEVEL 4 Qua ntita tive P roce s s Mgmt Orga niza tiona l P roce s s P e rforma nce
MANAGED S oftwa re Qua lity Mgmt Qua ntita tive P roje ct Ma na ge me nt

Orga niza tion P roce s s Focus Orga niza tion P roce s s Focus
Orga niza tion P roce s s De finition Orga niza tion P roce s s De finition
Tra ining P rogra m Orga niza tiona l Tra ining
Inte gra te d S oftwa re Mgmt Inte gra te d P roje ct Ma na ge me nt
Ris k Manag e me nt
S oftwa re P roduct Engr Re quire me nts De ve lo pme nt
Te c hnic al S o lutio n
Pro duc t Inte g ratio n
Inte rgroup Coordina tion Ve rific atio n
LEVEL 3 P e e r Re vie ws Validatio n
DEFINED De c is io n Analys is and Re s o lutio n

Re quire me nts Ma na ge me nt Re quire me nts Ma na ge me nt
S oftwa re P roje ct P la nning P roje ct P la nning
S oftwa re P roje ct Tra cking & Ove rs ight P roje ct Monitoring a nd Control
S oftwa re S ubcontra ct Mgmt S upplie r Agre e me nt Ma na ge me nt
S oftwa re Qua lity As s ura nce P roduct & P roce s s Qua lity As s ura nce
LEVEL 2 S oftwa re Configura tion Mgmt Configura tion Ma na ge me nt
REPEATABLE
Me as ure me nt and Analys is
86

Figura 6 – Comparación CMM - CMMI

¿Y que hay acerca de los Roles?
• CMM define más de 25 roles...

• Dynamics CMM trabaja en detalle el tema de roles y superposición de los mismos
para empresas de 1 a 50 individuos, nivel 2.

Dynamics CMM4
Es un modelo basado en CMM desarrollado por Astrid Laryd y Terttu Orci , de la
Universidad de Umeá / Universidad de Estocolmo, pensado para su aplicación a empresas
pequeñas, preferentemente desde el comienzo de las mismas.

4
La documentación que ha estado a nuestro alcance sobre este modelo contiene referencias a CMM y no a CMMI, no sabemos si ha
sido actualizado para alinearlo con las PA actuales de nivel 2.


Características:

• Para utilización tanto en SPI (software process improvement) como por el grupo
organizacional interno y por la gerencia.
• Se focaliza en los roles y documentos.
• Presenta el modelo en KPA organizadas por roles y responsabilidades asociadas,
documentadas por tipo.
• Preparado para el crecimiento.
• Cubre hasta nivel 2 (más allá de esto se supone a la empresa preparada para modelo
CMM tradicional).
• Existen documentos específicos con la versión adaptada de Dynamics CMM para
empresas de tipo eXtra-eXtra-Small, eXtra-Small, y Small.

Lo interesante de este modelo es que da una guía para la asignación de roles a una
misma persona, partiendo de empresas "extra extra small" (1 o 2 individuos y 1 proyecto)
hasta empresas pequeñas, considerando solo aquellos roles que sean relevantes según el
tamaño de la empresa y la cantidad de proyectos.

Roles en extremadamente pequeñas y muy pequeñas empresas:

En los diagramas de las figuras 7 y 8, las líneas indican que roles pueden ser asumidos por
un mismo individuo, cumpliéndose la transitividad.
Es de destacar en el
diagrama que SQA y STG
aparecen como roles no
compartibles, brindados por
grupos externos ya que en
modo estricto debe ser así,
aunque en algunos
casos podría solucionarse si
es el cliente el que aporta su
área de SQA (CSQA)."
Figura 7 – Roles en XXS – Laryd/Orci

En el segundo diagrama (figura 8) se contempla la aparición de varios proyectos y dos
nuevos roles: sales y project manager.

Figura 8 – Roles en XS – Laryd/Orci


Metodologías Ágiles
Tal como hemos expresado opinamos que el modelo CMMI de representación continua,
al brindar un marco para la mejora por cada área de proceso, permite avanzar hasta el nivel
que se considere adecuado en cada área priorizando y focalizando así los esfuerzos.
Ahora presentaremos con más detalle el conjunto de metodologías ágiles opinando
acerca de las mismas a medida que avanzamos en su presentación, con el objetivo puesto
en la propuesta que cada organización, apoyada en el conocimiento adquirido en sus
propias prácticas, institucionalice una versión personalizada incorporando lo que mejor se
adapte a su estructura y a cada proyecto en concreto, pudiendo así avanzar en varias de las
áreas de proceso identificadas previamente como candidatas a mejorar.

The Agile Manifesto

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

En Febrero de 2001, en Salt Lake City, Utah, se reunieron los proponentes principales
de estas metodologías y emitieron el manifiesto que transcribimos, formando la “Agile
Software Development Alliance”.

Interpretaremos este manifiesto aplicando sentido común y presentaremos las
metodologías proponiendo hacer el mejor uso posible de cada una y de su combinación.


Interpretando el Manifiesto
Las 4 sentencias:
El énfasis está puesto en los factores humanos, en el producto final y en la respuesta al
cambio, según se aprecia en los cuatro valores fundamentales que interpretamos de la
siguiente manera:

• Individuos e interacciones predominando sobre procesos y herramientas

Sin dejar de reconocerse la importancia de los procesos y herramientas se hace
hincapié en que es primordial factor de éxito la calidad y la buena interacción de los
individuos que componen el equipo.

• Software operativo predominando sobre documentación comprensiva

Si bien se reconoce que producir y mantener buena documentación no está mal, deben
focalizarse los esfuerzos en el producto final que es el software operativo.

• Colaboración con el cliente predominando sobre negociación de contratos

Los contratos son una práctica necesaria e importante, pero no suficiente de no
establecerse políticas colaborativas y de participación activa del cliente.

• Respuesta al cambio predominando sobre seguimiento de un plan

La planificación es importante, pero la misma debe adaptarse al cambio.

Lo que dicen sus redactores:

1. Son un grupo de experimentados y reconocidos ‘gurus’ que aseguran a la audiencia
que no tienen todas las respuestas y que no suscriben a la teoría de la bala de plata.
2. Actualmente practican los métodos que proponen.
3. Ayudan (no enseñan) a otros a desarrollar mejor software.
4. En cada sentencia del manifiesto lo primero indica una preferencia y lo segundo algo
menos prioritario, sin dejar de reconocer su importancia.
[Martin Fowler, Jim Highsmith]

Los principios:
El manifiesto incluye los siguientes 12 principios:

• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference for the shorter timescale.


• Business people and developers work together daily throughout the project.
• Build projects around motivated individuals, give them the environment and
support they need and trust them to get the job done.
• The most efficient and effective method of conveying information with and within a
development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers and
users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximizing the amount of work not done—is essential.
• The best architectures, requirements and designs emerge from self-organizing
teams.
• At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

Entendemos que estos principios deben de ser interpretados bajo la misma óptica con
que analizamos los valores ya expuestos. En particular hacemos notar que:

• No creemos que se pueda dar la “bienvenida” en forma genérica a cambios en
los requerimientos en etapas tardías del desarrollo e interpretamos que se
intenta con esto resaltar una actitud positiva hacia el cambio.
• La importancia de los roles de dirección es innegable, por lo que interpretamos
entonces como equipos autoorganizados aquellos en que la interacción es alta,
la distribución de algunos roles no necesariamente es estática a lo largo del
proyecto y las decisiones de sus miembros son valorizadas pero funcionando
bajo una coordinación general.
• Los ciclos muy breves no siempre se pueden corresponder a entregables para el
cliente, pero pueden ser utilizados como puntos de referencia y etapas dentro
del proyecto.
• La integración diaria de “business-people” creemos que debe interpretarse en
general como tener siempre disponibles, o lo más rápido posible, a los
representantes del cliente o usuarios.

Características de las Metodologías Ágiles
Estas metodologías se pueden caracterizar como adaptativas, orientadas hacia las
personas y pensadas para equipos pequeños o medianos.

• “Adaptativas” pues consideran en general que no es posible efectuar un plan
detallado y seguirlo sin desviaciones. En realidad el cambio debería ser visto como lo
que conduce a la construcción del producto final adecuado [Jim Highsmith].

Facilitating change is more effective than attempting to prevent it. Learn to trust in
your ability to respond to unpredictable events; it's more important than trusting in your
ability to plan for disaster. [ Martin Fowler, Jim Highsmith]


“The problem for engineers is that change translates into chaos... But, change also
translates into opportunity. It's as simple as this: if there is time to put a certain amount of
functionality into the product easily, then there is time to put in more functionality at the
price of a certain amount of disruption and risk. Thus does madness creep into our
projects - we will tend to take on as much risk as we possibly can." [James Bach. October
1995. "American Programmer"]
En particular interpretamos que:

o Se “planifica” a nivel general en etapas iniciales, y se construye luego por
partes bajo la forma de ‘iteraciones’, con posibilidad de cambios y
revisiones importantes ante cada iteración a partir de la introducción,
cambio o modificación de requerimientos. Se define también una etapa de
clausura.
o Las entregas son frecuentes, producto de iteraciones breves y controladas
que producen software operativo y testeado.
o El análisis de riesgo es un componente fundamental que acompaña a todo el
proceso de desarrollo.
o Los contratos deben contemplar el nuevo paradigma propuesto.

• “Orientadas hacia las personas” pues consideran que los factores humanos son
primordiales en el proceso de desarrollo.

..."People" are highly variable and non-linear, with unique success and failure
modes. Those factors are first-order, not negligible factors. [Alistair Cockburn]

En particular interpretamos que:

o Primero están las personas y luego los roles. Se reconoce explícitamente la
experiencia de los desarrolladores, posibilitando que estos efectúen
importantes decisiones técnicas o colaboren estrechamente en la toma de las
mismas, fomentándose la iniciativa personal.
o Se buscan y fortalecen los mejores medios de comunicación directa e
inmediata entre los integrantes del equipo, así como los mecanismos para
que estos expresen sus opiniones, sugerencias y problemas, trabajándose en
forma permanente en pro de este objetivo.
o Se trata de brindar un ambiente físico de trabajo que ayude a priorizar el
mejor relacionamiento, comodidad y creatividad con la menor cantidad de
interrupciones.
o El equipo debe sentirse comprometido con el proyecto.
o Usuarios y clientes deben estar muy involucrados y disponibles durante el
desarrollo, colaborando en la elaboración de requerimientos y en el test así
como aprobando los entregables. Estrictamente hablando representantes del
usuario o cliente se deberían integrar al equipo de desarrollo.
o Se trata de eliminar las actividades no necesarias

• “Equipos medianos y pequeñas” pues las consideran aplicables en equipos de
pocos desarrolladores (no más de 20) aunque esto depende de las
particularidades de cada metodología, habiéndose efectuado experiencias de
aplicación para equipos más numerosos.


Algunas Metodologías Ágiles
Del conjunto de metodologías ágiles presentaremos las siguientes:

Extreme programming (XP) (Kent Bench) (Ward Cunningham) (Rod Jeffries)

Scrum (Takeuchi, Hirotaka) (Nonaka, Ikujiro) (Ken Schwaber)
(Mike Beedle) (Jefh Shuterland)

Crystal Family and Adaptative Software (Alistair Cockburn) (Jim Highsmith)

Dynamic System Development Method (DSDM)5

Feature Driven Development (FDD) (Peter Coad) (Jeff de Lucca)

Antes de pasar a la descripción y comentarios acerca de cada una de ellas queremos
destacar que en un estudio publicado en el artículo “The Decision is in: Agile versus
Heavy Methodologies” de Robert Charette, que involucró a 200 IS/IT managers, con
respecto a la experiencia en metodologías ágiles, el 54% respondió que utilizaban una
metodología desarrollada internamente la cual describen como ágil.

Para aquellos que no utilizaban una metodología ágil propia la distribución se muestra
en la Figura 9.

Figura 9 Utilización de metodologías ágiles
5
DSDM is a registered trademark of Dynamic Systems Development Method Limited. (c) 2001 by Dynamic Systems Development
Method Limited


Extreme Programming
Breve Reseña Histórica
A comienzos de los 90’ Kent Beck y Ward Cunningham colaboraron experimentando
formas para lograr que el desarrollo de software fuera más simple y eficiente, apoyados
en ideas y prácticas existentes las cuales van adaptando.

En Marzo de 1996 Kent fue contratado para revisar el proyecto C3 en
DaimlerChrysler y recomendó tirar todo el código existente y comenzar nuevamente. El
proyecto fue restaurado bajo su liderazgo y la metodología XP se formalizó.
Kent Beck escribió un libro que puede considerarse como el manifiesto de la
metodología: “Extreme Programming Explained”

Valores
Se postula que los 4 valores esenciales para la mejora de cualquier proyecto son:

Comunicación, Simplicidad, Retroalimentación, Coraje

Como vemos estos valores se focalizan en aspectos humanos. Algunas frases de Kent
Beck nos ilustran a este respecto:

“...there are four dimensions along which one can improve any software project. You
need to improve communication. You need to seek simplicity. You need to get feedback
on how well you are doing. And you need to always proceed with courage.
Communication, Simplicity, Feedback, and Courage are the four values sought out by XP
programmers” [Kent Beck]

”...XP is often presented as a list of practices, XP is not a finish line. You don't get
better and better grades at doing XP until you finally receive the coveted gold star. XP is
a starting line. It asks the question, 'How little can we do and still build great software “
[Kent Beck]


Descripción de la Metodología

Ciclos de vida

Las fases de un proyecto XP son las siguientes:

Exploración

Los clientes describen las funcionalidades que quieren implementar bajo la forma de
‘stories’ (pueden verse como casos de uso que entran en una ficha) mientras el resto de
los integrantes del equipo de desarrollo se familiarizan con las herramientas, arquitectura,
y se va construyendo la metáfora del sistema (visión común de todos los integrantes –
desarrolladores y clientes- acerca del sistema a implementar y su dominio). Se crean
también ‘spikes’ (pequeños programas) para explorar potenciales soluciones a problemas
técnicos o de diseño y encontrar las respuestas.

Planificación de versiones

A partir de las “stories” los desarrolladores deciden cual es el conjunto inicial de las
mismas a implementar para la primera versión escogiendo el mínimo conjunto que tenga
sentido. En siguientes versiones será el cliente quien escoja el conjunto el conjunto de
“stories” a implementar y los desarrolladores definen el plazo y costo.
La primera versión llevará probablemente más tiempo de desarrollo y es de destacar
que es un aspecto critico pues puede dar lugar a la iteración más larga, desarrollándose
mientras el sistema aún “no respira”.
Se realizan reuniones con los clientes para la elaboración del plan.
El tiempo de desarrollo de cada ‘story’ se medirá en semanas y el plan se explicita
colocándolo en un lugar visible a todos.

Iteraciones

El objetivo de las iteraciones es poner en marcha una versión (release).
Los desarrolladores subdividen las “stories” en tareas (tasks) y se estiman los tiempos
de cada tarea. Cada tarea debe llevar pocos días en ser completada y se asigna a parejas
de programadores quienes escriben los test y codifican los módulos. Al completarse cada
tarea se integra al código existente y se corren los test de regresión.
Mientras tanto los clientes especifican los test funcionales que se correrán al final de
cada iteración.
Cada iteración debería tener un tiempo de 1 a 4 semanas y una versión surge como
resultado de una o varias iteraciones que cuentan con la aprobación del cliente luego de
correr los test de aceptación. Es de destacar que una versión puede ser obtenida pero por
razones de costo y oportunidad se puede decidir posponer su implementación.

Producción-Mantenimiento

Una vez que se corren todos los test funcionales y se obtiene la aprobación del cliente
el sistema está listo para entrar en producción. A partir de este momento se continúa con
las iteraciones y el equipo de desarrollo deberá encargarse del sistema en producción así
como de la incorporación de nueva funcionalidad.


Finalización

Cuando el cliente decide que no necesita producir nuevas “stories” se produce
entonces la documentación final que se considere estrictamente necesaria.

http://www.extremeprogramming.org/map/project.html

Prácticas

The Planning Game
Los desarrolladores estiman el esfuerzo que se necesita para implementar las ‘stories’ y
el cliente decide acerca de las stories a implementar en las mismas.

Small Releases
Cada versión debe ser tan pequeña como sea posible, y debe contener los
requerimientos del negocio más valiosos.

Methapor
El sistema es definido como una “metáfora” que conocen tanto el cliente como el
equipo de desarrollo. Se explicita el sistema en forma general y coherente.

Simple Design
Se busca la simplicidad de diseño. Se elimina todo código extra y complejidad
innecesaria. Se diseña por la funcionalidad que ha sido definida y no por la potencialmente
necesaria a futuro.

Testing
El desarrollo es guiado por los casos de test. Existen test de unidad y funcionales. Los
desarrolladores codifican primero los casos de test y luego el código de la aplicación que
satisface dichos casos. Los clientes escriben los test funcionales. Los test son ejecutados en
forma continua. Cada vez que una porción de código es escrita se la somete a todo el
conjunto de casos de test correspondientes.

Refactoring
Se reestructura el sistema durante todo el ciclo del proyecto removiendo redundancias,
eliminando funcionalidad obsoleta, mejorando la comunicación, rejuveneciendo diseños
obsoletos, simplificando para incrementar la calidad. No se traduce necesariamente en


cambios observables en el comportamiento del sistema, aunque la adición de nueva
funcionalidad debería ser precedida por el refactoring.

Pair Programming
Dos programadores trabajando con una misma máquina. El desarrollo de las tareas se
realiza en parejas de programadores.

Collective Ownership
Cualquiera dentro del equipo de desarrollo puede cambiar cualquier parte del código en
cualquier momento.

Continuous Integration
La integración de código es continua y ocurre varias veces al día. Se integra cada pieza
en cuanto está pronta. Todos los test deben pasarse para aprobar la integración.

40-horas week
No se debería trabajar más de 40 horas semanales. Si ocurre que se necesita sobre
tiempo más de una semana consecutiva entonces debe tratarse como un problema a
resolver.

On-Site Customer
El cliente debe estar siempre disponible para el equipo de desarrollo. La mejor forma es
integrarlo al equipo.

Coding Standard
El código debe adherir a estándares conocidos por el equipo para así facilitar el trabajo
en conjunto, la propiedad colectiva, la reconstrucción, la integración, etc.

Actividades
Es de destacar que XP prescribe actividades diarias que pueden representarse por una
máquina de estados como la que se muestra en la figura 10.

La actividad diaria comienza por
una breve reunión inicial, luego se
trabaja en parejas de programadores
donde cada una de ellas itera un ciclo
de Test – Código – Reconstrucción
hasta integrar el código o tirarlo.

Las horas de comienzo y final están
puestas solo para resaltar el hecho que
no se trabaja tiempo extraordinario.

Figura 10 – Máquina de estados actividad diaria


Variantes de XP

Se ilustra en la figura 11 “variantes de XP” en las que alguna de las prácticas no está
implementada:

Figura 11 - Don Roberts, Ron Jeffries, and William C. Wake

Roles
Los roles de administración en XP

• Tracker
Es quien maneja la mecánica de administración y medición del progreso que hacen los
equipos. Hace el seguimiento del plan de versiones (release plan), del plan de iteraciones
(iteration plan) y de los test de aceptación (acceptance test). El plan de iteraciones es, por
la brevedad de cada iteración, en el que se hace énfasis por lo que el seguimiento es diario.
En caso de notar desviaciones importantes puede derivar en que el cliente deba ajustar el
plan.

• The Manager
Es el “propietario” del equipo y de sus problemas. Toma las decisiones. Es la cara
visible del equipo al que formó y para el que obtuvo recursos. Se encarga de manejar los
problemas y dirigir a las personas.

• The Coach
Es responsable del proceso. Es la persona experimentada a la que se asignan muy pocas
o ninguna tarea de desarrollo y que se encarga de hacer el seguimiento de cada proceso, de
que se apliquen las reglas o cambiar las mismas de ser necesario, de guiar y aconsejar.
También debe ser sensible a los problemas que se presentan para actuar en pro de su
resolución.


Los demás roles:

• Programmer
Escribe los programas y test de unidad.

• Customer
Escribe las “stories” y los test funcionales. Decide cuando quedan satisfechos los
requerimientos.

• Tester
Ayuda a los clientes en la elaboración de los test funcionales y se encarga de la
ejecución de los mismos.

El ambiente

Poner el énfasis en lograr determinados ambientes físicos de trabajo, la comunicación
directa, el evitar interrupciones, etc. es muy importante en esta metodología.

El ambiente de trabajo debe estar lo menos compartimentado posible para permitir la
mejor comunicación, con espacio para moverse libremente y para colocar exhibidores o
pizarrones. También debe tenerse en cuenta que la programación de a pares puede requerir
cierta adaptación del equipamiento de la oficina.

Niveles de maduración y adaptabilidad

Beck definió tres niveles de “maduración XP”
• XP "out of the Box" (como está escrito en el libro)
• Adaptation (adaptándolo al proceso)
• Transcendence (ya no tiene importancia si se está en XP o no, el modelo adaptado
funciona)

Puntos a tener en cuenta:
► pair programming
► técnicas de testing previo
► usuarios escriben los test funcionales
► entregas muy frecuentes
► reuniones diarias
► disciplina


S C R U M6

En el artículo publicado en 1986 por Takeuchi, Hirotaka and Nonaka, Ikujiro The New
Product Development Game (Harvard Business Review) es donde aparecen las primeras
referencias a esta metodología aplicada al desarrollo de productos originada en ambientes
hiper-productivos en Japón, luego elaborada en "The Knowledge Creating Company"
(1995) por los mismos autores.

Las empresas ADM y VMARK, ambas miembros del OMG (Object Management
Group) basándose en los trabajos de Takeuchi y Nonaka, y apoyadas en investigaciones
propias y de científicos de DuPont's Advanced Research Facility en Wilmington,
Delaware, elaboran y presentan una ponencia en el encuentro de OMG’ Business Object
Modeling Special Interst Group en 1995 describiendo la metodología aplicada al software.

Schawaber y Beedle publicaron el libro: “Agile Software Development with Scrum”.

Valores
SCRUM es visto como un proceso de creación de conocimiento donde el mismo es
creado y compartido a medida que el trabajo progresa, basándose en equipos de trabajo
colaborativos que aseguran lo anterior.

Define al proceso de desarrollo como un conjunto de actividades que combinan
conocimiento, herramientas de trabajo y técnicas con lo mejor que un equipo de desarrollo
pueda hacer para construir sistemas.

Sostienen haber probado que el proceso de desarrollo de sistemas es empírico y que se
debe agregar control para administrar los procesos y el riesgo inherente, así como para dar
respuesta adecuada a lo desconocido e inesperado.

Se hace especial énfasis en los siguientes items:

• Aceptar que la realidad está signada por complejidad e impredicibilidad.
• Se puede estimar pero no planificar exactamente lo que se entregará, cuando se
entregará y a que costo.
• Se entregará el mejor software posible según las circunstancias.
• El proceso de desarrollo de sistemas es complicado e impredecible.
• La falta de habilidad para responder a la impredicibilidad deja los proyectos fuera de
control.

Principios
Los autores de Scrum sostienen que la metodología está basada en principios extraídos
de la teoría de la complejidad:

6
Scrum no es un acronimo y se refiere a un mecanismo del juego del rugby : “getting an out-of-play ball back into play”


• Self organization
• No single point of control
• Interdisciplinary teams
• Emergent behavior
• Outcomes emerge with high dependence on relationship and context
• Performance far greater than sum of individuals on the team

Descripción de la Metodología7

Ciclo de vida

Las fases de un proyecto SCRUM son las siguientes:

• Pre_Game

Incluye dos sub-fases: planificación y arquitectura. Los procesos en esta fase están bien
definidos, con todos los procedimientos, entradas y salidas explícitos y con un flujo lineal
con algunas iteraciones en la fase de planificación.
De las lista de actividades a realizar en esta fase destacamos:

• Los requerimientos que se conocidos se capturan y se construye una lista
priorizada llamada “backlog” estimándose el esfuerzo que demandará
implementarlos. Se trabaja en fuerte integración con el cliente.
• Se hace el análisis y la conceptualización.
• Se hace el análisis de riesgo
• Se identifican recursos, se hace el “envisioning” de la arquitectura basado en
el “backlog” conocido y se estable el ambiente operativo de destino así como
un diseño de alto nivel.
• Se definen herramientas a usar y necesidades de entrenamiento.
• Se asigna el “backlog” a equipos con un máximo de 6 desarrolladores cada
uno bajo la forma de “paquetes” a implementar.
• Se llevan a cabo reuniones de revisión de diseño.

• Game

Esta es la fase de desarrollo que incluye ciclos iterativos, los cuales tienen como
objetivo producir incrementos (ejecutables) donde se ha construido o agregado
funcionalidad. Dichos ciclos se conocen como “Sprints” y tienen una duración teórica de
30 días, pero se considera admisible que puedan variar de 1 a 6 semanas (los Sprint
iniciales suelen tener mayor duración).
Los “Sprints” son procesos empíricos, con comportamientos sin identificar e
impredecibles. Son no lineales y flexibles.
Los equipos que intervienen en el “Sprints” están compuestos por un máximo de 9
personas.
7
Scrum ha sido definido por sus presentadores en realidad como un “marco” o un “macro-proceso” más que como una metodología.


Un producto entregable al cliente-usuario puede necesitar de varios “Sprints” para ser
producido.
Dentro del “Sprint” se efectúa una reunión cada 24 horas para el seguimiento del
proyecto y se toman decisiones en el momento.
El último día del “Sprint” se presenta el producto en reunión informal con usuarios,
clientes, equipo de desarrollo y dirección. Se determina la aceptación del incremento.
Entre dos “Sprint” se decide como continuar y que producirá el próximo. Nuevos items
pueden ser agregados al “Backlog” o efectuarse otro tipo de cambios en el mismo.

• End-Game (Closure)

Los procesos en esta fase están bien definidos, con todos los procedimientos, entradas y
salidas explícitos y con un flujo lineal.
Cuando el equipo de dirección decide que el producto está listo para su distribución
cierra la versión. Esto es en base a que se halla implementado la funcionalidad suficiente a
partir de los items requeridos del “Backlog” y el riesgo se halla reducido aceptablemente.
Es este momento en que incluye la documentación final, escenificación de casos de test y
liberación.

Reglas y prácticas

Scrum se focaliza en prácticas de administración y no en prácticas o métodos de
desarrollo de software lo que permite:

• La introducción (total o parcial) como marco para proyectos ya comenzados.
• La combinación con otras metodologías.


Backlog
Solo una persona es responsable del mantenimiento del backlog aunque muchas pueden
producir item candidatos a integrar el backlog, que define a toda cosa que sea necesaria
para construir el producto final.

Effort estimation
A partir de los items del backlog se hace una estimación del esfuerzo para cada uno.
Esto se efectúa en forma iterativa en la medida que se va obteniendo más conocimiento
sobre cada item.

Sprint planning meeting
Previo a cada Sprint se efectúan 2 tipos de reuniones de planificación del mismo.
En un tipo de reunión donde participan todos se definen funcionalidades y se seleccionan
los items del “backlog” que se asignará al Sprint).
En el otro tipo de reunión participan solo los equipos y el Scrum Master y se dedican a
detalles técnicos.

Sprint
Es el procedimiento que se utiliza para construir un ejecutable. Dura 30 días y los
equipos allí hacen el trabajo de programación y ensamblaje. Dentro de cada Sprint se
pueden distinguir tareas de análisis, diseño, revisión y ajuste.

Daily Scrum meeting (Scrums)
Son reuniones muy breves convocadas a diario en el mismo lugar y hora por el Scrum
Master quien interroga a cada miembro del equipo con tres cuestiones básicas y resuelve
en el momento acerca de los problemas e impedimentos.

Sprint Review meeting
Es la reunión final de presentación del producto del Sprint. Intervienen todos.

Controls
Se define que es sumamente importante definir indicadores (“Controls”) para efectuar el
seguimiento del proceso y controlar el caos.

Por ejemplo:

• Risks: Riesgos que afectan el éxito del proyecto son continuamente evaluados y las
respuestas planificadas. Es el más importante y otros indicadores pueden ser
afectados por los resultados de la evaluación.
• Backlog: Se incorporan al backlog los requerimientos no adecuadamente
solucionados en la versión actual. Los bugs, defectos, las nuevas solicitudes del
cliente, cambios tecnológicos a tener en cuenta, etc.
• Packets: Componentes del producto que deben ser cambiados para implementar un
item del backlog en una nueva versión.


Roles

Roles de Administración

Scrum Master
Es el responsable que el proyecto cumpla las reglas. Modera las reuniones diarias de
Sprints. Si encuentra impedimentos o problemas toma en forma inmediata las decisiones
que permitan resolverlos8 y procede para que dichos impedimentos sean resueltos tan
pronto como sea posible.
Interactúa con el equipo de desarrollo y con los clientes. Mide el progreso.

Product Owner
Es el responsable por el proyecto y es seleccionado por el Scrum Master en acuerdo
con el cliente y el equipo de desarrollo. Se encarga de administrar el “backlog” y participa
en la estimación del esfuerzo para la construcción de los item del “backlog”.

Management
Es el que se encarga de las decisiones finales. Participa en la definición de objetivos y
metas.

Otros Roles

Scrum Team
Equipo de desarrolladores ampliado con expertos sobre el dominio del problema y
clientes.

Customer


► marco para otras metodologías como XP.
► backlog como concentrador de toda la información del proyecto.
► reuniones diarias donde se toman inmediatas decisiones.

8
“Better to ask forgiveness than ask permission”


Una forma propuesta de integración de XP y SCRUM
“XP-SCRUM” http://www.controlchaos.com/xpkane.htm


Crystal9 and Adaptative Software
Reseña Histórica
Alistair Cockburn es el autor de la familia de metodologías Crystal y Jim HighSmith es
el autor de Adaptative Software.
Las metodologías surgen en forma independiente y actualmente están en proceso de
unificación, siendo por eso que hicimos referencia a ambas en forma simultánea, aunque
las describiremos por separado.

Crystal Family

A comienzos de los 90 Cockburn trabajando para IBM diseña la metodología para el
Wordwilde IBM Consulting Group. En 1998 en su libro “Surviving Object Oriented
Projects” describe la metodología que actualmente corresponde a “Crystal Orange”.
El propio Cockburn explica que sus metodologías tienen como “antecedentes
filosóficos” a la filosofía general de desarrollo de software centrada alrededor de
“Languaje Games” de Wittgensteins y de “Programming as theory building” de Naur; pero
que su base es fundamentalmente empírica y surge de observar como trabaja la gente y de
las respuestas de los lideres de proyectos a las preguntas sobre su forma de trabajar, sus
éxitos y sus fracasos.

Adaptative Software Development

Propuesta de Jim HighSmith presentada en su libro ”Adaptative Software Development:
A Collaborative aproach to managing complex systems” en el año 2000 y que tiene como
principal antecedente los trabajos realizados en colaboración con S.Bayer en el año 1994
en la metodología “Radical Software Development”.

Crystal Family of Methodologies

No todo el conjunto de metodologías Crystal ha sido formalizado. Las metodologías se
“codifican por colores” y se denominan Crystal Clear, Crystal Orange, Crystal Red,
Crystal Maroon, Crystal Blue y Crystal Violet.
En especial nos ocuparemos en detalle de Crystal Clear y haremos alguna referencia a
Crystal Orange.

Valores, Características Generales y Principios
Una metodología por proyecto

Crystal es en un conjunto de metodologías que opera bajo la premisa de que una única
metodología no puede cubrir todos los proyectos, postulando esto como un requerimiento y
no como una opción, debiendo cada organización desarrollar su propia manera de trabajar
adaptando la metodología a cada proyecto.

9
Crystal es el apodo de un personaje ficticio, supuesto corresponsal de Cockburn, que este utiliza para
presentar sus metodologías.


El desarrollo del software es un juego cooperativo

“El desarrollo de software es un juego cooperativo, en el cual las personas emplean
registros como apoyo para comunicar, rememorar e inspirar tanto a sí mismas como a
otros participantes con el propósito de llevar a cabo el siguiente movimiento en el juego.
El punto final del juego es un sistema de software en operación; el residuo del juego es un
conjunto de registros que ayudarán a los jugadores a participar en el próximo juego. El
juego siguiente es la modificación o el reemplazo del sistema, o quizá la creación de un
sistema colindante."
Alistair Cockburn

Las personas son un componente variable no lineal de primer orden

Se enuncia que las personas:

• Se comunican mejor cara a cara.
• Se sienten en apuros si actúan en forma consistente todo el tiempo
• Son altamente variables
• Toman iniciativa

Alistair Cockburn destaca que durante años se le presentaron los siguientes dos
problemas cada vez que intentaba implantar una metodología:

Problem 1. The people on the projects were not interested in learning our system.
Problem 2. They were successfully able to ignore us, and were still delivering
software, anyway
La conclusión que extrae es que hay que preguntarse cuales son las características de las
personas que afectan el desarrollo de software y cuales son sus implicaciones en el diseño
de las metodologías.

Crystal Clear
La familia de metodologías Crystal está pensada para ser adaptada a diferentes tipos de
proyectos y tamaño de los equipos y los colores con que se denominan representan que la
metodología tiene mayor
“peso” cuanto más oscuros
son.

Basado en las
dimensiones de cantidad de
personas involucradas en el
desarrollo y criticidad del
sistema se propone el cuadro
que se muestra en figura 12
como guía para seleccionar el
marco metodológico
apropiado al proyecto.

Figura 12 – Alistair Cockburn
http://www.crystalmethodologies.org/articles/mpp/methodologyperproject.html


Crystal Clear está recomendada para grupos de desarrollo pequeños, en lo posible de
hasta 6 desarrolladores y para proyectos no involucrados con el control de vida, pues
carece de buena coordinación entre grupos y le falta verificación de correctitud.
Los valores en particular son:
Fuerte en comunicación, ‘liviana’ en entregables, mantiene los caminos de
comunicación cortos e informales, produce entregas frecuentes

Descripción de la Metodología

Ciclo de vida
Nota: En general el ciclo de vida que se detalla es común a Crystal Clear y Crystal
Orange, salvo que en Crystal Orange en las versiones interviene más de un equipo de
desarrollo (hasta 40 desarrolladores) y se establecen mecanismos para la comunicación
entre los grupos exigiéndose mayor documentación y más formalidad en los
procedimientos.

El sistema a desarrollar se va construyendo en Incrementos donde cada incremento
consta de los siguientes pasos:

Stagging

• Se hacen entrevistas a usuarios y ejecutivos.
• Se observa a los usuarios haciendo su trabajo.
• Se documentan los requerimientos en la forma de casos de uso breves o “stories”
(descripciones de la funcionalidad).
• Se priorizan las “stories” de acuerdo con los usuarios, en base a las de mayor valor o
necesidad.
• Se determinan los requerimientos tecnológicos y se establece la arquitectura de base.
• Se hace el plan de versiones, con períodos de 1 a 3 meses entre entrega de cada
versión.

Releases

• Las versiones se van construyendo en iteraciones. El producto final de las
iteraciones es una versión usable para el usuario.
• En cada versión se ajusta el conjunto de políticas estándares y locales, “works
products”10, actividades, roles, estándares y herramientas a aplicar (es decir, la
metodología) de acuerdo a la experiencia recogida en la versión anterior.
• Dentro de cada iteración se cumplen etapas de Construcción, Demostración y
Revisión con fuerte intervención de los usuarios.
• Dentro de cada versión se sugieren dos revisiones generales por parte de los
usuarios, una al poco tiempo de comenzar (2 días hasta 2 semanas) y otra con un
prototipo funcional a la mitad del período de la versión.
• Se monitorea el progreso y la estabilidad. Para medir el progreso el plan incluye
mojones como “inicio”, “revisión”, “test”, “entregable” y para medir la estabilidad
se utilizan estados a saber “muy fluctuante”, . “fluctuante”, “listo para revisión”.

10
En Crystal Clear se definen 20 Work Products que cada proyecto debe producir. Ver ROLES.


• Las técnicas de trabajo a utilizar admiten la utilización de practicas de otras otras
metodologías como XP y SCRUM.

Reflection WorkShop

• Antes y después de cada incremento se prescriben reuniones del equipo con el
objetivo de discutir el proceso y ajustar la metodología.

Roles
La función de cada rol está descripta en base a los “work products” que debe entregar y
mantener. En todo proyecto Crystal Clear se definen 20 “work productos” que deben
entregarse:
Rol Producto
Sponsor 1 Mission Statement
Coordinador 2 Secuencia de versiones
3 Cronograma de versiones
4 Lista de riesgos
4ª Estado de proyecto
Senior Designer 5 Estructura del equipo
6 Metodología
7 Diseño del sistema
Business Expert 8 Parejas de actores-objetivos
9 Casos de uso
10 Documentar requerimientos
Users 11 Ayuda caso uso y pantallas
Designers 12 Borradores pantallas
13 Diseño y notas
14 Modelo de objetos
15 Código fuente
16 Sistema “Empaquetado”
17 Código de migración
18 Casos de Test
Tester 19 Test y Reportes errores
Writer 20 Manuales de usuario

Políticas Estándares

Se deben usar las siguiente políticas estándares:
• Uso de incrementos con mojones para medir el progreso y riesgos.
• Escenarios de uso para capturar requerimientos.
• Testing de regresión.
• Revisión de código entre pares.
• Usuarios involucrados directamente.

Estándares Locales

Se deben tener conjuntos de estándares locales para:
• Estilos de programación


• Diseño de pantallas
• Marco para test de regresión


► postula modificar la metodología a medida que se avanza en el proyecto.
► el acento en la comunicación entre los individuos.
► funciona como marco para metodologías como xp.

Adaptative Software Development
Se citarán solo valores, principios y el ciclo de vida.

Valores y Principios
Se considera que la planificación es una paradoja en ambientes adaptativos y que en un
ambiente de impredicibilidad las personas deben de colaborar enriquecedoramente para
lidiar con la falta de certeza. Se sostiene que los cambios no deben ser vistos como una
desviación del plan a corregir, sino como el camino hacia el producto final adecuado.

Algunas frases de HighSmith nos ilustran al respecto:
“In an adaptive environment, learning challenges all stakeholders - developers and
their customers - to examine their assumptions and to use the results of each
development cycle to adapt the next. “ -- [Highsmith]
“The overriding, powerful, indivisible, predominant benefit of the Adaptive
Development Life Cycle is that it forces us to confront the mental models that are at
the root of our self-delusion. It forces us to more realistically estimate our ability.”
-- [Highsmith]
Ciclo de vida
Los proyectos son obtenidos en iteraciones como resultado de ciclos de 3 fases:

Speculation
Comienza con una subfase de Iniciación de Proyecto que define la misión del proyecto,
para luego dar lugar a la subfase de Planificación del Ciclo Adaptativo donde se fija la
agenda global, y la agenda y objetivos de cada ciclo de desarrollo.

Collaboration
Son los ciclos de desarrollo propiamente dichos, que deben durar entre 4 y 8 semanas, y
se desarrollan componentes de software en forma concurrente, refinándoles en cada ciclo.

Learn
Se hacen revisiones de calidad y se demuestra la funcionalidad implementada durante el
ciclo, con la participación del cliente. Con el conocimiento obtenido al final de cada ciclo
se alimenta la fase de Speculation para el próximo. Son críticos los post-mortem de los
proyectos.


Dynamic System Development Method

Es una metodología de amplia aceptación dentro del Reino Unido, donde se utiliza
desde 1994 siendo mantenida y actualizada por el DSDM Consortium.

Los miembros de dicho consorcio usan la metodología y se comprometen a aportar
conocimiento a la misma.

Valores
Parte de una idea que consiste que en lugar de fijar la funcionalidad y en base a ella
ajustar el tiempo y los recursos se proceda en forma inversa, fijando el tiempo y los
recursos con que se cuenta ajustando en base a esto el monto de funcionalidad que se
puede obtener.

Se sostiene que con la aplicación de los conceptos anteriores, con el fuerte
involucramiento que se hace del usuario a lo largo de todo el ciclo de vida y con la
metodología que se ha desarrollado se aportan los siguientes beneficios:

• Los usuarios se sienten dueños del sistema
• El riesgo de construir el sistema equivocado se reduce mucho
• El sistema final tiene alta probabilidad de ajustar a los requerimientos reales
• Los usuarios resultan mejor entrenados

Principios

- El involucramiento activo del usuario es imperativo.
- El equipo debe ser facultado a tomar decisiones.
- El foco se pone en la entrega frecuente de productos.
- Ajustarse a los propósitos del negocio es el criterio esencial de aceptación de
entregables.
- Entregas iterativas e incrementales son necesarias para converger en soluciones
apropiadas al negocio.
- Todos los cambios durante desarrollo son reversibles.
- Requerimientos a alto nivel en etapas tempranas.
Nota: Los requerimientos de alto nivel son congelados en etapas tempranas y los
nuevos requerimientos o la refinación de los anteriores se van congelando a medida
que resultan claros para todos.
- El testing debe estar integrado a todo el ciclo de vida.
- La colaboración y cooperación entre todos los involucrados es esencial.

Ciclo de Vida

El ciclo de vida de DSDM es iterativo e incremental.


Cada iteración se ajusta a un predefinido período de tiempo y debe completarse dentro
del mismo (días o semanas)
El sistema a construir es entregado al cliente en la forma de una serie de incrementos de
forma tal que la funcionalidad más importante es entregada primero relegándose la menos
necesaria o importante.

Consta de 7 fases que se describen a continuación:

Al comienzo del proyecto se dan las siguientes fases en forma secuencial

Pre-Project

Se obtiene la certeza que el proyecto es el correcto.

Feasibily Study

En esta fase se determina en primera instancia si es posible usar DSDM o no para el
proyecto que se pretende llevar adelante.
Se hace un análisis de las posibilidades técnicas de llevarlo adelante junto con un
análisis de los riesgos y otras consideraciones.
La salida de esta fase está dada por dos reportes: reporte de factibilidad y un plan
general
Esta etapa no debería llevar más de 2 semanas.

Business Study

Se hace el estudio del negocio capturando las principales características del mismo así
como se estudian los aspectos tecnológicos. Para lograrlo se hacen reuniones de trabajo
con expertos del cliente. Se documentan los procesos y se identifican las clases de usuario.
Se obtienen además como salidas de la fase otros dos documentos: La definición de la
arquitectura del sistema y un plan de prototipos.

Las siguientes fases son iterativas e incrementales y se pueden mezclar y solapar
según se determine para cada proyecto

Funtional Mode Iteration

Es la primera fase iterativa e incremental . Se hace análisis y codificación y se
construyen prototipos que se usan para refinar el análisis, verificándolos con los usuarios.
Los prototipos van adquiriendo calidad y son sometidos a testing extensivo, pudiendo
llegar a integrar el producto final.
Al final de las iteraciones de la fase se obtiene un modelo funcional contiendo un
prototipo y el resultado del análisis. Conjuntamente se obtiene una lista priorizada de
funciones para la siguiente iteración, comentarios de los usuarios sobre el prototipo,
requerimientos que se dejan para la próxima fase y un análisis de riesgo.


Design and Builds Iteration

Aquí realmente es donde se construye el sistema.
La salida es un sistema testeado que cumple con un mínimo conjunto de requerimientos.
Esta fase es también iterativa, y los prototipos los revisa el usuario.

Implementation

Consiste en la etapa en la cual el sistema pasa de desarrollo a producción.
Se entrena a los usuarios.
Si el sistema a implementar es grande se pueden hacer iteraciones también para la
implementación.
Como salidas se obtienen los manuales de los usuarios, el sistema en producción y un
reporte de revisión del proyecto.

En la figura 13 se muestran con 4 flechas el curso del proyecto luego de la fase de
implementación.

Una vez completo el proyecto se ejecuta la fase final.

Figura 13 - Ciclo de vida de DSDM. www.dsdm.org Dsdm_overview.pdf

Post-Project

Corresponde al cierre del proyecto. Se disuelve el equipo de desarrollo y a partir de aquí
se mantiene el sistema funcionando efectivamente y chequeando que los beneficios
esperados se sigan cumpliendo.

Roles
Mencionaremos solo algunos de los roles que la metodología define:


Technical Coordinator
Define la arquitectura del sistema.
Coordina el proyecto y usa el software de administración de configuraciones.
Es responsable por la calidad técnica del proyecto.

Senior Developers
Desarrolladores con más experiencia y capacidad de liderar equipos.

Developers
Son los analistas, diseñadores, tester y programadores.

Executive Sponsor
Es una persona de la organización del cliente con responsabilidades financieras y
jerárquicas y es quien toma por último las decisiones.

Ambassador User
Es el usuario encargado de brindar a los demás el conocimiento sobre el sistema, en
que fase de desarrollo se encuentra, etc.

Advisor Users
Son representantes de los diferentes puntos de vista de la organización sobre el
proyecto (por ejemplo Auditores, Responsables de Seguridad, Gerencia Financiera,
etc.)

Visionary
Es el usuario participante con mejor percepción de los objetivos del negocio, del
proyecto y del sistema. Su tarea consiste en que el proyecto se mantenga en la
dirección correcta. Es común que él haya sido el usuario que propuso el sistema.

Integración DSDM y XP

Los proponentes de DSDM sostienen que XP es una metodología basada
fundamentalmente en un conjunto de técnicas muy precisas y que DSDM brinda un marco
de control de los proyectos por lo que la integración de XP bajo el marco de DSDM no
solo es posible sino que puede traer beneficios.
Sostienen también que subsisten problemas a resolver tales como que XP parece muy
enfocado a la programación orientada a objetos y DSDM no, que en otros ambientes el
continuo testing es difícil de lograr y la programación en parejas no es aceptada por todos
los desarrolladores.

► Resulta muy interesante el cambio de óptica para fijar las dimensiones del proyecto
ya que al marcar primero el tiempo y el costo estos estarán muy controlados, y en
base a ellos se determina la funcionalidad que se puede obtener.
► El manual de la metodología y otros documentos, así como ‘templates’, etc. están
disponibles solo para “full members” del consorcio.


Feature Driven Development


Fue presentada por Peter Codd y ha sido desarrollada por Peter Coad, Jeff Lucas y
Stephen Palmer.

Peter Coad y Jeff De Luca, con Stephen Palmer, desarrollaron FDD inicialmente en la
práctica, en un gran proyecto de software en 1998. En 1999, Peter and Jeff escribieron un
capítulo sobre FDD en su libro “Java Modeling in Color with UML”.

En 2002, Stephen Palmer y John Felsing extendieron, mejoraron y avanzaron FDD,
resultando en el libro “A Practical Guide to Feature-Driven Development.”.

“...the first implementation "ala FDD" was coded by Herman Veluwenkamp to my
requirements in early 1998. That implementation was incrementally enhanced through
1998 and 1999 by Herman from my requirements but also from feedback by several other
people. I may have missed a name or two but the people most likely to have had some
influence on it are Cecilia Kiew and Stephen Palmer. Herman also made many
incremental enhancements to that system himself”. [Jeff De Lucca]

Valores

La metodología FDD según sus autores es adaptable a equipos y proyectos grandes, y es
adecuada para el desarrollo de sistemas críticos.

Se presenta como una metodología iterativa y adaptativa que se focaliza en el diseño y
en las etapas de construcción.
.
“...Feature-Driven Development is a new, valuable and flexible tool that enables people -
the essence of any project, IT or otherwise - to work in a efficient and productive way with
a minimum of fuss for a maximum of output” [Sherman, Robert]

“FDD subscribes to those four statements and it isn't the same as all other Agile methods.
For example, FDD values design over the code is the design. FDD values design first. The
unit of development and thus an increment in an FDD project - a feature - is tiny; more
granular than the iterations in other processes. Features (tiny, granular pieces of client-
valued function) are being completed every week in an FDD project - and completed is
terrific word to get used in a project. ” [Sherman, Robert]


Descripción de la Metodología11

Ciclo de Vida

FDD consiste en 5 procesos secuenciales, ejecutándose los dos últimos en forma iterativa.

Importante: En la descripción de la metodología se hacen referencias muy claras a OO,
pero creemos que aunque no se trabaje en ese ámbito igual el ciclo de vida podría ser
adaptable a otro tipo de desarrollo.

FDD - Feature Driven Development

FddOverview.pdf

Develop an Overall Model

Es la actividad inicial realizada por los desarrolladores y expertos del domino bajo la
dirección de quien ocupa el rol de Arquitecto Principal.
Se hace una descripción superficial del modelo (Domain Walk-trough) por parte de los
expertos del dominio, luego se subdivide por área y se crean equipos de desarrolladores y
expertos. Dichos equipos elaboran una descripción más detallada dividiéndose en
pequeños grupos de trabajo.
Cada grupo de trabajo compone entonces un modelo de objetos para el área a su
estudio.
Una vez realizados los modelos de objetos se presentan para revisión entre pares a los
demás grupos del área. Uno de los modelos, o la mezcla de algunos, es aprobado.

11
La metodología está fuertemente ligada a OO. Esto también lo hemos notado en XP y en SCRUM.


Los modelos por área se van uniendo para construir el modelo global, que será
iterativamente modificado con el resultado del proceso “design by feature” que se
describirá más adelante.
Criterio de entrada: Las personas han sido seleccionadas.
Criterio de salida: Modelo global aprobado por los participantes (incluye el modelo
propiamente dicho, los walk-throughs y requerimientos).

Build a Features List

Se identifican todas las características del modelo (features).12
Se hace una descomposición funcional en “Subject Areas” con detalle de “Business
Activities” (actividades del negocio) y “Steps” (pasos).
Se categoriza la lista de “features” y se presenta a su revisión por usuarios y
patrocinantes del proyecto.
Criterio de Entrada: Modelo global completo.
Criterio de salida: “Features List”.

Plan by Feature

Se planifica el orden en que las “features” serán desarrolladas.
Es un plan de alto nivel. Las clases identificadas en el primer paso se asignan a
desarrolladores individuales.
Se establecen los primeros “milestones” para control futuro del plan.
Criterio de entrada: “Feature List”.
Criterio de salida: Plan de desarrollo con fechas (mes/año) y asignación de clases a
dueños.

Los siguientes dos procesos son iterativos:

Design by Feature

Se selecciona un conjunto de “features” que se le asignan a un programador en jefe (en
su ‘caja de entrada’). El programador en jefe va tomando las “features” y forma el equipo
que las desarrollará.
Se construye el diagrama de secuencias y el programador en jefe refina el Modelo de
objetos. Los programadores escriben las clases y los “method prologues”.
Se hacen inspecciones de diseño.
Criterio de entrada: El plan está pronto.
Criterio de salida: Paquete de diseño completo (Incluye memos, diagramas de
secuencia, calendarios y to-do list detalladas por clases, documentación de los
requerimientos asociados si los hay, el Modelo actualizado, etc.)

Build by Feature

Se codifica, se hace testing, se inspecciona el código, se integra.
Criterio de Entrada: Paquete de diseño completo.
Criterio de Salida: “package” completo que puede ser integrado.

12
Cada “feature” deberá ser posible desarrollarla en menos de 2 semanas.


Roles
Se describen brevemente lo roles más importantes:

Project Manager
Líder administrativo y financiero del proyecto.

Chief Arquitect
Diseño global del sistema. Toma las decisiones finales sobre el diseño.

Chief Programmer13
Uno de los roles claves. Lidera el grupo que desarrolla las “features”.

Class Owner
Es el responsable por el diseño y e implementación de una clase.

Programmer

Otros roles

Domain Experts
Expertos en el dominio de la aplicación.

Build Engineer
Es el responsable de mantener el proceso de construcción (Build) y administra el
versionado y publicación.

► revisión entre pares
► inspecciones de código
► Class Owner
► Foco en el diseño
► Granularidad obtenida al constuir por “features”

13
Coad sostiene que adicionar personas a este rol y ponerles equipos a trabajar con él acelera los proyectos, a pesar de la regla de Fred
Brooks sobre adicionar programadores a un proyecto una vez comenzado.


Valoración de Metodologías Ágiles a CMM
Se han efectuado valoraciones de las metodologías ágiles a CMM de las cuales
presentamos las siguientes dando indicación del origen de la información. 14
Un signo de ‘+’ indica que cumple parcialmente y un ‘++’ que cumple en mayor medida.

Nivel KPA XP Crystal Scrum
Requirements Management 2 RM ++ ++ ++
Softw are Project Planning 2 SPP ++ ++ ++
Softw are Project Tracking and Oversight 2 SPTO ++ ++ ++
Softw are Subcontract Management 2 SSM
Softw are Quality Assurance 2 SQA +
Softw are Configuration Management 2 SCM + + +
Organization Process Focus 3 OPF + + +
Organization Process Definition 3 OPD + + +
Training Program 3 TP
Integrated Softw are Management 3 ISE
Softw are Product Engineering 3 SPE ++ ++ ++
Intergroup Coordination 3 IC ++ + +
Peer Review s 3 PR ++ ++
Quantitative Process Management 4 QPM
Softw are Quality Management 4 SQM
Defect Prevention 5 DP +
Technology Change Management 5 TCM
Process Change Management 5 PCM
Carniege M. University, Soft.Inst., E-SEPG 2001 Mark C. Paul
An Assessment of Scrum with the sw-cmm Seth Bowen

Entre Ágiles y Monumentales - Ken Orr: Next Practice
Considerando que según Clayton Christensen (disruptive technologies), a veces las
buenas prácticas no son suficientes y hay que dar un paso mas, Ken Orr rotuló a este nivel
más elevado, Next Practice.
Para Ken Orr muchas
organizaciones están atrapadas
entre mucha documentación,
(metodologías tradicionales) y muy
poca documentación (metodologías
ágiles).
Next Practice tiene que ver con
la relación entre conocimiento y
esfuerzo. Mediante la figura 14, el
autor, ilustra esa relación.

Figura 14 - Advanced agile development.

14
No hemos tenido contacto con valoraciones efectuadas para la PA de CMMI, probablemente por la reciente aparición de dicho
modelo.


Comentarios finales
¿Cómo mejorar el proceso de desarrollo de software?

Algunas ideas, nada nuevo...

• Aplicar metodologías que disciplinen sin que se conviertan en un obstáculo.
• De cada metodología la parte que mejor se adapte (sin ‘credos’) y adaptar las
metodologías a las personas involucradas y a cada proyecto.
• Tener memoria de los proyectos y experiencias pasadas.
• Comenzar el proceso de mejora cuanto antes (estrategia de supervivencia).
• Utilizar las mejores herramientas a las que se tenga acceso que apliquen a la meta de
producir software de mejor calidad en el menor plazo y con el menor esfuerzo.
Recordar que muchas veces la utilización de una herramienta de desarrollo introduce
una metodología y disciplina.
• Tener siempre presente que no se ha encontrado aún la Bala de Plata. Recordar que al
introducir una herramienta que permite proceder en forma ágil se puede caer en la
tentación de no planificar.
• Definir estándares, políticas y procedimientos, documentarlos en forma breve,
difundir y aplicar.
• Documentar usando las posibilidades de las herramientas (en fuentes, en los
receptáculos donde lo permitan, etc.). Algo tan simple como usar las carpetas
compartidas del correo electrónico para almacenar documentación o scanear los
diagramas efectuados manualmente puede ser un buen comienzo.
• Involucrar fuertemente al usuario.
• Espíritu de cuerpo y buena comunicación en los equipos (debería ser intrínsico a
pequeñas empresas).
• Ámbito laboral adecuado.
• No reinventar la rueda.
• Capacitar de la mejor manera posible (cursos, capacitación a distancia, biblioteca,
Internet).
• Q&A (Probablemente tercerizados).
• Revisiones de Código y de Diseño.
• Usar el buen criterio al aplicar mejoras y siempre tener presente la meta del negocio
para el que se desarrolla el proyecto.
• Personal motivado y comprometido con los proyectos.
• Realizar análisis de riesgo continuos para identificar problemas potenciales antes que
ocurran.


Bibliografia y Referencias
Adaptative Software Development, http://www.adaptativesd.com

Agile Software Development Alliance, Agile Manifesto http://www.agilemanifesto.org

Agile Software Development Alliance sitio http://www.agilealliance.org

Beck Kent, http://www.extremeprogramming.org/kent.html

Beck Kent, http://www.awprofessional.com/series/index.asp?st=C9C8D6CB-E4FD-46FA-B011-
6A7C92FF9193&session_id={D04B8E49-48D6-492D-ABB2-B825D91AFA56}

Boehm Barry Get Ready for Agile Methods with Care

Boehm Barry, De Marco Tom The Agile Methods Fray

Bowen Seth An Assessment of Scrum with the SW-CMM

CMMI sitio http://www.sei.cmu.edu/

Charette, Robert The decision is in: Agile versus Heavy Methodologies
http://www.cutter.com/freestuff/epmu0119.html

Coad Peter, stio www.thecoadletter.com
http://www.thecoadletter.com/download/bookpdfs/jmcuch06.pdf

Coad Peter Using Strategy and Process to guide Software Development

Coad Peter, De Luca, Lebfebvre Java Modeling in Color with UML, chapter 6

Cockburn Alistair, Balancing Lightness with Sufficiency
http://www.crystalmethodologies.org/articles/blws/balancinglightnesswithsufficiency.html

Cockburn Alistair, Crystal Clear: An Human-Powered Methodology for small teams
http://members.aol.com/humansandt/crystal/clear.

CockBurn Alistair, People as not a Linear Components
http://www.crystalmethodologies.org/

Cockburn Alistair, Software Development as a Cooperative Game
http://members.aol.com/humansandt/papers/asgame/asgame.htm

Cockburn Alistair, Methodology per project
http://www.crystalmethodologies.org/articles/mpp/methodologyperproject.html

Cockburn Alistair http://members.aol.com/acockburn

Crystal Methodology sitio http://www.crystalmethodology.org

Davies Rachel The power of Stories


De Luca, Jeff The latest FDD processes- http://www.nebulon.com

DSDM, DSDM and Extreme Programming http://www.dsdm.org/kss/download.asp?fileid=66

DSDM, sitio http://www.dsdm.org

DSDM Introducing DSDM into an organization

Extreme Programming sitio http://www.ExtremeProgramming.org

Fowler Martin The New Methodology
http://www.martinfowler.com

Glass, R. Frequently Forgotten Fundamental Facts about Software Engineering

Glass, R. Agile Vs. Traditional: Make Love, not War!

Galloso Manuel y Abin Jorge CMM Aplicación A Empresas Uruguayas

HighSmith, Jim and Martin Fowler
http://www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm

HighSmith, Jim DSDM and the Agile Software Development Movement

HighSmith, Jim Openning Statement The Great Methodologies Debate cutter it journal
Vol 14 nro.12

Hussman, David Test First Design with UML A Picture is Worth a thousand programmers

Jeffries Rod, sitio Extreme Programming http://www.xprogramming.org

Juhani W, Sale J, Pekka O. Agile Software Development Methods

Karlstrom Daniel Introducing Extreme Programming, an experience report

Nebulon (FDD) Feature Driven Development, an Overview

Moss, Larissa Business Intelligence Methodologies: Agile with Rigor?
Cutter journal vol 14 nro. 12

Orr, Ken CMM versus Agile Development: Religious War and Software Development
http://www.cutter.com

Orr, Ken Next practice: http://www.kenorrinst.com

Paulk, Mark, Using the software CMM in small organizations
www.sei.cmu.edu/activities/cmm/papers/cmm-small.pdf


Paulk, Mark, Agile Methodologies from a CMM perspective

Paulk, Mark, Extreme Programming from a CMM Perpective

Paulk, Mark, Using the software CMM with good judgment

Paulk, Mark, Using the software CMM in Small Projects and Small Organizations

Phillips Johnson. Introduction to Agile Development Methods

Phillips, Mike CMMI V1.1 Tutorial

SCRUM sitio http://www.controlchaos.com

SEI http://www.sei.cmu.edu/

Sherman, Robert http://www.nebulon.com/fdd/index.html

Shuterlan, Jeff http://jeffshuterlan.com/scrum/archive.html

Shuterlan, Jeff Agile can Scale: Inventing and Reinventing SCRUM in five companies
Cutter journal vol 14 nro.12

Stapleton J., DSDM Dinamyc System Development Method www.dsdm.org

Seth Bowen An Assessment of Scrum with the sw-cmm

Terttu Orci, Capability Maturity Model for Extra Extra Small Organizations Level 2
Version 1.0, 2000-09-10

Terttu Orci, Capability Maturity Model for Extra Small Organizations Level 2 Version 1.0,
2000-09-10

Terttu Orci y Astrid Laryd, Dynamic CMM for Small Organizations, 1999

Terttu Orci y Astrid Laryd, Dynamic CMM for Small Organizations – Implementation
Aspects, 2000

Wagner Larry Extreme Requirements Engineering
Cutter Journal vol 14 nro.12


Propuesta mejora proceso desarrollo Software (2002) (Diaz Arnesto, Araújo)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Propuesta mejora proceso desarrollo Software (2002) (Diaz Arnesto, Araújo)

Similar a Propuesta mejora proceso desarrollo Software (2002) (Diaz Arnesto, Araújo) (20)

Más de Alejandro Araújo

Más de Alejandro Araújo (12)

Último

Último (15)

Propuesta mejora proceso desarrollo Software (2002) (Diaz Arnesto, Araújo)