Lectura 7 - Mantenimiento de Software PDF

Unidad 4: Proceso de Mantenimiento y Mtricas
Referencia bibliogrfica para el alumno sobre la Unidad 4:

Ingeniera del Software Autor: Ian Sommerville Captulo 21
Introduccin al mantenimiento
Una vez entregado el software al cliente es lgico pensar que el uso del mismo y el dinamismo de
las actividades, procesos y negocios provocarn cambios necesarios en el sistema para que sirva
a los nuevos requerimientos que se presenten. Otras veces se presenta la necesidad de corregir
errores encontrados en su funcionamiento, aunque esto no debera suceder si se cumplieron con
las etapas de pruebas del producto antes de entregarlo al cliente o simplemente mejorar su
rendimiento. Tambin se debe tener en cuenta que el avance de la tecnologa requerir adaptarlo
a una nueva plataforma, por ejemplo de un entorno de escritorio a web, cambios de plataforma o
de base de datos.
Es as que el desarrollo de software contina despus de haber sido entregado el sistema
conformando su ciclo de vida. Esta etapa es la que se conoce como Mantenimiento del software.
Se puede decir entonces que Cambios en el Producto es la aplicacin de diferentes estrategias
para aplicar cambios en el software.
Veamos algunas definiciones de Mantenimiento de software:
La modificacin de un producto de software luego de su entrega para corregir fallas,

mejorar performance u otros atributos, o para adaptar el producto a un ambiente
modificado. (IEEE 1219 Standard for SW Maintenance)
El proceso de mantenimiento se ejecuta cuando el producto de software es sometido a

modificaciones al cdigo y documentacin asociada debido a un problema o a la necesidad
de mejora o adaptacin. El objetivo es modificar el software existente preservando su
integridad. Este proceso incluye la migracin y el retiro del producto de software.
(IEEE/EIA 12207.2-1997 Standard for SW life cycle processes implementation
considerations)
Definiciones ISO: traduccin de (ISO/IEC 14764 IEEE Std 14764 2006 SW Engineering SW Life
Cycle Processes -Maintenance)
3,10 Mantenimiento de software, totalidad de las actividades necesarias para proporcionar
los gastos de apoyo eficaz a un sistema de software. Las actividades se realizan durante la
etapa previa a la entrega, as como la posterior fase de entrega.
3,11 Transicin del Software es una secuencia de acciones de desarrollo de software

controlada y coordinada en el que pasa de la organizacin de ejecucin inicial de
desarrollo de software a la organizacin de realizar el mantenimiento de software.
Teniendo en cuenta que los sistemas de software son activos de negocio crtico y que las
organizaciones invierten recursos en los cambios es que requiere de nuestra atencin esta etapa
del proceso que es la que lleva la mayor cantidad de tiempo.
Desde las pequeas empresas de fabricacin de software hasta las grandes empresas invierten la
mayor parte del presupuesto en el mantenimiento de los sistemas existentes, variando el
porcentaje de acuerdo a las distintas visiones y experiencias obtenidas, por ejemplo:
Materia: Construccin de Software

Profesora: Adriana Prez
-1-
Erlikh sugiere que el 90% de los costos del software son costos de evolucin. (Erlikh,
2000).
Algunos datos de la industria indican que:
o Entre el 40% y el 70% del costo del software a lo largo de todo su ciclo de vida es
consumido por actividades de mantenimiento.
o Entre el 60% y el 80% del presupuesto de IT de las organizaciones se gasta en
Mantenimiento y Soporte
Si consideramos el proceso de desarrollo como un modelo en espiral con requerimientos, diseo,

implementacin y pruebas que se realizan continuamente produciendo las versiones que se
entregan al cliente, los cambios pueden concebirse en medio de una iteracin con lo cual pueden
estar dos versiones en produccin al mismo tiempo. Este hecho trae aparejado algunos
inconvenientes, por ejemplo:
Los tiempos reducidos requeridos por los mercados generan ciclos de entregas tempranas
seguidas por actividades de crecimiento de funcionalidad y reduccin de defectos que son
considerados esencialmente mantenimiento. Este mantenimiento se encuentra dentro del
proceso de desarrollo si se aplica un proceso en espiral.
Una vez que los sistemas estn en servicio, no es posible reemplazarlos de una sola vez.
En la prctica, las nuevas tecnologas son introducidas gradualmente en el tiempo
debiendo interactuar con sistemas existentes lo que origina modificaciones en estos
ltimos.
Cuando un nuevo producto es utilizado en un ambiente de produccin, nuevos
requerimientos emergen y se requieren adaptaciones al uso especfico de los clientes en
entornos de operacin que se modifican con el tiempo.
Si bien siempre existi la etapa de mantenimiento del software, no siempre ha significado lo
mismo:
Hace 30 aos el mantenimiento de software se caracterizaba con un iceberg, se esperaba
que slo fuera lo que se vea, pero sabamos que una enorme masa de problemas y
costos yaca bajo la superficie.
A principio de los aos 70 el iceberg era suficientemente grande como para hundir un
portaaviones.
En la actualidad podra hundir a toda la armada
Por qu se necesita tanto mantenimiento?
Gran parte del software del que dependemos en la actualidad tiene entre 15 y 20 aos. An
cuando hayan sido construidos empleando las mejoras tcnicas de anlisis y diseo (sabemos
que para la mayora no fue as) se crearon cuando los datos, el tamao de los programas y el
espacio de almacenamiento eran las principales preocupaciones. Luego se trasladaron a nuevas
plataformas, cambios de mquinas, de sistemas operativos y se mejoraron para satisfacer nuevas
necesidades de los usuarios.
Todos estos cambios se realizaron sin tener en cuenta la arquitectura global.
El resultado de este proceso es:
Arquitecturas muy mal diseadas
Mala codificacin
Lgica inadecuada
Escasa documentacin
Los problemas planteados como resultado de los avances tecnolgicos y de procesos requieren

-2-
establecer estrategias para el cambio las cuales estn centradas en tres puntos importantes:
1- Mantenimiento de Software: los cambios en el software se hacen en respuesta a los
cambios en los requerimientos que satisfagan las nuevas necesidades del cliente, pero la
estructura fundamental de dicho software permanece estable.
2- Evolucin Arquitectnica: Enfoque ms radical para cambiar el software con la
importancia que tiene el diseo y continuar dndole mantenimiento conforme se
implementen cambios ms importantes en la arquitectura del mismo.
3- Reingeniera de Software: Estrategia diferente en el sentido que en principio no se
agrega nueva funcionalidad al sistema, sino que se lo modifica para hacerlo ms fcil de
comprender y cambiar. Implica modificaciones estructurales, no cambios arquitectnicos
mayores.
Dinmicas de la evolucin de los programas
Las dinmicas de evolucin de programa son el objeto de estudio de los procesos de cambio los
de sistemas.
Durante los 70 y 80 Lehman y Belady trabajaron sobre esta rea problemtica, el mantenimiento
del software, dichos estudios continuaron y en los 90, luego de los principales estudios,
propusieron la existencia de un nmero de leyes (las Leyes de Lehman) que son aplicables a
todos los sistemas conforme evolucionen.
Existen observaciones sensibles ms que leyes, hiptesis realmente, que son aplicables a
grandes sistemas desarrollados por grandes organizaciones. Tal vez menos aplicables en otros
casos.
Ley de Lehman
Ley
Cambio continuo
Incremento de Complejidad
Evolucin de Grandes Programas
Estabilidad Organizacional
Conservacin de Familiaridad
Crecimiento continuado
Decremento de la calidad
Realimentacin del sistema
Descripcin
A travs de la vida el sistema, el sistema debe
cambiar sino ser menos til cada da.
Como un programa en evolucin cambia, su
estructura en evolucin tiende a ser cada vez ms
compleja, Deben asignarse recursos extra para
preservar y simplificar esta estructura.
La evolucin del programa es un proceso auto
regulado. Atributos del sistema tales como tamao,
tiempo entre releases (versiones), y el nmero de
reporte de errores, son invariantes, en general para
cada versin.
A travs de la vida de un programa, su ratio de
evolucin es constante e independiente de los
recursos dedicados al desarrollo del sistema.
El cambio incremental en cada release es
aproximadamente constante.
Es necesario el crecimiento continuo para
mantener la satisfaccin del cliente.
Si los sistemas no se adaptan a los cambios en su
entorno de funcionalidad, la calidad de los sistemas
disminuir.
Los sistemas de evolucin incorporan sistemas de
realimentacin para lograr una mejora significativa
del producto.

-3-
Las cinco primeras leyes fueron las que se propusieron inicialmente por Lehman, las restantes
fueron agregadas despus de trabajos posteriores.
La sexta y sptima Ley son similares y dicen que los usuarios estarn cada vez ms
descontentos con el sistema a menos que se lo mantenga y se le agreguen nuevas
funcionalidades.
La ltima Ley refleja el trabajo de investigacin ms reciente, aunque an no est muy claro cmo
implementarlo.
Aplicabilidad de la Ley de Lehman
La aplicabilidad de la Ley de Lehman no ha sido establecida completamente, generalmente es
aplicable a sistemas grandes a medida, desarrollados para organizaciones de gran tamao.
Las Leyes deberan tenerse en cuenta cuando se planifica el proceso de mantenimiento, pero
puede seer que las caractersticas del negocio requieran prescindir de ellas en algn momento,
por ejemplo, cuando las empresas de software deben realizar cambios mayores en el sistema en
una nica entrega, las consecuencias ms notable ser la necesidad de realizar nuevas entregas
dedicadas a la reparacin de los errores producidos por dicha entrega.
Otro ejemplo que nos es familiar y que parece no respetar las Leyes de Lehman, es el de
Microsoft Word, que en su principio era un sencillo procesador de textos que funcionaba en 256 K
de memoria y se transform en un sistema de gran porte con mltiples caractersticas,
necesitando en la actualidad caractersticas tecnolgicas mayores para que funcione. Dicha
evolucin parece no respetar la cuarta y quinta Ley, sin embargo es muy posible que el producto
inicial no haya evolucionado como una secuencia de revisiones a partir de un programa ncleo
comn, sino que ha sido reescrito y reestructurado ms de una vez desde su primera entrega, lo
cual lo convierte en un nuevo producto. Este es el caso de muchas empresas que deciden dar de
baja un producto para reestructurarlo completamente y comenzar un nuevo sistema.
4.1. Prediccin del mantenimiento

Para la gestin de proyectos el factor sorpresa es uno de los que se deben minimizar,
principalmente si este conduce a elevados costos inesperados, por lo que predecir los futuros
cambios que sufrir el sistema y cules son los componentes o mdulos ms difciles de
mantener, es una medida conveniente de adoptar.
La prediccin del mantenimiento est relacionada con la evaluacin de cules son las partes del
sistema que pueden cuasar problemas y tener costos altos de mantenimiento:
La aceptacin del cambio depende de la mantenibilidad de los componentes afectados por
el cambio.
La implementacin de los cambios degrada el sistema y reduce su mantenibilidad
Los costos de mantenimiento dependen del nmero de cambios y los costos del cambio
dependen de la mantenibilidad.
Los trminos mantenimiento y mantenibilidad no significan lo mismo.
Mantenibilidad:
Capacidad del producto de software para ser modificado. Las modificaciones pueden
incluir correcciones, mejoras o adaptacin del software a los cambios en el medio
ambiente, y en los requisitos y especificaciones funcionales. [ISO/IEC 9126-1]

-4-
Es un atributo de calidad del producto de software, se incorpora al mismo en el momento

