Proyectos de desarrollo de software: La importancia de las métricas y de la documentación

Si los proyectos no varían de proveedor de servicios de desarrollo de software o de responsable del proyecto, la importancia de las métricas y de la documentación pueden pasar a un segundo plano, ya que de una u otra forma el sistema de información seguirá adelante. Es cierto que las métricas y la documentación pueden resultar también de gran utilidad en estos casos, sobre todo si se quiere ver cómo evoluciona la calidad de la herramienta y las incidencias que están teniendo los usuarios en el uso cotidiano de la aplicación.

En cualquier caso el problema está en que generalmente nos solemos acordar de la documentación y de conocer métricas cuando las necesitamos y precisamente por eso, cuando tenemos que echar mano de ellas no las tenemos.

Como es lógico, esa no son las únicas circunstancias que aconsejan que se documenten los proyectos y se obtengan métricas, ya que por encima de eso está la persistencia del conocimiento de la aplicación lo que permite que la adaptación a cambios en la gestión y en los proveedores resulte menos traumática. También permitirá tener un punto de referencia para evaluar la evolución del producto en las nuevas condiciones de explotación o mantenimiento.

Por ejemplo, si se fueran a externalizar en bloque el mantenimiento de una serie de aplicaciones de una organización probablemente lo primero que querrían conocer los posibles proveedores de ese servicio sería información general de las aplicaciones: tecnologías, arquitecturas, fecha de puesta en producción, etc… y métricas: número de incidencias de relacionadas con correctivos, frecuencia de mantenimientos evolutivos, volumen, calidad y formato de la documentación, etc… Si eso se adobara con informes Sonar que indiquen la evolución del análisis estático de código de las mismas, les permitiría todavía más ser más precisos en la estimación del esfuerzo que se requeriría para realizar el servicio en función del número de aplicaciones a mantener, las características del servicio y del acuerdo de nivel de servicio. Además de todo lo anterior, les sería interesante conocer las reglas de desarrollo y de calidad del software de la organización, el ecosistema de desarrollo, las características del entorno de producción, preproducción y desarrollo: sistemas físicos, software de base y servidores de aplicaciones, la estructura organizativa del departamento de informática, el proceso de paso a producción, etc…

3 comentarios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: