UNIVERSIDAD CATLICASEDES SAPIENTIAE

Facultad de Ingeniera Carrera profesional de Ingeniera Informtica Trabajo Monogrfico:

Evolucin y Mantenimiento del Software

Asignatura: Ingeniera de Software I
Profesor : Integrantes: - CORDOVA DIAZ , Lourdes - GARCA FLORES, Stefany - JIMENEZ GOMEZ, Sheila - OLIVERA ARTOLA, Joseph - SANTIAGO COSAR, Miriam

Chvez Barces, Elena

Ciclo
530

:V :Maana
2011 - II

Seccin

Turno

Semestre acadmico:

Lima - Per

INTRODUCCION Alguna vez ha pensado usted en el mantenimiento como un proceso importante en su vida? (tal vezcon el aumento de su edad aumentara el nivel de atencin en su persona ... ) , alguna vez se ha preguntado si el producto que compra es mantenible?(posiblemente cuando vayamos a comprar algo que quiebre nuestros bolsillo como en el caso de un auto le prestemos atencin a la mantencin de este );posiblemente que no . Muchas veces nos atrae ms la cara externa del producto(estampado de la ropa) , la novedad que trae(productos quality produtcs...) o que nos quede bien (exclusivamente en la ropa).Pero se ha dado cuenta usted que la caracterstica ms importantes del producto que adquiere es la calidad(que a veces es enmaraada por los vendedores), y adems que esos productos que ofrecen calidad alta son los ms caros del mercado. Y que por consiguiente el prepotente vendedor muestra las cualidades o caractersticas de calidad del producto de modo que usted har lo mnimo necesario para conservar la calidad. Cuando hablamos de software hablamos de los mismos parmetros pero de una diferente perspectiva de acuerdo a las cualidades del software .Podemos ver que los desarrolladores al igual que un albail se preocupan por que el trabajo este terminado y listo .Lo cual repercutir en un diseo de software que carezca de posibilidades metodolgicas y tcnicas, el cual terminara como juguete desfasado de un nio (a veces los gerentes toman esa postura o cualquier consumidor ),el cual buscara otras cosas para llamar su atencin .Cabe resaltar que esta funcionalidad meditica recae claramente en interfaces llamativas o con mltiples pasos para llegar a una funcionalidad queharn perder mucho tiempo y dinero a los empresarios novatos . Esa caracterstica dicha anteriormente del producto expresada en que nos quede bien" posee un gran poder meditico ya que no piensa en los cambios continuos (imaginemos que la persona engorda un poquito .. el material de la ropa no cumple con las nuevas cualidades embellecedoras de la mujer... ),para el software equivaldra a la capacidad de mantenibilidad del software medida en la capacidad de soportar el cambio (adecuarse al entorno ). Esas estimaciones en el software al igual que en producto siempre empiezan de un clculo subjetivo (podra ser...) ya que no siempre conocemos las caractersticas de la que nos hablan tanto los vendedores (y en el software este clculo se hace en base a los objetivos de la empresa ).Tambin cabe resaltar que en el software la calidad se mide en base a caractersticas que nos hagan hacer menos trabajo de mantenimiento al igual que el producto tangible( queremos hacer el mnimo mantenimiento de nuestras cosas ) y los niveles de calidad determinaran los costos del producto. La evolucin en el software podra ser comparable a la evolucin humana la cual conllevara a todo el transcurso de los cambios que generan una nueva forma

de vida (en nuestro caso el software con facultadas especializadas y de acuerdo al entorno y a la pocahistrica (comprendida en cambios de metodologa y tecnologa mas eficientes). El mantenimiento seria anlogamente en la vida del hombre como el conjunto de mejoras que el hombre tuvo acoplar debido a los requerimientos de su entorno, poco a poco hasta que se produce un punto de quiebre ocasionando la evolucin. Hoy en da la criticidad del software en la vida del ser humano repercute fuertemente en la preocupacin por el mantenimiento del software. En este trabajo se analizara de manera muy general los diferentes aspectos que hay que tener en cuentas para poder comprender esa inclumerelacin que hay entre evolucin y mantenimiento. Adems de pasar a ver cmo podremos tomar las mejores decisiones de estimacinsegn las mtricas requeridas por las empresas, teniendo como base algunas tcnicas de mantenimiento.

CAPITULO I
I-MARCO TERICO 1 Caractersticas del Software
El software se desarrolla, no se fabrica en un sentido clsico. El software no se estropea. La mayora de software se construye a medida, en vez de ensamblar componentes existentes.

2-Historia de la evolucin del software

3- La Crisis del Software

Se le conoce a una etapa en la que el software desarrollado tena entre sus principales caractersticas altos costos de desarrollo , insatisfaccin por parte del cliente(baja calidad, proyectos que se pasaban del tiempo previsto , dificultad de mantenimiento) .

3.1 -Causas de la crisis del software

-La planificacin y estimacin de costos frecuentemente son imprecisas. -Documentacin nula -proyectos con vaguedad de requisitos -complejidad y demanda creciente por dependencia actual del software -recursos limitados -El software no satisface los requisitos deseados. -Altos requerimientos de personal para el desarrollo y mantenimiento.

4- Caractersticas de Calidad en el Software

Algunas caractersticas de calidad fundamentales en todo producto de programacin son: utilidad, claridad, confiabilidad, eficiencia y economa. a)Utilidad: Que satisfaga las necesidades del usuario, ya que con frecuencia no desempeara las funciones esperadas debidos principalmente a una pobre comunicacin con el cliente. b)Confiabilidad: Capacidad de un programa para desempear una funcin requerida bajo ciertas condiciones durante un tiempo especfico. El grado de confiabilidad deseado en un producto depende del costo de las fallas. c)Claridad: Los productos de software deben ser escritos con claridad y ser fciles de entender tanto internamente como externamente, ya que las pruebas y

actividades de mantenimiento consumen gran cantidad del presupuesto del proyecto. d)Econmico: El producto debe ser costeable en su desarrollo, mantenimiento y uso. Un software debe operar normalmente usando menos tiempo o recursos humanos o materiales de los que se requeran antes de tenerlo.

5 Sistemas Heredados(LegacySystems)
Una aplicacin de software que posee un importante valor de negocio que est Debilitada por el constante cambio tecnolgico y metodolgico se caracteriza por: -Pobre soporte arquitectnico -Alto costo de mantenimiento -Documentacin inexistente -Se mantiene en produccin Estos sistemas son sometidos a un mantenimiento estresante y, normalmente, indocumentado, que desemboca en una degradacin de la aplicacin y, por ende, en un servicio deficiente para el usuario.
La adecuacin de estos sistemas en estos sistemas se puede dar por Reingeniar el sistema Abandonar el sistema y sustituirlo por otro nuevo(no significa perdida de datos de la empresa) Optar por una solucin hbrida entre las dos anteriores

6-Dificultades de Administracin de Software

. Algunos problemas importantes identificados en la administracin de software son: 1. Planeacin de proyectos de software pobres. 2. Procedimientos de seleccin de gerentes de proyecto pobres. 3. La medicin de proyectos es pobre. 4. Falta de procedimientos para vigilar el avance del proyecto. 5. Falta de estndares para medir la calidad del desempeo y cantidad de produccin esperada.

7-Costos del Mantenimiento alto

El mantenimiento representa el porcentaje ms alto del coste de todo el ciclo de vida de un sistema grandes costos en mantenimiento de sistemas heredados aunque no existe un acuerdo, los datos empricos indican que el mantenimiento consume una gran porcin del coste total del ciclo de vida del software. Segn Singer [1998], los programadores pasan el 61% de su vida profesional realizando trabajos de mantenimiento, y slo un 39% nuevos desarrollos. Algunos autores [Frazer, 1992] estiman que la situacin puede llegar a ser casi insostenible, ya que existen empresas que se acercan a porcentajes del 95% de los recursos dedicados al mantenimiento, con lo cual se hace imposible el desarrollo de nuevos productossoftware. Esta situacin se conoce como Barrera de Mantenimiento.

7.1 -Causas costos altos

Uso de metodologas para nuevos desarrollos, pero ausencia de ellas para el mantenimiento (Basiliet al., 1996). Dificultad progresiva de modificacin (Griswold y Notkin, 1993; Sommerville, 1992).

La causa real del elevado coste habra que buscarla en los usuarios: La mayora de sus peticiones son mejoras o ampliaciones. estabilidad de equipo: luego de la entrega los equipos de desarrollo se disuelven y nuevos equipos verifican mantenimiento (estos equipos perdern el tiempo en comprensin del sistema). Responsabilidad contractual: el contrato para el desarrollo de un sistema est separado del mantenimiento del sistema. Habilidades de personal asignado: Asignacin de principiantes a reas de mantenimiento por creerse que es fcil de llevar. Edad y estructura del programa: El paso de los aos traen consigui nuevas tecnologas que devalan el sistema necesitndose mucho tiempo en el anlisis de estos sistemas antiguos para hacerlos evolucionar .Tendencia a la desestructuracin (Baxter y Pigdeon, 1997). Los sistemas han experimentado mltiples modificaciones para mejorarlos y adaptarlos a las nuevas necesidades de los usuarios.

NOTA : Ian sommerville , nos dice que los costes varan de acuerdo al dominio de la aplicacin segn su criticidad

8- El efecto Iceberg: costes intangibles (i)

Cuando se planifican los costes de mantenimiento, los analistas programadores experimentados tienen la impresin de que el MS es algo descontrolado y que nunca se sabe qu va a pasar (es algo as como predecir el futuro). Parece como si fuese un iceberg del cual slo se percibe unapequea parte, pero bajo cuya superficie se esconde una gran cantidad de problemas potenciales y de costes encubiertos.

CONTENIDO CAPITULO II: -EVOLUCION DEL SOFTWARE 1- Definicin.

-NedChapin 1(1999) lo defini como la aplicacin de las actividades y procesos de mantenimiento del software que generan una nueva versin operativa de un software con una funcionalidad de usuario o propiedades cambiadas a partir de una versin anterior junto con los procesos y actividades de garanta de calidad y con la gestin de esos procesos. Una definicin atribuida a Lehman y Ramil dice que la evolucin del software son todas las actividades de programacin que se orientan a generar una nueva versin de un software a partir de una versin anterior operativa. Se podra decir que la evolucin en el software se da cuando este logra asimilar las nuevas tecnologas del entorno(metodologas , tcnicas basadas en la especificacin de los usuarios de negocio, tecnologa ) y logra variar ,mejorar adaptar o agregar una nueva funcionalidad al software

Modelo en espiral de desarrollo y evolucin

2-Objetivos del mantenimiento y la Evolucin

Consiste en un conjunto de actividades necesarias para mantener operativo un sistema software. Estas actividades incluyen: -Corregir los defectos (mantenimiento) -Mejorar la funcionalidad del software (evolucin) -Mejorar la calidad del software existente (mantenimiento)

3- Importancia de la Evolucin
-Organizaciones y sociedad dependientes del software. -En algunas empresas el proceso de mantenimiento ha llegado hasta el 90 % en los costes del software - Se utilizan para adaptar el software a los nuevos requerimientos de desarrollo.

4- Procesos de Evolucin. -Gestin de cambio Anlisis de impacto

-Anlisis del impacto de los cambios(Estimar las consecuencias mutiples del impaxcto de los cambios ) -Planificacin de entregas,(Planifica tiempo de demora , requerimientos y personal del proyecto de evolucion) -Implementacin de los cambios(codigo y tests) -Entrega del sistema a los usuarios

5- Leyes de la Evolucin del Software

Lehman1 (1974) formul las primeras leyes de la evolucin del software por primera vez a partir de un estudio del proceso de programacin en IBM. Con el tiempo, se han llegado a formular ocho de estas leyes. En el mbito de ciencias

de la ingeniera, una ley debe entenderse como una caracterstica comn a muchos fenmenos o que se presenta con regularidad. Tipo de leyes:

Ley I: Cambio Continuo Un programa de tipo-E que se utiliza debe adaptarse continuamente, en caso contrario, el programa se hace progresivamente menos satisfactorio. Estas adaptaciones son el resultado del cambio en la operacin del entorno en el cual la aplicacin cumple una funcin. Ley II: Complejidad creciente A medida que evoluciona un programa, su complejidad se incremente, a menos que se trabaje para mantenerla o reducirla. Esta ley implica un tipo de degradacin o entropa en la estructura del programa. Esto a su vez implica un aumento progresivo del esfuerzo de mantenimiento, a menos que se realice algn tipo de mantenimiento perfectivo a este respecto. Ley III: Autorregulacin El proceso de evolucin del programa se autorregula con una distribucin de medidas de atributos de producto y procesos cercana a la normal. La evolucin de programas industriales tipo-E se lleva a cabo por un equipo que opera en una organizacin ms grande. Las decisiones de gestin respecto a los cambios en el programa constituyen una dinmica que determina las caractersticas de crecimiento del producto. Ley IV: Conservacin de la estabilidad organizativa La velocidad de actividad global efectiva media en un sistema en evolucin es invariante a lo largo del ciclo de vida del producto. Usualmente se considera que el esfuerzo gastado en la evolucin del sistema se determina por decisiones de direccin por ejemplo, la complejidad. Los datos empricos sugieren que la actividad lleva a una estabilizacin de actividad aproximadamente constante. Ley V: Conservacin de la familiaridad Durante la vida activa de un programa en evolucin, el contenido de las versiones sucesivas es estadsticamente invariante. Uno de los factores que determina el progreso de un desarrollo de software es la familiaridad de todos los implicados. Cuantos ms cambios y adiciones se hacen a una versin, es ms difcil que todos los implicados la conozcan. Debido a que el crecimiento est limitado por la capacidad de adquirir informacin de los participantes, una evolucin grande dificultara ese aprendizaje, por lo que los cambios tienden a ser de un tamao parecido y limitado. Ley VI: Crecimiento continuo El contenido funciona de un programa debe incrementarse continuamente para mantener la satisfaccin del usuario durante su ciclo de vida. Esta ley