del desarrollo como respuesta a un requerimiento no funcional.
No hay un modelo universalmente aceptado que permita medir mantenibilidad, sin

embargo ciertos indicadores se utilizan como predictores de la mantenibilidad.
La prediccin del mantenimiento se puede representar de la siguiente forma (Sommerville, cap.

21.2.1, pag. 455):
Qu partes del S.
sern ms costosas
de mantener?
Qu partes del S. son

ms probables de
afectarse por las
peticiones de cambio?
Mantenimiento
Previsto
Cambios
Previstos del
sistema
Costos Previstos
Mantenimiento
Cuntas peticiones
de cambio se
esperan?
Cules sern los

costos de
mantenimiento durante
el periodo de vida del
Sistema?
Cules sern los

costos de
mantenimiento de este
S. en el prximo ao?
Para poder determinar la prediccin del nmero de peticiones de cambios que puede sufrir un
sistema es necesario entender la relacin que existe entre el sistema y su entorno. Para poder
realizar dicha evaluacin debe tener en cuenta los siguientes factores que influyen:
Nmero y complejidad de las interfaces del sistema.

Nmero de requerimientos voltiles del sistema.
Los procesos de negocio que utilizan el sistema.
Teniendo en cuenta que el mantenimiento del sistema implica la modificacin de un programa

luego de haberlo puesto en produccin, requiere de la administracin del mantenimiento con la
planificacin y prediccin del proceso de cambio.
La Administracin del mantenimiento presenta caractersticas como las siguientes:
El mantenimiento tiene una imagen pobre frente al personal de desarrollo y no es visto

como una actividad creativa o desafiante.
Los costos de mantenimiento aumentan conforme el software es mantenido.
La cantidad de software que debe ser mantenido aumenta con el tiempo.
Una Gestin de Configuracin inadecuada a menudo significa que pueden existir
diferentes representaciones del sistema.

-5-
Proceso de evolucin
Dependiendo del tipo de software a mantener, el ciclo de vida utilizado, los procesos de desarrollo
diseadas y utilizados y el nivel del personal implicado en el proceso, es que varan los procesos
de evolucin del mismo. Si bien se puede adoptar un proceso informal es conveniente disponer de
un proceso formalizado en el que se deja documentacin estructurada en cada etapa del proceso.
El mantenimiento es disparado por requerimientos de cambio que vienen desde los clientes,
usuarios y administradores, entre otros. Dichos cambios son incluidos normalmente en una nueva
entrega del sistema.
Los programas a veces necesitan ser reparados sin una iteracin completa del proceso, pero eso
es peligroso si se permite que la documentacin y los programas tengan diferencias entre las
versiones.
Los procesos de evolucin incluyen actividades fundamentales, tales como el anlisis de cambios,
planificacin de entregas, implementacin del sistema y entrega final del sistema al cliente.
Estas etapas se pueden representar de la siguiente forma:
Proceso de
identificacin de
cambios
Propuesta de
cambio
Nuevo sistema
Proceso de
identificacin de
cambios
El proceso de implementacin de los cambios representa una iteracin del proceso de desarrollo
en la que se disean, implementan y prueban las revisiones del sistema. Veamos una
representacin del proceso de evolucin del mismo:
Peticiones de
Cambio
Anlisis de
Impacto
Reparacin
de fallas
Planificacin
de versiones
Adaptacin
Implementacin
de cambios
Liberacin del
Sistema
Perfeccionamiento
del sistema
El proceso de implementacin se puede simplificar en las siguientes etapas:

-6-
Cambios
propuestos
Anlisis de
requerimientos
Actualizacin de
requerimientos
Desarrollo de
software
Caractersticas inherentes al mantenimiento
Entendimiento del sistema presente:

o Qu HACE en realidad el sistema tal como est? (no que debera hacer o que fue
especificado)
o Cmo operan las PARTES RELEVANTES del software? (no necesariamente
todo el SW)
o Dnde deben hacerse los cambios? (que partes no deben tocarse)
Implementacin del cambio:

o Anlisis de impacto (cules son los efectos laterales del cambio?)
o Seleccin de alternativas (anlisis de costo-beneficio a la luz del contexto de
negocio)
o Mnimo incremento de la entropa del cdigo (Cul es la mejor solucin tcnica
encaja en el contexto del Sistema?)
Testing:
o Reproduccin del comportamiento a modificar
o Prueba del cambio implementado (funcional y no funcional por ejemplo, en
condiciones de stress)
o Pruebas de regresin
Qu es entender el sistema?
Comprende los siguientes puntos:
Entender qu debe hacer el sistema (los requerimientos)
Entender qu hace el sistema (el comportamiento)
Entender cmo esta implementado el sistema (el cdigo)
Entender cmo mapean las funcionalidades del sistema al cdigo (la descomposicin
funcional y las dependencias).
Cada etapa del proceso de mantenimiento tiene caractersticas particulares que es necesario
tener en cuenta:
Identificacin del Problema:
Comienza con el requerimiento de cambio.
Identificacin Unvoca del Requerimiento de Modificacin
Ingresar el Requerimiento de Modificacin al Repositorio
Actividades:
Asignar nmero de cambio
Clasificar
Aceptar o rechazar el cambio
Estimacin preliminar de magnitud
Priorizar

-7-
Salida:
Requerimiento de Modificacin
Validado
Determinaciones de Proceso
Mtricas:
Cantidad de Requerimientos de Modificacin enviados
Tiempo insumido en la validacin del problema
Cantidad de Req. de Modificacin duplicados
Anlisis:
Ingreso:
Documentacin del Proyecto/Sistema
Informacin del Repositorio
Requerimiento de Modificacin Validado
Conducir Revisiones Tcnicas
Verificar:
o Estrategia de Prueba
o Si la documentacin est actualizada
o Identificar aspectos de seguridad fsica y lgica
Actividades:
Anlisis de Factibilidad
Anlisis Detallado
Redocumentacin, si es necesario
Salida:
Reporte de Factibilidad
Reporte de Anlisis Detallado
Requerimientos Actualizados
Lista preliminar de modificacin
Plan de Implementacin
Estrategia de Prueba
Mtricas:
Cambios a los Requerimientos
Ratio de error en la documentacin
Esfuerzo por rea de funcin
Ratio de errores generados por prioridad y tipo
Tiempo insumido
Diseo
Ingreso:
Documentacin del
Proyecto/Sistema
Cdigo Fuente
Base de Datos
Salida Fase de Anlisis
Inspecciones y revisiones de software
Verificar Diseo

-8-
Actividades:
Crear casos de prueba
Revisar requerimientos
Revisar Plan de Implementacin
Salida:
Revisado:
o Lista de Modificaciones
o Anlisis Detallado
o Plan de Implementacin
Actualizado:
o Lnea Base de Diseo
o Planes de Prueba
Mtricas:
Complejidad del Software
Cambios en el diseo
Esfuerzo por rea de funcin
Tiempo insumido
Nmero de Aplicaciones
Implementacin
Ingreso:
Documentacin del Proyecto/Sistema
Cdigo Fuente
Resultados de la Fase de Diseo
Inspecciones y revisiones de software
Verificar
o Gestin de configuracin
o Rastreabilidad del Diseo
Actividades:
Codificar
Realizar Pruebas de unidad
Revisar Prueba de Legibilidad
Salida:
Actualizado:
o Software
o Documentos de Diseo
o Documentos de Prueba
o Documentos de Usuario
o Material de Capacitacin
Reporte de revisin de prueba de Legibilidad
Mtricas:
Volumen/Funcionalidad (puntos de funcin o lneas de cdigo fuente)
Prueba del Sistema
Ingreso:

-9-
Documentacin del Software Actualizada

Sistema Actualizado
Control de Gestin Configuracin de:
o Cdigo
o Listados
o Requerimientos de Modificacin
o Documentacin de Prueba
Actividades:
Realizar Pruebas Funcionales
Realizar Pruebas de Interfaz
Realizar Pruebas de Regresin
Revisar Pruebas de Legibilidad
Salida:
Sistema Probado
Reportes de Prueba
Mtricas:
Volumen/Funcionalidad (puntos de funcin o lneas de cdigo fuente)
Prueba de Aceptacin
Ingreso:
Sistema completamente integrado
Prueba de Aceptacin:
o Planes
o Casos
o Procedimientos
Actividades:
Realizar Pruebas de Aceptacin
Realizar Pruebas de Interoperabilidad
Salida:
Nueva lnea base del sistema
Reporte de Prueba de Aceptacin
Reporte de Auditora de Configuracin Fsica
Mtricas:
o Generados
o Corregidos
Entrega
Ingreso:
Sistema Probado y Aceptado
Actividades:

- 10 -
Realizar Auditora de Configuracin Fsica

Instalar
Capacitar
Salida:
Reporte de Auditora de Configuracin Fsica
Documento de Descripcin de la Versin
Mtricas:
Cambios de Documentacin (ej. Manuales de, Capacitacin, Instructivos de
Operacin, Documento de Descripcin de la Versin)
Si bien las etapas del proceso de mantenimiento se presentan como estndar, cada organizacin
evaluar en funcin de la criticidad del requerimiento, la metodologa aplicada, pesada o gil y al
ciclo de vida, entre otras para determinar las actividades y entregables de cada etapa.
Tambin hay que tener en cuenta los factores de complejidad que se pueden presentar, entre los
cuales podemos citar:
Complejidad de Control: puede medirse examinndose las sentencias condicionales en el

programa.
Complejidad de Datos: La complejidad de las estructuras de datos y los componentes de
interfaces.
Tamao de los mdulos
Extensin de los nombres identificadores: Los nombres ms largos implican ms
legibilidad.
Comentarios del Programa: Tal vez ms comentarios significan mantenimiento ms fcil.
Los nuevos requerimientos al sistema en uso pueden implicar cambios a distinto nivel de
implementacin, como pueden ser:
De nueva funcionalidad
A nivel arquitectnico.
A nivel Reingeniera de software
Nuevas funcionalidad:
Estn encuadradas en lo expuesto anteriormente, es decir, se recibe el requerimiento y se evala
la factibilidad tcnica teniendo en cuenta el impacto que provoca en el sistema actual, si es factible
de realizar se pone en marcha el proceso de mantenimiento diseado.
Evolucin arquitectnica:
Una de las caractersticas principales para evaluar el nuevo requerimiento es el tipo de
arquitectura que se requiere y la que se posee en el sistema actual.
Existe la necesidad de convertir sistemas legados desde arquitecturas centralizadas a arquitectura
cliente- servidor.
Adems las organizaciones pueden contar con sistemas heredados por lo que se debe decidir
cules sern las medidas a tomar para obtener los mejores beneficios a su inversin.
Existen cuatro opciones estratgicas:

- 11 -
1- Desechar completamente el sistema: es vlido para sistemas muy viejos con tecnologa
que no se utiliza ms y para aquellos que no contemplan los procesos de negocio, con lo
cual el gasto es mayor si se trata de actualizar.
2- Dejar el sistema sin cambios y continuar con un mantenimiento regular: es viable cuando el
sistema es necesario, el nmero de requerimiento es pequeo y el sistema es estable.
3- Hacer Reingeniera del sistema para mejorar su mantenibilidad: cuando el sistema no
soporta ms cambios y no soporta nuevos componentes.
4- Reemplazar todo o parte del sistema con un nuevo sistema: es posible cuando se cambia
de tecnologa y el sistema actual puede seguir cubriendo las necesidades del cliente. El
cambio se hace en forma paulatina.
Factores que contribuyen al cambio
Costos de Hardware: los servidores son ms baratos que los mainframes.
Expectativas de Interfaz de Usuario: los usuarios esperan interfaces grficas.
Acceso distribuido a sistemas: Los usuarios desean acceder a los sistemas desde lugares
diferentes, distribuidos geogrficamente.
Factores
Importancia en los negocios
Descripcin
Distribuir un sistema heredado depende de su importancia para
los negocios y del tiempo que ser importante y til. Si la
distribucin proporciona soporte ms eficiente a los procesos
de negocio, entonces puede ser una estrategia de evolucin
costeable.
Edad del sistema
Mientras ms antiguo sea el sistema es ms difcil de modificar
su arquitectura debido a que los cambios previos degradaron la
estructura del sistema.
Estructura del Sistema
Mientras ms modular sea el sistema, ms fcil ser cambiar su
estructura. Si la lgica de negocio, la interfaz y la administracin
de datos estn fuertemente entrelazadas, ser difcil separar las
funciones para la migracin.
Polticas de Adquisicin de La distribucin de la aplicacin puede ser necesaria si existe
Hardware
una poltica de la compaa para reemplazar computadoras
mainframes ms costosas por servidores ms baratos.
Estructuras de sistemas heredados:
Idealmente, para la distribucin, debera existir una clara separacin entre la interfaz de usuario,
los servicios del sistema (lgica) y la administracin de los datos. En la prctica, usualmente estn
mezclados en los sistemas legados ms viejos.
Por lo general los sistemas viejos no cuentan con un diseo de clases o componentes, no estn
orientados a objetos ni a servicios, son monousuarios, no contemplan su estructura distribuida con
arquitectura cliente servidor, la lgica de negocio y las sentencias de base de datos estn
embebidas en las distintas interfaces de usuario, por lo que requiere de un esfuerzo importante
poder realizar una modificacin cuando no se cuenta con documentacin ni con el conocimiento
de quienes lo codificaron en su momento.
En este momento de la materia es importante tener claro todos los contenidos de diseo vistos en
los mdulos anteriores de esta materia, es conveniente que realice un repaso de los temas para
entender con profundidad los trminos y significados tratados.

- 12 -
Para la evaluacin de los sistemas heredados se deben ver desde dos perspectivas, una de
negocio y otra tcnica (Warren, 1998). Desde el punto de vista del negocio, determinar si el
negocio realmente necesita el sistema, desde el punto de vista tcnico se evala la calidad de la
aplicacin.
Se identifican cuatro clases de sistemas:
1- Baja calidad y bajo valor de negocio. Alto costo de mantenimiento y baja tasa de beneficio
para el negocio.
2- Baja calidad y alto valor de negocio. Alto costo de mantenimiento, requieren ser
reemplazados por uno nuevo o aplicarles reingeniera.
3- Alta calidad y bajo valor de negocio. Bajo costo de mantenimiento, no conviene
reemplazarlos mientras los cambios no sean caros.
4- Alta calidad y alto valor de negocio. El costo de cambio no es elevado debido a su calidad
y la utilidad para el negocio marcan que el sistema debe continuar.
Existen factores a tener en cuenta para determinar el valor para el negocio y el valor tcnico, pero
fundamentalmente depende de cada empresa.
Reingeniera de software
Para realizar cambios en los sistemas se debe comprender exprograma que tiene que cambiarse
para poder implementar dichos cambios. Cuando los sistemas son heredados y datan de bastante
tiempo son difciles de comprender y de cambiar, por lo general se han optimizado en funcin de
la optimizacin del uso de la memoria y su rendimiento a expensas de la comprensibilidad, la
estructura de la base de datos y los programas pueden ser poco confiables por una serie de
cambios en el tiempo.
El concepto de Re-ingeniera implica lo siguiente:
Re-estructurar o re-escribir parte o todo un sistema heredado sin cambiar su funcionalidad.
Aplicable cuando algunos pero no todos los subsistemas de un sistema grande requieren
mantenimiento frecuente.
La Re-ingeniera implica agregar esfuerzo para hacer el sistema ms fcil de mantener. El
sistema puede ser re-estructurado y redocumentado.
Cundo se debe hacer Reingeniera del producto?
Cuando los cambios en el sistema estn afectando a parte del sistema, entonces hacer reingeniera de esa parte.
Cuando el hardware o software de soporte se vuelve obsoleto
Cuando hay disponibilidad de herramientas para soportar reestructuracin
Hacer Reingeniera tiene dos ventajas que son clave sobre las aproximaciones de la evolucin del
sistema:
1- Riesgo reducido, trabajar sobre software crtico tiene un alto riesgo de cometer errores en
la especificacin o puede haber problemas en el desarrollo retrasando el tiempo de
inclusin de nuevos cambios y proporcionando costos adicionales al negocio.
2- Costo reducido, hacer reingeniera implica menor costo que el mantenimiento del existente.
Realizar reingeniera significa realizar el proceso al revs de la ingeniera de software, o sea, se
parte del sistema existente, se comprende y transforma obteniendo el nuevo sistema.

- 13 -
Tambin es posible plantear la reingeniera de procesos de negocio:

Relacionado con el re-diseo de procesos de negocio para hacerlos ms eficientes y
adaptados a las necesidades.
A menudo est relacionado con la introduccin de nuevos sistemas de computadoras para
soportar procesos revisados.
Pueden forzar la re-ingeniera de software de los sistemas heredados que han sido
diseados para soportar los procesos existentes.
Factores de Costo de la Reingeniera a tener en cuenta:
La calidad de software al que se le va a aplicar Re-ingeniera.
La herramienta de soporte disponible.
La extensin de la conversin de datos que se requiere.
La disponibilidad de personal experto para realizar la Re-ingeniera.
Cuando se plantea la posibilidad de realizar reingeniera de un sistema es porque realmente tiene
ventajas a nivel negocio, el sistema tiene el conocimiento del funcionamiento de los procesos
principales y de soporte de la organizacin, por lo que se mejora la estructura con un diseo
arquitectnico acorde a las nuevas tecnologas y a los avances de la ingeniera de software como
por ejemplo, utilizar modelos de diseo orientado a objetos, a servicios o diseo a base de
componentes que busquen reutilizar cdigo y funcionalidades, entre otros.
4.2. Tipos de mantenimiento

El mantenimiento del software, tal como dijimos anteriormente, implica cambios que llegan como
requerimientos de parte del cliente mientras est en su ciclo de vida de uso.
Estos requerimientos pueden atender distintas causas, durante muchos aos se consider el
mantenimiento como la etapa de correccin de errores, con la incorporacin de los conceptos de
Ingeniera de software y de la importancia de la calidad de software, lo que menos se debera
hacer en el perodo de mantenimiento es corregir fallos del sistema.
Se pueden identificar distintas causas de los requerimientos, entre ellas citamos las siguientes:
Mantenimiento para reparar fallas de software. Por lo general errores relativamente

baratos de corregir, salvo que sean de diseo. Los errores de requerimientos son los ms
costos de reparar.
Mantenimiento para adaptar el software a diferentes entornos operativos. Se requiere
cuando cambian aspectos del entorno como hardware, plataforma del sistema operativo o
el software de base.
Mantenimiento para agregar o modificar funcionalidad del sistema. Necesario cuando
los requerimientos cambian como respuesta a cambios en el ambiente del sistema.
Teniendo en cuenta la clasificacin anterior se pueden identificar claramente cuatro tipos de

mantenimiento:
Mantenimiento adaptativo: modificacin para que el producto funcione en un ambiente

distinto del original.
Mantenimiento correctivo: modificacin reactiva destinada a corregir fallas.
o Mantenimiento de emergencia: mantenimiento correctivo no planificado destinado a
mantener un sistema en condiciones de operacin.

- 14 -
Mantenimiento perfectivo: modificacin destinada a ampliar la funcionalidad o mejorar

atributos de calidad del producto de software.
Mantenimiento preventivo: modificacin destinada a detectar y corregir fallas latentes
antes de que se conviertan en fallas operativas
Esta clasificacin de los tipos de mantenimiento se puede representar de la siguiente forma:
Nuevos Requerimientos
Cambio Adaptativo
Cambio Perfectivo
Defectos
Cambio Correctivo
Cambio Preventivo
Cada uno de estos tipos de mantenimiento representa un esfuerzo y un costo en el proceso de

mantenimiento, que se puede representar en la siguiente relacin:
Adaptativo
18%
Preventivo 5%
Correctivo
17%
Perfectivo
60%
4.2.1 Perfectivo
Este mantenimiento no esta nicamente enfocado a mejorar tcnicamente una solucin, sino que
tambin incluye un proceso continuo de optimizacin a nivel funcional y de procesos. Este
mantenimiento hace foco en:
La optimizacin constante del rendimiento de las aplicaciones mediante anlisis tcnicos.

La adaptacin de las aplicaciones a las nuevas necesidades del cliente en funcin de los
anlisis funcionales.
La deteccin de posibles puntos a mejorar en el diseo y uso de las bases de datos
mediante el anlisis de la base de datos.
Por lo tanto, el principal objetivo del mantenimiento perfectivo es llevar a cabo las tareas y
procesos necesarios para identificar aquellos puntos susceptibles de mejora, aportando las

- 15 -
soluciones ptimas y haciendo efectivos esos cambios en las aplicaciones. Mejorar la calidad del
software para hacerlo ms fcilmente mantenible y reducir el coste e impacto de los cambios de
los procesos de mantenimiento.
Entre otros, los procesos necesarios que se ponen en marcha para la consecucin de estos
objetivos son:
Aseguramiento del rendimiento ptimo de los servicios del cliente.

Anlisis de posibles cambios de las necesidades del cliente, para aportar soluciones
funcionales a sistemas existentes o a nuevos servicios.
Anlisis proactivo de puntos a mejorar o perfeccionar
Las actividades del mantenimiento perfectivo que se encuentran normalmente son:

Reingeniera
Reescritura
Actualizacin de la documentacin
El proceso de mantenimiento perfectivo consta de dos etapas:
1. Identificacin de candidatos (antes de planificar la versin), utilizando la tcnica de Anlisis
de Pareto, tratando de identificar el 20% de los programas que consumen el 80% del
presupuesto y recursos de personal.
2. Correccin de los problemas de calidad identificados para maximizar los beneficios.
Como se puede apreciar, este mantenimiento tiene directa relacin con la calidad del software, se
focaliza en alcanzar la perfeccin del funcionamiento del sistema y que cubra el mximo de
necesidades del cliente.
4.2.2 Adaptativo
Cuando el software ya est en uso, puede ocurrir que se produzca algn cambio en el software o
el hardware del entorno en el que se ejecuta, este tipo de mantenimiento responde a esta
situacin, ya que requiere adaptarse a la nueva situacin planteada.
Estos cambios pueden deberse a:
Cambio en el sistema operativo.
Cambio del tipo de arquitectura en la que se ejecuta (red local a Internet/Intranet).
Entorno de desarrollo del software (nuevos elementos y herramientas como ODBC- Open
Database Connectivity, conectividad abierta a una Base de Datos).
Cualquiera sea el motivo del cambio, estos pueden ir desde un pequeo retoque a nivel de
mdulo hasta la casi reescritura de todo el cdigo.
Se pueden realizar cambios en el entorno software a nivel de datos, como por ejemplo una
migracin de un sistema de ficheros a un sistema basado en bases de datos relacionales o de
procesos tanto de negocio como de dominio de la aplicacin, como por ejemplo, pasar de una
tecnologa a otra, por ejemplo el paso a una plataforma de desarrollo con componentes
distribuidos.

