Diseño y desarrollo de software en proyectos Fastrack: Como minimizar los riesgos

Imagen proporcionada por Picasa Web Albums

Hoy en día muchos proyectos de informática se están ejecutando bajo un enfoque de “Fastrack”, buscando disminuir el tiempo de desarrollo de software, por medio de la aplicación de diseños prefabricados y la ejecución en paralelo de actividades como el análisis, diseño, desarrollo y pruebas.

La aplicación de este enfoque implica comenzar a desarrollar el Software antes de tener el diseño detallado completo y aprobado en su totalidad, situación que de por sí supone riesgos de retrabajo más adelante en el proyecto, originado en nueva información técnica o cambios en los requerimientos.

En este artículo se exploran las consecuencias negativas de comenzar a desarrollar sin tener un diseño detallado aprobado y se presentan algunas recomendaciones que minimizarán dichos riesgos.

Requisitos para comenzar un desarrollo de software bajo enfoque tradicional

Aplicando los enfoques de desarrollo de software tradicionales, para comenzar una fase de un proyecto es necesario haber completado las anteriores en su totalidad.

Siguiendo este enfoque, antes de comenzar con el desarrollo es necesario haber concluido la fase de diseño del sistema, tanto los aspectos de funcionalidad definidos por el usuario, como los requerimientos técnicos definidos por la unidad de Tecnología de Información (TI) de la organización.

>> Más información sobre enfoques tradicionales de desarrollo de software

Por ende, el desarrollo no puede comenzar hasta cumplir con los siguientes puntos:

• Elaboración de las especificaciones del sistema, diseño de interfaz y diseño detallado. 
• Elaboración del plan de soporte al área de operaciones. 
• Documentación del plan de pruebas. 
• Documentación del plan de gestión de proyectos. 
• Revisión detallada para comprobar que el diseño incluye todas las necesidades del usuario, incluyendo funciones especiales, diseño de pantallas y reportes. 
• Aplicación de controles de calidad durante la elaboración del diseño. 
• Aprobación formal del diseño detallado por parte de la gerencia y los usuarios. 

Riesgo de hacer el desarrollo del software en paralelo con el diseño

Comenzar un desarrollo antes de concluir la fase de diseño implica que no se tendrá un documento que establezca firmemente el trabajo a realizar, por lo que dependerá de información recabada de las reuniones con el usuario y área técnica del cliente.
Trabajar de esta forma implica los siguientes riesgos:

• La información estará sujeta a interpretaciones divergentes entre las partes o a cambios que surjan de un mayor entendimiento del alcance más adelante.
• Es posible que no se identifiquen todas las áreas implicadas, omitiendo características esenciales para que el producto pueda ser usado y no afecte las operaciones de la empresa.
• Existen mayores oportunidades para que se añadan indiscriminadamente nuevas características al producto (Scope Creep) por parte de los usuarios y otros implicados.

De ocurrir estas situaciones, pudiera perderse parte del trabajo realizado por los desarrolladores, obligando a realizar los ajustes necesarios más adelante (retrabajo).

Adicionalmente, resulta en mayores costos al requerirse más personal para cubrir estos retrabajos y actividades en paralelo, posible escasez o excedentes de personal en distintas etapas del proyecto, incremento de sobretiempo y mayores costos con contratistas quienes buscaran protegerse de posibles cambios de alcance.

Recomendaciones

Es posible comenzar a desarrollar el software sin un diseño firmemente establecido si se siguen las siguientes recomendaciones:

1. Minutas de Reunión: Elaborar y distribuir minutas de toda reunión que se tenga, minimizando la posibilidad de interpretaciones divergentes entre el proyecto y el cliente. Además, sirve para controlar cambios indiscriminados en los requerimientos de una reunión a otra. 
2. Asegurar que todos los implicados asistan a las reuniones: Énfasis en las primeras reuniones en identificar e involucrar a todos las áreas implicadas dentro de la organización cliente, asegurando que todos asistan a las reuniones funcionales y técnicas.
3. Definición general sobre que está en el alcance y que no: Si bien no se tiene un diseño detallado, conviene contar con una definición general del alcance, a usar como referencia para validar si se incluyen o no los puntos que surjan de las reuniones.
4. Comunicación directa y frecuente entre el proyecto y los interlocutores clave del cliente: Al no contar con un diseño firmemente establecido, conviene realizar a diario revisiones con el cliente, permitiendo la identificación temprana de cualquier error de interpretación. Asimismo, garantiza que cualquier cambio será comunicado al proyecto de forma expedita.
5. Sistema de Gestión de Requerimientos: Permitirá establecer la trazabilidad entre todo requerimiento que se pidió, bitácora de todos los cambios realizados y control sobre las últimas versiones de los documentos de diseño.

Las medidas mencionadas no eliminaran por completo las posibilidades de retrabajo (algo se incurrirá), sin embargo, reducirá significativamente los costos y efectos adversos de los mismos, mejorando la capacidad de adaptación del proyecto.

>> Más información desarrollo ágil de software

Referencias

Bibliografía:

Cannon, D. CISA Certified Information Systems Auditor Study Guide. Second Edition. Wiley Publishing, Inc., Indianapolis, Indiana, Estados Unidos de América. ISBN: 978-0-470-23152-4.

Enlaces:

>> Fastrack Projects without taking shortcuts
>> Managing Fastracking Projects, a guide and checklists