refleja un aspecto del mismo fenmeno que refleja la primera. Habitualmente, los sistemas se crean con una limitacin en cuanto a la funcionalidad del dominio cubierta, por motivos de tiempo o recursos. Ley VII: Calidad decreciente Los programas de tipo-E sern percibidos como de calidad decreciente a menos que se mantengan de manera rigurosa y se adapten al entorno operativo cambiante. Esta percepcin de la calidad decreciente tiene que ver con los cambios en los criterios de aceptabilidad de los usuarios. Ley VIII: Realimentacin del sistema: Los procesos de evolucin incorporan sistemas de realimentacin multiagente y multibucle y estos deben ser tratados como sistemas de realimentacin para lograr una mejora significativa del producto.

6-Gestionar la evolucin
La gestin de la evolucin debe consistir en dar una respuesta rpida, preparada y eficiente a los cambios que se produzcan en el entorno ya sean estos de ndole tecnolgica o de gestin del propio negocio. Ayudar a preveer las posibles dificultades que traer la evolucin. El dominio puede abarcar desde una simple modificacin para corregir un bug (error) de un programa hasta una reimplantacin completa del sistema.

7-Actividades de la evolucin
Las actividades de evolucin que se pueden realizar sobre un sistema son de tres tipos: mantenimiento, reingeniera(que se ver en tcnicas de mantenimiento) y abandono(al final ) , y los veremos los siguientes apartados

Captulo III: Mantenimiento del software(MS)

1-Definicin
Cambios que deben hacerse a programas de computadora despus de haber sido enviados al cliente o usuario(Martin y McClure 1983). -La realizacin de aquellas actividades necesarias para mantener operativo un sistema software despus de haber sido aceptado un puesto en produccin (FIPS 1984). -El mantenimiento cubre la vida de un sistema software desde el momento en que se instala hasta que se desfasa (von Mayrhaser 1990).

-Modificacin de un producto software despus de haber sido entregado para corregir fallos, mejorar el rendimiento u otros atributos, o para adaptarlo a un ambiente cambiante (IEEE 1219 1993). -Un producto software sufre modificaciones de cdigo y documentacin asociada debido a un problema o a la necesidad de mejora. El objetivo es modificar productos software existentes conservando su integridad (ISO/IEC 12207 1995). Pressman [1998] dice que la fase mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente
Todas las definiciones concuerdan en que el mantenimiento Ocurr despus de que el producto est en operacin. Histricamente, el mantenimiento se puede considerar como la primera forma de evolucin de los sistemas.(microevolucion) . (fig) El mantenimiento constituye la ltima fase del ciclo de vida del software

fig -

Pigoski1 (1997) resalta que hay una necesidad de comenzar a considerar el mantenimiento desde el mismo momento en que comienza el desarrollo

Fig - En esta figura se puede ver claramente que dice Pigoski

2-CARACTERSTICAS DEL MANTENIMIENTO -Impredecible (Muchos cambios durante el ciclo de vida del software hace imposible proveer el mantenimiento) -Consume una gran parte del coste total del ciclo de vida del software -Imposibilita un cambio rpido y fiable en el software haciendo perder oportunidades de negocio -Dificulta la adopcin de nuevas tecnologas -Ocasiona daos en la integridad del sistema

3-Actividades del Mantenimiento de Software Las actividades de MS se pueden agrupar en tres categoras funcionales: 3.1 Comprensin del software y de los cambios a realizar: para poder modificar un programa, los programadores necesitan conocer su funcionalidad y objetivos, su estructura interna y los requisitos de operacin. De no ser as, se corre un gran riesgo de introducir nuevos defectos que en el futuro supondrn un coste de mantenimiento adicional. 3.2 Modificacin del software: para incorporar los cambios necesarios se deben crear y

modificar las estructuras de datos, la lgica de los procesos, las interfaces y la documentacin. Los programadores deben conocer lo mejor posible las repercusiones que tienen en el sistema los cambios que estn realizando, con el fin de evitar al mximo posible los efectos secundarios. 3.3 Realizacin de pruebas: para validar los cambios se deben realizar pruebas selectivas que nos permitan comprobar la correccin del software. Esta actividad es necesaria siempre, ya que incluso un cambio muy pequeo no verificado puede producir defectos en el software que reduzcan su calidad y fiabilidad.

4-Definiciones de las personas involucradas en el mantenimiento:

-Cliente (Customer): persona o personas para las que se desarrolla el producto, y que generalmente deciden lo requisitos (ISO/IEC 12207 usa el trmino adquirer). -Usuario (User): personas que interactan directamente con el sistema. -Proveedor (Supplier): organizacin que establece un contrato con el cliente para suministrar un producto software. Un desarrollador es una organizacin que realiza actividades de desarrollo durante el proceso de ciclo de vida software. -Gestor de mantenimiento (Maintainer): organizacin que realiza actividades de mantenimiento. En este cuadro se ven las ventajas y desventajas que traen la asignacin del mantenimiento a los desarrolladores de la empresa o a empresas especializadas en mantenimiento Si lo hacen los Ventajas Desventajas Desarrolladores de la Tras un largo desarrollo, no empresa El desarrollador es el que podemos confiar en que mejor conoce el sistema. sigan las mismas personas No hay necesidad de (no desean trabajar en elaborar documentacin. mantenimiento, estn No hay que establecer descontentos o se envan a mecanismos de otro proyecto). comunicacin formal entre La documentacin nunca desarrolladores y gestores estar realmente finalizada. de mantenimiento. Los desarrolladores se Los usuarios nicamente hacen necesarios para trabajan con una siempre. organizacin. Se pasa demasiado tiempo intentando perfeccionar el sistema.

Empresas independientes(outsourcing)

Se produce mejor documentacin. Los programadores de mantenimiento conocen las partes fuertes y dbiles del sistema. Se establecen procedimientos para implementar cambios. Se incrementa la moral.

La transicin puede ser lenta. Hay una necesidad de entrenamiento. Puede haber problemas de financiacin. Se tarda en aprender el nuevo sistema. Se tarda tiempo en configurar la organizacin de mantenimiento. El soporte de usuario puede sufrir (puede sufrir la credibilidad de la organizacin) Prdida de control Prdida de una fuente de aprendizaje, porque una actividad interna pasa a ser externa. Problemas entre el personal

4.1 mantenimiento de cdigo ajeno Esto se da en la mayora de empresas y algunas pautas que hay que seguir son : -Estudiar el programa antes de entrar en modo emergencia Estudiar el flujo de control general -Evaluar la documentacin existente -Hacer uso de los listados de referencias cruzadas -Hacer cambios con el mayor cuidado -No eliminar cdigo hasta estar totalmente seguro -Insertar variables propias para evitar problemas -Mantener un registro de las actividades de mantenimiento -Evitar la necesidad de tener que tirar el programa y volverlo a escribir (Yourdon, 1975)

5-Tipos de Mantenimiento de Software

Lientz y Swanson proponen dividir en tres tipos de mantenimiento: 5.1 Mantenimiento para aadir o modificar las funcionalidades del sistema o Mantenimiento perfectivo: El objetivo principal del mantenimiento perfectivo es mejorar la calidad del software para hacerlo ms fcilmente mantenible y reducir el

coste impacto de los cambios de los procesos de mantenimiento. Las Actividades del mantenimiento perfectivo son reingeniera, Reescritura y Actualizacin de la documentacin y consta de las etapas de identificacin de candidatos (antes de planificar la versin) y Correccin de los problemas de calidad identificados 5.2 Mantenimiento para adaptar el software a diferentes entornos operativos o mantenimiento adaptativo: Se define como el proceso para mejorar la funcionalidad del software, hardware y su documentacin. Sus pasos son: -Definicin de Requisitos: revisar y entender los requisitos de nuevos cambios -Diseo del sistema: determina donde y cuando implementar los cambios a nivel de sistema. -Diseo de datos: los cambios en las estructuras de datos deben ser diseados. -Diseo de programa: analizar los documentos del diseo del programa para determinar donde aadir, modificar y borrar las funciones que implementan los cambios propuestos. -Diseo del mdulo :analizar los documentos Los cambios en el entorno software pueden ser de dos clases: En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clsico y sustituirlo por un sistema de gestin de bases de datosrelacionales. En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma dedesarrollo con componentes distribuidos, Java, ActiveX, etc. Los cambios pueden afectar a: El sistema operativo (cambio a uno ms moderno), La arquitectura fsica del sistema informtico o al entorno de desarrollo del software. 5.3- Mantenimiento para reparar defectos del software o Mantenimiento correctivo. Se define como aquel proceso orientado a la reparacin de defectos existentes en un sistema software. Ejemplo: fallo de programa, resultado que no es acorde con los requisitos, documentacin de usuario lleva a conclusiones errneas al propio usuario hacia actividades que provoquen resultados incorrectos o fallos en el sistema. La reparacin de errores en el mantenimiento correctivo tiene dos problemas: -. Incrementa las operaciones de testeo. -. Reparar un defecto tiene una probabilidad de introducir otro defecto o efecto secundario 5.3.1Clasificacin de efectos secundarios 5.3.1.1 -Efectos secundarios sobre el cdigo Todos los desarrolladores de software han "sufrido" en algn momento los problemas originados por olvidar aadir un ";" o por confundir un signo de

puntuacin con otro. Las modificaciones en el cdigo fuente que tienen una mayor probabilidad de inducir a nuevos errores son: y Cambios en el diseo que suponen muchos cambios en el cdigo. y Eliminacin o modificacin de un subprograma. y Eliminacin o modificacin de una etiqueta. y Eliminacin o modificacin de un identificador. y Cambios para mejorar el rendimiento. y Modificacin de la apertura/cierre de ficheros. y Modificacin de operaciones lgicas.

5.3.1.2 Efectos secundarios sobre los datos Las estructuras de datos constituyen una parte fundamental y bsica en cualquier producto software. Los efectos secundarios de este tipo pueden aparecer debido a los siguientes cambios: y Redefinicin de constantes locales o globales. y Modificacin de los formatos de registros o archivos. y Cambio en el tamao de una matriz u otras estructuras similares. y Modificacin de la definicin de variables globales. y Re inicializacin de indicadores de control o punteros. y Cambios en los argumentos de los subprogramas. 5.3.1.3 Efectos secundarios sobre la documentacin Los efectos secundarios de esta clase se producen cuando los cambios sobre el cdigo de una aplicacin no se reflejan en la documentacin de diseo y/o en la documentacin de usuario. Los cambios que con mayor probabilidad pueden producir efectos secundarios sobre la documentacin son: y Modificar el formato de las entradas interactivas. y Nuevos mensajes de error no documentados. y Tablas o ndices no actualizados. y Texto no actualizado correctamente. Nota :En la prctica no existe clara distincin de estos tipos de mantenimiento(existen comportamientos de estos tipos ambiguos en determinadas circunstancias ejm al adaptar el software se tendr que hacer correcciones , al perfeccionar el software se puede mejorar el rendimiento o implementar nuevos requerimientos) sommerville

Una visin ms general de los tipos de mantenimiento, se puede observar en la _gura siguiente, ya que se distinguen los diferentes tipos de mantenimiento segn cambios de software, cambios de cdigo fuente o cambios de funcionalidad

5.4 -Tipos de mantenimiento opcionales

5.4.1 -Apoyo a usuarios (PARA SISTEMAS ERP) Acciones realizadas para responder a las peticiones o solicitudes de los usuarios de la aplicacin y a sus continuas necesidades formativas. Por tanto, son tareas para ayudar a la comunidad de usuarios a eliminar su aversin hacia el sistema y reducir el riesgo de una incorrecta utilizacin del mismo. 5.4.2 -MANTENIMIENTO DE EMERGENCIA Por ltimo, un estndar de mantenimiento del IEEE (1998) define una categora adicional, la de mantenimiento de emergencia, cuando los cambios se deben hacer sin planificacin previa, para mantener un sistema en operacin. 5.4.3 -Preventivo - Se usa para soportar las mejoras del sistema y hacer que sea mas fcil de cambiar se basa en el mejoramiento de mantenibilidad futura (reingeniera incremental).

Este tipo de mantenimiento por tener un alto carcter de prediccin debido a la inconstancia del mantenimiento del software ser analizado seguidamente teniendo en cuenta la prediccin del mantenimiento

5.4.3.1 - Prediccin del mantenimiento Las ms recurrentes preguntas de prediccin sobre el mantenimiento del software son : -Que cambios se darn en el sistema? -rea del sistema difciles de mantener? -Estimacin de costes de mantenimiento (Estimacin) Ian Sommerville , da algunas pauta que podran tomarse como reglas de prediccin 1- La aceptacin o no de un cambio en el sistema depende hasta cierto punto , de la mantenibilidad de los componentes del sistema afectado por dicho cambio 2-La implementacin de cambios en el sistema tiende a degradar la estructura de dicho sistema y por lo tanto reduce su mantenibilidad

3-Los costes del mantenimiento dependen del numero de cambios y los costos de la implementacin de los cambios dependen de la mantenibilidad de los componentes del sistema Se debe evaluar la relacin del sistema con en el entorno .Habr mas peticiones de cambio cuando - Haiga muchas interfaces complejas - mas requerimientos voltiles(polticas de empresas, procedimientos organizacionales) -Mas procesos de negocio

