Mantenimiento y evolución del software

IntroducciónEl Proceso de Cambio de un Sistema

Actividades de MantenimientoGestión de la Configuración

Mantenimiento y Evolución del Software

M.I. Capel

ETS Ingenierías Informáticay Telecommunicación

Universidad de GranadaEmail: [email protected]

Desarrollo de SoftwareIngeniería de Software (3er curso de Grado)

M.I.Capel Tema 5 1/83



Índice1 Introducción

Tipos de sistemas y su mantenimientoMantenimiento de los sistemas softwareImportancia de la gestión correcta en el tiempo

2 El Proceso de Cambio de un SistemaComportamiento evolutivo de los sistemasPlan de Gestión de los cambiosGerencia de los cambios

3 Actividades de MantenimientoMantenimiento y evoluciónTipos de mantenimientoPlanificación del mantenimientoPredicción y evaluación del coste de mantenimientoEvolución y calidad del softwareHerramientas automáticasRejuvenecimiento del software

4 Gestión de la ConfiguraciónConceptos fundamentales y estándares actualesMarcos de trabajo y herramientas gestión de la configuración





Mantenimiento

Definición“Cualquier trabajo hecho para cambiar el sistema después deponerlo en operación"

El software no se degrada ni necesita de un mantenimiento“‘físico" periódico, como otras obras de ingenieríaSin embargo, el software está en continua evolución y elproceso de su mantenimiento puede ser muy difícil





Evolución de un sistema software

Aspectos a tratarLas funciones diarias del sistemaLas modificaciones del sistemaPerfeccionamiento de su funcionalidadConservación de los niveles de desempeño del sistema





Mantenimiento de sistemas hard y soft

Sistemas SoftwareSe diseñan e implementan para que se incorporen cambios alo largo de todo su ciclo de vida, a diferencia de los sistemashardware–exclusivos

Mutabilidad de los sistemasAlta si los requerimientos del sistema son muydependientes del contexto de ejecución del sistemaDependencia con el tipo de sistema: S, P, o E





Diferencias entre mantenimiento y desarrollo desoftware

Control de los CambiosLos cambios afectan a etapas del ciclo anteriores yposteriores a la actualModularización de componentes de códigoTrazabilidad de los requerimientos hacia/desde laspruebasAplicación de los principios de la ISEl costo del ciclo de vida de un sistema se incrementa conel paso del tiempoComportamiento evolutivo de los sistemas software





Características del mantenimiento del software

DificultadesUn difícil mantenimiento tiene un impacto importante enlos costes reales del softwareNovedad del softwarePlazo de vida del sistemaDependencia de entornos de ejecución cambiantesCalidad del diseño y del código

El esfuerzo de mantenimiento de un sistema software se puedemodelar empíricamente





Medida y estimación del esfuerzo de mantenimiento

Facilidad de mantenimiento del softwareSe trata de un atributo externo del softwareResultado de varios factores: calidad del código,especificación, diseño, documentación y plan de pruebas

MedidasPredicen la probabilidad de que un sistema sea fácil demantenerSe deberían proporcionar al cliente junto con el software





Gestión de Configuración del Sistema

Seguimiento de los cambios

Cuanto más complejo es un sistema, los cambiosproducen mayor impacto en más componentesLa gestión de la configuración (GC) de un sistema seconvierte en una actividad crítica del mantenimiento delsoftware





Técnicas y herramientas de mantenimiento software

Técnicas específicas:Control de versionesAnálisis de impactoUso de herramientas–software





Costes del Mantenimiento de Sistemas Software

Periodo Desarrollo Mantenimientoaños setenta 60% 40%años ochenta 40% 60%actualidad 20% 80%




Comportamiento evolutivo de los sistemasPlan de Gestión de los cambiosGerencia de los cambios

Tipos de Sistemas I

Figure: Mutabilidad y tipos de sistemas





Tipos de Sistemas IIPredisposición a los cambios de los sistemas

Sistemas-S:Improbabilidad de cambios en todas las fases del ciclo-Manipulación de matrices

Sistemas-P:Solución aproximada al problema que pretende resolver elsistema-Programa para jugar al ajedrez

