Trabajo con la

implementacin-
Diseo, codificacin
y pruebas
EQUIPO 5
SERRANO SOTO LUIS ALEJANDRO
VISCARRA HOLGUN JUAN RAMON
Problemas.
Proceso de diseo.
Asumimos que la arquitectura del sistema en desarrollo fue revisada y probada
y que estamos frente al diseo detallado de cada caso de uso. Adems de capacitar a
nuestros desarrolladores en temas de diseo tales como falencias comunes en el diseo,
criterios de buen diseo y patrones de diseo, cules son otras acciones que podramos
tomar para que nuestros diseos sean de mejor calidad. Una buena prctica que ha
mostrado dar muy buenos resultados es la revisin de los diseos en sesiones con la
participacin de pares y otros miembros de la organizacin con probada experiencia
y conocimientos. Yo he participado de estas sesiones y a decir verdad en muchas de
ellas el producto a revisar era tan importante como muchos otros que no se revisaron.
Entonces, qu revisamos, cmo seleccionamos los productos a revisar. Necesitamos
un criterio de seleccin que nos permita, por ejemplo, revisar las partes crticas, pero
tambin las partes con potenciales falencias. Pero cmo saber cules son?
Coordinacin de la construccin

Desde hace tiempo el software de los sistemas est compuesto de un gran volmen
de cdigo. Todos los miembros de los grupos de desarrollo aportan a este cdigo. Todos los
das en el ciclo de vida del proyecto cada desarrollador usa y modifica al cdigo escrito por
otro desarrollador. Esta es la fuente de muchos errores de difcil solucin. Tradicionalmente
una vez desarrollada una porcin de cdigo los desarrolladores la prueban con test
unitarios y cuando el cdigo est integrado se prueba esta integracin para luego
comprobar su funcionalidad y entonces relevar los errores y corregirlos. Este miniciclo
dentro de cada iteracin implica el desarrollo de una ceremonia muy cara en recursos.
Por esta razn es necesaria una forma de trabajo que facilite y acelere este proceso.
Adems si consideramos importante la realizacin de revisiones de cdigo, se nos plantea
un inconveniente parecido al que describimos con el diseo. Necesitamos una gua para
seleccionar los productos a revisar, de lo contrario revisaremos cdigo no importante o
quizs sin falencias y dejaremos sin revisar otros con potenciales problemas.
Pruebas

Existe un error conceptual en el ambiente de desarrollo de software acerca de

cmo
se puede garantizar la calidad de los productos que las empresas desarrolladoras
generan.
Muchos proyectos son sometidos a pruebas por parte de empresas especialistas en
testing
y como consecuencia de esto, los responsables de estos proyectos piensan que de
esta
forma estn cubiertas las actividades orientadas a la mejora de la calidad. Sin
embargo lo
que sucede en la mayora de estos casos es que les cobran por decirles cuntos
errores su
software todava tiene. Realizar este tipo de pruebas no contribuye a la mejora de la
calidad
sino a la deteccin de errores y en el mejor de los casos direcciona posibles
soluciones.
 Como conclusin podemos mencionar entonces que las razones para
cambiar la forma de trabajo con las pruebas son:
El ciclo de prueba manual es muy largo
El proceso de prueba manual es propenso a errores
Liberar a la gente para realizar tareas creativas
Generar un ambiente de confianza soportado por los test
Obtener realimentacin de forma temprana y con alta frecuencia
Generar conocimiento del sistema en desarrollo a partir de los test
Generar documentacin consistente del cdigo
Generar una mejor utilizacin de los recursos a partir de menores
costos
Desarrollar un criterio de diseo basado en las pruebas
 Por todo lo dicho necesitamos:
Automatizar y sistematizar las pruebas
Desarrollar un criterio de diseo basado en las prueba
trabajo con el ReposItorIo

Haga commit con frecuencia

Construya binarios con cada cambio
No tome del repositorio (check out) a su estacin de trabajo cdigo
que
no funciona
Escriba test unitarios sistemticos para el cdigo que desarrolla
Antes de subir al repositorio (check in) el cdigo desarrollado y todos
los tests
(suyos y los de los otros desarrolladores) deben ser ejecutados con xito
Corrija los errores (tests sin funcionar) que su cdigo gener en forma
inmediata
test sIstemtIcos y automtIcos