Para que el proceso de prediccin sea ms exacto y preciso utilizaremos las estimaciones y las mtricas por razones de orden, de extensin y de evitar complejidad en el tema crearemos un nuevo captulo las cuales veremos a continuacin...

Captulo IV
Estimacin y mtricas del de mantenimiento
I.-ESTIMACION Vista desde el punto de vista de un diccionario, una estimacin es un conjunto aproximado de valores para algo que ha de ser hecho. En el mundo del desarrollo de software, Larry Putnam ha apuntado que la gestin del desarrollo de software considera la estimacin como una actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas Cunto costar?, Cunto tiempo llevar hacerlo? 1-Causas de las estimaciones hechas en software

-La principal caracterstica del software por naturaleza que ocasiona la estimacin es la complejidad(sus constantes cambios y reacciones para adaptarse al entorno y la tecnologa genera inexactitud y puntos de estimacin -Ana Morenos Capuchino en su artculo estimacin de proyectos de software (pag 12 -14)menciono algunas causas como 1. No existe un modelo de estimacin universal o una frmula que pueda ser usada para todas las organizaciones. 2. Hay muchas personas implicadas en los proyectos que precisan de estimaciones. 3. La utilidad de una estimacin tambin depender de la etapa de desarrollo en la que nos encontremos. 4. La estimacin, a menudo, se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un trabajo. 5. Las estimaciones claras, completas y precisas son difciles de formular, especialmente al inicio del proyecto. 6. Las caractersticas del software y de su desarrollo hacen difcil la estimacin. Por ejemplo, el nivel de abstraccin, la complejidad, el grado de medicin del producto y del proceso, los aspectos innovadores, 7. La rapidez con la que cambia la tecnologa de la informacin y las metodologas de desarrollo de software son problemas para la estabilizacin del proceso de estimacin. 8. Un estimador puede no tener mucha experiencia en estimar desarrollos, especialmente de proyectos largos. Cuntos proyectos largos puede alguien dirigir en, por ejemplo, 10 aos? 9. Existe una tendencia aparente de los desarrolladores hacia la subestimacin. Un estimador suele elegir una porcin de software debera tomar para luego extrapolarlo al resto del sistema, normalmente se ignoran los aspectos no lineales del desarrollo de software, por ejemplo, la coordinacin y la gestin. 10. El estimador estima el tiempo que le llevara ejecutar personalmente una tarea, ignorando el hecho de que, a menudo, una parte del trabajo la realiza personal menos experimentado, con un ndice de productividad menor. 11. Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. 12. El estimador tiende a reducir en algn grado las estimaciones para hacer ms aceptable la oferta. 2- Puntos de estimacin (Disparadores) . Influyen un gran nmero de factores en el esfuerzo y duracin de un desarrollo de software -Generan los altos costos de mantenimiento Ejemplos de estos disparadores son el tamao y complejidad del software, el compromiso y participacin del usuario, la experiencia del equipo de desarrollo. En general estos disparadores de coste son difciles de determinar.

Para resolver el problema de los disparadores estas cuestiones conviene tener en cuenta varios aspectos: a)Definicin Hay una falta de definiciones claras y aceptadas de los disparadores, tales como tamao, calidad, complejidad, experiencia. b)Cuantificacin: La mayora de los disparadores de coste son difciles de cuantificar. A menudo, se utilizan medidas tales como: mucho, moderado, poco,... c)Objetividad:La objetividad es un factor de riesgo potencial. Lo que puede ser complejo para el desarrollador A, puede no serlo para el B. d)Correlacin: Es difcil considerar un driver independiente de los dems. Un cambio en el driver A, puede tener consecuencias en los valores de otros disparadores. e)Relacin entre disparador y esfuerzo: Para la estimacin es importante poder predecir la relacin entre, por ejemplo, el tamao del software y el esfuerzo requerido, el nivel de calidad especificado y el esfuerzo requerido, etc. f)Calibracin: Es imposible hablar de los disparadores de coste ms importantes de forma aislada 3-Marco Temporal de la Estimacin de Proyectos Es un proceso continuo. A medida que el proyecto avanza, ms se conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin. 1-Al principio, en la concepcin del sistema, slo necesitamos estimaciones a grosso modo para determinar el tamao del proyecto y estudiar su viabilidad (MACROESTIMACION). 2-Una vez que los requisitos han sido definidos, se necesita una estimacin ms detallada para la siguiente fase, diseo del producto, con el fin de utilizarla para confeccionar una planificacin para dicha fase. 3-e hace la primera estimacin se conocen ms exactamente, y tambin se dispone de informacin adicional sobre los recursos que intervendrn en el desarrollo, como por ejemplo la experiencia de los desarrolladores. 4-Despus de que el diseo del producto ha finalizado, puede ser incluso que la base de la estimacin haya cambiado, es decir, se puede pasar de utilizar parmetros descriptivos a emplear otros ms detallados como el nmero de mdulos esperados, o el nmero de lneas de cdigo. 5-Cuando la codificacin, las pruebas y la instalacin han finalizado podemos obtener datos sobre el rendimiento y la calidad del sistema que,

cuantificados adecuadamente, pueden constituir la base para la estimacin de defectos. Estos datos, junto con el conocimiento sobre el entorno del desarrollo, permitirn realizar estimaciones para la fase de mantenimiento.

ejemplo de mtodos de estimacin Estimacin por analoga Comparar las caractersticas del sistema que vamos a modificar con el mismo conjunto de caractersticas de otras modificaciones previamente realizadas al mismo o a otros sistemas

4-Tipos de Mtodos 4.1. Modelos Estadsticos Miden de acuerdo a las estadsticas de las peticiones de cambio y a las areas involucradas del software . C.E. Walston y P.C. Flix, de IBM utilizaron datos de 60 proyectos terminados completamente para desarrollar un modelo simple de clculo del esfuerzo de desarrollo de software. El principal determinante del esfuerzo de desarrollo fue la mtrica LOC.

Teora de falla por el hilo paralelo (parallel-strand) Cada componente es tratado como un cable de muchos hilos el cual no falla hasta que todos sus hilos se rompan. Corresponde a la confiabilidad en paralelo.

Ley del producto de las desconfiabilidades en paralelo La desconfiabilidad en paralelo, U(S), de un sistema compuesto por varios equipos funcionalmente en paralelo y con confiabilidades expresadas en fracciones decimales, es el producto de las desconfiabilidades correspondientes a los equipos. U(S) = U(1) * U(2) * U(3) * . * U(N) La confiabilidad en paralelo, R(S), se calcula restando la desconfiabilidad del sistema, U(S), de la unidad R(S) = 1 - U(S) = 1 - [(1-R1) * (1-R2) * (1-R3) * * (1-Rn)] Esquemticamente se representa:

4.2 Modelos basados en Teoras: Modelo de Putnam.: Correspondiente al entorno propio a partir de datos histricos recopilados sobre anteriores esfuerzos de desarrollo. 4.3. Modelos Compuestos: Son modelos que utilizan una combinacin de intuicin, anlisis estadstico y juicio de expertos. A continuacin se describen los ms importantes. a) Modelo COCOMO de Boehm. Es probablemente el ms conocido y slidamente documentado de todos los modelos de estimacin de costes. Estudia principalmente los diferentes ndices de mantenibilidad los cuales se calculan usando datos histricos y una serie de matrices a partir de: XC : porcentaje de lneas comentadas por cada cien, para calcular IC. XR : porcentaje de lneas sin datos constantes por cada cien, para calcular IR. XP : nmero de errores comprobados por cada cien lneas de cdigo, para IP b) SOFTCOST Tausworthe

Tausworthe, de Jet PropulsionLaboratory, intent desarrollar una estimacin de coste del software utilizando elementos de los modelos de ms xito disponibles. Este modelo requiere 68 parmetros de entrada, cuyos valores se deducen a partir de las respuestas del usuario a 47 preguntas acerca del proyecto. c) SPQR - Capers Jones El enfoque del problema es similar al de Boehm en su modelo COCOMO. Est basado en 20 factores que influyen razonablemente en el coste y productividad del desarrollo de software y que estn bien definidos y otros 25 factores que no estn tan bien definidos. d) COPMO - Thebaut Thebaut propone un modelo de desarrollo de software que intenta contabilizar el esfuerzo requerido cuando los equipos de programacin estn involucrados en grandes proyectos. La ecuacin general de clculo de esfuerzo es: E = a + bS + cPd - Donde a, b, c y d son constantes para ser determinadas a partir de datos empricos mediante anlisis de regresin: - S es el tamao del programa en miles de LOC - P es el nivel medio de personal durante el ciclo de vida del proyecto. - Desafortunadamente, este modelo requiere no uno sino dos parmetros cuyos valores no son conocidos hasta la terminacin del proyecto. 5-Requisitos que debe Cumplir un Buen Estimador 1. Debe poseer una importante formacin y experiencia profesional que le ayuden a entender y solucionar los problemas de la gestin de proyectos. 2. Debe tener una posicin en la organizacin que le permita adoptar un juicio independiente. 3. Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado por otros expertos. 4. Siempre que use una herramienta de estimacin, sta debe ajustarse a su propsito de estimacin y debe soportar el mtodo. La herramienta tambin debe estar documentada y controlada. 5. Debe ser capaz de describir su experiencia en cada estimacin. Es decir, describir los problemas a los que ha tenido que enfrentarse, las soluciones, etc. 6. Debe ser capaz de documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificarle.

II-Mtricas de Mantenimiento
1- Definicin de Mtrica

Podemos definir las Mtricas de Software o Medidas de Software como:La aplicacin contina de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Un mtodo y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta caracterstica en un producto software concreto. (ISO/IEC, 1991) Una funcin que toma como entrada cierta informacin del software que se est midiendo, y que devuelve como salida un valor numrico sencillo, el cual es interpretado como el grado en que el producto software posee un atributo dado que afecta a su calidad. (IEEE, 1992) 2- Caractersticas de las Mtricas de Software La calidad de las medidas debera facilitar el desarrollo de modelos que sean capaces de predecir el comportamiento de determinados parmetros que afectan al desarrollo de productos o de procesos. Una medida ideal debera ser: y Objetiva. y Sencilla, definible con precisin para que pueda ser evaluada. y Fcilmente obtenible (a un coste razonable). y Valida, la mtrica debera medir exactamente lo que se quiere medir y no otra cosa. y Robusta. Debera de ser relativamente insensible a cambios poco significativos en el proceso o en el producto. Adems, para una mejor utilizacin de estas medidas, a la hora de realizar estudios analticos o anlisis estadsticos deberan de tener unos valores que se ajusten a una cierta escala de medida. 3-Clasificacin de las Mtricas del Software Las Mtricas de producto son medidas del producto software durante cualquier fase de su desarrollo, desde los requisitos hasta la instalacin. 3.1- Las Mtricas de producto pueden medir la complejidad del diseo, el tamao del producto final (fuente u objeto) o el nmero de pginas de documentacin producida..

Las medidas ms utilizadas son : 3.1.1Metricas de Tamao Mtricas que intentan cuantificar el tamao del software a)Lneas de cdigo(LOC) Se toman en cuenta lnea de un texto de un programa que no es un comentario o lnea en blanco, sin tener en cuenta el nmero de instrucciones o parte de instrucciones en la lnea.(NCLOC) La longitud del esfuerzo es la base de la mtrica de lnea de cdigo

Para medir la longitud se suele medir en :

1. Nmero de bytes de almacenamiento requerido para contener el texto del programa 2. Nmero de caracteres en el texto del programa. (CHAR, del ingls Carcter) - Tiene el inconveniente obvio de que sus valores no pueden ser medidos hasta que el proceso de codificacin ha finalizado. b) Especificaciones de diseo: Se recopilara toda la documentacin de diseo (artefactos )para realizar una estimacin . Los principales documentos analizados son :
- Diagrama Funcional de Flujo de Datos Burbuja -Diccionario de Datos Dato elemental -Datos Diagrama E/R Objetos y relaciones - Diagrama de estado y de Transicin , >Hoy en da no existe una mtrica para comparar especificaciones ni diseos.

c) Prediccin de la longitud. . En particular, una prediccin de longitud, se puede obtener considerando la relacin ratio de expansin entre la longitud de las especificaciones o del diseo y la longitud del cdigo en proyectos similares de los que se mantienen datos d) Funcionalidad. El concepto de funcionalidad de un producto se origina a partir de una nocin intuitiva de la cantidad de funciones que proporciona. Ha habido dos intentos serios para medir la funcionalidad de un producto software. Uno de ellos se debe

a Albright y corresponde a los Puntos de Funcin (FPA, del ingls Funcin Point Analysis)) y otro debido a DeMarco, los Bang, que no ha tenido una gran difusin. 3.2 -Las Mtricas de proceso, Son medidas del proceso de desarrollo del software tales como tiempo de desarrollo total, esfuerzo en das/hombre o meses/hombre de desarrollo del producto, tipo de metodologa utilizada o nivel medio de experiencia de los programadores. 3.3Mtricas de Calidad Se puede generar una larga lista de caractersticas de la calidad del software: correccin, eficacia, portabilidad, mantenibilidad, fiabilidad, etc. o la complejidad, cuyo estudio ha sido ms uniforme. Han tenido considerable atencin tres reas: y Correccin de los programas, medida como el nmero de defectos. y Fiabilidad del software, calculada a partir del dato anterior. y Mantenibilidad del software, que se mide a partir otro conjunto de mtricas, incluidas las de complejidad. 3.4 -Cualidades para formular mtricas 3.4.1 Visin General Para la estimacin, existen cuatro tcnicas bsicas y comunes: 1. La opinin de los expertos; Esta tcnica se basa en la experiencia profesional de los participantes en el proyecto de estimacin. 2. La analoga; Es una aproximacin ms formal que la experiencia de los expertos y se basa en la comparacin directa de uno o ms proyectos pasados. La estimacin inicial se ajusta dependiendo de las diferencias entre el proyecto pasado y el nuevo. 3. La descomposicin; Consiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior. La estimacin se hace a partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior. La estimacin global del proyecto resultar de sumar las estimaciones de los componentes. 4. Las ecuaciones de estimacin; Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir. 4-Mantenibilidad y Mantenimiento

