Software Testing – Pruebas de Software

El Software Testing o como se conoce en español las pruebas de software se aplican como

una etapa más del proceso de desarrollo de software, su objetivo es asegurar que el software

cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera

tener. En un principio la mayoría de  empresas de desarrollo contaban con una etapa de

pruebas demasiado informal, en la actualidad el software testing se ha convertido en una de

las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado el

origen de diversas metodologías. En la actualidad el software testing se hace más

complicado ya que debe hacer frente a una gran cantidad de metodologías de desarrollo,

lenguajes de programación, sistemas operativos, hardware etc.

Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos

más fundamentales que debe considerar todo proceso de pruebas. Debido a esta

complejidad actualmente se cuentan con una gran cantidad de software diseñado

exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de software

testing, la administración y seguimiento de errores, la administración de los casos de

prueba, automatización de pruebas etc. Luego de culminadas las etapas de análisis, diseño y

desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el software se

mantenga en un ambiente aislado o separado del ambiente de desarrollo o de producción, lo

ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en

producción para asegurar su correcto funcionamiento en esa futura etapa. Se debe

considerar adquirir un equipo de pruebas especializado “software tester” o analista de

pruebas, con experiencia. Estas personas tienen una formación que les permite detectar una

gran cantidad de errores en tiempos mínimos, así como una metodología especifica que les

permite hacer el trabajo de manera correcta. Algunas empresas más informales utilizan a

los futuros usuarios del sistema como testers situación que puede traer una serie de

problemas debido a la poca experiencia que pueden tener los usuarios en la detección de

errores.

Además se obvian pruebas importantes como las pruebas de Esfuerzo o “Stress testing”,

también se dejan de lado las pruebas unitarias o pruebas modulares, las que deberían

asegurar que cada modulo del sistema trabaje correctamente de manera independiente. Otro

error muy conocido en empresas de software es el uso de los mismos desarrolladores como

analistas de pruebas, es muy difícil probar con objetividad un software si nosotros mismos

lo hemos desarrollado, un técnico o analista programador empezara a probar con la idea

preconcebida de que su hijito trabaja a la perfección e inconcientemente evitara realizar

pruebas mas exhaustivas considerando que las mismas podrían ser absurdas o innecesarias.

Lo bueno es que poco a poco estas ideas van quedando descartadas y se van alineando

conceptos hacia un software testing profesional.

Functional Testing – Pruebas Funcionales

Se denominan pruebas funcionales, a las pruebas de software que tienen por objetivo probar

que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han

sido creados. Es común que este tipo de pruebas sean desarrolladas por analistas de pruebas

con apoyo de algunos usuarios finales. Esta etapa suele ser la ultima etapa de pruebas y al

dar conformidad sobre esta el paso siguiente es la producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de

caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se

generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en

el análisis de los datos de entrada y en los de salida. Esto generalmente se define en los

casos de prueba preparados antes del inicio de las pruebas. Las pruebas funcionales en la

mayoría de los casos son realizadas manualmente por el analista de pruebas. También es

posible automatizar este tipo de pruebas utilizando herramientas como WinRunner o

SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con

el aplicativo a probar. La automatización de pruebas puede resultar compleja y solo se

recomienda en algunas funcionalidades específicas, por ejemplo en las pantallas que

tendrán mayor uso, generalmente pantallas de ingreso de datos. Se debe tener en cuenta que

el costo de estas licencias suele ser bastante elevado.

Al realizar pruebas funcionales lo que se pretende es ponerse en los pies del usuario, es

decir utilizar el sistema como él lo utilizaría. Sin embargo el analista de pruebas debe ir

más allá que cualquier usuario, generalmente se requiere apoyo de los usuarios finales ya

que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos, enfocados

básicamente al negocio. Posibles particularidades que no se hayan contemplado

adecuadamente en el diseño funcional, el analista de pruebas debería dar fuerza a las

pruebas funcionales y más aún a las de robustez. Generalmente los usuarios realizan las

pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que

tiene más bien una misión destructiva. Su objetivo será encontrar alguna posible debilidad y

si la llega a ubicar se esforzará por que deje de ser pequeña y posiblemente se convertirá en

un gran error. Cada error encontrado por el analista de pruebas es un éxito, y se debería

considerar como tal.

Unit Testing - Pruebas Unitarias

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a

considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White

Box), o pruebas modulares ya que nos permiten determinar si un modulo del programa esta