- 16 -
El mantenimiento adaptativo es cada vez ms frecuente debido a la gran velocidad a la que

evoluciona el hardware, a los nuevos sistemas operativos, continuas actualizaciones de los
existentes o cambios en los protocolos de comunicacin, llevan a las modificaciones en el
software, lo que se realiza luego del avance tecnolgico a nivel de plataforma.
Por trmino general, la vida de un sistema software suele ser superior a la frecuencia de estos
cambios, por lo que debe adaptarse casi continuamente. Cuando un software no registra
mantenimiento adaptativo, es posible que quede obsoleto con el tiempo.
Dentro del tipo adaptativo se distingue el Mantenimiento Evolutivo de Infraestructura. En este caso
se trata de asegurar la evolucin de la infraestructura software que da soporte a las aplicaciones,
aportando ideas de mejoras en los distintos entornos. Este mantenimiento se especializa en
aportar soluciones para adaptar los distintos sistemas a cambios en el entorno operativo as como
a nuevas plataformas o versiones de plataformas existentes.
El objetivo que se pretende alcanzar con este servicio es el de mantener actualizada la
infraestructura software de forma que sta vaya incorporando los ltimos estndares y mejoras
que aparezcan en el mercado.
Para lograr este objetivo se establecen los siguientes procesos:
Estudio de nuevas versiones de las distintas plataformas software y soluciones

tecnolgicas empleadas para la implementacin de los servicios del cliente.
Evolucin de la infraestructura software en funcin del anlisis de las necesidades de
negocio o de la estrategia tecnolgica, siempre bajo el paraguas de la Enterprise
Architecture definida.
4.2.3. Preventivo y Correctivo

Preventivo
El concepto de prevencin es tomar los recaudos necesarios para cubrir eventos antes de que
sucedan, o sea no sucedi nunca, por lo tanto antes de que pase, lo prevengo, por ejemplo, nunca
hubo un corte de luz, se compra una UPS (Uninterruptible Power Supply - Sistema de
alimentacin ininterrumpida) para cuando suceda no tenga problemas con la PC.
El mantenimiento Preventivo consiste en anticipar fallos del sistema en cualquiera de los niveles
analizados para ser proactivo en la resolucin de los mismos y, por tanto, mitigarlos y que stos
fallos nunca lleguen a suceder.
Para conseguir este cometido, el servicio de Soporte al Ciclo de Vida del Software, dentro del rea
de Mantenimiento Preventivo, pone en marcha, entre otros, los siguientes mecanismos y
procesos:
Monitorizacin continua mediante la definicin y desarrollo de servicios de agentes o

vigilantes de las aplicaciones existentes, de forma que emitan alertas en caso de que se
produzcan valores fuera de los umbrales establecidos en los parmetros analizados.

- 17 -
Ejecucin peridica de pruebas de los distintos sistemas con el fin de analizar sus
resultados.
Anlisis peridicos de los resultados de las anteriores pruebas y monitorizaciones con el fin
de encontrar factores de riesgo en las tres capas analizadas.
Elaboracin de planes de actuacin y/o contingencia que ayuden a mitigar dichos factores.
Distribucin continua del conocimiento de los distintos sistemas entre todos los miembros
de los distintos equipos de trabajo, aunque no estn asignados a un sistema concreto, de
forma que en cualquier momento los integrantes de los equipos puedan ser trasladados a
otra rea.
Correctivo
Dentro del servicio integral de Soporte al Ciclo de Vida del Software se encuentra el servicio de
Mantenimiento Correctivo, mediante el cual se ofrecen soluciones a las incidencias surgidas en los
distintos sistemas.
Estas incidencias sern analizadas y solventadas atendiendo principalmente a los aspectos que
implica:
Anlisis de la aplicacin: problemas identificados como errores del cdigo de la aplicacin.

Anlisis de la funcionalidad: problemas detectados a raz de funcionalidades incorrectas o
mal implementadas, as como las distintas implicaciones que ese fallo puede tener en otras
aplicaciones incluidas en el servicio.
Anlisis de base de datos: problemas derivados de errores en la base de datos, coherencia
de los datos, entre otros.
El principal objetivo del Mantenimiento Correctivo es subsanar los fallos detectados en el sistema
y asegurar que stos no han producido incoherencias en la integridad en los datos. Estos fallos en
el sistema provocan una falta de conformidad en el cliente, lo que las normas de calidad lo
llaman No conformidad, cuando esto sucede hay dos tipos de acciones a realizar en el tiempo:
1- Accin de correccin, es la accin inmediata para solucionar en primera instancia lo
sucedido, sin analizar la causa que lo provoc, por ejemplo, si se produce un incendio la
accin de correccin es echarle agua ara apagarlo.
2- Accin correctiva, es la accin que se toma luego de haber analizado el fallo y encontrado
la causa, o sea que ataca la causa minimizando la posibilidad que pueda volver a ocurrir.
En el ejemplo del incendio, ser ver las causas que lo provocaron y buscar las acciones
correctivas que solucionen el problema, como llamar al electricista, cambiar los cables,
entre otras.
Para ofrecer el servicio de mantenimiento correctivo o de soporte al cliente se establecen, entre
otros, los siguientes mecanismos y procesos:
Sistema de gestin de las incidencias, para poder controlar en todo momento el estado,
personas implicadas en la resolucin, medidas tomadas para analizarlo y corregirlo, etc.
Verificacin y, en caso necesario, correccin o restauracin de los datos que, por fallos de
conexin, uso incorrecto de la aplicacin o por los efectos laterales de un defecto, se
hayan podido almacenar incorrectamente en la base de datos.

- 18 -
Documentacin del know-how adquirido al producirse el problema de cara a que se

prevenga en futuras ocasiones y se tomen las medidas correctoras que procedan.
Anlisis post-correccin para comprobar que el error detectado no se est produciendo en
otros sistemas, de ser as, corregirlo en el resto de sistemas en los que se detecte.
Mecanismos para mantener la coherencia de los entornos, de tal forma que la resolucin
de un defecto detectado en un entorno de produccin quedar definitivamente resuelto en
todas las versiones y entornos del servicio (pre-produccin, pruebas, desarrollo), mediante,
por ejemplo, la utilizacin de herramientas de Gestin de las Configuraciones que
aseguren la correcta sincronizacin de los distintos entornos.
Se debe tratar de minimizar los fallos en los sistemas con lo cual es importante que se cumplan
con el proceso de desarrollo de software durante la construccin del mismo, sobre todo con los
procesos de V&V y las pruebas de testing en cada etapa posible, tratando de detectar las fallas
antes de que lo haga el cliente.
Se puede representar la relacin entre los mantenimientos de la siguiente forma:
Afecta indirectamente al
Sistema Software
En el proceso de mantenimiento evidentemente se pueden presentar los cuatro tipos, cada uno se
presenta a su manera pero todos tienen relacin con el software y su construccin, cada iteracin
lleva consigo una nueva funcionalidad, una mejora, una correccin o una adaptacin.

- 19 -
Unidad 5: Tcnicas de Mantenimiento

Referencia bibliogrfica para el alumno de los temas tratados en la Unidad 5:
Ingeniera del Software Autor: Ian Sommerville Captulo 26, 27.5 y 28
Como hemos visto en la Unidad 4, el mantenimiento es una fase del proceso de desarrollo de
software en la cual se presentan distintos tipos de mantenimiento de acuerdo a la naturaleza del
requerimiento, recordemos que estos tipos son, mantenimiento preventivo, correctivo, adaptativo y
perfectivo. Hay requerimientos que son ms fciles de implementar que otros, con lo cual se
exigen tcnicas para solucionar la implementacin de estos requerimientos que se presentan con
mayor complejidad.
La Ingeniera del software proporciona soluciones tcnicas que permiten abordar el mantenimiento
de manera que su impacto en costos dentro del ciclo de vida sea menor. Estas soluciones
tcnicas pueden ser de cuatro tipos:
1. Ingeniera inversa: consiste en el anlisis de un sistema para identificar sus componentes
y las relaciones entre ellos, as como para crear representaciones del sistema en otra
forma o en un nivel de abstraccin ms elevado.
2. Reingeniera: representa la necesidad de modificar un producto software, o de ciertos
componentes, usando para el anlisis del sistema existente tcnicas de ingeniera inversa
y, para la etapa de reconstruccin, herramientas de Ingeniera directa, de tal manera que
se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento,
reutilizacin, comprensin o evolucin.
3. Reestructuracin del software: Cambio de representacin de un producto software, pero
dentro del mismo nivel de abstraccin.
4. Transformacin de programas: tcnica formal de transformacin de programas.
El objetivos de estas tcnicas es proporcionar mtodos para reconstruir el software, ya sea
reprogramndolo, redocumentndolo, redisendolo o rehaciendo alguna de las caractersticas
del producto. La diferencia entre las soluciones descritas radica en cul es el origen y cul es el
destino de las mismas (producto inicial y/o producto final).
Grficamente, estas tres soluciones tcnicas se enmarcan en el ciclo de vida de la siguiente
manera:
Relaciones entre los trminos asociados con la Reingeniera.
DISEO
REQUISITO
Ingeniera
directa
Ingeniera
directa
Ingeniera
inversa
Ingeniera
inversa
Recuperacin
diseo
Recuperacin
diseo
Reingeniera
Reestructuracin
IMPLEMENTACIN
Reingeniera
Reestructuracin
Reestructuracin
Redocumentacin
- 20 -
La Ingeniera directa corresponde al desarrollo del software tradicional.

La Ingeniera Inversa es el proceso de anlisis de un sistema para identificar sus componentes e
interrelaciones y crear representaciones del sistema o un nivel ms alto de abstraccin.
La Reingeniera es el examen y la alteracin de un sistema para reconstruirlo de una nueva forma
y la subsiguiente implementacin de esta nueva forma.
La Reestructuracin es la modificacin del software para hacerlo ms fcil de entender y
cambiar.
La Reingeniera hace referencia a un ciclo, esto es, se aplican tcnicas de Ingeniera inversa para
conseguir representaciones de mayor abstraccin del producto y sobre ellas se aplican tcnicas
de Ingeniera directa para redisear o reimplementar el producto.
Cualquiera de estas tcnicas se puede aplicar a lo largo de todas las fases del ciclo de vida o bien
entre algunas de sus fases.
Otras tcnicas de mantenimiento
El mantenimiento del software involucra varias tcnicas especficas. Una tcnica es el
rebanamiento esttico, tcnica del rea de programacin conocida como Mantenimiento de
software, usada para identificar todo el cdigo de programa que puede modificar o afectar alguna
variable.
Una descripcin simplificada de su clculo es el siguiente:
Basado en la definicin original de Weiser, una rebanada esttica de programa (S)
consiste de todas las sentencias en un programa P que pueden afectar el valor de la
variable v en algn punto p.
La rebanada es definida por un criterio de rebanamiento C=(x,V), donde x es una
sentencia en un programa P y V es un subconjunto de variables en P.
Una rebanada esttica incluye todas las sentencias que afectan la variable v para un
conjunto de todos los posibles inputs en el punto de inters.
Las rebanadas estticas son computadas encontrando conjuntos consecutivos de
sentencias indirectamente relevantes, de acuerdo a los datos y dependencias de control.
Generalmente es til en la refabricacin del cdigo del programa y fue especficamente til en
asegurar conformidad para el problema del ao 2000, tambin conocido como efecto 2000, error
del milenio, problema informtico del ao 2000 (PIA2000) o Y2K, es un bug o error de software
causado por la costumbre que haban adoptado los programadores de omitir el ao para el
almacenamiento de fechas (generalmente para economizar memoria), asumiendo que el software
slo funcionara durante los aos cuyos nombres comenzaran con 19. Lo anterior tendra como
consecuencia seria que despus del 31 de diciembre de 1999, sera el 1 de enero de 1900 en vez
de 1 de enero de 2000.
Tambin existen otras tecnologas, como por ejemplo:
La remodularizacin: consiste en cambiar la estructura modular de un sistema de forma

