Unidad 3. Mantenimiento de Sistemas de Software

Pruebas y mantenimiento de sistemas de software
Unidad 3. Mantenimiento de sistemas de software

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 1

Ingeniera en Desarrollo de Software
10 Cuatrimestre

Programa de la asignatura:


Clave:
150941040

Universidad Abierta y a Distancia de Mxico
UnADM

ndice

Unidad 3. Mantenimiento de sistemas de software ............................................................ 3
Presentacin de la unidad ................................................................................................. 3
Propsitos .......................................................................................................................... 4
Competencia especfica ..................................................................................................... 4
3.1. Mantenimiento del software ........................................................................................ 4
3.1.1. Tipos de mantenimiento ........................................................................................... 9
3.1.2. Pronstico del mantenimiento ................................................................................ 10
Actividad 1. Mantenimiento de software ........................................................................... 17
3.2. Procesos de evolucin del software .......................................................................... 18
3.2.1. Evolucin del software ........................................................................................... 18
3.2.2. Reingeniera de sistemas ....................................................................................... 22
3.2.3. Mantenimiento de sistemas existentes ................................................................... 34
Actividad 2. Procesos de evolucin del software .............................................................. 39
3.3. Gestin del mantenimiento ....................................................................................... 40
3.3.1. Costos de un plan de mantenimiento de sistemas de software .............................. 41
3.3.2. Viabilidad y anlisis de riesgo ................................................................................ 42
Actividad 3. Gestin del mantenimiento ........................................................................... 67
Autoevaluacin ................................................................................................................ 67
Evidencia de aprendizaje. Informe de viabilidad y anlisis de riesgo de un proyecto de
mantenimiento de software .............................................................................................. 68
Autorreflexiones ............................................................................................................... 68
Cierre de la unidad .......................................................................................................... 69
Para saber ms ............................................................................................................... 70
Fuentes de consulta ........................................................................................................ 71



Presentacin de la unidad

Despus de establecer los fundamentos del aseguramiento de la calidad en la unidad 1.
Aseguramiento de la calidad del software y de someter al sistema por un proceso de
pruebas para lograr un grado de aceptacin por parte del cliente en la unidad 2 Pruebas
de sistemas de software donde mediante el diseo de un plan de pruebas donde se
realiz el anlisis de los requerimientos del software y el tipo de prueba correspondiente,
el software pasa a una etapa de implementacin, es decir que el sistema de software se
libera.

El sistema puesto ya en produccin implica necesariamente una evolucin del mismo
pues, lo que es funcional ahora maana ya no lo es porque surgen nuevos requerimientos
o son necesarios cambios estructurales en el sistema para adaptarse lo ms rpidamente
a nuevas necesidades, de tal forma que se requiere realizar acciones.

No es menos complejas que desarrollar un sistema de software, se trata ni ms ni menos
del mantenimiento, en donde antes de la liberacin del sistema se establecen las fechas
del mantenimiento peridico, para mantener al sistema funcional. Y durante la vida en
produccin es posible que broten errores ocultos que hay que arreglar y/o nuevos
requerimientos en el proceso de negocio que requieran cambios en el sistema y que hay
que implementar si no se quiere perder ventaja competitiva.

La fase del mantenimiento se ubica como la ltima dentro del proceso de desarrollo de
software y generalmente no es un proceso econmico, por lo que, para comprender la
importancia y el peso de esta fase en el desarrollo de la presente unidad, se abordarn
los siguientes temas:

El tema 3.1 Mantenimiento del software, es una introduccin a la fase del mantenimiento
identificando el concepto, los tipos de mantenimiento del software segn la norma y los
pronsticos del mismo, sentando las bases necesarias para la comprensin del siguiente
tema 3.2. Procesos de evolucin del software, donde se expondr el proceso de evolucin
inevitable del software, el papel de la reingeniera como herramienta para la evolucin
lgica del software y el mantenimiento a un software operando. Para darle sentido a los
temas anteriores es necesaria una adecuada gestin que es el ltimo tema de la unidad
3.3. Gestin del mantenimiento, englobando en una metodologa los pasos necesarios
para asegurar mantenimientos en tiempos sin abusar del presupuesto y que se siga
manteniendo la funcionabilidad del software.


Propsitos

Al finalizar esta unidad logrars:
Identificar los tipos de mantenimiento a realizar a lo largo de la vida til de un
sistema de software, de acuerdo a la causa que genera la necesidad.
Seleccionar la estrategia ms adecuada segn el tipo de mantenimiento a realizar
para garantizar que el objetivo del mantenimiento se cumpla.
Identificar en qu momento de la evolucin se encuentra el software para aplicar
reingeniera o el mantenimiento correspondiente.
Identificar las fases de la gestin del mantenimiento para aplicarlas y lograr un
mantenimiento de calidad, eficiente y que garantice la funcionabilidad del sistema
de software.

Competencia especfica

Disear el proyecto de mantenimiento de un producto software para asegurar el
funcionamiento de acuerdo a los estndares de calidad mediante un estudio de viabilidad,
riesgos y costos.

3.1. Mantenimiento del software

Una vez entregado un producto de software para su puesta en marcha, despus de
verificar que cumple con los requerimientos de los usuarios as como con los
requerimientos no funcionales propios del sistema. Sin embargo, de acuerdo al ciclo de
vida del software, an en esta fase de puesta en marcha, no termina la responsabilidad
del equipo de desarrollo.

Es posible que durante el uso cotidiano del sistema de software surjan errores que hayan
pasado desapercibidos, los ambientes operativos cambien, el proceso de negocio de la
empresa cambie y por ende surjan nuevos requerimientos de usuario necesarios.

De acuerdo al ciclo de vida del software, se observa que el mantenimiento es una de sus
fases, y el ciclo propio del mantenimiento se repetir hasta que haya un cambio
tecnolgico y el sistema ya no sea soportado, o simplemente deje de ser funcional y entre
en una situacin de obsolescencia, se ilustra la fase de mantenimiento como una fase del
ciclo de vida del software, en la imagen siguiente.


El mantenimiento en el ciclo de vida del software (Basado en Sicilia, 2008)

Como se observa en la imagen anterior, el mantenimiento comienza cuando se identifican
nuevos requerimientos despus de un periodo de garanta o soporte post entrega, sin
embargo, tambin se realizan actividades de mantenimiento propias del sistema, como la
depuracin de archivos temporales durante la operacin del mismo.

Hace unas dcadas, la fase de mantenimiento no tena la importancia que tiene hoy en
da, actualmente se considera que un sistema de software no es una inversin cualquiera
y se trata de aprovechar al mximo, esto es posible gracias al mantenimiento mediante el
cual se alarga la vida operativa de un sistema de software.

Bourque y Fairley (2014) en la gua para la ingeniera de software SWEBOK Software
Engineering Body of Knowledge, (la cual es un proyecto del IEEE Computer Society),
define al mantenimiento del software como el conjunto de actividades necesarias para
hacer que los programas sean rentables (p.5-1).Dichas actividades son:

Las actividades que se realizan durante la etapa previa a la entrega es la
planificacin de las operaciones posteriores a la entrega, como el mantenimiento
y la logstica para las actividades de transicin entre las versiones del sistema de
software.
Las actividades posteriores a la entrega del sistema de software, incluyen la
clasificacin e identificacin de requerimientos, anlisis, diseo,
implementacin, pruebas de implantacin, pruebas de aceptacin de las
modificaciones realizadas, al sistema (que es el mantenimiento mismo) y entrega
de la nueva versin del sistema de software.

Para el estndar ISO/IEC 14764 (2006) el mantenimiento es la modificacin de un
producto de software despus de la entrega para corregir los fallos, para mejorar el
rendimiento u otros atributos, o para adaptar el producto a un nuevo entorno.

El mantenimiento se realiza con el fin, en general de:
Corregir fallas detectadas
Mejorar el diseo
Implementar mejoras
Mantener la interfaz con otros sistemas (ejemplo: tienda virtual con los portales
bancarios)
Adaptar los programas de manera que las caractersticas del sistema y de las
telecomunicaciones se puedan seguir utilizando en diferentes de plataformas de hardware
y software,
Migrar el legado del software
Identificar cundo es necesario retirar el software de su vida productiva.

Los objetivos del mantenimiento se establecen de acuerdo al tipo de mantenimiento (se
explicar a detalle en el tema 3.1.1. Tipos de mantenimiento) se explicarn a detalle los
tipos de mantenimiento:

Mantener el control sobre las funciones del software del da a da, se realizan una
serie de modificaciones para permitir la funcionalidad del sistema a travs del
tiempo (correctivo).
Mantener el control sobre modificacin de software, al ir adaptando el sistema de
software a los distintos requerimientos es necesario tener una vigilancia para que
tales modificaciones no degeneren el sistema de software (adaptativo).
El perfeccionamiento de las funciones existentes, tales modificaciones buscan en
todo momento el mejoramiento de los procesos del sistema (perfectivo).
Prevenir el rendimiento del software de degradar a niveles inaceptables, son
acciones de limpieza de basura informtica, de procesos incensarios que hacen
lento el sistema, operaciones que provoquen desbordamiento de la memoria,
etctera (preventivo).

Las actividades del proceso de mantenimiento, como se observa en la siguiente imagen,
es un proceso continuo hasta que el sistema se retira y se reemplaza por otro o hay una
migracin de una versin a otra del sistema de software. Las actividades observadas
corresponden al ciclo de vida del software, estudiadas en la asignatura Introduccin a la
ingeniera de software.

Actividades del proceso del proceso de mantenimiento ISO/EC 14764 (2006)

Cada una de las actividades del mantenimiento de software segn ISO/IEC 14764 (2006)
se clasifica en tareas de la siguiente manera.

Tareas de procesos de mantenimiento:
Desarrollar planes y procedimientos de mantenimiento.
Establecer procedimientos para la peticin de modificacin.
Implementar el proceso de gestin de la configuracin.

Tareas de nuevos requerimientos y modificaciones:
Realizar el anlisis inicial.
Verificar el problema.
Desarrollar opciones para aplicar la modificacin.
Documentar los resultados.
Obtener la aprobacin para la modificacin.

Tareas de implementacin de la modificacin:
Realizar un anlisis detallado.
Desarrollar, el cdigo y probar la modificacin.
Tareas de revisin, mantenimiento y aceptacin:
Obtener la aprobacin para su modificacin.
Realizar las pruebas pertinentes.

Tareas de migracin:
Asegurar de que la migracin este de acuerdo con la norma ISO/IEC 12207.
Desarrollar un plan de migracin.
Notificar a los usuarios de los planes de migracin.
Llevar a cabo operaciones paralelas de migracin y pruebas de compatibilidad de
datos.
Notificar al usuario de que la migracin se ha iniciado.
Llevar a cabo una revisin posterior a la operacin.
Asegurar de que los datos de la versin anterior estn accesibles.

Tareas de retiro de software:
Desarrollar un plan de retiro del sistema de software.
Notificar a los usuarios de los planes de retiro del sistema de software.
Llevar a cabo operaciones paralelas del retiro del sistema de software y la
implantacin del nuevo sistema de software.
Notificar al usuario de que el proceso de retiro se ha iniciado.
Asegurar de que los datos del sistema en retiro estn accesibles para el nuevo
sistema de software.

Una estrategia de mantenimiento, segn ISO/IEC 14764 (2006, p. 31) se conforma por,
"todas las actividades para preparar los recursos humanos y materiales necesarios para el
mantenimiento de software para productos de software".

Y un plan de mantenimiento es un documento que indica cules son las prcticas
especficas del mantenimiento, los recursos y la secuencia de actividades relevantes para
el mantenimiento de un software, ISO/IEC 14764 (2006).

Todo lo anterior debe estar documentado en un plan de mantenimiento del software
(FHWA CA Divisin, 2009, apartado 8.4.12), es necesario que revises los elementos que
conforman este plan en el documento Plantilla del plan de mantenimiento FHWA CA
Divisin (2009) apartado 8.4.12, con los elementos bsicos a considerar.

Las diferentes causas (mencionadas previamente) por las cuales la fase de
mantenimiento se inicia, da lugar a los diferentes tipos de mantenimiento, como se
detallar en el subtema siguiente 3.1.1 Tipos de mantenimiento.

3.1.1. Tipos de mantenimiento

El ISO/IEC 14764 (2006) es un estndar internacional que proporciona los requerimientos
para el proceso de mantenimiento del software, el cual establece tres tipos de
mantenimiento basados en la clasificacin de Lientz y Swanson (1978).

Mantenimiento correctivo: Son modificaciones reactivas a un producto software
hechas despus de la entrega, para corregir defectos descubiertos.
Mantenimiento adaptativo: Es una modificacin de un producto software realizada
despus de la entrega con el fin de que siga siendo productivo en un ambiente
diferente.
Mantenimiento perfectivo: Es la modificacin de un producto software despus de
la entrega para mejorar o seguir manteniendo su rendimiento.

