Transición

Tema 11: Fase de Transición
Departamento de Lenguajes y Sistemas Informáticos II
www.kybele.urjc.es
Índice
Transición
 Mantenimiento

Fase de Transición
www.kybele.urjc.es
2
Transición
Flujos de
trabajo
Fases
Inicio
Elaboración
Construcción
Transición
Requisitos
Análisis
Diseño
Implementación
Prueba
Iteración(es)
Inicial(es)
Iter.
#1
Iter.
#2
Iter.
#3
Iter.
#4
Iter.
#5
Iter.
#6
Iter.
#7
(Adaptado de Jacobson, 1999)
Fase de Transición
www.kybele.urjc.es
3
Transición
El sistema ha alcanzado la capacidad operativa
inicial
 Confianza suficiente como para operar en el
entorno del usuario

Algunos problemas, riesgos y defectos pueden
ponerse de manifiesto en el entorno del usuario
Descubrir con retraso determinadas necesidades
 El jefe de proyecto puede aceptar añadirlas
Fase de Transición
www.kybele.urjc.es
4
Transición

Objetivos
Cumplir los requisitos, establecidos en las fases
anteriores, hasta la satisfacción de todos los usuarios
Gestionar todos los aspectos relativos a la operación
en el entorno del usuario, incluyendo la corrección de
los defectos remitidos por los usuarios de la versión
beta o por los encargados de las pruebas de
aceptación

Las pruebas de aceptación son responsabilidad
del cliente, aunque pueden contratarse
Fase de Transición
www.kybele.urjc.es
5
Transición

Visión general
Implantar el producto en su entorno de operación
 Producto dirigido al mercado:
• Pruebas beta: “clientes beta” de empresas representativas
 Producto a medida
• Pruebas beta
• Pruebas alfa
• Validación por un tercero
El proyecto recibe información para






Fase de Transición
El sistema hace lo que demandan sus usuarios y el negocio
Descubrir riesgos inesperados
Anotar problemas no resueltos
Encontrar fallos
Eliminar ambigüedades y lagunas en la documentación
Centrarse en áreas en las que los usuarios muestren deficiencias
www.kybele.urjc.es
6
Transición

Visión general
A partir de lo anterior, el equipo del proyecto
 Modifica el sistema o los artefactos relacionados
 Prepara la producción del producto, el empaquetado, la distribución y
lanzamiento al mercado en general.
En esta fase no se busca reformular el producto.
 Cambios significativos deberían haberse en fases anteriores
 Pequeñas deficiencias que pasaron desapercibidas
Además, puede incluir:




Ayuda para crear un entorno apropiado para el producto
Formación de la organización del cliente
Ayudar a los usuarios a llevar en paralelo con el sistema antiguo
Ayudar a la conversión de BD a la nueva configuración.
En el caso de productos para el mercado, en el programa de
instalación, complementado con el servicio de asistencia técnica.
La fase de transición termina con el lanzamiento del producto
Fase de Transición
www.kybele.urjc.es
7
Transición

Tipos de acuerdos comerciales
Producto dirigido al mercado (relación 1:N)
 Amplio
 Reducido
Producto a medida
 Para un único cliente con una única sede
 Para un único cliente con suborganizaciones y sedes
 Para un único cliente pero después adaptado para otras
sedes o clientes
 Desarrollo de software para otros departamentos de la
misma empresa bajo acuerdos específicos
Fase de Transición
www.kybele.urjc.es
8
Transición

Planificación de la transición
Información de las pruebas beta
Resultado de las pruebas
Reelaboración < 5%
Problemas
 Presión de la agenda
 Pruebas erróneas o inexistentes
 Mala evaluación del trabajo de transición
 Considerar que la reelaboración implica un fracaso
…
Fase de Transición
www.kybele.urjc.es
9
Transición

Criterios de evaluación
Los usuarios beta han cubierto las funciones clave
EL producto ha superado las pruebas de aceptación
realizadas por el cliente (fijados por contrato)
El material de usuario tiene una calidad aceptable
El material de cursos está listo
Los usuarios y clientes parecen satisfechos con el
producto
Fase de Transición
www.kybele.urjc.es
10
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
Actuar a partir de la información recogida
Adaptar el producto corregido
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto

Diferencias en función de
Producto para el mercado/para un cliente
Producto novedoso/preexistente
Fase de Transición
www.kybele.urjc.es
11
Transición