que se obtenga una nueva estructura siguiendo los principios del diseo estructurado.
Anlisis de la facilidad de mantenimiento: normalmente la mayor parte del
mantenimiento se centra relativamente en unos pocos mdulos del sistema.
Visualizacin: el proceso ms antiguo para la comprensin del software.

- 21 -
Anlisis y mediciones: son importantes tecnologas que estudian ciertas propiedades de

los programas.
Ingeniera inversa (Reverse engineering)

Introduction to Reverse Engineering Software (Mike Perry) es un libro on-line
y en construccin permanente que constituye un intento de proporcionar una
introduccin a la Ingeniera inversa del software, tanto bajo Linux como bajo
Windows; trata aproximaciones generales que usted puede consultar en la
siguiente URL: http://www.acm.uiuc.edu/sigmil/RevEng/ (2009)
Se denomina Ingeniera inversa del software a la actividad que se ocupa de descubrir cmo
funciona un programa, funcin o caracterstica de cuyo cdigo fuente no se dispone, hasta el
punto de poder modificar ese cdigo.
La Ingeniera inversa es el proceso de descubrir los principios tecnolgicos de un dispositivo,
objeto o sistema, a travs de razonamiento abductivo de su estructura, funcin y operacin. Se
trata de tomar algo (un dispositivo mecnico o electrnico, un software de computadora, entre
otros) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo
o programa que haga la misma o similar tarea sin copiar la original.
Usos de la Ingeniera inversa
La Ingeniera inversa suele ser empleada por empresas, para analizar si el producto de su
competencia infringe patentes de sus propios productos.
Muchas veces, la Ingeniera inversa es utilizada en el rea militar para investigar (y copiar)
las tecnologas de otras naciones, sin obtener planos ni detalles de su construccin o
desarrollo.
En el software y en el hardware, la Ingeniera inversa, muchas veces es empleada para
desarrollar productos que sean compatibles con otros productos, sin conocer detalles de
desarrollo de stos ltimos. En otras palabras, quien desarrolla los nuevos productos, no
puede acceder a los detalles de fabricacin de los productos de los que intenta ser
compatibles.
La Ingeniera inversa tambin es empleada para comprobar la seguridad de un producto,
generar keygens (key generator, generador de llave, clave, serial, nmero de llave) de
aplicaciones, reparacin de productos, entre otros.
La Ingeniera inversa se ha definido como el proceso de construir especificaciones de un mayor

nivel de abstraccin partiendo del cdigo fuente de un sistema software o cualquier otro producto
(se puede utilizar como punto de partida cualquier otro elemento de diseo, etc.).
Estas especificaciones pueden volver ser utilizadas para construir una nueva implementacin del
sistema utilizando, por ejemplo, tcnicas de Ingeniera directa.
Beneficios de Ingeniera Inversa
La aplicacin de Ingeniera inversa nunca cambia la funcionalidad del software sino que permite
obtener productos que indican cmo se ha construido el mismo. Se realiza permite obtener los
siguientes beneficios:

- 22 -
Reducir la complejidad del sistema: al intentar comprender el software se facilita su

mantenimiento y la complejidad existente disminuye.
Generar diferentes alternativas: del punto de partida del proceso, principalmente cdigo
fuente, se generan representaciones grficas lo que facilita su comprensin.
Recuperar y/o actualizar la informacin perdida (cambios que no se documentaron en su
momento): en la evolucin del sistema se realizan cambios que no se suele actualizar en
las representaciones de nivel de abstraccin ms alto, para lo cual se utiliza la
recuperacin de diseo.
Detectar efectos laterales: los cambios que se puedan realizar en un sistema puede
conducirnos a que surjan efectos no deseados, esta serie de anomalas puede ser
detectados por la ingeniera inversa.
Facilitar la reutilizacin: por medio de la Ingeniera inversa se pueden detectar
componentes de posible reutilizacin de sistemas existentes, pudiendo aumentar la
productividad, reducir los costes y los riesgos de mantenimiento.
La finalidad de la Ingeniera inversa es la de desentraar los misterios y secretos de los sistemas

en uso a partir del cdigo. Para ello, se emplean una serie de herramientas que extraen
informacin de los datos, procedimientos y arquitectura del sistema existente.
Tipos de Ingeniera Inversa

La Ingeniera inversa puede ser de varios tipos:
Ingeniera inversa de datos: Se aplica sobre algn cdigo de bases datos (aplicacin,
cdigo SQL, etc.) para obtener los modelos relacionales o sobre el modelo relacional para
obtener el diagrama entidad-relacin
Ingeniera inversa de lgica o de proceso: Cuando la Ingeniera inversa se aplica sobre
cdigo de un programa para averiguar su lgica o sobre cualquier documento de diseo
para obtener documentos de anlisis o de requisitos.
Ingeniera inversa de interfaces de usuario: Se aplica con objeto de mantener la lgica
interna del programa para obtener los modelos y especificaciones que sirvieron de base
para la construccin de la misma, con objeto de tomarlas como punto de partida en
procesos de Ingeniera directa que permitan modificar dicha interfaz.
Herramientas para la Ingeniera Inversa

Los Depuradores
Un depurador es un programa que se utiliza para controlar otros programas. Permite avanzar paso
a paso por el cdigo, rastrear fallos, establecer puntos de control y observar las variables y el
estado de la memoria en un momento dado del programa que se est depurando. Los
depuradores son muy valiosos a la hora de determinar el flujo lgico del programa.
Un punto de ruptura (breakpoint) es una instruccin al depurador que permite parar la ejecucin
del programa cuando cierta condicin se cumpla. Por ejemplo, cuando un programa accede a
cierta variable, o llama a cierta funcin de la API, el depurador puede parar la ejecucin del
programa.

- 23 -
Algunos depuradores de Windows son:
OllyDbg es un potente depurador con un motor de ensamblado y desensamblado

integrado. Tiene numerosas otras caractersticas incluyendo un precio de 0 $. Muy til para
parcheado, desensamblado y depuracin.
WinDBG es una pieza de software gratuita de Microsoft que puede ser usada para
depuracin local en modo usuario, o incluso depuracin remota en modo kernel.
Las Herramientas de Inyeccin de Fallos

Las herramientas que pueden proporcionar entradas malformadas con formato inadecuado a
procesos del software objetivo para provocar errores son una clase de herramientas de insercin
de fallos. Los errores del programa pueden ser analizados para determinar si los errores existen
en el software objetivo. Algunos fallos tienen implicaciones en la seguridad, como los fallos que
permiten un acceso directo del asaltante al ordenador principal o red. Hay herramientas de
inyeccin de fallos basados en el anfitrin que funcionan como depuradores y pueden alterar las
condiciones del programa para observar los resultados y tambin estn los inyectores basados en
redes que manipulan el trfico de la red para determinar el efecto en el aparato receptor.
Los Desensambladores
Se trata de una herramienta que convierte cdigo mquina en lenguaje ensamblador. El lenguaje
ensamblador es una forma legible para los humanos del cdigo mquina. Los desensambladotes
revelan que instrucciones mquinas son usadas en el cdigo. El cdigo mquina normalmente es
especfico para una arquitectura dada del hardware. De forma que los desensambladotes son
escritor expresamente para la arquitectura del hardware del software a desensamblar.
Algunos ejemplos de desensambladores son:
IDA Pro es un desensamblador profesional extremadamente potente. La parte mala es

su elevado precio.
PE Explorer es un desensamblador que se centra en facilidad de uso, claridad y
navegacin. No es tan completo como IDA Pro, pero tiene un precio ms bajo.
IDA Pro Freeware 4.1 se comporta casi como IDA Pro, pero slo desensambla cdigo
para procesadores Intel x86 y solo funciona en Windows.
Bastard Disassembler es un potente y programable desensamblador para Linux y
FreeBSD.
Ciasdis esta herramienta basada en Forth permite construir conocimiento sobre un
cuerpo de cdigo de manera interactiva e incremental. Es nico en que todo el cdigo
desensamblado puede ser re-ensamblado exactamente al mismo cdigo.
Los compiladores Inversos o Decompiladores

Un decompilador es una herramienta que transforma cdigo en ensamblador o cdigo mquina en
cdigo fuente en lenguaje de alto nivel. Tambin existen decompiladores que transforman
lenguaje intermedio en cdigo fuente en lenguaje de alto nivel. Estas herramientas son
sumamente tiles para determinar la lgica a nivel superior como bucles o declaraciones if-then de
los programas que son decompilados. Los decompiladores son parecidos a los desensambladotes
pero llevan el proceso un importante paso ms all.

- 24 -
Algunos decompiladores pueden ser:
DCC Decompiler es una excelente perspectiva terica a la descompilacin, pero el

descompilador slo soporta programas MSDOS.
Boomerang Decompiler Project es un intento de construir un potente descompilador
para varias mquinas y lenguajes.
Reverse Engineering Compiler (REC) es un potente descompilador que descompila
cdigo ensamblador a una representacin del cdigo semejante a C. El cdigo est a
medio camino entre ensamblador y C, pero es mucho ms legible que el ensamblador
puro.
Las Herramientas CASE (Computer Aided Systems Engineering Computadoras asistidas

por Ingeniera de software)
Las herramientas de Ingeniera de sistemas asistida por ordenador (Computer Aided Systems
Engineering CASE) aplican la tecnologa informtica a las actividades, las tcnicas y las
metodologas propias de desarrollo de sistemas para automatizar o apoyar una o ms fases del
ciclo de vida del desarrollo de sistemas. En el caso de la ingeniera inversa generalmente este tipo
de herramientas suelen englobar una o ms de las anteriores junto con otras que mejoran el
rendimiento y la eficiencia.
Conclusiones de la Ingeniera inversa
El anlisis del software para comprender su diseo y especificacin.
Puede ser parte de un proceso de reingeniera pero puede usarse para reespecificar un
sistema para una nueva instalacin.
Construir una base de datos de programas y generar informacin desde all.
Pueden usarse en el proceso herramientas de comprensin de programas (browsers,
generadores de referencias cruzadas, entre otras).
Proceso de Ingeniera inversa
Anlisis
automatiza
do
Sistema a ser
reingenierizado
Diagramas de
estructuras de
programas
Almacn del
sistema de
informacin
Generacin de
documentacin
Diagramas de
estructuras de
datos
Anotacin
manual
Matrices de
rastreabilidad
La Ingeniera reversa a menudo precede a la re-ingeniera aunque a veces vale la pena por s
sola.
Puede hacerse Ingeniera reversa del diseo y la especificacin de un sistema como
entrada de un proceso de reemplazo de un sistema.
Puede hacerse Ingeniera reversa del diseo y la especificacin de un sistema como
soporte de un programa de mantenimiento.

