Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading content…
Loading…
Transcript

ESTÁNDAR IEEE 1219 DE MANTENIMIENTO DEL

SOFTWARE

PRUEBAS DE ACEPTACIÓN

DETERMINAR EL PROCESO DE

MANTENIMIENTO A SEGUIR

DETERMINAR EL ESFUERZO DE MANTENIMIENTO

El proceso de mantenimiento es una forma natural de comprobar la obsolescencia de

muchas de las medidas del sistema que se tienen como referencia. Una vez estas medidas han sido recogidas, es necesario determinar el siguiente paso en el mantenimiento.

Cada uno de los procesos será descrito por una serie de eventos. En general, el flujo de

trabajo se describe desde la recepción de la Solicitud de Modificación hasta su implementación

y liberación.

PLANIFICACIÓN DEL MANTENIMIENTO

A nivel de sistema, cada uno deberá ser examinado para determinar lo siguiente:

• Tiempo transcurrido desde la puesta en producción.

• Número y tipo de cambios durante su ciclo de vida.

• Utilidad del sistema

• Número y tipo de Solicitudes de Modificación recibidas

• Calidad y temporalidad de la documentación

• Estadísticas existentes del rendimiento (CPU, E/S disco, etc.)

. El plan de mantenimiento puede incluir lo siguiente:

• Determinar el esfuerzo de mantenimiento

• Determinar el proceso de mantenimiento a seguir

• Cuantificar el esfuerzo de mantenimiento

• Determinar los requisitos del proyecto de mantenimiento

• Desarrollar un plan de mantenimiento.

Al igual que las pruebas de sistema,

las pruebas de aceptación serán realizadas sobre un sistema completamente integrado. Estas pruebas se realizan por el cliente, por el usuario o por un 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 documentación

generada.

Procesos de las pruebas del sistema

• Pruebas de funcionalidad del sistema

• Pruebas de interface

• Pruebas de regresión

• Revisión de la disponibilidad de pruebas del sistema para valorar el nivel de

preparación para las pruebas de aceptación.

DETERMINAR LOS REQUISITOS DEL PROYECTO DE MANTENIMIENTO

CUANTIFICAR EL ESFUERZO

DE MANTENIMIENTO

DESARROLLAR UN PLAN DE MANTENIMIENTO

la secuencia de procesamiento, y

la manera de controlar este proceso.

ALCANCE DEL PROCESO

SECUENCIA DEL PROCESO

CONTROL DEL PROCESO

ORGANIZACIÓN

RESERVA DE RECURSOS

AUDITORÍA DEL RENDIMIENTO

DESARROLLO DEL PLAN

La información recogida dará una base para

el nuevo plan de mantenimiento. El plan

deberá cubrir cuatro áreas principales:

• Proceso de Mantenimiento

• Organización

• Reserva de Recursos

• Auditoría del Rendimiento.

Las fases del ciclo de vida

A este nivel, el proceso de mantenimiento necesita ser asociado a un entorno de

negocio. Se debería completar una revisión de las futuras expectativas, que podrían incluir:

• Cambios del sistema esperados, externos o regulatorios.

• Cambios internos esperados para soportar los nuevos requisitos.

• Lista de nuevas funciones y características deseadas.

• Mejoras esperadas en el rendimiento, adaptabilidad, conectividad, etc.

• Nuevas líneas de negocio que necesitan ser soportadas.

• Nuevas tecnologías que necesitan ser incorporadas.

INTRODUCCIÓN

Tipos de Mantenimiento del Software

• Identificación del Problema

• Análisis

• Diseño

• Implementación

• Pruebas del Sistema

• Pruebas de Aceptación

• Puesta en Producción o liberación de versión

Cada uno de los pasos en el proceso

necesita ser descrito numéricamente en términos de

volumen de tiempo. Estos números pueden entonces ser utilizados como base para determinar el

rendimiento actual de la organización de mantenimiento.

Este estándar define cambios en un producto software a través de un proceso de

mantenimiento dividido en fases.Estas fases son:

• Identificación y Clasificación del Problema o de la Modificación.

• Análisis.

• Diseño

• Implementación.

• Pruebas del Sistema.

• Pruebas de Aceptación.

• Liberación del Producto

“Este estándar describe un proceso iterativo para la gestión y ejecución de las

actividades de Mantenimiento del Software.

Los criterios establecidos se aplican tanto a la

planificación del Mantenimiento del Software mientras este está en desarrollo, como a la

planificación y ejecución de las actividades de Mantenimiento para productos software

existentes...”

FASES DEL DESARROLLO EN EL MANTENIMIENTO DEL SOFTWARE

MANTENIMIENTO PREVENTIVO

ANÁLISIS DETALLADO

MANTENIMIENTO ADAPTATIVO

ELEMENTOS DE DISEÑO

IMPLEMENTACIÓN

Procesos

PRUEBAS DEL SISTEMA

Las pruebas de sistema se realizan sobre un sistema modificado. Deberían ser realizadas

por una organización independiente y siempre estar presente el cliente y el usuario final. La organización responsable de las pruebas del sistema deberá ser independiente de los

desarrolladores y diseñadores del software, pero podrían utilizarse como recursos para el

personal de pruebas.

Procesos de la implementacion

Estos procesos son:

• Codificación y pruebas de unidad.

• Integración.

• Análisis de riesgo y revisión.

• Revisión de disponibilidad de pruebas.

Consiste en la modificación del producto Software

sin alterar las especificaciones del

mismo, para mejorar las propiedades de mantenimiento del producto y facilitar así las futuras

tareas de mantenimiento.

ANÁLISIS DE VIABILIDAD

Elementos

•Documentación de diseño y requisitos aprobados y controlados.

• Estándar de codificación acordado para ser utilizado por el grupo de mantenimiento.

• Métricas de diseño que podrían ser aplicables en la fase de implementación (podrían

clarificar la complejidad del código a desarrollar o mantener).

Las tres preguntas claves

Tiene por objetivo la modificación

de un programa debido a cambios

en el entorno, bien cambios en el

hardware o en el software,

en el que se ejecuta.

1. ¿Existe alguna forma de determinar analíticamente los efectos de un cambio antes

de su implementación?

2. ¿Existe alguna forma de garantizar que el cambio propuesto no tendrá efectos

adversos en partes del sistema que no se han modificado?

3. ¿Se puede hacer una estimación razonable del esfuerzo total necesario para realizar

una modificación antes de llevarla a cabo?

Al identificar los elementos susceptibles de modificación en el análisis, se examinan

todos los elementos generados en las fases del Mantenimiento del Software que están afectados,

por ejemplo el software, las especificaciones, las bases de datos, la documentación, etc. Cada

uno de estos elementos serán identificados y generados si fuera necesario, especificando las

partes del producto que van a ser modificadas, los interfaces afectados, los cambios esperados

por el usuario, el grado relativo y clase de experiencia necesaria del personal para hacer los

cambios, y el tiempo estimado para completar la modificación.

• Lista de modificaciones revisada.

• Guía básica del diseño actualizada.

• Planes de pruebas actualizados.

• Análisis detallado actualizado.

• Requisitos verificados.

• Plan de implementación revisado.

• Lista de restricciones y riesgos bien documentados.

MANTENIMIENTO PERFECTIVO

Es la modificación de un producto software, después de su puesta en producción y para

mejorar el rendimiento o la mantenibilidad, que es la facilidad de mantenimiento que tiene un

software, es decir, la facilidad de un software para ser modificado, lo que influye directamente

en los costes del mantenimiento.

MANTENIMIENTO DE EMERGENCIA

Es un mantenimiento correctivo realizado sin

planificación previa y utilizado para

mantener operativo el sistema.

MANTENIMIENTO CORRECTIVO

DISEÑO

contiene los siguientes elementos:

• Impacto de las modificaciones. Identificar los efectos bilaterales potenciales.

• Soluciones alternativas, incluyendo prototipado.

• Análisis de los requisitos de conversión.

• Implicaciones de Seguridad.

• Implicaciones de Robustez.

• Factores humanos

• Costes a corto y largo plazo.

• Beneficios de realizar las modificaciones

Tiene por objetivo localizar y eliminar los posibles

defectos de los programas. A pesar de las pruebas y verificaciones que aparecen en etapas

anteriores del ciclo de vida del software, los programas pueden tener defectos. Un defecto en un

sistema es una característica del sistema que podría ser la causa de un fallo. El fallo se produce

cuando el comportamiento del sistema es diferente al esperado por su especificación.

A partir de toda la documentación existente del proyecto y del sistema que esté en

producción, así como todo el código fuente y las bases de datos de la última versión, se va a

realizar el diseño de las modificaciones del sistema en base a la documentación generada en la

fase de análisis (análisis detallado, informe de requisitos, identificación de los elementos

afectados, estrategia de pruebas y plan de implementación).

ANÁLISIS

MANTENIMIENTO DEL SOFTWARE

IDENTIFICACIÓN, CLASIFICACIÓN Y PRIORIZACIÓN DEL

PROBLEMA

En esta fase los procedimientos a seguir son:

• Asignación de un Número de Identificación.

• Clasificación del tipo de mantenimiento.

• Análisis de la modificación para determinar si se acepta, se deniega o se evalúa.

• Realizar una estimación preliminar de la magnitud de la modificación.

• Priorizar la modificación.

• Asignar Solicitudes de Modificación a bloques de tareas planificadas para su

implementación.

Según el IEEE, el Mantenimiento del Software es la modificación de un producto

software después de su entrega al cliente o usuario para corregir defectos, para mejorar el

rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno.

a lo largo del estándar IEEE 1219, el proceso de

Mantenimiento del Software comienza con las primeras fases del ciclo de vida, puesto que el

coste de Mantenimiento va a estar tremendamente influido por las decisiones que se tomen en

cada una de estas fases.

En esta fase se estudia la viabilidad y el alcance de las modificaciones, que ya tenemos

clasificadas y priorizadas, así como la generación de un plan preliminar de diseño,

implementación, pruebas y liberación del software. La información que se va a utilizar en esta fase proviene del repositorio y de la Solicitud de Modificación validada en la fase anterior,

además de la documentación del proyecto y del sistema existente.

Componentes del Analisis

Integrantes:

Victoria Toapanta 5580

Janeth Caiza 5208

Greta Chancusi 5295

Learn more about creating dynamic, engaging presentations with Prezi