La siguiente tabla es la propuesta del estndar ISO/IEC 14764 (2006), en donde se
observan las caractersticas de los tipos de mantenimiento, as se tiene que el preventivo
(tipo que agrega el estndar ISO/IEC 14764) es de correccin y es proactivo, se adelanta
a los hechos, el perfectivo tambin se adelanta a los hechos pero es de mejora, el
adaptativo es de mejora pero de naturaleza reactiva, reacciona a los hechos; y el
correctivo, como su nombre lo dice, es de correccin y de naturaleza reactiva.

Naturaleza Correctiva Mejora
Proactiva Preventivo Perfectivo
Reactiva Correctivo Adaptativo
Caractersticas de los tipos de mantenimiento ISO/IEC 14764 (2006)

Tipos de mantenimiento segn ISO/IEC 14764 (2006):
Mantenimiento preventivo: Son modificaciones del producto software tras la
entrega para detectar y corregir fallos latentes antes de que se conviertan en fallos
efectivos, ISO/IEC 14764 (2006). El mantenimiento preventivo, se trata de mejorar en
puntos especficos detectados sin cambiar los requerimientos originales; como la
validacin de datos de entrada, mejorar la legibilidad de los programas y/o la
documentacin, detectar mdulos reutilizables para otros sistemas.

Mantenimiento correctivo: Identifica y elimina los defectos o fallos en el sistema de
software, los fallos son provocados en el procesamiento de salidas incorrectas del
programa, en el rendimiento del sistema, como lentitud en el tiempo de respuesta de
bsqueda, en la programacin al encontrarse inconsistencias en el diseo del
programa con lo programado, en la documentacin de la funcionalidad de un
programa que indica para que sirve y el manual del usuario que dice otra cosa.

Mantenimiento adaptativo: Es la adaptacin del sistema a un nuevo entorno de
operacin, tales cambios son: el cambio del sistema operativo, una computadora con
diferentes caractersticas a la usual, cambio de una arquitectura de red a otra, o
nuevos elementos al entorno de operacin del sistema como herramientas
administrativas de orgenes de datos ODBC
1
.
Los cambios en el entorno de ejecucin del software se realizan en dos aspectos:
Cambio en el entorno de los datos, de un archivo de datos a tablas de base de
datos.
Cambio en el entorno de los procesos, de una plataforma de desarrollo a otra como
de C++ a C#.

El mantenimiento perfectivo se hace necesario cuando surgen nuevos requerimientos, por
ejemplo, cambios en el formato de la factura, nuevos procedimientos de clculo o hasta
un nuevo componente.

Se dice que se tiene un mantenimiento perfectivo de aplicacin cuando al sistema se le
incorporan nuevas funcionabilidades y el mantenimiento perfectivo de eficiencia, cuando
solo se busca mejorar un proceso existente.

Una vez identificados los tipos de mantenimiento y las caractersticas que los determinan,
la actividad siguiente es determinar cada cuando hacer un mantenimiento y el impacto
econmico que representa dentro del costo del sistema, que se desarrollar en el tema
siguiente 3.1.2. Pronstico del mantenimiento.

3.1.2. Pronstico del mantenimiento

En el tema anterior se identificaron los tipos de mantenimiento, y se observ que implica
una serie de actividades que tienen un costo con tal de que el sistema siga siendo
funcional. Para no caer en la situacin de que el mantenimiento sobrepase el costo del
sistema, es necesario hacer un pronstico del mantenimiento.

Un pronstico no es ms que una prediccin de la evolucin de un proceso o de un hecho
futuro a partir de criterios lgicos o cientficos segn la Real academia de la lengua
espaola (2014), el concepto aplicado al mantenimiento del software en pronosticar el
costo del mantenimiento para realizar los ajustes necesarios para tener el control del
mismo.

1
Open DataBase Connectivity
Una aplicacin sencilla de un pronstico sera por ejemplo, el costo anual de mantener un
sitio web esttico despus de que se puso en marcha es ms o menos equivalente al
costo de su desarrollo. Si el desarrollo cost $150,000.00, se puede esperar que el costo
de mantenimiento sea de $112,500.00 Foster (1993) hasta los $150,000.00 en un periodo
de 4 a 5 aos (Tecnologas de la informacin y ms, 2008).
El ejemplo anterior es sencillo, pero se complica cuando los sistemas son dinmicos y
tienden a crecer exponencialmente por ejemplo, una plataforma de comercio electrnico o
una universidad cuya matrcula se incremente semestre tras semestre.

Hay modelos en el mercado para predecir los costos del mantenimiento, basados en la
densidad de los defectos tales como:

La curva de Raleigh. Este modelo predice la deteccin de fallos durante la vida del
esfuerzo de desarrollo de software por lo tanto tambin del mantenimiento. Se puede
utilizar este perfil para medir el estado de defecto. Este modelo supone que durante la
vida del proyecto que los fallos detectados por mes se asemejar a una curva de Raleigh
segn Lakey (2014)

Curva de Raleigh relacin fallas-tiempo (basado en Lakey, 2014, p. 10)

Anlisis Weibull. El anlisis de Weibull es la tcnica mayormente elegida para estimar
una probabilidad, basada en datos medidos o asumidos. La distribucin de Weibull es til
por su habilidad para simular un amplio rango de distribuciones como la normal, la
exponencial y para los proyectos de mantenimiento tener una aproximacin a un numero
de fallos, Abernethy (2006).

Prediccin de fallas basado en Abernethy (2006) pg. 5

KSLOC. KSLOC es el nmero de miles de lneas de cdigo (1000(K ) por sus siglas en
ingles de -Source Logical Code) fuente que se entregarn, al finalizar el proyecto del
mantenimiento, Newport (1994).

Variable A, son las caractersticas del tipo de aplicacin a desarrollar.
Variable B, es el tamao aproximado de la aplicacin en lneas de cdigo fuente y
el nmero de unidades.
Variable C, determina la densidad de falla inicial y el nmero de fallas inherentes
estimadas, utilizando las listas de verificacin.

D = Numero de fallas por KSLOC = A si D no es conocida
FD = Errores por KSLOC = A * D si D es conocida
N = Nmero estimado de fallas inherentes = FD *KSLOC

Sin embargo estos modelos no tienen un 100% de fiabilidad, ya sea por imprecisin o
complejidad sin mencionar su costo.

Hay una metodologa rescatable basada en el modelo de estimacin de proyectos de
Boehm (2000), que es ampliamente aceptada en la industria del software como un modelo
vlido para la prediccin de los costos de mantenimiento, el cual es el COCOMO II (por
sus siglas en ingls de Constructive Cost Model II), es un modelo que permite estimar el
costo, el esfuerzo, y el tiempo en la planificacin de una nueva actividad de desarrollo de
software. COCOMO II es la ltima ampliacin del modelo COCOMO 81, publicado en
1981.
Es relativamente fcil de entender, y ms importante an, permite refinar el pronstico
gracias a los multiplicadores de costo.

La frmula bsica de Boehm (2000) que se utiliza en el modelo COCOMO es la siguiente:

Donde:

AME: Es el esfuerzo de mantenimiento anual medido en meses-persona.
ACT: Es el trfico de variacin anual, lo que representa una fraccin de las instrucciones
de cdigo de un producto de software que sean objeto de modificaciones durante un ao
tpico mediante la adicin o modificacin.
SDT: Es el tiempo de desarrollo de software en meses-persona.

Por ejemplo, un proyecto de software requiere 100 meses-persona de esfuerzo de
desarrollo y se estima que el 15 % del cdigo se modificara en un ao tpico. Por tanto, la
estimacin del esfuerzo de mantenimiento anual bsica (AME) es:

= 0,15 x 100 = 15 meses-persona.

Lo cual significa que se debe planear 15 meses-persona de esfuerzo por ao para
mantener este proyecto de software especfico, que representa el costo base del
mantenimiento.

La estimacin base de costo anual de mantenimiento obtenida anteriormente se puede
refinar, por la importancia de cada factor que afecta el costo y la seleccin del
multiplicador de costo adecuado.

El costo de mantenimiento base se multiplica por cada multiplicador de costo para obtener
una estimacin integral del costo de mantenimiento.

Los multiplicadores de costo son aquellas variables significativas que afectan el costo del
mantenimiento del software, con lo cual se logra una mayor precisin en la estimacin del
costo:

CPLX: Complejidad del producto
AEXP: Experiencia de los analistas

El resultado del clculo del AME en el ejemplo anterior que se traduce como el costo
base del mantenimiento se refina considerando el factor de la complejidad del producto
CPLX como alto, debido al nmero de componentes y al nmero de transacciones que
se hacen en la base de datos y el factor AEXP bajo debido a la poca disponibilidad de
personal de apoyo con experiencia en aplicaciones. En las imgenes siguientes se
observa el rango de valores del factor CPLX, obtenido a travs de la experiencia, segn
Gmez (2014).
Atributo Valores
Muy bajo Bajo Nominal Alto Muy alto Extra alto

CPLX
Se usan
expresiones
matemticas
simples
Se usan
muchos
recursos de
planificacin
0,7 0,85 1 1,15 1,3 1,65
Rango de valores de CPLX

CPLX = 1,30

AEXP = 1,29

Atributo

Valores
Muy bajo Bajo Nominal Alto Muy alto Extra alto
AEXP <= 4 meses 1 ao 3 aos 6 aos >= 12 aos o
reimplementacin
de un subsistema
-
1,29 1,13 1 0,91 0,82 -
Rango de valores de AEXP

La frmula para refinar la estimacin del costo del mantenimiento queda de la siguiente
forma:

Sustituyendo los valores en la frmula:

AEM = 0.15 x 100 x 1,30 x 1,29 = 25,1 meses-persona.

El pronstico de las mejoras no es un asunto trivial ya que se requiere conocer las futuras
demandas de mejoras de los clientes. Estas solicitudes de cambio ya no representarn un
costo para la empresa desarrolladora, porque se integran a los costos estimados en la
planeacin y se cobrarn a la empresa que se le vendi el sistema de software. Si es un
producto que se cre en el departamento de sistemas de la empresa, las solicitudes de
cambio s representan un costo extra para la empresa, ya que se requiere financiar los
cambios.

La prediccin del mantenimiento se ocupa de la evaluacin de qu partes del sistema
pueden causar problemas y sus costos asociados.

Distribucin de la prediccin del mantenimiento basado en Henry & Wake (1988, p.14)

La prediccin de cambios, determina el nmero de cambios necesarios para el sistema
con base en la relacin entre el sistema y su entorno. Los sistemas fuertemente
acoplados requieren cambios siempre que se modifica el medio ambiente.

Los factores que influyen en la relacin entre el sistema y su entorno, son:
La cantidad y complejidad de las interfaces del sistema.
El nmero de los requisitos del sistema inherentemente voltiles
2
.
Los procesos de negocio que utiliza el sistema.
La prediccin del costo del mantenimiento, se pueden realizar mediante la evaluacin de
la complejidad de los componentes del sistema, hay estudios de base que han

2
Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o despus
de que se haya puesto en funcionamiento
demostrado que la mayor parte del esfuerzo se gasta en el mantenimiento de un nmero
relativamente pequeo de los componentes del sistema y la complejidad depende de los
siguientes factores:
La complejidad de las estructuras de control
La complejidad de las estructuras de datos.
Del objeto, mtodo (procedimiento) y el tamao del mdulo.

La prediccin de la mantenibilidad, permite que los procesos sean medidos y usados
para evaluar la mantenibilidad a travs de los siguientes casos:
El nmero de solicitudes de mantenimiento correctivo.
El tiempo promedio necesario para el anlisis de impacto.
El tiempo promedio necesario para poner en prctica una solicitud de cambio.
El nmero excepcional de solicitudes de cambio.

Si cualquiera o todos los casos anteriores es cada vez ms frecuente, esto indica una
disminucin en la capacidad de mantenimiento.