- 25 -
Reestructuracin de software
El mantenimiento del software tiende a corromper la estructura de un programa. Lo vuelve cada
vez ms difcil de entender. Cuando esto sucede el programa puede ser reestructurado
automticamente para remover bifurcaciones incondicionales y las condiciones pueden
simplificarse para hacerlas ms comprensibles
La reestructuracin del software modifica el cdigo fuente y/o los datos en un intento de adecuarlo
a futuros cambios. Tiende a centrarse en los detalles de diseo de mdulos individuales y en
estructuras de datos locales definidas dentro de los mdulos.
La reestructuracin del cdigo trae aparejado beneficios y problemas que debe conocer para
actuar debidamente.
Los beneficios de de la reestructuracin son:
Programas de mayor calidad con mejor documentacin, menos complejidad y ajustados a

las prcticas y estndares de la Ingeniera del software moderno.
Reduce la frustracin entre ingenieros del software que deban trabajar con el programa,
mejorando por tanto la productividad y haciendo ms sencillo el aprendizaje.
Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.
Hace que el software se mas sencillo de comprobar y depurar.
La reestructuracin se produce cuando la arquitectura bsica de la aplicacin es slida, an

cuando sus interioridades tcnicas necesiten un retoque. Comienza cuando existen partes
considerables del software que son tiles todava y solamente existe un subconjunto de todos los
mdulos y datos que requieren una extensa modificacin.
Los problemas de la reestructuracin son:
Prdida de comentarios.
Prdida de documentacin.
Demandas computacionales pesadas.
La reestructuracin no ayuda con la modularizacin pobre, donde componentes
relacionados estn dispersos a travs del cdigo.
La incomprensibilidad de los programas conducidos por datos no puede mejorarse con la
reestructuracin
Los tipos de reestructuracin, bsicamente son 2: del cdigo y de datos.

Reestructuracin del cdigo
La reestructuracin del cdigo se lleva a cabo para conseguir un diseo que produzca la misma
funcin pero con mayor calidad que el programa original.
El objetivo es tomar el cdigo de forma de "plato de espaguetis" y derivar un diseo de
procedimientos que se ajuste a la filosofa de la programacin estructurada.
Lgica espaguetis

- 26 -
Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch)

