Documentos de Académico
Documentos de Profesional
Documentos de Cultura
n
Punto ptimo: Mayor grado de comprensin con la
menor ambigedad
Modos eficaces de evitar la ambigedad:
Inspecciones formales de los documentos de requisitos.
Escritura de casos de prueba
Elaboracin de casos de uso.
Elaboracin de diagramas.
109
Requisitos del software
Propiedades de los buenos requisitos
Un requisito es verificable si, y slo si a travs de un proceso concreto y finito es posible
comprobar si el software lo cumple. En general los requisitos ambiguos no son verificables.
Los requisitos no verificables incluyen sentencias como que trabaje eficientemente,interfaz de
usuario amigable, debe responder rpidamente. Estos requisitos no son verificables porque no
es posible definir los trminos eficiente, amigable, rpido. La sentencia el programa no
debe entrar nunca en un bucle infinito tampoco es verificable porque un nivel de pruebas
absoluto es tericamente imposible.
Un ejemplo de requisito verificable es:
El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el
90% de las veces, y una transaccin de compra de un billete sencillo nunca debe tardar ms de
5 segundos.
Esta sentencia es verificable porque emplea trminos concretos y magnitudes medibles y
comprobables.
Si no es posible establecer un mtodo para comprobar si el software cumple con un
determinado requisito, el requisito debe eliminarse o revisarse
Verificable
110
Requisitos del software
Propiedades de la documentacin
Una SRS es completa si, y slo si incluye los elementos siguientes:
Todos los requisitos significativos, relativos a funcionalidad, rendimientos, restricciones
de diseo, atributos e interfaces externos.
Definicin de las respuestas del software a todas las posibles entradas de datos en toda
clase de situaciones. Es importante especificar las respuesta tanto para datos de
entrada vlidos, como invlidos.
Referencias a todas las imgenes, tablas y diagramas y definicin de todos los trminos
propios y unidades de medida no normalizadas.
No puede considerarse completa una SRS si en la descripcin de algunos requisitos se incluye la
frase A determinar o la expresin inglesa TBD (to be determined).
Si excepcionalmente se indica que un requisito se concretar ms adelante es necesario indicar
tambin:
Descripcin de las causas por las que no se ha concretado el requisito.
Descripcin de qu debe realizarse para poder eliminar el TBD, quin es la persona
responsable de llevarlo a cabo, y cundo debe eliminarse
Completa
111
Requisitos del software
Propiedades de la documentacin
Completos
A
Este bloque pertenece a
los requisitos que
conocemos y sabemos
que son aplicables al
problema
B
Este bloque pertenece a
los requisitos que
conocemos pero no
conocemos, es decir que
sabemos que existen pero
no hemos realizado su
anlisis.
D
Este bloque pertenece a
los requisitos que no
conocemos y tampoco
sabemos que no
conocemos
C
Este bloque pertenece a
los requisitos que
sabemos que son
aplicables al problema
pero que no entendemos
No Entendemos
Entendemos
Conocemos No Conocemos
Prototipado y
casos de uso
Prototipado
Entrevistas y revisiones
112
Requisitos del software
Propiedades de la documentacin
Una especificacin de requisitos de software es correcta si, y solo si todos y cada uno de los
requisitos indicados son los que debe cubrir el software del sistema.
No hay ninguna herramienta que pueda garantizar la correccin. Una SRS debe compararse con
las especificaciones de rango superior del proyecto (Descripcin del sistema, documentacin
referenciada, etc.) para comprobar que cumple sus indicciones.
Tambin es recomendable que la parte cliente determine si la especificacin de requisitos de
software refleja sus necesidades actuales
Correcta
C
A
B
Necesidades
del Usuario
Requisitos
Especificados
B
Requisitos
Correctos
Revisin y aprobacin
B
Requisitos
Correctos
113
Requisitos del software
Propiedades de la documentacin
El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia con
documentos superiores (ej. descripcin del sistema). La ausencia de esta congruencia supondra
un problema de correccin y no de consistencia.
Una documentacin es internamente consistente si, y solo si, no se establecen conflictos entre
requisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son:
Consistente
Conflictos
Objetos Lgicos Trminos
C=A+B
C=A*B
RF 10 Informe A
cierre de caja
RF 50 Informe A
cierre diario de operaciones
114
Requisitos del software
Propiedades de la documentacin
Un documento de requisitos es modificable si, y slo si su estilo y estructura permiten que
puedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, de
forma fcil, completa y consistente. La modificabilidad generalmente requiere en la
documentacin:
Que tenga una organizacin coherente y fcil, con una tabla de contenidos y un ndice..
Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares del
documento)
Exprese cada requisito por separado, mejor que mezclados con otros requisitos.
La redundancia, por s misma no es un error, pero puede acarrearlos. En ocasiones la
redundancia puede hacer un SRS ms legible, pero puede generar errores al actualizar el
documento, y generar inconsistencias si slo se actualiza una de las apariciones, olvidando la
otra.
Modificable
115
Requisitos del software
Propiedades de la documentacin
Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita su
referencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentacin. Se
recomiendan los dos tipos siguientes de trazabilidad:
Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuente
del requisito.
Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tener
un nombre o referencia nica.
La trazabilidad remota es importante cuando el producto de software entra en la fase de
operacin y mantenimiento. Al modificar el diseo y el cdigo es esencial poder determinar
todos los requisitos que quedan afectados por una modificacin
Trazable
116
Requisitos del software
Conclusiones
OBJETIVO
Desarrollar software
Desarrollar una
solucin
Tomar requisitos
del usuario
Comprender el entorno
y necesidades del usuario
Realizar procesos
normalizados para el
desarrollo de requisitos
Descripcin de requisitos
correcta
117
Requisitos del software
Conclusiones
MEDIOS FIN
Aplicar tcnicas
y procesos
Conseguir
el objetivo
118
4.- Diseo del software
119
Diseo del software
Diseo
Definicin
El proceso de definicin de la arquitectura, componente, interfaces y otras
caractersticas de un sistema o de un componente.
El resultado de este proceso.
IEEE std. 610.12-1990 Glossary of software engineering terminology
El diseo del software comprende la descripcin de la arquitectura del sistema con el nivel de
detalle suficiente para guiar su construccin.
Descomposicin del sistema
Organizacin entre los componentes del sistema
Interfaces entre los componentes
120
Diseo del software
Diseo
Diseo es la actividad del ciclo de vida en la que se analizan los requisitos del software para
desarrollar una descripcin de la estructura interna y la organizacin del sistema que servir de
base para su construccin.
Requisitos Diseo Construccin
121
Diseo del software
Diseo
Una vez conocidas las necesidades de los usuarios es preciso disear una solucin.
Empleando el smil con la construccin de edificios, tras conocer cuales son las necesidades que
se desean cubrir con un edificio (hotel, colegio, vivienda familiar, edificio de apartamentos),
es el momento de disear la solucin.
Las posibilidades son muchas, y exceptuando proyectos de tamao mnimo, la complejidad de
concebir todas las facetas e interacciones del sistema desborda la capacidad de abstraccin
mental para concebirlo en una nica visin. Al mismo tiempo es necesario que todas las
personas implicadas en el proyecto conozcan y compartan los planos de la solucin.
As pues, las razones del diseo son:
Concepcin u anlisis de las posibles soluciones.
Apoyo metodolgico para abordar la complejidad de la solucin.
Registro documentado como medio de comunicacin entre los participantes.
Un modelo es una representacin simplificada de la realidad.
De igual forma que al concebir un edificio se divide la complejidad del sistema para hacerlo
digerible, y se generan diversos modelos de los diferentes aspectos: planos de estructura,
planos del subsistema de fontanera, del de electricidad, etc. los sistemas de software son
tambin realidades complejas que es preciso conocer (modelizar) para llevar a cabo el diseo
de su solucin.
El diseo como creacin de modelos
122
Diseo del software
Actividades del diseo de software
Descripcin de la arquitectura general, identificacin de
sus componentes y su organizacin y relaciones en el
sistema.
Diseo de la arquitectura del software
El diseo del software comprende dos actividades intermedias entre la fase de requisitos y la de
construccin:
Diseo detallado del software
Definicin y estructura de los componentes y datos.
Definicin de los interfaces
Elaboracin de las estimaciones de tiempo y tamao.
Considerando que la descripcin del sistema (ConOps) dibuja una primera aproximacin del
sistema en su conjunto, algunos autores diferencian entre:
Diseo del sistema (la visin del documento de descripcin del sistema).
Diseo de la arquitectura
Diseo del detallado del software
123
Diseo del software
Razones del diseo del software
Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de
comenzar la construccin de un sistema son:
Permite la descomposicin del problema en partes y vistas de menor tamao, ms
manejables para el trabajo intelectual del diseo de la solucin.
Permite el desarrollo de modelos que se pueden analizar para determinar si cumplen
los distintos requisitos.
Permite examinar soluciones alternativas.
Los modelos se pueden utilizar para planificar el desarrollo de las actividades, y son el
punto de partida para empezar las actividades de codificacin y pruebas.
124
Diseo del software
Razones del diseo de software
Descomposicin de la complejidad
Class nombredeclase{
Public: funcion() {}
}
125
Diseo del software
Razones del diseo de software
Anlisis de soluciones posibles a travs de su modelado.
Disponibilidad
Coste desarrollo
Coste mantenimiento
Robustez
Tiempos de respuesta
Hardware necesario Etc.
?
Requisitos
126
Diseo del software
Razones del diseo de software
Elemento de comunicacin, Base de planificacin y del desarrollo
127
Diseo del software
Fin del proceso de diseo
Todas las preguntas Como tienen respuesta
La descripcin del diseo de la arquitectura est completada
La revisin del diseo se ha completado y cada equipo/persona implicado est de acuerdo
con el diseo.
Los borradores de manuales para mantenimiento y administracin estn realizados
Se ha realizado la trazabilidad del diseo
Se ha revisado el diseo de la arquitectura
Se ha verificado el diseo de la arquitectura
Se ha escrito la planificacin de la integracin del software.
Se ha establecido la lnea base del producto
Se considera que el proceso de diseo se ha completado cuando
128
Diseo del software
Vistas del diseo de la arquitectura
Un sistema de software es una entidad ortogonal que puede contemplarse o analizarse desde
diferentes vistas:
Puede enfocarse la atencin en:
Distribucin fsica del software entre los diferentes elementos del sistema.
Descomposicin en las diferentes funcionalidades que realiza.
Estructuras de la informacin que gestiona.
Etc.
De esta forma el diseo puede generar modelos para cada una de las diferentes vistas empleadas
en su anlisis (modelo fsico, modelo de datos, modelo se procesos, etc.).
129
Diseo del software
Notacin empleada
Si bien el concepto y la finalidad del diseo o modelado de un sistema de software es siempre el
mismo, las notaciones pueden variar en funcin de las caractersticas de cada proyecto o de los
conocimientos o preferencias de las personas u organizacin que lo realice.
A travs del lenguaje de modelado empleado (UML, IDEF, Diagramas de flujo, etc.) se consiguen
realizar dos tipo de descripciones:
Descripciones estructurales
Las notaciones para descripciones estructurales suelen ser grficas y representan los
diferentes componentes y sus relaciones.
Lenguajes de descripcin de arquitecturas (ADL): AADL, AESOP, CODE, MetaH,
Gestalt, Modechart, UML, Unicon, Modechart, etc.
Diagramas de clases y objetos
Diagramas de componentes
Diagramas entidad-relacin
Lenguajes de descripcin de interfaz
Etc.
Descripciones de comportamiento
Diagramas de actividad
Diagramas de colaboracin
Diagramas de flujo de datos
Diagramas de flujo
Pseudo-cdigo y lenguajes de diseo (PDL)
Diagramas de secuencia
Etc.
130
Diseo del software
Estrategias y mtodos para el diseo del software
Las principales estrategias que suelen emplearse para el diseo del software son:
Orientadas a funciones (estructurada)
Orientada a objetos (diseo orientado a objetos)
Diseo centrado en las estructuras de datos (menos empleado)
Diseo estructurado
Esta es la aproximacin clsica y se centra en la identificacin y descomposicin de las
principales funciones del sistema hacia niveles ms detallados.
Diseo orientado a objetos
Es la aproximacin ms popular actualmente, sobre la que se han desarrollado numerosos
mtodos partiendo de su concepcin inicial en la dcada de los 80
A travs del diseo orientado a objetos (OOD), se desarrollan las especificaciones de sistemas
como modelos de objetos (sistemas compuestos por conjuntos de objetos que interactan
entre ellos). que, expuesta de forma muy bsica, identifica a los nombres como objetos, a los
verbos como los comportamientos que pueden ofrecer y a los adjetivos como sus mtodos.
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
131
Diseo del software
El paradigma 00 Orientacin a objetos
OO no es una estrategia de diseo. El paradigma de orientacin a objetos es ms amplio
y abarca un enfoque general para conceptualizar, disear y programar los sistemas de
software.
Estrategias
Las estrategias OO cubren tanto los requisitos como el anlisis, diseo y programacin.
Anlisis Orientado a Objetos (OOA)
Diseo Orientado a Objetos (OOD)
Programacin Orientada a Objetos (OOP)
Mtodos
Las metodologas ms importantes de anlisis y diseo de sistemas, orientado a objetos, han
terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object
Management Group (www.omg.org).
Algunas de las principales metodologas, pioneras que han terminado confluyendo en el UML
son:
Object-Oriented Design (OOD), Booch.
Object Modeling Technique (OMT), Rumbaugh.
Object Oriented Analysis (OOA), Coad/Yourdon.
Hierarchical Object Oriented Design (HOOD), ESA.
Object Oriented Structured Design (OOSD), Wasserman.
Object Oriented Systems Analysis (OOSA), Shaler y Mellor.
Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
132
Diseo del software
El paradigma 00 Orientacin a objetos
Enfoque OO
Este paradigma centra su foco en el concepto Objeto.
Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y
reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos).
La estructura y comportamiento de objetos similares estn definidos en su clase comn; los
trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que
comparten una estructura y comportamiento comn.
La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe
en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un
objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede
ser un objeto.
Beneficios del enfoque OO
Los beneficios sealados por Booch en 1986 son:
Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de
programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS,
Ada, Java, C#
Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de
diseos completos.
Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y
por ello son ms resistentes al cambio en especificaciones y tecnologa.
133
Diseo del software
El paradigma 00 Orientacin a objetos
Principios del modelo OO
Abstraccin. Simplificacin en la descripcin o especificacin de un sistema consistente
en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de
otros.
Encapsulacin. Ocultacin de los detalles de un objeto que no contribuyen a sus
caractersticas esenciales.
Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de
mdulos coherentes e independientes.
Jerarqua o herencia. Orden de las abstracciones organizado por niveles.
Tipificacin. Definicin precisa de un objeto de forma tal que objetos de diferentes tipos
no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy
restringida.
Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est.
Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es
decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o al
espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue
creado).
Fundamentales: Abstraccin, encapsulacin, modularidad y jerarqua. Booch afirma que
un modelo en el que no est presente alguno de estos principios NO es un modelo OO.
Complementarios: Tipificacin, concurrencia y persistencia
134
Diseo del software
UML
UML es un lenguaje de modelado que permite especificar, visualizar y documentar modelos de
sistemas de software.
Desde sus inicios fue concebido para ayudar a las tareas de anlisis de los sistemas de software, y
este es sin duda el mbito de mayor utilizacin, si bien es cierto que en la actualidad tambin se
emplea en el modelado y diseo de otros tipos de sistemas (modelos de negocio, producciones
cinematogrficas, etc.)
Tipos de diagramas UML
UML proporciona diagramas para representar modelos de las visiones estticas y dinmicas del
sistema, as como de su modularizacin.
Estructura esttica Comportamiento dinmico Modularizacin
REPRESENTACIONES
Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de despliegue
Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboracin
Diagrama de actividad
Diagrama de colaboracin
Diagrama de estados
Paquetes
Subsistemas
Modelos
135
Diseo del software
Descripcin del diseo del software (SDD)
El resultado del proceso de diseo es la documentacin denominada Descripcin del Diseo del
Software.
Un estndar empleado para desarrollar esta documentacin de forma normalizada es el IEEE Std.
1016-1998.
IEEE Std. 1016-1998
Describe prcticas recomendadas para describir los diseos de software. Especifica la informacin
que debe contener, y recomienda cmo organizarla.
Puede emplearse en software comercial, cientfico o militar sin limitaciones por el tamao,
complejidad o nivel de criticidad.
El estndar no establece ni limita determinadas metodologas de diseo, gestin de la
configuracin o aseguramiento de la calidad.
136
Diseo del software
Descripcin del diseo del software (SDD)
Ejemplo de una posible organizacin de la informacin en una SDD
1.- Introduccin
1.1 Propsito
1.2 Alcance
1.3 Definiciones y acrnimos
2.- Referencias
3.- Descomposicin de la informacin
3.1 Descomposicin modular
3.1.1. Descripcin del mdulo 1
3.1.2. Descripcin del mdulo 2
3.2 Descomposicin de los proceesos
3.2.1. Descomposicin del proceso
1
3.2.2. Descomposicin del proceso
2
3.3 Descomposicin de los datos
3.3.1. Descripcin de la entidad 1
3.3.2. Descripcin de la entidad 2
4.- Descripcin de las dependencias
4.1 Dependencias intermolulares
4.2 Dependencias inter-procesos
4.3 Dependencias de los datos
5.- Descripcin de interfaces
5.1 Interfaces entre mdulos
5.1.1 Interfaz del mdulo 1
5.1.2 Interfaz del mdulo 2
5.2 Interfaces entre procesos
5.2.1 Interfaz del proceso 1
5.2.2 Interfaz del proceso 2
6.- Diseo detallado
6.1 Diseo detallado de los mdulos
6.1.1 Detalle del mdulo 1
6.1.2 Detalle del mdulo 2
6.2 Diseo detallado de los datos
6.1.1 Detalle de la entidad 1
6.1.2 Detalle de la entidad 2
137
Diseo del software
Comprobacin de que el diseo incluye todos lols requisitos
Comprobacin de que el diseo no incluye funciones adicionales no
especificadas en el SRS.
Los resultados de la trazabiliad del diseo deben estar
documentados para la reunin de revisin del diseo
Trazabilidad del diseo
Prcticas recomendadas
Reunin de revisin del diseo de la arquitectura
Revisin del diseo de la arquitectura
Un equipo apropiado (Usuarios, cliente, ingeniero de soft) revisan el diseo.
Una vez aprobado este diseo de puede comenzar a realizar el diseo detallado.
Verificacin del diseo de la arquitectura
El diseo se verifica contra el SRS
El proceso de verificacin analiza si el diseo es incompleto, incorrecto, ineficiente, difcil de
mantener, presenta un interfaz de usuario difcil de utilizar o aprender, o la documentacin
es de baja calidad.
Se realiza un informe para documentar los posibles problemas encontrados y tomar nota de
posibles incompatibilidades entre documentos.
LNEA BASE DE REQUISITOS
LNEA BASE DE DISEO
QU
CMO
138
Diseo del software
Base para las tareas de planificacin
La planificacin comienza con la misma decisin de desarrollar un sistema de software, y es un
esfuerzo continuo que termina cuando el proyecto ha concluido.
La planificacin consiste en la especificacin de:
Metas y objetivos para el proyecto
Estrategias, poltica, y procedimientos
Explicndolo de otra forma es la decisin de:
qu hacer
cmo hacerlo
cuando hacerlo
quien va a hacerlo.
A lo largo del ciclo de vida, desde la concepcin inicial del proyecto, la planificacin se va
revisando y depurando, y una vez obtenido el diseo se dispone de una base slida.
El diseo es la representacin formal de qu hacer y cmo hacerlo, sobre la que se
puede asignar cando y quin.
139
Diseo del software
Planificacin = tareas de ingeniera del software y de gestin
La planificacin del proyecto est dividido entre dos componentes relacionados:
Planificacin realizada por el gestor
Planificacin realizada por el ingeniero de sistemas
Qu tareas hay que realizar
Orden y Dependencias de tareas
Tamao (Esfuerzo en horas)
Solucin tcnica para la resolucin del problema
Qu herramientas de anlisis y diseo hay que
utilizar
Riesgos tcnicos
El modelo de procesos (Tcnicas)
Actualizar la planificacin cuando los requisitos o el
entorno cambian.
Ingeniero de Software decide:
Las habilidades necesarias para realizar las tareas
La agenda para terminar el proyecto
El coste de esfuerzo
Metodologa para evaluar el estatus del proyecto
Qu herramientas de planificacin hay que utilizar
Gestin de riesgos
El modelo de procesos (Gestin)
Actualizar la planificacin cuando condiciones de
gestin y entorno cambian.
Gestor de Proyecto decide:
140
Diseo del software
Consideraciones
El diseo es la estrategia de solucin.
Las tareas de codificacin, integracin y mantenimiento del sistema son la tctica.
La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos
de calidad esperados).
No surge de procesos, herramientas o lenguajes de modelado.
Surge del talento de su creador.
Los procesos, las herramientas y los lenguajes de modelado pueden resultar tiles como
ayuda para descomponer la complejidad, y para comunicar el diseo a los participantes del
proyecto.
El talento de algunos profesionales les puede permitir manejar niveles de complejidad
elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado.
A travs del cdigo es posible ver el diseo y la arquitectura del sistema.
La documentacin del cdigo resulta til para comunicar su diseo a travs del espacio en
sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su
mantenimiento.
Al emplear documentacin para la comunicacin del diseo es necesario trabajar con
procesos suficientes para garantizar su integridad y actualidad a travs de los cambios.
El diseo no cumple su finalidad hasta que no queda plasmado en el cdigo.
El resultado del diseo puede fallar tanto errores en su estrategia como por distorsiones
introducidas en la codificacin, integracin y mantenimiento.
141
5.-Documentacin de usuario
142
Documentacin de usuario
Conceptos generales
Interno
Documentacin de usuario que se encuentra integrada y es accesible a travs del software.
Externo
Documentacin de usuario que cuyo acceso no est integrado en la operativa del software.
El formato externo no quiere decir que emplee una distribucin no informtica, sino que se
encuentra apartada de la operacin del software.
De hecho la documentacin externa puede distribuirse en CD, a travs de descargas desde
la web, etc.
Formatos de distribucin
Importancia de la calidad de la documentacin
A pesar de su importancia, las organizaciones productoras de software suelen descuidar la calidad
de la documentacin de usuario.
En muchos casos la documentacin se prepara en el ltimo minuto, y orientando su desarrollo ms
como trmite que como herramienta de informacin para el usuario.
Ayuda al cliente a obtener todo el valor de su inversin.
La operacin de sistemas complejos sin un conocimiento detallado de los mismos puede
dejar sin uso un porcentaje importante de los mismos.
Una documentacin completa y til incrementa la facilidad de uso del sistema.
LA PRODUCCIN DE DOCUMENTACIN DE USUARIO INADECUADA ES UN PROBLEMA
COMN EN LA INDUSTRIA DEL SOFTWARE
143
Documentacin de usuario
Conceptos generales
La documentacin de usuario de un sistema de software puede estar comprendida en uno o varios
documentos fsicos.
Un documento puede abordar uno o varios de los siguientes mbitos:
Instalacin / desinstalacin.
Uso del sistema.
Administracin.
Un sistema de software puede disponer de manuales diferentes para cada uno de los subsistemas
que lo componen.
Tipos de documentos y contenidos posibles
P1
144
Documentacin de usuario
Conceptos generales
La documentacin de usuario puede adoptar dos modos narrativos diferentes: formativo o
referencia, en funcin de la finalidad con la que el lector va a usar el texto:
Para aprender a trabajar con el software (modo formativo)
Para refrescar la memoria, realizando consultas puntuales (modo referencia).
A su vez, los textos formativos pueden orientar la exposicin de sus contenidos para indicar al lector
cmo realizar cada tarea paso a paso. (orientados a tareas), o para transmitirle la informacin y
conocimientos tcnicos necesarios para emplear el software de forma adecuada (orientados a la
informacin).
Modos descriptivos
Modos descriptivos
Formativo
Referencia
Orientado a tareas
Orientado a la
informacin
E1
145
Documentacin de usuario
Desarrollo de la documentacin
En funcin de las caractersticas del sistema, de los usuarios e incluso de parmetros del proyecto,
es necesario determinar cules son los documentos que debernelaborarse.
Algunos factores que pueden resultar tiles en su determinacin son:
Naturaleza del producto, fin previsto, entorno en el que se emplear, complejidad de uso
vista desde el punto de vista del usuario. Cmo de complejo es instalar, operar y mantener
el sistema.
Nivel de conocimientos de los usuarios, instaladores y personal de mantenimiento.
En el uso de sistemas informticos.
En los procesos y negocio gestionados por el sistema.
Tamao y complejidad del sistema, junto con las tecnologas empleadas en su desarrollo y
mantenimiento.
Requisitos contratados.
Ciclo de desarrollo del producto.
As por ejemplo, un producto con desarrollo incremental puede tener como requisitos en el contrato
la elaboracin de manuales de usuario para cada subsistema entregado, o uno global para todo el
sistema.
Documentos necesarios
Los factores que deben determinarse antes de desarrollar la documentacin son:
Cules son los documentos necesarios.
Las caractersticas de la audiencia o audiencias de la documentacin.
El modo descriptivo de cada documento.
146
Documentacin de usuario
Desarrollo de la documentacin
Antes de comenzar el desarrollo de la documentacin es importante clasificar a los usuarios del
sistema por audiencias, identificando las caractersticas clave.
La documentacin debe plantearse pensando en las caractersticas y necesidades de la audiencia.
Algunos criterios tiles para identificar las audiencias y sus caractersticas:
Educacin:Cul es el nivel educativo de la audiencia?
Actitud: Cul es la actitud de la audiencia?. Son reacios al uso de ordenadores?.
Presentan resistencia al cambio?
Nivel de sofisticacin informtica. A ttulo de ejemplo, Brockmann
[1]
identifica cinco
niveles de sofisticacin informtica de los usuarios, que se muestran en la pgina siguiente.
Familiaridad con los procesos y negocio de la aplicacin.
Caractersticas de la audiencia o audiencias
Audiencia: grupo de usuarios con caractersticas similares, tanto de operacin con el sistema,
como de conocimientos y experiencia informtica y profesional.
[1] Brockmann, R.J. (1990). Writing Better Computer Documentation: From Paper to Hypertext
P2
147
Documentacin de usuario
Desarrollo de la documentacin
Clasificacin de usuarios
Experto
Inexperto
[1]
Principiante
Intermedio
Intermitente
Nivel de sofisticacin informtica
Muy poca o ninguna experiencia con ordenadores
Tratan volmenes reducidos de informacin
No confan en la informtica
Trabajadores concretos
Caractersticas
Alguna experiencia con ordenadores
Pueden comprender conceptos aislados
Emplean ejemplos concretos
Emplean siempre las opciones por defecto
Usuario novel con pocos meses de experiencia con
ordenadores
Comienza a enlazar conceptos aislados
Emplea acciones por defecto y sus opciones.
Es la evolucin de un usuario intermedio.
Comprende las relaciones entre conceptos aislados.
Tiene un nivel alto de autoconfianza.
Comprende el lenguaje abstracto
Puede ser inexperto, principiante, intermedio o
experto. Trabaja muy poco con el sistema.
Se conduce a travs de los mens y mensajes del
sistema
[1] La denominacin original que hace Brockmann en su libro es lorito (parrot)
148
Documentacin de usuario
Estructura de la documentacin de usuario
Por estructura de la documentacin se entiende la manera en la que la informacin se divide en
apartados, y el orden en el que stos se presentan.
La estructura afecta tanto a documentos impresos como a documentos electrnicos.
La documentacin puede estructurarse en uno o varios documentos.
La estructura debe ayudar a localizar y comprender la informacin.
Cuando la documentacin de un sistema se dirige a audiencias diferentes debe emplearse uno de
los siguientes criterios:
Separar en secciones diferentes la informacin dirigida a audiencias diferentes, identificando
en la introduccin de cada seccin la audiencia a la que va dirigida.
Separar en documentos diferentes la informacin para cada audiencia.
E2
149
Documentacin de usuario
Estructura de la documentacin de usuario
La documentacin de un sistema de software puede consistir en uno o ms documentos, y cada
documento puede comprender uno o varios volmenes. Por ejemplo la referencia de comandos de
un lenguaje de programacin puede tener un volumen con la mitad de ellos y otro con la otra
mitad.
Son recomendables (aunque no obligatorio) las siguientes divisiones dentro de cada documento:
Documentos impresos: Captulos, temas y sub-temas.
Documentos electrnicos: temas.
La unidad de presentacin para los primeros es la pgina, y para los segundos la pantalla.
Cada pgina o pantalla debe tener una identificacin nica (por ejemplo el ttulo del captulo y
el n de pgina), que debe aparecer al imprimirla el usuario.
Los documentos impresos no deben tener ms de tres niveles de subdivisin dentro de un
captulo. As, por ejemplo, un sub-tema con nivel 1.2.3.4 debe ser el mayor nivel de sub-divisin.
Los documentos electrnicos deben permitir acceder a cualquier informacin con menos de 3
saltos (links) desde la pgina inicial.
Los documentos que contengan informacin en varios modos descriptivos (formativo y de
referencia) deben estar claramente separados en captulos diferentes, o al menos en temas
diferentes o manteniendo formatos tipogrficos distintos.
La documentacin en modo de referencia debe estar estructurada para facilitar la bsqueda y
acceso a los diferentes elementos. Por ejemplo, ordenando alfabticamente una lista de
comandos, o de informes de error.
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Estructura general
150
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Cada documento debe incluir
INFORMACIN IDENTIFICATIVA
Ttulo del documento
Versin del documento y fecha de publicacin
Nombre del producto de software y versin
Organizacin que edita el documento
TABLA DE CONTENIDOS (ndice)
INTRODUCCIN
Audiencia
Alcance y propsito del documento
Descripcin general del propsito y funcionalidad
del software, as como del entorno de operacin
E3
151
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Informacin crtica
La informacin crtica debe aparecer en una ubicacin destacada de la
documentacin.
Las advertencias de carcter general deben incluirse en la introduccin del
documento.
Las advertencias particulares deben aparecer en la misma pgina o pantalla en
la que se da informacin del procedimiento implicado
!
Contenido
La informacin debe ser completa
Si es en modo formativo debe incluir descripcin suficiente para que los
individuos con menos experiencia de la audiencia puedan realizar
eficientemente las funciones descritas.
En modo referencia se deben incluir todas las instancias de los elementos
seleccionados.
La informacin debe ser actual y acorde a la versin del software indicada.
152
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE OBLIGATORIO?
Informacin identificativa S
Tabla de contenidos S, en documentos de ms de 8 pginas
Lista de imgenes Opcional
Introduccin S
Informacin para el uso de la documentacin S
Informacin conceptual de las funcionalidades
generales
S
153
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE OBLIGATORIO?
Procedimientos S, en modo formativo
Informacin de comandos de software S, en modo referencia
Mensajes de error y resolucin de problemas S
Glosario
S, si la documentacin incluye trminos
desconocidos para la audiencia
Fuentes de informacin adicionales Opcional
ndice S, en documentos de ms de 40 pginas
Capacidad de bsqueda S, en documentacin sobre formato electrnico
154
Documentacin de usuario
Estructura de la documentacin de usuario
Recomendaciones generales
La documentacin impresa y electrnica debe resultar legible para el usuario, teniendo en cuenta la
distancia que se emplear en las condiciones normales del entorno de consulta. Deben emplearse
tipos de letra y colores fcilmente legibles sobre el color de fondo empleado. La documentacin
impresa debe mantenerse legible si el usuario agranda o reduce la ventana de visualizacin.
El estndar IEEE 1063, por ejemplo, da algunas recomendaciones especficas como:
No abusar de las letras maysculas, indicando que no se emplee en ms de 25 palabras
seguidas.
No emplear en los textos electrnicos letras menores de 3mm. (aprox. 7,5 puntos).
En la documentacin electrnica deben considerarse tambin las combinaciones de colores
previendo el caso de que el usuario vaya a imprimirla en una impresora monocromo.
Legibilidad
Correccin
Los textos deben ser lxica, ortogrfica y sintcticamente correctos.
Consistencia en la terminologa y en el formato
El documento debe emplear de forma consistente la terminologa empleada para nombrar los
elementos del interfaz de usuario, nombres de operaciones, funciones, procesos y conceptos claves
del sistema.
Asimismo debe respetar a travs de todo el documento unas caractersticas grficas homogneas:
cabeceras, pies de pgina, estilos de ttulos y prrafos, mrgenes, estilos de vietas, etc.
Las convenciones empleadas para mostrar las advertencias y notas resaltadas deben presentarse
con las mismas caractersticas de estilo en todo el documento.
155
6.- Verificacin y validacin
E1
156
Verificacin y validacin
Introduccin
Durante el desarrollo de un sistema de software, antes de producir el producto ejecutable final, se
generan mltiples productos intermedios:
Especificaciones de requisitos.
Diseo.
Planes de prueba.
Cdigo.
Al mismo tiempo el producto final se genera a travs de las tareas y actividades realizadas en
diferentes procesos:
Adquisicin.
Suministro.
Desarrollo.
Etc.
La complejidad del desarrollo de un sistema de software
Los errores introducidos en los productos intermedios se transmiten al
producto final.
Las calidad del producto final depende de la calidad imprimida en las
diferentes tareas, actividades y procesos.
E2
157
Verificacin y validacin
Introduccin
Aunque en el lenguaje coloquial estos trminos pueden considerarse sinnimos, en el contexto de la
ingeniera del software tienen significados diferentes:
Verificacin: Determinacin con medios objetivos y repetibles de que un elemento
satisface los requisitos.
Validacin: Determinacin con medios objetivos y repetibles de que un elemento puede
emplearse para el fin que tiene asignado.
Verificacin y validacin
Coste de la validacin y verificacin
Las actividades de validacin y verificacin en un proyecto requieren un esfuerzo, que debe
estimarse y planificarse de forma apropiada en el plan del proyecto.
En funcin de las caractersticas del proyecto los costes directos e indirectos suelen situarse en
rangos del 5% al 40%
[1]
del coste total del proyecto.
[1] Boehm Software Engineering Economics 1981 Marciniak J.J. Encyclopedia of Software Engineering 1994 Neal, R.D. A Case
Study of IV & V Cost Efectiveness 1997
P1
158
Verificacin y validacin
Conceptos
Es la disciplina de gestin y actividad tcnica para garantizar que el software operar segn lo
especificado en los requisitos y las necesidades del usuario, que se lleva a cabo a travs de:
Proceso proactivo de anlisis, revisin y pruebas.
Gestin en paralelo con las actividades de desarrollo para garantizar que el software cumple
los objetivos de correccin, calidad, rendimiento, agendas y usabilidad.
Verificacin y validacin
Verificacin: Mtodo empleado para garantizar que el producto resultante de una
actividad o fase del desarrollo cumple con los requisitos de esa actividad o fase en lo
relativo a correccin, calidad, rendimiento, cumplimiento de agendas y usabilidad.
Validacin: Mtodo que garantiza que el producto es conforme para el uso que tiene
previsto.
Verificacin
Se est construyendo adecuadamente el producto?
La verificacin se realiza contra el entorno de desarrollo o del proyecto.
Validacin:
Se est construyendo el producto adecuado?
La validacin se realiza contra el entorno cliente, donde el producto debe
cumplir su finalidad.
159
Verificacin y validacin
Verificacin: Mtodo empleado para garantizar que el producto resultante de una
actividad o fase del desarrollo cumple con los requisitos de esa actividad o fase en lo
relativo a correccin, calidad, rendimiento, cumplimiento de agendas y usabilidad.
Validacin: Mtodo que garantiza que el producto es conforme para el uso que tiene
previsto.
E3
160
Verificacin y validacin
Verificacin y validacin en los procesos de desarrollo
5. Procesos primarios 6.- Procesos de soporte
7. Procesos organizacionales
5.1 Adquisicin
5.2 Suministro
5.3
Desarrollo
5.3
Operacin
5.3
Mantenimiento
6.1 Documentacin
6.2 Gestin de la configuracin
6.3 Control de calidad
6.4 Verificacin
6.5 Validacin
6.6 Reuniones
6.7 Auditora
6.8 Resolucin de problemas
7.1 Gestin
7.3 Mejora
7.2 Infraestructura
7.4 Formacin
161
Verificacin y validacin
Verificacin y validacin en los procesos de desarrollo
Las actividades de verificacin y validacin pueden realizarse en diversas fases y sobre diversos
productos del desarrollo.
Por esta razn estn clasificados como procesos de soporte, que son llamados por otros procesos
del ciclo de vida.
As, por ejemplo, si el estndar 830 de IEEE se emplea para regular cmo debe hacerse el
documento de especificacin de requisitos del software, resulta posible y probable que durante el
curso del desarrollo se revise el documento para ver si se ajusta a las caractersticas definidas en el
estndar (verificacin).
Tambin resulta posible (y muy recomendable) que se contraste el documento generado con
interlocutores del cliente para comprobar que lo escrito refleja sus necesidades (validacin).
Si la agenda del plan de proyecto prevea disponer del diseo en la fecha X, parece lgico que
regularmente se verifique si los procesos estn inyectando causas de problemas en el proyecto
(incumpliendo agendas, en este caso).
El esfuerzo de verificacin y validacin debe ajustarse a las caractersticas del proyecto. En
algunos casos resultar aconsejable o necesario generar un plan de verificacin y validacin del
software que se ajuste a estndares como el IEEE 1012-1998, y en otros casos bastar con tareas
bsicas de verificacin yvalidacin, contempladas y dimensionadas en el plan del proyecto.
Procesos de soporte
162
Verificacin y validacin
Relacin entre V&V y el Aseguramiento de la Calidad
La funcin del Aseguramiento de la Calidad es garantizar que la organizacin realiza el trabajo
conforme a los procedimientos y mtodos establecidos para el proyecto.
IEEE Std. 730-1998
Aseguramiento de la calidad
Es frecuente encontrar cierta confusin entre estas dos reas.
El Aseguramiento de la calidad (SQA) es una metodologa interna cuya principal finalidad es
garantizar que el flujo del trabajo cumple con las normas que tiene impuestas el desarrollador (por
su normativa interna, por imposicin del cliente, etc.).
SQA no evala el producto producido en esa fase o en ese proyecto, sino el
proceso que lo ha producido. No mira el producto, mira el proceso.
Validacin y Verificacin enfocan su anlisis en atributos del producto
generado.
Relacin con Verificacin y validacin.
163
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Las consideraciones que deben contemplarse para evaluar la planificacin de las actividades de
Validacin y Verificacin son:
Nivel de integridad del proyecto.
Concepto desarrollado en las pginas siguientes. Mide la criticidad del software.
Mnimo de tareas recomendadas para el nivel de integridad del proyecto.
La regulacin interna de la organizacin desarrolladora puede determinar qu tareas de V&V
deben realizarse para cada nivel de integridad.
El estndar IEEE 1012 define 4 niveles de integridad e incorpora una tabla en la que se
estipulan las actividades mnimas de V&V en funcin del nivel.
Intensidad y rigor necesarios en las tareas de Validacin y verificacin.
El nivel de integridad no slo determina qu tareas deben realizarse, sino tambin su
intensidad y rigor. Por ejemplo, si lo realiza el propio personal de desarrollo, otro equipo de
desarrollo diferente, o incluso una organizacin externa (auditora).
Los criterios que se emplearn en las tareas de V&V para establecer los parmetros
mnimos de correccin, consistencia, precisin
Definiendo los objetivos
164
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
El estndar IEEE 1012 establece que el plan de validacin y verificacin del software (SVVP) debe
especificar un mtodo para clasificar el nivel de integridad del software de cada subsistema de
software del proyecto.
Criticidad del producto
E4
165
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Proceso para identificar, evaluar y categorizar el grado de criticidad de los elementos del producto
de software.
La definicin formal incluida en el estndar IEEE 1012-1998 es:
La evaluacin estructurada de las caractersticas del software (p. ej. Seguridad, complejidad,
rendimiento) para determinar la severidad del impacto de un fallo del sistema, de su degradacin o
de su no cumplimiento con los requisitos o los objetivos del sistema.
En otras palabras:
Anlisis de criticidad
Anlisis de criticidad
Anlisis de daos
(hazard analysis)
Anlisis de riesgos
(risk analysis)
Si el sistema falla, se degrada o no consigue realizar las funciones de los
requisitos, qu impacto tiene en la seguridad o en el rendimiento?
166
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
La definicin formal del anlisis de daos (a nivel de sistema) es:
Anlisis de fuentes potenciales de daos o de situaciones que pueden generar daos en trminos
de daos a personas, daos a la salud, o al entorno, o una combinacin de ellos.
IEC 60300-3-9, 1995
No obstante el estndar para validacin y verificacin IEEE 1012-1998 da una definicin ms amplia
que incluye tambin prdidas econmicas, fallo en la misin del sistema, o impacto social adverso.
Para nosotros dao en el marco de validacin y verificacin de software incluye por tanto:
Daos a las personas.
Daos al medio ambiente.
Prdidas econmicas.
Fallo en la finalidad del sistema.
Impacto social adverso.
Para realizar el anlisis de daos deben identificarse las consecuencias que pueden ocasionar
los fallos en el software. Es posible que no generen daos fsicos, pero s en trminos de
prdidas econmicas (para el desarrollador, para el cliente, para los usuarios), o de impacto social
adverso (desprestigio del cliente, del desarrollador, de los usuarios, de terceros).
Anlisis de criticidad: anlisis de daos
167
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
En el desarrollo de un sistema de software se pueden producir adversidades que afecten a:
Los planes del proyecto.
Al producto o subproductos del desarrollo.
Los riesgos inherentes a un proyecto suelen ser de tres naturalezas:
Intrnsecos al sistema que se desarrolla
Derivados de las particularidades de desarrollo del software.
Propios del desarrollo de proyectos.
Anlisis de criticidad: anlisis de riesgos
Riesgo: probabilidad de que se produzca un dao identificado
P2
P3
168
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos
Propios del sistema
Propios del desarrollo
de software
Propios de los desarrollos
por proyecto
[1]
NATURALEZA DEL RIESGO CAUSAS TPICAS
Los identificados en el anlisis de daos
Complejidad innecesaria
Complejidad intrnseca del diseo mayor de la necesaria
Baja calidad
Incumplimiento de estndares necesarios
Inestabilidad de los requisitos
Problemas con herramientas y mtodos
Inestabilidad, bugs en compiladores, etc.
Comportamiento imprevisto de los interfaces
Interfaces con hardw. y softw. externo en la implementac.
Inestabilidad y cambio rpido de las
plataformas tecnolgicas
Presin en costes y agendas.
Lagunas en planificacin y gestin.
Retrasos en subcontrataciones.
[1] En los proyectos de software se suelen dar con mayor intensidad los riesgos tpicos indicados.
169
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos
[1] En los proyectos de software se suelen dar con mayor intensidad los riestos tpicos indicados.
Validacin y Verificacin no gestionan las causas de los riesgos. Esa gestin pertenece a la gestin
de riesgos, dentro de la gestin del proyecto.
Gestin de proyecto
(Gestin de riesgos)
Validacin
Verificacin
Dirige el esfuerzo en la identificacin de los riesgos y la
cuantificacin de su posible impacto, para determinar
el nivel de integridad del proyecto.
Dirige el esfuerzo en la identificacin de los riesgos para
desarrollar un plan de accin para reducir la probabilidad
de cada riesgo en funcin de la magnitud de su impacto,
as como para prever las acciones si se llegan a producir
Daos.
170
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Una vez realizado el anlisis de criticidad a travs de los anlisis de
daos y de riesgos, resulta posible establecer el nivel de integridad
del proyecto y adecuar a l las tareas de validacin y verificacin.
Niveles de integridad
Anlisis de criticidad
Anlisis de daos
(hazard analysis)
Anlisis de riesgos
(risk analysis)
NIVEL DE
INTEGRIDAD
Adecuacin de las
tareas de
VALIDACIN
y
VERIFICACIN
El nivel de criticidad depende de dos factores:
MAGNITUD DEL DAO POSIBLE POSIBILIDAD DE MITIGACIN
DEL DAO
171
Verificacin y validacin
Adecuacin de V&V a las caractersticas del proyecto
Niveles de integridad
El estndar IEEE 1012-1998 define 4 niveles de integridad.
En el borrador de 2004 las definiciones que se recogen para cada uno son:
Nivel Dimensin del dao por fallo del Software Mitigacin aplicable
4
Prdida de vida
Prdida del sistema
Graves prdidas econmicas o sociales
No es posible mitigar
los daos producidos
3
El sistema no realiza el fin previsto ni en
todo ni en parte.
Graves prdidas econmicas o sociales
Es posible una mitigacin
parcial de los daos producidos
2
No se pueden realizar funcionalidades
parciales del sistema.
Prdidas econmicas o sociales importantes
Se pueden mitigar los
daos producidos
1
Una determinada funcionalidad del sistema
no se realiza.
Consecuencias mnimas
No es necesario mitigar
los daos
El modelo del estndar resulta vlido, pero cualquier modelo, adecuado a las circunstancias del
sistema y del entorno de desarrollo, puede resultar igualmente vlido.
172
Verificacin y validacin
Independencia
Adecuacin de V&V a las caractersticas del proyecto
La determinacin de las personas responsables de las tareas de verificacin y validacin, depende
de:
Caractersticas y naturaleza del proyecto
Nivel de integridad
La independencia puede aplicarse a distintas reas del proyecto:
Independencia de gestin
Las personas que realizan las tareas de verificacin y validacin se gestion al margen de la
organizacin que realiza el desarrollo. Tienen la autoridad para tomar decisiones sobre el
trabajo de V&V, incluyendo qu elementos se van a analizar, con qu herramientas. Facilitan
la informacin de sus conclusiones tanto a los desarrolladores como al adquiriente, pero
slo el adquiriente puede modificar la lnea de trabajo de validacin y verificacin.
Independencia tcnica
Las personas que analizan el proyecto son ajenas al grupo de desarrollo. Emplean sus
propias herramientas, mtodos y recursos.
Independencia financiera
Las tareas de verificacin y validacin cuentan con presupuesto propio, y la autoridad para
modificar su presupuesto est fuera de la organizacin desarrolladora.
P4
P5
173
Verificacin y validacin
Tipos de independencia
Adecuacin de V&V a las caractersticas del proyecto
La validacin y verificacin independiente (IV&V) se clasifica en 4 tipos, en funcin del rigor con el
que se realiza: clsica, modificada, interna y domstica. Los proyectos con nivel de integridad 4
requieren independencia rigurosa en todas sus reas.
El estndar IEEE 1012-1998 muestra con la siguiente tabla el grado de independencia generalmente
proporcionado por cada tipo, para cada faceta del proyecto.
Tipos de independencia
Gestin Tcnica Financiera
reas
CLSICA I I I
MODIFICADA I-R I I
INTERNA I-R I-R I-R
DOMSTICA I-M I-M I-M
I: Independencia rigurosa IR: Independencia con reparos IM: Independencia mnima
174
Verificacin y validacin
Tipos de independencia
Adecuacin de V&V a las caractersticas del proyecto
Normalmente requerida para proyectos con nivel de integridad 4.
Exige rigurosa independencia en las 3 reas del proyecto.
IV&V CLSICA
IV&V MODIFICADA
Suele emplearse en proyectos con nivel de integridad 3.
El desarrollo y la V&V lo realizan organizaciones diferentes, pero la responsabilidad de la gestin en
el proyecto es nica, y es la que recibe la informacin de ambas partes. No obstante, los
presupuestos y el personal tcnico estn separados.
IV&V INTERNA
Se emplea cuando el equipo de V&V pertenece a la misma organizacin desarrolladora, pero en la
forma de una entidad diferenciada del grupo de desarrollo del proyecto.
IV&V DOMSTICA
Se emplea personal de la organizacin desarrolladora para realizar la V&V. El personal de desarrollo
y de validacin y verificacin trabaja conjuntamente. No se puede garantizar la independencia
tcnica, y la gestin y el presupuesto son nicos para desarrollo y V&V.
175
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
Las tareas de verificacin y validacin se deben realizar en paralelo con los procesos del ciclo de
vida, incluyendo tambin la gestin del proyecto.
Gestin
Verificacin y Validacin
Adquisicin Suministro Desarrollo Operacin Mantenim.
GESTIN
El objetivo del trabajo de verificacin y validacin es garantizar que el software tiene la integridad
requerida.
Este trabajo debe realizarse de forma integrada en la gestin del proyecto y puede comprender:
Desarrollo del plan de validacin y verificacin.
Valoracin de las modificaciones.
Supervisin de las actividades de verificacin y validacin
Planificacin, monitorizacin y control del trabajo de validacin y verificacin.
Etc.
176
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
ADQUISICIN
En el proceso de adquisicin el trabajo de verificacin y validacin debe incluir siempre
Revisin de la descripcin del sistema.
En funcin del nivel de integridad del proyecto, puede cubrir tambin:
Valoracin de la dimensin y alcance de los trabajos de V&V.
Planificacin de la comunicacin entre los trabajos de V&V y la organizacin desarrolladora.
SUMINISTRO
El proceso de verificacin y validacin comienza cuando un suministrador decide atender la peticin
de adquisicin. V&V se enfoca en determinar si la documentacin e informacin facilitada por el
adquiriente es consistente y si, en opinin del suministrador, la solucin satisfar las necesidades de
los clientes.
Este proceso se denomina verificacin del contrato.
177
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
DESARROLLO
La verificacin y validacin en el desarrollo centra su actividad en 6 tareas, que corresponden a las
5 tpicas de los ciclos de desarrollo en cascada, ms instalacin.
V&V EN EL PROCESO DE DESARROLLO
CONCEPTO REQUISITOS DISEO
IMPLEMENTACIN PRUEBAS INSTALACIN
Si en el ciclo de vida empleado por el proyecto, la incorporacin de estas actividades est
modificada, el proceso de verificacin y validacin tambin se adecuar a las caractersticas del
proyecto.
V & V CONCEPTO
La verificacin y validacin del concepto trabaja sobre la descripcin del sistema, lleva a cabo el
anlisis de criticidad, estudiando y evaluando daos y riesgos; y genera o actualiza el plan de
validacin y verificacin.
178
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V REQUISITOS
En esta fase, la verificacin y validacin comprueba el principal producto generado en esta fase: la
especificacin de requisitos del software.
Se analizan las propiedades de calidad
DEL DOCUMENTO
Completo
Correcto
Consistente
Modificable
Trazable
Posibles
Necesarios
Priorizados
Correctos
Verificables
DE LOS REQUISITOS
V & V DISEO
Comprobacin de que el diseo realizado comprende todos los requisitos sin omisiones y sin
complejidad innecesaria. Los aspectos generales que se analizan son:
Trazabilidad entre requisitos y diseo.
No hay omisiones ni aadidos.
El diseo es apropiado para los objetivos deseados del sistema.
El diseo es conforme con los estndares, prcticas y convenciones acordadas para el
proyecto
El diseo es comprensible por el equipo de desarrollo y el posterior de mantenimiento.
Contiene informacin suficiente para realizar las pruebas de unidad y de integracin.
La documentacin est completa, incluyendo grficas o especificaciones necesarias.
179
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V IMPLEMENTACIN
La implementacin transforma la descripcin del diseo en componentes de que juntos integran el
producto final de software. La labor de verificacin y validacin comprueba:
Conformidad del cdigo
Con las especificaciones del diseo
Con los estndares aplicables
La idoneidad del cdigo para obtener el producto con el nivel de integridad deseado.
V & V PRUEBAS
La verificacin y validacin de las pruebas garantiza que se han cumplido los requisitos del sistema
y del software, alcanzando los niveles de integridad requeridos.
En sistemas con niveles de integridad 3 y 4 es necesario que el equipo de verificacin y validacin
realice los planes y procesos de prueba, as como su ejecucin.
Para niveles 1 y 2 es suficiente con verificar las pruebas realizadas por el equipo de desarrollo.
V & V INSTALACIN
Se comprueba el rendimiento del sistema de software al ejecutarse en el entorno del cliente, as
como que los procedimientos de instalacin son correctos.
180
Verificacin y validacin
Verificacin y validacin en el ciclo de vida del software
V & V OPERACIN
Una vez instalado y puesto en servicio el sistema de software, la verificacin y validacin valora el
impacto que los cambios pueden suponer en el nivel de integridad del sistema, o los riesgos o daos
que pueden introducir.
Incluye la monitorizacin y evaluacin del entorno de operacin.
V & V MANTENIMIENTO
Una vez puesto en servicio el sistema de software, las modificaciones del entorno, o la presencia de
errores, o la necesidad de ampliar su funcionalidad requerirn emprender tareas de mantenimiento,
que en esencia, y a menor escala son pequeas acciones de desarrollo que pueden introducir
modificaciones en el nivel de integridad, y requerir revisiones en los anlisis de criticidad, daos y
riesgos, as como requerir posteriores acciones de verificacin y validacin sobre las modificaciones
de requisitos, diseo, desarrollo y pruebas.
E5
181
7.- Mantenimiento
E1
182
Mantenimiento
El mantenimiento consume ms
del 60% del coste de todo el
ciclo de vida
CONSUME MUCHOS RECURSOS
EL SISTEMA YA EST EN USO
Las actividades de mantenimiento resultan muy visibles para el
cliente.
Pueden afectar negativamente a la imagen de la organizacin.
Introduccin
La complejidad del mantenimiento de un sistema de software
ES UNA ACTIVIDAD CRTICA
GENERALMENTE INFRACONSIDERADA
183
Mantenimiento
Introduccin
Definicin
Modificacin de un producto de software, despus de su entrega para corregir errores,
mejorar el rendimiento u otros atributos o adaptar el producto a cambios del entorno.
IEEE Std. 1219-1998
Producto de software no comprende slo el cdigo. Incluye tambin la documentacin y los datos de
configuracin
PRODUCTO DE SOFTWARE
Cdigo
Datos de configuracin
y estructuras de datos
Requisitos, documentos
de anlisis, plan de V&V
Manuales y
documentacin de usuario
184
Mantenimiento
Tipos de mantenimiento
El mantenimiento del software se clasifica generalmente en tres categoras, en funcin de cul es la
causa que motiva el cambio:
Adaptativo Correctivo Perfectivo
ADAPTATIVO
Permite al software continuar en funcionamiento, adaptndose a cambios producidos en su entorno
de operacin.
Los cambios tpicos se suelen centrar en el hardware con el que interacta, en el sistema operativo,
o en formatos de datos que recibe o enva.
CORRECTIVO
Tiene como finalidad corregir fallos o problemas. Dentro del mantenimiento correctivo se suele
diferenciar entre de emergencia o de agenda; en funcin de la urgencia con la que deba
aplicarse la solucin.
En algunas ocasiones el cliente necesita urgentemente la reparacin del fallo, y en otras, puede
seguir operando con el error presente, y esperar a la prxima versin que normalmente incluye
cambios acumulados en la agenda de mantenimiento, tanto de tipo adaptattivo, como correctivo y
perfectivo.
185
Mantenimiento
Tipos de mantenimiento
PERFECTIVO
Se realiza para dar respuesta a nuevos requisitos del cliente, o para mejorar el rendimiento del
sistema.
PREVENTIVO
En su versin de 1993, el estndar IEEE 1229 inclua tambin en su clasificacin el mantenimiento
preventivo como aquel que se realiza para evitar la aparicin futura de errores, o para mejorar la
integridad de producto en prevencin de stos. Algunos textos lo consideran como un 4 tipo de
mantenimiento, y otros lo incluyen como mantenimiento correctivo.
Clasificacin Porcentajes habituales
Mantenimiento
Adaptativo
Correctivo
Perfectivo
De emergencia
De agenda
[Preventivo]
E2
186
Mantenimiento
Dificultad del mantenimiento
El mantenimiento es una de las fases ms difciles del ciclo de vida, y generalmente no est lo
suficientemente reconocida.
Las principales razones de esta situacin son:
En las organizaciones de software no aparece asociada a nuevas oportunidades de negocio,
que es sin duda un aspecto mucho ms atractivo para sus gestores.
Los trabajos de mantenimiento suelen tener asignados sus propios presupuestos pre-
establecidos, y se ven como un negocio normal, por lo que no suelen atraer la atencin de
la actividad del negocio.
El personal tcnico suele preferir trabajar en proyectos nuevos y no en mantener sistemas
ya desarrollados.
En muchos sentidos, el mantenimiento resulta ms difcil tanto desde el punto de vista tcnico como
de gestin del proyecto. Algunos de los factores que hacen del mantenimiento un proceso difcil
son:
Posibilidad de introduccin de errores en cascada o distorsionar funcionalidades ya
implementadas al insertar nuevas modificaciones.
El equipo de mantenimiento debe tener un conocimiento global del producto.
Las pruebas suelen resultar especialmente complicadas porque generalmente las
limitaciones de tiempo no hacen posible ejecutar pruebas completas de regresin.
Desde el punto de vista de gestin, las tres categoras de mantenimiento (correctivo,
perfectivo y adaptativo) suelen realizarse de manera simultnea, con gestin de prioridades
de cada peticin de cambio, y respetando la gestin de la configuracin del sistema.
187
Mantenimiento
Dificultad del mantenimiento
Cuanto mejor diseado, codificado y documentado est un sistema, ms fcil resulta su
mantenimiento.
Las propias tareas de mantenimiento tienden a degradar el diseo, la limpieza del cdigo y su
documentacin, generando de esta forma una espiral que se retroalimenta y que con el tiempo
incrementa la dificultad de mantenimiento de un sistema.
Los factores que favorecen esta situacin, y que por tanto es necesario gestionar adecuadamente
son:
Los mitos ya apuntados de no otorgar al mantenimiento la importancia y rigor necesarios.
Las presiones de tiempo y recursos con las que suelen ejecutarse.
La consideracin por parte del personal tcnico de tareas de segunda divisin
Dificultad por degradacin del sistema
reas de degradacin creciente
Diseo Cdigo Datos Documentacin
188
Mantenimiento
Dificultad del mantenimiento
Dificultad por degradacin del sistema
Factores agravantes
Escasa concienciacin
organizacional de la relevancia del
mantenimiento.
Peticiones de cambios con presin
de fechas y presupuestos.
Consideracin del personal tcnico
de que se trata de un trabajo de
segunda categora
DIFICULTAD
DEL MANTENIMIENTO
Degradacin del sistema
Diseo cada vez ms turbio
Cdigo parcheado cada vez ms
sucio
Estructurad de datos van
perdiendo su normalizacin e
integridad referencial
Actualizacin deficiente o nula de
la documentacin
SISTEMA MS DIFCIL
DE MANTENER
189
Mantenimiento
Gestin del mantenimiento
Las tareas de mantenimiento deben ejecutarse dentro de un marco de gestin, de igual forma que
si se trata el desarrollo de un sistema nuevo.
Tambin es frecuente que en este aspecto tambin el mantenimiento suele ser tratado como la
cenicienta en los proyectos de software, y generalmente resulta ms difcil la gestin de un
proyecto de mantenimiento que la de un desarrollo nuevo. De hecho puede ocurrir que dentro del
mantenimiento de un sistema se incluya tambin el desarrollo de un nuevo sub-sistema paraa
ampliar su funcionalidad.
Por tanto todas las tareas e indicaciones propias de la gestin de proyectos de software son
aplicables a los proyectos de mantenimiento: estimacin del esfuerzo necesario, identificacin de
procesos necesarios, planificacin de costes y agendas, gestin de riesgos, etc.
Las actividades de mantenimiento deben realizarse con tcnicas de gestin
de proyectos
190
Mantenimiento
Las 7 fases del mantenimiento
Para identificar y comprender las actividades que deben tenerse en cuenta en el mantenimiento, los
pasos que deben seguirse y las herramientas y mtodos que deben emplearse, resulta muy til
considerar que los procesos de cambio o modificaciones de un sistema de software comprenden 7
fases:
Identificacin clasificacin y priorizacin del problema o de la modificacin.
Anlisis.
Diseo.
Implementacin.
Pruebas de sistema y de regresin.
Pruebas de aceptacin.
Entrega.
Al realizar tareas de mantenimiento, en cada una de estas fases deben considerarse los siguientes
elementos:
EN CADA FASE
Entradas Procesos Control Salidas Mtricas
191
Mantenimiento
Las 7 fases del mantenimiento
Cada peticin de cambio debe identificarse, clasificarse y asignarle una prioridad, teniendo en
cuenta qu tipo de mantenimiento implica (correctivo, adaptativo, perfectivo y si es de emergencia)
Entradas Procesos Control Salidas Mtricas
1.- Identificacin del problema, clasificacin y priorizacin
Peticin de cambio Asignar n de
identificacin
Clasificar por tipo
de mantenimiento
Analizar y deter-
minar se se acepta
rechaza o pospone
Primera estimacin
de su magnitud
Priorizar la
modificacin
Asignar la peticin
a qu bloque de
modificaciones
prevista va a ir
Una vez identificada
la peticin de
cambio, debe
quedar registrada
en un registro de
peticiones de
cambio
Peticin de cambio
validada que queda
en un registro con la
siguiente
informacin:
Definicin del
problema o del
nuevo requisito
Evaluacin
Tipo de mantenim.
Prioridad inicial
Estimacin inicial
de recursos
necesarios
N de omisiones
en la P.C.
N de P.C.
enviadas
N de peticiones
de cambio
duplicadas
Tiempo invertido
en la validacin.
Factores medidos:
correccin y
mantenibilidad
192
Mantenimiento
Las 7 fases del mantenimiento
La fase de anlisis emplea la relacin de peticiones de cambio registradas y validadas para analizar
su viabilidad, alcance de las modificaciones y preparar un plan preliminar de diseo implementacin
y entrega
Entradas Procesos Control Salidas Mtricas
2.- Anlisis
Peticin de cambio
validada
Estimacin inicial
de recursos y
dems informacin
registrada.
Documentacin del
proyecto (si la
hay).
Anlisis de
viabilidad
(impacto,
soluciones
alternativas,
implicaciones de
seguridad, coste y
beneficio de la
modificacin)
Anlisis detallado
(SRS de la
modificacin,
elementos a
modificar,
estrategia de
pruebas)
Realizar revisiones
tcnicas y revisar
Estrategia de
pruebas.
Que la documen-
tacin est
completa y
actualizada e
incluye parmetros
de seguridad
Informe de
viabilidad de las
P.C.
Informe del anli-
sis detallado.
Requisitos
actualizados (y
trazables)
Lista preliminar
de mofificaciones.
Plan de pruebas
Plan de
implementacin
Modificaciones de
requisitos
% de errores en
la documentacin
Esfuerzo por rea
(SQA, SE, etc.)
Tiempo empleado
% de errores
generados por
prioridad y tipo.
Factores: flexibilidad
trazabilidad
usabilidad
mantenibilidad
reusabilidad
193
Mantenimiento
Las 7 fases del mantenimiento
En esta fase se emplea toda la documentacin del sistema, del proyecto y la generada en la fase
anterior (anlisis) para disear la modificacin del sistema.
Entradas Procesos Control Salidas Mtricas
3.- Diseo
Salidas de la fase
de anlisis.
Documentacin del
sistema y del
proyecto
Cdigo,
comentarios y
bases de datos del
sistema.
Identificacin de
los mdulos
afectados.
Documentacin de
las modificaciones
Creacin de casos
de prueba para las
modificaciones
Identificacin y
creacin de
pruebas de
regresin
Actualizacin de
documentacin
(SRS manuales)
Inspeccin /
verificacin del
diseo
Inspeccin /
verificacin de la
documentacin
asociada
Revisados:
Lista de
modificacines
Anlisis detallado
Plan de
implementacin
actualizado
Lnea base de
diseo
Planes de
pruebas
Complejidad del
software
Cambios diseo
Esfuerzo por rea
Cambios en
planes de prueba
Nmero de
mdulos
N lneas de
cdigo aadidas o
modificadas
194
Mantenimiento
Las 7 fases del mantenimiento
A partir del diseo realizado y verificado, el cdigo y la documentacin del sistema y del proyecto se
lleva a cabo el trabajo de implementacin.
Entradas Procesos Control Salidas Mtricas
4.- Implementacin
Resultados de la
fase de diseo.
Cdigo fuente y
bases de datos del
sistema.
Documentacin del
sistema y del
proyecto.
Codificacin y
pruebas unitarias
Integracin
Anlisis de riesgos
Revisin de
pruebas
Revisiones de
cdigo
Verificacin de la
integracin.
Verificacin de
modificaciones y
actualizaciones
de
documentacin.
Gestin de
riesgos y
supervisin
durante las
pruebas
Revisados:
Software
actualizado.
Documentacin
de diseo,
pruebas,
manuales
documentacin
de formacin
actualizados.
Definicin de
riesgos e
impactos.
Informe de
revisin de las
pruebas
Volumen (puntos
de funcin /
lneas de cdigo)
Porcentaje de
errores
generados.
195
Mantenimiento
Las 7 fases del mantenimiento
Tras la implementacin deben realizarse las pruebas del sistema modificado. Las pruebas de
regresin son parte de las pruebas del sistema que comprueban que el cdigo modificado no ha
introducido errores nuevos.
Entradas Procesos Control Salidas Mtricas
5.- Pruebas de sistema y de regresin
Informe de las
pruebas.
Documentacin de
los planes de
prueba, casos de
prueba,
procedimientos de
prueba, manuales
de usuario, diseo.
Sistema
actualizado
Prueba funcional
del sistema.
Pruebas de
interfaz.
Pruebas de
regresin.
Las pruebas del
sistema se han
realizado segn
los planes SQA.
Control de la
gestin de la
configuracin de:
cdigo, peticiones
de cambio,
documentacin
de pruebas
Revisados:
Sistema revisado.
Informes de
pruebas.
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
196
Mantenimiento
Las 7 fases del mantenimiento
Sobre el sistema completamente integrado, el cliente, los usuarios o un tercero nombrado por el
cliente lleva a cabo las pruebas de aceptacin
Entradas Procesos Control Salidas Mtricas
6.- Pruebas de aceptacin
Informes de
pruebas.
Sistema
completamente
integrado.
Planes de pruebas
de aceptacin.
Casos de prueba
de aceptacin.
Procedimientos de
aceptacin
Ejecucin de las
pruebas de
aceptacin a nivel
funcional.
Ejecucin de
pruebas de
interoperabilidad.
Ejecucin de
pruebas de
regresin.
Ejecucin de
planes de
aceptacin.
Auditora
funcional.
Puesta bajo
control de
configuracin de
la nueva
documentcin.
Establecimiento
de la nueva lnea
base del sistema.
Informe de los
resultados de
auditora
funcional.
Nueva lnea base
del sistema.
Informe de
auditora
funcional.
Informe de
pruebas de
aceptacin.
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
197
Mantenimiento
Las 7 fases del mantenimiento
Entrega del sistema modificado.
Entradas Procesos Control Salidas Mtricas
7.- Entrega
El sistema
modificado segn
se represente en la
nueva lnea base.
Auditora fsica de
la configuracin.
Notificacin a la
comunidad de
usuarios.
Desarrollo y
archivo de una
copia de seguridad
del nuevo sistema.
Instalacin y
formacin de
usuarios.
Ejecucin de la
auditora fsica de
la configuracin.
Documento de
descripcin de la
versin.
Informe de la
auditora fsica.
Documento de
descripcin de la
versin.
Cambios en la
documentacin
(manuales de
usuario, de
operacin,
documento
descripcin de
versin, etc.)
E3
198
Mantenimiento
Mantenibilidad
Con este trmino, que aunque inexistente en el lxico espaol se ha hecho hueco en nuestra jerga,
se define una propiedad del software que se puede definir como:
Los factores que conforman la mantenibilidad de un sistema de software son:
Mayor o menor profesionalidad en las fases de diseo, codificacin y prueba.
Adecuada cualificacin del equipo desarrollador del software.
Facilidad de comprensin de la estructura del software.
Facilidad de uso del sistema.
Uso de lenguajes de programacin y sistemas operativos estandarizados.
Grado de normalizacin de la documentacin.
Disponibilidad de la documentacin de los casos de prueba.
Facilidades de depuracin con las que cuenta el sistema.
Disponibilidad de medios e infraestructura para realizar el mantenimiento.
Madurez en la planificacin del mantenimiento.
la medida cualitativa de la facilidad para comprender, corregir y adaptar o
mejorar el software.
199
Mantenimiento
Mantenibilidad
Vista la definicin de mantenibilidad, y los factores que la forman
Cmo se mide la mantenibilidad?. Es posible afirmar que este sistema tiene una mantenibilidad
de 6, o alta, o peor que la de aquel otro sistema?.
No es un atributo ni fsico ni simple. No puede medirse directamente.
Las mediciones siempre tendrn carcter de aproximacin, y se pueden realizar indirectamente
midiendo aspectos relacionados:
Tiempos invertidos en las tareas de mantenimiento
Para indentificar el problema, para analizarlo, para modificar x lneas de cdigo, etc.
Midiendo la complejidad del sistema de software.
En esta lnea las propuestas de medicin apuntan a la medicin de la complejidad
ciclotmica, la legibilidad, etc.
Esta lnea presenta el problema de utilizar atributos indirectos que tambin son de difcil
medicin.
Medicin
La mantenibilidad es un atributo de calidad del software.
200
Mantenimiento
Mantenibilidad
Cmo abordar el mantenimiento de un sistema de software con problemas de
mantenibilidad?
No se dispone de documentacin (diseo, requisitos)
Con deficiente gestin de la configuracin.
Que ha sufrido mltiples y cambios que han degradado el sistema, o desfasado la
documentacin.
Reingeniera
Analizar el sistema y decidir si conviene rehacerlo de nuevo, o por el contrario resulta
ms apropiado aplicar tcnicas de reingeniera.
201
Mantenimiento
Mantenibilidad
El modelo comprende 6 actividades. La primera es un anlisis de inventario del que se decidir si de
aplica reingeniera, y en caso afirmativo se emplearn alguna o todas de las cinco actividades
restantes.
Modelo de reingeniera del software
Anlisis de
inventario
Qu
hacer?
Reestructuracin
de documentos
Ingeniera
progresiva
Ingeniera
inversa
Reestructuracin
de cdigo
Reestructuracin
de datos
Reconstruccin
Ingeniera inversa
202
Mantenimiento
Mantenibilidad
El inventario del sistema comprende la informacin necesaria para el anlisis que servir para
decidir si resulta ms conveniente rehacer de nuevo el sistema, o aplicar tcnicas de reingeniera:
Identificacin del sistema de software
Ao de creacin
Nmero de cambios importantes realizados
Esfuerzo invertido en esos cambios
Fecha y esfuerzo del ltimo cambio importante
Sistema o sistemas en los que se integra el software
Sistemas con los que se relaciona
Bases de datos a las que accede
Errores detectados en los ltimos x meses (12)
Nmero de usuarios
Complejidad de la arquitectura, cdigo y documentacin
Calidad de la documentacin
Mantenibilidad general
Longevidad acumulada y previsible del proyecto
Nmero de cambios previstos en los prximos x meses
Coste anual del mantenimiento
Valor actual del negocio que gestiona
Importancia estratgica para el negocio del cliente y del desarrollador
Modelo de reingeniera del software
Anlisis de inventario
203
Mantenimiento
Mantenibilidad
Los sistemas en los que se cuestiona aplicar reingeniera suelen tener deficiencias en su
documentacin.
En funcin de las caractersticas del proyecto, tras el anlisis del inventario las opciones son:
Dejarlo como est
Razones:
Se trata de un sistema con escasa previsin de cambios futuros.
Se trata de un sistema que se encuentra cercano al fin de su ciclo de vida.
Los recursos necesarios para crear la documentacin no compensan con el beneficio
obtenido.
Documentar slo las partes que se modifican
Razones:
Se dispone de recursos limitados.
Tras el anlisis de inventario resulta necesario actualizar la documentacin.
Reducir la documentacin al mnimo imprescindible
Razones:
Se trata de un sistema crtico para el negocio.
Es preciso volver a documentarlo
Modelo de reingeniera del software
Reestructuracin de documentos
204
Mantenimiento
La ingeniera inversa realiza un anlisis de un sistema de software para conseguir especificar su
documentacin; generalmente su diseo.
Obviamente se aplica cuando no se dispone del diseo, o ste est obsoleto.
Un proceso de ingeniera inversa debe ser capaz de:
Derivar las representaciones de diseo de procedimientos.
Extraer la estructura de datos.
Representar el modelo de los flujos de datos y de control.
Representar el modelo de entidades y relaciones.
Modelo de reingeniera del software
Ingeniera inversa
205
Mantenimiento
Mantenibilidad
Los sistemas que tras un anlisis de inventario quedan como candidatos a una reestructuracin de
cdigo suelen presentar una arquitectura de programa relativamente slida, pero presentan
mdulos individuales que por haber sufrido modificaciones poco ortodoxas, o por las razones que
sean presentan un cdigo sucio de difcil comprensin, comprobacin y mantenibilidad.
Modelo de reingeniera del software
Reestructuracin de cdigo
Las deficiencias en las estructuras de datos son una de las principales causas de errores.
Es necesario realizar reestructuracin (rediseo y posterior migracin de la informacin al nuevo
diseo) en las bases de datos que por no tener un diseo normalizado, o sin integridad relacional
presentan un riesgo de error cuyo impacto aconseje su reestructuracin.
La reestructuracin de datos suele implicar tambin modificaciones de cdigo.
Reestructuracin de datos
Ensame tu cdigo y mantn ocultas tus estructuras de datos, y me seguirs engaando.
Mustrame tus estructuras de datos y normalmente no necesitar que me ensees tu cdigo:
resultar evidente
Fred Brooks
206
Mantenimiento
Mantenibilidad
Por el estado actual de las herramientas CASE se trata de un modelo ideal de proceso, ms que de
un proceso que se pueda aplicar directamente.
Su objetivo es ejecutar ingeniera inversa y reestructuracin de cdigo de forma automtica a
travs de herramientas CASE que analicen el cdigo y generen su diseo, as como su
reestructuracin.
Modelo de reingeniera del software
Ingeniera progresiva
E4
207
8.- Gestin de la configuracin
208
Gestin de la configuracin
El problema
Entorno de desarrollo de un sistema de software de tamao medio:
Equipo de 10 programadores.
75 mdulos de programa.
Media de dos versiones de cada mdulo.
Documentacin del proyecto: descripcin del sistema, SRS, plan
de proyecto, anlisis, etc.
Cada programador modifica un mdulo cada da.
Modificaciones de requisitos
Varios programadores deben trabajar de forma concurrente
sobre el mismo mdulo.
Etc.
Consecuencias
La versin del programa no coincide con la documentacin.
Estamos en la versin 2.3, y debemos revisar un error que se ha
producido en una instalacin de la versin 1.7. Dnde est el cdigo de
esa versin?
Ese error ya se corrigi hace un mes.. Porqu ha vuelto a aparecer?
Quin aprob esa modificacin de requisitos, y porqu no est en la
versin actual de SRS?
Se est dando mantenimiento a usuarios con diferentes versiones del
sistema Qu versin del componente de acceso a datos se integr en
la versin 2.0 del sistema?.
Etc.
Introduccin
209
Gestin de la configuracin
Gestin de la configuracin del software es una disciplina formal de la ingeniera del software
que proporciona mtodos y herramientas para identificar y controlar el software durante su
desarrollo y posterior uso.
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
Comprende las siguientes actividades:
[1]
Identificacin y establecimiento de las lneas base.
Revisin, aprobacin o rechazo, control y seguimiento de los cambios.
Auditoras y revisiones de la evolucin de los productos de software.
Control de la relacin del sistema de software en su interfaz de operacin.
mbito de la gestin de la configuracin
Entorno
De aplicacin
Temporal
Sistema
Los componentes del sistema y su
relacin con el entorno
Desde el inicio del proyecto hasta
que se deja de usar y se retira.
Desarrollo Mantenimiento
Ciclo de vida
Definicin
210
Lnea base
Peticin de
cambio
Librera
Comit de
control de la
configuracin
Elementos de
configuracin
del software
Gestin de la configuracin
Conceptos clave
211
Gestin de la configuracin
Lnea base
Especificacin de un producto que ha sido formalmente revisada y aceptada para servir como
punto de referencia para su posterior desarrollo, y slo puede modificarse a travs de un
procedimiento formal de control de cambio.
El nmero y tipo de lneas base de un proyecto puede ser diferente en funcin de las
caractersticas y modelo de ciclo de vida del mismo, pero las habituales son:
Lnea base funcional
Describe las funcionalidades que realizar el sistema, y se establece despus de la
revisin de la descripcin del sistema y del diseo del sistema.
Lnea base de requisitos (tambin lnea base asignada)
Documenta las funciones que desarrollar el software y se establece despus de la
revisin de la especificacin de requisitos del software (SRS). Tambin se denomina
Lnea base asignada, porque en ella se asignan al software los requisitos de la
descripcin del sistema.
Lnea base de desarrollo
Esta lnea base crece y evoluciona durante el desarrollo del sistema y recoge la
configuracin en cada fase del diseo, codificacin y pruebas. Los elementos contenidos
en esta lnea base van incrementando y son normalmente revisados por el equipo del
desarrollo.
Lnea base de producto
Contiene el producto completo en su versin final. Se establece tras comprobar con la
validacin y verificacin del producto que ste es conforme a las especificaciones de los
requisitos.
Conceptos clave
212
Gestin de la configuracin
Elemento de configuracin del software
Un elemento de configuracin del software (SWCI) es un conjunto de
productos de trabajo documentados que se han producido en los
procesos del ciclo de vida, o que se emplean en los mismos.
Por producto de trabajo se entiende a un elemento tangible que es el
resultado de determinadas actividades o tareas de desarrollo: planes de
pruebas, documentos de requisitos, documentos de diseo, cdigo, manuales
de usuario, etc.
Conceptos clave
Los elementos de configuracin del software son cualquier parte del desarrollo o del producto
entregable y necesitan poder identificarse, almacenarse, cambiarse, revisarse o mantenerse de
forma independiente.
Estos elementos no comprende slo los productos de software que se entregan al cliente, tambin
incluyen los elementos que son necesarios para crear esos productos.
C
a
t
e
g
o
r
a
s
Producto: Productos intermedios o finales desarrollados durante el proyecto.
Software adquirido: Mdulos o componentes adquiridos o subcontratados.
Software suministrado: Software proporcionado por el cliente para que se integre en el sistema.
Software de pruebas: Software empleado para realizar las pruebas.
Software de apoyo: Software empleado para desarrollar el sistema de software (compiladores, etc.)
E1
213
Gestin de la configuracin
Peticin de cambio
Las peticiones de cambio documentan la necesidad de modificar un elemento de
configuracin del software.
Las peticiones de cambio deben incluir:
Razn por la que hay que realizar el cambio (deteccin de un fallo,
modificacin de requisitos, etc.)
Elemento de configuracin afectado y lnea base a la que pertenece.
Urgencia del cambio.
Persona que lo solicita e indicacin de si el origen es interno o externo.
Conceptos clave
214
Gestin de la configuracin
Comit de control de la configuracin
Para conseguir que las peticiones de cambio se procesen de forma ordenada,
correcta y a tiempo, el proyecto debe establecer quin o quienes configuran el
comit de control de la configuracin.
En funcin del tamao y caractersticas del proyecto puede ser que lo forme una
sola persona (p. ej. el analista o el gestor del proyecto), o que est formado por
varias: gestor de proyecto, cliente, gestor de calidad, etc.
Conceptos clave
Las funciones del comit incluyen:
Sopesar las ventajas e inconveniente de la introduccin del cambio (beneficios esperados,
coste de la implementacin)
Evaluar el impacto de la modificacin sobre los parmetros del proyecto (agenda, costes,
riesgos, etc.).
El comit no slo decide si debe realizarse el cambio, tambin determina su prioridad, cundo y
cmo debe llevarse a cabo y cmo deber comprobarse y verificarse su implementacin.
215
Gestin de la configuracin
Libreras
Las libreras constituyen los dispositivos de almacenamiento necesarios para
llevar a cabo los cambios y el control histrico de los mismos que requiere la
gestin de la configuracin, de forma que queden guardadas y puedan
recuperarse las diferentes lneas base en cualquiera de sus versiones.
El nmero y tipo de libreras puede variar en funcin de las caractersticas del
proyecto, pero generalmente son 3:
Conceptos clave
Librera dinmica
Es el entorno de almacenamiento usado y gestionado por el equipo de programacin en el que se
ubican los elementos con los que estn trabajando.
Librera controlada
Es la librera empleada para guardar las lneas base y controlar los cambios que sobre ellas se
realizan. Los elementos se almacenan en esta librera despus de haber sido identificados como
elementos de configuracin asignados a su lnea base, documentados y aceptados por el comit
de gestin de la configuracin.
Librera esttica
Tambin llamada repositorio de software. Guarda las lneas base una vez que han sido validadas y
verificadas para su distribucin y uso final.
216
Gestin de la configuracin
Libreras
Conceptos clave
LIBRERA DINMICA
LIBRERA CONTROLADA
LIBRERA ESTTICA
Versin 1.0 Versin 1.1
Tambin llamada Directorio de programacin.
Controlada por el equipo de programacin.
Tambin llamado Directorio maestro.
Contiene todas las lneas base del proyecto.
Tambin llamado Repositorio de software
Comprende las lneas base que finalmente se entregan.
217
Gestin de la configuracin
Funciones clave de la gestin de la configuracin
Gestin de la configuracin
del software
Identificacin de
la configuracin
Control de la
configuracin
Medicin del
estado de la
configuracin
Auditoras y
revisiones
Control de las
relaciones de
interfaz
218
Gestin de la configuracin
Identificacin de la configuracin
Funciones clave de la gestin de la configuracin
Determinacin de los elementos de configuracin del software y de las lneas
base a las que pertenecen.
A
c
t
i
v
i
d
a
d
e
s
Seleccin de los elementos de configuracin y agrupacin en lneas base.
Deben considerarse productos que puedan disearse, desarrollarse, probarse y
modificarse de forma independiente.
No deben identificarse muy pocos, ni tampoco demasiados. Los criterios de
seleccin deben ser acordes con las caractersticas del proyecto.
Nomenclatura: Cada elemento de configuracin debe nombrarse con un identificador nico. Es
habitual que el identificador contenga:
NOMBRE: descriptivo del elemento.
IDENTIFICADOR DE CONFIGURACION: Usado en la gestin interna de la librera.
IDENTIFICADOR DE VERSION: Usado para identificar las diferentes versiones.
Adquisicin: Una vez identificado cada elemento, debe incorporarse a su respectiva librera.
I
d
e
n
t
i
f
i
c
a
c
i
n
N
o
m
e
n
c
l
a
t
u
r
a
y
a
d
q
u
i
s
i
c
i
n
Documentos
Cdigo
Datos
Seleccin
Revisin
tcnica y
formal
Lneas base
219
Gestin de la configuracin
Control de la configuracin
Funciones clave de la gestin de la configuracin
Comprende la gestin de las revisiones y de los procesos de aprobacin, para
evitar que se produzcan cambios de forma descontrolada.
Que para cada cambio se evala y considera el impacto en el proyecto.
Que slo se implementan los cambios aprobados.
Que todos los cambios aprobados se implementan.
Que las lneas base se mantienen controladas y actualizadas.
Garantiza
Identificacin
del cambio
Comunicacin
formal
Validacin
y evaluacin
CLASIFICACIN
Por urgencia
Por Naturaleza (error, mejora, mod. Requisitos)
Por categora de elementos modificados (producto,
Software adquirido, Software suministrado, software
de pruebas o software de apoyo).
EVALUACIN
Tcnico
En los interfaces de configuracin
En la agenda
En el presupuesto
Aprobacin
o rechazo
Implementacin
Check-out lnea base
Ejecucin de cambios
Pruebas y verificacin
Aprobacin de la ejecucin
Chech-in lnea base
220
Gestin de la configuracin
Medicin del estado de la configuracin
Funciones clave de la gestin de la configuracin
Medicin y registro de los cambios, contenidos e histricos de la gestin de la
configuracin
Versin inicial aprobada de los elementos de la configuracin.
Estado de las peticiones de cambio.
Estado de implantacin de los cambios aprobados.
Registra
Esta es la informacin mnima que debera registrarse (Std. IEEE 828-1998).
Auditoras y revisiones
Con menor o mayor rigor, segn se trate de revisiones o auditoras, estos
procesos tambin se deben aplicar sobre la gestin de la configuracin para
garantizar:
Que los elementos de la configuracin se encuentran en el estado que
deberan estar.
Que las actividades, las tareas y los resultados de la gestin de la
configuracin son correctos.
221
Gestin de la configuracin
Control de las relaciones de interfaz
Funciones clave de la gestin de la configuracin
El desarrollo y mantenimiento de sistemas de software no suele ser auto-
contenido. Normalmente el software debe relacionarse con hardware y con otro
software. El control de las relaciones de Interfaz contempla y gestiona las
situaciones posibles:
Evolucin paralela del hardware
del sistema global
El software debe ejecutarse
sobre plataformas operativas
comerciales
El producto de software debe
integrar componentes externos
El desarrollo de partes del
software se subcontrata a un
proveedor externo.
La gestin de la configuracin del sistema global debe
relacionarse con la del proyecto de software por las
implicaciones de cambios que pueden derivarse en sta
de aquella.
La gestin de la configuracin
debe registrar tambin las
plataformas y componentes
externos, evaluando las posibles
evoluciones y cambios.
Las gestiones de configuracin del proyecto de
software y del subcontratado deben comunicarse y
gestionar las implicaciones de cambio derivadas de uno
a otro.
SITUACIONES IMPLICCIONES DE INTERFAZ
222
Juan Palacio
jpalacio@navegapolis.net
http://www.navegapolis.net
Obra y derechos registrados en safecreative.net. Cdigo de obra: 0710040047711
Puede consultar la forma en la que puede emplear y distribuir este trabajo en:
hthttp://www.safecreative.org/work/0710040047711