listo y correctamente terminado. Estas pruebas no se deben confundir con las pruebas

informales que realiza el programador mientras esta desarrollando el módulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a

probar, se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su

funcionalidad de manera sencilla y rápida. También es importante separar los módulos de

acuerdo a su funcionalidad, si los módulos son muy grandes y contienen muchas

funcionalidades, estos se volverán más complejos de probar y al encontrar algún error será

más difícil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de

pruebas podrá recomendar que un modulo muy complejo sea separado en 2 o 3 módulos

más sencillos.

Fig 1. Pruebas de Caja Blanca - White Box Software Testing

Este tipo de pruebas debe ser realizado por personal especializado en Software Testing, el

cual debe estar familiarizado en el uso de herramientas de depuración y pruebas, así mismo

deben conocer el lenguaje de programación en el que se esta desarrollando la aplicación. En

la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de

pruebas, inclusive se pueden conseguir herramientas para cada tipo de lenguaje. Estas

herramientas pueden facilitar el desarrollo de pruebas, la elaboración de casos de pruebas,

el seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas

unitarias son: JUnit, La Suite de  Mercury, CPPUnit etc. El objetivo fundamental de las

pruebas unitarias es asegurar el correcto funcionamiento de las interfases, o el flujo de

datos entre los componentes.

No es un requisito indispensable la culminación de todos los módulos del sistema para

iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan.

En la actualidad algunas metodologías consideran oportuno iniciar la etapa de pruebas

unitarias poco después del desarrollo. En esta imagen se muestra lo que se considera una

representación clásica de Software Testing White Box o pruebas de caja blanca. En este

tipo de pruebas el cubo representaría un sistema en donde se pueden observar los diversos

componentes que forman parte del mismo, cada uno de estos componentes debe ser

probado en su totalidad (óvalos), y también sus interfases o comunicaciones con los demás

componentes (flechas). Este tipo de pruebas también son llamadas pruebas de caja de cristal

ya que este último término representa mejor el tipo de pruebas.

Lo importante en este tipo de pruebas es que se deben tener claros los siguientes aspectos:

Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos

deben ser preparados con minuciosidad, ya que el resultado de las pruebas dependen

de estos.

Se debe conocer que componentes interactúan en cada caso de prueba.

Se debe conocer de antemano que resultados debe devolver el componente según

los datos de entrada utilizados en la prueba.

Finalmente se deben comparar los datos obtenidos en la prueba con los datos

esperados, si son idénticos podemos decir que el modulo supero la prueba y

empezamos con la siguiente.

Luego de tener una buena cantidad de módulos independientes probados y encontrados

Conformes, el siguiente paso es integrarlos. Las principales formas de integración que

existen son las siguientes:

Integración Incremental.

Integración no incremental.

Integración Incremental

Al realizar una integración incremental debemos combinar o unir el siguiente módulo que

se debe probar con el conjunto de módulos ya probados. El número de módulos se

incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar

de 2 formas:

Integración Incremental Ascendente.

Integración Incremental Descendente.

Integración Incremental Ascendente

En este tipo de integración se combinan los módulos de más bajo nivel en grupos que

realizan alguna sub función específica. A través de un driver (módulo impulsor) se simulan

llamadas a los módulos, se introducen los datos de prueba y se recogen los resultados.

Cada grupo se prueba usando su driver (test integrador), y este luego es sustituido por los

módulos de nivel superior en la jerarquía. En el último paso se prueba el programa

completo con sus entradas y salidas reales.

La siguiente imagen muestra la primera fase de la integración ascendente, en este ejemplo

cada módulo debe ser probado por separado, para esto se debe construir un driver o

impulsor para probar cada módulo.

 

Fig. 2 Integración Incremental Ascendente - Fase 1

Tal como se muestra en la figura 3, luego de probar los módulos de más bajo nivel (E, F y

G), continuamos con los módulos del siguiente nivel, para esto debemos construir nuevos

drivers o impulsores (B y C), que se aplicaran directamente a los módulos superiores (B y

C) y estos a su vez se integrarán a los de más bajo nivel (E, F Y G).

Fig. 3 Integración Incremental Ascendente - Fase 2

Este proceso se repite algunas veces hasta que se culmina por probar el sistema completo,

en la figura 4 se muestra un nivel más de integracion incremental ascendente.

 

Fig. 4 Integración Incremental Ascendente - Fase 3

 

Ventajas de la integración incremental ascendente:

Las entradas para las pruebas son más fáciles de crear ya que los módulos inferiores

suelen tener funciones más específicas.

Es más fácil la observación de los resultados de las pruebas puesto que es en los

módulos inferiores donde se elaboran.

Resuelve primero los errores de los módulos inferiores que son los que acostumbran

tener el procesamiento más complejo, para luego nutrir de datos al resto del sistema.

Desventajas de la integración incremental ascendente:

Se requieren módulos impulsores, que deben escribirse especialmente y que no son

necesariamente sencillos de codificar.

El sistema como entidad no existe hasta que se agrega el último módulo.

Integración incremental Descendente

Inicia del módulo de control principal (de mayor nivel) para luego ir incorporando los

módulos subordinados progresivamente. No hay un procedimiento considerado óptimo para

seleccionar el siguiente módulo a incorporar. La única regla es que el módulo incorporado

tenga todos los módulos que lo invocan previamente probados.

En general no hay una secuencia óptima de integración. Debe estudiarse el problema

concreto y de acuerdo a este, buscar el orden de integración más decuado para la

organización de las pruebas. No obstante, pueden considerarse las siguientes pautas:

Si hay secciones críticas como ser un módulo complicado, se debe proyectar la

secuencia de integración para incorporarlas lo antes posible.

El orden de integración debe incorporar cuanto antes los módulos de entrada y

salida.

Existen principalmente dos métodos para la incorporación de módulos:

1. Primero en profundidad: Primero se mueve verticalmente en la estructura de

módulos.

2. Primero en anchura: Primero se mueve horizontalmente en la estructura de módulos.

Etapas de la integración descendente:

1. El módulo de mayor nivel hace de impulsor y se escriben módulos ficticios

simulando a los subordinados, que serán llamados por el módulo de control

superior.

2. Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado.

3. Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real que

reemplazaba, según el orden elegido.

4. Escribir los módulos ficticios subordinados que se necesiten para la prueba del

nuevo módulo incorporado.

Ventajas de la integración descendente:

Las fallas que pudieran existir en los módulos superiores se detectan en una etapa

temprana.

Permite ver la estructura del sistema desde un principio, facilitando la elaboración

de demostraciones de su funcionamiento.

Concuerda con la necesidad de definir primero las interfaces de los distintos

subsistemas para después seguir con las funciones específicas de cada uno por

separado.

Desventajas de la integración descendente:

Requiere mucho trabajo de desarrollo adicional ya que se deben escribir un gran

número de módulos ficticios subordinados que no siempre son fáciles de realizar.

Suelen ser más complicados de lo que aparentan.

Antes de incorporar los módulos de entrada y salida resulta difícil introducir los

casos de prueba y obtener los resultados.

Los juegos de datos de prueba pueden resultar difíciles o imposibles de generar

puesto que generalmente son los módulos de nivel inferior los que proporcionan los

detalles.

Induce a diferir la terminación de la prueba de ciertos módulos.

Integración No Incremental

La integración no incremental es bastante sencilla y generalmente se recomienda para

proyectos de poca envergadura, la integración consiste en probar cada modulo por separado

de manera similar a la intregación incremental pero una vez de terminar con los módulos

independientes, se continua probandolos todos juntos como un todo.

La única ventaja es que no se necesita ningún tipo de trabajo adicional: ni planificar el

orden de integración, ni crear módulos impulsores, ni crear módulos ficticios subordinados.

Por otro lado, la lista de desventajas incluye:

No se tiene noción de la comunicación de los módulos hasta el final.

En ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o

presentar.

El hecho de realizar todas las pruebas de una vez hace que las sesiones de prueba

sean largas y tediosas.

La cantidad de errores que arroje puede ser atemorizante.

La tarea de encontrar la causa de los errores resulta mucho más compleja que con

los métodos incrementales.

Se corre el riesgo de que a poco tiempo de que se cumpla el plazo de entrega, haya

que volver sobre el diseño y la codificación del sistema.

Pruebas de Requisitos

La prueba de requisitos pretende comprobar los tres principales atributos de calidad de los

requisitos, con el fin de detectar tantos errores como sea posible y cuanto antes. Los tres

atributos son corrección (carencia de ambigüedad), compleción (especificación completa y

clara del problema) y consistencia (que no haya requisitos contradictorios). (Bashir and

Goel 2000) proponen la utilización de una Matriz de Prueba de Requisitos (RTM:

Requirements Testing Matrix), en la que se lista cada requisito junto a sus casos de uso y

