c



  c


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.

Ä
 
  Ä
 

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.

V
 
 V

 

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.
 Ä
 
 c
 


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:
j? 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.
j? Se debe conocer que componentes interactúan en cada caso de prueba.
j? Se debe conocer de antemano que resultados debe devolver el componente según
los datos de entrada utilizados en la prueba.
j? Äinalmente 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:
j? åntegración åncremental.
j? åntegración no 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:
j? åntegración åncremental Ascendente.
j? åntegración åncremental Descendente.
å
å 
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.

Ä
 å
å Ä 

Tal como se muestra en la figura 3, luego de probar los módulos de más bajo nivel (E, Ä 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, Ä Y G).

Ä
!å
å Ä  
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.

Ä
"å
å Ä !

# 


 $
j? 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.
j? 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.
j? 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.

 % 


 $
j? Se requieren módulos impulsores, que deben escribirse especialmente y que no son
necesariamente sencillos de codificar.
j? El sistema como entidad no existe hasta que se agrega el último módulo.
å

 
ånicia 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:
j? Si hay secciones críticas como ser un módulo complicado, se debe proyectar la
secuencia de integración para incorporarlas lo antes posible.
j? 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:

? Primero en profundidad: Primero se mueve verticalmente en la estructura de
módulos.
? Primero en anchura: Primero se mueve horizontalmente en la estructura de módulos.

O& 

 $
? 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.
? Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado.
!? Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real que
reemplazaba, según el orden elegido.
"? Escribir los módulos ficticios subordinados que se necesiten para la prueba del
nuevo módulo incorporado.
# 

 $
j? Las fallas que pudieran existir en los módulos superiores se detectan en una etapa
temprana.
j? Permite ver la estructura del sistema desde un principio, facilitando la elaboración
de demostraciones de su funcionamiento.
j? 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.

 % 

 $
j? 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.
j? Antes de incorporar los módulos de entrada y salida resulta difícil introducir los
casos de prueba y obtener los resultados.
j? 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.
j? ånduce a diferir la terminación de la prueba de ciertos módulos.

å
' å

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:
j? No se tiene noción de la comunicación de los módulos hasta el final.
j? En ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o
presentar.
j? El hecho de realizar todas las pruebas de una vez hace que las sesiones de prueba
sean largas y tediosas.
j? La cantidad de errores que arroje puede ser atemorizante.
j? La tarea de encontrar la causa de los errores resulta mucho más compleja que con
los métodos incrementales.
j? 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.

 ()

 

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:

(*+*
,()

 -
  
. 

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
åmplementació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 Äigura 1.

Ä

%
 &&
. 

(%

 å &
 
 Ä

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.
  #



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?


& & %


j? 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.
j? Pruebas alfa: Realizadas por el usuario con el desarrollador como observador en un
entorno controlado (simulación de un entorno de producción).
j? Pruebas beta: Realizadas por el usuario en su entorno de trabajo y sin observadores.

 c


El software ya validado se integra con el resto del sistema donde algunos tipos de pruebas a
considerar son las siguientes:
j? 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.
j? Resistencia: determinan hasta donde puede soportar el programa determinadas
condiciones extremas.
j? Robustez: determinan la capacidad del programa para soportar entradas incorrectas.
j? Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de acceso
al sistema y acceso a datos.
j? 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.
j? ånstalación: se determinan las operaciones de arranque y actualización del software.

 (


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.
V & 

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.

/  c


j? 



 Es similar a la prueba de sistema pero esta involucra la interacción
con otros hardwares, bases de datos y redes.
j?  
 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.
j?    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.
j?  0  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.
j?   &
 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. åncluye
entrevistas con el usuario y programador.
j?  
 
 1 
 
 Determina la eficiencia de los procesos que
instalan y desinstalan las aplicaciones del programa.
j? &
 Es la prueba que evalúa que tan bien se recupera el sistema
luego de bloqueos, fallas del hardware u otros problemas catastróficos.
j?  &


 Evalúa el desempeño del software en diferentes hardwares,
sistemas operativos, redes, etc.
j?   & 
 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.
j? 
 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.
åncluye reunión con analistas y programadores.
j?    
 Determina si el usuario se desenvuelve satisfactoriamente con el
programa.
j?    &
 En esta prueba se comparan los pros y los contras del
programa con los programas creados por la competencia.
j?   
 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.

 
,
 & 

(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:
? Äalta 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.
? Äalta de compatibilidad e interoperabilidad entre herramientas.
!? Äalta de proceso de gestión de la configuración. ågual 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 åSO/åEC 12207 (åSO/åEC 1995), que debería utilizarse
en la ejecución de los procesos principales, y muy especialmente en los de Desarrollo y
Mantenimiento.
"? Äalta de un proceso básico de pruebas y de conocimiento de qué es lo que se debe
probar.
ë? Äalta 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.
w? Äormación inadecuada en el uso de la herramienta.
6? 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.
Õ? Äalta 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.
M? Organización inadecuada del equipo de pruebas.
2?Adquisición de una herramienta inadecuada.

*

 c


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 ANSå åEEE, 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´.
   *

 c


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:

 å    *


 

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 *

 .

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:
j? En España, el estudio del Ministerio de åndustria y Energía sobre las Tecnologías de la
ånformació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).
 
& *

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

Las definiciones de åSO e åEEE 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 Äigura 2:

Ä
 
& *

 

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:
j? No Planificable (NP):
‘? Correctivo Urgente (UC): localizar y eliminar los posibles defectos que
bloquean el programa o los procesos de funcionamiento de la empresa.
j? Planificable (P):
‘? Correctivo No Urgente (NUC): localizar y eliminar los posibles defectos de los
programas que no son bloqueantes.
‘? Perfectivo (PER): añadir al software nuevas funcionalidades solicitadas por los
usuarios.
‘? Adaptativo (A): modificar el software para adaptarlo a cambios en el entorno de
trabajo (hardware o software).
‘? Preventivo (PRE): modificar el software para mejorar sus propiedades (calidad,
mantenibilidad, etc.).

*

  
% 
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.
?

?  en un sistema es una característica del sistema con el potencial de causar 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:
j? Procesamiento, por ejemplo, salidas incorrectas de un programa.
j? Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de
información.
j? Programación, por ejemplo, inconsistencias en el diseño de un programa.
j? Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y
el manual de usuario.
*

 &
% 
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:
j? El sistema operativo (cambio a uno más moderno),
j? La arquitectura física del sistema informático (paso de una arquitectura de red de área
local a ånternet/åntranet),
j? 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:
j? 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.
j? 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).

*

 

% 
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:
j? Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.
j? Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de la ejecución.

*

 %
% 
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:

j? åncluir sentencias que comprueben la validez de los datos de entrada,
j? Reestructurar los programas para mejorar su legibilidad, o
j? åncluir 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.