Actividades
Preparación de versión beta (o de aceptación)
 Usuarios experimentados
 A partir de información preliminar
 Documentación necesaria para usuarios
 Selección de usuarios
Instalación
Actuar a partir de la información recogida
Adaptar el producto corregido
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto
Fase de Transición
www.kybele.urjc.es
12
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
 Beta: normalmente en varios sitios, sin presencia del personal de
transición (necesarias instrucciones). Si es actualización,
instrucciones sobre migración de datos…
 Aceptación: presentes miembros del personal, documento
formal, si es posible, corrección sobre el terreno
Actuar a partir de la información recogida
Adaptar el producto corregido
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto
Fase de Transición
www.kybele.urjc.es
13
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
Actuar a partir de la información recogida
 Fallos menores: traza, corrección, pruebas (de regresión)
 Problemas importantes:
• Iteración adicional de pruebas, aprobación de comité de control de
cambios, control de configuraciones, ¿retraso a otro ciclo?
Adaptar el producto corregido
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto
Fase de Transición
www.kybele.urjc.es
14
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
Actuar a partir de la información recogida
Adaptar el producto corregido
 Producto para el mercado: adaptaciones (países, nodos), ampliar
documentación, instalación, asistencia…
 Producto a medida. Cliente participa en fases anteriores,
desarrollador en instalación y pruebas de aceptación. Posibilidad
de ampliación del contrato
 En caso de sistema preexistente, procedimiento de migración de
datos, pruebas adicionales
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto
Fase de Transición
www.kybele.urjc.es
15
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
Actuar a partir de la información recogida
Adaptar el producto corregido
Completar los artefactos del proyecto
 Incluyendo modelos y descripción de la arquitectura
 Todos los artefactos son consistentes unos con otros
Determinar cuándo se acaba el proyecto
Fase de Transición
www.kybele.urjc.es
16
Transición

Actividades
Preparación de versión beta (o de aceptación)
Instalación
Actuar a partir de la información recogida
Adaptar el producto corregido
Completar los artefactos del proyecto
Determinar cuándo se acaba el proyecto
 Cuando el cliente queda “satisfecho”:
- Productos para el mercado: jefe de proyecto tras pruebas beta.
Evolución del producto o un nuevo ciclo. Transferencia del
mantenimiento a organización de apoyo
- Productos a medida. Pruebas de aceptación. Modalidades de
mantenimiento (nuevo contrato, propio, terceros…)
Fase de Transición
www.kybele.urjc.es
17
Transición

Después:
Control del progreso
 Consecución de objetivos, añadir métricas…
Revisión del plan de negocio (éxito)
 Producto a medida: contrato
 Producto para el mercado
Evaluación
 De la fase/iteraciones
 Del proyecto (Autopsia): qué se ha hecho bien y qué se ha
hecho mal
Planificación de nueva versión
Fase de Transición
www.kybele.urjc.es
18
El cambio en el software

El cambio en el software es inevitable
Aparecen nuevos requisitos a medida que se utiliza
Cambia el entorno de negocio
Deben corregirse los errores
Aparecen nuevos equipos, entornos…
Ha de mejorarse el rendimiento o la fiabilidad del
sistema

La gestión del cambio en el software existente es
un problema fundamental para las
organizaciones
Fase de Transición
www.kybele.urjc.es
19
Tipos de cambios

Reparación de fallos en el software
Cambiar un sistema para corregir errores para cumplir los
requisitos

Adaptar el software a diferentes entornos operativos
Cambiar un sistema de tal forma que funcione en un
entorno distinto al original (ordenador, SO, etc.)

Añadir o modificar funcionalidad al sistema
Modificar el sistema para satisfacer nuevos requisitos

Mejorar la estructura del programa y el rendimiento
Reescribir todo o parte del sistema para hacerlo más
eficiente y mantenible
Fase de Transición
www.kybele.urjc.es
20
Mantenimiento

Elevado gasto
Hasta el 75% de los profesionales de sw están
implicados de alguna forma en tareas de
mantenimiento/evolución
Muchos estudios dan cifras similares
Fase de Transición
www.kybele.urjc.es
21
Mantenimiento

Factores
Inexistencia de métodos, técnicas y herramientas que
puedan proporcionar una solución global al
mantenimiento
La complejidad de los sistemas se incrementa
paulatinamente por la realización de continuas
modificaciones
La documentación del sistema es defectuosa o inexistente
Se considera el mantenimiento como una actividad poco
creativa, a diferencia del desarrollo
Las actividades del mantenimiento se suelen realizar bajo
presión de tiempo
Poca participación del usuario durante el desarrollo del
sistema
Fase de Transición
www.kybele.urjc.es
22
Mantenimiento

