INACAP VIRTUAL

MATERIAL INTRODUCTORIO
TALLER DE MANTENCIN DE SOFTWARE
TI1211
2
INACAP VIRTUAL
COPYRIGHT 2014 TODOS LOS DERECHOS RESERVADOS INACAP | INACAP VIRTUAL
TALLER DE MANTENCIN DE SOFTWARE
TI1211
UNIDAD 4: LAS TCNICAS DE MANTENIMIENTO DE SOFTWARE 3
Taller de mantencin de software
TI1211
Unidad 4: Las tcnicas de mantenimiento de software
MATERIAL INTRODUCTORIO A LA UNIDAD 4
TALLER DE MANTENCIN DE SOFTWARE 4
INACAP VIRTUAL
ndice
INTRODUCCIN
Contenidos
Tema 1: Tcnicas de anlisis de una solicitud de mantencin
1.1 Parte Funcional
1.2 Parte no funcional
1.3 Reproduccin de la falla (debugging)
Tema 2: Introduccin a reingeniera de software
2.1 Proceso y actividades principales
2.2 Dnde y cmo usar
2.3 Actividades de planifcacin
CONCLUSIONES
BIBLIOGRAFA

5
6
6
7
7
8
9
9
11
11
12
12
TALLER DE MANTENCIN DE SOFTWARE
MATERIAL INTRODUCTORIO A LA UNIDAD 4
UNIDAD 4: LAS TCNICAS DE MANTENIMIENTO DE SOFTWARE 5
INTRODUCCIN
Para la unidad de informtica, los procesos de mo-
difcaciones de software son los proyectos que ms
tiempo y costo les ocupa, ya que el desarrollo de un
sistema no debera ir ms all de uno o dos aos y
los procesos de modifcaciones, pueden durar 20 o
ms aos, por lo tanto se debe tomar con la seriedad
que amerita y uno de los puntos a considerar, es que
durante el proceso de mantenimiento de software
es importante mantener un fujo de comunicacin
expedito entre las distintas fuentes del conocimien-
to que existen en la organizacin.
En esta unidad veremos la utilizacin de diagramas
de casos de uso en el mantenimiento de software y
la necesidad de realizar un proceso de reingeniera
al sistema en cuestin, cuando as lo requieran las
condiciones. En qu consiste y qu condiciones de-
ben presentarse para tomar la decisin de hacerlo,
considerando que adems, en los casos de modif-
caciones importantes a los sistemas existentes que
impliquen cambios signifcativos en el diseo ac-
tual y/o funcionalidad, se debe seguir un proceso de
desarrollo similar al empleado para el de sistemas
nuevos.
TALLER DE MANTENCIN DE SOFTWARE 6
INACAP VIRTUAL
La importancia de poder realizar una trazabilidad al
producto software es alta, nos permite tener estndares
internos relacionados con el mantenimiento respecto al
tiempo de respuesta de la unidad informtica y de cada
una de las unidades internas. Dentro de la trazabilidad,
se debe seguir el estado de todos los requerimientos in-
dividuales, incluyendo los rechazados, durante el dise-
o, desarrollo e implementacin y aprobar los cambios
a los requerimientos a travs de un proceso de gestin
de cambios establecidos, e ingresando en dicho sistema
las fechas y recursos involucradas en el proceso.
Vamos a clasifcar los requerimientos como funcionales
y no funcionales. Posteriormente los debemos catalo-
gar en orden de importancia, con esto le damos prio-
ridad, dentro de los mantenimientos pendientes, que
pueden ir desde:
a) Deseables: el usuario lo preferira de otra forma y se
puede archivar para ser realizado en la prxima versin.
b) Urgentes: detienen el funcionamiento del negocio y
hay que reaccionar de forma inmediata.
Se debe llevar un registro de la fecha en que la solicitud
es levantada y de:
El usuario que lo solicita.
El usuario que lo autoriza, (recordemos que cada modi-
fcacin tiene un costo asociado y ser cargado al centro
de costo respectivo).
El usuario experto (a quin acudir en caso de solicitar
mayor informacin sobre el nuevo requerimiento).
El centro de costo (asume el costo del mantenimiento),
el sistema y mdulo al que se hace referencia.
El tipo de mantenimiento (funcional, no funcional).
El tipo de problema (falla o mejora).
El estado de la solicitud (que pueden ser solicitado,
aceptado, en diseo, etc.).
CONTENIDOS
Tema 1: Tcnicas de anlisis de una solicitud de mantencin
La fecha de cada uno de los cambios de estado, fecha
tentativa de trmino, detallada del problema, observa-
ciones (por si se necesita agregar algo).
Los recursos utilizados (en el caso de los RRHH, se
debe identifcar a cada uno de los profesionales que
tienen relacin con este mantenimiento),
La fecha real de trmino.
El estado de conformidad del usuario (en caso de no
quedar 100% conforme con la solucin, la solicitud
quedara en estado de revisin para una prxima ver-
sin programada) y su costo total asociado.
Como se puede observar, hay algunos de los datos que
no pueden ser ingresados al momento de levantar la so-
licitud, sin embargo se irn rellenando en la medida que
el mantenimiento se desarrolle.
Segn COBIT
1
, todos los cambios, incluyendo el man-
tenimiento de emergencia y parches, relacionados con
la infraestructura y las aplicaciones dentro del ambien-
te de produccin, deben administrarse formalmente y
controladamente. Los cambios (incluyendo procedi-
mientos, procesos, sistema y parmetros del servicio) se
deben registrar, evaluar y autorizar previo a la implanta-
cin y revisar contra los resultados planeados despus
de esta. Esto garantiza la reduccin de riesgos que im-
pactan negativamente la estabilidad o integridad del
ambiente de produccin.
1
IT Governance Institute COBIT 4.1
TALLER DE MANTENCIN DE SOFTWARE
MATERIAL INTRODUCTORIO A LA UNIDAD 4
UNIDAD 4: LAS TCNICAS DE MANTENIMIENTO DE SOFTWARE 7
1.1 Parte funcional
Corresponde a trabajar con la funcionalidad del sistema. Tenemos que lograr, en este caso, una gran participacin
del usuario para que nos entregue sus conocimientos al respecto. Los requerimientos de mantencin de la parte
funcional, se pueden deber a dos tipos:
a) Correcciones de un defecto: la funcionalidad fue solicitada y aceptada en el desarrollo del sistema o en un man-
tenimiento anterior, pero se pueden dar las siguientes situaciones: no fue desarrollada, no est operativa, no hace la
operacin como corresponde, el sistema no responde o se cae. En caso de que se tenga, se debera adjuntar informa-
cin adicional, como impresiones de pantallas del error.
b) Mejora del sistema: la funcionalidad no fue requerida anteriormente, sin embargo se necesita incorporar.
Proceso de solicitud de mantenimiento:
Tenemos que dejar claro que alguno de los mantenimientos corresponden a agregar un mdulo completo al software
y se debe hacer un trabajo muy similar al que se realiza cuando hacemos un desarrollo, con cada una de sus fases y
complejidades, sumndole a la que tiene toda modifcacin de software.
1.2 Parte no funcional
Muchos de estos requerimientos no parten del sector usuario, sino de la unidad de informtica. Por ejemplo, si tene-
mos en el plan informtico un proyecto de cambio del computador central y este funciona con un sistema operativo
diferente (software de sistemas), tenemos que probar cmo van a comportarse cada uno de los sistemas que en el
residen y posteriormente hacer una planifcacin para ir mejorando.
Fuente: elaboracin propia.
TALLER DE MANTENCIN DE SOFTWARE 8
INACAP VIRTUAL
Los requerimientos de mantencin no funcionales, tam-
bin se clasifcan en dos tipos:
a) Correcciones de un defecto: el requerimiento fue
solicitado y aceptado en el desarrollo del sistema o en
un mantenimiento anterior, sin embargo no fue desa-
rrollado, no est operativo, no hace la operacin como
corresponde, el sistema no responde o se cae. En caso
de que se tenga, adjuntar informacin adicional, como
impresiones de pantallas del error.
b) Mejora del sistema: el requerimiento no fue solici-
tado anteriormente, sin embargo se necesita incorporar.
De la misma forma que en el caso de las modifcacio-
nes funcionales, una vez levantada la solicitud, la recibe
inmediatamente el ingeniero de mantenimiento, si el
requerimiento est claro, puede seguir adelante, si hay
algo que pudiera estar en duda, debe solicitar una re-
unin con el usuario experto y/o con el que expuso (nor-
malmente se da este ltimo caso cuando es una falla).
En el caso de las modifcaciones por requerimientos
no funcionales, es muy difcil que consista en agregar
un mdulo completo, a menos que no se le haya incor-
porado el de administracin de usuarios, pero a veces
tenemos que intervenir gran parte del cdigo, como en
el caso de solicitar una modifcacin que mejore la ca-
pacidad de entendimiento y aprendizaje.
1.3 Reproduccin de la falla (debugging)
Esta tarea, se realiza cuando ya se ha levantado el re-
querimiento de mantencin y tenemos claro que su cla-
sifcacin indica que es una correccin de un defecto.
Cabe recordar que la unidad de informtica debe tener
distintos ambientes para trabajar:
a) Ambiente de produccin: (puede ser ms de un
equipo). En produccin no podemos instalar herramien-
tas que puedan distorsionar los tiempos de ejecucin
de otros usuarios y otros sistemas, pudiendo cambiar
los valores de las variables.
b) Ambiente de desarrollo: (replicamos todos los
equipos, software y sus datos no reales), pero est la
versin que se est modifcando. En este ambiente la
tcnica de debugging ms comn consiste en ejecutar
el cdigo de la aplicacin lnea por lnea, verifcando el
valor de las variables y el contexto de ejecucin hasta
encontrar el error.
c) Ambientes de pruebas: (replicamos todos los equi-
pos, su software y sus datos no reales). Ac debemos
tener acceso a la versin en produccin y a las distintas
versiones que se estn trabajando, en ambientes sepa-
rados, ya que se debe intentar replicar la falla. En caso
de no poder, se puede revisar el cdigo para ver si se
logra dilucidar en que condiciones puede ocurrir.
El primer paso, es conseguir informacin sobre el esta-
do de la aplicacin y del servidor al momento de pro-
ducirse el error. Luego debemos analizarla para obtener
el origen del problema. Para el segundo paso, existen
algunas herramientas que permiten hacer una depura-
cin (debug) o seguimiento de forma remota y con in-
terfaces grfcas.
TALLER DE MANTENCIN DE SOFTWARE
MATERIAL INTRODUCTORIO A LA UNIDAD 4
UNIDAD 4: LAS TCNICAS DE MANTENIMIENTO DE SOFTWARE 9
Tema 2: Introduccin a reingeniera de software
Cuando tenemos un software heredado, grande y que
es muy importante para los objetivos de la empresa, se
cumplir:
Ley de cambio continuo (1974): el software que se im-
plement en un contexto de cmputo del mundo real
y que, por tanto, evolucionar con el tiempo (llamados
sistemas tipo E) debe adaptarse continuamente, sino se
volver progresivamente menos satisfactorio.
Ley de complejidad creciente (1974): cuando un sis-
tema de tipo E, evoluciona, su complejidad aumenta, a
menos que se trabaje para mantenerlo o reducirlo.
En la medida que este tipo de sistemas se va reparando,
llegar un momento en el que se necesitar reconstruir-
lo. Se crear un producto con funcionalidad agregada,
mejor desempeo y confabilidad, como tambin opti-
mizando la mantenibilidad. A eso se le llama reingenie-
ra.
2.1 Proceso y actividades principales
Para implementar los principios de la reingeniera, se
puede usar un modelo de proceso de reingeniera de
software que defna seis actividades y que se muestra
en la fgura siguiente:
Figura: Modelo de procesos de reingeniera de software.
Fuente: Un enfoque prctico. Ingeniera de Software, Roger
Prerssman.
Cada una de estas actividades, presentadas en el mode-
lo cclico, las veremos a continuacin:
a) Anlisis de inventarios: debe existir un inventario
de todas las aplicaciones, puede estar alojado en una
planilla electrnica que presente una descripcin deta-
llada de cada una. Al ordenar esta informacin, apare-
cen los candidatos para reingeniera. El inventario debe
revisarse con periodicidad, ya que el estado de las apli-
caciones puede cambiar y como resultado, cambiarn
las prioridades para utilizar la reingeniera.
b) Reestructuracin de documentos: la documenta-
cin dbil es el distintivo de muchos sistemas hereda-
dos. Para evitar esto se pueden realizar algunas de las
siguientes opciones:
El sistema funciona y se puede vivir con lo que tiene:
en algunos casos, este es el enfoque correcto. Si un pro-
grama es relativamente esttico y se aproxima al fnal
de su vida til, es improbable que experimente cambio
signifcativo, djelo as!
La documentacin debe actualizarse, pero su organi-
zacin tiene recursos limitados: es posible que no sea
necesario volver a documentar por completo una apli-
cacin. En vez de ello, aquellas porciones del sistema
que en el momento experimenten cambio se documen-
tan por completo. Con el tiempo, evolucionar a una co-
leccin til y relevante.
El sistema tiene importancia empresarial y debe vol-
ver a documentarse por completo: incluso en este caso,
un enfoque inteligente es recortar la documentacin a
un mnimo esencial.
c) Ingeniera inversa: el trmino tiene su origen en
el mundo del hardware. Una compaa desarma un pro-
ducto de otra empresa con la intencin de entender los
secretos de diseo y fabricacin de su competidor. No
obstante, la ingeniera inversa para software es el pro-
ceso de analizar un programa con la intencin de crear
una representacin del mismo en un nivel superior de
abstraccin que el cdigo fuente. Las herramientas de
ingeniera inversa extraen informacin de diseo de
datos, arquitectnico y procedimental de un programa
existente.
TALLER DE MANTENCIN DE SOFTWARE 10
INACAP VIRTUAL
d) Reestructuracin de cdigo: para realizar esta actividad se analiza el cdigo fuente con una herramienta de
reestructuracin. Las violaciones a los constructos de programacin estructurada se anotan y luego el cdigo se
reestructura (esto puede hacerse automticamente) o incluso se reescribe en un lenguaje de programacin ms
moderno. El cdigo resultante se revisa y se pone a prueba para garantizar que no se introdujeron anomalas. La
documentacin de cdigo interna se actualiza.
e) Reestructuracin de datos: a diferencia de la de cdigo, que ocurre en un nivel de abstraccin relativamente
bajo, esta es una actividad de reingeniera a gran escala. En la mayora de los casos, comienza con una actividad de
ingeniera inversa. En ella se defnen modelos de datos necesarios, se identifcan los objetos y atributos de datos y
se revisa la calidad de las estructuras de datos existentes.
Puesto que la arquitectura de datos tiene una fuerte infuencia sobre la del programa y sobre los algoritmos que
los pueblan, las modifcaciones a los datos, invariablemente resultarn en cambios arquitectnicos o en el nivel de
cdigo.
f) Ingeniera hacia adelante. Esta recupera informacin de diseo del software existente y tambin la usa para al-
terar o reconstituirlo, con la intencin 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 y/o mejora
el rendimiento global.
Para diferenciar los dos conceptos de ingeniera directa (o hacia adelante), de la reingeniera, es conveniente revisar
la fgura siguiente:
Figura: Comparacin ingeniera directa y reingeniera.
Fuente: Ingeniera de Software. Ian Sommerville.
TALLER DE MANTENCIN DE SOFTWARE
MATERIAL INTRODUCTORIO A LA UNIDAD 4
UNIDAD 4: LAS TCNICAS DE MANTENIMIENTO DE SOFTWARE 11
Y para visualizar el proceso de reingeniera completo, segn Ian Sommerville:
Figura: Proceso de reingeniera.
Fuente: Ingeniera de Software. Ian Sommerville.
2.2 Dnde y cmo usar
A primera vista, la sugerencia de desarrollar un programa grande cuando ya existe una versin operativa, puede
parecer muy extravagante. Antes de juzgar, considere los siguientes puntos:
El costo de mantener una lnea de cdigo fuente puede ser 20 a 40 veces el del desarrollo inicial de dicha lnea.
El rediseo de la arquitectura del software (programa y/o estructura de datos), con el uso de modernos conceptos
de diseo, puede facilitar enormemente el mantenimiento futuro.
Puesto que ya existe un prototipo del software, la productividad de desarrollo debe ser mucho ms alta que el
promedio.
Ahora el usuario experimenta con el software. Por tanto, pueden averiguarse con mayor facilidad los nuevos requi-
sitos y la direccin del cambio.
Las herramientas automatizadas para reingeniera facilitarn algunas partes de la labor.
Existir una confguracin de software completa (documentos, programas y datos) al completar el mantenimiento
preventivo.
Por lo tanto, la decisin de hacerlo o no, puede variar de una aplicacin a otra.
TALLER DE MANTENCIN DE SOFTWARE 12
INACAP VIRTUAL
IT Governance Institute , COBIT (2007). 4.1. Adquirir e Implementar,
AI6.- Administrar cambios.
Pressman, R. S. (2005). Ingeniera del Software. Un enfoque prctico.
Captulo 6, 9 y 29. Mc Graw Hill.
Sommerville, I, (2005). Ingeniera del software. Captulo 21: Evolucin
del software. (7a ed). Pearson Education.
CONCLUSIONES
BIBLIOGRAFA
De esta manera hemos llegado al fnal de la unidad 4 de la asignatura de
Taller de Mantencin de Software. Luego de haber revisado los temas
centrales, se puede decir que el proceso de modifcacin de software en
una empresa es algo que se debe llevar con mtodos y procesos claros,
para que no se nos cree un problema mayor con cada cambio que se rea-
lice. Al tener incorporado un sistema de gestin para soportar el mante-
nimiento, nos permite tener mtricas y sacar estndares de rendimiento
de nuestro propio actuar.
Tambin se analiz la importancia de ir aplicando conceptos de ingenie-
ra a los mantenimientos que se realizan, para bajar el volumen del pro-
blema a medida que se avanza en el entendimiento del software.
INACAP VIRTUAL