Sistemas-E:Naturaleza altamente mutable, que cambia con rapidezSe han de incluir las mutaciones en el propio sistema paraacomodar los frecuentes cambios-Software que predice cómo funciona la Economía





Cambio en las actividades del proceso de desarrollo

Actividad que inicia cambios Artefactos a cambiarAnálisis de requerimientos Especificación de requerimientosDiseño de sistemas Especificación de diseño arquitectónico

Especificación de diseño técnicoDiseño de programas Especificación del diseño de programaImplementación de programas Código de programas

Documentación de programasPruebas unitarias Planificación de las pruebas

Scripts con las pruebas(casos,suites,etc.)Entrega del sistema Documentación del usuario

Documentación del operadorGuía del usuarioGuía del programadorClases de entrenamiento

Table: Actividades y artefactos que cambian





Control de costos asociados a los cambios

Costos del ciclo de vida:Tamaño del sistemaRecursos que gestiona el sistemaComplejidad del sistemaComprensión del código

Fácil instrumentación de los cambios si se siguen losprincipios de la IS





Leyes de comportamiento evolutivoObservaciónLos sistemas software no evolucionan caóticamente, sino quesiguen un comportamiento previsible

Leyes de Lehman de evolución del softwareComportamiento evolutivo de los sistemas softwareLey de Continuidad del CambioLey de Complejidad CrecienteLey Fundamental de la Evolución de un ProgramaLey de Conservación de la Estabilidad OrgánicaLey de Conservación de la Familiaridad





Procedimiento para decidir los cambiosPara decidir llevar a cambio un cambio en el sistema se ha deseguir un procedimiento sistemático de toma de decisiones

Figure: Determinación de la oportunidad de los cambios y cómo afectan a losrequerimientos M.I.Capel Tema 5 17/83




El Plan de Control de Cambios

Clase de elementos que componen el plan de control

Quién toma la responsabilidad de los procedimientos y lacreación de la Línea Base

Políticas de control de cambios y versiones

Almacenamiento de la información relevante

Las herramientas que deberían ser usadas

Proceso de uso de la herramienta.

Base de datos de gestión de los cambios

Información adicional





Línea Base I

AntecedentesEs un concepto que nos ayuda a controlar modificacionesen el sistema sin impedir que se lleven a cabo ningúncambio justificadoEl estándar IEEE 610.12-1990 define una línea basecomo:

Especificación o producto que se ha revisado formalmenteExiste acuerdo sobre el productoSoporte para un desarrollo posterior de otro sistemaPuede cambiarse solamente a través de procedimientosestablecidos





Línea Base II





La Base de Datos de Configuración

Mantiene toda la información relevante para gestionar laconfiguración de un sistema softwareDebería permitir consultas sobre las configuraciones:

¿Quién tiene una versión particular del sistema?¿Qué plataforma es requerida para una versión particular?¿Qué versiones se ven afectadas por un cambio en elcomponente X?¿Cuántas fallas fueron informadas desde la distribución dela versión T?

Debería estar unida indisociablemente al software queestá siendo gestionado





Gerencia de los cambios en una organizaciónTareas de mantenimiento

La aceptación de nuevos requisitos para el softwareimplica a varios niveles de la organizaciónEl equipo de mantenimiento finalmente decide si el cambiopuede ser asumido a un coste razonable

Figure: Movimiento de los requisitos de mantenimiento a través de la organización





Comité de Gestión de Cambios

1 Registra los síntomas en un formulario de solicitud de cambio.2 El cambio propuesto se informa al comité.3 Discutir el problema y determinar el motivo del cambio4 Cuando se trata de un fallo del sistema, discute el origen probable del problema5 El CCG asigna una prioridad o nivel de severidad a la solicitud6 El analista o programador designado localiza el origen del problema o los

componentes involucrados7 El responsable de los cambios trabaja en colaboración con el administrador del

sistema8 El programador o analista archiva un informe de cambio