Actuaciones comunes para mantener la
operatividad del software
Corrección de defectos en el software
Creación de nuevas funcionalidades en el software
por nuevos requisitos de usuario
Mejora de la funcionalidad y del rendimiento

IEEE:
“Proceso de modificar un sistema o componente
software después de su entrega para corregir
defectos, mejorar el rendimiento u otros atributos o
adaptarlo a un entorno cambiante”
Fase de Transición
www.kybele.urjc.es
23
Evolución versus Mantenimiento

No hay definiciones estándar, aunque de una manera
amplia se refiere al estudio y gestión de cambios en
el software a lo largo del tiempo
Con esta definición, la evolución del software comprende:
 Actividades de desarrollo
 Actividades de mantenimiento
 Actividades de reingeniería
Definición más estricta: actividad de añadir nueva
funcionalidad a software existente
 Mantenimiento se refiere a la actividad de modificar
el software tras haber sido puesto en uso para
mantener su utilidad

Fase de Transición
www.kybele.urjc.es
24
Un poco de historia

1960s – 1970s
Inclusión del mantenimiento en el ciclo de vida en cascada tras la entrega del
producto
Percepción de que las actividades tras la entrega sólo consistirían en la corrección
de errores y ajustes menores
No se tenía en cuenta la necesidad de añadir nueva funcionalidad debido a
requisitos nuevos y cambiantes

1970s
Lehman enuncia las leyes iniciales de la evolución de programas
Énfasis en la necesidad de una evolución continua debido a cambios en el entorno
operacional del software

Finales de 1970s – 1980s
Primeros modelos de proceso que tenían en cuenta las solicitudes de cambios

1990s
Aceptación general de la evolución del software
Desarrollo de nuevos modelos de procesos que consideraban actividades de
evolución: desarrollo evolutivo, modelo en espiral, desarrollos ágiles
Fase de Transición
www.kybele.urjc.es
25
Leyes de Lehman

Leyes de Lehman (iniciales)
Cambio continuo
 Un programa que se usa en un entorno real necesariamente debe cambiar o se
volverá progresivamente menos útil en ese entorno
Complejidad creciente
 A medida que un programa en evolución cambia, su estructura tiende a ser cada vez
más compleja. Se deben dedicar recursos extra para preservar y simplificar la
estructura
Evolución prolongada del programa
 La evolución de los programas es un proceso autorregulativo. Los atributos de los
sistemas, tales como tamaño, tiempo entre entregas y el número de errores
documentados son aproximadamente invariantes para cada entrega del sistema
Estabilidad organizacional
 Durante el tiempo de vida de un programa, su velocidad de desarrollo es
aproximadamente constante e independiente de los recursos dedicados al desarrollo
del sistema
Conservación de la familiaridad
 Durante el tiempo de vida de un sistema, el cambio incremental en cada entrega es
aproximadamente constante
Fase de Transición
www.kybele.urjc.es
26
Mantenimiento

Tipos de mantenimiento
Mantenimiento perfectivo: conjunto de actividades para
mejorar o añadir nuevas funcionalidades requeridas por el
usuario
Mantenimiento adaptativo: es el conjunto de actividades
para adaptar el sistema a los cambios (hardware o
software) en su entorno tecnológico
Mantenimiento correctivo: es el conjunto de actividades
dedicadas a corregir defectos en el hardware o en el
software detectados por los usuarios durante la
explotación del sistema
Mantenimiento preventivo: conjunto de actividades para
facilitar el mantenimiento futuro del sistema
Fase de Transición
www.kybele.urjc.es
27
Mantenimiento

Tipos de mantenimiento y coste relativo
Fase de Transición
www.kybele.urjc.es
28
Mantenimiento

Distribución del tiempo en tareas de mantenimiento:
Comprensión del software y de los cambios que hay que
realizar
Modificación del software incorporando los cambios
Realización de pruebas para validar los cambios
Fase de Transición
www.kybele.urjc.es
29
Mantenimiento