casos de prueba:

Tabla 1. Tabla RTM (Matriz de Tabla de Requisitos)

Pruebas del diseño

La fase de diseño tiene como objetivo generar un conjunto de especificaciones completas

del sistema que se va a implementar, transformando los requisitos en un Plan de

Implementación. La prueba del diseño debe comprobar su consistencia, compleción,

corrección, factibilidad (es decir, que el diseño sea realizable) y trazabilidad (es decir, que

podamos “navegar” desde un requisito hasta el fragmento del diseño en que éste se

encuentra). Las actividades que proponen (Bashir and Goel 2000) para este tipo de pruebas

se muestran en la Figura 1.

Figura 1. Actividades para la prueba del diseño

Revisiones e Inspecciones del Código Fuente

Las revisiones e inspecciones de código fuente son una técnica para la detección manual de

errores en el código (Bashir and Goel 2000). Se trabaja bajo el principio de que “cuatro

ojos ven más que dos”, de tal manera que el método de trabajo consistirá, básicamente, en

pasar el código escrito por un programador a un tercero o grupo de terceros, que tratará de

encontrar posibles errores, faltas de adecuación al estilo de codificación utilizado por la

organización, etc. Para ello suelen utilizarse listas de comprobación (checklists), que

enumeran defectos y en los que el revisor anota su presencia o ausencia.

Pruebas de Validación

Las pruebas de validación en la ingeniería de software son el proceso de revisión que el

sistema de software producido cumple con las especificaciones y que cumple su cometido.

Es normalmente una parte del proceso de pruebas de software de un proyecto, que también

utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el

proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quería.

Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para

determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el

cliente quiere?

Tipos de pruebas de validación

Pruebas de aceptación: Son las que hará el cliente. Se determina que el sistema cumple

con lo deseado y se obtiene la conformidad del cliente.

Pruebas alfa: Realizadas por el usuario con el desarrollador como observador en un

entorno controlado (simulación de un entorno de producción).

Pruebas beta: Realizadas por el usuario en su entorno de trabajo y sin observadores.

Pruebas de Sistema

El software ya validado se integra con el resto del sistema donde algunos tipos de pruebas a

considerar son las siguientes:

Rendimiento: determinan los tiempos de respuesta, el espacio que ocupa el módulo en

disco o en memoria, el flujo de datos que genera a través de un canal de

comunicaciones, etc.

Resistencia: determinan hasta donde puede soportar el programa determinadas

condiciones extremas.

Robustez: determinan la capacidad del programa para soportar entradas incorrectas.

Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de acceso

al sistema y acceso a datos.

Usabilidad: se determina la calidad de la experiencia de un usuario en la forma en la

que éste interactúa con el sistema, se considera la facilidad de uso y el grado de

satisfacción del usuario.

Instalación: se determinan las operaciones de arranque y actualización del software.

Pruebas de Regresión

Se denominan pruebas de regresión a cualquier tipo de pruebas de software que intentan

descubrir las causas de nuevos errores, carencias de funcionalidad, o divergencias

funcionales con respecto al comportamiento esperado del software, inducidos por cambios

recientemente realizados en partes de la aplicación que anteriormente al citado cambio no

eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como

consecuencia inesperada del citado cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versiones, falta

de consideración acerca del ámbito o contexto de producción final y extensibilidad del error

que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del

rediseño de la aplicación.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una

buena práctica que cuando se localiza y corrige un error, se grabe una prueba que exponga

el error y se vuelvan a probar regularmente después de los cambios subsiguientes que

experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de manera

parcial o totalmente automatizada. La práctica habitual en programación extrema es que

este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del

software.

Uso de la pruebas de regresión

Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un programa,

sino a menudo suelen usarse para rastrear la calidad de su salida. Por ejemplo en el diseño

de un compilador, las pruebas de regresión deben rastrear el tamaño del código, el tiempo

de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que

aparezca un nuevo build, el proceso de regresión aparece.

Otras Pruebas de Software

Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción

con otros hardwares, bases de datos y redes.

Prueba de sanidad. Determina si la nueva versión de un software esta bien realizada y

si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de

un programa cumple con casi todos los requisitos pero destruye la base de datos al

leerla, por lo tanto se dice que este software no esta en una condición sana.

Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas, generalmente

usadas en sitios web y en servidores con gran cantidad de datos donde se determina en

