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

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

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 Interamericano de Desarrollo (TC-99-10-05-6-UR) del año 1999, en Uruguay hay 250 empresas dedicadas al desarrollo de software y consultoría en informática.1

La figura 1 muestra, de acuerdo a la información disponible (170 empresas), la distribución respecto al 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:

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.

Orientadas a los procesos

Predictivas

Orientadas hacia las personas

Adaptativas

Monumentales

Agiles

70 66

34

170

80

Sin datos

Hasta 4De 5 a 20

Más de 20

Personas

Empresas

Figura 1 – Personal empleado

http://www.sei.cmu.edu/activities/cmm/papers/cmm-small.pdf




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.

http://www.crystalmethodologies.org/articles/blws/balancinglightnesswithsufficiency.html


¿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 con sus 5 niveles de maduración. Al hablar de implantar CMM en pequeñas

empresas se plantean muchos problemas:

• Gran cantidad de Roles • Documentación excesiva • Procedimientos rígidos • Manuales extensos • Costos de implementación • Cursos • 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 tiene en cada área de proceso. Niveles de Capacidad:

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

0 - Incompleto

1 - Ejecutado

2 - Administrado

3 - Definido

4 - Cuantitativamente Administrado

5 - Optimizado

CMM Niveles de Maduración

Inicial

Repetible

Definido

Administrado

Optimizado

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 theU.S. Department of Defense © 1997 by Carnegie Mellon University (www.sei.edu)

Figura 2 – CMM Niveles de Maduración

Estratificada

ML 1

ML2ML3

ML4

ML5

Contínua

PA PA

Proc

ess

Are

a C

apab

ility

0

1 2

3

4

5

PA

CMMI - Comparando la representación de los modelos

CMMI Tutorial Mar 25, 2002Mike Phillips, CMMI Program Manager

Figura 3 – CMMI representaciones

Propuesta para la mejora del pr

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:

¿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.

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability LevelsGeneric Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability Levels

Las Areas de Procesoidentifican

“que se hace”

Los Niveles de Capacidad identifican

“que tan bien se hace”

1 - Inicial

2 - Administrado

3 - Definido

4 - Cuantitativamente Administrado

5 - Optimizado

Figura 4 - Componentes del modelo CMMI

oceso de desarrollo de software en pequeñas empresas Pág. 5


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 realiza pasando de un nivel a otro pero sin saltear ninguno y las áreas de proceso pueden estar a distintos niveles como lo indica la figura 5.

Para que un área de proceso tenga por ejemplo nivel de capacidad 2, se deben satisfacer las metas específicas, las prácticas específicas de nivel 2 y las metas genéricas de nivel 2 para esa área de proceso.

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

Niveles de Capacidad

• Los valores en el eje de las ordenadas describencuan bien se ejecuta un proceso.

Cap

abili

ty

Procesos

ProcessArea 1

ProcessArea n

ProcessArea 2

ProcessArea 3

Proceso bien realizado y continuamente mejorado

Proceso no realizado

ProcessArea 4

Incompleto

Ejecutado

AdministradoDefinido

Cuant.Administrado

Optimizado

Sin saltos1

2

34

5

0

CMMI Tutorial Mar 25, 2002Mike Phillips, CMMI Program Manager

Figura 5 – Niveles de Capacidad

http://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. CMMIProcess Areas

Defect Prevention Causa l Ana lys is and ResolutionTechnology Change Mgmt Organiza tiona l Innova tion & Deployme ntProcess Change Management

Quantita tive Proces s Mgmt Organiza tiona l Process PerformanceSoftware Qua lity Mgmt Quantita tive Project Management

Organiza tion Process Focus Organiza tion Process FocusOrganiza tion Process Definition Organiza tion Process DefinitionTra ining Program Organiza tiona l Tra iningIntegra ted Software Mgmt Integra ted Project Management

Ris k ManagementSoftware Product Engr Requireme nts De velo pment

Technical Solutio nProduct Integ ration

Inte rgroup Coordina tion VerificationPeer Reviews Validation

Decis ion Analys is and Res o lution

Requirements Management Requirements ManagementSoftware Project P lanning Project PlanningSoftware Project Tracking & Overs ight Project Monitoring and ControlSoftware Subcontract Mgmt Supplie r Agreement ManagementSoftware Qua lity Assurance Product & Process Qua lity AssuranceSoftware Configura tion Mgmt Configura tion Management

Meas urement and Analys is

LEVEL 5OPTIMIZING

LEVEL 4MANAGED

LEVEL 3DEFINED

LEVEL 2REPEATABLE

86Mike Phillips, CMMI Program Manager

¿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.