4.1 Concepto de mantenibilidad del software Existen varias definiciones de mantenibilidad. A continuacin se relacionan algunas de las ms conocidas: y El Gobierno Federal de Estados Unidos la define como la facilidad con la cual el software puede ser mantenido, mejorado, adaptado o corregido para satisfacer los requerimientos especificados [FIPS, 1984]. y Card y Glass [1990] establecen que la mantenibilidad significa que los cambios tienden a ser confinados en reas localizadas del sistema (mdulos) y son fciles de llevar a cabo. y El IEEE la define como la facilidad con que un sistema o componente software puede ser modificado para corregir defectos, mejorar el rendimiento u otros atributos, o adaptarse a un cambio de entorno[IEEE, 1990]. y ISO define la mantenibilidad como un conjunto de atributos referidos al esfuerzo necesario para realizar las modificaciones especificadas o implicadas [ISO/IEC, 1994]. 4.2Aspectos que influyen en la mantenibilidad Proceso de Desarrollo: la mantenibilidad debe formar parte integral del proceso de desarrollo del software. Las tcnicas utilizadas deben ser lo menos intrusivas posible con el software existente [Lewis y Henry, 1989]. Los problemas que surgen en muchas organizaciones de mantenimiento son de doble naturaleza: mejorar la mantenibilidad y convencer a los responsables de que la mayor ganancia se obtendr nicamente cuando la mantenibilidad est incorporada intrnsecamente en los productos software. Documentacin: En mltiples ocasiones, ni la documentacin ni las especificaciones de diseo estn disponibles, y por tanto, los costes del mantenimiento del software se incrementan debido al tiempo requerido para que un mantenedor entienda el diseo del software antes de poder ponerse a modificarlo. Las decisiones sobre la documentacin que debe desarrollarse son muy importantes cuando la responsabilidad del mantenimiento de un sistema se va a transferir a una organizacin nueva [Marciniak y Reifer, 1990]. Comprensin de Programas: La informacin disponible es incomprensible, incorrecta o insuficiente. La complejidad del software, de la naturaleza de la aplicacin o de ambos. La confusin, mala interpretacin u olvidos sobre el programa o sistema. 4.3 Su categoras de mantenibilidad Analizabilidad: Capacidad del producto software de diagnosticar sus deficiencias o causas de fallos, o de identificar las partes que deben ser modificadas.

 Confiabilidad: Capacidad del producto software de permitir implementar una modificacin especificada previamente. La implementacin incluye los cambios en el diseo, el cdigo y la documentacin. Si el software es modificado por el usuario final, entonces, la confiabilidad puede afectar a la tolerabilidad. Estabilidad: Capacidad del producto software de minimizar los efectos inesperados de las modificaciones. Facilidad de prueba: Capacidad del producto software de permitir evaluar las partes modificadas. Conformidad: Capacidad del producto software de satisfacer los estndares o convenciones relativas con la mantenibilidad. 4.4Propiedades de la mantenibilidad . Reparabilidad: Un sistema software es reparable si permite la correccin de sus defectos con una cantidad de trabajo limitada y razonable. . Flexibilidad: Capacidad de evolucionar Actividades de mantenibilidad       Actividad 1. Implementacin del proceso Actividad 2: Anlisis de problemas y modificaciones Actividad 3: Implementacin de la modificacin Actividad 4: Revisin y aceptacin del mantenimiento Actividad 5: Migracin Actividad 6: Retirada

CAPITULO V I-Tcnicas para el Mantenimiento de software Conjunto de 1-Reingeniera Reingeniera es la transformacin (modificacin) sistemtica de un sistema existente a una nueva forma para realizar mejoras de la calidad en operacin, capacidad del sistema, funcionalidad, rendimiento o capacidad de evolucin a bajo coste, con un plan de desarrollo corto y con bajo riesgo para el cliente.

(Reengineering Center del Software EngineeringInstitute de la Universidad Carnegie Mellon) Proceso de recuperacin de la informacin de diseo de un software existente para alterarlo o reconstruirlo en un esfuerzo de mejorar la calidad general. La reingeniera trabaja todos los niveles de abstraccin (desde la implementacin hasta el diseo) para conseguir realizar cambios ms drsticos preservando los valores de negocio del sistema . En los proyectos de Ingeniera Inversa y Reingeniera de productos terminados, la primera ocupacin del ingeniero se centra en asignar o asociar valor semntico a los elementos sustanciales del cdigo fuente. Biggerstaff [1994] y Weide [1995] indican las dos tareas necesarias para esta labor:

1.1Actividades de Reingeniera

1.1.1 -Anlisis de inventario Toda organizacin debera hacer un inventario de sus aplicaciones, para determinar las aplicaciones candidatas a reingeniera y su prioridad. La informacin a recoger es la siguiente: Nombre de la aplicacin y ao de implantacin. Sistema/s en los que se encuentra instalada. Bases de datos a las que accede y aplicaciones con las que est relacionada Cambios importantes desde su creacin y esfuerzo global necesario. Fecha del ltimo cambio importante y esfuerzo aplicado para realizarlo. Errores detectados en el ltimo ao (o periodo). N de usuarios y nde mquinas donde se encuentra instalada. Complejidad Calidad de la documentacin Vida futura prevista y n de cambios previstos en los prximos aos. Coste anual de mantenimiento y coste anual de funcionamiento. Importancia para el negocio 1.1.2- Reestructuracin de la documentacin Nuevo Ordenamiento y analtico , metodolgico y estratgico de la documentacin para seleccionar , agregar o desechar documentacin antigua 1.1.2.1 Situaciones de reestructuracin de documentacin La documentacin sea inexistente o inservible Su creacin de nuevo consumira muchos recursos. Si el sistema funciona adecuadamente y no se prev que vaya a tener larga vida, mejor dejar las cosas como estn. Sea necesario actualizar la documentacin, pero se dispone de pocos recursos para hacerlo. En este caso lo mejor es actualizar slo las partes que se vayan modificando. El sistema es muy crtico para el funcionamiento del negocio y hay que documentarlo por completo. En esta caso reducir la documentacin al mnimo indispensable, y despus optar por la opcin anterior. 1.1.3- Reestructuracin del cdigo Es la actividad ms frecuente dentro de la reingeniera. Se aplica a programas con un buen diseo arquitectnico, pero donde la codificacin individual de cada mdulo muy degradada. 1.1.4 Reestructuracin de datos - Se utiliza cuando en bases de datos cuando la metodologa ya no es factible . Normalmente se hace reingeniera Inversa primero para hacer la reestructuracin de datos

 Primero se extraeran todas las sentencias que contienen definiciones de datos y descripciones de ficheros, evaluando y comprendiendo la utilidad de los datos extrados. Esto se conoce con el nombre de Anlisis de datos. A continuacin comienza el Rediseo de datos, que define las nuevas estructuras de datos a partir de las antiguas, manteniendo la consistencia, y renombrndolas con las nuevas convenciones que se ajusten a los estndares. 1.1.5 Ingeniera inversa
. Consiste principalmente en recuperar el diseo de una aplicacin a partir del cdigo. Es aplicable a aplicaciones con las siguientes caractersticas:

Documentacin inexistente o totalmente obsoleta. Programacin en bloque de cdigo muy grandes y/o sin estructurar. Inexistencia de documentacin interna en los programas, o bien sta es incomprensible o est desfasada. La aplicacin cubre gran parte de los requisitos y del rendimiento esperado. La aplicacin est sujeta a cambios frecuentes, que pueden afect ar a parte del diseo. Se prev que la aplicacin pueda tener an larga vida. 1.1.6 Ingeniera progresiva Es lo que frecuentemente se conoce por reingeniera, ya que puede decirse que es el conjunto de todas las actividades anteriores. Con la ingeniera progresiva no slo se recupera el diseo, sino que permite reconstruir el sistema a partir del mismo con el propsito de mejorarlo, ampliarlo y en definitiva aumentar su calidad en conjunto.

1.2-Pasos para hacer Reingeniera

y y y y y y

Anlisis de requerimientos que identifiquen las metas perseguidas por la reingeniera Captura del modelo por medio del conocimiento del legacysystem y su documentacin utilizando patrones de ingeniera inversa. Deteccin del problema con la ayuda de herramientas de inspeccin, mtrica y software de visualizacin Anlisis del problema seleccionando la estructura que puede resolverlo Reorganizacin seleccionando la transformacin ptima para el sistema Propagacin del cambio con metodologa de reingeniera

1.3 Alternativas a la Reingeniera Dejar el software como est Comprar la aplicacin Desarrollar de nuevo Para hallar la mejor opcin utilizaremos el anlisis de costo y beneficio 1.3.1-Costes y beneficios de la reingeniera Cuatro operaciones nos pueden dar una idea de los costes del proyecto y del valor de negocio del software actual: a) Introduccin de un sistema de evaluacin de los costes del mantenimiento. Es recomendable que esta tarea la lleve a cabo la organizacin anticipndose con suficiente antelacin al momento en que se percibe la necesidad de aplicar b) Anlisis de la calidad del software actual, para lo cual pueden utilizarse auditores de cdigo automticos que proporcionan datos del tamao, complejidad y mtricas de calidad del cdigo fuente. Estos valores son incorporados a una base de datos que es utilizada por otra herramienta para realizar comparaciones y obtener resultados. c) Anlisis de los costes de mantenimiento:Berns [1984] propone tres mtricas para medir los procesos de mantenimiento: 1.3.2 Medicin de procesos -"Dominio del impacto" o proporcin de instrucciones y elementos de datos afectados por una tarea de mantenimiento con respecto al total de instrucciones y elementos de datos del sistema; -"Esfuerzo empleado", que es el nmero de horas dedicadas a tareas de mantenimiento, con lo que se puede obtener una media del nmero de horas por tarea de mantenimiento;

-"Tasa de errores de segundo nivel", que es el nmero de errores causados por acciones de mantenimiento. Si observamos que estas tres medidas se incrementan, es muy probable que los costes de mantenimiento se incrementen con el tiempo. d) Evaluacin del valor de negocio del sistema actual, que es realizado por la direccin de la organizacin. 2- Tipos de Reingeniera 2.1-Ingeniera inversa o modernizacin de caja blanca
. Consiste principalmente en recuperar el diseo de una aplicacin a partir del cdigo. Es aplicable a aplicaciones con las siguientes caractersticas:

Documentacin inexistente o totalmente obsoleta. Programacin en bloque de cdigo muy grandes y/o sin estructurar. Inexistencia de documentacin interna en los programas, o bien sta es incomprensible o est desfasada. La aplicacin cubre gran parte de los requisitos y del rendimiento esperado. La aplicacin est sujeta a cambios frecuentes, que pueden afect ar a parte del diseo. Se prev que la aplicacin pueda tener an larga vida. 2.1.2 -Tipos de Ingeniera Inversa 2.1.2.1 -Ingeniera inversa para comprender el procesamiento La primera actividad real de la ingeniera de inversa comienza con un intento de comprender y despus extraer abstracciones de procedimientos representadas por el cdigo fuente. Para comprender las abstracciones de procedimientos, se analiza el cdigo en distintos niveles de abstraccin, sistema, programa, mdulo, trama y sentencia. La funcionalidad general de todo sistema debe ser algo perfectamente comprendido antes de que se produzca un trabajo de ingeniera inversa ms detallado. Para grandes sistemas, la ingeniera inversa suela efectuarse mediante el uso de un enfoque semiautomtico. Se utilizan herramientas CASE para analizar la semntica del cdigo existente. La salida de este proceso se pasa entonces a unas herramientas de reestructuracin y de ingeniera progresiva que completarn el proceso de reingeniera. 2.1.2.2 Ingeniera inversa para comprender los datos

En el nivel de programa, es frecuente que sea preciso realizar una ingeniera inversa de las estructuras de datos de programa internas, como parte de un esfuerzo global se reingeniera

2.1.2.2.3 Estructuras de base de datos: independientemente de su organizacin lgica y de su estructura Las bases de datos permiten definir objetos de datos y admiten algn mtodo para establecer relaciones entre objetos. Consiguientemente, la reingeniera de un esquema de bases de datos para formar otro exige una comprensin de los objetos ya existentes y de sus relaciones. Pasos para definir el modelo de datos existente como precursor para una ing. que producir un nuevo modelo de base de datos: 1. Se construye un modelo de objetos inicial 2. Se determinan los candidatos a clases 3. Se refinan las clase tentativas: se determinan si ciertas clases similares pueden o no combinarse en una nica clase. 4. Se definen las generalizaciones se examinan las clases que puedan tener muchos atributos similares para determinar si se debera o no construir una jerarqua de clases con una clase de generalizacin como precursor de todos sus descendientes. 5. Se descubren las asociaciones. Mediante el uso de tcnica anlogas al enfoque de CRC se establecen las asociaciones entre clases. 2.2Reconstruccin de programas En la reconstruccin de programas partimos de los productos elaborados en la fase de Ingeniera Inversa para, aplicando tcnicas de Ingeniera directa, reconstruir el programa objeto del estudio. En la Ingeniera Inversa habremos conseguido una Recuperacin del diseo del programa en la que, segn [Piattini et al., 1996], se recrean abstracciones de diseo partiendo de una combinacin del cdigo, documentacin, experiencia personal yconocimientos generales sobre los dominios del problema y la aplicacin.Cambio de representacin de un producto software, pero dentro del mismo nivel de abstraccin. 2.2.1Reestructuracin La reestructuracin del software modifica el cdigo fuente y/o los datos en un intento de adecuar10 a futuros