if Switch = off goto off
if Switch = on goto on
goto Cntrld
off: if Heating-status = on goto Sw-off
goto loop
on: if Heating-status = off goto Sw-on
goto loop
Cntrld: if Time = Time-on goto on
if Time = Time-off goto off
if Time < Time-on goto Start
if Time > Time-off goto Start
if Temp > Setting then goto off
if Temp < Setting then goto on
Sw-off: Heating-status := off
goto Switch
Sw-on: Heating-status := on
Switch: Switch-heating
loop: goto Start
Simplificacin de Condicin
Condicin Compleja
if not (A > B and (C < D or not ( E > F) ) )...
Condicin Simplificada
if (A <= B and (C>= D or E > F)...
Reestructuracin de datos
El anlisis del cdigo fuente es la primera actividad, en primer lugar se evaluarn todas las
sentencias del lenguaje de programacin con definiciones de datos, descripciones de archivos, de
Entrada / Salida y descripciones de interfaz. Esta actividad a veces se denomina anlisis de datos.
Una vez finalizado el anlisis de datos, comienza el rediseo de datos. Se emplea un paso de
estandarizacin de rediseo de datos que clarifique las definiciones de datos para lograr una
consistencia entre nombres de objetos de datos, o entre formatos de registros fsicos o formato de
archivos existentes. Otra forma de rediseo, denominada racionalizacin de nombres de datos,
garantiza que todas las convenciones de denominacin de datos se ajusten a los estndares
locales y/o internacionales y que se eliminen las irregularidades a medida que los datos fluyen por
el sistema.
Cuando la reestructuracin sobrepasa la estandarizacin y la racionalizacin, se efectan
modificaciones fsicas en las estructuras de datos ya existentes con objeto de hacer que el diseo
de datos sea ms efectivo. Esto puede significar una conversin de un formato de archivo a otro,
o, en algunos casos, una conversin de un tipo de base de datos a otra.

- 27 -
Muchos sistemas heredados usan tablas compartidas y datos globales para ahorrar espacio en
memoria. Esto trae problemas debido a que los cambios tienen un impacto muy grande en el
sistema.
Los datos globales pueden ser convertidos a objetos o ADT (Abstract data type, tipos de
datos abstractos)
Analizar reas de datos comunes para identificar abstracciones lgicas.
Crear un objeto o ADT para esas abstracciones
Use un browser para encontrar todas las referencias a los datos y reemplcelas con la
referencia a la abstraccin del dato.
Modularizacin de Programas
Dentro de la reestructuracin de un sistema, el proceso de reorganizacin de los programas de
manera tal que las partes de programas relacionados sean puestos juntos en un mismo mdulo es
la actividad principal para la modularizacin.
Usualmente, es ejecutado un proceso manual por un programa de inspeccin y reorganizacin
para lograr la modularizacin, otras veces es manual de acuerdo al conocimiento de los
programadores o diseadores del sistema.
Tipos de Mdulos
Los mdulos se pueden clasificar teniendo en cuenta caractersticas que posean, en:
Abstracciones de Datos
o Tipos de datos abstractos donde las estructuras de datos y operaciones asociadas
son agrupados.
Mdulos de Hardware
o Todas las funciones requeridas para relacionarse con una unidad de hardware.
Mdulos Funcionales
o Mdulos que contienen funciones para ejecutar tareas muy relacionadas.
Mdulos de Soporte de Proceso
o Mdulos cuyas funciones dan soporte a procesos de negocio o fragmentos de
proceso.
Proceso de Reestructuracin
Programa
reestructurado
Programa a ser
reestructurado
Analizador y
constructor
grfico
Generador de
programa
Reestructuracin
Grfica

- 28 -
Reingeniera de software
En la Unidad 4 de la materia vimos el concepto de Reingeniera de software, por lo cual ahora slo
profundizaremos en algunos conceptos.
Recordemos que la Reingeniera de software significa reescribir y/o reestructurar el sistema, por lo
que es esfuerzo es mayor cuanto ms grande es el sistema.
Idealmente, las aplicaciones se deberan reconstruir utilizando un motor de Reingeniera
automatizado, en el cual se inserte el programa viejo, que lo analice, reestructure y despus
regenere la forma de exhibir los mejores aspectos de la calidad del software.
Los fabricantes de CASE han presentado herramientas que proporcionan un subconjunto limitado
de estas capacidades y que se enfrentan con dominios de aplicaciones especficos, siendo estas
herramientas de Reingeniera cada vez ms sofisticadas.
La Ingeniera directa no slo recupera la informacin de diseo a partir del software existente,
tambin utiliza esta informacin para alterar o reconstruir el sistema existente con la finalidad de
mejorar su calidad global. En la mayora de los casos el software sometido a reingeniera vuelve a
implementar la funcin del sistema existente y tambin aade nuevas funciones o mejoras.
Entre los beneficios de aplicar reingeniera a un producto existente se puede destacar:
Reducir los riegos evolutivos de una organizacin.

Ayudar a las organizaciones a recuperar sus inversiones en software.
Software ms fcilmente modificable
Ampla las capacidades de las herramientas CASE
Es un catalizador para la automatizacin del mantenimiento del software
Acta como catalizador para la aplicacin de tcnicas de inteligencia artificial para resolver
problemas de reingeniera
Reducir Costos. El costo de la re-ingeniera es significativamente menor que el costo del
desarrollo de nuevo software.
El proceso de Reingeniera es el siguiente:
Programa
original
Documentacin
del Programa
Programa
modularizado
Datos
originales
Ingeniera
reversa
Traduccin
de cdigo
fuente
Modularizacin
del programa
Datos
reingeniarizados
Mejora de la
estructura
del programa
Programa
estructurado
Datos
reingeniarizados

- 29 -
5.1. Mtricas
En el ciclo de vida del sistema es necesario realizar revisiones de los procesos asegurando la
mejora continua, estas revisiones son costosas, consumen tiempo y retrasan la fecha de entrega
del software. Para mejorar es necesario medir, lo cual consume tiempo, lo ideal es que esta tarea
se realice de forma automtica por sistema, es necesario para ello que se cuente con un sistema
de seguimiento de las actividades de los procesos.
Estas mtricas permiten comprobar que el software tiene el umbral de calidad requerido,
destacando las partes en las cuales no se a ha alcanzado dicho umbral para ser revisadas.
Medir el software implica obtener un valor numrico desde algn atributo o del proceso del
software, por ejemplo una herramienta para medir la cantidad de fallos que posee un desarrollo de
software en un tiempo determinado, una vez solucionados se vuelve a repetir el proceso para ver
si se descubren nuevos errores en la misma cantidad de tiempo. La informacin obtenida es til
para el proceso de validacin del software.
Las mediciones del software pueden utilizarse para:
1- Hacer predicciones generales del sistema, como por ejemplo la cantidad de fallos.
2- Identificar componentes anmalos, los que se salen de lo normal, por ejemplo los de
complejidad ms alta suponen mayor cantidad de errores posibles de aparecer, con lo cual
se debe centrar la atencin en ellos en el proceso de revisin.
Una mtrica o indicador es entonces, cualquier tipo de medida relacionada con un sistema,
proceso o documentacin de software.
Algunos ejemplos de indicadores del proceso de software son:
Cantidad de fallos del software
Desviacin de la estimacin del tiempo para las actividades del proceso, su frmula es
Tiempo real / (tiempo estimado *100).
Cantidad de ciclos de testing para aun mismo componente desarrollado.
Cantidad de requerimientos que no funcionan correctamente en el cliente con respecto a la
cantidad total de requerimientos entregados, lo que nos indica el porcentaje de No
Conformidades y la calidad del trabajo de Testing.
Las mtricas son de control o de prediccin, ambas influyen en la toma de decisiones de gestin.
Mtricas de control, suelen estar asociadas con los procesos.

Mtricas de prediccin, estn asociadas a los productos, por ejemplo la complejidad
ciclomtica de un mdulo, la longitud media de los identificadores de un programa y el
nmero de atributos y operaciones asociadas con los objetos de un diseo.
Ejemplo de mtricas de ambos tipos es el esfuerzo y tiempo promedio requeridos para reparar los
defectos encontrados.
Relacin entre los atributos del software y la mtrica utilizada

- 30 -
Mantenibilidad
Nmero de parmetros del

procedimiento
Fiabilidad
Complejidad ciclomtica
Portabilidad
Usabilidad
Tamao del programa en lneas

de cdigo
Nmero de mensajes de error
Extensin del manual de usuario
El proceso de medicin
Los pasos claves en este proceso son:
1- Seleccionar las medidas a realizar, formulando las preguntas que la medicin intenta
responder o los problemas detectados y definir la medicin requerida para resolver cada
pregunta.
2- Seleccionar los componentes a evaluar, no es conveniente estimar todos los componentes
de un sistema de software, hay que elegir un conjunto representativo de componentes y
los crticos.
3- Medir las caractersticas de los componentes, las actividades del proceso como anlisis,
diseo, desarrollo, testing poseen sus propias caractersticas que proporcionan mtricas
particulares, lo cual se puede procesar con una herramienta de recogida de datos.
4- Identificar las mediciones anmalas, cuando se tienen los resultados de las mediciones de
los componentes, se comparan entre s y con los resultados anteriores registradas y
almacenadas, Los valores obtenidos deben estar dentro de un rango establecido, para lo
cual se determina un mnimo, un mximo y un ideal, si los valores estn fuera de las cotas
tenemos retroalimentacin negativa, con lo cual hay que ver qu sucede.
5- Analizar los componentes anmalos, cuando se identifican los componentes con valores
fuera de lo establecido para las mtricas particulares, se examinan estos componentes
para decidir si los valores de las mtricas obtenidas indican que la calidad del componente
est en peligro.
Los datos obtenidos de las mediciones realizadas deben registrarse y conservarse en registros
histricos que permitan realizar anlisis, estadstica y predicciones. Estos registros son un
patrimonio organizacional, ya que ayuda a la toma de decisiones. Cuando se tiene una base de
datos lo suficientemente grande se pueden realizar comparaciones entre proyectos, refinando las
mtricas si es necesario.
Mtricas del producto

- 31 -
Las mtricas del producto se refieren a las caractersticas propias del software, pero lo que
normalmente se mide no ayuda de determinar su calidad, como la comprensin y la
mantenibilidad.
Esta relacin entre las mediciones y los atributos del software dependen del proceso, la tecnologa
y el tipo de sistema a desarrollar, por ejemplo un proceso de nueva funcionalidad no es igual a un
proceso para desarrollo de un proyecto nuevo, ya que la nueva funcionalidad es agregar algo
nuevo a algo existente y tiene un estudio de impacto y de factibilidad, por lo que tendr sus
propias mtricas en estas etapas.
Si bien todos los registros de mediciones son importantes y deben almacenarse en base de datos
permitiendo contar con histricos, no todos lo que se mide es vlido, hay que saber elegir el
indicador necesario, para ello hay que tener en cuenta lo que el valor obtenido significa, por
ejemplo cantidad de veces que se rechaz el cdigo por fallos, indica que el producto software no
es de calidad y que los programadores no estn haciendo bien su trabajo.
Las mtricas del producto se dividen en dos clases:
1- Las mtricas dinmicas, valores recogidos de las mediciones realizadas en un programa
en ejecucin.
2- Las mtricas estticas, valores recogidos de las mediciones realizadas en las
representaciones del sistema como el diseo, el programa o la documentacin.
Las mtricas estticas ayudan a valorar la eficiencia y la fiabilidad de un programa, la complejidad,
la comprensin y la mantenibilidad de un sistema de software.
Las mtricas dinmicas se relacionan con los atributos de calidad de software, como por ejemplo,
el tiempo que demora la ejecucin de una funcionalidad, performance, tiempo de respuesta,
eficiencia; otro indicador est dado por la cantidad de cadas del sistema que se han producido lo
cual se relaciona con la fiabilidad del sistema.
Una mtrica muy usada en los aos anteriores es la longitud del cdigo, es difcil inferir si es
correcto o no un cdigo que tenga X cantidad de lneas de cdigo, ya que depende mucho de la
herramienta de programacin, del paradigma de programacin y del lenguaje, por lo que hoy slo
se pide que el componente tenga una funcionalidad especfica que permita ser reutilizado con
reglas de buena programacin y patrones que garanticen la calidad del componente.
Anlisis de las mediciones
Tener los valores cuantitativos de las mediciones del software y de los proyectos de software
requiere comprender su significado, ya que es fcil malinterpretar los datos y realizar inferencias
incorrectas. Para que esto no suceda se deben analizar cuidadosamente dichos datos para
comprender realmente lo que significan.
Es comn utilizar como indicadores la cantidad de ocurrencias de algo especfico, por ejemplo la
cantidad de requerimiento de cambios que se reciben. Dicha mtrica no significa nada por s sola,
hay que ubicarla en un contexto que nos indique por qu se produce la peticin por parte del
cliente, es posible que sea porque el sistema no responde como lo esperaban y no solamente
porque se establecen cantidad de cambios en el tiempo.
El anlisis requiere encontrar las causas y ver a qu o a quien ayuda la mtrica.

- 32 -
Suponga que en la fase de mantenimiento del software se cuenta la cantidad de no conformidades

en un lapso de tiempo con respecto a la cantidad de requerimientos de mantenimiento que ha
realizado el cliente por distintos motivos, esta mtrica slo nos da un valor que cuenta pero no
indica ni ayuda, ya que no sabemos por qu se produjeron estas desconformidades.
Los indicadores de proceso y de producto requieren que se estudien y tengan en cuenta varios
factores, como son:
Qu se quiere medir
Para qu se quiere medir.
A quin ayuda dicha medicin.
Qu mejora puede producir.
Cules son las cotas mnima y mxima del indicador, determinado los valores de
desviacin.
Cundo ser una retroalimentacin positiva que indica que se puede seguir como hasta
ahora.
Cundo ser una retroalimentacin negativa que indica que se deben realizar cambios.
No se puede mejorar lo que no se mide ni lo que se mide mal, por lo que elegir las mtricas y
realizar su anlisis son tareas fundamentales para la mejora continua.
Toda mtrica que se elija tiene que ver con los objetivos planteados como deseables de alcanzar.
Por ejemplo, si una organizacin pone una mtrica al proceso de venta, tiene que tener en cuenta
su objetivo, si ste es aumentarlas en un 20% en un ao, la cota mnima ser 0% y la mxima
ser 20%. Si los registros de la medicin indican que las ventas cayeron, estaremos por debajo de
la cota mnima, retroalimentacin negativa, requiere del anlisis de las causas antes de tomar
decisiones sobre modificaciones en el proceso de ventas o en el indicador. Por el contrario si las
ventas superaron el 20%, si bien est fuera del rango establecido y hay una desviacin, dice que
superaron las expectativas, requiere de su anlisis y se ver si es necesario realizar algn cambio.
En este caso el valor es mejor mientras es ms alto y se acerca ms a la cota superior.
En el caso que la mtrica est en la etapa de testing del software, el ideal es que se realice 1 ciclo
como mnimo y se puede establecer un valor mximo que depender de la poltica de la empresa
y objetivos del rea de desarrollo. Si el valor establecido como mximo 3 ciclos para el mismo
componente, el valor del indicador ser mejor mientras ms se acerque a la cota inferior y se
considera desviacin, retroalimentacin negativa cuando supere la cota superior. Este indicador
est en la etapa de testing pero ayuda al programador a mejorar su trabajo y a entregar cdigo de
mejor calidad. Por el contrario, si el indicador registra que todos los componentes pasan con un
ciclo de testing, no indica que los programadores estn haciendo excelentemente su cdigo, sino
que el tester no est realizando bien su trabajo, ya que es responsable de encontrar fallos y no lo
est haciendo. En este caso el indicador ayuda al tester a mejor su trabajo.
El propsito de la actividad de Medicin y Anlisis es establecer la gestin cuantitativa del
proyecto con el fin de alcanzar los objetivos definidos en el plan de aseguramiento de calidad.
Las tareas a realizar son:
Planificar la gestin cuantitativa: establecer las mtricas relevantes de producto y proceso,
sus definiciones operacionales y mecanismos de coleccin y almacenamiento; definir que
mtricas sern gestionadas bajo control estadstico.
Ejecutar la gestin cuantitativa: colectar las mtricas definidas, aplicar mtodos

estadsticos para entender la variacin y sus causas, identificar y ejecutar las acciones
correctivas resultantes.

- 33 -
Mantener registros de las mtricas y los resultados de los correspondientes anlisis.
La coleccin de mtricas resulta vital para poder realizar estimaciones y establecer expectativas
realistas con base histrica.
Mtricas de mantenibilidad
Condiciones de
mantenibilidad
Compatibilidad
Integridad
Simplicidad
Usabilidad
Extensibilidad
Estabilidad
Familiaridad
Indicador de
mantenibilidad en el
desarrollo
Se emplean mtodos
y herramientas de
desarrollo vigentes
Indicador de
mantenibilidad en la
administracin
Se utiliza tecnologa
estndar para la
plataforma
El software adhiere a
estndares de calidad
y contiene pocos
defectos
El software es
estructurado y
modularizado
Los reportes de
problemas operativos
son infrecuentes
Los pedidos de nueva

funcionalidad por
parte de los usuarios
son bien
fundamentados
Los nuevos mdulos
requieren pocos
cambios de los
mdulos existentes
El software puede ser
modificado sin
introducir nuevos
defectos
Los encargados de
mantener el software
han estado trabajando
en el sistema desde
los comienzos
El procesamiento
requiere minima
intervencin del
administrador
Los pedidos de
asistencia de los
usuarios para la
operacin del sistema
son mnimos
La plataforma soporta
ampliacin de la
capacidad de
procesamiento
Las intervenciones del
administrador no
provocan cadas del
sistema
Los administradores
tienen larga
experiencia con el
sistema
Indicador de
mantenibilidad en el
uso
Se utilizan interfaces
de usuario
ampliamente
aceptadas
Los datos ingresados
por los usuarios son
de alta calidad
Las habilidades y
procedimientos para
uso rutinario son
sencillos de aprender
Los usuarios emplean
pocos "workarounds"
para cumplir sus
tareas
La funcionalidad del
sistema puede
aprovecharse para
nuevos usos
Los picos de uso no
generan fallas en el
sistema
Los usuarios tienen
entrenamiento
especfico y
experiencia con el
sistema
Mtricas de Complejidad
La prediccin de la mantenibilidad puede ser evaluada por la complejidad de los componentes del
sistema. Estudios realizados han demostrado que el esfuerzo de mantenimiento es caro en
relacin a un nmero pequeo de componentes.
La complejidad depende varios factores:
Complejidad de Control: puede medirse examinndose las sentencias condicionales en el
programa.

- 34 -
Complejidad de Datos: La complejidad de las estructuras de datos y los componentes de

interfaces.
Tamao de los mdulos
Extensin de los nombres identificadores: Los nombres ms largos implican ms
legibilidad.
Comentarios del Programa: Tal vez ms comentarios significan mantenimiento ms fcil.
Despus de que el sistema se haya puesto en funcionamiento, se pueden usar los valores para
ayudar a predecir la mantenibilidad.
Veamos algunas de estas mtricas propuestas:
1- El nmero de peticiones de mantenimiento correctivo, si el nmero de informes de fallos de
ejecucin se ha incrementado, puede estar indicando que se han producido ms errores
en el programa de los que se ha logrado corregir durante el proceso de mantenimiento, lo
cual indica que el nivel de mantenibilidad est decreciendo.
2- El tiempo medio requerido para el anlisis de impacto, representa la cantidad de
componentes del programa que se ven afectados por los requerimientos de cambio. Si el
tiempo se incrementa implica que hay ms componentes afectados y que est
disminuyendo la mantenibilidad.
3- Tiempo medio empleado en implantar un cambio, refleja el tiempo que se emplea en
modificar cdigo de los componentes y su documentacin. Si el tiempo aumenta puede
indicar que cada vez es ms complejo realizar un cambio, por lo que la mantenibilidad
disminuye.
4- Cantidad de requerimientos de cambio pendientes, refleja que faltan recursos para resolver
los cambios o la mantenibilidad est disminuyendo.
Conclusin:
Las mtricas son necesarias para plantear la mejora continua de los procesos y los productos;
para lograrlo se deben plantear correctamente dichas mtricas y realizar un correcto anlisis de
las mismas para determinar las decisiones a tomar, ya sean de continuar igual porque los
indicadores estn dentro de los parmetros planteados o realizar cambios en relacin con los
indicadores que establecen desviaciones.
5.2. Costos y beneficios

La mejora de procesos significa entender los procesos existentes y cambiarlos para mejorar la
calidad del producto y/o reducir costos y tiempo de desarrollo.
La optimizacin de los procesos y la mejora de la calidad del producto, reduciendo el nmero de
defectos en el software que se entrega, implica que lo que sigue es tratar la reduccin de costos y
tiempo de desarrollo.
Para la construccin de software se requiere de un proceso de desarrollo y una metodologa de
trabajo, como vimos anteriormente, existen mtodos pesados que tienen gran carga de tiempo y
esfuerzo en la documentacin del sistema y mtodos giles que requieren de menos tiempo en el
desarrollo pero es necesario contar con recursos ms capacitados. Ambas metodologas implican
tiempo, recursos y costos asociados, los cuales deben ser registrados y analizados para

- 35 -
determinar si hay que realizar mejoras al proceso, qu metodologa conviene ms, cuntos
recursos altamente especializados se necesitan para cumplir con xito la entrega en el tiempo y a
un costo menor, sin perder la calidad del producto.
Cuando se realiza la estimacin asociada al esfuerzo y al tiempo con las actividades del proyecto,
es necesario responder a las siguientes preguntas:
1- Cunto esfuerzo se requiere para completar una actividad?
2- Cunto tiempo se necesita para completar una actividad?
3- Cul es el costo total de una actividad?
En la etapa de planificacin se tienen en cuenta el alcance del sistema, la cantidad y criticidad de
los requerimientos y la cantidad de recursos necesarios para llevar a cabo el proyecto. En las
primeras etapas es necesario realizar una estimacin de costos en funcin a estos factores. Esta
estimacin es necesaria para establecer el presupuesto para el proyecto y asignar un valor de
venta al producto.
Existen tres parmetros involucrados en el clculo del costo total de un proyecto de desarrollo de
software.
1- Costos de hardware y software, incluyendo el mantenimiento de los mismos.
2- Costos de viajes y capacitacin.
3- Costos de esfuerzo (costo de hora hombre).
Los costos de esfuerzo son los ms elevados del proyecto, incluyen los salarios de los
profesionales, pero hay otros costos asociados al de esfuerzo y son los que se tienen en cuenta
para que el proceso se lleve a cabo, como son las inversiones en comunicacin, redes, gastos de
servicios elctricos, de telefona, edilicios, entre otros, lo que hacen el costo total.
Durante la ejecucin del proceso se deben actualizar regularmente sus estimaciones de tiempo y
costos. Esta revisin ayuda a la planificacin del proyecto y el uso efectivo de los recursos. Por
ejemplo, si los gastos actuales son mayores que los estimados se debe tomar una decisin
temprana, antes de que el proyecto de prdidas o se tenga que abortar. Lo mismo sucede cuando
se verifica que el tiempo real es mayor al tiempo estimado, con lo cual es posible que sea
necesario incorporar ms recursos lo que implica mayores costos.
Al asignarle un precio al software se debe tener en cuenta consideraciones organizacionales,
econmicas, polticas y de negocio. Esta tarea no es sencilla y es muy comn que las
estimaciones del costo total estn por debajo de lo real.
Cmo se estima correctamente?
No existen tcnicas especficas para estimar el esfuerzo de forma precisa, ya que hay muchos
factores que intervienen, por lo que las empresas se basan en su experiencia, para lo cual es
necesario tener los registros de las mtricas y de los resultados de los cambios realizados en
funcin del anlisis. Estos registros histricos ayudarn a comparar los proyectos y ajustar las
estimaciones de acuerdo a las desviaciones sufridas y a los aciertos realizados.
No obstante existen propuestas de tcnicas de estimacin de costos, entre las ms importantes
podemos citar las siguientes:
Modelado de algoritmos de costos: se realiza en base a los histricos, se hace una mtrica
y el sistema predice.

- 36 -
Juicio experto: basado en la consulta a varios expertos, cada uno hace su estimacin en
funcin de su experiencia y sus registros.
Estimacin por analoga: se realiza en base a la comparacin con otros proyectos
terminados.
Ley de Parkinson: establece que el trabajo se extiende para llenar el tiempo disponible, por
ejemplo si se tiene que entregar un proyecto en 12 meses y se cuenta con 5 recursos, el
esfuerzo requerido se estima en 60 personas / mes.
Pricing to win: el costo del software se estima en funcin a lo que el cliente est dispuesto
a pagar. El esfuerzo estimado depende del presupuesto del cliente y no de la
funcionalidad.
Cada tcnica de estimacin tiene sus ventajas y desventajas, evaluarlas har que la empresa
tome una decisin sobre cul tcnica utilizar, lo cual no implica que sea la misma para cada
proyecto.
Las tcnicas son aplicables cuando existe un documento de especificacin de requerimientos del
software (ERS). Las empresas que han certificado alguna norma de calidad cuentan con dicho
documento, sin embargo en muchos casos, los costos se deben estimar utilizando requerimientos
incompletos, por lo que las etapas de anlisis y diseo son costosas ya que deben lograr relevar
la mayor cantidad de requerimientos para negociar o renegociar el valor del software.
Costos del mantenimiento
La etapa de mantenimiento es la mayor en tiempo, esfuerzo y costos, por lo que merece su
atencin.
Entre las caractersticas ms importante a tener en cuenta se encuentran las siguientes:
Usualmente son considerablemente mayores que los costos del desarrollo.

Afectado tanto por factores tcnicos como no tcnicos.
Los incrementos como el software tambin se mantienen. El mantenimiento corrompe la
estructura del software de manera tal que hace ms difcil el mantenimiento adicional.
El software ms viejo puede tener costos de soporte ms altos (es decir, lenguajes viejos,
compiladores, etc.)
Factores del costo de mantenimiento

Los factores involucrados en el costo del mantenimiento son numerosos, se destacan los
siguientes:
Independencia Modular
o Debera ser posible cambiar un mdulo sin afectar a otros.
Lenguaje de Programacin
o Los lenguajes de programacin de alto nivel son ms fciles de mantener.
Estilo de Programacin
o Los programas bien estructurados son ms fciles de mantener.
Validacin de Programa y Testing
o Los programas bien validados tienden a requerir menos cambios a causa del
mantenimiento correctivo.
Documentacin
o La buena documentacin hace los programas ms fciles de comprender.
Gestin de Configuracin

- 37 -
La buena Gestin de Configuracin significa que las conexiones entre programas y

su documentacin debe ser mantenida.
Dominio de Aplicacin
o El mantenimiento es ms fcil en dominios de aplicacin maduros y bien
comprendidos.
Estabilidad del Personal
o Los costos de mantenimiento son reducidos si el mismo personal es afectado al
mismo por algn tiempo.
Edad del Programa
o Mientras ms viejo es el programa, es ms caro mantenerlo (usualmente).
Ambiente Externo
o Si un programa es dependiente de su ambiente externo, el programa de cambiar
para reflejar los cambios ambientales.
Estabilidad del Hardware
o Los programas diseados para hardware estable no requerir cambiar conforme
cambie el hardware.
Factores que encarecen los costos de mantenimiento

Si bien se tienen en cuenta todos los factores a la hora de estimar los costos de un proyecto, es
lgico que algunos encarezcan ms que otros el proyecto. Algunos de los factores que encarecen
los costos de mantenimiento son:
Usualmente es ms caro agregar funcionalidad despus que el sistema ha sido

desarrollado en vez de disearlo en el sistema desde el comienzo.
El personal de mantenimiento frecuentemente no tiene experiencia ni est familiarizado
con el dominio de aplicacin.
Los programas pueden estar pobremente estructurados y ser difciles de comprender.
Los cambios pueden introducir nuevas fallas como la complejidad de los sistemas hace
difcil la evaluacin del impacto.
La estructura puede ser degradada debido a los cambios continuos.
Puede no haber documentacin disponible para describir el programa.
Conclusin:
Los costos del proyecto son estimados tempranamente; para minimizar las desviaciones es
necesario contar con mtricas y adoptar alguna tcnica que permita que las estimaciones no se
desven demasiado y no sean perjudiciales. Esta tarea implica anlisis de costos y de resultados
de estimaciones anteriores.
Cada etapa del proceso de desarrollo tiene asociado su costo de esfuerzo, su sumatoria dar el
costo total en funcin slo del esfuerzo a ello hay que sumarle los costos directos e indirectos para
lograr el valor final. Es factible realizar este proceso de clculo de costos slo cuando tenemos
independencia para realizarlo, esto significa que no estamos sujetos al presupuesto que cuenta el
cliente.

- 38 -

Lectura 7 - Mantenimiento de Software PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Lectura 7 - Mantenimiento de Software PDF

Caricato da

Copyright:

Formati disponibili

Unidad 4: Proceso de Mantenimiento y Mtricas

Referencia bibliogrfica para el alumno sobre la Unidad 4:

La modificacin de un producto de software luego de su entrega para corregir fallas,

El proceso de mantenimiento se ejecuta cuando el producto de software es sometido a

3,11 Transicin del Software es una secuencia de acciones de desarrollo de software

Materia: Construccin de Software

Si consideramos el proceso de desarrollo como un modelo en espiral con requerimientos, diseo,

Materia: Construccin de Software

Evolucin de Grandes Programas

Realimentacin del sistema

Materia: Construccin de Software

4.1. Prediccin del mantenimiento

Materia: Construccin de Software

Es un atributo de calidad del producto de software, se incorpora al mismo en el momento

No hay un modelo universalmente aceptado que permita medir mantenibilidad, sin

La prediccin del mantenimiento se puede representar de la siguiente forma (Sommerville, cap.

Qu partes del S. son

Cules sern los

Cules sern los

Nmero y complejidad de las interfaces del sistema.

Teniendo en cuenta que el mantenimiento del sistema implica la modificacin de un programa

El mantenimiento tiene una imagen pobre frente al personal de desarrollo y no es visto

Materia: Construccin de Software

El proceso de implementacin se puede simplificar en las siguientes etapas:

Materia: Construccin de Software

Caractersticas inherentes al mantenimiento

Entendimiento del sistema presente:

Implementacin del cambio:

Materia: Construccin de Software

Materia: Construccin de Software

Materia: Construccin de Software

Documentacin del Software Actualizada

Materia: Construccin de Software

Realizar Auditora de Configuracin Fsica

Complejidad de Control: puede medirse examinndose las sentencias condicionales en el

Materia: Construccin de Software

Materia: Construccin de Software

Materia: Construccin de Software

Tambin es posible plantear la reingeniera de procesos de negocio:

4.2. Tipos de mantenimiento

Mantenimiento para reparar fallas de software. Por lo general errores relativamente

Teniendo en cuenta la clasificacin anterior se pueden identificar claramente cuatro tipos de

Mantenimiento adaptativo: modificacin para que el producto funcione en un ambiente

Materia: Construccin de Software

Mantenimiento perfectivo: modificacin destinada a ampliar la funcionalidad o mejorar

Esta clasificacin de los tipos de mantenimiento se puede representar de la siguiente forma:

Cada uno de estos tipos de mantenimiento representa un esfuerzo y un costo en el proceso de

La optimizacin constante del rendimiento de las aplicaciones mediante anlisis tcnicos.

Materia: Construccin de Software

Aseguramiento del rendimiento ptimo de los servicios del cliente.

Las actividades del mantenimiento perfectivo que se encuentran normalmente son:

Materia: Construccin de Software

El mantenimiento adaptativo es cada vez ms frecuente debido a la gran velocidad a la que

Estudio de nuevas versiones de las distintas plataformas software y soluciones

4.2.3. Preventivo y Correctivo

Monitorizacin continua mediante la definicin y desarrollo de servicios de agentes o

Materia: Construccin de Software

Anlisis de la aplicacin: problemas identificados como errores del cdigo de la aplicacin.

Materia: Construccin de Software

Documentacin del know-how adquirido al producirse el problema de cara a que se

Materia: Construccin de Software

Unidad 5: Tcnicas de Mantenimiento

La Ingeniera directa corresponde al desarrollo del software tradicional.