Formulario de Solicitud de CambiosProyecto NúmeroSolicitante FechaCambio Solicitado Urgencia, motivaciónAnalizador del cambio Fecha de análisisComponentes asociadosEvaluación del cambio CostosPrioridad del cambioImplementación del cambioEsfuerzo estimadoFecha entrega Fecha de decisiónal comité del comitéDecisión del comitéImplementador del cambio Fecha del cambioFecha envío al QA Decisión del QAFecha de envío a CMComentarios

Table: Formato de Solicitud de Cambio




Mantenimiento y evoluciónTipos de mantenimientoPlanificación del mantenimientoPredicción y evaluación del coste de mantenimientoEvolución y calidad del softwareHerramientas automáticasRejuvenecimiento del software

Evolución del Ciclo de Mantenimiento

Figure: Primera versión de un sistema de software





Impacto del mantenimiento en la evolución de lossistemas software

Características mantenimiento vs. desarrollo de softwareA diferencia de la actividad de desarrollo, en el mantenimientode hay tener en cuenta etapas anteriores, actual y futura delciclo del software

Actividades para controlarFunciones diariasModificacionesPerfeccionar la funcionalidadImpedir la degradación en el desempeño





Actividades del mantenimiento

CaracterísticasTiene relación con todas las fases del ciclo de vida:

Productos anteriores de desarrollo (anteriores)Relación activa con usuarios, programadores y operadores(presente)Anticiparse a fallos (futuro)

Valoración del importante papel que juegan losprogramadores en el mantenimiento del sistema





Evolución del Ciclo de Mantenimiento II

Figure: Extensión simple de un sistema de software

CondicionesNinguno de los nuevos requerimientos afecta a laarquitectura softwareFase de Elaboración reducida





Clasificación de los tipos de mantenimiento

Clasificación para sistemas softwareMantenimiento correctivoMantenimiento adaptativoMantenimiento perfectivoMantenimiento preventivo





Mantenimiento Correctivo

CaracterísticasObjetivosFrecuenciaAfectan a los requerimientos, diseño, código, pruebas ydocumentaciónDurabilidad de los cambios y reparaciones





Mantenimiento Adaptativo

CaracterísticasObjetivosFrecuenciaDurabilidad de los cambios y reparaciones





Mantenimiento Perfectivo

CaracterísticasSe buscan oportunidades de mejora del sistemaNo tiene por qué estar dirigido por la detección de fallosPuede afectar a la documentación del sistema, a laspruebas, al diseño y a la codificación





Evolución del Ciclo de Mantenimiento III

Figure: Mantenimiento perfectivo con cambios mínimos entreiteraciones





Mantenimiento Preventivo

CaracterísticasSimilar al preventivo, ha de involucrar también lamodificación para prevenir fallosFrecuenciaAnticipación





Evolución del Ciclo de Mantenimiento IV

Figure: Versión del mantenimiento con ciclos concurrentes

CondicionesComponentes altamente cohesivos y sin acoplamientoReduce los tiempos de puesta en servicio





Temporización de los tipos de mantenimientoAntecedentes

Varía mucho dependiendo del tipo de sistema y equiposimplicadosLienz y Swanson (1981) realizaron un estudio de 487organizaciones de proceso de datos

Tipo PorcentajeCorrectivo 21 %Adaptativo 25%Perfectivo 50%Preventivo 4%

Table: Distribución del esfuerzo de mantenimiento





Mantenimiento de Sistemas Muy Grandes

Estándar ISO/IEC-IEEE 122071 Obtención de los requerimientos de mantenimiento2 Análisis del problema y de la modificación necesaria3 Transformación de los requisitos detectados en cambios4 Diseño de los cambios5 Implementación de los cambios6 Revisión y aceptación del mantenimiento7 Migración





Ciclo de Mantenimiento de RUP

Rational Unified Process1 Implementación2 Pruebas3 Despliegue del Sistema4 Configuración y Gerencia de Cambios (CGC)5 Gestión del Proyecto6 Entorno de ejecución





RUP (Rational Unified Process)

Marco de trabajo para el proceso iterativo de desarrollo desoftware creado por “Rational Software Corporation" (IBM,2003)Se trata de un marco de trabajo adaptable, pororganizaciones que se dedican al desarrollo de software,según sus necesidadesRUP es una implementación del Proceso Unificado(1251_bestpractices_TP026B)