cambios. En general, la reestructuracin no modifica la arquitectura global del programa. Tiende a centrarse en los detalles de diseo de mdulos individuales y en estructuras de datos locales definidas dentro de los mdulos. Si el esfuerzo de la reestructuracin se extiende ms all de los lmites de los mdulos y abarca la arquitectura del software, la reestructuracin pasa a ser ingeniera directa La reestructuracin es la transformacin de un producto software a otra forma de representacin, pero sin cambiar de nivel de abstraccin. Las herramientas desarrolladas permitan: Insertar funciones en clases. Encapsular cdigo en funciones. Expulsar funciones de clases.

2.3- Ingeniera inversa y reingeniera de bases de datos relacionales En el nivel de programa, es frecuente que sea preciso realizar una ingeniera inversa de las estructuras de datos de programa internas, como parte de un esfuerzo global se reingeniera. Enel nivel de sistema, es frecuente que se efectu una reingeniera de las estructuras globales de datos para ajustarlas a los nuevos paradigmas de gestin de bases de datos. Enfoque para la determinacin de clases para la ing. Inversa: 1) Se identifican los indicadores y estructuras de datos locales dentro del programa que registren informacin importante acerca de las estructuras de datos globales. 2) Se define la relacin entre indicadores y estructuras de datos locales y las estructuras de datos globales. 3) Para toda variable que represente una matriz o archivo, se enumeran todas las dems variables que tengan una relacin lgica con ella.

Recuperacin del diseo de bases de datos

Al recuperar el diseo de una base de datos relacional, intentaremos obtener, a partir de su diseo en un soporte fsico, los esquemas lgico y conceptual del universo del discurso que estn representando, tal y como mostramos

Pedro de Jess y Sousa [1999] presentan una interesante comparacin entre diferentes mtodos aplicables a la Ingeniera inversa de bases de datos relacionales. En la Tabla 7mostramos resumidamente los diferentes mtodos analizados, las condiciones necesarias para su aplicacin, las entradas que toman y el tipo de resultado que producen.

Evidentemente, en una misma base de datos relacional podemos encontrarnos tablas que se adecuen ms a un mtodo que a otro. En este sentido, Sousa et al. [1999] proponen un algoritmo para clasificar las tablas de una misma base de datos en diferentes conjuntos, de manera que pueda aplicarse a cada uno de stos el mtodo de Ingeniera inversa ms apropiado. 2.4-Ingeniera inversa y reingeniera de interfaces de usuario Exclusimanete se basa en en proceso de reingenieria para determinar el comportamiento funcional autentico y la posible complejidad delas interfases del sistema para luego reconstruir la interfaz(aplicar reingenieria progresiva o directa). Tres preguntas bsicas a las cuales hay que responder cuando comienza la ingeniera inversa de la IU: Cuales son las acciones bsicas que debe de procesar la interfaz, por ejemplo, acciones de teclado y clics de ratn? cul es la descripcin compacta de la respuesta del sistema a estas acciones? Qu quiere decir una sustitucin o ms exactamente que concepto de equivalencia de interface es relevante en este caso? Se puede utilizar lgebra de procesos para presentar el comportamiento de una interfaz de manera formal. Existen al menos dos entidades activas concurrentes: el sistema y el usuario. Uno tiene que ser capaz de expresar ciertas opciones externas que no se encuentran bajo control del usuario.

Estos ingredientes, la reactividad, la concurrencia y las operaciones externas resultan bsicos para el lgebra del procesos. La descripcin de la interfaz hace uso de agentes y acciones. Un agente es algo que da vida a algn aspecto del sistema. Las acciones permiten que los agentes se comuniquen entre s. En esencia, el lgebra de procesos es una notacin taquigrfica para representar la forma en que los agentes y las acciones dan vida a la funcin de una IU 3-Importancia Arnold [5] identifica siete principales razones que demuestran la importancia de la reingeniera: "Re-ingeniera puede ayudar a reducir el riesgo de una organizacin evolucin; Re-ingeniera puede ayudar a la organizacin recuperar su inversin en software; Re-ingeniera de software puede hacer ms fcil a los cambios; Re-ingeniera es un gran negocio; Re-ingeniera de capacidad se extiende conjuntos de herramientas CASE; Re-ingeniera es un catalizador para el mantenimiento de software automticas; Re-ingeniera es un catalizador para la aplicacin de tcnicas de inteligencia artificial para resolver software de re-ingeniera de los problemas. "

4-Otras tcnicas 4.1Reingenieria orientada a objetos La aparicin de tcnicas de modelado arquitectnico orientada a objeto (OMT [20]) y su documentacin asociada (UML) facilitaron el desarrollo de tcnicas de diseo con el paradigma de objetos. El proyecto de recoleccin de premisas para reingeniera orientada a objetos (FAMOOS) proponen, descomposicin de sistemas (subsistemas) ,-mayor portabilidad, Incorporacin de tecnologas UML y CORBA, diseo independiente del lenguaje de implementacin, Desarrollo escalable Herramientas que soporten las tcnicas aplicadas. 4.2Deteccin de clones Los clones son fragmentos de cdigo iguales o similares que se encuentran en el cdigo fuente de los programas y que entorpecen la realizacin efectiva de modificaciones (efectos colaterales, repeticin de la misma modificacin por cada clon, encarecimiento de las pruebas, etc.).

4.2.1Causas para la existencia de clones: Copiar y pegar por comodidad Estilos de codificacin Operaciones sobre T.A.D.s Mejora del rendimiento Accidente 4.3Reingeniera basada en wrapping Tienen como en conocimiento del sistema, los datos, las funcionalidades y las interfaces: se basan en el comportamiento de entradas y salidas y no en el cdigo, la reingeniera que se utiliza solo las interfaces y CAPITULO VI I-HERRAMIENTAS PARA EL MANTENIMIENTO DEL SOFTWARE.

1-Herramientas CASE.
-Revision Control System Es una implementacin en software del control de versiones que automatiza las tareas de guardar, recuperar, registrar, identificar y mezclar versiones de archivos. RCS es til para archivos que son modificados frecuentemente, por ejemplo programas informticos, documentacin, grficos de procedimientos, monografas y cartas. RCS tambin puede ser utilizado para manejar archivos binarios, pero con eficacia y eficiencia reducidas. -Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de aplicaciones.

2-Herramientas de metricas
MNTICA: una Herramienta de Mtricas para Modelos de Datos MANTOOL: gestin del Proceso de Mantenimiento conforme a

3-Herramientas de ingeniera inversa.

3.1Desensambladores Esencialmente, un desensamblador es exctamente lo contrario de un ensamblador. Tal como un ensamblador convierte cdigo escrito en ensamblador en cdigo mquina binario, un desensamblador invierte el proceso e intenta recrear el cdigo en ensamblador partiendo del cdigo mquina binario. El principal problema son la no muy exacta datos.(perdida de datos) Algunos ejemplos Comerciales IDA Pro es un desensamblador profesional (lase: caro) extremadamente potente. La parte mala es su elevado precio. Por lo tanto, y aunque ciertamente merece su precio, este wikibook no considera IDA Pro especficamente porque su precio es exclusivista. Dos versiones gratuitas existen; mira abajo. diferenciacion de codigo y

3.2Herramientas Gratuitas -IDA 3.7 Esta es una herramienta para DOS con GUI parecida a IDA Pro, pero considerablemente mas limitada. Puede desensamblar cdigo para procesadores Z80, 6502, Intel 8051, Intel i860, y PDP-11, as como instrucciones x86 hasta el 486. http://www.simtel.net/product.php -IDA Pro Freeware 4.1 Se comporta casi como IDA Pro, pero solo desensambla cdigo para procesadores Intel x86, y solo funcions en Windows. Puede desensamblar instrucciones para aquellos procesadores disponibles a fecha de 2003. 3.3-Software Libre Bastard Disassembler Bastard es un potente y programable desensamblador para Linux y FreeBSD. ciasdis El nombre oficial de ciasdis es computer_intelligence_assembler_disassembler. Esta herramienta basada en Forth permite construir conocimiento sobre un cuerpo de cdigo de manera interactiva e incremental. Es nico en que todo el cdigo desensamblado puede ser re-ensamblado exactamente al mismo cdigo. Soporta 8080, 6809, 8086, 80386, Pentium I y DEC Alpha. Facilidades de scripting ayudan

en al anlisis de cabeceras de fichero Elf y MSDOS y hacen esta herramienta extensible. ciadsis para Pentium I est disponible como imagen binaria, las otras estn en cdigo fuente, cargables sobre lina Forth, disponible del mismo sitio. objdump viene de manera estandar, y es tipicamente usada para inspeccin genrica de ficheros binarios. Presta atencin a las opciones de relocation y dynamic symbol table. 3.2 -Descompiladores DCC Decompiler Dcc es una excelente perspectiva terica a la descompilacin, pero el descompilador slo soporta programas MSDOS. http://www.itee.uq.edu.au/~cristina/dcc.html Boomerang Decompiler Project El descompilador Boomerang es un intento de construir un potente descompilador para varias mquinas y lenguajes. Hasta ahora, slo descompila en C con un xito moderado. http://boomerang.sourceforge.net/ Reverse Engineering Compiler (REC) REC es un potente "descompilador" que descompila cdigo ensamblador a una representacin del cdigo semejante a C. El cdigo est a medio camino entre ensamblador y C, pero es mucho mas legible que el ensamblador puro. http://www.backerstreet.com/rec/rec.htm ExeToC es un descompilador interactivo que presume de buenos resultados. http://sourceforge.net/projects/exetoc 4-Herramientas de gestin de la configuracin.
IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.

5-Herramientas para la reestructuracion de codigo

La refactorizacin (del ingls Refactoring) es una tcnica de la ingeniera de software para reestructurar un cdigo fuente, alterando su estructura interna sin cambiar su comportamiento externo.

6-Un Generador de Referencias Cruzadas

Un generador de referencias cruzadas es un programa que selecciona palabras de un fichero de entrada y las imprime en orden con los nmeros de lnea en que aparecen. Los nmeros de lnea se imprimen junto con cada palabra y deben estar tambin en orden. Considrese por ejemplo el siguiente programa C++:
#include <iostream> int main() { cout << Hello C Programmeres. << endl; cout << Welcome to the World of C++!.<< endl; }

La salida producida por el generador podra ser similar a: C 4, 5 Hello 4 Programmers 4 Welcome 5 World 5 cout 4, 5 include 1 iostream 1 main 2 n 4, 5 of 5 the 5 to 5 void 2

7-Gestin de proyectos Las principales funcionalidades de un gestor de proyectos son: y Posibilidad de parametrizacin o personalizacin de las opciones de utilizacin del programa (opciones de clculo, seleccin de datos a visualizar, etc.).

y y y y y y y y y y

Presentacin de diferentes vistas del proyecto (por tareas, por recursos, por fechas...). Definicin de calendario a nivel de proyecto y de recurso. Establecimiento de diferentes relaciones entre tareas (final- inicio, finalfinal, inicio-inicio). Facilidades grficas para la planificacin (diagrama de GANTT, diagrama de PERT). Resolucin de conflictos de los recursos. Facilidades para la impresin de programas de trabajo. Posibilidad de desarrollar macros. Conexin entre varios proyectos. Facilidades de importacin / exportacin. Facilidad de comunicacin con otras herramientas (hojas de clculo, aplicaciones grficas, correo electrnico, etc.). Ejm: Planner
Una aplicacin multiplataforma de administracin de proyectos.

8-Gestin de la Configuracin Las principales funcionalidades de una herramienta de gestin de la configuracin son: y Identificacin de cada uno de los elementos de la aplicacin: nmero de versin e informacin de carcter general. y Soporte para jerarquas de elementos. y Control de versiones. Utilizacin de tcnicas de bloqueo de objetos o cdigo para evitar actualizaciones simultneas por varios desarrolladores. y Definicin de las configuraciones. Criterio que se sigue para seleccionar elementos de una versin. y Posibilidad de recuperacin de versiones anteriores de determinados objetos o partes del cdigo.

8.1Gestin de Configuracin de Software Software Configuration Management (SCM) ?Consiste en identificar, organizar y controlar los cambios al producto que se desarrolla ?SCM cubre el proceso completo ?Configuracin del software corresponde a todos los artefactos que se producen durante el desarrollo y mantencin ?Para administrar el cambio: baselines, o lneas base, hitos en el desarrollo y que constituyen los temes de la configuracin ?Los cambios se hacen sobre una copia del baseline

Actualmente los siguientes sistemas se ofrecen en el mercado: AccuRev Perforce ClearCase Plastic SCM SpectrumSCM Surround SCM Sablime Smart Bear