Mejorar la calidad del software

Entender el SUT (System Under Test)
Reducir los riesgos
Tests fciles de ejecutar
Tests fciles de escribir y mantener, si es posible en el mismo
lenguaje en
que los desarrolladores programan el sistema
Tests con mnimo mantenimiento ante evolucin del sistema
Como adoptar la nueva forma de
trabajo
Obstculos para automatizar las pruebas:

1. Actitud de los programadores

2. Inversin inicial
3. Cdigo que siempre cambia
4. Sistemas legacy
5. Temor
6. Viejos hbitos
Que debera automatizarse

Pruebas unitarias y de
componentes

Pruebas de funcionalidad
sin interfaces de usuario

Pruebas de sistemas con

interfaces de usuario.
Que no debera automatizarse

Pruebas de usabilidad

Pruebas exploratorias

Pruebas que no fallaran

Tareas nicas de fcil ejecucin manual y de difcil automatizacin

Estrategia para comenzar la
automatizacin
Capacitacin a analistas, testers y programadores

Seleccionar una forma de trabajo

Seleccionar herramientas

Desarrollar proyectos pilotos

Institucionalizar
DINAMICA
Integracin continua.
forma de trabajo
Pasos

1. Un desarrollador realiza un commit (cambios) sobre el repositorio (SCM)

mientras el administrador de integracin continua (IC) lo consulta por
cambios con una frecuencia determinada.
2. Despus del commit el administrador de IC detecta el cambio, toma del
repositorio
las ltimas versiones y ejecuta los scripts que integran todo el software
(compila y linkea), ejecuta los tests, toma mtricas y elabora informes.
3. El administrador de IC informa por mail a los miembros del grupo de
desarrollo de los resultados del build.
4. El administrador de IC continua consultando al repositorio (SCM) con la
frecuencia determinada.
Infraestructura

A efectos de ejemplificar un posible ambiente de integracin continua se

muestran en las figuras que siguen las herramientas integradas y los nodos sobre los
cuales estas fueron instaladas. La arquitectura del ambiente mostrado en el
esquema
se presenta en las dos figuras. En la figura 6.7 se muestran las herramientas y sus
roles, y en la 6.8, los nodos en los cuales estn instaladas.
Se indican, con diferentes colores, los roles de las herramientas en relacin con lo
expuesto en la tabla 6.3. Pueden verse una gran cantidad de mdulos orientados a
tomar
mtricas y armar informes relacionados. La presentada es solo una posible
arquitectura
usada por nosotros en algunos proyectos en los que se utiliz tecnologa Java. Una
referencia
donde pueden encontrarse vnculos a otras herramientas es el libro de Duvall (op.
cit.).
resultados

Un aspecto de gran importancia que deseamos volver a mencionar es la

posibilidad que ofrecen Maven y Cruise Control de generar un sitio para el
proyecto
donde se publican los informes con resultados y mtricas.
Este sitio es el punto de referencia de los involucrados en el proyecto as como
para los miembros del rea de calidad de la organizacin, ya que ellos
encontrarn
informacin de gran utilizadad para realizar su trabajo con relacin al
proyecto.
En la figura 6.9 se presenta una imagen de la portada de uno de estos sitios.
Es importante tener en cuenta que la informacin all publicada es actualizada
con cada construccin de binarios, por lo que constituye la fuente de
informacin ms
actualizada y precisa del proyecto.
Revisiones de diseo y cdigo

Las revisiones de productos por parte de pares y/o

especialistas externos ha probado ser un mtodo
efectivo para la deteccin de errores. Cuando se
alcanza madurez y habilidad para su desarrollo,
los nmeros indican que el 60% de los errores de
un proyecto son detectados por este medio
contra el 40% restante detectados por los tests.
Objetivos

Detectar problemas de anlisis, diseo y cdigo

en forma temprana.
Definir y acordar criterios de retrabajo para su
resolucin.
Verificar que se resolvi de acuerdo al criterio
acordado.
Beneficios

Genera datos acerca del producto y del proceso de

desarrollo
Genera datos acerca del producto y del proceso de
desarrollo
Genera conocimiento entre miembros del grupo de
desarrollo
Aumenta la efectividad de la validacin y verificacin
Contribuye a la instalacin del concepto de calidad.
Quines participan en las
revisiones de diseo y cdigo?