Ciclo de Mantenimiento de RUP II





Factores determinantes del costo del mantenimiento

Impactan en el coste del mantenimiento:Tipo de aplicaciónNovedad del sistemaPlazo de vida del SistemaDependencia de un ambiente cambiante y del tipo desistemaCaracterísticas del hardwareCalidad del DiseñoCalidad del CódigoCalidad de la DocumentaciónCalidad de las Pruebas

Los costes de mantenimiento pueden haberseincrementado actualmente hasta el 80% del ciclo de vida





Predicción del coste de mantenimiento

El esfuerzo de mantenimiento se puede modelar para predecirsu magnitud y el coste de llevarlo a cabo completamente

Modelo Predictivo de Belady-LehmanDeterioro de un sistema con el tiempo por las reparacionesy perfeccionamiento de su arquitectura y códigoCuando se corrige, el sistema se vuelve más complejo:

M = p + K × c − d (0)Si un sistema se desarrolla sin los principios de la IS (altacomplejidad) y el código es difícil de comprender (baja“‘d"), los costes de mantenimiento aumentaránexponencialmente





Predicción del coste de mantenimiento II

COCOMO II

Tamano = ASLOC(AA+SU+0.4DM+0.3CM+0.3IM)/100ASLOC: número de líneas de código fuente que han de adaptarse

AA: esfuerzo de valoración y asimilación

SU: cantidad de código que ha ser comprendido necesariamente

DM: porcentaje del diseño que ha de ser modificado

CM: porcentaje de código que ha de ser modificado

IM: porcentaje de código externo que ha de ser integrado





Esfuerzo de comprensión del software (COCOMO)

Muy bajo Bajo Normal Alto Muy AltoEstructura Cohesión muy baja Cohesión moderada Bien estructurado Alta cohesión Alta modularidad

Alto acoplamiento Alto acoplamiento Con áreas débiles Bajo acoplamiento ocultación inform.Claridad Falta correlación Alguna Moderada Buena Coinciden

aplicación- programa y correlación correlación correlación aplicación-programa aplicación con programa con programa con programa -programa

Autocontenido Código poco Algún comentario Moderada Buena, Códigoclaro, sin y cabeceras calidad útil docum. y razón del

documentación documentación áreas débiles diseñoIncremento SU 50 40 30 20 10

Table: Valoración de la comprensión del código





Esfuerzo de evaluación y asimilación (COCOMO)

Incremento de Nivel del esfuerzoEvaluación y de Evaluación y

Asimilación (AA) Asimilación (AA)0 Ninguno2 Búsqueda componentes

y evaluación documentación6 Bastante prueba de componentes y

y evaluación de documentación8 Prueba extendida de componentes y

y evaluación de documentación

Table: Valoración del esfuerzo de asimilación de un software





Medida de la facilidad de mantenimiento

Facilidad de mantenimientoDefinición: “Tiempo medio para realizar la reparación deun software"Factores necesarios externos a evaluar:

Momento en que se dá parte del problemaRetrasos administrativosTiempo de análisis del problemaTiempo para especificar los cambiosTiempo necesario para hacer los cambiosTiempo para probar los cambiosTiempo para documentar los cambios

Visión externa, deja cosas fuera





Medida de la facilidad de mantenimiento II

Medidas aconsejadas después de los cambiosRelación entre el tiempo total de implementación delcambio y la cantidad total de cambios realizadosNúmero de problemas no resueltosTiempo gastado en problemas no resueltosEl porcentaje de cambios que introducen nuevos defectosEl número de componentes modificados para implementarun cambio

Son dependientes del entorno





Medida del Mantenimiento III

Figure: Tiempo medio para reparar varios subsistemas de unsoftware





Medidas dependientes de la complejidad del software

Número de McCabe o Número ciclomáticoSe trata fe un atributo interno, muy importante para

determinar la facilidad de mantenimiento del software:

E − N + 2 (1)

Captura la complejidad estructural de un código fuentemidiendo el número de caminos linealmenteindependientes del flujo de control

E: Número de arcos (edges) del grafoN: Número de nodos del grafo





Ejemplo medida número ciclomático1 Scoreboard : : drawscore ( i n t n )2 { while ( numdigi ts−− > 0} {3 score [ numdig i ts ]−>erase ( ) ; }4 // build new score in loop, each time update position5 numdig i ts = 0 ;6 // if score is 0, just display ’’0’’7 i f ( n == 0) { de le te score [ numdig i ts ] ;8 score [ numdig i ts ] = new Disp layab le ( d i g i t s [ 0 ] ) ;9 score [ numdig i ts ]−>move( Po in t ((700− numdig i ts ∗1 8 ) , 4 0 ) ) ;

10 score [ numdig i ts ]−>draw ( ) ;11 numdig i ts ++ ; }12 while ( n ) { i n t rem = n % 10;13 de le te score [ numdig i ts ] ;14 score [ numdig i ts ] = new Disp layab le ( d i g i t s [ rem ] ) ;15 score [ numdig i ts ]−>move( Po in t (700−numdig i ts ∗1 8 ) , 4 0 ) ) ;16 score [ numdig i ts ]−>draw ( ) ;17 n /= 10;18 numdig i ts ++;19 } }





