Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 26

PROCESOS DE

MANTENIMIENTO
NORMA ISO 14764
El proceso de mantenimiento propuesto en esta norma
internacional comprende las actividades y tareas necesarias
para modificar un producto software que ya existe.

La persona encargada del mantenimiento debe asegurarse


haber definido el proceso de mantenimiento de software
antes de su desarrollo.

La norma ISO/IEC 14764:2006 proporciona los pasos a seguir


con el objetivo de llevar a cabo las tareas de mantenimiento.
TÉRMINOS Y DEFINICIONES

Mantenimiento
Plan De
BASELINE: de mejora:
Mantenibilidad
RELEASE Adaptativos
PM:
perfectivos

Plan de Proceso de Programa de


mantenimiento: mantenimiento mantenimiento
TÉRMINOS Y DEFINICIONES
Petición de modificación (PM). Modification Request (MR)

Informe del problema: Problem report (PR)

Entorno de Ingeniería de software: Software engineering


environment (SEE)

Entorno de pruebas de software: Software Test environment (STE)

Transición del software


PROCESOS

Gestión de la
Resolución de
configuración
problemas

Las MR y PR que
MR Determinamos si es Someter a sean aprobadas se
PR un problema o una probación de la implementan
Se reciben, analizan mejora petición llamando al proceso
y resuelven de mantenimiento
PETICIÓN DE
MODIFICACIÓN
(MR)

CORRECCIÓN MEJORA

MANTENIMIENTO MANTENIMIENTO MANTENIMIENTO MANTENIMIENTO


CORRECTIVO PREVENTIVO ADAPTATIVO PERFECTIVO
CONSIDERACIONES

Acuerdos de Herramientas para el Medición del Documentación del


mantenimiento mantenimiento Software proceso

Participación
temprana en el
desarrollo : plan
logístico – Asegurar la Transición del
Mantenibilidad: Documentación
soportabilidad del software
producto – Apoyar la
planificación de la
transición
ASPECTOS PARA ELEGIR EL LENGUAJE DE
PROGRAMACIÓN
 Portable
• Disponibilidad en los compiladores
 Legible
• Tolerancia a “trucos” de
 Estable
programación
 Posibilidades de estructuración
• Disponibilidad de SEE y STE
 Facilidad para crear nuevas
versiones • Éxito en las herramientas de
 Posibilidad para estructuras de desarrollo
datos
• Posibilidad de pruebas en
 Estabilidad en los compiladores
compilación y ejecución
 Identificar y definir funciones, especialmente
las funciones que son opcionales.
 Exactitud y la organización en la lógica de los
datos.
 Las interfaces tanto de máquina como de
usuario.
ANÁLISIS DE
 Requerimientos de rendimiento.
REQUERIMIENTOS  Requerimientos propuestos por el entorno
(presupuesto).
 Granularidad (detalle) de requerimientos y el
impacto que tienes sobre la trazabilidad.
 Plan de aseguramiento de calidad (SQAP)
para cumplir las normas de documentación.
¿Por qué es necesario el
mantenimiento?
¿Quién hará el trabajo
Estrategia de
mantenimiento Roles y responsabilidades de cada uno
de los participante?
¿Cómo debe ser realizado el trabajo’
¿Qué recursos estarían disponibles?
- Preparar recursos humanos ¿Dónde será realizado el
y materiales mantenimiento?
- Análisis de mantenibilidad ¿Cuándo comenzará el
- Estrategia consta de tres mantenimiento?
elementos

CONCEPTO DE PLAN DE
ANÁLISIS DE RECURSOS
MANTENIMIENTO MANTENIMIENTO
ESTRUCTURA DEL PLAN DE
MANTENIMIENTO

2- identificar el
1- describir el sistema
a) Introducción estado inicial del
que será soportado
software

5- describir los
3- describir describir 4- identificar el protocolos de
porqué es necesario mantenedor (la acuerdo entre el
el mantenimiento organización) cliente y el
suministrador
 La persona encargada del
mantenimiento deberá desarrollar,
documentar y llevar a cabo los planes
y procedimientos para la realización
1. de las actividades y tareas del
IMPLEMENTACIÓN proceso de mantenimiento. El plan de
mantenimiento debe documentar la
DEL PROCESO estrategia que se utiliza para
mantener el sistema, mientras que los
procesos de mantenimiento deben
proporcionar un enfoque más
detallado sobre como llevar a cabo
el mantenimiento en la realidad.
Líneas de base pertinente.

LAS ENTRADAS O
INPUTS PARA LA
ACTIVIDAD DE La documentación del
IMPLEMENTACIÓN sistema, si está disponible.
DEBEN INCLUIR:

Una modificación de
solicitud (MR) o un informe
de incidencia (PR).
Facilitar que el promotor del software comprenda
el concepto de mantenimiento y su alcance. CON EL FIN DE
DESARROLLAR
El responsable de mantenimiento debe ser PLANES EL
designado por escrito.
MANTENIMIENTO,
EL RESPONSABLE
Determinar los costes de mantenimiento. DEBE REALIZAR LAS
SIGUIENTES
TAREAS:
Realizar evaluaciones del mantenimiento del
sistema.

