Se trata de darle el papel que se merece la documentación en el software evitando refactorizaciones y reingenierías innecesarias con el paso del tiempo.

1. ¡Documentar aburre pero… evita hacer reconstrucciones del
Software!

2. ¿Más documentación?
• Efectivamente, es necesario documentar todas las fases del ciclo de vida software incluida, la fase
de Diseño.
¿Cómo la documento?
•IEEE 1016 es el estándar que nos dicta cómo realizar la documentación del diseño software. Ésta se basa en:
1. Diferenciar 7 roles básicos: manager del proyecto, manager de configuración, diseñador, programador, pruebas
unitarias, pruebas de integración y programador de mantenimiento.
2. Distinguir 10 atributos de diseño: Identificación, tipo, propósito, función, subordinación, dependencia, interfaz,
recursos, procesamiento y datos.
CADA UNO DE LOS ROLES SE ENCARGARÁ DE ALGUNO O VARIOS ATRIBUTOS DE DISEÑO A FIN DE ORGANIZAR Y
ASUMIR RESPONSABILIDADES EN LA DOCUMENTACIÓN DEL DISEÑO SOFTWARE.
¿PROBLEMAS?
¡La documentación está incompleta u obsoleta!
¿Qué podemos hacer para solucionarlo?
• Aplicar reingeniería o ingeniería inversa: mediante el
análisis de nuestro sistema, produciremos una
representación a alto nivel del mismo para así poder
re-documentarlo.
El diseño y el funcionamiento están bien
pero…¡pueden ser mejorados!
• Aplicar la técnica conocida como refactorización:
mediante el análisis de nuestro sistema,
localizaremos los “bad-smells” o antipatrones y los
solventaremos, aumentando la calidad de nuestro
producto software.
“NUNCA HAY TIEMPO PARA HACER LAS COSAS BIEN, PERO SÍ PARA HACERLAS DOS VECES”
¡HAGAMOS SOFTWARE DE CALIDAD!