9-Herramientas de prueba. Herramientas de ayuda en las pruebas Los principales componentes de una herramienta de ayuda a las pruebas y sus funcionalidades son: y Utilidades de datos. Describen las caractersticas de los datos implicados en la prueba del software. y Simuladores. Permiten representar partes del sistema no desarrollado todava o simular la interaccin del mismo con otros sistemas o con el usuario final. y Trazadores. Permiten seguir paso a paso el funcionamiento de un determinado proceso e introducir paradas dentro de la ejecucin para analizar el contenido de variables. y Sistemas de captura y repeticin. Permiten capturar datos para utilizarlos como entrada de un proceso, interceptar el flujo de ejecucin de un programa, retener una secuencia de acciones desde el teclado o ratn y repetirlos posteriormente. y Comparadores de datos. Sirven para comparar los resultados esperados de la prueba con los obtenidos. Estos componentes o mdulos pueden formar parte de una misma herramienta de ayuda, las pruebas, o pueden ser herramientas independientes entre s. 9.1Tipos de pruebas - Pruebas unitarias - Pruebas funcionales - Pruebas de Integracin

-Pruebas de validacin - Pruebas de sistema - Caja blanca (sistemas) -Caja negra (sistemas) Pruebas de aceptacin -Pruebas de regresin -Pruebas de carga -Pruebas de prestaciones -Pruebas de recorrido -Pruebas de mutacin -Pruebas concurrentes
CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

10-Generador de cdigo fuente Normalmente, se suele utilizar sobre ordenadores personales o estaciones de trabajo, por lo que el paso posterior del cdigo al host puede traer problemas, al tener que compilar en ambos entornos. Las caractersticas ms importantes de los generadores de cdigo son: y y y Lenguaje generado. Si se trata de un lenguaje estndar o un lenguaje propietario. Portabilidad del cdigo generado. Capacidad para poder ejecutarlo en diferentes plataformas fsicas y/o lgicas. Generacin del esqueleto del programa o del programa completo. Si nicamente genera el esqueleto ser necesario completar el resto mediante programacin. Posibilidad de modificacin del cdigo generado. Suele ser necesario acceder directamente al cdigo generado para optimizarlo o completarlo. Generacin del cdigo asociado a las pantallas e informes de la aplicacin. Mediante esta caracterstica se obtendr la interface de usuario de la aplicacin. El mdulo generador de la documentacin se alimenta del repositorio para transcribir las especificaciones all contenidas. Algunas caractersticas de los generadores de documentacin son: Generacin automtica a partir de los datos del repositorio, sin necesidad de un esfuerzo adicional. Combinacin de informacin textual y grfica, lo que hace ms fcil su comprensin. Generacin de referencias cruzadas. Con ello se podr localizar fcilmente en qu partes de la aplicacin se encuentra un determinado objeto o elemento, con el fin de analizar el impacto de un cambio o identificar los mdulos afectados por un determinado error.

y y

y y y y y

Ayuda de tratamiento de textos. Facilidad para la introduccin de textos complementarios a la documentacin que se genera de forma automtica. y Interface con otras herramientas: procesadores de textos, editores grficos, etc. 10.1EntiPro y Da flexibilidad para el diseo de las plantillas. Las plantillas sirven como base para generar los archivos de cdigo fuente,

11-Herramientas de estimacion : ANGEL Herramienta para estimar esfuerzo por analoga (Shepperd et al., 1996) 20 atributos a comparar de 21 proyectos necesitaron 42 horas de computacin 12 atributos utilizaron 10 minutos para el mismo nmero de proyecto cas ms importantes sern analizadas en el apartado de otras herramientas Mdulos propensos a fallos Deteccin de mdulos propensos a fallos (Zage, Zage y Wilburn, 1994): Proponen dos mtricas de medida de la calidad deldiseo: De, para medir la calidad del diseo de un mdulo, desde el punto de vista de sus relaciones con el exterior Herramientas de Tests - Test Complete: carga HTTP, stress, pruebas de escalabilidad, - pruebas de unidad http://www.automatedqa.com - Quick Test: tests funcionales, de regresin, de aceptacin - http://www.mercury.com - CACTUS: tests de unidad para cdigo Java en el servidor - (EJB, servlets, etc.) http://jakarta.apache.org/cactus/

II-Metodologas y Gestin del Mantenimiento

El objetivo de MANTEMA es convertir el mantenimiento de software en un proceso controlable y mensurable mediante laidentificacin y definicin clara de todos los elementos (software, documentos, personas, tareas...) que intervienen en el mantenimiento. MANTEMA ha sido desarrollada entre el Grupo Alarcos del Departamento de Informtica de la Universidad de Castilla La Mancha y Atos ODS. 1- Planteamiento de la metodologa MANTEMA aborda por entero el problema del mantenimiento, intentando disminuir los costes de todas sus actividades. Para conseguirlo, una de las primeras tareas que debe completarse es la definicin clara del conjunto de actividades que se deben ejecutar a lo largo del proceso de mantenimiento. En este sentido, es til seguir las recomendaciones de ISO/IEC 12207 [ISO/IEC, 1995], IEEE 1219 [IEEE, 1993], o Pressman [1993], que abogan por ejecutar cada peticin de modificacin segn el tipo de mantenimiento que le corresponda. Por ello, en MANTEMA se definen cinco tipos diferentes de mantenimiento, cada uno con un conjunto diferentes de tareas: 1. Correctivo urgente, que tiene lugar cuando existe un error en el software que bloquea el funcionamiento normal de la organizacin o de la aplicacin, siendo crtico el tiempo de solucin. 2. Correctivo no urgente, que ocurre cuando existe un error en el software que no es crtico, pero que tal vez impida el funcionamiento de la aplicacin o el normal funcionamiento de la empresa en un periodo de tiempo relativamente corto. 3. Perfectivo, que tiene lugar cuando se van a aadir nuevas caractersticas o funcionalidades al software en explotacin. 4. Adaptativo, que se aplica cuando el software en explotacin va a cambiarse para que contine funcionado correctamente en un entorno cambiante. 5. Preventivo, que es aplicado cuando se desea mejorar las caractersticas internas de un producto para hacerlo, por ejemplo, ms fcilmente mantenible. tipos de mantenimiento bajo una nica denominacin

- mantenimiento planificable, -Mantenimiento no planificable al correctivo urgente.

2-Conjuntos adicionales de actividades: En el primero, Actividades y tareas iniciales comunes, se engloban todas las actividades que deben ser ejecutadas al comenzar el proceso de mantenimiento y que sern anteriores a la ejecucin de cualquier intervencin. El segundo, Actividades y tareas finales comunes, agrupa las actividades que sern realizadas tanto al finalizar el proceso de mantenimiento como aquellas que sern ejecutadas con posterioridad a las intervenciones, independientemente de su tipo.

CAPITULO VII I-PROCESOS DEL MANTENIMIENTO Ciclo de vida segn el ISO/IEC 12207: Determinacin de la necesidad (tcnica, operacional y econmica). Definicin del concepto (prototipo, borrador de requisitos, etc.). Demostracin. Desarrollo. Produccin. Entrega/Venta. Operacin. Mantenimiento y Soporte. Se divide en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos. 2-Procesos principales Estos procesos principales son parte importante durante el ciclo de vida de un software desde su concepcin hasta su retirada. Estos procesos se dividen en cinco y son los siguientes: 2.1Proceso de adquisicin: Son las actividades o tareas del adquiriente u organizacin para adquirir un sistema. Este proceso se implementa cuando la organizacin requiere de la compra de un producto software para el funcionamiento de su negocio.

2.2 Proceso de suministro: Son las actividades del proveedor, organizacin que proporciona un sistema producto o servicio software al cliente.Este proceso se implementa para aquellas organizaciones que se dedique a desarrollar software para un tercero o para una unidad interna de la misma organizacin que brinde servicios a otras reas. 2.3Proceso de desarrollo:Aqu se encuentran las actividades del desarrollador (implementacin del software, instalacin del software, apoyo a la aceptacin del software, anlisis de los requisitos del sistema, diseo de la arquitectura del sistema, integracin del sistema, pruebas de calificacin del sistema, anlisis de los requisitos del software, diseo de la arquitectura del sistema, diseo detallado del software, integracin del software, pruebas de calificacin del software, codificacin y pruebas del software). 2.4-Proceso de operacin: Actividades realizadas por el operador y proporciona el servicio de operar un sistema informtico en su entorno real . 2.5-Proceso de mantenimiento: Son las actividades realizadas por el encargado del mantenimiento, servicio del mantenimiento de software, las modificaciones al software para mantenerlo actualizado y operativo.

3- Procesos de soporte Los procesos de apoyos son aquellos que apoyan a otro proceso como parte importante del mismo. Un proceso de apoyo se emplea y ejecuta por otro proceso, segn sus necesidades. 3.1Proceso de documentacin: Es un proceso para registrar la documentacin producida por un proceso o actividad del ciclo de vida. El proceso contiene el conjunto de actividades para planificar, disear, desarrollar, producir editar, distribuir y mantener aquellos documentos que necesitan todos los involucrados tales como gerentes, ingenieros y usuarios del sistema o producto software. 3.2Proceso de gestin de configuracin: Es el procesos de aplicar procedimientos tcnicos y administrativos a lo largo del ciclo de vida del software para identificar, definir y establecer la lnea base de los elementos software en un sistema; controlar modificaciones, registrar e informar del estado de los elementos y peticiones de modificacin; asegurar la completitud, consistencia y correccin de los elementos; y controlar el almacenamiento, manipulacin y entrega de los elementos.

3.3Proceso de aseguramiento de la calidad: Aporta la seguridad que los procesos y producto, cumplen con los requisitos especficos. El aseguramiento de la calidad puede ser interno o externo dependiendo de si la evidencia de la calidad del producto o proceso se les demuestra a los gerentes del proveedor o adquiriente. 3.3Proceso de verificacin: Este proceso se usa para determinar si un producto software de una actividad cumplen con los requerimientos o condiciones que tienen impuestas por las actividades precedentes. 3.4Proceso de validacin: Sirve para determinar si el sistema o los productos software y los requerimientos tal como se han construido cumplen con su uso especfico previsto. Este proceso se puede llevar a cabo como parte del apoyo a la aceptacin del producto. 3.5Proceso de revisin conjunta: Define las actividades para evaluar el estado y productos de una actividad. Este proceso puede ser empleado por cualquiera de las dos partes, donde una de las partes revisa a la otra parte de una manera conjunta. 3.6Proceso de auditora: Es un proceso para determinar el cumplimiento con los requerimientos, planes y contrato, segn aplique. Puede ser empleado por cualquiera de las dos partes, donde una de ellas (la auditora) audita los productos software o actividades de la otra parte (la auditada). 3.7Proceso de resolucin de problemas:Es un proceso para analizar y resolver problemas cualquiera que sea su naturaleza u origen que se descubran durante la ejecucin de los procesos de desarrollo, operacin, mantenimiento y otros. 4-Procesos organizacionales Se emplean por una organizacin para implementar y establecer una infraestructura mejorada continuamente formada por personal y procesos asociados al ciclo de vida. 4.1Proceso de gestin:Contiene tareas genricas y tareas que pueden ser empleadas por cualquier parte que tenga que gestionar sus respectivos procesos. 4.2Proceso de infraestructura: Es un proceso para establecer y mantener la infraestructura que necesita cualquier otro proceso. La infraestructura puede incluir hardware, software, herramientas, tcnicas normas e instalaciones para el desarrollo, operacin o mantenimiento. 4.3Proceso de mejora: Este proceso de mejora de proceso es un proceso para establecer, evaluar, medir controlar y mejorar un proceso del ciclo de vida del software.

4.4 Proceso de formacin:El proceso de formacin sirve para proporcionar y mantener un personal formado. 5-Proceso de adaptacin Este proceso permite realizar la adaptacin bsica de la norma ISO a distintos proyectos de software, teniendo en cuenta las variaciones en las polticas y procedimientos organizacionales, los mtodos y estrategias de adquisicin, el tamao y complejidad de los proyectos, los requisitos de sistema y mtodos de desarrollo, etc. 6-Actividades y tareas del proceso demantenimiento El Proceso de Mantenimiento contiene las actividades y tareas necesarias para modificar un producto software existente conservando su integridad. Establecer una organizacin de mantenimiento, prescribir procedimientos de evaluacin y de informacin, definir una secuencia estandarizada de sucesos para cada peticin, establecer un sistema de registro de informacin de las actividades, definir criterios de revisin y de evaluacin de las tareas de mantenimiento. Tareas  Unidad de mantencin  Documentos estndar  Flujo de eventos  Registro  Evaluacin Las actividades que comprende el Proceso de Mantenimiento son: 6.1 Implementacin del proceso:Durante la Implementacin del Proceso, el encargado del mantenimiento establece los planes y procedimientos a ejecutar durante el Proceso de Mantenimiento. 6.2 Anlisis de problemas y modificaciones: Esta actividad consiste en analizar los problemas o peticiones de modificacin con el fin de evaluar su impacto en el sistema y la organizacin existentes, determinando el tipo de modificacin (preventiva, correctiva, etc.), su alcance (tamao, coste, tiempo, etc.) y su criticidad (rendimiento, seguridad, etc.). 6.3 Implementacin de las modificaciones: En esta actividad se incluyen todas las tareas relativas a determinar qu documentacin, unidades de software y versiones deben modificarse, y se utiliza el proceso de desarrollopara implementar las modificaciones. 6.4 Revisin y aceptacin del mantenimiento: sta actividad asegura que las modificaciones al sistema se han hecho de forma correcta y de acuerdo a los estndares aprobados dentro del uso de una metodologa correcta.