Para determinar la frecuencia de un mantenimiento preventivo es necesario considerar el
entorno de uso, segn la siguiente tabla:
Entorno de uso Frecuencia de mantenimiento
Muy poco uso (equipo aislado, pocas
aplicaciones, etctera.)
Una vez al ao
Uso espordico (consultas puntuales,
mbitos atpicos, etc.9
Dos veces al ao
Uso diario (entorno de oficina) Tres veces al ao
Uso intensivo (multiusuario, flujo de datos
alto-pagina comercio electrnico-)
De cuatro a seis veces al ao
Uso muy intensivo (multiusuario, red, alto
flujo de datos, por ejemplo: algunos sitios
de redes sociales)
De seis a doce veces al ao
Tabla de frecuencia de mantenimiento de acuerdo al entorno de uso (basado en Gallego, 2010, p.10)

Los dems tipos de mantenimientos se determinan de acuerdo a los tipos de
requerimientos que surjan.

En este tema se ha desarrollado la forma de pronosticar costos del mantenimiento,
identificar factores que incrementan el costo del mantenimiento as como, la distribucin
de la prediccin del mantenimiento para medir el impacto econmico que la empresa
absorber con tal de mantener funcional el sistema de software.

De manera general se han identificado los tipos de mantenimiento y sus caractersticas
para establecer la metodologa adecuada para su realizacin, cuidando la funcionabilidad
del sistema y que el costo no sobrepase el presupuesto asignado.

Para poder aplicar los conocimientos anteriores es necesario conocer y reconocer el
proceso de evolucin del software, y determinar cundo hacer reingeniera o un tipo
mantenimiento en particular a un software en produccin, que es el siguiente tema a
desarrollar 3.2. Procesos de evolucin del software.

Actividad 1. Mantenimiento de software

El propsito de esta actividad es que identifiques los tipos de mantenimiento de software
y sus caractersticas. Para ello, tu Facilitador (a) te har llegar un caso, una vez que
cuentes con l, sigue estos pasos:

1. Identifica los requerimientos de mantenimiento de software:

2. Identifica el tipo de mantenimiento de software que aplicaras, segn los
requerimientos.

3. Identifica si hay algn requerimiento en el sistema de software que no justifique
un tipo de mantenimiento.

4. Identifica la frecuencia de mantenimiento y su relacin con el pronstico de los
costos.

5. Redacta tus conclusiones sealando la importancia de la aplicacin de los tipos
de mantenimiento seleccionados.

6. Guarda la actividad con el nombre DPSS_U3_A1_XXYZ. Sustituye las XX por
las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por
tu segundo apellido.

7. Enva la actividad a tu Facilitador(a) para recibir retroalimentacin mediante la
herramienta Tareas.

*No olvides consultar los criterios de evaluacin de las actividades de la unidad 3 para
que los consideres en el desarrollo de tu actividad.

3.2. Procesos de evolucin del software

Un software puesto en marcha no significa que se queda esttico y al paso del tiempo
todo sigue funcionando de igual forma. Los cambios son inevitables y si se desea que la
inversin en el sistema de software sea redituable, se tiene que invertir en su
mantenimiento.
Como bien se ha expuesto al principio de la unidad los cambios surgen cuando:
El software se utiliza.
Surgen cambios en el entorno de negocio.
Surgen errores y deben ser arreglados.
Nuevas arquitecturas de computadora y equipos se integran.
El rendimiento o la confiabilidad del sistema pueden y deben ser mejorados.

Las organizaciones se enfrentan al reto de poner en prctica y gestionar los cambios en
su sistema de software existente, por lo que hacen grandes inversiones en sus sistemas
de software y los consideran sus activos crticos del negocio, y para mantener el valor de
estos activos en la empresa, deben ser actualizados, para ello, la mayor parte del
presupuesto de software se dedica a la evolucin de los programas informticos
existentes en lugar de desarrollar un nuevo software.

A consecuencia de lo anterior se observa que el software cambia a lo largo de su vida til
y surge el concepto de la dinmica de evolucin del programa que es el estudio de los
procesos de cambio del sistema, derivado de los estudios de Lehman y Belady (1985), y
determinaron a la vez una serie de leyes que se aplican a todos los sistemas a medida
que evolucionan; tambin hay observaciones aplicables a los grandes sistemas que se
detallan en el siguiente subtema 3.2.1 Evolucin del software.

3.2.1. Evolucin del software

En la ingeniera de software, las leyes de la evolucin de software se refieren a una serie
de leyes que Lehman y Belady (1985) formularon en 1974 y 1996 con respecto a la
evolucin del software. Las leyes describen un equilibrio entre las fuerzas impulsoras de
nuevos desarrollos, por un lado, y fuerzas que frenan el progreso, por otro lado.

Al observar que la mayora del software est sujeto a cambios en el curso de su
existencia, los autores se propusieron determinar las leyes que estos cambios suelen
obedecer, o deben obedecer para que el software pueda sobrevivir.

Lehman y Belady (1985), publicaron en su artculo de 1980, la aplicacin de las leyes
mediante la distincin de tres categoras de software:
1. Un programa S se escribe de acuerdo con una especificacin exacta de lo que el
programa puede hacer.
2. Un programa P se escribe para implementar ciertos procedimientos que determinan
lo que el programa puede hacer.
3. Un programa E est escrito para llevar a cabo algn tipo de actividad en el mundo
real; su comportamiento est relacionado con el entorno en el que se ejecuta, y un
programa de este tipo tiene que adaptarse a las diferentes necesidades y
circunstancias del medio ambiente.

Las leyes siguientes se aplican a la ltima categora de sistemas, mencionadas
anteriormente.

Ley Descripcin
Cambio continuo Un programa que se utiliza en un entorno
real necesariamente debe cambiar o ser
cada vez menos til en ese entorno.
El aumento de la complejidad Es una consecuencia de la evolucin de los
cambios del programa, su estructura tiende
a ser ms compleja y se requieren recursos
adicionales, se aplican para la preservacin
y la simplificacin de la estructura.
Evolucin de sistemas grandes El programa es un proceso de auto-
regulacin, los atributos del sistema, tales
como el tamao, el tiempo entre las
versiones y el nmero de errores
notificados es aproximadamente invariante
para cada versin del sistema.
Estabilidad organizacional Durante la vida del programa, su ritmo de
desarrollo es aproximadamente constante
e independiente de los recursos dedicados
al desarrollo del sistema.
Conservacin de familiaridad Durante la vida til de un sistema, el
cambio incremental en cada versin es
aproximadamente constante.
El continuo crecimiento La funcionalidad ofrecida por los sistemas
tiene que aumentar continuamente para
mantener la satisfaccin del usuario.
Disminucin de la calidad La calidad de los sistemas suele decaer, a
menos que el sistema de software se
adapte a los cambios en su entorno
operativo.
Sistema de retroalimentacin El proceso de evolucin incorpora un
multiagente
3
como un sistema de
retroalimentacin, y hay que tratarlos como
sistemas de retroalimentacin para lograr
una mejora significativa del producto
Leyes y descripciones de Lehman y Belady (1985)

Las leyes como bien se observan, se aplican a un tipo de software en particular con
ciertas caractersticas, pero qu pasa con el resto de los sistemas de informacin que no
estn en la categora E?, aquellos sistemas que realizan tareas rutinarias,
administrativas, que no influenciados por el entorno de en el que se ejecuta.

Hay una propuesta de evolucin del software de Bennett y Rajlich (2000), que se muestra
en la siguiente imagen, que considera a todos los sistemas de software incluyendo a los
de programa E, y se basa en el principio que todos los sistemas tienen una versin alfa,
una etapa de madurez y una etapa de salida.

Evolucin del software basado en Bennett & Rajlich (2000) p.4

3
Sistema multiagente (SMA) es un sistema compuesto por mltiples agentes inteligentes que interactan
entre ellos
La propuesta consiste en separar la fase de "mantenimiento" en etapas de evolucin
seguida por una de mantenimiento.

Etapa 1 de la evolucin del software: versin alfa
Durante la versin alfa del sistema de software, a pesar de las diferentes pruebas, es
posible que se detecte la falta de algunas caractersticas, que se incorporarn durante
esta etapa tambin conocida como el desarrollo inicial.

Durante la versin alfa, tambin es posible vislumbrar posibles cambios o modificaciones
en el futuro. La mayora de las referencias en esta etapa se basan en escenarios o casos
de estudios. El desarrollo inicial genera un banco de conocimiento, tal como el
conocimiento de dominio de aplicacin, requisitos de los usuarios, las reglas de negocio,
las polticas, las soluciones, algoritmos, etctera, el conocimiento se determina como un
factor importante para la fase siguiente de la evolucin.

Una vez que la versin alfa se complet con xito, el sistema de software es puesto en
marcha, lo que conlleva a la necesidad de la evolucin como consecuencia del uso.

Etapa 2 de la evolucin del software: madurez
Esta etapa se origina por que los usuarios tienden a cambiar sus necesidades, as como
su propia percepcin de mejoras en el sistema de software.

Independientemente de lo anterior se sabe que la industria del software se enfrenta al reto
de cambios vertiginosos en el entorno, de ah que la meta de la evolucin sea la
adaptacin de la aplicacin a las siempre cambiantes necesidades de los usuarios y el
medio ambiente de trabajo.

El sistema de software ya en produccin, y durante los primeros das, los usuarios pueden
detectar fallas, y esas fallas se pueden corregir durante la etapa de madurez, basada en
requisitos ms especficos y precisos, debido al estudio de casos o escenarios.

Etapa 3 de la evolucin del software: salida
El software evoluciona continuamente mantenindose estable hasta que el sistema de
software ya no sea adaptable y se llega a la etapa de salida. Esta etapa se caracteriza por
que ya no hay soporte tcnico para el software en particular, sin embargo, el software
todava est en produccin.

Y por ltimo el sistema de software es dado de baja, se apaga o se interrumpe y los
usuarios son redireccionados hacia el nuevo sistema.

De esta forma se facilita la identificacin de las fases del sistema de software y se
determina a tiempo la posible salida de un sistema para ir preparando el nuevo,
considerando siempre que las necesidades del usuario sean satisfechas.

Conociendo las leyes de evolucin del software que aunque se aplican a un tipo en
particular de sistema de software y las etapas de evolucin, se tienen parmetros reales
para estar midiendo la funcionalidad de un sistema y determinar cuando ya no da ms y
sustituir a tiempo antes de perder ventaja competitiva.

Y antes de que el sistema sea obsoleto, ese es el momento en que entra la reingeniera
de sistemas para identificar el cdigo reutilizable y tomarlo de base para el nuevo
componente, mdulo o sistema, tema que se desarrollar a continuacin.

3.2.2. Reingeniera de sistemas

La ingeniera de sistemas analiza, disea y organiza los diversos elementos de un
sistema que se traduce en un producto, un servicio o una tecnologa para la
transformacin de informacin o control de la informacin, segn Pressman (2010).

Y como parte de la ingeniera del software, hay una tcnica que permiten abordar el
mantenimiento de manera que su impacto en coste dentro del ciclo de vida sea menor, y
es no es ms que la reingeniera de sistemas.

Y la reingeniera de sistemas se define como la modificacin de 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 evaluacin, Somerville (2011).

Segn las etapas de evolucin del software visto en el tema 3.2.1 Evolucin del software
se observa que despus de la madurez del sistema llega un momento en se torna
inestable debido a la serie correcciones, adaptaciones o mejoras que han podido surgir a
lo largo del tiempo.

Y antes que el sistema tenga reacciones inesperadas y afecte la produccin de la
empresa, o comience a dar un servicio intermitente, se aplica la tcnica de la reingeniera
al sistema con el fin de mejorarlo en cuanto a la calidad y mantenibilidad, sin alterar sus
especificaciones funcionales.

La imagen siguiente muestra las actividades que se desarrollan dentro de la reingeniera
de sistemas:

Modelo de proceso de la reingeniera de sistemas (Pressman, 2010)

Pressman (2010), describe cada elemento del modelo de la reingeniera de sistemas de la
siguiente forma:

Anlisis de Inventarios: El inventario es un modelo en una hoja de clculo que
contiene informacin detallada del tamao, edad, importancia para el negocio de
las aplicaciones activas. Los mdulos o componentes candidatos a la reingeniera
se ordenan en funcin de su importancia para el negocio, longevidad,
mantenibilidad actual y otros criterios localmente importantes. Se le asignan
recursos a las aplicaciones candidatas para el trabajo de reingeniera. El inventario
se deber revisar con cierta regularidad, porque el estado de los componentes
puede cambiar en funcin del tiempo y, como resultado, cambiarn las prioridades
para la reingeniera.

En la tabla siguiente la letra C, indica que el sistema en cuestin es candidata de
mantenimiento prximo.
Sistemas de
software
Funcionalidad Fecha de
produccin
Tamao
en SLOC
Importancia Fecha ltima
de
mantenimiento
Fecha del prximo
mantenimiento
Nivel
SIA
Misional
SIREL
Funcin
territorial estatal
01/01/2010 350, 000 Muy
importante
01/06/2013 01/06/2014 C
SIA
Contralora
Funcin de
control estatal
01/01/2013 175,000 Muy
importante
01/12/2013 01/06/2014 B
SIRECI Funcin
territorial
municipal
01/01/2011 285,000 Muy
importante
01/01/2013 01/01/2014 A
SIA
Misional
PGA
Funcin
municipal
01/01/2013 155,000 Importante 01/01/2014 01/12/2014 A
PNA Funcin
municipal
01/01/2009 255, 000 Importante 01/01/2010 01/01/2014 A
SICA Funcin
municipal
01/01/2010 223,568 Importante 01/01/2011 01/01/2013 C
Ejemplo de inventarios de aplicaciones
Reestructuracin de documentos: Se debe crear una documentacin breve y
comprensible que soporte el cdigo del componente que permita una actualizacin
gil y eficaz.

Ejemplo prlogo del programa como documentacin

Ingeniera inversa: Es el proceso de anlisis de un programa con el fin de crear una
representacin de programa con un nivel de abstraccin ms elevado que el cdigo
fuente, recupera el diseo original arquitectnico y de proceso, e informacin de los datos.

A continuacin se expone un ejemplo basado en Garca (2010), en donde en un sistema
de software de detecta un error de proteccin bsica y se busca reforzar tal, en pos de la
seguridad misma del sistema:
Los pasos de la ingeniera inversa aplicados en este caso, son:
Paso 1. Valorar el tipo de programa y cmo est protegido. La aplicacin a estudiar tiene
una proteccin excesivamente bsica, ante ello se prueba buscar un archivo para
comprobar el hecho.

A continuacin se observa una imagen que representa la visualizacin de su ejecucin
normal:

Ventana de error
Se comprueba que el programa busca un archivo, llamado archivo.opl. Si el
archivo no existe, el programa no se ejecuta y enva el mensaje File archivo.opl
not found. Es una proteccin bastante burda, puesto que existen multitud de
llamadas conocidas para buscar un archivo en el sistema.

Paso 2. Se ejecuta el programa OllyDbg para depurar el programa y se genera el
siguiente cuadro de dilogo:

Ventana de OllyDbg indicando que el programa esta comprimido

El programa OllyDbg indica que este programa est empaquetado. El empacamiento es
una proteccin frecuente y til. Sin embargo, existen herramientas que facilitan el trabajo
a cualquier usuario, malicioso o no, y que permite conocer detalles sobre las cabeceras
PE
4
.

Paso 3. Se abre el programa con PeId, y presenta la siguiente informacin:

4
Portable ejecutable

Ventana de PEID indicando la herramienta de empaquetado

Esta ventana ofrece informacin crucial y adems indica la mala proteccin del sistema: lo
primero que se observa es que efectivamente, el ejecutable est empacado con una
proteccin comercial, UPX, que incluso su utilera trae un desempacador.

Lo ideal hubiera sido proteger el programa con un empacador propio o, al menos, editar
las cabeceras para que PeId no pudiera mostrar el empacador utilizado o su versin

Paso 4. Se utiliza la herramienta Peld para desempacar el programa gracias a un plugin
que se ejecuta. El resultado de la ejecucin es dicho programa desempacado y con sus
instrucciones listas para ser ledas por el cracker
5
.

Paso 5. Se ejecuta el programa otra vez con OllyDbg y se presenta la siguiente ventana:

5
Persona que disea o programa cracks informticos, que sirven para modificar el comportamiento o
ampliar la funcionalidad del software o hardware original al que se aplican

Ventana de OllyDbg con el programa desempaquetado

Se observa que la advertencia anterior no aparece, lo que indica que el programa estaba,
efectivamente, empacado.

Se depura con el OllyDbg hasta que salte la ventana. Es decir, se depurar de atrs
hacia adelante, buscando el punto exacto en el que el programa se rompe, por decirlo de
alguna manera.

Paso 6. Se sabe que una ventana se muestra en Windows con un
registerWindowMessage, se busca ese comando y se inserta un punto de ruptura.

Se obtiene el siguiente resultado:

Ventana de OllyDbg con insercin de punto de ruptura

Est claro que si se llega a ese punto de ruptura depurando y la ventana no ha salido, es
muy posible que esa llamada sea la ventana de error; as que seguimos hacia atrs a ver
dnde se bifurca (si es que lo hace) el programa para terminar en esa ventana.

Paso 7. Se sigue depurando hacia atrs despus de establecer el punto de ruptura y se
encuentra una bifurcacin muy simple: un salto que se realiza en funcin de una
comparacin. Si se cambian las banderas de las instrucciones, nos encontramos con que
el comando de esa ventana se salta y podemos continuar sin mostrarla: parece que
hemos avanzado en la direccin correcta. Sin embargo, si seguimos hacia adelante en el
flujo, arroja este error:

Ventana del sistema con mensaje de error

El programa analizado, no slo valida que exista el archivo a buscar, sino que tambin
verifica su integridad. Esto es completamente lgico y es un buen sntoma de que al
menos, no se han equivocado al decidir la proteccin.

Se observa que, efectivamente, se llama al mismo comando que antes para mostrar otra
ventana. Se sigue depurando y se encuentra con, exactamente, lo mismo que antes: una
bifurcacin simple y llana en la que se pasa o no por la ventana de error dependiendo de
una bandera de verificacin. Se realiza el cambio, idntico al anterior.

Y se contina depurando el programa, y se comprueba que se muestra la ventana de
inicio de la aplicacin; de modo que se ha logrado corregir el ejecutable y saltar la
proteccin.

Paso 8. Despus de verificar que se ha corregido el cdigo para mejorar la validacin de
archivos, se guardan los cambios y se crea un ejecutable con OllyDbg.

Lo que ha hecho entonces a partir de los resultados llegar al cdigo y modificar para
mejorar un comportamiento del programa, a base de la ingeniera inversa.

Reestructuracin de cdigo: Se aplica a mdulos cuya codificacin no permite
comprenderlos, probarlos y mantenerlos.

El siguiente ejemplo presenta un mtodo que realiza una verificacin de das y meses.

public boolean verifica () { //Mtodo
if (dia < 1 || dia > 31)
return false;
if (mes < 1 || mes > 12)
return false;
// determina la cantidad de das del mes:
int diasMes = 0;
switch (mes) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12: diasMes = 31; break;
case 4:
case 6:
case 9:
case 11 : diasMes = 30; break;
case 2 : // verificacin de ao bisiesto
if ( (anio % 400 == 0) || ( (anio % 4 == 0) && (anio % 100 != 0) ) )
diasMes = 29;
else diasMes = 28;
break;
}
if (dia > diasMes)
return false;
else return true;
}