Una selección de métricas para medir el factor
«Facilidad de Mantenimiento»
Fase de Transición
www.kybele.urjc.es
30
Ejemplo de definición de métricas y su
asignación a los criterios de calidad
Definición de métricas de módulo
Longitud de programa :
Número de sentencias :
Frecuencia comentarios :
Frecuencia operandos :
Número ciclomático :
Niveles anidados (máx) :
LENG
NSTM
COMF
OPEF
V(G)
NEST
Selección de límites
LENG
NSTM
COMF
OPEF
V(G)
NEST
1
1
0.15
1.0
1
0
100
50
1.0
3.0
20
4
Definición de criterios de calidad
FACILIDAD DE PRUEBA:
SIMPLICIDAD :
CONCISION :
LEGIBILIDAD :
AUTODESCRIPTIVO :
Fase de Transición
V(G), NEST
V(G), NSTM, OPEF
LENG
LENG, NEST, NSTM
COMF
www.kybele.urjc.es
31
La reingeniería del software

Examen y alteración de un sistema para reconstruirlo de una
nueva forma y la subsiguiente implementación
TECNOLOGÍA DE LA REINGENIERÍA
MEJORA DEL SOFTWARE
Reestructuración.
Redocumentación, Anotación, actualización de documentación.
Ingeniería para reutilización.
Remodularización.
Reingeniería de procesos de negocio (BPR)
Reingeniería de datos.
Análisis de facilidad de mantenimiento, análisis económico.
COMPRENSIÓN DEL
SOFTWARE
Visualización
Análisis, mediciones.
Ingeniería inversa, recuperación de diseño.
CAPTURA, CONSERVACIÓN Y
EXTENSIÓN DEL
CONOCIMIENTO SOBRE EL
SOFTWARE
Descomposición.
Ingeniería Inversa y recuperación de diseño.
Recuperación de objetos.
Comprensión de programas.
Transformaciones y bases de conocimiento.
Fase de Transición
www.kybele.urjc.es
33
La reingeniería del software

La importancia de la reingeniería del software
Puede reducir los riesgos evolutivos de una organización
Aumentar su esperanza de vida
Puede ayudar a las organizaciones a recuperar sus
inversiones en software
Puede hacer el software más fácilmente modificable
Facilitar la migración, traducir un programa de un lenguaje
a otro, moverlo de un entorno operativo a otro o
actualizar su tecnología
Capturar sus componentes en un repositorio que puede
ser gestionado por herramientas CASE
Fase de Transición
www.kybele.urjc.es
34
La reingeniería del software

Ingeniería directa
Corresponde al desarrollo de software tradicional

Reestructuración
Es la transformación de una forma de representación a otra en
el mismo nivel de abstracción relativo, mientras se mantenga el
comportamiento externo del sistema (funcionalidad y
semántica): a nivel de análisis, diseño (modelos) o
implementación (datos, funcionalidad)
Es la modificación del software para hacerlo más fácil de
entender y cambiar

Ingeniería inversa
Es el proceso de análisis de un sistema para identificar sus
componentes e interrelaciones y crear representaciones del
sistema en otra forma o a un nivel más alto de abstracción. Ej:
ingeniería inversa de datos.
Fase de Transición
www.kybele.urjc.es
35
La reingeniería del software

Relaciones entre los términos asociados a la
reingeniería
REQUISITOS
DISEÑO
Ingeniería
directa
Ingeniería
directa
Ingeniería
inversa
Ingeniería
inversa
Reingeniería
Reestructuración
Fase de Transición
IMPLEMENTACIÓN
Reingeniería
Reestructuración
www.kybele.urjc.es
Reestructuración
(refactorización)
36
Mantenimiento

Sistemas heredados
Críticos, que deben adaptarse
 Desechar completamente el sistema
 Dejar el sistema sin cambios y continuar con un
mantenimiento regular
 Hacer reingeniería del sistema para mejorar su
mantenibilidad
 Reemplazar todo o parte del sistema con un nuevo sistema
Fase de Transición
www.kybele.urjc.es
37
Mantenimiento
Sistemas heredados
Perspectiva de negocio
(valor de los negocios)

Reingeniería
Mantenimiento
normal
Desechar
Mantener
/ desechar
Perspectiva técnica
(calidad del sistema)
Fase de Transición
www.kybele.urjc.es
38
Bibliografía
El Proceso Unificado de Desarrollo de Software. I.
Jacobson, G. Booch y J. Rumbaugh. Pearson
Prentice-Hall 2007
 M. Piattini et al. Análisis y Diseño detallado de
Aplicaciones Informáticas de Gestión. Ed. Ra-Ma.
1996
 Ingeniería del Software. Ian Sommerville.
Pearson/ Addison Wesley 2005

Fase de Transición
www.kybele.urjc.es
54