Documentar el proceso de mantenimiento


utilizando los procedimientos de operación.
UNA VEZ REALIZADAS ESTAS TAREAS, LAS
PRINCIPALES SALIDAS O PRODUCTOS ESPERADOS
SON:

Plan de Procedimientos Manual de


mantenimiento. de mantenimiento.
mantenimiento.

Planes de Evaluación de
retroalimentación mantenimiento.
del usuario.
 Esta y las sucesivas actividades se
activan después de la transición
software y se llaman iterativamente
2. ANÁLISIS DE cuando la necesidad de
modificación surge. El responsable de
PROBLEMAS Y mantenimiento deberá analizar el
informe de problemas o solicitud de
MODIFICACIÓN modificación por su impacto en la
organización, el sistema existente y los
sistemas de interfaz para el tipo, el
alcance y la criticidad.
LAS
Documentación del sistema.
ENTRADAS
ESTA Información de estado de configuración.
SECCIÓN
DEBEN SER: Requerimientos funcionales.

Requisitos de interfaz.

Las salidas de la actividad del proceso de


implementación.
Determinar si el Determinar si el
responsable cuenta programa tiene un
CON EL FIN DE con suficiente personal presupuesto adecuado
para implementar la para implementar la
ASEGURAR QUE modificación modificación
propuesta. propuesta.
LA SOLICITUD DE
MODIFICACIÓN Determinar si hay
Evaluar las restricciones
ES FACTIBLE, EL suficientes recursos
de software o hardware
disponibles y si esta
RESPONSABLE modificación afectará
que pueden resultar de
las modificaciones.
a proyectos en curso.
DEBE REALIZAR
LAS SIGUIENTES
TAREAS: Determinar el valor de
Determinar los costos a
la ventaja de hacer la
largo plazo.
modificación.
Análisis de impacto.
DESPUÉS DE
REALIZAR Documentación
TODAS ESTAS actualizada.

TAREAS, LAS
SALIDAS Prioridad inicial.
ESPERADAS
DEBERÁN SER:
Requisitos actualizados.
Actualización de planes de pruebas y
procedimientos.

LAS SALIDAS O Documentación actualizada.


OUTPUTS DE
ESTA Modificación del código fuente.

ACTIVIDAD Presentación de informes de prueba.

DEBEN
Requisitos actualizados.
INCLUIR:
Actualización de planes e informes de pruebas.
 Durante la actividad de modificación,
el responsable desarrolla y pone a
prueba la modificación del producto
3. software. El responsable deberá
MODIFICACIÓN establecer una conducta de análisis y
determinar qué documentación,
DE APLICACIÓN unidades de software, y versiones de
los mismos necesitarán ser
modificados. Todo este proceso
deberá ser documentado.
Identificar los elementos a ser
modificadas en el sistema
existente.
LA EJECUCIÓN Identificar los elementos de la
DE ESTE interfaz afectadas por la
PROCESO DE modificación.
MANTENIMIENT Identificar la documentación
O INCLUYE LAS que se debe actualizar.
SIGUIENTES
TAREAS: Actualizar la documentación del
software.
4. REVISIÓN DE
MANTENIMIENTO/ACEPTACIÓN

 En esta parte del proceso se asegura que se ha seguido la


metodología adecuada para la modificación del sistema y que
efectivamente dichas modificaciones han sido satisfactorias.
5. MIGRACIÓN

 En el ciclo de vida de cualquier software puede ser necesario


trasladar el entorno actual a uno nuevo. Para poder realizar este
traslado de una forma apropiada, el equipo de mantenimiento
debe determinar las acciones competentes para el mismo y
luego desarrollar y documentar cada uno de los pasos a seguir
para llevar la migración a buen puerto.
Cuando el software ha alcanzado el
final de su ciclo de vida debe ser
retirado del mercado. Con el objetivo
de ejecutar una buena retirada, un
análisis (normalmente basado en el
coste/impacto económico) debe
realizarse, incluyendo en el mismo el
plan de retirada.2
6. RETIRADA DEL Las tarea principal consiste en el
desarrollo de un plan de retirada que
SOFTWARE notifique a los usuarios, ofreciendo
alternativas, avisando conforme se
acerca el momento del retiro final y
notificando cuando finalmente la
retirada se haya llevado a cabo. En
dicho plan debe incorporarse también
la exportación de los datos recogidos
por el software a lo largo de su ciclo de
vida.
Analizar los requisitos de la retirada.

Determinar el impacto de la retirada del


ENTRE OTRAS, LAS producto.

TAREAS QUE DEBEN Identificar el software sustituto, en caso de que


SER lo hubiera.

DESARROLLADAS Establecer una calendario con las fechas clave


POR EL EQUIPO DE en la retirada del software.

MANTENIMIENTO Identificar aquello que fuera necesario para un


SON LAS QUE futuro soporte

SIGUEN: Definir y documentar los pasos del proceso de


retirada.

También podría gustarte