El mtodo verifica es poco legible, poco cohesivo, y difcil de mantener.

La solucin a la problemtica con el cdigo es la siguiente, es en la separacin de las
operaciones de verificacin para mejorar su legibilidad, la cohesin y su mantenimiento:

private int diasMes() { // Mtodo que verifica da y mes
int diasMes = 0;
switch (mes) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12: diasMes = 31; break;
case 4:
case 6:
case 9:
case 11 : diasMes = 30; break;
case 2 : if ( bisiesto() )//Mtodo que verifica si el ao es bisiesto
diasMes = 29;
else diasMes = 28;
break;}
return diasMes;}

private boolean bisiesto() { //mtodo que verifica si el mes es bisiesto
if ( (anio % 400 == 0) || ( (anio % 4 == 0) && (anio % 100 != 0) ) )
return true;
else return false; }

Y el mtodo verifica queda de la siguiente forma:
public boolean verifica () {
if (dia < 1 || dia > 31)
return false;
if (mes < 1 || mes > 12)
return false;
if (dia > diasMes())
return false;
else return true;
}

El mtodo verifica quedo pequeo, sencillo, fcil de depurar y mantener sobre todo fcil
de entender segn los criterios los criterios del cdigo de calidad.

Reestructuracin de datos, es una actividad de reingeniera a gran escala y comienza
con una actividad de ingeniera inversa, se analiza la arquitectura de datos actual con
minuciosidad y se definen los modelos de datos necesarios, se identifican los objetivos de
datos y los atributos, y despus se revisa la calidad de las estructuras de datos existentes.
Se verifican los cambios obtenidos de la revisin y se actualizan ya sea la arquitectura o
el cdigo mismo.

A continuacin se expone un ejemplo basado en Date (2001) pg.294.

Es necesario dividir la base de datos Varrel por VNC y VT, y se realiza la separacin,
para cuestiones de mejor control y proteccin de los datos

Cdigo de divisin de la base de datos Varrel

Se crea una vista de ambas bases para consultas
Vista de VNC y VT

Ahora se podrn hacer consultas sin poner en riesgos las tablas originales, gracias a esta
reestructuracin de datos.
Ingeniera avanzada, recupera la informacin de diseo a partir del software existente,
utilizando 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.

El procedimiento es parecido al de la ingeniera inversa pero buscando hacer crecer al
mdulo o sistema en s.

Las herramientas de apoyo para el proceso de reingeniera se encuentran:
IBM Rational Rose Enterprice, el cual es una suite de soluciones de software diseadas
para administrar el ciclo de vida de desarrollo de aplicaciones, para utilizar la suite se
requiere comprar la licencia de uso, pero el elemento de la suite Rational Application
Developer 9.0, tiene una versin de prueba por 30 das que puedes descargar en su sitio
oficial IBMTrial download: Rational Application Developer 9.0.

Softwarenaut, del grupo Software Composition (Instituto de ciencias de la computacin y
matemtica aplicada de la Universidad de Berna), que apoya el anlisis esttico y
evolutivo del cdigo fuente a travs de la visualizacin y exploracin, es una herramienta
libre de derechos que se puede utilizar y experimentar su uso en el sitio oficial SCG, esta
herramienta es utilizada tanto en el ciclo de vida del software como en el proceso de
mantenimiento del software y por ende en la reingeniera de sistema en el anlisis
evolutivo del cdigo.

Las actividades anteriores como parte de la reingeniera tratan de rescatar lo bueno de un
sistema que comienza a ser intermitente en su servicio y lo renuevan con la funcionalidad
original y otros agregados que le dan un valor, unos autores dicen que es proceso no es
barato y otros que ahorra en costos, lo cierto es que el viejo sistema es renovado por un
porcentaje aceptable de un posible nuevo.

La reingeniera de sistemas finalmente es una tcnica de mantenimiento, pero cmo
empezar?, dnde se observa la necesidad del mantenimiento?, y cul es el proceso?,
las respuestas a estas preguntas se desarrollarn en el siguiente tema 3.2.3.
Mantenimiento de sistemas existentes.

3.2.3. Mantenimiento de sistemas existentes

En el tema anterior 3.2.2 Reingeniera de sistemas, se detall la tcnica de la reingeniera
de sistemas como un conjunto de actividades que renuevan a un sistema que comienza a
ser decadente como forma de mantenimiento para renovarlo y que dure unos aos ms.

A continuacin se exponen las actividades que integran el proceso de mantenimiento

Proceso del mantenimiento del software (Basado en Stark, 1996)

El proceso comienza cuando un usuario identifica un cambio deseado o una entidad
externa se identifica como un problema potencial, por ejemplo, un cambio en los
requisitos o la necesidad de arreglar un funcionamiento inadecuado, un mdulo sin el
nivel de seguridad necesaria, tal problema se documenta en el reporte del problema.

Un analista en sitio en conjunto con el usuario revisa el informe de problemas, verifica
que efectivamente sea un problema para la integridad del sistema, comprueba contra los
informes de problemas conocidos para eliminar la duplicacin y para determinar si el
usuario entiende correctamente el sistema.

Si el problema es nuevo, y se identifica como tal el analista clasifica el informe de
problemas, ya sea como un problema del equipo de software, hardware o
comunicaciones.

En caso de que sea un problema de software, se genera un formulario de cambio de
software (FCS). El analista documenta con un nmero el FCS con la siguiente
informacin:
Formulario de cambio de software 1
Fechas de presentacin y aprobacin.
Mtodo actual.
Cambio propuesto.
Justificacin.
Estimaciones de recursos.

El analista enva el FCS a un comit de usuarios para su validacin y al ingeniero de
mantenimiento de software para la evaluacin independiente del requerimiento; el
ingeniero de mantenimiento evala el FCS con base en tres criterios:
El esfuerzo necesario para realizar el cambio.
Los recursos informticos necesarios.
El impacto sobre la calidad del servicio.

El ingeniero hace la estimacin del esfuerzo sobre la base de la taxonoma de los tipos de
cambio que es la siguiente:

Taxonoma de cambios de software (Basado en Stark, 1996)

Si el anlisis es 20 por ciento mayor o menor que las estimaciones del usuario original, el
usuario y el ingeniero se renen para resolver la diferencia. Lo anterior se realiza con el
fin de aclarar el requisito.
Computacionales
Operandos
incorrectos en
ecuacin.
Uso incorrecto de
parntesis.
Ecuacin
incorrecta o
inexacta.
Error de redondeo
o truncamiento.

Lgicos
Operando incorrectos
en una expresin
lgica.
Lgica fuera de
secuencia Variable
incorrecta.
Falta de prueba lgica
o condicin.
Numero de iteraciones
incorrectas en un ciclo.

De entrada
Formato incorrecto.
Lectura de entrada
desde ubicacin
incorrecta.
Fin de archivo no
encontrado o
encontrado
prematuramente.
Manejo de datos
Archivo de datos no
disponible.
Datos de referencia fuera de
lmites.
Datos de inicializacin.
Variables usados como
bandera o ndice no
ajustado apropiadamente.
Los datos no estn
apropiadamente definidos ni
dimensionados.
Error de subndices.
Salida
Datos escritos
en otra
ubicacin
diferente.
Formato
incorrecto.
Salida
incompleta o
prdida.
Salida confusa.

Interfaz
Interfaz de
Software/hardware.
Interfaz de usuario
Software.
Interfaz de base de
datos de software.
Operaciones
Cambio de software.
Configuracin del control.

Rendimiento
Tiempo lmite
excedido.
Lmite de
almacenamiento
excedido.
Cdigo o diseo
ineficiente.
Eficiencia de la red.

Especificacin
Interfaz del sistema.
Especificacin
incorrecta o
inadecuada.
Especificacin de
requerimientos
incorrecta o
inadecuada.
Entrenamiento
/manual de usuario
inadecuado.
Mejora
Mejora de funciones
existentes.
Mejora de interfaz.
El equipo de mantenimiento genera los FCS que afectan a los sistemas para los que no
son directamente responsables, pero con los que deben interactuar. Estos pueden ser el
resultado de las modificaciones tcnicas. Por ejemplo, si el sistema A est actualizando
su protocolo de comunicacin y se intercambia informacin con el sistema B, los usuarios
del sistema A puede generar una FCS para el sistema B con el fin de actualizar su
protocolo de comunicaciones.