Ejemplo de cálculo del número ciclomático II





Otros factores internos que dificultan el mantenimiento

Jerarquía de herencia entre entidades sintácticas de loslenguajes de programaciónligadura dinámica entre referencias y código actual de losmétodos que se ejecutanrelaciones de uso, delegacióninclusión de clases y paquetes





Análisis de Impacto

AntecedentesEl mantenimiento de software comienza con la definiciónde los requerimientos del softwareDefinición: “Evaluación de los riesgos asociados con elcambio de un sistema software: estimación de efectos,esfuerzo de desarrollo y cronograma"Ayuda a mantener bajo control el costo del mantenimientodel softwarePara el mantenimiento se han de aplicar los mismosprincipios de IS que para desarrollar buen software





Modelo de mantenimiento del software

Debido a Pfleeger y Bohner, permite medir el impacto deun cambio y determinar los riesgos de llevarlo a cabo:

Incluye realimentación de subactividadesMedidas que proporcionan información a los gerentesDetermina: cuándo y cómo realizar un cambio

Flechas etiquetadas en la parte inferior del diagramaproporcionan medidas del impacto de los cambiosLos requerimientos, componentes de diseño, código,casos de prueba y documentación son subproductos delproceso de desarrollo del software





Modelo de Pfleeger del Mantenimiento

Figure: Actividades realizadas cuando se solicita un cambio delsoftware M.I.Capel Tema 5 55/83




Análisis de Impacto II

Calidad del softwareLas calidad de los productos software (requerimientos,código, pruebas, documentación) pueda afectar a lacalidad de los otrosSe necesitan facilidades de rastreo (tracing) paracomprender el juego completo de relaciones que seevalúan entre productos software durante el análisisAmbos tipos de rastreos son necesarios para comprenderel juego completo de relaciones que se evalúan durante elanálisis de impacto de los cambios





Tipos de rastreos entre subproductos

Subproducto (workproduct): cualquier artefacto dedesarrollo cuyo cambio sea significativoTrazabilidad horizontal: relaciones de componentes através de colecciones de subproductosTrazabilidad vertical: relaciones entre partes de unsubproducto





Gráfica de los rastreos entre subproductos

Figure: Trazabilidad Horizontal





Gráfica de los rastreos en subproductos

Figure: Trazabilidad VerticalM.I.Capel Tema 5 59/83




Herramientas de mantenimiento de software

Clasificación de los tipos más comunesEditores de textoComparadores de archivosCompiladores y encuadernadores (linkers)Herramientas de depuraciónGeneradores de referencias cruzadasAnalizadores de código estáticoRepositorios de gestión de la configuración





Herramienta “tipo"

CaracterísticasIncorpora el código fuente, código objeto , lenguaje decontrol, y archivos de datos necesarios para hacerfuncionar un sistemaControla más de una versión de un sistema:

Se designa una única versión como la de producción y nose permite que ninguna la altere