cuales puntos existen degradaciones del sistema.

Prueba de estrés. Es una prueba de carga y performance basada en la funcionalidad del

sistema bajo cargas pesadas, un gran numero de repeticiones, manejo de grandes datos

y demasiadas preguntas a bases de datos grandes.

Prueba de performance. Es una de las pruebas finales y sirve para definir los

requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye

entrevistas con el usuario y programador.

Prueba de instalación y desinstalación. Determina la eficiencia de los procesos que

instalan y desinstalan las aplicaciones del programa.

Prueba de recuperación. Es la prueba que evalúa que tan bien se recupera el sistema

luego de bloqueos, fallas del hardware u otros problemas catastróficos.

Prueba de compatibilidad. Evalúa el desempeño del software en diferentes hardwares,

sistemas operativos, redes, etc.

Prueba de exploración. Es una prueba informal del software que no esta basada en

ningún plan o caja de prueba y a menudo los testers aprenden del programa al explorar

todas las aplicaciones posibles.

Prueba de anuncio. Es similar a la prueba de exploración pero los testers deben tener

suficiente noción sobre el funcionamiento del programa antes de comenzar esta prueba.

Incluye reunión con analistas y programadores.

Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el

programa.

Prueba de comparación. En esta prueba se comparan los pros y los contras del

programa con los programas creados por la competencia.

Prueba de mutación. Esta prueba esta basada en la introducción deliberada de

diferentes códigos externos al programa para reexaminar si estos pueden ser detectados.

Requiere gran disponibilidad de recursos de computación.

Automatización de las pruebas

(Rice 2002) enumera y explica los diez retos más importantes en la automatización del

proceso de pruebas. De acuerdo con este autor, éstos son los siguientes:

1. Falta de herramientas, debido fundamentalmente a su elevado precio o a que las

existentes no se ajusten al propósito o entorno para el que se necesitan. La primera

razón parece deberse a la no mucha importancia que habitualmente se le da a la fase de

pruebas, y eso que el costo de corregir un error puede, en muchos casos, superar al de la

licencia de uso. Sería conveniente evaluar el coste de corrección de defectos del

software entregado y compararlo con el de la licencia de la herramienta de pruebas.

2. Falta de compatibilidad e interoperabilidad entre herramientas.

3. Falta de proceso de gestión de la configuración. Igual que las diferentes versiones del

código fuente, las pruebas, especialmente las de regresión, deben someterse a un control

de versiones. Recuérdese que el proceso de Gestión de la Configuración es uno de los

procesos de soporte del estándar ISO/IEC 12207 (ISO/IEC 1995), que debería utilizarse

en la ejecución de los procesos principales, y muy especialmente en los de Desarrollo y

Mantenimiento.

4. Falta de un proceso básico de pruebas y de conocimiento de qué es lo que se debe

probar.

5. Falta de uso de las herramientas de prueba que ya se poseen, bien por su dificultad de

uso, por falta de tiempo para aprender a manejarla, por falta de soporte técnico,

obsolescencia, etc.

6. Formación inadecuada en el uso de la herramienta.

7. La herramienta no cubre todos los tipos de prueba que se desean (corrección, fiabilidad,

seguridad, rendimiento, etc.). Obviamente, a la hora de elegir la herramienta, deberían

tenerse priorizados los tipos de pruebas, y entonces hacer la elección de la herramienta

basados en esto. A veces también es necesario utilizar no una, sino varias herramientas

de prueba, así como tener en cuenta que es imposible automatizar el 100% de las

pruebas.

8. Falta de soporte o comprensión por parte de los jefes, debido otra vez a la escasa

importancia que habitualmente se le da a la fase de pruebas.

9. Organización inadecuada del equipo de pruebas.

10. Adquisición de una herramienta inadecuada.

Mantenimiento del Software

Aun cuando son las últimas en el ciclo de vida del software, las actividades de

mantenimiento no son las menos importantes. Muy al contrario, a continuación veremos

que el mantenimiento del software se ha convertido en la principal actividad en cuanto a

recursos necesarios y costes.

Según la terminología ANSI-IEEE, el mantenimiento del software es: “la modificación de

un producto de software después de su entrega al cliente o usuario para corregir defectos,

para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de

entorno”.

Costes del Mantenimiento del Software

Múltiples estudios señalan que el mantenimiento es la parte más costosa del ciclo de vida

del software. Estadísticamente está comprobado que el coste de mantenimiento de un