El comit de usuario clasifica el FCS, ya sea como una modificacin o una correccin:
Una modificacin es un cambio que no es una parte de los requisitos actuales del
sistema.
Una correccin es la mejora de fallos.

El equipo de mantenimiento asigna tambin una prioridad a la FCS:
Emergencia si la FCS es necesaria para evitar tiempo de inactividad del sistema o
si los requisitos son de alta prioridad.
Urgente si se necesita la FCS en la prxima entrega de software para un proceso
en particular o para solucionar un problema que surgi como resultado de un
cambio en las operaciones.
Rutina para el resto de los FCS, por ejemplo, la conversin de unidades, cambios
en el valor por defecto, y para arreglar la impresin.

A continuacin, el FCS se pone en una cola de FCS para su incorporacin en la siguiente
versin del sistema que se libere. Los usuarios, el equipo de mantenimiento, y el equipo
de desarrollo de sistemas negocian el contenido de la versin.

Este proceso de planificacin y aprobacin incluye una revisin de varias mtricas:
Complejidad, fiabilidad del software, mantenibilidad del software, y la utilizacin de
recursos informticos.

El equipo de mantenimiento, revisa el plan de lanzamiento y programa la liberacin. El
equipo de desarrollo de software, termina el diseo, la programacin del cdigo, las
pruebas, la instalacin y garantiza la calidad de la liberacin con los requerimientos del
usuario.

En la siguiente tabla se muestran las mtricas que reflejan los cuatro productos de
informacin de la imagen del proceso de mantenimiento, sobre los cuales el equipo de
mantenimiento tiene control:
Validacin de los requerimientos.
Costo independiente.
Definicin de contenido de entrega.
Liberacin de implementacin.
Meta Cuestin Mtricas
Mxima
satisfaccin del
cliente
Cuntos problemas afectan al
cliente?
Atrasos en el cambio
actual
Confiabilidad de
software
Qu tiempo se tomar arreglar un
problema catalogado como de
emergencia o urgente?
Cambio del ciclo del
tiempo y fecha
Aprobado y con fecha
de aplicacin
Minimizar costo Cunto ser el coste de la entrega
del mantenimiento?
Coso por entrega
Cmo se asignan los costos? Costo por actividad
Qu tipo de cambios se estn
haciendo?
Numero de cambios por
tipo
Cunto esfuerzo es necesario por
tipo de cambio?
Das de staff utilizados
por tipo de cambios
Cuntos cambios no vlidos se
evalan?
Porcentaje de cambios
invlidos
Solicitudes cerradas
cada 3 meses
Minimizar la
agenda de
actividades
Qu tan difcil es la entrega de la
nueva versin?
Evaluacin de la
complejidad
Mantenibilidad del
software
Utilizacin de recursos
informticos
Cuntos cambios se hacen para
la entrega de contenido planeada?
Porcentaje de
contenidos de cambios
por entrega
Se cumple con la entrega
programada?
Porcentaje de entrega
en tiempo
Metas, cuestiones y mtricas del mantenimiento del software (basado en Stark, 1996)

En el presente tema, se ha desarrollado el proceso de mantenimiento del software, desde
que surge el requerimiento hasta que estos estn satisfechos en una nueva versin del
software que los contiene, cabe destacar que en este proceso muchos de requerimientos
son desechados por que no representan un problema real como de configuracin que con
los parmetros adecuados funcione adecuadamente o falta de capacitacin del usuario al
usar el modulo del sistema, se recalca entonces la importancia de validar los problemas
como problemas reales y darles solucin.

Las actividades descritas en los temas 3.1. Mantenimiento del software y 3.2. Procesos de
evolucin del software, hasta el momento, ms los costos y el estudio de viabilidad y
riesgos del mantenimiento de software deben estar englobadas en una metodologa de
gestin de mantenimiento que administre y documente cada proceso y actividad
involucradas en el mantenimiento con el fin de apegarse a los estndares establecidos
para ello en la norma ISO/IEC 14764 (2006), por lo que la gestin del mantenimiento se
desarrolla en el ltimo tema de la unidad 3.3 Gestin del mantenimiento.

Actividad 2. Procesos de evolucin del software

Esta actividad tiene la finalidad de que identifiques las fases de la evolucin de un
sistema de software y sus requerimientos de mantenimiento con base en un caso que te
har llegar tu Facilitador(a), una vez que cuentes con l sigue estos pasos:

1. Identifica las etapas de la evolucin del software.

2. Explica las fases de la evolucin detectadas, si le faltara alguna fase indicar cul
es y qu implicaciones tiene en el desarrollo y mantenimiento del software.

3. Redacta tus conclusiones sealando la importancia de la observancia de la
evolucin del software


5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin mediante la
herramienta Tareas.

*No olvides consultar los criterios de evaluacin de actividades de la unidad 3 para que
los consideres en el desarrollo de tu actividad.

3.3. Gestin del mantenimiento

Adolfo Crespo Mrquez, autor del libro el marco de gestin de mantenimiento dice que la
gestin del mantenimiento se refiere a todos los planes y actividades relacionadas con el
trabajo de mantenimiento y Ned Chapin menciona en el prlogo del libro Software
Maintenance Management de Alian (2008), que el libro contiene las mejores prcticas de
la gestin del mantenimiento del software.

Por lo que entonces la gestin del mantenimiento del software es la administracin del
conjunto de actividades y procesos necesarios para llevar a cabo las modificaciones
pertinentes que le permiten al sistema seguir siendo funcional sin desviarse de su
propsito original.

En la gua SWEBOK de Bourque y Fairley (2014), se establece que las actividades
previas al mantenimiento son aquellas que se realizan antes de la entrega del sistema de
software que incluyen la planificacin de las operaciones despus de la entrega as como
la determinacin de la mantenibilidad y logstica de las actividades de transicin de la
entrega.

Las actividades posteriores a la entrega, son aquellas que incluyen la modificacin del
software, la capacitacin, operacin y/o interfaz con una mesa de ayuda.

La gua presenta un desglose de tpicos de la gestin del mantenimiento de software de
los cuales muchos se han desarrollado en los temas anteriores. Para revisar los tpicos,
consulta el documento Tpicos de la gestin del mantenimiento de software.

La gua contempla todas las actividades previas y posteriores a la entrega de un producto
de software con respecto al mantenimiento, dejando muy claro, que es necesario una
adecuada administracin y control que es en si la gestin del mantenimiento del software,
para asegurar que el sistema sea funcional hasta donde sea posible, mientras tenga la
caracterstica de mantenibilidad.

A continuacin se detallar con ms detalle lo referente a los costos del mantenimiento y
el estudio de viabilidad y anlisis de riesgos.

3.3.1. Costos de un plan de mantenimiento de sistemas de software

Los costos del mantenimiento suelen ser altos porque cada modificacin, mejora o
requerimiento se aplica a todo el ciclo de vida del software y se requiere el personal
calificado para mantener la calidad del sistema de software.
Es necesario tener claro los tipos del mantenimiento para establecer un plan adecuado
del mantenimiento, considerar los factores que influyen para ser eficientes en el manejo
de los recursos, estos son:
Entorno de funcionamiento (hardware y software necesarios).
Entorno organizacional (polticas, competencia, proceso, producto y personal).

Respecto a la estabilidad del equipo, el costo del mantenimiento se reduce si el equipo de
desarrollo es el mismo, porque ya conoce el sistema ahorrando tiempo, dinero y esfuerzo.
Respecto a la responsabilidad contractual, el costo se reduce si se establece con los
desarrolladores del sistema, ya que genera incentivos para participar en el diseo de
cambios futuros.

Respecto al tiempo de vida y la estructura del sistema, en los sistemas con un
considerable tiempo de vida se observa una degradacin en su estructura original y se
vuelven difciles de entender y cambiar.

Costo del mantenimiento (Gmez de Len, 1998, p.36)

Sin embargo hay una serie de herramientas para estimar tanto el costo y el riesgo con el
fin de minimizarlos, sin sacrificar calidad por supuesto, lo siguiente es apegarnos al
presupuesto lo ms que se pueda y hacer los ajustes si se observan desviaciones.

Para establecer el costo del mantenimiento, la norma IEEE 14764, establece que lo ideal
es la combinacin de un modelo paramtrico y la experiencia.

Procedimiento que se desarrollar en el siguiente tema 3.3.2 Viabilidad y anlisis de
riesgo.

3.3.2. Viabilidad y anlisis de riesgo

Cuntas veces se cree que se tiene una gran idea y por todos los lados que se observa la
idea no se le ve ningn pero. Sin embargo para cualquier proyecto que implique inversin
y para cuestiones de mantenimiento de software es necesario realizar un estudio de
viabilidad y anlisis de riesgos para verificar si las modificaciones generadas de nuevos
requerimientos estn al alcance en cuestiones tcnicas, operativas y econmicas. La
informacin que arrojan los estudios son el costo, los riesgos inherentes, el tiempo
aproximado y el nmero de personas necesarias para el proyecto de mantenimiento.

El estudio debe hacerse cuando menos para una segunda opcin y al final seleccionar
una de las alternativas, este estudio es parte de la gestin del mantenimiento que se debe
documentar y presentar.

Viabilidad
Segn el diccionario de la Real Academia Espaola (2014), la palabra viabilidad significa:
Cualidad de viable
Condicin del camino o va por donde se puede transitar

La viabilidad en el mantenimiento del software, es el resultado de un estudio de
factibilidad que determina si un proyecto es viable o no, respecto a una serie de factores
que influyen en el tipo de mantenimiento, tratando de minimizar los costos y riesgos que
implica, los cuales se explican a continuacin. Los factores de anlisis de viabilidad que
se mencionan a continuacin, estn basados en la taxonoma de riesgos de Kuna (2008,
pg. 17).

Anlisis de riesgos
Segn el diccionario de la Real Academia Espaola (2014), la palabra riesgo significa:
Contingencia o proximidad de un dao.
Cada una de las contingencias que pueden ser objeto de un contrato de seguro.
Dicho de acometer una empresa o de celebrar un contrato: sometindose al influjo
de suerte o evento, sin poder reclamar por la accin de estos.
Estar expuesto a perderse o a no verificarse.

Los riesgos en el mantenimiento del software son:
Que el costo del mantenimiento sobrepase el costo del sistema mismo.
Que el mantenimiento haga perder mantenibilidad al sistema.
Que el mantenimiento acelere el retiro del sistema.
Que el mantenimiento afecte el funcionamiento general de los componentes del
sistema.

El anlisis de riesgos consiste entonces en analizar los riesgos y el impacto que podran
tener sobre el sistema de software y crear las estrategias para minimizar tal, apoyados en
el estudio de viabilidad la cual presenta cuando menos dos alternativas de solucin,
escogiendo la mejor alternativa.

El riesgo siempre va a existir, no se puede evitar, pero s minimizar y para eso hay
tcnicas de riesgos que se pueden aplicar considerando siempre la experiencia del
experto. Las tcnicas incluyen:
Toma de decisiones. La toma de decisiones es el proceso de anlisis y
escogencia entre diversas alternativas, para determinar un curso a seguir,
Chiavenato (2001).
El anlisis de Monte Carlo. Es una simulacin para tomar decisiones en la cual
las distribuciones de probabilidad describen ciertos elementos econmicos. Este
mtodo utiliza las distribuciones, que pueden ser empricas o tericas, para
generar resultados aleatorios, los cuales, a su vez, se combinan con los resultados
tcnico-econmicos de un estudio de factibilidad para tomar decisiones respecto al
proyecto. Mientras ms simulaciones se efecten, se espera que el resultado sea
ms confiable, Baca (2010).
Los rboles de decisin. Es un enfoque por medio del cual es posible realizar un
anlisis de como las decisiones tomadas en el presente pueden afectar las
decisiones en un futuro, ya que muchas decisiones tomadas en el tomadas en el
presente afectan las decisiones en presente no consideran las consecuencias a
largo plazo, por lo que se utiliza cuando es importante considerar las secuencias
de decisin y se conocen las probabilidades de que sucedan en el futuro los
eventos bajo anlisis, Baca (2010).

A continuacin se expone un ejemplo de aplicacin de los rboles de decisin (Morales,
2008), la gerencia de sistemas de informacin de una cadena de tiendas de zapatos se ha
planteado sustituir el software de punto de venta de las 14 cajas (8 tiendas) en las que
est instalado. Esto a pesar de que recientemente se ha renovado la licencia de uso del
software por un ao ms.

Las razones son variadas y van desde la escasa integracin que el software actual
permite con el sistema ERP de la empresa, hasta las dificultades para usarlo y para
entrenar al personal de nuevo ingreso.