Sitúa el número de versión y la fecha del último cámbio enel listado del compilador y en el objeto producido en lacompilaciónPosee facilidades de reporting, backup y recuperación,además de tres niveles de seguridad de accesos





Rejuvenecimiento del software

Tipos:Redocumentación: el análisis estático añade másinformaciónRestructuración: transformar para mejorar la estructura delcódigoIngeniería Reversa: recrear el diseño y la información dela especificación desde el códigoRe–ingeniería: Ingeniería Reversa+ cambios en laespecificación y el diseño para completar el modelo lógico;después generar un nuevo sistema a partir de laespecificación revisada y del diseño





Taxonomía del rejuvenecimiento del software

Figure: Relación gráfica entre los 4 tipos de rejuvenecimiento delsoftware





Redocumentación de software

Comienza enviando el código a una herramienta deanálisisNo está basada en métodos softwareLa salida puede incluir:

relaciones de llamadas entre componentestablas de interfaces de datosinformación del diccionario de datostablas de flujo de datos o diagramastablas de control de datos o diagramaspseudocódigocaminos de pruebareferencias cruzadas entre componentes y variables





Redocumentación de software II

Figure: Proceso de redocumentación





Restructuración de código

Interpretación del código fuente y representación internadel mismoSimplificación de la representación internaRegeneración del código estructurado





Actividades de restructuración

Figure: Proceso de restructuración: (1) análisis estático, (2)simplificación de la representación, (3) refinamiento para generar unaversión estructurada





Ingeniería Reversa

Se basa en métodos software aceptadosGestiona la representaciónIntentar recuperar información de ingeniería basándose enmétodos de especificación y diseño de softwarePersisten obstáculos por superar antes de que laingeniería se pueda utilizar en cualquier caso

Problema del Sistema de Tiempo RealSistema extremadamente complejo





Ingeniería Reversa II

Figure: Proceso de ingeniería reversa





Reingeniería

Se trata de una extensión de la ingeniería reversaproduce nuevo código–software sin cambiar la función delsistema completocompleta y modifica la representación

Pasos de Reingeniería:Al sistema se le aplica ingeniería reversaEl sistema software es corregido o completadoSe genera el nuevo sistema





Reingeniería II

Figure: Proceso de reingeniería




Conceptos fundamentales y estándares actualesMarcos de trabajo y herramientas gestión de la configuración

Gerencia de la Configuración de Software

Definición de IEEE (2004)Es un soporte al proceso del ciclo de vida del software quebeneficia a la gestión del proyecto, el desarrollo del producto ylas actividades de mantenimiento, además de estaríntimamente ligado a las actividades de aseguramiento de lacalidad del software.

IEEE (Institute of Electrical and Electronic Engineers) handesarrollado varios estándares para seguir en el proceso dedesarrollo, prueba y evolución del software





Gerencia de Configuración II

Basada en estándaresLa GC siempre debería estar basada en un conjunto deestándares que son aplicados dentro de la organizaciónLos citados estándares deberían definir:

Cómo se identifican los elementos,Cómo se controlan los cambios yCómo se manejan las nuevas versiones del sistema





Estándares relacionados con la GC

Estándar Descripción1042–1987 Guía IEEE para Gestión de Configuración de Software828–2005 Planes de Gestión de Configuración de Software1008–1987 Unidad de Prueba de Software1012–2004 Planes para Validación y Verificación de Software1028–2008 Revisión y Auditoría de Software1004–1993 Clasificación de Anomalías de Software1059–1993 Guía de Planes de Verificación y Validación de Software829–1998 Documentación de Pruebas de Software

Table: Estándares de IEEE





Estándares relacionados con la GC II

Estándar Descripción10007–2003 Gestión de calidad de sistemas (Guías de GC)

15846–1998 Tecnología de la Información–Proceso de Ciclo de Vida (GC)

Table: Estándares ISO Software Engineering





Estandarización de las prácticas para gestión deservicios en IT