6.5Migracin: Durante la vida de un sistema, puede que haya que modificarlo para ejecutarlo en entornos diferentes. Para migrar un sistema a un nuevo entorno, el mantenedor necesita determinar las acciones necesarias para conseguir la migracin y a partir de ah desarrollar y documentar los pasos necesarios para efectuar la migracin. 6.6Retirada de software: Una vez que el producto ha alcanzado el final de su vida til debe retirarse. Se debera hacer un anlisis para ayudar en la toma de la decisin de retiro de un producto software 7-FASES DEL DESARROLLO EN EL MANTENIMIENTO DEL SOFTWARE Este estndar define cambios en un producto software a travs de un proceso de mantenimiento dividido en fases, se detallan a lo largo del estndar, indicando en cada una los elementos de los que se dispone al empezar, estas fases son: 7.1IDENTIFICACIN, CLASIFICACIN Y PRIORIZACIN DELPROBLEMA: En esta fase se identifican, clasifican y asignan una prioridad inicial a las modificaciones del software. En esta fase los procedimientos a seguir son: y Asignacin de un Nmero de Identificacin. y Clasificacin del tipo de mantenimiento. y Anlisis de la modificacin para determinar si se acepta, se deniega o se evala. y Realizar una estimacin preliminar de la magnitud de la modificacin. y Priorizar la modificacin. y Asignar Solicitudes de Modificacin a bloques de tareas planificadas para su implementacin. 7.2- ANLISIS: En esta fase se estudia la viabilidad y el alcance de las modificaciones, que ya tenemosclasificadas y priorizadas, as como la generacin de un plan preliminar de diseo, implementacin, pruebas y liberacin del software. La informacin que se va a utilizar en estafase proviene del repositorio y de la Solicitud de Modificacin validada en la fase anterior, adems de la documentacin del proyecto y del sistema existente. 7.3 -DISEO: A partir de toda la documentacin existente del proyecto y del sistema que est en produccin, as como todo el cdigo fuente y las bases de datos de la ltima versin, se va a realizar el diseo de las modificaciones del sistema en base a la documentacin generada en la fase de anlisis (anlisis detallado, informe de requisitos, identificacin de los elementos afectados, estrategia de pruebas y plan de implementacin). 7.4 IMPLEMENTACIN: Para dirigir apropiadamente el esfuerzo en la fase de implementacin ser necesario disponer, como en las otras fases, de la documentacin actualizada del proyecto y del sistema, del cdigo fuente actual, y

los resultados de la fase de diseo. Otros elementos necesarios para el xito de esta fase sern: y Documentacin de diseo y requisitos aprobados y controlados. y Estndar de codificacin acordado para ser utilizado por el grupo de mantenimiento. y Mtricas de diseo que podran ser aplicables en la fase de implementacin (podranclarificar la complejidad del cdigo a desarrollar o mantener). y Una planificacin de desarrollo detallada, incluyendo todas las revisiones de cdigo que se harn y a qu nivel. y Un conjunto de respuestas a los riesgos identificados en las fases anteriores y que sern aplicables en la fase de pruebas. 7.5 -PRUEBAS DEL SISTEMA:Las pruebas de sistema se realizan sobre un sistema modificado. Deberan ser realizadaspor una organizacin independiente y siempre estar presente el cliente y el usuario final. Para realizar las pruebas de sistema dispondremos de toda la documentacin generada a tal efecto en las fases anteriores que son: y Informe de revisin de disponibilidad de pruebas y Plan de pruebas de sistema y Casos de pruebas de sistema y Procedimientos de prueba del sistema y Manuales de usuario y Diseo 7.6 PRUEBAS DE ACEPTACIN: Al igual que las pruebas de sistema, las pruebas de aceptacin sern realizadas sobre un sistema completamente integrado. Estas pruebas se realizan por el cliente, por el usuario o porun tercero designado por el cliente. Se llevan a cabo para asegurar que el resultado de las modificaciones es satisfactorio para el cliente, tanto del software como de la documentacin generada. 7.7 PUESTA EN PRODUCCIN: Una vez probado completamente el sistema, estamos a punto de pasar a la fase de liberacin de la versin modificada. Los pasos a seguir para instalar la nueva versin sern los siguientes: y Conducir una Auditora de Configuracin Fsica (PCA, PhysicalConfigurationAudit). Ser necesario organizar y documentar la auditora segn el estndar IEEE1028-1988. y Notificar a la comunidad de usuarios. y Desarrollar una versin de archivo del sistema para salvaguarda del mismo. y Realizar la instalacin y formacin para el cliente. Se ha de proveer del material de sistema necesario para facilitar la utilizacin a los usuarios. y Se ha de completar la Documentacin de Descripcin de la Versin (VDD, VersionDescriptionDocument), segn el estndar IEEE 1042-1987. y Hay que actualizar el estado de la base de datos de cuentas y auditora. y Y finalmente, hay que poner todo bajo el control de la Gestin de Configuracin delSoftware.

8-ESTANDARES DE MANTENIMIENTO Existen diversos estndares de otros tantos organismos internacionales de estandarizacin que tienen una relacin directa o indirecta con el Mantenimiento del Software: y Para los procesos del ciclo de vida del software: IEEE 1074 e ISO 12207. y Para la calidad del software y sus mtricas: IEEE 1061 e ISO 9126. y Para el Mantenimiento del Software: IEEE 1219 e ISO/IEC 14764 8.1IEEE 1074 El IEEE 1074-1995, Developing Software LifeCycleProcesses, detalla el conjunto de actividades que aparecen obligatoriamente en el desarrollo y mantenimiento del software. La clasificacin se realiza dependiendo de que los procesos sean de gestin de proyectos, antes del IEEE 1219-1992: Standard for Software Maintenance, durante el desarrollo, despus del desarrollo o durante todo el ciclo de desarrollo de un producto software. 8.2ISO 12207 En este estndar publicado en 1995, ISO/IEC 12207 International Standard froInformationTechnology Software LifeCycleProcesses, se define el proceso de mantenimiento como una parte principal del ciclo de vida del software. En l se definen los procesos, actividades y tareas presentes en la adquisicin, suministro, desarrollo, operacin y mantenimiento del software. 8.3 IEEE 1061 El IEEE 1061 Standard for a Software QualityMetricsMethodologyprovee una metodologa para establecer requerimientos de calidad e identificar, implementar, analizar y validar mtricas de calidad de productos y procesos software. La metodologa es aplicable a todo el software en todas las fases de cualquier estructura de ciclo de vida. En este estndar se establece la mantenibilidad como uno de los factores de la calidad del software. 8.4ISO 9126 En la nueva revisin de 1998 del estndar ISO 9126 Software QualityCharacteristics and Metrics, se abordan las caractersticas que determinan la calidad del software, tanto del producto como de los procesos para desarrollarlo y mantenerlo.

8.5 IEEE 1219 Este es el estndar objeto del documento, IEEE 1219 Standard for Software Maintenance. Hasta 1998, nico estndar que ntegramente se ocupa del proceso de Mantenimiento del Software. En l se detalla un proceso iterativo para gestionar y realizar las actividades de mantenimiento. 8.6 ISO/IEC 14764 Este es el estndar especfico sobre Mantenimiento del Software que publico ISO en 1998. Como todos los estndares, el acceso de su lectura est restringido a aquellos que son miembros de la organizacin, o pagan por hacerlo. Al igual que pasa con los dems estndares, en estos documentos nicamente se especifica cules deben ser las actividades y tareas del proceso de mantenimiento pero no se indica cmo realizarlas.

9-Criterios para seleccionar y evaluar un software de mantenimiento(punto de vista del cliente) Como sugerencia indicamos, en el listado presentado a continuacin, algunas caractersticas que deben ser observadas en la seleccin de software de mantenimiento: 1.- Que el proveedor tenga los programas fuente para venderlos, en caso de inters del cliente(naturalmente bajo criterios que eviten la comercializacin del sistema por el cliente o por cualquiera de susfuncionarios); 2.- Que el sistema opere en el ambiente o plataforma utilizado por la empresa as como tenga las caractersticas de un mono multiusuario, de acuerdo con la necesidad; 3.- Que el proyectista sea un experto en mantenimiento y que contine produciendo nuevas versiones; 4.-Que el sistema sea de fcil operacin no exigiendo, en consecuencia, la participacin de ingenieros o tcnicos especializados para la ejecucin de sus tareas cotidianas. 5.- Que el sistema pueda ser comercializado de forma modular, pero sin exigir ninguna adecuacin a medida que sean adquiridos nuevos mdulos y que sea de fcil navegabilidad entre las pantallas, ventanas y mdulos. 6.- Que los cdigos sean compuestos por clulas para permitir selecciones o filtros en los reportes y listados y adems que el contenido de esas clulas sean establecidas por el propio usuario, a partir de las tablas patrones para sus necesidades; 7.- Que la recoleccin de datos de mano de obra sea independiente de las rdenes de trabajo de forma que permita su implementacin en cualquier momento; 8.- Que exista la posibilidad de integrar los sistemas de gestin de material de forma que el sistema de mantenimiento informe al sistema de material las necesidades para los servicios programables y hasta inicie el proceso de

reposicin de stocks y el sistema de material provea al sistema de mantenimiento, los costos de repuestos y material de uso comn; 9.- Que sea posible monitorear servicios de terceros, tanto a travs de contratos permanentes y globales como a travs de servicios eventuales. 10.- Que existan niveles de acceso para restringir algunas operaciones slo a usuarios acreditados como, por ejemplo, recuperacin de datos de back-up, operacin con sueldos, acceso a reportes confidenciales, exclusin de informaciones de los archivos, etc.; 11.- Que la capacidad de memoria (RAM) necesaria para el procesamiento del sistema, sea compatible con la disponible en los equipos de la empresa as como la capacidad del almacenaje de datos por perodos de consulta definidos por el usuario y la creacin de archivos muertos a partir de plazos tambin definidos por el usuario; 12.- Contestacin rpida a consultas cuando los archivos estn muy cargados de informaciones. En este caso es recomendable analizar el tiempo de procesamiento cuando los archivos ms usuales llegan a ocupar ms de 1Mbyte de capacidad. 13.- Garanta de ejecucin de back-up automticamente, de forma eficiente, rpida y compactada; 14.- Que sea permitido cambiar ttulos y leyendas para personalizar las informaciones de la empresa (as como cambios de idioma); 15.- Que sea permitido crear nuevos reportes de acuerdo con la necesidad del usuario a partir de los datos existentes en los archivos. 16.- Atender la gestin de costos, de material (en el nivel de mantenimiento) y de mano de obra de acuerdo con las reales necesidades del usuario; 17.- Posibilidad de implementacin de recursos de sistema experto con mdulo de mantenimiento predictivo, alertas a la gerencia de mantenimiento y nivelacin de recursos de mano de obra: 18.- Que los costos sean adecuados y los pagos puedan ser hechos de forma parcial, o sea de acuerdo con la implementacin de cada mdulo. 10-Tipos de evaluacin Las pruebas o tests asegurar la conformidad de los cambios aprobadoscon los requisitos originales. Las actividades principales de las pruebas son las siguientes: Pruebas manuales Pruebas automatizadas Pruebas de integracin Pruebas del sistema Pruebas de aceptacin 10.1Tipos de Test 10.1.1Tests de Software

y y y

Las pruebas de software o tests son imprescindibles en los procesos de mantenimiento y desarrollo del software. Despus de un proceso de mantenimiento o desarrollo es fundamental probar el software modificado o desarrollado. De un correcto diseo de las pruebas a realizar dependern los resultados que obtengamos.

10.1. 2TESTS EN MANTENIMIENTO versus TESTS EN DESARROLLO y Slo necesitan revisarse los cambios, no el producto completo. y Slo necesitan implementarse casos de tests para los cambios realizados. y Los resultados del test pueden ser comparados de forma automtica frente a resultados previos para identificar variaciones (tests de regresin). 10.1.3Ventajas de los Tests Incrementales y Los mantenedores del sistema pueden realizar tests incrementales al principio del ciclo de mantenimiento para eliminar defectos de las fases de requisitos y diseo. y Los errores de programacin se detectan temprano. y Los procesos de depuracin (debugging) son ms fciles. Los test son ms minuciosos dado que los mdulos estn sujetos a ms tiempo de prueba.

Capitulo IX
1-Conclusiones La criticidad que ha alcanzado el software hoy en da es de suma importancia ya que por la complejidad cada vez creciente del software, y la poca importancia que se le ha dado al mantenimiento ha repercutido en los costos altos de mantenimiento .El mantenimiento en el software se debe dar de manera continua y hasta puede comenzarse antes del trmino de la fase de desarrollo. Cabe resaltar que no necesariamente los desarrolladores harn el mantenimiento del sistemas (en la mayora de empresas no sucede eso).Las tcnicas y metodologas que se desarrollan en el mantenimiento del software pueden cambiar el rumbo de la empresa y adaptarla a los nuevos modelos metodolgicos y tecnologas pero tambin traen posibles problemas si no se analiza correctamente (efectos secundarios). La gestin de procesos cumple un papel analtico fundamental el cual nos dar la forma de detectar problemas de proceso y a la vez nos dara algunas pautas referidas a los estandares. La estimacin se har de poco a poco de estimaciones ms cercanas o subjetivas hasta estimaciones basadas en base