El gerente no solo debe decidir si recurre a un sistema COTS soluciones listas para usar
que abundan en el mercado , si contrata un desarrollo externo (outsourcing) o si lleva a
cabo todo el desarrollo internamente, para lo cual necesitara ampliar su plantilla de
desarrolladores y probablemente contratar temporalmente a un administrador del
proyecto. Tambin debe justificar su decisin tomando en cuenta que ya se hizo la
inversin en licencias por un ao ms. El rbol de decisin siguiente plantea estas
alternativas:

rbol de decisin con tres alternativas fuente Morales (2008)

Se agregan los valores de cada rama en trminos de beneficios cuantificados.

rbol de decisin con valores y porcentaje de probabilidad de tres alternativas fuente Morales (2008)

Se determina el costo/beneficio de cada alternativa, se observa que el desarrollo interno
es la mejor opcin, realizando previamente el anlisis de costos de cada una,
probablemente mediante cotizaciones de productos y servicios, anlisis de personal a
contratar, modalidad de contratacin, etc.

La mejor opcin es la que presenta los mayores beneficios, como se observa en la
siguiente imagen.

rbol de decisin con costo/beneficio de tres alternativa, fuente Morales (2008)

Valor esperado de la informacin perfecta. Es la cantidad o comportamiento
esperado que se puede mejorar sabiendo de antemano que evento va a ocurrir
(Krajewski, 2000).

Cuando se tiene una serie de alternativas de solucin a un requerimiento, para
seleccionar la mejor alternativa, se realiza un proceso de evaluacin, minimizando el
impacto negativo que pudiera surgir en un momento dado, analizando los procedimientos
los pros y los contra mediante un diagrama de flujo como el siguiente:

Diagrama de flujo de seleccin de la mejor alternativa basado en la

Los pasos para desarrollar un estudio de viabilidad y anlisis de riesgos son los
siguientes:
1. Identificar los requerimientos
2. Identificar el tipo de mantenimiento
3. Identificar la solucin a tales requerimientos
4. Identificacin de riesgos y medidas de prevencin
5. Estudio de factibilidad operativa
6. Estudio de factibilidad tcnica
7. Estudio de factibilidad econmica
8. Estudio de factibilidad de tiempo
9. Estudio de factibilidad de derechos de autor
10. Seleccin de alternativas
11. Conclusiones del estudio de viabilidad y anlisis de riesgos

Los siguientes son documentos que se generan teniendo como base los resultados de los
estudios de factibilidad y respaldan la decisin final por una alternativa en particular.

Anexo A anlisis costo/beneficio
Anexo B punto de equilibrio
Anexo C anlisis de amortizacin
Anexo C cronograma de actividades
Anexo D mtrica aplicada

A continuacin se expone el siguiente ejemplo en relacin con un sistema de control de
activos fijos (SCAF) de la secretara de hacienda (SH) el cual tiene un ao de operacin y
por el cambio de administracin, se incorpor nuevo personal y el personal que ya se
encontraba laborando se distribuy a otras secretaras.

1. Identificar los requerimientos. Los nuevos usuarios detectan que al sistema de
control de activos le hace falta una serie de funcionalidades tales como:
El sistema debe reportar los activos fijos para su donacin al 100% de su periodo de
vida til.
Realizar la bitcora de cada activo fijo, desde su ingreso, hasta que este ya no sea
utilizado por el personal de la SH.

2. Identificar el tipo de mantenimiento. Segn los requerimientos generados por los
usuarios del sistema el tipo de mantenimiento es perfectivo, ya que busca obtener
nuevas funcionalidades o caractersticas no contempladas al momento de la
implementacin del software. El mantenimiento perfectivo adapta la aplicacin a los
requerimientos.

3. Identificar la solucin a tales requerimientos. Se ha analizado la situacin y se ha
determinado una solucin a los nuevos requerimientos de los usuarios.

El sistema debe permitir:
Generar de reportes de los activos fijos mediante un criterio de seleccin (estos
pueden ser: nmero de AF (activo fijo), descripcin, ubicacin, etc.).
Presentar una bitcora que refleje el historial de vida de cada activo fijo.
Registrar los movimientos de cada activo fijo (cuando se realiza un traslado o
cambio de usuario).
Generar un respaldo de los datos.

Se requiere integrar algunas restricciones del usuario tales como:
Debe de estar orientado a trabajar sobre una arquitectura de red centralizada y de
dominio pblico para los usuarios de departamento de sistemas de la secretara de
hacienda.
Que sea adaptado para plataforma Windows 8
Utilizar SQL Server 2012 como administrador de base de datos y visual Basic
2012 para el diseo de la interfaz.

Requisitos del sistema: Continuando con el ejemplo, para el desarrollo de los mdulos
del sistema y a su vez aprovechar las capacidades de informacin contenida dentro de su
registro de base de datos se determinaron lo siguiente mdulos como necesarios para
satisfacer los nuevos requerimientos y las condiciones tcnicas del servidor y el software
necesario para mantener la funcionabilidad del sistema:
Mdulos del sistema:
Actualizacin de datos
Generacin de reportes
Equipo de hardware:
Nmero de procesador E3-1125C
Cantidad de ncleos 4
Cantidad de subprocesos 8
Velocidad del reloj 2 GHz
Memoria cach L3 8 MB
Conjunto de instrucciones 64-bit
Extensiones de conjunto de instrucciones AVX, AES-NI
Disco Duro de 1 TB
Un quemador para respaldar la informacin
Software:
SQL Server y Visual Basic 2012
Sistema operativo windows 8

Las condiciones del local actual son: Cuenta con un sistema elctrico polarizado y
condiciones de temperatura entre 20C y 22C, para garantizar un mejor aprovechamiento
y seguridad del equipo tanto del hardware como de los usuarios.

4. Identificacin de riesgos y medidas de prevencin. Como parte del anlisis de
riesgos, se identificaron los riesgos despus de analizarlos se establecieron las
diferentes medidas para su control en el proyecto de mantenimiento del software del
SCAF, que se observan en la siguiente tabla:

Tipo de
riesgo
Riesgo Medidas preventivas Medidas correctivas
Riesgo del
proyecto
Ocurrencia de
siniestros.
Ninguna. Restablecer la
funcionalidad de los
equipos daados a la
mayor brevedad posible.
Planteamiento de
requerimientos
adicionales por
parte del usuario.
Establecer una buena
comunicacin con el
usuario de manera que
se establezcan todos los
parmetros antes de
concluir el estudio de
factibilidad.
Replantear el estudio de
factibilidad y hacerle notar
al usuario las
consecuencias de esta
medida.

Riesgo
tcnico
Presencia de virus. Instalar antivirus para
proteger las
computadoras y
actualizarlo
peridicamente.
Eliminar virus.
Equipos daados
durante el
desarrollo del
proyecto.
Realizar mantenimiento
preventivo para los
equipos peridicamente.
Realizar mantenimiento
correctivo.
Prdida de datos Configurar SQL Server
para que cree respaldos
peridicamente.

Crear respaldos del
sistema (base de datos y
programa), en cualquier
dispositivo de
almacenamiento de
datos.
Crear o ingresar
nuevamente los datos, en
caso de ser posible.
Riesgo
tecnolgico
Necesidad de una
interfaz propia para
el administrador
del sistema
informtico.
Establecer permisos
para cada usuario del
sistema.
Desarrollar la interfaz.
Riesgo
asociado con
el tamao y
Prdida de un
desarrollador de
software.
Contratar personal
confiable.
Buscar un nuevo personal.
Redistribuir las actividades.
experiencia
de la plantilla
del personal
Falta de
experiencia por
parte de los
desarrolladores en
el uso del software
a utilizar.
Garantizar que todos los
desarrolladores tengan
los conocimientos
necesarios para el
desarrollo del sistema.
Dar capacitacin intensiva
al personal.
Anlisis de riesgos, medidas preventivas y correctivas de mantenimiento del sistema de activos fijos

Como bien se observa los riesgos son claros pero tambin las medidas preventivas y
correctivas, y si bien no se podrn evitar si minimizar para no impactar de forma negativa
el proyecto de mantenimiento del software y parte fundamental de la gestin del
mantenimiento del software (reingeniera).

5. Estudio de factibilidad operativa. Con este anlisis de factibilidades se da inicio con
el estudio de viabilidad del proyecto de mantenimiento para el SCAF.

La factibilidad operativa, es la determinacin de la probabilidad de que un nuevo sistema
se use como se supone, y para eso es necesario el desarrollo de dos mdulos ms:
Actualizacin de datos
Generacin de reportes

Siguiendo la misma interfaz amigable que los mdulos existentes en el SCAF, de tal
forma que sin mucha dificultad el usuario pueda adaptarse y aprovechar al mximo las
facilidades que este brinde, ahorrando gran parte de su tiempo y permitiendo la
realizacin de otras actividades.

Se expone el ejemplo de un sistema que funcionar en red, al cual se acceder a travs
de la pgina oficial de la secretara de hacienda (www.sh.gob.mx). Los usuarios podrn
visualizar la informacin que ellos soliciten, sin embargo, no se les permitir alterar dicha
informacin si no cuenta con los permisos necesarios para realizar este proceso.

Al implantar este sistema en la secretara de hacienda, facilitar el trabajo del encargado
de llevar el control de los activos fijos, reduciendo el tiempo que invierte para la
elaboracin de los informes de inventario solicitado.

La secretaria de hacienda y sus directivos se encuentran anuentes a aceptar los cambios
y mejoras que el sistema ofrezca dentro del entorno de su organizacin, se llega a la
conclusin de que el sistema es factible operativamente, ya que se cuenta con una base
de desarrollo (sistema existente SCAF), la aceptacin de los directivos.

6. Estudio de factibilidad tcnica. El anlisis de factibilidad tcnica determina si el
equipo y software estn disponibles (o, en el caso del software, si puede desarrollarse) y
si existen las capacidades tcnicas requeridas por cada alternativa del diseo que se est
considerando.

A continuacin se realiza el estudio de factibilidad tcnica para el proyecto de
mantenimiento del SCAF.

Actualmente la Secretaria de Hacienda cuenta con 15 computadoras de las cuales 3
sern asignara a los desarrolladores del sistema. Estas se utilizan para ejecutar trmites
internos, estas se encuentran conectadas a la red local a la que se puede tener acceso a
travs de la Web, lo cual permite compartir/intercambiar informacin.

A continuacin se detalla una descripcin del equipo con que se cuenta:
Hardware
15 Computadoras Personales marca DELL, modelo OptiPlex GX200 con
siguientes caractersticas:
Procesador: Intel Pentium 4 de 2.4 GHz
Memoria RAM: 512 MB DDR
Disco Duro: 1HDD de 40 GB
Monitor: 15
Teclado: Standard PS 2
Mouse: OMEGA PS 2
DVD-RW: LG
Unidad de Disco Flexible 3
Estabilizador ProNet de1000 W
2 Impresoras:
HP Color LaserJet 8550-PS (Compartida para todos los usuarios de la red
local).
Canon Bubblet -Jet S450
Matricial EPSON LQ 570-e (Ubicada en Recepcin)

Plataforma de software actual
Sistema Operativo: MS Windows XP Pro
MS Windows 2000 Pro + Service Pack 4
Programas instalados:
MS Office XP
DoNet
SQL Server EnterPrice Manager + Service Pack 4
Visual Basic 6.0
WinZip 9.0
WinRar 3.3
Adobe Acrobat 6.0
Nero Burning ROM 6.0.0.9

Para cumplir con los requerimientos del SCAF es necesario hacer las siguientes
adquisiciones:
El servidor
El sistema operativo Windows 8
Visual Basic 2012
SQL Server 2012

Por lo que hay que hacer el presupuesto de las nuevas adquisiciones, sin embargo se
considera que es un paso lgico en la actualizacin del equipo de cmputo y software y
que se tendr un periodo de vida til de 5 aos antes de pensar en cambiar nuevamente
la tecnologa.

7. Estudio de factibilidad econmica. La factibilidad econmica incluye el anlisis de
costos y beneficios asociados con cada alternativa del proyecto. Todos los costos y
beneficios de adquirir y operar cada alternativa se identifican y se hace una comparacin
de ellos.

Ejemplo de alternativa 1: SQL Server y Visual Basic 2012
Costo de desarrollo del sistema
El personal de desarrollo ha sido contratado con los conocimientos necesarios en
programacin y administracin de servidores.
2 desarrolladores 750.00 al mes
1 Analista 750.00 al mes

Para el desarrollo de la factibilidad econmica se utilizar la herramienta libre
COCOMO II.2000.4 creada por alumnos de la Universidad del Sur de California USC
(por sus siglas en ingles University of Southern California), disponible en su sitio oficial,
para diferentes plataformas.


Mdulos para el proyecto alternativa 1

Frmula del costo real y el tiempo real:

Costo real = 226.52+4*283.15+353/6
Costo real = 285.35
Tiempo real = 3.2+4*3.5+3.7/6
Tiempo real= 3.48

Equipo de cmputo y software:
El servidor 726.00
El sistema operativo Windows 8 120.00
Visual Basic 2012 438.00
SQL Server 2012 859.00
Insumos:
2 Paquetes de papel $ 6.00
1 Cajas de lapiceros $ 3.00
6 Lpiz mecnicos $ 8.00
10 Cajas de minas 0.5 $ 6.00
Llamadas telefnicas $ 40.00
Impresin $ 20.00
Costo mensual de operacin del sistema
Costos variables
1 Paquete de papel $ 3.00
1 Cartucho de tinta negra $ 20.00
1 Cartucho de tinta color $ 35.00