ITIL“Information Technology Infrastructure Library" , conjuntode prácticas estandarizadas que alinean servicios–IT conla necesidades de un negocioPublicaciones ITIL (2011)(verhttp://www.itil-officialsite.com), cada unacubre una etapa del ciclo de vida de gestión de serviciosConforme con estándar ISO/IEC 20000, internacional dereferencia para servicios–IT


http://www.itil-officialsite.com




Estandarización de las prácticas para gestión deservicios en IT (2)

CMM“Capability Maturity Model", modelo de desarrollo desoftware creado a partir de datos de organizaciones quemantienen contratos con el DoD (USA)El modelo es la base de la actividades desarrolladas porSoftware Engineering Institute (SEI), creado porCarnegie–Mellon UniversityMadurez es el grado de formalización y optimización deprocesos implicados en el desarrollo de softwareMétricas de gestión de los resultados para conseguir laoptimización de los procesos aludidos





Marcos de trabajo IÁreas de proceso Actividades ITIL RUP CMM IEEE

Gerencia y 1.1.Entender el contexto X X X Xorganizacional

Planificación 1.2.Preparar el plan de GCS X X X X1.2.1.Definir restricciones X X X XGuías y organizacional1.2.2.Establecer procedimientos X X X Xy políticas1.2.3.Establecer roles X X X Xy responsabilidades1.2.4.Establecer tiempos X X X Xy cronogramas1.2.5.Selección de X X X Xherramientas1.2.6.Control de X X — Xproveedores1.3.Revisar resultados X X X Xde auditorias1.4.Realizar mediciones X X X Xpara mejorar





Marcos de trabajo IIÁreas de proceso Actividades ITIL RUP CMM IEEE

Identificación y 2.1.Seleccionar elementos X X X Xa ser controlados

Almacenamiento 2.2.Identificar versiones X X X X2.3.Establ. líneas base X X X X2.4.Definir Almacenamiento X X X X

Control de 3.1.Requisitos de cambios X X X X

Cambios, versiones 3.2.Aprobar cambios X X X X3.3.Implementar cambios X X X —

Estados 4.1.Informe del estado X X X X4.2 Reportes diversos X X — X

Auditoría 5.1.Verificar si se cumplen X X X Xprocedimientos y políticas5.2.Verificar el X X X —Almacenamiento5.3.Verificación X X X Xlíneas base5.4.Revisión X X X Xfuncionamiento herramientas





Gestión de Versiones

AntecedentesEl administrador del sistema ha de poder identificarsiempre la versión operativa actual del sistema y elnúmero de revisión de cada componente en usoGarantizar que todos los procedimientos que afectan a loscambios se aplican adecuadamente:

Se asigna un número a cada versión activa del sistemaSe asigna un número de revisión a cada componente queresulte cambiadoSe guardan registros de cada versión, estado decomponente e histórico de cambios en el sistema





Herramientas CASE para control de cambios I

Gestión de Cambios:Editores de formularios para soportar los formatos desolicitud de cambio.Sistemas basados en flujo de trabajos (WF) para definirquién hace qué y automatizar la transferencia deinformación.Base de Datos de cambio que gestionan las propuestasde cambio y está enlazadas con un sistema de gerenciade versiones.





Herramientas CASE para control de cambios II

Identificación de versiones y distribucionesLos sistemas asignan identificadores automáticamentecuando se libera una nueva versión del sistema.Gestión del Almacenamiento. Los sistemas almacenan lasdiferencias entre las versiones más que todo el código dela nueva versión.Registro de la Historia de Cambios. Registra las razonespara la creación de una nueva versión.Desarrollo Independiente. Sólo se puede permitir unaversión a la vez para el cambio, por lo que se realiza untrabajo paralelo en diferentes versiones.





Para ampliar

Jarzabeck (2007).Effective Software Maintenance and Evolution.Auerbach.

Pfleeger, S. (2002).Ingeniería de Software: Teoría y Práctica.Prentice-Hall.

Pigoski (1996).Practical Software Maintenance.Wiley.

Pressman, R. (2010).Software engineering: a practitioner’s approach.McGraw-Hill.

Sommerville, I. (2010).Ingeniería de Software.Pearson–Addison Wesley.


Mantenimiento y evolución del software

Software

Transcript of Mantenimiento y evolución del software