a el requerimiento y pruebas del software. Las mtricas de estndares darn una mejor solucin pero se debe saber cmo adaptar estos pasos. La evaluacin y documentacin continua posibilitaran el mantenimiento. La conservacion de la calidad del software es el fin del mantenimiento 2-Bibliografa 1. Martnez Prraga, Juan Angel. PLANIFICACIN Y GESTIN DE SISTEMAS DE INFORMACIN. Mayo de 1999.43p. 2. DOMINGUEZ AJENJO, Alberto. Direccin y Gestin de Proyectos. Un enfoque prctico. Editorial: Alfa Omega Grupo Editor SA. Colombia. 282390 pp. 3. INDECOPI. Norma Tcnica Peruana NTP-ISO/IEC 12207. Tecnologa de la Informacin. 2 Edicin. 2006-07-13. 189 pp. 4. DAVILA, Abraham. NTP-ISO/IEC 12207:2003 Procesos Del Ciclo de Vida Del Software. 2005. 70 pp. 5. INDECOPI. GI-NTP - 008: 2009. Procesos del ciclo de vida del software. 1ra. Edicin. Lima, Per. 23 pp. 6. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n3. 7. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n4 8. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n5. 9. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n8. 10. ANA M MORENO S.- CAPUCHINO. ESTIMACIN DE PROYECTOS SOFTWARE.87p. 11. MANTENIMIENTO DE APLICATIVOS DE SOFTWARE.Oficina de Tecnologia para la Administracion Pblica. 12. Somerville, Ian (2002) Ingeniera de software, 6a edicin. Addison Wesley. 13. Pressman, S Roger (1998) Ingeniera del Software: Un enfoque prctico, 5a edicin McGraw-Hill 40 Hill. 14. Piattini, M., Villalba, J., Ruiz, F., Fernndez, I., Polo, M., Bastanchury, T., Martnez, M.A., 1998. Mantenimiento del Software. Conceptos, mtodos, herramientas y outsourcing. Ra-ma editorial, Madrid. 15. ANA M MORENO S.- CAPUCHINO. COCOMO II.55p.
16. PRESIDENCIA DEL CONSEJO DE MINISTROS (PCM).2004.NTP ISO/IEC 12207 TECNOLOGA DE LA INFORMACIN. Procesos del Ciclo de Vida del Software. http://www.pcm.gob.pe/

17. COMPUTER SOCIETY Guide to the Software Engineering Body of Knowledge. 2004 Version. http://www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf 18. Pedraza, G. et al., III Congreso Colombiano de Computacin. Evolucin

e Integracin de Aplicaciones. Legadas: Comenzar de Nuevo o Actualizar? Medelln, Abril 23 25 de 2008.

19. Arnold, R.S.; Software Reengineering, IEEE Computer Society Press, 1993. 20. Tilley, Scott R. & Smith, Dennis B. Perspectives on Legacy Systems Reengineering (draft). Reengineering
Center, Software Engineering Institute, Carnegie Mellon University. 1995.

21. SICILIA, Miguel ngel. Mantenimiento del Software como Actividad de

Ingeniera_Evolucin del Software. [en lnea]. 25 octubre 2011.n

http://cnx.org/content/m17401/1.3/. [consulta: 25 octubre 2011] 22. SICILIA, Miguel ngel. Definiciones de Mantenimiento del Software Evolucin del Software. [en lnea]. 25 octubre 2011.n http://cnx.org/content/m17404/1.3/. [consulta: 25 octubre 2011] 23. SICILIA, Miguel ngel. Mantenimiento en el ciclo de vida del Software. [en lnea]. 24 noviembre,2008. n http://cnx.org/content/m17407/1.3/. [consulta: 24 noviembre, 2008.] 24. SICILIA, Miguel ngel. Leyes de la Evolucin del Software. [en lnea]. 24 noviembre, 2008.n 2. http://cnx.org/content/m17406/1.3/. [consulta: 25 octubre 2011] 25. SICILIA, Miguel ngel. Evolucin del Software. [en lnea]. 24 noviembre, 2008.n http://cnx.org/content/m17405/1.3/. [consulta: 25 octubre 2011] 26. SICILIA, Miguel ngel. Tipos de Mantenimiento. [en lnea]. 24 noviembre, 2008.n http://cnx.org/content/m17408/1.3/. [consulta: 25 octubre 2011] 27. 2000/2001. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n9. 28. 2000/2001. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n1. 29. Sneed, H.M., Economics of Software Re-engineering. Journal of Software Maintenance, vol. 3, n 3, 1991, pp. 163-182. 30. Braude Eric J. (2003) Ingeniera de Software Una perspectiva orientada a objetos, AlfaomegaInce (1994) Detalles de ISO Oskarrson y Glass (1995) Detalles de ISO 31. Bowen, Jonathan - Stavridou, Victoria: "Safety-Critical Systems, Formal Methods and Standards"; submitted to the Software Engineering Journal, may 1992. 32. Jacobson, Ivar: "Object-Oriented Software Engineering", AddisonWesley, 1994. 33. Singer, J. Practices of Software Maintenance. Proceedings of the International
Conference on Software Maintenance (pp. 139-145). Los Alamitos, 34. California: IEEE Computer Society.

35. S. Humphery, Watts: "Managing the Software Process", AddisonWesley, 1989. 36. IEEE. 1993. IEEE Standard for Software Maintenance. IEEE STD 12191993. Institute of Electrical and Electronics Engineers, inc., New York, NY. 37. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n6. 38. RODRGUEZ HERNNDEZ, DAVID. CONTEXTO DE LA ASIGNATURA EN INGENIERA DEL SOFTWARE.14p. 39. Jimnez Fernndez,D. MANTENIMIENTO PLANIFICADO Y PROGRAMADO. www.mantenimientoplanificado.com. 40. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n7. 41. 2000/2001 Informe de Mantenimiento del Software. [Ciudad Real]: Francisco Ruiz, Macario Polo. Mantenimiento del Software. Ciudad Real, 2000/2001. Serie, n2. 42. BARRA P, Carlos. Software e Ingeniera de Software. 43. Francisco Ruiz, Macario Polo. Mantenimiento Software. 44. Piattini, M. G., Daryanani, S. N., Elementos y Herramientas en el Desarrollo de
Sistemas de Informacin. Ed. RA-MA, 1995.

3-Glosario de trminos     Adaptabilidad:Facilidad con la que un sistema o un componente puede modificarse para corregir errores, mejorar su rendimiento u otros atributos, o adaptarse a cambios del entorno. Aplicacin de software: Software diseado para satisfacer las necesidades de un usuario. Contrasta con: software de soporte; software de sistema Adquisicin: El proceso de obtener un sistema, producto software o servicio software. Auditora de configuracin: Exmenes independientes de tems de la configuracin y actividades para evaluar cumplimiento de criterios establecidos Baseline: Producto formalmente revisado y aprobado, base para futuros desarrollos, puede ser modificado solo a travs de un procedimiento formal de control de cambios Ciclo de vida: Periodo de tiempo que comienza con la concepcin del producto de software y termina cuando el producto est disponible para su uso. Normalmente, el ciclo de vida del software incluye las fases de

concepto, requisitos, diseo, implementacin, prueba, instalacin, verificacin, validacin, operacin y mantenimiento, y, en ocasiones, retirada. Nota: Esta fases pueden superponerse o realizarse iterativamente.  Codificacin: (1) Proceso de descripcin de un programa de ordenador en un lenguaje de programacin. (2) Transformacin del diseo lgico y dems especificaciones de diseo en un lenguaje de programacin. Control de cambio: Proceso y procedimiento para identificar, documentar, revisar y autorizar cambios. Control de versiones: Proceso y procedimiento para identificar y gestionar temssegn cambian en el tiempo, usualmente apoyado por unaherramienta. Crisis del software. Trmino acuado en 1968, en la primera conferencia de la NATO sobre desarrollo de software, con el que se identificaron los problemas que surgan en el desarrollo de sistemas de software. Desarrollador: Organizacin que lleva a cabo actividades de desarrollo (incluyendo anlisis de los requerimientos, diseo y pruebas hasta la aceptacin) durante el proceso del ciclo de vida del software. Diseo: (1) Proceso de definicin de la arquitectura, componentes, interfaces y otras caractersticas de un sistema o de un componente. (2) El resultado de este proceso. Disponibilidad: El grado con el que se mide la accesibilidad de un sistema o de un componente cuando es necesario su uso. Suele expresarse en trminos de probabilidad. Gestin de configuracin: Disciplina que aplica la direccin y supervisin tcnica y administrativa para: identificar y documentar las caractersticas funcionales y fsicas de un elemento de configuracin, controlar cambios, registrar cambios procesados, registrar el estado de la implementacin, informar y verificar la conformidad con los requisitos especificados. Gestin de procesos: Direccin, control y coordinacin del trabajo realizado para desarrollar o producir un servicio. Implementacin: (1) Proceso de transformacin de un diseo en componentes de hardware, software o de ambos. Ver tambin: codificacin. (2) El resultado del proceso (1). Ingeniera del software: (1) Aplicacin de procesos sistemticos y disciplinados para el desarrollo, operacin y mantenimiento de software. (2) El estudio de la aplicacin (1).

 

 

Mantenimiento: (1) Proceso de modificacin de un sistema de software o de un componente, despus de su puesta en funcionamiento para corregir fallos, mejorar el rendimiento u otros atributos, o adaptarlo a modificaciones del entorno. Mantenimiento perfectivo. (2) Proceso primario del modelo de ingeniera que desarrolla tareas de mantenimiento (1). Mantenimiento adaptativo: Modificacin de un sistema de software o de un componente, despus de su puesta en funcionamiento, para adaptarlo a cambios del entorno. Contrasta con: mantenimiento correctivo; mantenimiento perfectivo. Mantenimiento correctivo: Modificacin de un sistema de software o de un componente, despus de su puesta en funcionamiento para corregir fallos. Contrasta con: mantenimiento adaptativo; mantenimiento perfectivo. Mantenimiento perfectivo: Modificacin de un sistema de software o de un componente, despus de su puesta en funcionamiento para mejorar el rendimiento u otros atributos. Contrasta con: mantenimiento adaptativo; mantenimiento correctivo. Modelo de ciclo de vida: Representacin del ciclo de vida del software. Normas: Estndar o referencia para establecer la calidad o la prctica deseable. Proceso: Conjunto de actividades mutuamente relacionadas o que interactan, las cuales transforman elementos de entrada en resultados. Producto de software. (1) Conjunto de programas, procedimiento y opcionalmente documentacin asociada que se entrega al usuario como resultado.  Uno de los elementos de (1). Propsito del proceso: El objetivo de alto nivel de realizar el proceso y los probables resultados de la implementacin eficaz del proceso. La implementacin del proceso debe proveer beneficios tangibles a los involucrados. Reestructuracin: Cambio de representacin de un producto software, pero dentro del mismo nivel de abstraccin. Retirada: Cese del soporte activo por parte de la organizacin de operacin y mantenimiento, sustitucin parcial o total por un nuevo sistema, o instalacin de un sistema mejorado. Release: Accin mediante la cual una versin particular de un producto se hace disponible para un propsito especfico

   

 

Servicio software: Ejecucin de actividades, trabajos o tareas relacionadas a un producto software, tales como su desarrollo, operacin y mantenimiento. Sistema: Conjunto de procesos, hardware, software, instalaciones y personas necesarios para realizar un trabajo o cumplir un objetivo. Sistema de software: Conjunto de programas de ordenador, procedimientos y opcionalmente la documentacin y datos asociados, necesarios para el funcionamiento de un sistema. Software de sistema: Software diseado para facilitar o permitir la operacin y el mantenimiento de un sistema informtico; por ejemplo los sistemas operativos. Contrasta con aplicacin de software y software de soporte. Software de soporte: Software de ayuda para el desarrollo o mantenimiento de otro software; por ejemplo compiladores, editores y otras utilidades. Contrasta con aplicacin de software; software de sistema. SQA: (Software QualityAssurance) Se aplica a los procesos o a las funciones encaminadas a garantizar que la organizacin realiza el trabajo de desarrollo, operacin o mantenimiento de software conforme a los procedimientos y mtodos establecidos para el proyecto. Subsistema. Sistema subordinado a otro mayor. Unidad software: Pieza de cdigo compilable por separado. Usuario: Individuo u organizacin que utiliza el sistema en operacin para llevar a cabo una funcin especfica. Trazabilidad: Grado de relacin entre dos o ms productos del proceso de desarrollo, especialmente productos que tienen una relacin de predecesor sucesor o de superior subordinado con otro. Validacin: Confirmacin mediante examen y aportacin de pruebas objetivas de que se cumplen los requisitos concretos para un uso determinado. Verificacin: Confirmacin mediante examen y aportacin de pruebas objetivas de que se cumplen los requisitos especficos. Verificacin y validacin: Proceso que determina si los requisitos de un sistema o de un componente son completos y correctos, si los productos de

 

   

 

cada fase cumplen los requisitos o condiciones marcados al inicio de la fase y si el sistema o componente final cumple con los requisitos especificados.  Anexo Correctivo Mantenimiento y el ciclo de vida Versin: Instancia de un tem de la configuracin, una vez transformado en baseline no puede ser cambiado sin crear una nueva versin

Mantena

Normas Tcnicas Peruanas NTP-ISO 9000:2001 Sistema de gestin de la calidad. Fundamentos y vocabularios 2.2.2 NTP-ISO 9001:2001 Sistemas de gestin de calidad. requisitos 2.2.3 NTP-ISO 14001:2002 Sistemas de gestin ambiental. Especificacin con orientacin para su uso 2.2.4 NTP-ISO/IEC 9126 1: 2004 Ingeniera de software Calidad de Producto Parte 1: Modelo de calidad. 2.2.5 NTP-ISO/IEC 12119:2005 Tecnologa de la informacin Paquetes Software Requerimientos de calidad y pruebas. 2.2.6 NTP-ISO/IEC 14598 1:2004 Tecnologa de la informacin Evaluacin del producto software Parte 1: Vista general 2.2.7 NTP-ISO/IEC TR 9126 2:2004 Ingeniera de software Calidad de producto - Parte 2: Mtricas externas.

2.2.8 NTP-ISO/IEC TR 9126 3:2004 Ingeniera de software Calidad de producto Parte 3: Mtricas internas