Construccion en Colaboracion

INTRODUCCION

De una forma u otra, todas las técnicas de construcción en colaboración son los intentos de formalizar el proceso de mostrar su trabajo a otra persona con el fin de eliminar errores.

1. RESEÑA DE LAS TECNICAS DE DESARROLLO EN COLABORACIÓN

La "Construcción en Colaboración" se refiere a la programación en pares, las inspecciones formales, análisis técnicos informales, y la lectura de documentos, así como otras técnicas en las que los desarrolladores deben de compartir la responsabilidad de la creación de código y otros productos de trabajo.


1.1 Construcción en Colaboración complementa otras técnicas de fortalecimiento de calidad.

El objetivo principal de la construcción en colaboración es la mejora de la calidad del software. El segundo beneficio de la construcción en colaboración es que se reduce el tiempo de desarrollo, que a su vez reduce los costos del mismo.

Los primeros informes sobre la programación en par sugieren que puede lograr un código de nivel de calidad similar al de las inspecciones formales. El desarrollo de código en pares es de un 10 a 25% mas costoso que el desarrollo de una sola persona, pero la reducción en el tiempo de desarrollo es de un 45% aproximadamente, en algunos casos suele ser una gran ventaja sobre el desarrollo de una sola persona.

Los Análisis técnicos se han estudiado mucho más tiempo que la programación en pares, y sus resultados, como se describe en los estudios de casos y en otros lugares, han sido impresionantes:

· IBM encontró que cada hora de la inspección impide cerca de 100 horas de trabajo relacionado con (prueba y corrección de defectos).
· Hewlett-Packard informó de que su programa de inspección ha ahorrado un estimado de $ 21,5 millones por año.

· Raytheon redujo su costo de corrección de defectos (reelaboración) de aproximadamente el 40% del coste total del proyecto a cerca de 20% a través de una iniciativa que se centró en las inspecciones.


Un efecto secundario es que cuando las personas saben que su trabajo será examinado, se dedican a analizar más detenidamente. Así pues, aun cuando las pruebas se realizan de manera eficaz, exámenes u otros tipos de colaboración son necesarios como parte de un programa de calidad.

2. PROGRAMACIÓN EN PAREJA
En esta un programador esta en el teclado y el otro programador observa los errores y piensa estratégicamente acerca de si el código está escrito correctamente.

2.1 Claves para el Éxito

El concepto básico de la programación en pareja es simple, pero su uso, sin embargo, se beneficia de algunas directrices:

· Apoyo a la programación en pareja con una codificación estándar: No será eficaz si las dos personas pasan el tiempo discutiendo sobre el estilo de codificación.

· No dejar que la programación en pareja se convierta solo en observación: La persona sin el teclado debe ser un participante activo en la programación. Esa persona está analizando el código, y debe adelantarse a lo que se codificará, evaluar el diseño, la planificación y la forma de probar el código.

· Alternar las parejas y tareas de trabajo regularmente: el beneficio esta en que hay programadores aprendiendo de las diferentes partes del sistema.

· Alentar a las parejas para que vallan al ritmo de los demás: Uno va demasiado rápido limita el beneficio de contar con opiniones del otro socio.


· Asegúrese de que ambos socios pueden ver el monitor.


· No obligar a trabajar con una persona que no es de su agrado: A veces, conflictos de personalidad, impiden a las personas un trabajo eficaz.

· Evite emparejar todos los novatos: funciona mejor cuando al menos uno de los socios tiene experiencia.

· Asignar un jefe de equipo: Si su equipo quiere hacer 100 por ciento de su programación en pareja, sólo deberá asignar a una persona para coordinar las tareas de trabajo, que se considerará responsables de los resultados, y actuar como punto de contacto para las personas fuera del ámbito del proyecto.


2.2 Beneficios de la Programación en Pareja

· Se elimina un poco el estrés por desarrollo en solitario.

· Se mejora la calidad del código. La legibilidad y comprensibilidad del mismo tiende a aumentar con el nivel del mejor programador en el equipo.

· Se acorta horarios. Pares tienden a escribir código más rápido y con menos errores. El equipo del proyecto dedica menos tiempo al final en la corrección de los defectos del proyecto.

3. LAS INSPECCIONES FORMALES

La inspección es un tipo específico de análisis que ha demostrado ser muy eficaz en la detección de errores y de ser relativamente económico en comparación con los demás.

3.1 Que resultados puedo esperar de las inspecciones?

Las inspecciones normalmente eliminan 70-85% o más de los defectos de un producto.

Los programadores aprenden a mejorar su trabajo a través de la participación en las inspecciones, y estas aumentan la productividad en aproximadamente un 20%.
En un proyecto que utiliza las inspecciones para el diseño del código, las inspecciones se llevarán aproximadamente 10-15 por ciento del presupuesto del proyecto y normalmente reducir el costo general del mismo.

3.2 Funciones durante una Inspección

Una característica fundamental de una inspección es que cada uno de los actores tiene un papel que desempeñar, por ejemplo:

Moderador: es responsable de mantener la inspección en movimiento, a un ritmo que sea lo suficientemente rápido para ser productivas, pero con lentitud suficiente para encontrar la mayoría de los errores posibles.

Autor: La persona que hizo el diseño del código, desarrolla un papel relativamente menor en la inspección. Parte del objetivo de una inspección es para asegurarse de que el código habla por sí mismo.

