La problemática del mantenimiento se resume en realizar el mantenimiento del software de forma tan rigurosa que la calidad no se deteriore como resultado de este proceso.
La pregunta a formular es la siguiente: ¿cómo debe mantenerse el software para preservar su fiabilidad? A continuación veremos las circunstancias que hacen que la respuesta a esta pregunta no sea fácil y esté muy condicionada.
Código Heredado
En la actualidad, la mayor parte de éste software está formado por código antiguo “heredado” (del inglés legacy code); es decir, código de aplicaciones desarrolladas hace algún tiempo, con técnicas y herramientas en desuso y probablemente por personas que ya no pertenecen al colectivo responsable en este momento del mantenimiento del software concreto.
En muchas ocasiones la situación se complica porque el código heredado fue objeto de múltiples actividades de mantenimiento. La opción de desechar este software y reescribirlo para adaptarlo a las nuevas necesidades tecnológicas o a los cambios en la especificación es muchas veces inadecuada por la gran carga financiera que supuso el desarrollo del software original y la necesidad económica de su amortización.
Los problemas específicos del mantenimiento de código heredado han sido caracterizados en las llamadas Leyes del Mantenimiento del Software [Lehman, 1980]:
Continuidad del Cambio – Un programa utilizado en un entorno del mundo real debe cambiar, ya que si no cada vez será menos usado en dicho entorno. En otras palabras, esto significa que, tan pronto como un programa ha sido escrito, está ya desfasado. Las razones que conducen a esta afirmación son varias: a los usuarios se les ocurren nuevas funcionalidades cuando comienzan a utilizar el software; nuevas características en el hardware pueden permitir mejoras en el software; se encuentran defectos en el software que deben ser corregidos; el software debe instalarse en otro sistema operativo o máquina; o el software necesita ser más eficiente
Incremento de la Complejidad – A la par que los cambios transforman los programas, su estructura se hará progresivamente más compleja salvo que se haga un esfuerzo activo para evitar este fenómeno. Esto significa que al realizar cambios en un programa (excluyendo el mantenimiento preventivo), la estructura de dicho programa se hace más compleja cuando los programadores no pueden o no quieren usar técnicas de ingeniería del software
Evolución del Programa – La evolución de un programa es un proceso autorregulado. Las medidas de determinadas propiedades (tamaño, tiempo entre versiones y número de errores) revelan estadísticamente determinadas tendencias e invariantes.
Conservación de la Estabilidad Organizacional – A lo largo del tiempo de vida de un programa, la carga que supone el desarrollo de dicho programa es aproximadamente constante e independiente de los recursos dedicados.
Conservación de la Familiaridad – Durante todo el tiempo de vida de un sistema, el incremento en el número de cambios incluidos con cada versión (release) es aproximadamente constante. Casi veinte años después, el mismo autor vuelve a confirmar las leyes anteriores [Lehman et al., 1998]: la afirmación “los grandes programas no llegan nunca a completarse y están en constante evolución” se ve confirmada por el hecho de que, como ya hemos mencionado, algo más del 60% de las modificaciones que se realizan en el software se refieren a mantenimiento perfectivo.
Problemas de Mantenimiento
Además de las dificultades de mantenimiento que señalan las leyes anteriores, existen otros problemas clásicos que complican el mantenimiento [Schneidewind, 1987]:
A menudo, el mantenimiento es realizado de una manera ad hoc en un estilo libre establecido por el propio programador (esta opinión también es compartida por Pressman [1993], quien afirma que “raramente existen organizaciones formales, de modo que el mantenimiento se lleva a cabo como se pueda”). No en todas las ocasiones esta situación es debida a la falta de tiempo para producir una modificación diseñada cuidadosamente. Prácticamente todas las metodologías se han centrado en el desarrollo de nuevos sistemas y no han tenido en cuenta la importancia del mantenimiento. Por esta razón, no existen o son poco conocidos los métodos, técnicas y herramientas que proporcionan una solución global al problema del mantenimiento.
Cambio tras cambio, los programas tienden a ser menos estructurados. Esto se manifiesta en una documentación desfasada (como afirman Baxter y Pigdeon [1997] al indicar que “la documentación completa o inexistente del sistema es uno de los cuatro problemas más importantes del mantenimiento de software”), código que no cumple los estándares, incremento en el tiempo que los programadores necesitan para entender y comprender los programas o en el incremento en los efectos secundarios producidos por los cambios. Todas estas situaciones implican casi siempre unos costes de mantenimiento del software muy altos.
Es muy habitual que los sistemas que están siendo sometidos a mantenimiento sean cada vez más difíciles de cambiar (lo cual, como confirman Griswold y Notkin [1993], provoca que el mantenimiento sea cada vez más costoso). Esto se debe al hecho de que los cambios en un programa por actividades de mantenimiento dificultan la posterior comprensión de la funcionalidad del programa. Sommerville [1992] también apunta que “cualquier cambio conlleva la corrupción de la estructura del software y, a mayor corrupción, la estructura del programa se torna menos comprensible y más difícil de modificar”.
Por ejemplo, el programa original puede basarse en decisiones de programación no documentadas a las que no puede acceder el personal de mantenimiento. En estas situaciones, es normal que el software no pueda ser cambiado sin correr el riesgo de introducir efectos laterales no deseados debidos a interdependencias entre variables y procedimientos que el personal de mantenimiento no ha detectado.
La falta de una metodología adecuada suele conducir a que los usuarios participen poco durante el desarrollo del sistema software. Esto tiene como consecuencia que, cuando el producto se entrega a los usuarios, no satisface sus necesidades y se tienen que producir esfuerzos de mantenimiento mayores en el futuro.
Además de los problemas de carácter técnico anteriores, también pueden existir problemas de gestión. Muchos programadores consideran el trabajo de mantenimiento como una actividad inferior menos creativa- que les distrae del trabajo -mucho más interesante- del desarrollo de software. Esta visión puede verse reforzada por las condiciones laborales y salariales y crea una baja moral entre las personas dedicadas al mantenimiento. Como resultado de lo anterior, cuando se hace necesario realizar mantenimiento, en vez de emplear una estrategia sistemática, las correcciones tienden a ser realizadas con precipitación, sin pensarse de forma suficiente, no documentadas adecuadamente y pobremente integradas con el código existente. No es extraño, pues, que el propio mantenimiento conduzca a la introducción de nuevos errores e ineficiencias que conducen a nuevos esfuerzos de mantenimiento con posterioridad
Todos estos problemas se pueden atribuir –parcialmente al gran número de programas existentes que han sido desarrollados sin tener en cuenta la ingeniería del software. Esta área de la informática no es una panacea, pero, por lo menos, aporta soluciones parciales a los diversos problemas planteados con el mantenimiento del software.
martes, 29 de abril de 2014
Tipos de Actividades
Tipos de Actividades:
Basili et al. [1996] identifican las siguientes once actividades, que se realizan con cada modificación del software:
Análisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementación y/o a comprobar su impacto en la planificación, coste y facilidad de operación.
Comprensión del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada.
Diseño del cambio: se refiere al diseño propuesto para el cambio, pudiéndose incluir un rediseño del sistema.
Codificación y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado.
Inspección, certificación y consultoría: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseños, reuniones de inspección, etc.
Pruebas de integración: se refiere a comprobar la integración de los componentes modificados con el resto del sistema.
Pruebas de aceptación: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuación del cambio a sus necesidades.
Pruebas de regresión: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pasó.
Documentación del sistema: se revisa y reescribe, en caso necesario, la documentación del sistema para que se ajuste al producto software ya modificado.
Otra documentación (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentación, excepto la documentación del sistema.
Otras actividades, como las dedicadas a la gestión del proyecto de mantenimiento.
Otros resultados interesantes de este mismo estudio se refieren a la distribución del esfuerzo en cada grupo de actividades según se trate de mantenimiento correctivo o perfectivo, resultando que:
La proporción de esfuerzo dedicado a comprensión es mucho mayor en el caso de mantenimiento correctivo que en perfectivo.
La proporción de esfuerzo empleado en inspección, certificación y consultoría es mucho mayor en el caso de mantenimiento perfectivo que en correctivo.
La proporción de esfuerzo dedicado a diseño, codificación y pruebas es muy similar en ambos tipos de mantenimiento.
Distribución del esfuerzo en actividades de mantenimiento
Basili et al. [1996] identifican las siguientes once actividades, que se realizan con cada modificación del software:
Análisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementación y/o a comprobar su impacto en la planificación, coste y facilidad de operación.
Comprensión del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada.
Diseño del cambio: se refiere al diseño propuesto para el cambio, pudiéndose incluir un rediseño del sistema.
Codificación y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado.
Inspección, certificación y consultoría: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseños, reuniones de inspección, etc.
Pruebas de integración: se refiere a comprobar la integración de los componentes modificados con el resto del sistema.
Pruebas de aceptación: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuación del cambio a sus necesidades.
Pruebas de regresión: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pasó.
Documentación del sistema: se revisa y reescribe, en caso necesario, la documentación del sistema para que se ajuste al producto software ya modificado.
Otra documentación (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentación, excepto la documentación del sistema.
Otras actividades, como las dedicadas a la gestión del proyecto de mantenimiento.
Otros resultados interesantes de este mismo estudio se refieren a la distribución del esfuerzo en cada grupo de actividades según se trate de mantenimiento correctivo o perfectivo, resultando que:
La proporción de esfuerzo dedicado a comprensión es mucho mayor en el caso de mantenimiento correctivo que en perfectivo.
La proporción de esfuerzo empleado en inspección, certificación y consultoría es mucho mayor en el caso de mantenimiento perfectivo que en correctivo.
La proporción de esfuerzo dedicado a diseño, codificación y pruebas es muy similar en ambos tipos de mantenimiento.
Distribución del esfuerzo en actividades de mantenimiento
lunes, 21 de abril de 2014
Tipos de Mantenimiento
Existen cuatro tipos de mantenimiento: correctivo, adaptativo, perfectivo y preventivo.
Mantenimiento Adaptativo
Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta.
Estos cambios pueden afectar al sistema operativo (cambio a uno más moderno), a la arquitectura física del sistema informático (paso de una arquitectura de red de área local a Internet/Intranet) o al entorno de desarrollo del software (incorporación de nuevos elementos o herramientas como ODBC).
El tipo de cambio necesario puede ser muy diferente: desde un pequeño retoque en la estructura de un módulo hasta tener que re escribir prácticamente todo el programa para su ejecución en un ambiente distribuido en una red.
Los cambios en el entorno software pueden ser de dos clases:
En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clásico y sustituirlo por un sistema de gestión de bases de datos relacionales.
En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc.
El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio, cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de hardware cada dos años, nuevos sistemas operativos -ó versiones de los antiguos- que se anuncian regularmente, y mejoras en los periféricos o en otros elementos del sistema.
Frente a esto, la vida útil de un sistema software puede superar fácilmente los diez años [Pressman, 1993].
Mantenimiento Perfectivo
Cambios en la especificación, normalmente debidos a cambios en los requisitos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo.
Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la incorporación de un nuevo módulo aplicativo. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.
Algunos autores dividen este tipo de mantenimiento en dos:
Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.
Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución.
Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.
En algunos casos se ha planteado el Mantenimiento para la Reutilización, consistente en modificar el software (buscando y modificando componentes para incluirlos en bibliotecas) para que sea mas fácilmente reutilizable. En realidad este tipo de mantenimiento es preventivo, especializado en mejorar la propiedad de reusabilidad del software.
Mantenimiento Adaptativo
Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta.
Estos cambios pueden afectar al sistema operativo (cambio a uno más moderno), a la arquitectura física del sistema informático (paso de una arquitectura de red de área local a Internet/Intranet) o al entorno de desarrollo del software (incorporación de nuevos elementos o herramientas como ODBC).
El tipo de cambio necesario puede ser muy diferente: desde un pequeño retoque en la estructura de un módulo hasta tener que re escribir prácticamente todo el programa para su ejecución en un ambiente distribuido en una red.
Los cambios en el entorno software pueden ser de dos clases:
En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clásico y sustituirlo por un sistema de gestión de bases de datos relacionales.
En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc.
El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio, cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de hardware cada dos años, nuevos sistemas operativos -ó versiones de los antiguos- que se anuncian regularmente, y mejoras en los periféricos o en otros elementos del sistema.
Frente a esto, la vida útil de un sistema software puede superar fácilmente los diez años [Pressman, 1993].
Mantenimiento Perfectivo
Cambios en la especificación, normalmente debidos a cambios en los requisitos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo.
Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la incorporación de un nuevo módulo aplicativo. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.
Algunos autores dividen este tipo de mantenimiento en dos:
Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.
Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución.
Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.
Mantenimiento Correctivo
El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificación.
Entre otros, los fallos en el software pueden ser de:
Procesamiento, por ejemplo, salidas incorrectas de un programa.
Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de información.
Programación, por ejemplo, inconsistencias en el diseño de un programa.
Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de usuario.
Mantenimiento Preventivo
Este último tipo de mantenimiento consiste en la modificación del software para mejorar sus propiedades (por ejemplo, aumentando su calidad y/o su mantenimiento) sin alterar sus especificaciones funcionales. Por ejemplo, se pueden incluir sentencias que comprueben la validez de los datos de entrada, re estructurar los programas para mejorar su legibilidad, o incluir nuevos comentarios que faciliten la posterior comprensión del programa. Este tipo de mantenimiento es el que más partido saca de las técnicas de ingeniería inversa y reingeniería.
¿Mantenimiento del Software?
Mantenimiento de software
En ingeniería del software, el
mantenimiento de software es la modificación de un producto de software
después de la entrega, para corregir errores, mejorar el rendimiento, u otros
atributos.
El mantenimiento de software es también una de
las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés
de system development life cycle),
que se aplica al desarrollo de software. La fase de mantenimiento es la fase
que viene después del despliegue (implementación) del software en el campo.
Una percepción común del
mantenimiento es que se trata meramente de la corrección de defectos. Sin
embargo, un estudio indicó que la mayoría, más del 80%, del esfuerzo de
mantenimiento es usado para acciones no correctivas (Pigosky 1997). Esta
percepción es perpetuada por usuarios enviando informes de problemas que en
realidad son mejoras de funcionalidad al sistema[cita requerida].
El mantenimiento del software
y la evolución de los sistemas fue abordada por primera vez por Meir M.
Lehman en 1969. Durante un período de veinte años, su investigación condujo a
la formulación de las leyes
de Lehman (Lehman 1997). Principales conclusiones de su investigación incluyen
que el mantenimiento es realmente un desarrollo evolutivo y que las decisiones
de mantenimiento son ayudadas por entender lo que sucede a los sistemas (y al
software) con el tiempo. Lehman demostró que los sistemas continúan
evolucionando con el tiempo. A medida que evolucionan, ellos crecen más
complejos a menos que se toman algunas medidas como refactorización de código para
reducir la complejidad.
Los problemas claves de
mantenimiento de software son administrativos y técnicos. Problemas clave de
administración son: alineación con las prioridades del cliente, dotación de
personal, cuál organización hace mantenimiento, estimación de costos. Son
cuestiones técnicas claves: limitado entendimiento, análisis de impacto, pruebas
(testing), medición de mantenibilidad.
El mantenimiento de software
es una actividad muy amplia que incluye la corrección de errores, mejoras de
las capacidades, eliminación de funciones obsoletas y optimización. Debido a
que el cambio es inevitable, se debe desarrollar mecanismos para la evaluación,
controlar y hacer modificaciones.
Así que cualquier trabajo
realizado para cambiar el software después de que esté en operación es
considerado trabajo de mantenimiento. El propósito es preservar el valor del
software sobre el tiempo. El valor puede ser mejorado ampliando la base de
clientes, cumpliendo requisitos adicionales, siendo cada vez más fácil de usar,
más eficiente y empleando más nuevas tecnología. El mantenimiento puede abarcar
20 años, mientras que el desarrollo puede estar entre 1 y 2 años.
Importancia
del mantenimiento de software
A finales de los años 1970,
una famosa y ampliamente citada estudio de encuesta por Lientz y Swanson,
expuso la muy alta fracción de los costos del ciclo de vida que estaban siendo
gastados en mantenimiento. Clasificaron las actividades de mantenimiento en
cuatro clases:
- Adaptable – modificar el sistema para hacer frente a cambios en el
ambiente del software (DBMS, OS)2
- Perfectivo – implementar nuevos, o cambiar requerimientos de
usuario referentes a mejoras funcionales para el software
- Correctivo, diagnosticar y corregir errores, posiblemente los
encontraron por los usuarios2
- Preventiva – aumentar la capacidad de mantenimiento de software o
fiabilidad para evitar problemas en el futuro2
La encuesta mostró que
alrededor del 75% del esfuerzo de mantenimiento fue en los dos primeros dos
tipos, y la corrección de errores consumía aproximadamente el 21%. Muchos
estudios posteriores sugieren una magnitud similar del problema. Los estudios
muestran que la contribución del usuario final es crucial durante el análisis y
recopilación de nuevos datos de requerimiento. Y ésta es la causa principal de
cualquier problema durante el mantenimiento y evolución del software. Así que
el mantenimiento de software es importante porque consume gran parte de los
costos del ciclo de vida y también la imposibilidad de cambiar el software de
forma rápida y fiable significa que las oportunidades de negocio se pierden. 3 4 5
Impacto de los factores clave
de ajuste en el mantenimiento (por orden de máximo impacto positivo)
|
Factores de mantenimiento
|
Rango más
|
|
Especialistas de mantenimiento
|
35%
|
|
Experiencia alta del personal
|
34%
|
|
Variables y datos manejados por tablas
|
33%
|
|
Baja complejidad de la base de código
|
32%
|
|
Y2K y motores especiales de búsqueda
|
30%
|
|
Herramientas de reestructuración de código
|
29%
|
|
Herramientas de reingeniería
|
27%
|
|
Lenguajes de porgramación de alto nivel
|
25%
|
|
Herramientas de ingeniería inversa
|
23%
|
|
Herramientas de análisis de complejidad
|
20%
|
|
Herramientas de seguimiento de defectos
|
20%
|
|
Especialistas en "actualización masiva"
Y2K
|
20%
|
|
Herramientas de control de cambio automático
|
18%
|
|
Horas extras no pagadas
|
18%
|
|
Mediciones de calidad
|
16%
|
|
Inspecciones formales de la base de código
|
15%
|
|
Bibliotecas de pruebas de regresión
|
15%
|
|
Tiempo de respuesta excelente
|
12%
|
|
Formación anual de > 10 días
|
12%
|
|
Experiencia de la alta gerencia
|
12%
|
|
Automatización del HELP desk
|
12%
|
|
No módulos propensos a errores
|
10%
|
|
Reporte de defectos en-línea
|
10%
|
|
Medidas de productividad
|
8%
|
|
Excellent ease of use
|
7%
|
|
Medidas de satisfacción de usuarios
|
5%
|
|
Alta moral del equipo
|
5%
|
|
Suma
|
503%
|
No sólo son problemáticos los
módulos propensos a errores, también muchos otros factores pueden disminuir el
rendimiento. Por ejemplo, muy complejo "código espagueti" es bastante
difícil de mantener con seguridad. Una situación muy común que a menudo degrada
el rendimiento es la falta de herramientas de mantenimiento adecuadas, como
software de seguimiento de defectos, software de gestión de cambio y software
de biblioteca de pruebas. A continuación se describen algunos de los factores y
la gama de impacto en el mantenimiento de software.
Impacto de los factores clave
de ajuste en el mantenimiento (por orden de máximo impacto negativo)
|
Factores de mantenimiento
|
Rango menos
|
|
Módulos propensos a errores
|
-50%
|
|
Datos y variables incrustados
|
-45%
|
|
Inexperiencia del personal
|
-40%
|
|
Alta complejidad del código
|
-30%
|
|
No Y2K de motores de búsqueda especiales
|
-28%
|
|
Métodos manuales de control de cambio
|
-27%
|
|
Lenguajes de programación de bajo nivel
|
-25%
|
|
Ninguna herramienta de seguimiento de defectos
|
-24%
|
|
No hay especialistas en "actualización
masiva" Y2K
|
-22%
|
|
Pobre facilidad de uso
|
-18%
|
|
No hay mediciones de calidad
|
-18%
|
|
No hay especialistas de mantenimiento
|
-18%
|
|
Tiempo de respuesta pobre
|
-16%
|
|
No hay inspecciones de código
|
-15%
|
|
No hay bibliotecas de pruebas de regresión
|
-15%
|
|
No hay automatización del help desk
|
-15%
|
|
No hay reportes de defecto en línea
|
-12%
|
|
Falta de experiencia de gestión
|
-15%
|
|
No hay herramientas de reestructuración
|
-10%
|
|
No hay entrenamiento anual
|
-10%
|
|
Ningunas herramientas de reingeniería
|
-10%
|
|
No hay herramientas de ingeniería inversa
|
-10%
|
|
No hay herramientas de análisis de la complejidad
|
-10%
|
|
No hay medidas de productividad
|
-7%
|
|
Moral pobre del equipo
|
-6%
|
|
No hay medidas de satisfacción del usuario
|
-4%
|
|
Horas extras no pagadas
|
0%
|
|
Suma
|
-500%
|
Fase de
mantenimiento
La fase de mantenimiento de
software involucra cambios al software para corregir defectos encontrados
durante su uso o la adición de nueva funcionalidad mejorando la usabilidad y aplicabilidad del
software.
El mantenimiento del software
involucra diferentes técnicas específicas. Una técnica es el rebanamiento
estático, la cual es usada para identificar todo el código de programa que
puede modificar alguna variable. Es generalmente útil en la refabricación del código
del programa y fue específicamente útil en asegurar conformidad para el problema
del año 2000.
La fase de mantenimiento de
software es una parte explícita del modelo en cascada del proceso de desarrollo
de software el cual fue desarrollado durante el movimiento de programación
estructurada en computadores. El otro gran modelo, el Desarrollo en espiral
desarrollado durante el movimiento de ingeniería de software orientada a objeto
no hace una mención explícita de la fase de mantenimiento. Sin embargo, esta
actividad es notable, considerando el hecho de que dos tercios del coste del
tiempo de vida de un sistema de software involucran mantenimiento (Page-Jones
pg 31).
En un ambiente formal de
desarrollo de software, la organización o equipo de desarrollo tendrán algún
mecanismo para documentar y rastrear defectos y deficiencias. El Software tan
igual como la mayoría de otros productos, es típicamente lanzado con un
conjunto conocido de defectos y deficiencias. El software es lanzado con esos
defectos conocidos porque la organización de desarrollo en las utilidades y el valor
del software en un determinado nivel de calidad compensa el impacto de los
defectos y deficiencias conocidas.
Las deficiencias conocidas son
normalmente documentadas en una carta de consideraciones operacionales o notas
de lanzamiento (release notes) es así que los usuarios del software serán
capaces de trabajar evitando las deficiencias conocidas y conocerán cuándo el
uso del software sería inadecuado para tareas específicas.
Con el lanzamiento del
software (software release), otros defectos y deficiencias no documentados
serán descubiertas por los usuarios del software. Tan pronto como estos
defectos sean reportados a la organización de desarrollo, serán ingresados en
el sistema de rastreo de defectos.
Las personas involucradas en
la fase de mantenimiento de software esperan trabajar en estos defectos
conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido
como un lanzamiento de mantenimiento, el cual resolverá los temas pendientes.
Mantenimiento
Preventivo de Software
El mantenimiento preventivo
consiste en una atención constante de limpieza, revisión y afinación de los
distintos elementos integrantes de un equipo de cómputo. Es importante saber
que la mayoría de los problemas que se presentan en el trabajo cotidiano, se debe
a la falta de un programa específico de mantenimiento de los equipos, de tal
manera que la mayoría de los problemas se resuelven con el mismo procedimiento
del mantenimiento preventivo. El mantenimiento tiene técnicas para darle un
periodo de vida útil más largo y libre de fallas. Debemos de tener en cuenta
que es necesario darle mantenimiento al software ya que el continuo uso genera
una serie de cambios en la configuración original del sistema, causando bajas
en el rendimiento que al acumularse con el tiempo pueden generar problemas
serios. Actualmente es indispensable mantener actualizada la protección contra
virus informáticos.
Por supuesto es muy recomendable usar su equipo responsablemente, ya que esto le podrá causar un gasto mayor a futuro.
Las recomendaciones son:
Cuidar las páginas a las que accesa, las de música, videos o juegos
regularmente traen enlaces que pueden filtrarse directamente al equipo de
cómputo, tener un antivirus actualizado, hacer cada cierto tiempo un escaneado
y limpieza de su PC, evitar los mensajes SPAM que llegan en los correos
electrónicos, estos mensajes llegan normalmente con remitente desconocido y se
almacenan en la carpeta Correo no deseado, generalmente son solo virus que no
hacen mucho daño, pero también puede costar hasta el formateo del equipo y con
esto, la perdida de archivos importantes.
Suscribirse a:
Entradas (Atom)