Descripción general del mantenimiento de software
El mantenimiento de software es una parte ampliamente aceptada de SDLC hoy en día. Representa todas las modificaciones y actualizaciones realizadas después de la entrega del producto de software. Hay varias razones por las que se requieren modificaciones, algunas de ellas se mencionan brevemente a continuación:
Market Conditions - Las políticas, que cambian con el tiempo, como los impuestos y las restricciones introducidas recientemente, como la forma de llevar la contabilidad, pueden generar la necesidad de modificaciones.
Client Requirements - Con el tiempo, el cliente puede solicitar nuevas características o funciones en el software.
Host Modifications - Si cambia el hardware y / o la plataforma (como el sistema operativo) del host de destino, se necesitan cambios de software para mantener la adaptabilidad.
Organization Changes - Si hay algún cambio en el nivel comercial del cliente, como la reducción de la fuerza de la organización, la adquisición de otra empresa, la organización que se aventura en nuevos negocios, puede surgir la necesidad de modificar el software original.
Tipos de mantenimiento
Durante la vida útil del software, el tipo de mantenimiento puede variar según su naturaleza. Puede ser solo una tarea de mantenimiento de rutina como algún error descubierto por algún usuario o puede ser un gran evento en sí mismo basado en el tamaño o la naturaleza del mantenimiento. A continuación se muestran algunos tipos de mantenimiento en función de sus características:
Corrective Maintenance - Esto incluye modificaciones y actualizaciones realizadas para corregir o solucionar problemas, que son descubiertos por el usuario o concluidos por informes de errores del usuario.
Adaptive Maintenance - Esto incluye modificaciones y actualizaciones aplicadas para mantener el producto de software actualizado y sintonizado con el cambiante mundo de la tecnología y el entorno empresarial.
Perfective Maintenance- Esto incluye modificaciones y actualizaciones realizadas para mantener el software utilizable durante un largo período de tiempo. Incluye nuevas funciones, nuevos requisitos de usuario para refinar el software y mejorar su confiabilidad y rendimiento.
Preventive Maintenance- Esto incluye modificaciones y actualizaciones para evitar problemas futuros del software. Tiene como objetivo atender problemas, que no son importantes en este momento pero que pueden causar problemas graves en el futuro.
Costo de mantenimiento
Los informes sugieren que el costo de mantenimiento es alto. Un estudio sobre la estimación del mantenimiento del software encontró que el costo de mantenimiento es tan alto como el 67% del costo de todo el ciclo del proceso del software.
En promedio, el costo del mantenimiento del software es más del 50% de todas las fases de SDLC. Hay varios factores que provocan que el costo de mantenimiento sea elevado, tales como:
Factores del mundo real que afectan el costo de mantenimiento
- La edad estándar de cualquier software se considera de 10 a 15 años.
- Los softwares más antiguos, que estaban destinados a funcionar en máquinas lentas con menos memoria y capacidad de almacenamiento, no pueden mantenerse desafiantes contra los nuevos softwares mejorados en hardware moderno.
- A medida que avanza la tecnología, resulta costoso mantener el software antiguo.
- La mayoría de los ingenieros de mantenimiento son novatos y utilizan el método de prueba y error para corregir el problema.
- A menudo, los cambios realizados pueden dañar fácilmente la estructura original del software, dificultando los cambios posteriores.
- Los cambios a menudo quedan indocumentados, lo que puede causar más conflictos en el futuro.
Factores finales del software que afectan el costo de mantenimiento
- Estructura del programa de software
- Lenguaje de programación
- Dependencia del entorno externo
- Confiabilidad y disponibilidad del personal
Actividades de mantenimiento
IEEE proporciona un marco para las actividades del proceso de mantenimiento secuencial. Se puede utilizar de manera iterativa y se puede ampliar para que se puedan incluir elementos y procesos personalizados.
Estas actividades van de la mano con cada una de las siguientes fases:
Identification & Tracing- Implica actividades relativas a la identificación de requisitos de modificación o mantenimiento. Lo genera el usuario o el propio sistema puede informar mediante logs o mensajes de error. Aquí también se clasifica el tipo de mantenimiento.
Analysis- La modificación se analiza por su impacto en el sistema, incluidas las implicaciones de seguridad y protección. Si el impacto probable es severo, se busca una solución alternativa. Luego, un conjunto de modificaciones necesarias se materializa en especificaciones de requisitos. Se analiza el costo de modificación / mantenimiento y se concluye la estimación.
Design- Los nuevos módulos, que necesitan ser reemplazados o modificados, se diseñan según las especificaciones de requisitos establecidas en la etapa anterior. Los casos de prueba se crean para validación y verificación.
Implementation - Los nuevos módulos se codifican con la ayuda del diseño estructurado creado en el paso de diseño. Se espera que cada programador realice pruebas unitarias en paralelo.
System Testing- Las pruebas de integración se realizan entre módulos recién creados. También se realizan pruebas de integración entre los nuevos módulos y el sistema. Finalmente, el sistema se prueba como un todo, siguiendo procedimientos de prueba regresivos.
Acceptance Testing- Después de probar el sistema internamente, se prueba su aceptación con la ayuda de los usuarios. Si en este estado, el usuario se queja de algunos problemas, se abordan o se indica que deben abordar en la próxima iteración.
Delivery- Después de la prueba de aceptación, el sistema se implementa en toda la organización, ya sea mediante un pequeño paquete de actualización o una nueva instalación del sistema. La prueba final se lleva a cabo en el cliente después de que se entrega el software.
Se proporciona un servicio de capacitación si es necesario, además de la copia impresa del manual del usuario.
Maintenance management- La gestión de la configuración es una parte esencial del mantenimiento del sistema. Cuenta con herramientas de control de versiones para controlar versiones, semi-versiones o administración de parches.
Reingeniería de software
Cuando necesitamos actualizar el software para mantenerlo en el mercado actual, sin afectar su funcionalidad, se llama reingeniería de software. Es un proceso minucioso en el que se cambia el diseño del software y se reescriben los programas.
El software heredado no puede seguir sintonizándose con la última tecnología disponible en el mercado. A medida que el hardware se vuelve obsoleto, la actualización del software se convierte en un dolor de cabeza. Incluso si el software envejece con el tiempo, su funcionalidad no lo hace.
Por ejemplo, inicialmente Unix se desarrolló en lenguaje ensamblador. Cuando surgió el lenguaje C, Unix fue rediseñado en C, porque trabajar en lenguaje ensamblador era difícil.
Aparte de esto, a veces los programadores notan que pocas partes del software necesitan más mantenimiento que otras y también necesitan reingeniería.
Proceso de reingeniería
- Decidequé rediseñar. ¿Es todo un software o una parte de él?
- Perform Ingeniería inversa, para obtener especificaciones de software existente.
- Restructure Programsi es requerido. Por ejemplo, cambiar programas orientados a funciones en programas orientados a objetos.
- Re-structure data según sea necesario.
- Apply Forward engineering conceptos para obtener software rediseñado.
Hay algunos términos importantes que se utilizan en la reingeniería de software
Ingeniería inversa
Es un proceso para lograr la especificación del sistema analizando a fondo y comprendiendo el sistema existente. Este proceso puede verse como un modelo SDLC inverso, es decir, intentamos obtener un mayor nivel de abstracción analizando niveles de abstracción más bajos.
Un sistema existente es un diseño implementado previamente, del que no sabemos nada. Luego, los diseñadores realizan ingeniería inversa mirando el código e intentan obtener el diseño. Con el diseño en la mano, intentan concluir las especificaciones. Por lo tanto, ir a la inversa del código a la especificación del sistema.
Reestructuración del programa
Es un proceso para reestructurar y reconstruir el software existente. Se trata de reorganizar el código fuente, ya sea en el mismo lenguaje de programación o de un lenguaje de programación a otro diferente. La reestructuración puede tener una reestructuración de código fuente y una reestructuración de datos o ambas.
La reestructuración no afecta la funcionalidad del software, pero mejora la confiabilidad y la capacidad de mantenimiento. Los componentes del programa, que provocan errores con mucha frecuencia, pueden modificarse o actualizarse con una reestructuración.
La confiabilidad del software en una plataforma de hardware obsoleta se puede eliminar mediante una reestructuración.
Ingeniería avanzada
La ingeniería avanzada es un proceso de obtención del software deseado a partir de las especificaciones disponibles que se eliminaron mediante ingeniería inversa. Se asume que ya se hizo algo de ingeniería de software en el pasado.
La ingeniería avanzada es lo mismo que el proceso de ingeniería de software con una sola diferencia: se lleva a cabo siempre después de la ingeniería inversa.
Reutilización de componentes
Un componente es parte del código del programa de software, que ejecuta una tarea independiente en el sistema. Puede ser un módulo pequeño o un subsistema en sí.
Ejemplo
Los procedimientos de inicio de sesión utilizados en la web se pueden considerar como componentes, el sistema de impresión en el software puede verse como un componente del software.
Los componentes tienen una alta cohesión de funcionalidad y una menor tasa de acoplamiento, es decir, funcionan de forma independiente y pueden realizar tareas sin depender de otros módulos.
En OOP, los objetos que se diseñan son muy específicos de su interés y tienen menos posibilidades de ser utilizados en algún otro software.
En la programación modular, los módulos están codificados para realizar tareas específicas que se pueden utilizar en varios otros programas de software.
Existe una vertical completamente nueva, que se basa en la reutilización de componentes de software y se conoce como Ingeniería de software basada en componentes (CBSE).
La reutilización se puede realizar en varios niveles
Application level - Donde una aplicación completa se utiliza como subsistema de nuevo software.
Component level - Dónde se utiliza el subsistema de una aplicación.
Modules level - Donde se reutilizan módulos funcionales.
Los componentes de software proporcionan interfaces que se pueden utilizar para establecer la comunicación entre diferentes componentes.
Proceso de reutilización
Se pueden adoptar dos tipos de métodos: manteniendo los mismos requisitos y ajustando los componentes o manteniendo los mismos componentes y modificando los requisitos.
Requirement Specification - Se especifican los requisitos funcionales y no funcionales, que debe cumplir un producto de software, con la ayuda del sistema existente, la entrada del usuario o ambos.
Design- Este también es un paso de proceso SDLC estándar, donde los requisitos se definen en términos de lenguaje de software. Se crea la arquitectura básica del sistema en su conjunto y sus subsistemas.
Specify Components - Al estudiar el diseño del software, los diseñadores segregan todo el sistema en componentes o subsistemas más pequeños. Un diseño de software completo se convierte en una colección de un gran conjunto de componentes que trabajan juntos.
Search Suitable Components - Los diseñadores remiten al repositorio de componentes de software para buscar el componente correspondiente, en función de la funcionalidad y los requisitos de software previstos.
Incorporate Components - Todos los componentes combinados se empaquetan juntos para darles forma como software completo.