La programacin de las fases qued de la siguiente forma en la ventana Phase
distribution Project Overall del programa COCOMO II:

Ventana de distribucin de fases del proyecto en general para la alternativa 1
Ejemplo de alternativa 2: SQL Server 2012 y .Net
Costo de desarrollo del sistema
Construccin
El personal de desarrollo ha sido contratado con los conocimientos necesarios en
programacin y administracin de servidores.
2 desarrolladores 790.00 al mes
1 Analista 790.00 al mes

Mdulos para el proyecto alternativa 2

Frmula del costo real y tiempo real

Costo real = 196.22+4*245.28+306.6/6
Costo real = 247.32
Tiempo real = 3.3+4*3.5+3.8/6
Tiempo real= 3.51
Insumos:
1 Cajas de lapiceros $ 3.00
6 Lpiz mecnicos $ 8.00
10 Cajas de minas 0.5 $ 6.00
Llamadas telefnicas $ 40.00
Impresin $ 20.00
Costo mensual de operacin del sistema
Costos Variables
1 Cartucho de tinta Negro $ 20.00
1 Cartucho de tinta Color $ 35.00

La programacin de las fases se integr de la siguiente forma:

Ventana de distribucin de fases del proyecto en general para la alternativa 2
Los beneficios de la integracin de dos mdulos ms al sistema de control de activos
son:
Tangibles:
Disminucin de errores.
Mejor utilizacin del tiempo disponible.
Reduccin de los costos variables.
Manejo adecuado de la informacin.
Intangibles:
Satisfaccin del cliente
Mejora la toma de decisin.

Los costos estn a la vista, sin embargo la decisin de una alternativa se maneja como un
paso, que se explica ms adelante.

8. Estudio de factibilidad de tiempo. El estudio de factibilidad de tiempo se refiere a la
estimacin del tiempo necesario para cada fase del proyecto de mantenimiento del
software, contiene la planificacin de lo estimado para la realizacin de cada una de las
tareas que deben llevarse a cabo para conseguir los objetivos del proyecto, la cual se
contabiliz en un aproximado de 3.5 meses hbiles (ver alternativa 2 tiempo real) de
trabajo desde el inicio del proyecto hasta su conclusin pasando por desarrollo.

Es de inters de los desarrolladores del proyecto tener una visin amplia de lo que es
todo el entorno del problema y sus posibles soluciones.

9. Estudio de factibilidad derechos de autor. Este estudio sirve para verificar que no se
violen los derechos de autor y se cometa una infraccin por omisin, en el presente
proyecto se respeta y se hace cumplir la ley de los derechos de autor cumpliendo con
todas las prerrogativas que dicha ley establece, con el objetivo de evitar multas o
demandas a la hora de implementar el sistema. El departamento de sistemas adquirir
los permisos de derechos de autor de cada software que se mencionaron en los
requerimientos del sistema por la compra de las licencias.

Una vez aprobado el proyecto SCAF, tendr los derechos de establecer sus clusulas de
contratacin de los desarrolladores del sistema.

10. Seleccin de alternativa. La seleccin de la mejor alternativa es una accin del
anlisis de riesgos y este como parte del estudio de viabilidad, que seleccionar
precisamente la mejor alternativa despus de analizar concienzudamente los reportes de
factibilidad y los anlisis de costo/beneficio, ya que esta accin infiere directamente en
que el proyecto se logre satisfactoriamente en tiempo, costo y funcionabilidad, las
acciones anteriores son parte de la gestin del mantenimiento.

Para poder realizar la seleccin de alternativa se tom en cuenta tanto los requerimientos
del usuario como los requerimientos del sistema, por tal motivo se ha seleccionado la
alternativa 1, ya que ofrece seguridad, adems, se puede desarrollar una interfaz grfica
sencilla y agradable para el usuario, mayor capacidad de almacenamiento de datos.

Alternativa Descripcin Costo de la inversin (en
trminos monetarios)
1: SQL Server con Visual
Basic
Esta alternativa pretende
utilizar como motor de base
de datos SQL Server, el
cual es una herramienta
diseada para el manejo de
Bases de datos y para el
diseo de interfaz Visual
Basic
$ 3, 220.00
2: SQL Server con .NET Esta alternativa pretende
utilizar como motor de base
de datos SQL Server y .Net
como diseador de interfaz
grfica.
$ 3, 373.00
Anlisis de alternativas (basado en PAE, 2013)

Alternativa Ventajas Desventajas
1 SQL Server con Visual
Basic
Precio
Presenta interfaces que
hacen ms fcil la labor
de implementacin y
desarrollo.
Genera archivo
ejecutable para que los
usuarios no manipulen
el cdigo del programa.

Limitacin en el enlace
de bases de datos que
no incluyan su versin.
Tendr que realizarse la
conversin
manualmente.
Se pueden desarrollar
aplicaciones que
funcionen en red, pero
no cuenta con los
suficientes soportes.
2 SQL Server con .NET Mayor seguridad.
Mucha flexibilidad en la
manipulacin de bases
de datos.
DoNet permite la
creacin de un archivo
Precio, puesto que se
pagar ms a los
desarrolladores que
trabajen en esta
aplicacin.
DoNet presenta un
ejecutable.
Tanto Microsoft SQL
Server como DoNet son
lenguajes diseados
especialmente para
trabajar en red
ofreciendo suficientes
soportes para su
implementacin.
grado de complejidad
mayor que Visual Basic
Comparacin de alternativas (basado en PAE, 2013)

Anexo A anlisis del costo/beneficio
El anlisis del costo/beneficio es un comparativo de las factibilidades donde se debe
observar siempre que el beneficio es mayor que el costo ya si es al contrario el esfuerzo
del proyecto no vale pena y se evita un gasto innecesario.
Es importante hacer un comparativo de cules son los gastos y costes actuales y cules
seran despus de implementarse los dos mdulos propuestos.
Y el anlisis de coste/beneficio proporciona una medida de los costes en que se incurre
en la realizacin de un proyecto y compara dicha previsin de costes con los beneficios
esperados de la realizacin de dicho proyecto.
Segn la siguiente tabla se observa una disminucin de gastos y costes y un aumento
considerable de los beneficios.
Detalles Actual operacin del
SCAF
Operacin del SCAF con
dos mdulos mas
Horas extras $ 180.00 $ 0.00
Gastos de oficina $ 130.00 $ 58.00
Total $ 310.00 $ 58.00
Beneficio $ 0.00 $ 252.00
Anlisis costo-beneficio (basado en PAE, 2013)

El resultado plasmado en la tabla anterior, seala que la implementacin de los dos
mdulos propuestos como parte del mantenimiento del sistema de software es
beneficiosa.

Anexo B punto de equilibrio
Grfico de punto de equilibrio muestra el punto en que los costes y los beneficios son
iguales, para de ah en adelante observar un crecimiento de beneficios a lo largo de un
periodo de tiempo.

Punto de equilibrio costes/beneficios

Anexo C anlisis de amortizacin
La frmula del valor presente es la siguiente:

Con una tasa de amortizacin del 12%
La tasa de amortizacin es el factor en el cual el valor del sistema se va depreciando a lo
largo de un periodo determinado.

Costo del sistema
3220
Frmula 1/(1+.12)^1 1/(1+.12)^2 1/(1+.12)^3 1/(1+.12)^4
Costo operacin y
mantenimiento -696
Aplicacin de la frmula
Factor de amortizacin 0.893 0.797 0.712 0.636

Aplicacin del factor -696*0.893 -696*0.797 -696*.712 -696*.636
Costo operacin y
mantenimiento real

-621.429 -554.847 -495.399 -442.321

Costo acumulado
-3220-
621.43
-3841.43-
554.84 -4396.28-495.40 -4891.67-442.32

-3220 -3841.43 -4396.28 -4891.67 -5334.00
Tabla de referencia del anlisis de amortizacin
En los datos de la siguiente tabla se observa el comportamiento de dos variables
importantes a considerar, los costes acumulados en tiempo ajustado a lo largo del tiempo
de vida que va disminuyendo ao con ao y los beneficios acumulados en tiempo
ajustado a lo largo del tiempo de vida que va aumentando:
Descripcin del flujo de
efectivo
Ao 0 Ao 1 Ao 2 Ao 3 Ao 4
Costo de anlisis, diseo e
implementacin
-3,220.00
Costo de operacin y
mantenimiento
-696.00 -696.00 -696.00 -696.00
Factor de descuento al 12% 1.00 0.893 0.797 0.712 0.636
Coste en tiempo ajustado
(ajustado al valor actual)
-3,220 -621.528 -554.712 -495.552 -442.656
Costes acumulados en tiempo
ajustados a lo largo del tiempo de
vida
-3,220 -
3,841.52
-4,396.24 -4,950.95 -5,393.60
Beneficios obtenidos del
funcionamiento del nuevo
sistema
0 3,024.00 3,024.00 3,024.00 3,024.00
Factor de descuento al 12% 1.000 0.893 0.797 0.712 0.636
Beneficios en tiempo ajustado
(valor real o actual)
0 2,700.43
2
2,410.128 2,153.088 1,923.264
Beneficios acumulados en tiempo
ajustado a lo largo del tiempo de
vida
0 2,700.43
2
5,110.56 7,263.648 9,186.912
Costes + beneficios acumulados
en tiempo ajustado a lo largo del
tiempo de vida
-3,220 -
1,141.08
8
714.32 2,312.698 3,793.312
Periodo de amortizacin en tiempo ajustado |------
---------------------|
2 aos
Anlisis de amortizacin (basado en Bassi, 2003, pg. 3)

Anexo D cronograma de actividades
La grafica muestra la planeacin en tiempos del proyecto de cada una de las fases que
comprende la realizacin del proyecto de mantenimiento del software.

Diagrama de Gantt de actividades
Anexo E mtrica utilizada. La mtrica utilizada que fue el punto de fusin por que mide
la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para
la construccin y explotacin del software, esta mtrica es un mtodo utilizado en
ingeniera del software para medir el tamao del software, definida por Allan Albrecht
(1979), se aplica en cualquiera de las fases de vida del software, desde el diseo inicial
hasta la implementacin y mantenimiento.

La determinacin del tamao del software es un parmetro necesario en el estudio de
viabilidad y anlisis de riesgo para la obtencin de los reportes de factibilidad
correspondientes como parte de la gestin del mantenimiento.

Mtrica punto de fusin. Se calculan los puntos de funcin para los dos mdulos a
agregar, en el mdulo Actualizacin_Datos, se tienen los siguientes puntos de fusin:
Entradas
Salidas
Archivos
Interfaces
Consultas

Calculo de los puntos de fusin mdulo Actualizacin_datos
Como se observa un estudio de factibilidad es un estudio detallado y profundo tanto de
factores, elementos, esfuerzos y costos para determinar si una alternativa es viable o no
y escoger la mejor con la intensin de minimizar posibles impactos negativos en el
proyecto de mantenimiento del software

Conclusiones del estudio de factibilidad
Con este estudio de factibilidad se observ que el capital invertido por el SCAF para el
manejo de la informacin de sus activos fijos es rentable y factible ya que la recuperacin
es prcticamente a corto plazo y sus beneficios son amplios.

Al seleccionar la mejor de las dos alternativas analizadas, se garantiza que el proyecto se
realice en tiempo y forma y de acuerdo a un presupuesto, lo anterior como parte
fundamental del anlisis de viabilidad y riesgos y esta como parte esencial de la gestin
del mantenimiento del software.

Al implementar este proyecto se conseguir lo siguiente.
Informacin actualizada disponible en todo momento.
Registros altamente organizados.
Reducir el tiempo de respuesta a las diferentes instancias a las que el SCA enva
el reporte general de todos sus activos fijos.
Desvos de gastos monetarios hacia otras reas en las cuales se requiere ms
presupuesto.

En conclusin, se puede decir que el anlisis de viabilidad y riesgos en la etapa de
mantenimiento de un sistema de software es un elemento que determina si el proyecto de
mantenimiento se realiza o no, en eso radica su importancia en no correr riesgos
innecesarios y si se corren que sean mnimos y son mnimos que sean controlables sus
posibles efectos negativos, de tal forma que el proyecto de mantenimiento se realice en
tiempo, forma y presupuesto.

Actividad 3. Gestin del mantenimiento

Esta actividad tiene la finalidad de que analices la viabilidad y riesgos de un proyecto de
mantenimiento de software mediante un caso que te har llegar tu Facilitador(a). Una
vez que cuentes con l, realiza los siguientes pasos:

1. Identifica las modificaciones necesarias al sistema.

2. Elabora un documento, con el caso propuesto y desarrolla un estudio de
viabilidad y riesgos de las modificaciones a realizar al sistema.

3. Redacta tus conclusiones en torno a la importancia del estudio de viabilidad y
riesgos en el mantenimiento de software.