Evaluador: Es cualquier persona que tenga un interés directo en el código, pero que no es el autor. Su función es encontrar errores.

Anotador: registra los errores que se detecten y los puntos que son asignados durante la reunión de inspección.

La Administración: Incluir la administración en una inspección usualmente no es una buena idea. Sin embargo, la administración tiene derecho a conocer los resultados de una inspección, lo cual se hace por medio de un informe de inspección.

3.3 Procedimiento General para una inspección

Una inspección consta de varias etapas:

Planificación: el autor le da el diseño del código al moderador. Este decide quien va a examinar el material y cuando y donde va a ocurrir la inspección, entonces le da un checklist para centrar puntos importantes.

Visión General: Cuando los encargados de revisión no están familiarizados con los proyectos en los que están trabajando, el autor puede pasar hasta una hora describiendo la técnica entorno la cual se ha hecho el diseño. Aunque el diseño del código debe hablar por si mismo, no la visión general.

Preparación: Cada examinador trabaja solo para analizar el diseño del código en la búsqueda de errores. Los examinadores utilizan el checklist para estimular y orientar su análisis.

Reunión de Inspección: El moderador elige a alguien que no sea el autor para leer el código. El encargado de registrar los errores, muestra sus registros y la discusión de un error se detiene tan pronto como se le reconoce como un error. No discutir soluciones durante la reunión. El grupo debe permanecer centrado en la identificación de los defectos.

Informe del grupo de Inspección: Este es emitido por el moderador luego de la reunión de inspección, listando cada error, incluyendo su tipo y gravedad. Esto sirve para asegurarse que todos los errores serán corregidos.

Reelaboración: el moderador asigna errores a alguien, usualmente el autor, para que los corrija.

Seguimiento: El moderador es el encargado de velar por que la modificación de todo lo asignado durante la inspección se lleve a cabo.

Reunión de Tercera Hora: Esta se realiza después que la inspección oficial ha terminado, para permitir que las partes interesadas tengan la oportunidad de debatir soluciones.


3.4 Ajuste de la Inspección

Mientras realiza las inspecciones, podrá ver que ciertos tipos de errores se producen con más frecuencia que otros. Crear una lista de verificación que llame la atención de los examinadores sobre los tipos de errores encontrados. Con el tiempo, encontrará tipos de errores que no se encuentran en la lista de control; y deberá de añadirlos.

Es posible que algunos errores en la lista de verificación inicial dejen de producirse; entonces elimínelos. Después de unas cuantas inspecciones, su organización tendrá una lista de comprobación para las inspecciones personalizada a sus necesidades.



4. OTRAS TÉCNICAS DE DESARROLLO EN COLABORACIÓN

Entre las demás técnicas tenemos Paseo, Lectura de Código y Dog and Pony Shows.

4.1 Walk-Throughs

Este es un popular tipo de análisis. Es un término que ha sido muy vagamente definido por lo que resulta un poco difícil decir lo que es. Pero ciertamente, consiste en dos o más personas discutiendo el diseño del código. Esta puede ser una reunión tanto formal como informal.

Algunas de las cosas que todos los walk-thoughs tienen en común:

· Son moderados por el autor del código bajo revisión.
· Se enfoca en cuestiones técnicas.
· Todos los participantes se preparan para la reunión leyendo el código en busca de errores.
· Tiene una duración de 30 a 60 minutos.
· Se hace énfasis en la detección de errores, no en la corrección.
· Su concepto es flexible por lo que puede ser adaptado a las necesidades específicas de quienes lo aplican.


4.1.1 Que resultados puedo esperar de Walk-Throughs?

Si esta es usada inteligentemente y con disciplina, puede producir resultados similares a los de las inspecciones formales.

Si se tiene un grupo grande de examinadores de código, la opción preferible seria walk-throughs porque proporciona más puntos de vista sobre los temas en discusión. Los roles en las inspecciones son mas formales y las personas necesitan tener experiencia para ser efectivos.

4.2 Lectura de Código

En esta técnica usted lee el código fuente en busca de errores. Además comente y califica aspectos del código como diseño, estilo, legibilidad, mantenibilidad y eficiencia.

La lectura de código consiste en dos o mas personas leyendo el código por separados y luego se reúnen con el autor para discutir sobre los errores encontrados.

La lectura de código funciona de la siguiente manera:

· El autor proporciona el código a los analistas.
· Dos o mas personas leen el código por separado. Aproximadamente 1000 líneas por día.
· Cuando los analistas terminan convocan a reunión con el autor del código. Esta debe durar aproximadamente de 1 a 2 horas y discuten sobre los problemas encontrados.
· El autor soluciona dichos problemas.


La diferencia entre esta y las inspecciones y walk-throughs es que esta basada en la lectura individual de código mas que en la misma reunión.

4.3 Dog and Pony Shows

Son evaluaciones en las que un producto de software es demostrado a un cliente. En esta el objetivo es demostrar a un cliente que el proyecto esta bien, por lo que es más bien un análisis de gestión que un análisis técnico.

5. REFERENCIAS

[1] Construcción en Colaboración (cap.21) Code Complete 2da ed.
[2] The Software-Quality landscape (cap. 20) Code Complete
[3] Developer Testing (cap. 22). Code Complete
[4] Prerequisites to Construction (cap. 3 y 4) Code Complete.