Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 1
Ingeniera en Desarrollo de Software 10 Cuatrimestre
Programa de la asignatura: Pruebas y mantenimiento de sistemas de software
Unidad 3. Mantenimiento de sistemas de software
Clave: 150941040
Universidad Abierta y a Distancia de Mxico UnADM
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 2 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
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 3
Unidad 3. Mantenimiento de sistemas de software
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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 4
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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 5
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, Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 6 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 7 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 8 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 9 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 10
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 11 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). Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 12
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 13 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
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 14 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 15 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 16 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 17 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 18 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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 19 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 20 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 21 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 22 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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 23
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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 24 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 25 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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 26
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 27
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 28
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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 29
Ventana de OllyDbg con insercin de punto de ruptura
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 30 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 31
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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 32 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 33 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 34 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)
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 35 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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 36
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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 37 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 38 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 39 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
4. Guarda la actividad con el nombre DPSS_U3_A2_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.
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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 40 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 41 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)
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 42 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 43 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 44 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 45
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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 46
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: Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 47
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 48 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 49 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:
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 50 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 51 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 52 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 53 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 54
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 55 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 56 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 57 Tiempo real = 3.3+4*3.5+3.8/6 Tiempo real= 3.51 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 Paquetes de papel $ 3.00 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 58 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 59
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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 60 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 61
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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 62
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
-3220 -3841.43 -4396.28 -4891.67 -5334.00 Tabla de referencia del anlisis de amortizacin Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 63 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. Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 64
Diagrama de Gantt de actividades Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 65 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 Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 66 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 67 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.
4. Guarda la actividad con el nombre DPSS_U3_A3_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.
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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 68 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 69 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.
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 70 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:
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/
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 71 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
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 72 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
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 73 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
Pruebas y mantenimiento de sistemas de software Unidad 3. Mantenimiento de sistemas de software Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 74 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