5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin mediante la
herramienta Base de datos.

6. Comenta la actividad de uno de tus compaeros(as), como mnimo. Recuerda
que tus comentarios no deben ser agresivos, sino constructivos.

*No olvides consultar los criterios de evaluacin de actividades de la unidad 3 para que
los consideres en el desarrollo de tu actividad.

Autoevaluacin

Realiza la autoevaluacin con el fin de que puedas analizar el avance que has tenido y
detectar las reas de oportunidad respecto al estudio de la tercera unidad.

Evidencia de aprendizaje. Informe de viabilidad y anlisis de riesgo de
un proyecto de mantenimiento de software

El propsito de la evidencia es que elabores un informe de viabilidad y anlisis de
riesgos de un proyecto de mantenimiento de un producto de software, que deber
fundamentarse en el anlisis de los planteamientos que te har llegar tu Facilitador(a),
una vez que cuentes con ellos:

1. Identifica el tipo de mantenimiento al que corresponda el caso.

2. Identifica las fases de evolucin del mantenimiento por las cuales el sistema ha
pasado.

3. Realiza el estudio de viabilidad y costos con base en los requerimientos.

4. Incluye tus conclusiones de la evidencia en torno a la importancia del informe de
viabilidad y anlisis de riesgos de un proyecto de mantenimiento de software.

5. Al finalizar guarda tu evidencia con la nomenclatura DPSS_U3_EA_XXYZ.
Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu
primer apellido y la Z por tu segundo apellido y envala a tu Facilitador(a)
mediante el Portafolio de evidencias.

* Consulta los criterios de evaluacin en el documento EA. Rbrica de evaluacin de la
unidad 3 para que los consideres en el desarrollo de tu evidencia.

Autorreflexiones

Adems de enviar tu Evidencia de aprendizaje, ingresa al foro Preguntas de
Autorreflexin y consulta las preguntas que tu Facilitador(a) presente, a partir de ellas
elabora tu Autorreflexin en un archivo de texto llamado DPSS_U3_ATR_XXYZ.

Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad

Durante la presente unidad se han abordado las nociones bsicas del mantenimiento
identificando los tipos de mantenimiento as como realizando pronsticos de los prximos
mantenimientos del software. Es importante reconocer la evolucin inevitable del
software, para poder aplicar la tcnica de mantenimiento tal como la reingeniera de
sistemas y el proceso de manteamiento a un sistema existente y concordar en que las
actividades propias del mantenimiento deben estar englobadas en una gestin como tal
para determinar los costos del mantenimiento a travs de un estudio de viabilidad y
anlisis de riesgos.

Grandes empresas hoy en da dedicadas al desarrollo de software tienen claro la
importancia del seguimiento de las normas de calidad para aseguramiento de la misma en
los productos desarrollados, que las pruebas no son un tema a tomar a la ligera ya que si
las aplicamos en los momentos correspondientes se garantiza un producto con un
porcentaje mnimo de errores que impacten en la funcionalidad del sistema de software, y
el mantenimiento considerado por mucho tiempo como un proceso necesario pero no con
la importancia que cobra hoy en da donde una buena planeacin del mantenimiento
garantiza una buena evolucin del sistema de software mantenindolo funcional por
mucho ms tiempo.

Sin embargo hay muchas otras que por falta de especialistas ocupan a los programadores
para las diferentes actividades antes descritas, programacin, pruebas y mantenimiento y
eso resulta en un trabajo a medias, clientes inconformes, sistemas inestables.

Es un reto el que se tiene como profesionista, desde especializarse y hacer una carrera
profesional en la empresa, es por eso esta materia ha presentado un panorama de estos
tpicos el cual tiene un amplio horizonte de desarrollo.

Es cierto que muchos tienen la experiencia pero es necesario certificarla para asegurar
trabajos de alta calidad y de acuerdo a las exigencias actuales.

Lo anterior genera las siguientes interrogantes:
Es necesario certificarse? Valdr la pena certificarse? Qu empresas tienen la
capacidad de certificar? La certificacin efectivamente garantizar un trabajo de
calidad?

Las respuestas las obtendrs en el camino de tu vida profesional.

En Mxico, hay mucho camino por recorrer aun, tanto en investigacin como en la
profesionalizacin, ya sea que nos inclinemos por una opcin o la otra, es importante
desempear siempre el mejor papel.

Para saber ms

Hoy en da en Mxico, en una industria creciente que ocupa tanto maquinaria, equipo de
cmputo y software, el mantenimiento ha cobrado gran importancia se cuenta con varias
empresas dedicadas al mantenimiento que ofrece el servicio outsourcing y la venta de
sistemas de gestin del mantenimiento tales como PSL, para saber ms sobre este
sistema de gestin visitita los siguientes sitios:

http://www.pslcorp.com.mx
http://www.informaticamilenium.com.mx
http://www.mpsoftware.com.mx/#

En Mxico se cuenta con la NMX-I-059/02-NYCE-2011, la cual es una norma mexicana
enfocada a las organizaciones que se dedican al desarrollo y mantenimiento de software;
en la que se establecen los requisitos de conformidad para el mtodo de verificacin del
modelo de procesos para la industria de software (MoProSoft), puedes consultar ms
sobre este modelo de procesos MoProSoft:

http://www.moprosoft.com.mx/

Particularmente el proceso de operacin (OPE) considera para el desarrollo y
mantenimiento de software (DMS) que:
El propsito de desarrollo y mantenimiento de software es la realizacin
sistemtica de las actividades de obtencin de requisitos, anlisis, diseo,
construccin, integracin y pruebas de productos de software nuevo o modificado
cumpliendo con los requisitos especificados.

Ya hay normas establecidas en el pas que estn de acuerdo con las normas
internacionales que guan el desarrollo correcto del proceso de mantenimiento de
software, hace falta personal capacitado y certificado que d respuesta a un
mercado demandante y creciente.

Para saber ms sobre el proceso de operacin OPE, consulta su sitio oficial:
http://ope.mx/

Fuentes de consulta

Abernethy, R. (2006). The new Weibull Handbook. 5 edicin. Florida, EU. Publicado y
distribuido por Robert B. Abernethy. ISBN 0965306232.

Abran, C. y Moore J. (2004). Guide to the Software Engineering Body of Knowledge.
EU.[En lnea]. http://www.computer.org/portal/web/swebok/htmlformat

Alain,A., Alain, A. (2008). Software Maintenance Management: Evaluation and
Continuous Improvement. Editorial Jhon Wiley & Sons. New Jersey. ISBN
9780470147078

Albrecht, A. (1979). Measuring Application Development Productivity.Conference on
application Development. October 1979, Montana California.

Baca, G. (2010). Evaluacin de proyectos. 6.Edicion. Mc.Graw Hill. Mxico. ISBN
9786071502605

Boehm, B. (2000). Software Cost Estimation with COCOCOMO II.Editorial Prentice
Hall. EU. ISBN-10: 0130266922

Bourque, P. y Fairley, R. (2014). Guide to the software engineering body of knowledge
version 3.0.IEEE Computer Society. [En lnea]
http://www.computer.org/portal/web/swebok/v3guide

Chiavenato, I.(2001).Administracin Proceso Administrativo. 3 Edicin. McGraw Hill.
Bogota, Colombia. ISBN 9789584101617

Date, C.(2001). Introduccin a los Sistema de bases de datos. Pearson Prentice Hall.
Estados Unidos. ISBN 9694444192

FHWA CA Divisin. (2009) Guidebook for ITS v3.0.EU. [En lnea].
http://www.fhwa.dot.gov/cadiv/segb/views/document/index.cfm

Foster, J., (1993). Thesis Cost Factors in Software Maintenance. University of Durham
School of Engineering and Computer Science. [En lnea].
http://www.jsjf.demon.co.uk/thesis/Thesis.html#QQ1-1-86

Gallego, JC., (2010). Mantenimiento de sistemas microinformticos. Editex
S.A..Amdrid. ISBN ebook 97884977167.

Garca Martn, D., (2010). Ingeniera inversa: Modifica un programa.

Gmez de Len, F. C., (1998). Tecnologa del mantenimiento industrial. Murcia:
Universidad de Murcia

Gmez, Julia.(2014). Gua Prctica de Estimacin y Medicin de Proyectos Software:
Por qu?, Para qu? y Cmo?. ASIN: B00JJ6OGKG

Henry, S. & Wakem, S.(1988). Predicting Maintainability with Software Quality Metrics. .
[En lnea]. http://eprints.cs.vt.edu/archive/00000131/

IEEE Standars (2014). 12207-2008-ISO/IEC/IEEE Standard for Systems and Software
Engineering-Software Life Cycle Processes . [En lnea]
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4475826&url=http%3A%2F%2Fi
eeexplore.ieee.org%2Fiel5%2F4475822%2F4475825%2F04475826.pdf%3Farnumber
%3D4475826

ISO/IEC 14764 (2006). Standard for Software Engineering - Software Life Cycle
Processes - Maintenance. [En lnea] http://standards.ieee.org/findstds/standard/14764-
2006.html

ISO (2001). ISO/IEC TR 9126-1. Software engineering: Product quality. Part 1: Quality
model. Switzerland: ISO copyright office.

IEEE Standard (2014). 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology . [En lnea] https://standards.ieee.org/findstds/standard/610.12-1990.html

Kuna, H. (2008). Plan de Riesgos para la implementacin, desarrollo y mantenimiento
de componentes de Web 2.0 en Bibliotecas, caso de estudio en una Biblioteca
Especializada. 6ta Jornada sobre la Biblioteca Digital Universitaria JBDU 2008. [En
lnea].
http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA%20MISION
ES%20RIESGOS%20Web2.0.pdf

Krajewski, L.; Ritzman, L. (2000). Administracin de operaciones Estratgicas y
Anlisis. Pearson Educacin. 5.Edicion. Mxico. ISBN 9684444117

Lakey, Peter, y otros (2014). Software Reliability Assurance Handbook. Rome
Laboratory. Universidad del estado de Colorado, E.U. [En lnea].
http://www.cs.colostate.edu/~cs530/rh/

Lehman, M., Belady,L. (1985). Program Evolution. Process Software Change. Vol.27 in
A.P.I.C. Studies in Data Processing. Texas E.U. Editorial Fraser Duncan and M. J. R.
Shave.

Lientz, B.P. y Swanson, E.(1978). Characteristics of Application Software Maintenance.
Communications of the ACM, pp. 466-471.

Llorens, J. (2005) Gerencia de Proyectos de Tecnologa de Informacin. 1 Edicin.
Venezuela: Editorial CEC. ISBN 9803881868.

Morales, L.(2008). Anlisis Por rboles de Decisin Para Eleccin de un Curso de
Accin Empresarial Sobre Desarrollo Interno, Contratacin o COTS. [En lnea]
http://www.ingenieriasimple.com/problemas/EjemploArbolesDecision.pdf

Newport, John.(1994). Avionic Systems Design. Press Inc. Florida, E.U. ISBN
0849324653

Pressman, R. S., (2010). Software Engineering: A Practitioner's Approach. New York:
McGraw-Hill Higher Education. [En lnea] https://docs.google.com/file/d/0B9G5Hj-
V6tdJTWZCZzVoUDNudUk/edit?pli=1

Sommerville, I., (2011). Ingeniera del Software. 9 Edicin. Espaa: Pearson
Educacin. ISBN 9786073206037

Stark, G. (1996). Measurements for managing Software Maintenance. Software
Maintenance 1996, Procedings Internacional Conference on. ISBN 0818676779. [En
lnea] http://www.serena.com/docs/agile/papers/Measurements-to-Manage-Software-
Maintenance.pdf.

Tecnologas de la informacin y ms (2008). El verdadero costo del mantenimiento del
software. [En lnea] http://webcool.wordpress.com/2008/02/22/el-verdadero-costo-del-
mantenimiento-del-software/

UDELAR Universidad de la Repblica de Uruguay (2003). Casos de estudio. FCEA
Facultad de Ciencias Econmicas y de Administracin. Ctedra introduccin a la
computacin. [En lnea] www.ccee.edu.uy/ensenian/catcomp/material/casoseda2.pdf

Fuentes de imagen:

Sicilia, M.A., (2008). Mantenimiento en el ciclo de vida del Software. Openstax
CNX [En Lnea] http://cnx.org/content/m17407/1.3/
PAE Portal Administracin Electrnica (2013) Mtrica V3. Estudio de Viabilidad del
Sistema (Proceso EVS) [En Lnea]
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Meto
dolog/pae_Metrica_v3.html?idioma=es#.U4OLmbWI7IV

Bassi, R. (2003). Apunte de clases: Estimacin de costos de proyectos
informticos y TCO (Total Cost of Ownership). [En Lnea]
http://materias.frba.utn.edu.ar/proyecto/DOCUMENTOS/TCO.doc

Unidad 3. Mantenimiento de Sistemas de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unidad 3. Mantenimiento de Sistemas de Software

Transféré par

Droits d'auteur :

Formats disponibles

Pruebas y mantenimiento de sistemas de software

Unidad 3. Mantenimiento de sistemas de software

Vous aimerez peut-être aussi