producto software a lo largo de toda su vida útil supone más del doble que los costes de su

desarrollo. La tendencia es creciente con el paso del tiempo:

Tabla 2. Incremento en los Costes de Mantenimiento

Existen empresas que se acercan a porcentajes del 95% de los recursos dedicados al

mantenimiento, con lo cual se hace imposible el desarrollo de nuevos productos de

software. Esta situación se conoce como Barrera de Mantenimiento.

En general, el porcentaje de recursos necesarios para el mantenimiento se incrementa a

medida que se produce más software.

Los estudios sobre la situación del mercado comercial del Mantenimiento de Software son

relativamente escasos:

En España, el estudio del Ministerio de Industria y Energía sobre las Tecnologías de la

Información calcula que en 1996 el mantenimiento del software supuso 31.184 millones

de pesetas, a los que habría que añadir una parte importante de los 88.140 millones

reseñados en el epígrafe de externalización (outsourcing).

Tipos de Mantenimiento

En la definición de mantenimiento aparecen indicados, directa o indirectamente, cuatro tipos de mantenimiento: Corregir defectos → correctivo Mejorar el rendimiento → preventivo/perfectivo u otras propiedades Adaptar a un cambio de entorno → adaptativo

Las definiciones de ISO e IEEE no coinciden.

En algunas propuestas más modernas, se proponen algunas subdivisiones (metodología MANTEMA).

Un resumen del papel que representa cada tipo de mantenimiento aparece en la Figura 2:

Figura 2. Tipos de Mantenimiento.

Mientras que el cambio tecnológico afecta indirectamente a los sistemas de software, el entorno de trabajo y los usuarios lo hacen directamente, produciendo demandas de mantenimiento adaptativo y perfectivo respectivamente.

En MANTEMA se trabaja con los siguientes tipos:

No Planificable (NP):

o Correctivo Urgente (UC): localizar y eliminar los posibles defectos que

bloquean el programa o los procesos de funcionamiento de la empresa.

Planificable (P):

o Correctivo No Urgente (NUC): localizar y eliminar los posibles defectos de los

programas que no son bloqueantes.

o Perfectivo (PER): añadir al software nuevas funcionalidades solicitadas por los

usuarios.

o Adaptativo (A): modificar el software para adaptarlo a cambios en el entorno de

trabajo (hardware o software).

o Preventivo (PRE): modificar el software para mejorar sus propiedades (calidad,

mantenibilidad, etc.).

Mantenimiento Correctivo

A pesar de las pruebas y verificaciones que aparecen en etapas anteriores del ciclo de vida

del software, los programas pueden tener defectos. 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 lo siguiente:

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 Adaptivo

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.

Los cambios pueden afectar lo siguiente:

El sistema operativo (cambio a uno más moderno),

La arquitectura física del sistema informático (paso de una arquitectura de red de área

local a Internet/Intranet),

El entorno de desarrollo del software (incorporación de nuevos elementos o

herramientas como el ODBC).

La envergadura del cambio necesario puede ser muy diferente: desde un pequeño retoque

en la estructura de un módulo hasta tener que reescribir prácticamente todo el programa

para su ejecución en un ambiente distribuido en una red.

Los cambios en el entorno de 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.

Este tipo de mantenimiento es cada vez más frecuente debido principalmente al cambio,

cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de

hardware, nuevos sistemas operativos o versiones de los antiguos, 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).

Mantenimiento Perfectivo

Cambios en la especificación, normalmente debidos a cambios en los requerimientos de un

producto de software, implican un nuevo tipo de mantenimiento llamado perfectivo. La

causa es muy variada. Desde algo tan simple como cambiar el formato de impresión de un

informe, hasta la incorporación de un nuevo módulo funcional. 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 la ejecución.

Mantenimiento Preventivo

Este último tipo de mantenimiento consiste en la modificación del software para mejorar

las propiedades de dicho software (por ejemplo, aumentando su calidad y/o su

mantenibilidad) sin alterar sus especificaciones funcionales.

Algunas maneras de hacerlo son las siguientes:

Incluir sentencias que comprueben la validez de los datos de entrada,

Reestructurar los programas para mejorar su legibilidad, o

Incluir nuevos comentarios que faciliten la posterior comprensión del programa.

En algunos casos se ha planteado el Mantenimiento para la Reutilización, consistente en

modificar el software (buscando y modificando componentes para incluirlos en las

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.