Figura 6 – Comparación CMM - CMMI


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)."

En el segundo diagrama (figura 8) se contempla la aparición de varios proyectos y dos

nuevos roles: sales y project manager.

Figura 7 – Roles en XXS – Laryd/Orci

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.

http://www.sei.cmu.edu/cmmi/models/models.html

http://www.agilemanifesto.org/


http://www.agilealliance.org/home

http://www.agilealliance.org/home


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.

http://www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm

http://www.agilemanifesto.org/authors.html

http://www.sdmagazine.com/sdonline/authors.html#jhighsmith


• 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]



http://www.sdmagazine.com/sdonline/authors.html#jhighsmith


“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.

http://www.crystalmethodologies.org/articles/panlc/peopleasnonlinearcomponents.html

http://www.alistaircockburn.us/


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.

5 DSDM is a registered trademark of Dynamic Systems Development Method Limited. (c) 2001 by Dynamic Systems Development Method Limited

Figura 9 Utilización de metodologías ágiles

http://www.extremeprogramming.org/


http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

http://www.xprogramming.com/

http://www.controlchaos.com/

http://www.jaist.ac.jp/~kouhou/FP/e/ks/nonaka.html

http://jeffsutherland.com/scrum/archive.html

http://www.crystalmethodologies.org/

http://www.alistaircockburn.us/

http://www.dsdm.org/

http://www.thecoadletter.com/download/fddguide/index.html

http://www.thecoadletter.com/speak/#coad

http://www.nebulon.com/

http://www.cutter.com/freestuff/epmu0119.html


http://www.cutter.com/consultants/charetter.html


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]

http://www.extremeprogramming.org/

http://c2.com/cgi/wiki?TheThreeExtremos

http://www.extremeprogramming.org/kent.html


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



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

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

http://www.extremeprogramming.org/rules.html


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:

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.

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


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 Breve Reseña Histórica

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”


http://www.controlchaos.com/ap.htm

http://www.controlchaos.com/philo.htm

http://jeffsutherland.com/scrum/archive.html


• 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 Puntos a tener en cuenta:

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

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.



http://www.crystalmethodologies.org/articles/mpp/methodologyperproject.html



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

http://members.aol.com/humansandt/papers/asgame/asgame.htm

http://www.crystalmethodologies.org/articles/panlc/peopleasnonlinearcomponents.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.

http://www.adaptivesd.com/

http://www.amazon.com/exec/obidos/ASIN/0932633404

http://www.amazon.com/exec/obidos/ASIN/0932633404


Dynamic System Development Method

Breve Reseña Histórica 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.

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:

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


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.

http://www.dsdm.org/kss/download.asp?fileid=66


Feature Driven Development Breve Reseña Histórica

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]

http://www.thecoadletter.com/download/bookpdfs/JMCUCH06.pdf


http://www.nebulon.com/fdd/index.html



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.

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.

FddOverview.pdf

FDD - Feature Driven Development


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.

Puntos a tener en cuenta: 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.

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.

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

Nivel KPA XP Crystal ScrumRequirements Management 2 RM ++ ++ ++Software Project Planning 2 SPP ++ ++ ++Software Project Tracking and Oversight 2 SPTO ++ ++ ++Software Subcontract Management 2 SSMSoftware Quality Assurance 2 SQA +Software Configuration Management 2 SCM + + +Organization Process Focus 3 OPF + + +Organization Process Definition 3 OPD + + +Training Program 3 TPIntegrated Software Management 3 ISESoftware Product Engineering 3 SPE ++ ++ ++Intergroup Coordination 3 IC ++ + +Peer Reviews 3 PR ++ ++Quantitative Process Management 4 QPMSoftware Quality Management 4 SQMDefect Prevention 5 DP +Technology Change Management 5 TCMProcess 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

Figura 14 - Advanced agile development.

http://www.kenorrinst.com/


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

http://www.adaptativesd.com/



http://www.agilealliance.org/

http://www.extremeprogramming.org/kent.html



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


http://www.thecoadletter.com/download/bookpdfs/jmcuch06.pdf

http://www.crystalmethodologies.org/articles/blws/balancinglightnesswithsufficiency.html

http://members.aol.com/humansandt/crystal/clear






http://members.aol.com/acockburn

http://www.crystalmethodology.org/


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


http://www.dsdm.org/kss/download.asp?fileid=66


http://extremmingprogramming.org/

http://www.martinfowler.com/



http://www.xprogramming.org/

http://www.cutter.com/

http://www.kenorrinst.com/


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


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


http://jeffshuterlan.com/scrum/archive.html

http://jeffshuterlan.com/scrum/archive.html
