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…
http://jummp.wordpress.com/2010/05/05/proyectos-de-desarrollo-de-software-la-importancia-de-las-metricas-y-de-la-documentacion/
No hay comentarios.:
Publicar un comentario