martes, 4 de agosto de 2009







La evolución del sistema de software suele incluirse dentro deuna fase denominada de mantenimiento aunque su implicación esmucho más amplia de lo que el término significa en otras ingenierías. Anadie se le ocurre llevar su coche a un taller para que le incorporen unnuevo cilindro; sin embargo, parece que modificar líneas de código sepuede hacer sin alterar la sustancia del producto, lo cual no es cierto.Se suele hablar de tres tipos diferentes de mantenimiento:









1) Mantenimiento correctivo. Pretende eliminar problemassurgidos durante la fase de operación del sistema y que nohan sido detectados anteriormente.






2) Mantenimiento perfectivo. Pretende mejorar lafuncionalidad del sistema ya sea en relación con la eficienciaen ejecución del mismo (menor tiempo de respuesta,optimización del uso de la memoria, etc.), facilitar su uso,etc.






3) Mantenimiento evolutivo. Pretende modificar (ampliar,eliminar o sustituir) la funcionalidad del sistema paraadaptarla a las nuevas necesidades del usuario o con elobjetivo de adaptarlo a nuevas interfaces hardware osoftware.








Modelo ciclo de vida convencional












Las ventajas e inconvenientes del modelo de ciclo de vidaconvencional son bien conocidas desde hace tiempo y podemos decirque el 90 % de los desarrollos actuales se realizan de acuerdo con él. Como ventajas citamos:



a) Fases conocidas por todos los desarrolladores y ligadasa los perfiles técnicos clásicamente establecidos. Existegran experiencia documentada sobre el uso del modeloque coincide con la formación típica del ingeniero desoftware.



b) Es el más eficiente cuando el sistema es conocido y losrequisitos estables ya que se puede avanzar rápidamentehacia la fase de diseño arquitectónico sin que exista elpeligro de una continua interacción entre las primerasfases.



c) Permite una gestión del proceso de desarrollo basada enrevisiones de los documentos generados en cada fasefacilitando la ejecución de los procedimientos de gestión.El modelo en cascada ha sido normalizado por diversas entidadescomo base para el proceso de contratación y para la aceptación delsoftware entregado. Una de estas entidades ha sido la Agencia Espacial Europea (ESA) quien, en su conjunto de normas de ingeniería software, ha definido el modelo de ciclo de vida a utilizar.












Un modelo normalizado como el de la Agencia Espacial Europea no solo presta atención a las actividades técnicas a desarrollar sinotambién a cómo éstas son gestionadas a lo largo del desarrollo. La imbricación de unas y otras define los procesos definidos por elmodelo. Tenemos que destacar, no obstante, que el detalle de losprocedimientos a usar a partir de un modelo no está contenido en elmismo sino que debe ser generado por sus usuarios; así, grandescorporaciones suelen definir complejas guías de aplicación en las que se detallan los procesos a usar en cada una de las etapasadaptados a sus características organizativas o de los productossoftware que deben desarrollar.






La Figura 6 describe esquemáticamente la idea de este modelonormalizado. La figura está abstraída de las normas de la ESA quedescriben las actividades técnicas y de gestión .
En ella se handescrito las fases y asociadas a ellas las actividades fundamentales, los documentos generados y el proceso de revisión y validación decada una. Obsérvese que este proceso de validación se realiza a partirde los documentos generados; sólo en el caso del código es posibleautomatizar el proceso de revisión (por ejemplo, existen programasque pueden leer de forma inteligente un código fuente con el fin deextraer ciertas estadísticas que permiten a los implementadores conocerla calidad del mismo).Son múltiples las desventajas asociadas al modelo convencional;entre ellas citamos:a) La visibilidad del proceso es muy limitada siendo el códigogenerado el único producto con el que el usuario puedevalidar sus requisitos. Las entradas y salidas intermediasson documentos internos al equipo de desarrollo nopensadas para su validación por los usuarios. El único objetoformalizado es el código y aparece al final cuando lasmodificaciones (caso de afectar a las fases anteriores) sonmuy costosas.b) No permite manejar fácilmente cambios de requisitos unavez iniciado el desarrollo.Es típico cuando el usuario no conoce exactamente lo quedesea que cambie de opinión sobre sus necesidades o,simplemente, que no indique todas sus necesidades. A esteproblema se le conoce como de inestabilidad de los requisitos y es uno de los más graves en el proceso dediseño.






Modelo de ciclo de vida convencional de la ESA











Como consecuencia, impide realizar el seguimientode los requisitos a lo largo del desarrollo de forma tal quefacilite la evolución posterior del sistema.
c) Las actividades de prueba se realizan sobre el códigocuando la relación con las decisiones de diseño se hanperdido. Durante las pruebas de los módulos la situación estolerable pero en las pruebas de integración surgendificultades crecientes con la complejidad del sistema.Casi todos los demás modelos han surgido como variacionesde éste.
Una conocida variación es el modelo en V en el que los aspectosde prueba aparecen claramente ligados a cada una de las fases.En este modelo se asocia una fase de prueba a cada una de lasfases del ciclo de vida estableciendo métodos de gestión para lavalidación de cada una de ellas (conformidad).
La Figura describe esquemáticamente la idea de este modelo.Visto globalmente, el modelo en V implica que las pruebas no seconsideran parte de la implementación sino de forma separada relacionadascon cada una de las fases del desarrollo.El problema de aplicación de este modelo reside precisamenteen la capacidad que tengamos de asegurar la conformidad mediantepruebas sobre el código.

La aparición de tecnologías de software que permiten formalizar parcialmente la fase de análisis de requisitos de software o deldiseño arquitectónico, está permitiendo completar la visión de este modelo combinando las pruebas mencionadas ) con otras sobre los documentos de requisitos















Modelo de ciclo de vida en v

















o diseño que mejoran globalmente la capacidad de validar el producto resultante.

No hay comentarios:

Publicar un comentario en la entrada