Buenos días, en esta entrada hablaremos de un tema poco común de hablar y muy escuchado.
Muchos adjudican que hacen mantenimiento de software pero la mayoría en realidad usa ésta excusa para cobrar dinero, en realidad el mantenimiento de software si existe, y pocos lo tienen en cuenta.
Frecuentemente las discusiones acerca del software y la calidad del mismo solo involucran la fase de desarrollo. Pero el cuadro real es más amplio. La parte pocas veces tratada de la profesión, y casi nunca tratada en los cursos introductorios de programación es el mantenimiento .
Es una estimación amplia mente aceptada que casi el 70% de los costos del software se aplican al mantenimiento. Ninguna discusión acerca de calidad del software puede ser satisfactoria si se subestima este aspecto.
¿Qué significa mantenimiento para el software?. Un poco de reflexión muestra que éste termino aplicado al software es difuso cuando no confuso. Un producto de software no se gasta por su uso repetido y así no necesita ser mantenido en la manera en que se mantiene por ejemplo un automóvil. En los hechos la palabra mantenimiento es utilizada en software para cubrir un conjunto de actividades algunas nobles y otras no tanto. La parte noble es la modificación, a medida que las especificaciones cambian el sistema debe cambiar para reflejar estos cambios. La parte menos noble es la depuración, corregir errores que nunca deberían haber estado allí.
Un trabajo realizado sobre casi 500 instalaciones desarrollando software de todo tipo muestra la distribución de costos de mantenimiento. Más de las dos quintas partes de las actividades de mantenimiento, de acuerda a este trabajo, son extensiones y modificaciones requeridas por el usuario. Esto parecería ser la parte noble del mantenimiento, que es también la parte inevitable. Sin embargo esta magnitud demuestra la falta de extensibilidad del software comúnmente implementado, los productos de software son mucho más difícil y costosos de cambiar de lo que deberían ser. Uno de los beneficios de las técnicas de diseño publicadas llevaría a construir software más fácil de modificar.
El segundo ítem en orden de magnitud es particularmente interesante, cambios en los formatos de datos, cuando la estructura lógica y/o física de los archivos y otros items de datos cambian, los programas deben ser adaptados. El tema no es que alguna parte del programa conozca la estructura física de los datos, esto es inevitable debido que los datos deben eventualmente ser accedidos para su procesamiento. Pero con algunas técnicas de diseño este conocimiento está distribuido en demasiadas partes del sistema, así cuando la estructura física cambia, como ocurrirá tarde o temprano, el efecto sobre la estructura del sistema esta fuera de proporción con respecto al cambio.
Otro ítem significativo en la distribución es el bajo impacto que tienen las tareas de documentación, lo significativo también es que las tareas de documentación o son relativamente realizadas durante el desarrollo o no son hechas como tal. Es necesario promover estilos de diseño en el cual la documentación no esté separada del desarrollo del producto propiamente dicho, esto es la documentación este embebida dentro de los programas.
Los próximos items en el estudio de Lientz y Swanson's son también interesantes. Las reparaciones de emergencia, hechas apresurada mente cuando los programas no están produciendo los resultados esperados o se comportan de manera catastrófica o caótica, cuestan mucho más que las reparaciones de rutina, esto no solo se debe a que estas deben ser hechas bajo mucha presión, sino también a que cortan el proceso ordenado de liberar nuevas versiones del sistema y tienden a introducir nuevos errores. Las últimas dos actividades parecerían tener bajo impacto.
Una es la mejora de eficiencia, este estudio parecería mostrar que una vez que un sistema trabaja, los administradores del proyecto y los programadores no se muestran muy proclives a perturbar la delicada estructura del sistema en pos de una remota esperanza de mejorar la eficiencia del sistema. El otro es la transferencia a un nuevo entorno, parecería que la mayoría de los sistemas comúnmente escritos o son muy portables en naturaleza o tan dependientes de la plataforma particular que cualquier intento de portabilidad queda desechado desde el comienzo.
Saludos!
Muchos adjudican que hacen mantenimiento de software pero la mayoría en realidad usa ésta excusa para cobrar dinero, en realidad el mantenimiento de software si existe, y pocos lo tienen en cuenta.
Es una estimación amplia mente aceptada que casi el 70% de los costos del software se aplican al mantenimiento. Ninguna discusión acerca de calidad del software puede ser satisfactoria si se subestima este aspecto.
¿Qué significa mantenimiento para el software?. Un poco de reflexión muestra que éste termino aplicado al software es difuso cuando no confuso. Un producto de software no se gasta por su uso repetido y así no necesita ser mantenido en la manera en que se mantiene por ejemplo un automóvil. En los hechos la palabra mantenimiento es utilizada en software para cubrir un conjunto de actividades algunas nobles y otras no tanto. La parte noble es la modificación, a medida que las especificaciones cambian el sistema debe cambiar para reflejar estos cambios. La parte menos noble es la depuración, corregir errores que nunca deberían haber estado allí.
Un trabajo realizado sobre casi 500 instalaciones desarrollando software de todo tipo muestra la distribución de costos de mantenimiento. Más de las dos quintas partes de las actividades de mantenimiento, de acuerda a este trabajo, son extensiones y modificaciones requeridas por el usuario. Esto parecería ser la parte noble del mantenimiento, que es también la parte inevitable. Sin embargo esta magnitud demuestra la falta de extensibilidad del software comúnmente implementado, los productos de software son mucho más difícil y costosos de cambiar de lo que deberían ser. Uno de los beneficios de las técnicas de diseño publicadas llevaría a construir software más fácil de modificar.
El segundo ítem en orden de magnitud es particularmente interesante, cambios en los formatos de datos, cuando la estructura lógica y/o física de los archivos y otros items de datos cambian, los programas deben ser adaptados. El tema no es que alguna parte del programa conozca la estructura física de los datos, esto es inevitable debido que los datos deben eventualmente ser accedidos para su procesamiento. Pero con algunas técnicas de diseño este conocimiento está distribuido en demasiadas partes del sistema, así cuando la estructura física cambia, como ocurrirá tarde o temprano, el efecto sobre la estructura del sistema esta fuera de proporción con respecto al cambio.
Otro ítem significativo en la distribución es el bajo impacto que tienen las tareas de documentación, lo significativo también es que las tareas de documentación o son relativamente realizadas durante el desarrollo o no son hechas como tal. Es necesario promover estilos de diseño en el cual la documentación no esté separada del desarrollo del producto propiamente dicho, esto es la documentación este embebida dentro de los programas.
Los próximos items en el estudio de Lientz y Swanson's son también interesantes. Las reparaciones de emergencia, hechas apresurada mente cuando los programas no están produciendo los resultados esperados o se comportan de manera catastrófica o caótica, cuestan mucho más que las reparaciones de rutina, esto no solo se debe a que estas deben ser hechas bajo mucha presión, sino también a que cortan el proceso ordenado de liberar nuevas versiones del sistema y tienden a introducir nuevos errores. Las últimas dos actividades parecerían tener bajo impacto.
Una es la mejora de eficiencia, este estudio parecería mostrar que una vez que un sistema trabaja, los administradores del proyecto y los programadores no se muestran muy proclives a perturbar la delicada estructura del sistema en pos de una remota esperanza de mejorar la eficiencia del sistema. El otro es la transferencia a un nuevo entorno, parecería que la mayoría de los sistemas comúnmente escritos o son muy portables en naturaleza o tan dependientes de la plataforma particular que cualquier intento de portabilidad queda desechado desde el comienzo.
Saludos!
0 comentarios:
Publicar un comentario