jueves, 18 de enero de 2007

Nuestro amigo más temido: el Proceso de desarrollo de SW

Las ventajas del uso (adecuado, medido) de un proceso de desarrollo de software son tan evidentes como la pesadez y sensación de pérdida de tiempo que provocan. Pero son necesarias, porque facilitan mucho la integración e integridad de los datos del proyecto, su seguimiento y, en definitiva, la calidad del producto (software + otras cosas).

Por consiguiente, es necesaria una herramienta que 'nos lleve de la mano' para trabajar de la manera indicada en el proceso de desarrollo que se haya definido, sin que ello suponga un esfuerzo extra para el desarrollador. Os podéis imaginar que el Team Edition del Visual Studio provee algo para esto (aquí hay un webcast detalles de lo que ofrece Microsoft) y, como siempre, un ejemplo clarifica los requisitos:

Supongamos que nuestro proceso dicta que al principio del proyecto se deben crear varios documentos, con diferentes autores / responsables y datos sobre el proyecto. Por ejemplo, un documento de requisitos que lo hace el analista, acta de creación de equipo por parte del jefe de proyecto, documento de Visión del proyecto, Oferta, etc. Pues nuestra herramienta debería ser capaz de crear automáticamente los documentos y meterlos en sus debidas carpetas de red, hacer el esqueleto de dichos documentos en base a los datos del proyecto, crear y asignar tareas para que cada personas las vea en su Project o sucedáneo, crear la carpeta donde se alojará el código en un servidor de control de código fuente, etc...

También debe saber establecer políticas de calidad de los producto que se generen, como normas de codificación o análisis y testeo del código que se crea, no permitir que se realicen tareas hasta que se hagan otras de las que se depende, etc.

Un aspecto importante de este componente que define el proceso es que, debido a la gran cantidad de otros componentes con los que se comunica, puede ser adecuado para coordinar el resto de ellos. Sería una especie de controlador (MVC) central, donde mediante un lenguaje de definición de proceso (Microsoft ha definido el suyo propio para el Team Foundation Server) se configura la manera de actuar del resto de los componentes del sistema (en ese proyecto, puede haber otros con diferentes procesos de desarrollo).

La posible arquitectura e implementación se tratará en el próximo capítulo.

1 comentario:

erramun dijo...

vaya vaya! quién te ha visto y quién te ve!

Importante es el proceso como importante es la agilidad de desarrollo. ¿Lo primero proporciona lo segundo??

Bueno yo creo que f(agilidad) = procesoD. Dónde la agilidad es un valor dado por la combinación de diferentes módulos/acciones/partes que has descrito. Se podría plantear un proceso/herramienta de desarrollo sw "basado en componentes".

arr ke malo es divagarr!!!