Escolar Documentos
Profissional Documentos
Cultura Documentos
Tabla
Tabla de
de contenido
contenido
Prlogo
Derechos
1.- Introduccin a la ingeniera del software
2.- Ciclo de vida
3.- Requisitos
4.- Anlisis y diseo
5.- Documentacin de usuario
6.- Verificacin y validacin
7.- Mantenimiento
8.- Gestin de la configuracin
Prlogo
Derechos
9.- Ingeniera de procesos del software
10.- Agilidad y procesos.
11.- Modelos formales: CMMI
12.- Modelos formales: ISO / IEC 15504
13.- Modelos giles
14.- Gestin de proyectos
14.1.- Gestin formal de proyectos
14.2.- Gestin gil de proyectos: Scrum
15.- Gestin de organizaciones de Software
Prlogo
Prlogo
CIS ofrece una visin prctica y sinptica de la Ingeniera del Software.
El formato de exposicin que emplea resulta adecuado para foros que requieren una exposicin
didctica de la Ingeniera del Software, o de alguna de sus reas (requisitos, CMMI, etc.) de carcter
ejecutivo o general, sin entrar en la densidad del libro especializado:
Etc.
Este no es un trabajo completo, y por su carcter general no pretende cubrir todos los modelos,
tcnicas o lneas de trabajo de la Ingeniera del Software, sino las ms relevante y las que mayor
repercusin o uso tienen en la industria del desarrollo y mantenimiento de software.
Si resulta posible, en futuras revisiones se incluirn temas que por razones de tiempo y prioridad
an se han quedado fuera (DSDM, mtricas, estimaciones, etc.). Tambin en ellas se revisarn los
contenidos actuales.
Transistores
10.000.000
Pentium II
Pentium
486 DX
1.000.000
386
286
100.000
8086
10.000
4004
8080
8008
1970
1975
1980
1985
1990
1995
2000
Incremento de la miniaturizacin.
Reduccin de costes en la produccin.
19%
53%
23%
28%
46%
40%
31%
xito
29%
49%
28%
1995
1994
Problemtico
26%
33%
27%
53%
16%
En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea
de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi
su famosa carta GoTo Statement Considered Harmful en 1968.
La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada
por Larry Constantine, Glenford Myers y Wayne Stevens.
El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb.
C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la
eliminacin de GoTo y la creacin de la programacin estructurada.
Otras definiciones
Disciplina para producir software de calidad desarrollado sobre las agendas y
costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
10
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
11
12
ISO
Organizacin Internacional para la Estandarizacin. Fundada en 1947
Son miembros 87 pases.
En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin
Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las
Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de
campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y
equipos.
Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
SEI
ISO/IEC 12207
ISO/IEC TR 15504
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
CMM / CMMI
ISO/IEC TR 15504
15
1 Software, Engineering Coordinating Comitee, Comisin creada por IEEE Computer Society y ACM (Association for Computer Machinery) para
definir el cuerpo de la Ingeniera del Software
16
Requisitos
Diseo
Construccin
Pruebas
Mantenimiento
Gestin de la configuracin
Gestin
Procesos
Herramientas y mtodos
Calidad
Es importante resaltar que estas reas no incluyen aspectos importantes de las tecnologas de la
informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes
o tecnologa de redes y comunicaciones.
Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un
enfoque de ingeniera.
Por supuesto que un Ingeniero de Software debe conocer las tcnicas de cada momento, pero la
definicin de procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el
rea de conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los
problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos
son indistintos del hardware o lenguaje de programacin empleado. Eran los mismos hace dos
dcadas que ahora, y todo nos hace suponer que seguirn siendo idnticos dentro de otros cuatro
lustros.
17
18
5.1
5.1 Adquisicin
Adquisicin
6.1
6.1 Documentacin
Documentacin
5.2
5.2 Suministro
Suministro
6.2
6.2 Gestin
Gestin de
de la
la configuracin
configuracin
6.3
6.3 Control
Control de
de calidad
calidad
5.3
5.3
Operacin
Operacin
6.4
6.4 Verificacin
Verificacin
6.5
6.5 Validacin
Validacin
5.3
5.3
Desarrollo
Desarrollo
6.6
6.6 Reuniones
Reuniones
5.3
5.3
Mantenimiento
Mantenimiento
6.7
6.7 Auditora
Auditora
6.8
6.8 Resolucin
Resolucin de
de problemas
problemas
7. Procesos organizacionales
7.1
7.1 Gestin
Gestin
7.2
7.2 Infraestructura
Infraestructura
7.3
7.3 Mejora
Mejora
7.4
7.4 Formacin
Formacin
20
ISO 1227 define los procesos que componen el ciclo de vida del software
Actividad 1
Tarea 1
Tarea 2
Proceso
Tarea n
Ciclo de vida
Concepto
Retirada
Proceso
N
Actividad n
Tarea 1
Tarea 2
Tarea n
21
TAREA X
ACTIVIDAD n
TAREA 1
INICIO
PLAN
Tareas, agenda,
asignaciones
ACT
Problemas y acciones
correctivas
PROCESO
DO
Ejecicin de planes
y tareas
CHECK
Evaluacin y
medicin
FIN
22
ISO 12207 establece un nexo con la Ingeniera de sistemas al considerar al software como
parte de un sistema.
Desde esta perspectiva se establece a la Ingeniera de sistemas como fundamento de la
Ingeniera del Software.
Qu es un sistema?
Coleccin de componentes organizados para cumplir una funcin o conjunto de funciones
especficas.
IEEE Standard 610.12-1990
Sistema de
Entrada
Elemento
Elemento del
del
sistema
sistema
Elemento
Elemento del
del
sistema
sistema
Sistema
Elemento
Elemento del
del
sistema
sistema
Elemento
Elemento del
del
sistema
sistema
Sistema de
Salida
Sistema de software
Sistema o sub-sistema formado por una coleccin de programas y documentacin que de forma
conjunta satisfacen unos determinados requisitos.
Un sistema de software puede ser en s mismo un sistema independiente que, por ejemplo, realiza
su objetivo en un ordenador independiente. A este tipo de sistemas se les denomina tambin
sistema intensivo de software, porque el sistema es prcticamente software.
Un sistema de software puede ser tambin una parte de un sistema mayor. En cuyo caso se trata en
realidad de un sub-sistema de software.
Por ejemplo, el sistema de software de un avin de combate es en realidad el sub-sistema de
software del avin.
Ingeniera de sistemas
El trmino Ingeniera de sistemas surgi por primera vez en 1956, y fue propuesto por H. Hitch,
presidente del departamento de Ingeniera Aeronatica de la Universidad de Pensilvania, para
intentar desarrollar una disciplina de ingeniera que pudiera abarcar el desarrollo de grandes
sistemas que empleaban diversas disciplinas de ingenieras especficas: construccin de
bombarderos, submarinos, etc.
Los principios de Ingeniera de sistemas desarrollados en los 60 y 70 se aplicaron en programas
como el Apolo, o el programa de misiles balsticos USAF/USN.
24
Los procesos de ingeniera de sistemas integran las secuencias de actividades y decisiones que
transforman la definicin de una necesidad en un sistema, que con un ciclo de vida optimizado,
consigue un balance ptimo de todos sus componentes.
USAF, 1985
La principal funcin de la ingeniera de sistemas es garantizar que el sistema satisface los requisitos
durante todo el ciclo de vida. Todas las dems consideraciones se alinean sobre esta funcin.
Wymore 1993
La ingeniera de sistemas define el plan para gestionar las actividades tcnicas del
proyecto. Identifica el ciclo de desarrollo y los procesos que ser necesario aplicar. Desde
la Ingeniera de sistemas se desarrolla la lnea base tcnica para todo el desarrollo, tanto
de hardware como de software.
25
Anlisis de la solucin: Determinar las opciones posibles para satisfacer los requisitos y las
restricciones. Estudiar y analizar las posibles soluciones. Seleccionar la mejor, sopesando las
necesidades inmediatas, opciones de implementacin, utilidad, evolucin del sistema
Planificacin de los procesos: Determinar los grupos de tareas tcnicas que se deben realizar,
el esfuerzo requerido para cada una, su prioridad y los riesgos que implican para el proyecto.
Control de los procesos: Determinar los mtodos para controlar las actividades tcnicas del
proyecto y los procesos; la medicin del progreso, revisin de los productos intermedios y
ejecucin de las acciones correctivas, cuando corresponda.
26
Ingeniera de sistemas
Planificacin
Organizacin
Personal
Direccin
Control
27
Anlisis
Anlisis del
del
sistema
sistema
Pruebas
Pruebas del
del
sistema
sistema
Diseo
Diseo del
sistema
sistema
Ingeniera de sistemas
Anlisis
Anlisis de
de
requisitos
requisitos del sw
Diseo
Diseo de la arquitectura
quitectura del sw
Ingeniera del software
Pruebas
Pruebas de
de
integracin
integracin del sis
Pruebas
Pruebas del
sistema
sistema de
de sw
sw
Pruebas
Pruebas de
de
integracin
integracin del
del sw
sw
Diseo
Diseo detallado
del
del software
software
Codificacin
Codificacin
Pruebas
Pruebas unitarias
unitarias
28
29
Ciclo
Ciclo de
de vida
vida del
del software
software
El marco del ciclo de vida del software cubre desde la conceptuacin de las ideas iniciales del
producto hasta el fin de su uso (retirada).
ISO/IEC 12207 1995
Desde el punto de vista del estndar (v. Introduccin a la Ingeniera del Software) un proceso es un
conjunto de actividades y tareas relacionadas, que al ejecutarse de forma conjunta transforman una
entrada en una salida.
30
31
33
E1
E1
34
ADQUISICIN
emplea
PROCESO DE ADQUISICIN
PROCESO DE ADQUISICIN
Adquiriente
Adquiriente
contrato
ROL
SUMINISTRO
emplea
ROL
OPERACIN
emplea
PROCESO DE SUMINISTRO
PROCESO DE SUMINISTRO
Suministrador
Suministrador
Operador
Operador
Usuario
Usuario
emplea
emplea
emplea
PROCESO DE OPERACIN
PROCESO DE OPERACIN
usa
ROL
INGENIERA
ROL
SOPORTE
ROL
ORGANIZACIONAL
Desarrollador
Desarrollador
Mantenedor
Mantenedor
Usuario
Usuario del
proceso
proceso de
de
soporte
soporte
Gestor
Gestor
PROCESO DE
usa
PROCESO DE
MANTENIMIENTO
MANTENIMIENTO
Documentacin
Gestin de la configuracin
Aseguramiento calidad
Verificacin
Gestin
Infraestructura
PROCESO DE
PROCESO DE
DESARROLLO
DESARROLLO
emplea
PROCESOS DE SOPORTE
ROL
Validacin
Reuniones de seguimiento
Auditora
Resolucin de problemas
Mejora
Formacin
35
Ciclo de vida del software: El periodo de tiempo comprendido desde la definicin de los
requisitos hasta el fin del su uso.
Procesos: Actividades y tareas implicadas en el desarrollo operacin y mantenimiento de un
sistema de software.
36
MODIFICADORES
Modelos
Modelos de
de ciclos
ciclos de
de vida
vida
MODELOS
CICLOS DESARROLLO
SECUENCIAL
SECUENCIAL
CASCADA
CASCADA
ESPIRAL
ESPIRAL
PROTOTIPADO
PROTOTIPADO
MODELOS CICLOS DE
VIDA DE SISTEMAS
INCREMENTAL
INCREMENTAL
EVOLUTIVO
CASCADA
EVOLUTIVO
CASCADA
CONCURRENCIA
CONCURRENCIA
37
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y
mantenimiento
38
El modelo prcticamente idntico, que evita esta rigidez es el de cascada, que se expone a
continuacin.
P1
P1
39
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y
mantenimiento
P2
P2
40
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y
mantenimiento
41
[1]
En 1970 Winston Royce defini flujos de retorno sobre el modelo secuencial, acuando as el modelo
en cascada.
El modelo en cascada refleja la necesidad impuesta por la realidad de retornar con frecuencia desde
una fase hacia las anteriores con la informacin generada al avanzar el desarrollo.
Las representaciones ms habituales de este modelo son las representadas en las dos figuras
anteriores. La primera parece indicar que el retorno posible se da solamente entre una fase y la
anterior, mientras que en la segunda se refleja mejor el hecho de que en cualquier fase puede surgir
un retorno para modificar cualquiera de las anteriores.
Este modelo, como el anterior, reconoce la importancia de disponer de unos requisitos y un diseo
previo antes de comenzar con la codificacin del sistema, pero al mismo tiempo se enfrenta al
hecho de que en la realidad la dificultad que supone disponer de documentacin elaborada de
requisitos y diseo antes de empezar a codificar puede actuar como una barrera que bloquee el
comienzo de la siguiente fase.
Por estas razones el modelo no se ha hecho muy popular, y los equipos que lo aplican pueden caer
en la tentacin de comenzar con el diseo o incluso con la codificacin, sin tener un conocimiento
suficiente de los requisitos.
Resulta apropiado para:
[1] Algunos textos llaman cascada al modelo lineal, y cascada modificada al modelo de cascada
42
43
P3
P3
45
Diseo
Diseo
Codificacin
Codificacin
Diseo
Diseo
Pruebas
Pruebas
Codificacin
Codificacin
Operacin
Operacin
Integracin
Integracin Mantenim.
Mantenim.
Pruebas
Pruebas
Diseo
Diseo
Sub-sistema
Operacin
Operacin
Integracin
Integracin Mantenim.
Mantenim.
Codificacin
Codificacin
Pruebas
Pruebas
Sub-sistema
SISTEMA
El usuario dispone de pequeos subsistemas operativos que ayudan a perfilar mejor las
necesidades reales del sistema en su conjunto.
46
P4
P4
47
Diseo
Diseo
Codificacin
Codificacin
Requisitos
Requisitos
Pruebas
Pruebas
Diseo
Diseo
Operacin
Operacin
Integracin
Integracin Mantenim.
Mantenim.
Codificacin
Codificacin
Pruebas
Pruebas
Sistema
Operacin
Operacin
Integracin
Integracin Mantenim.
Mantenim.
Requisitos
Requisitos
Sistema
Diseo
Diseo
Este modelo est compuesto por varios ciclos de desarrollo. Cada uno de ellos produce un sistema
completo con el que se operar en el entorno de operacin.
La informacin acumulada en el desarrollo de cada sistema, y durante su fase de operacin sirve
para mejorar o ampliar los requisitos y el diseo del siguiente.
En realidad es un ciclo de vida comn a todos los sistemas desarrollados que se mejoran a travs de
versiones sucesivas.
48
Necesidad de que el sistema entre en operacin en tiempos inferiores a los que seran
necesarios para disearlo y elaborarlo de forma exhaustiva.
P5
P5
P6
P6
49
Operativos: Mdulos de software con funcionamiento propio que se desarrollan sin cubrir las
funcionalidades completas del sistema, normalmente en entornos RAD (rapid application
development.
Esta forma de trabajo previo suele tener como principal objetivo la experimentacin con un entorno
similar al pretendido, para obtener retro-informacin del usuario o cliente que ayuda a los
desarrolladores en la concrecin de los requisitos.
Aunque ofrece muchas ventajas, deben conocerse los riesgos que implica el uso de prototipado:
51
52
Diseo del modelo especfico de ciclo de vida para el proyecto (sobre las bases de los
diseos ms apropiados, para el desarrollo y la evolucin del sistema de software.
Desarrollo del plan para la gestin del ciclo de vida del proyecto.
E2
E2
53
54
55
Requisitos deficientes
La planificacin de agendas y estimaciones de costes no se realizaron en base a los
requisitos
Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto
56
TOTAL: 52%
57
Fase en la que se
detecta el fallo
Requisitos
1X
1X
Arquitectura
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo detallado
construccin
Produccin
Estimacin
E1
E1
Planificacin
Diseo
Construccin
V&V
Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute
en todas las fases del proyecto.
Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar
algo que no se conoce.
Planificacin No se puede confiar en la planificacin para el desarrollo de algo que no se
sabe bien como es.
Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que ms tarde se confirmarn
como errneas y sern modificadas.
Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y
error que derrochan horas y paciencia de programacin sobre patrones de recodificacin
continua y programacin heroica.
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen
errores de bulto, o peor an, no estn reflejadas en una especificacin de requisitos, no
ser posible validar el producto con el cliente.
59
Problemas en la validacin
del producto obtenido
Requisitos crecientes
y cambiantes
Degradacin de la estructura
y arquitectura del producto
Requisitos ambiguos
Prdida de tiempo en
re-codificacin
Requisitos
innecesarios
Trabajo innecesario
Requisitos mnimos
(insuficientes)
Problemas en la validacin
del producto obtenido
Requisitos mnimos
(insuficientes)
Error en la estimacin
y planificacin
Usuarios insatisfechos
60
61
[1]
Para evitarla hay que confirmar que se comparte la visin obtenida con la que tienen las
diferentes fuentes de requisitos, y que los distintos participantes obtienen la misma
interpretacin de la documentacin de requisitos.
[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.
62
63
64
65
E2
E2
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.
Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el
proyecto que el sistema no era lo que se peda.
Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su
validacin.
Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su
peticin no est documentada y validada por l.
Base objetiva para la estimacin de recursos (coste, personal en nmero y competencias, equipos
y tiempo)
Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras
apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un
margen de error; por esta razn disponer de la mayor informacin posible reduce el error.
Conceptos clave.
Requisitos
del software
Requisitos
del sistema
Procesos de
ingeniera de
requisitos
Especificacin
Obtencin
Anlisis
Gestin
Validacin y
verificacin
67
Procesos
Obtencin
Obtencin
Anlisis
Anlisis
mbitos
Especif.
Especif.
V
V&
&V
V
Gestin
Gestin
Sistema
Sistema
Software
Software
Registro y contrastacin
Controlar las
modificaciones
Obtener informacin
Clasificarla, localizar
inconsistencias, dar
prioridades, pasar a
requisitos
Escribir los
requisitos
Registrar cambios,
estudiar su impacto,
actualizar
documentacin
OBTENCIN
ANLISIS
ESPECIFICACIN
VERIFICACIN
&
VALIDACIN
GESTIN
Obtencin (elicitation)
El primer paso consiste en conocer y comprender las necesidades y problemas del cliente.
En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y, en funcin
de las caractersticas del entorno y del proyecto se emplean las tcnicas ms apropiadas para la
identificacin de las necesidades que deben satisfacerse.
Anlisis
Una vez obtenida la informacin necesaria del entorno, es necesario sintetizarla, darle prioridades,
analizar posibles contradicciones o conflictos, descomponer el sistema y distribuir las necesidades de
cada parte, delimitar los lmites del sistema y definir su interaccin con el entorno.
69
70
Descripcin
Descripcin del
del sistema
sistema
ConOps
ConOps
Software
Software
Requisitos
Requisitos del
del software
software
SRS
SRS
mbitos
71
El documento que recoge los deseos del usuario, sin requerir una cuantificacin medible.
Por ejemplo, el usuario puede indicar que desea que los tiempos de respuesta de las
consultas sean rpidos, y las razones de su deseo, sin necesidad de cuantificar esos
trminos. Ms adelante, el desarrollo y anlisis de los requisitos del sistema, el analista
concretar y cuantificar esos deseos.
72
74
SISTEMA
EVOLUCIN
PREVISTA
75
Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
76
77
Algunos ejemplos de restricciones de diseo vlidas los constituyen los requisitos fsicos, los de
rendimiento y el cumplimiento de estndares en el desarrollo y procesos de garanta de calidad.
E3
E3
Coste.
Agenda de entregas.
Procedimientos de seguimiento.
Mtodos de desarrollo del software.
Control de calidad.
Criterios de validacin y verificacin.
Procedimientos de aceptacin
78
SRS
5.1 Adquisicin
5.1 Adquisicin
5.2 Suministro
5.2 Suministro
5.4
Operacin
5.3
Desarrollo
5.4
Operacin
5.3
Desarrollo
5.5
Mantenimiento
5.5
Mantenimiento
79
ENTORNO DE LA SOLUCIN
SRS
E4
E4
80
ANALIZAR EL PROBLEMA
DEFINIR EL SISTEMA
Analizar el
problema
Comprender las
necesidades de
los usuarios
Definir el sistema
Desarrollar los
requisitos del
software
Gestionar los
requisitos
81
Analizar el problema
Consiste en comprender los problemas reales de los usuarios, y proponer soluciones que cubran
sus necesidades.
El objetivo del anlisis es conseguir la mayor comprensin posible antes de que empiece el
desarrollo.
El analista de requisitos es en realidad un solucionador de problemas.
Durante el anlisis debe comprender las necesidades de los usuarios, y proponer soluciones. En
esta tarea es necesario explorar y comprender el entorno del cliente.
Al realizar el anlisis hay que
Evitar la tendencia frecuente a los prejuicios creyendo que ya conocemos las necesidades del
cliente, y que su principal problema en realidad es que no entiende cul es su problema.
Tener en cuenta que siempre hay varias maneras de abordar un problema, y que en ocasiones,
cambiar la perspectiva del usuario puede generar la solucin ms eficiente y rentable, aunque no
siempre es posible.
Comenzar el anlisis sin ideas preconcebidas y teniendo presente el objetivo: conseguir la mayor
comprensin posible del problema.
El anlisis del problema comprende
1.2.3.4.-
82
Definir el sistema
La descripcin del sistema marca el punto intermedio entre el anlisis del problema, y la
descripcin detallada de los requisitos del software. Es el documento que ofrece una visin general,
y ofrece la idea global del sistema en su conjunto. Marca una pausa antes de seguir avanzando
hacia los detalles, para evitar que los rboles nos impidan ver el bosque.
El resultado de esta fase es el documento de Definicin del sistema,
frecuentemente llamado tambin ConOps (Concept of Operations).
83
Definir el sistema
La descripcin del sistema el resultado del anlisis conceptual, y debe contener toda la informacin
necesaria para describir las necesidades de los usuarios, expectativas, entorno operativo, procesos
y caractersticas del sistema que se ha ideado para darles solucin.
Los elementos esenciales de la descripcin del sistema son:
Por Definir el sistema no consideramos slo la redaccin del Con Ops por
el ingeniero de requisitos. Tambin comprende la verificacin y
validacin del documento.
Por verificacin se entiende la supervisin del documento para garantizar que
resulta formalmente correcto.
Validacin implica la conformidad de las partes afectadas por el sistema
(usuarios, clientes, etc.).
84
85
Requisitos
Diseo
Codificacin
Integracin/
pruebas
Sistemas complejos.
Sistemas para dar soporte a procesos de negocio poco maduros.
Desarrollos evolutivos impuestos por la necesidad de implantaciones parciales tempranas
para los usuarios.
Avance del desarrollo del proyecto
E5
E5
88
89
El sistema no sustituye o modifica a otro existente, sino que se desarrolla para dar soporte a procesos de negocio
novedosos para la organizacin que lo solicita.
Los interlocutores nombrados por el cliente no son conocedores expertos de los procesos cubiertos por el sistema.
Faltan representantes de partes implicadas por procesos importantes del nuevo sistema.
Escasa implicacin del cliente, que por falta de recursos, tiempo o incluso por pereza intelectual no se sienta con el
ingeniero de requisitos a desmenuzar las particularidades de sus procesos, dando por vlidos los requisitos finalmente
obtenidos, sin prcticamente mirarlos.
91
92
93
Ya est todo?
Cundo se puede dar por terminado un trabajo?
Cuando ya no queda ms por hacer.
Cmo sabe el ingeniero de requisitos que ha descubierto
todos los requisitos necesarios?.
Esta incertidumbre es tambin inherente al trabajo del
ingeniero de requisitos, porque nunca tendr la certeza de
haber descubierto todas las necesidades y restricciones, y
sobre todo porque siempre puede dar por descontado que
algo se queda sin descubrir.
La nica forma de afrontar esta circunstancia es dedicar tiempo suficiente a la obtencin y anlisis,
e identificar a todos los participantes o partes implicadas en el proyecto.
Aunque nunca podr afirmar haber localizado todos los requisitos, el objetivo en este caso es
alcanzar el convencimiento de haber descubierto lo suficiente, y que las posibles omisiones
pertenecern a cuestiones menores, que pueden surgir durante la gestin de los requisitos, o a lo
largo del mantenimiento del futuro sistema.
94
96
Organizacin
Entorno
Proyecto
97
98
Problema: inestabilidad
Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio del
sistema.
La solucin para evitar problemas radica en el proceso de gestin de requisitos.
[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for Requirements
Definition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on
System Sciences, p. 201-209. IEEE Computer Society, January 1990
99
ESCENARIOS
PROTOTIPOS
Prototipos rpidos
prototipos evolutivos
TCNICAS
OBSERVACIN
Introspeccin
anlisis de protocolo
documentacin, otros sistemas
E6
E6
100
NO FUNCIONALES
RESTRICCIN
REQUISITO
DE INTERFAZ
RESTRICCIN
Requisitos funcionales
Definen el comportamiento del sistema.
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad,
insuficiencia de detalle o ambigedad, y el exceso de detalle con precisiones o descripciones
innecesarias o redundantes.
101
Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan
deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento.
etc.
Requisitos de interfaz
Definen las interacciones del sistema con su entorno:
Usuarios
Otros sistemas
102
Restricciones
Los requisitos, en su definicin purista definen el QU, y no el CMO; pero en el conjunto de
necesidades que debe cubrir un sistema, no slo hay que tener en cuenta QU cosas hay que
hacer, sino tambin en ocasiones CMO deben hacerse.
La clasificacin entre requisitos puros (QU) y restricciones (CMO) la debe considerar el analista
para que el equipo de trabajo sepa hasta qu punto determinados aspectos limitan sus opciones de
trabajo, y poder mantener as la trazabilidad con su origen (necesidad apuntada por el usuario,
normativa legal, limitacin tcnica, etc.)
Con carcter general las restricciones imponen limitaciones:
El analista del sistema elige entre todas las opciones tecnolgicamente posibles aquellas que segn
su criterio profesional y las circunstancias del sistema, aportan mejor solucin para la
implementacin de los requisitos funcionales y no funcionales.
La indicacin por parte del cliente de instrucciones como:
Debe emplearse base de datos Oracle.
Los procesos de desarrollo deben ser conformes a Mtrica 3.
El sistema final debe ejecutarse sobre la plataforma libre Linux.
Debe desarrollarse empleando Java.
El interfaz de comunicacin con un programa externo de contabilidad debe hacerse de la siguiente
forma...
103
Requisitos
Posibles
Completa
Necesarios
Correcta
Priorizados
Consistente
Concretos
Modificable
Verificables
Trazable
105
Necesarios
Un requisito es necesario si es algo:
Alto
externo o estndar.
Coste
Alto
Valor
106
107
Comprensin
Un requisito es concreto si tiene una nica interpretacin. Como mnimo esto requiere que cada
caracterstica del producto final se describa empleando un trmino nico. En los casos en los que
el trmino puede tener diferentes significados segn el contexto, ste debe incluirse en el
glosario de la SRS con el significado con el que se emplea.
Punto
ptimo
Ambigedad
109
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.
110
No Conocemos
Entrevistas y revisiones
Entendemos
Prototipado
Prototipado y
casos de uso
No Entendemos
111
A
B
B
Revisin y aprobacin
Requisitos
Correctos
C
Requisitos
Especificados
112
Conflictos
Objetos
Lgicos
C=A+B
C=A*B
Trminos
RF 10 Informe A
cierre de caja
RF 50 Informe A
cierre diario de operaciones
113
114
115
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
116
MEDIOS
Aplicar tcnicas
y procesos
FIN
Conseguir
el objetivo
117
118
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
119
Requisitos
Diseo
Construccin
120
121
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
122
Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de
comenzar la construccin de un sistema son:
123
Descomposicin de la complejidad
Class nombredeclase{
Public: funcion() {}
}
124
Requisitos
Disponibilidad
Coste desarrollo
Coste mantenimiento
Robustez
Tiempos de respuesta
Hardware necesario
Etc.
125
126
127
128
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.
129
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.
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
130
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.
131
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.
Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est.
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.
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).
133
Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de despliegue
Comportamiento dinmico
Modularizacin
Paquetes
Subsistemas
Modelos
134
135
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
136
QU
CMO
137
138
Ingeniero
Ingeniero de
de Software decide:
Gestor
Gestor de Proyecto
Proyecto decide:
decide:
Qu
Qu tareas
tareas hay
hay que
que realizar
realizar
Las
Las habilidades
habilidades necesarias
necesarias para
para realizar
realizar las
las tareas
tareas
Orden
Orden yy Dependencias
Dependencias de
de tareas
tareas
La
La agenda
agenda para
para terminar
terminar el
el proyecto
proyecto
Tamao
Tamao (Esfuerzo
(Esfuerzo en horas)
El
El coste
coste de
de esfuerzo
esfuerzo
Solucin
Solucin tcnica para la resolucin del problema
problema
Metodologa
Metodologa para
para evaluar
evaluar el estatus del proyecto
Qu
Qu herramientas
herramientas de anlisis y diseo hay que
utilizar
utilizar
Qu
Qu herramientas
herramientas de
de planificacin hay que utilizar
Riesgos
Riesgos tcnicos
tcnicos
Gestin
Gestin de
de riesgos
riesgos
El
El modelo
modelo de
de procesos
procesos (Tcnicas)
(Tcnicas)
El
El modelo
modelo de
de procesos
procesos (Gestin)
Actualizar
Actualizar la
la planificacin
planificacin cuando
cuando los requisitos o el
entorno
entorno cambian.
cambian.
Actualizar
Actualizar la
la planificacin
planificacin cuando
cuando condiciones
condiciones de
gestin
gestin yy entorno
entorno cambian.
cambian.
139
140
5.-Documentacin de usuario
141
Documentacin de usuario
Conceptos
Conceptos generales
generales
Formatos de distribucin
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.
Documentacin de usuario
Conceptos
Conceptos generales
generales
Tipos de documentos y contenidos posibles
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.
P1
P1
143
Documentacin de usuario
Conceptos
Conceptos generales
generales
Modos descriptivos
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).
Formativo
Orientado a la
informacin
Orientado a tareas
Modos descriptivos
E1
E1
Referencia
144
Documentacin de usuario
Desarrollo
Desarrollo de
de la
la documentacin
documentacin
Los factores que deben determinarse antes de desarrollar la documentacin son:
Documentos necesarios
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.
145
Documentacin de usuario
Desarrollo
Desarrollo de
de la
la documentacin
documentacin
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.
P2
P2
[1] Brockmann, R.J. (1990). Writing Better Computer Documentation: From Paper to Hypertext
[1]
146
Documentacin de usuario
Desarrollo
Desarrollo de
de la
la documentacin
documentacin
Clasificacin de usuarios
Nivel de sofisticacin informtica
Caractersticas
[1]
Inexperto[1]
Muy
Muy poca
poca o
o ninguna
ninguna experiencia
experiencia con
con ordenadores
ordenadores
Tratan
Tratan volmenes
volmenes reducidos
reducidos de
de informacin
informacin
No
No confan
confan en
en la informtica
informtica
Trabajadores
Trabajadores concretos
concretos
Principiante
Alguna
Alguna experiencia
experiencia con
con ordenadores
ordenadores
Pueden
Pueden comprender
comprender conceptos
conceptos aislados
aislados
Emplean
Emplean ejemplos
ejemplos concretos
Emplean
Emplean siempre
siempre las
las opciones
opciones por
por defecto
defecto
Usuario
Usuario novel con pocos meses de experiencia con
ordenadores
ordenadores
Comienza
Comienza aa enlazar
enlazar conceptos
conceptos aislados
aislados
Emplea
Emplea acciones
acciones por
por defecto
defecto yy sus
sus opciones.
opciones.
Es
Es la
la evolucin
evolucin de
de un
un usuario
usuario intermedio.
intermedio.
Comprende
las
relaciones
Comprende las relaciones entre
entre conceptos
conceptos aislados.
Tiene
un
nivel
alto
de
autoconfianza.
Tiene un nivel alto de autoconfianza.
Comprende
Comprende el
el lenguaje
lenguaje abstracto
abstracto
Puede
Puede ser
ser inexperto,
inexperto, principiante,
principiante, intermedio
intermedio o
o
experto.
experto. Trabaja
Trabaja muy
muy poco
poco con
con el
el sistema.
sistema.
Se
Se conduce
conduce aa travs
travs de
de los
los mens
mens yy mensajes
mensajes del
del
sistema
sistema
Intermedio
Experto
Intermitente
147
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
E2
E2
148
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Estructura general
149
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Cada documento debe incluir
INFORMACIN IDENTIFICATIVA
INFORMACIN IDENTIFICATIVA
Ttulo del documento
Ttulo del
Versin
del documento
documento y fecha de publicacin
Versin
del
documento
fecha de
Nombre del producto
de y
software
y publicacin
versin
Nombre del que
producto
software y versin
Organizacin
edita de
el documento
Organizacin que edita el documento
TABLA DE CONTENIDOS (ndice)
TABLA DE CONTENIDOS (ndice)
INTRODUCCIN
INTRODUCCIN
Audiencia
Audiencia
Alcance
y propsito del documento
Alcance
y propsito
delpropsito
documento
Descripcin
general del
y funcionalidad
del
Descripcin
y funcionalidad
software, general
as comodel
delpropsito
entorno de
operacin
del software, as como del entorno de operacin
E3
E3
150
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Informacin crtica
Contenido
151
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE
COMPONENTE
OBLIGATORIO?
OBLIGATORIO?
Informacin
Informacin identificativa
identificativa
S
S
Tabla
Tabla de
de contenidos
contenidos
S,
S, en
en documentos
documentos de
de ms
ms de
de 8 pginas
pginas
Lista
Lista de imgenes
Opcional
Opcional
Introduccin
Introduccin
S
S
Informacin
Informacin para
para el
el uso
uso de
de la
la documentacin
documentacin
S
S
Informacin
Informacin conceptual
conceptual de
de las
las funcionalidades
funcionalidades
generales
generales
S
S
152
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones del estndar IEEE 1063-2001 para la estructura
Componentes recomendados para la documentacin de usuario
COMPONENTE
COMPONENTE
OBLIGATORIO?
OBLIGATORIO?
Procedimientos
Procedimientos
S,
S, en
en modo
modo formativo
formativo
Informacin
Informacin de
de comandos
comandos de
de software
software
S,
S, en
en modo
modo referencia
referencia
Mensajes
Mensajes de
de error yy resolucin
resolucin de
de problemas
problemas
S
S
Glosario
Glosario
S,
S, si
si la
la documentacin
documentacin incluye
incluye trminos
trminos
desconocidos
para
la
audiencia
desconocidos para la audiencia
Fuentes
Fuentes de
de informacin
informacin adicionales
adicionales
Opcional
Opcional
ndice
ndice
S,
S, en
en documentos
documentos de
de ms
ms de
de 40 pginas
Capacidad
Capacidad de bsqueda
S,
S, en
en documentacin
documentacin sobre
sobre formato
formato electrnico
electrnico
153
Documentacin de usuario
Estructura
Estructura de
de la
la documentacin
documentacin de
de usuario
usuario
Recomendaciones generales
Legibilidad
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.
Correccin
Los textos deben ser lxica, ortogrfica y sintcticamente correctos.
E1
E1
155
Verificacin y validacin
Introduccin
Introduccin
La complejidad del desarrollo de un sistema de software
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.
E2
E2
156
Verificacin y validacin
Introduccin
Introduccin
Verificacin y validacin
Aunque en el lenguaje coloquial estos trminos pueden considerarse sinnimos, en el contexto de la
ingeniera del software tienen significados diferentes:
P1
P1
[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
157
Verificacin y validacin
Conceptos
Conceptos
Verificacin y validacin
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:
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.
158
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
E3
159
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en los
los procesos
procesos de
de desarrollo
desarrollo
5. Procesos primarios
5.1
5.1 Adquisicin
Adquisicin
6.1
6.1 Documentacin
Documentacin
5.2
5.2 Suministro
Suministro
6.2
6.2 Gestin
Gestin de
de la
la configuracin
configuracin
6.3
6.3 Control
Control de
de calidad
calidad
5.3
5.3
Operacin
Operacin
6.4
6.4 Verificacin
Verificacin
6.5
6.5 Validacin
Validacin
5.3
5.3
Desarrollo
Desarrollo
6.6
6.6 Reuniones
Reuniones
5.3
5.3
Mantenimiento
Mantenimiento
6.7
6.7 Auditora
Auditora
6.8
6.8 Resolucin
Resolucin de
de problemas
problemas
7. Procesos organizacionales
7.1
7.1 Gestin
Gestin
7.2
7.2 Infraestructura
Infraestructura
7.3
7.3 Mejora
Mejora
7.4
7.4 Formacin
Formacin
160
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en los
los procesos
procesos de
de desarrollo
desarrollo
Procesos de soporte
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.
161
Verificacin y validacin
Relacin
Relacin entre
entre V&V
V&V yy el
el Aseguramiento
Aseguramiento de
de la
la Calidad
Calidad
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
162
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Definiendo los objetivos
Las consideraciones que deben contemplarse para evaluar la planificacin de las actividades de
Validacin y Verificacin son:
Los criterios que se emplearn en las tareas de V&V para establecer los parmetros
mnimos de correccin, consistencia, precisin
163
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Criticidad del producto
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.
E4
E4
164
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Anlisis de criticidad
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 daos
(hazard analysis)
Anlisis de criticidad
Anlisis de riesgos
(risk analysis)
165
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Anlisis de criticidad: anlisis de daos
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:
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).
166
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Anlisis de criticidad: anlisis de riesgos
Riesgo: probabilidad de que se produzca un dao identificado
P2
P2
P3
P3
167
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Anlisis de criticidad: anlisis de riesgos
NATURALEZA DEL RIESGO
Propios del sistema
CAUSAS TPICAS
Los identificados en el anlisis de daos
Complejidad innecesaria
Baja calidad
Complejidad
Complejidad intrnseca
intrnseca del
del diseo
diseo mayor
mayor de
de la
la necesaria
necesaria
Incumplimiento
Incumplimiento de
de estndares
estndares necesarios
necesarios
[1] En los proyectos de software se suelen dar con mayor intensidad los riesgos tpicos indicados.
168
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Anlisis de criticidad: anlisis de riesgos
Validacin y Verificacin no gestionan las causas de los riesgos. Esa gestin pertenece a la gestin
de riesgos, dentro de la gestin del proyecto.
Validacin
Verificacin
Gestin de proyecto
(Gestin de riesgos)
[1] En los proyectos de software se suelen dar con mayor intensidad los riestos tpicos indicados.
169
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Niveles de integridad
Anlisis de daos
(hazard analysis)
NIVEL DE
INTEGRIDAD
Anlisis de criticidad
Anlisis de riesgos
(risk analysis)
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.
Adecuacin de las
tareas de
VALIDACIN
y
VERIFICACIN
POSIBILIDAD DE MITIGACIN
DEL DAO
170
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
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
4
Mitigacin aplicable
Prdida de vida
Prdida del sistema
Graves prdidas econmicas o sociales
No es posible mitigar
los daos producidos
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.
171
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Independencia
La determinacin de las personas responsables de las tareas de verificacin y validacin, depende
de:
P4
P4
P5
P5
Nivel de integridad
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.
172
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Tipos de independencia
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.
reas
Tipos de independencia
Gestin
Tcnica
Financiera
CLSICA
MODIFICADA
I-R
INTERNA
I-R
I-R
I-R
DOMSTICA
I-M
I-M
I-M
I: Independencia rigurosa
173
Verificacin y validacin
Adecuacin
Adecuacin de
de V&V
V&V aa las
las caractersticas
caractersticas del
del proyecto
proyecto
Tipos de independencia
IV&V CLSICA
Normalmente requerida para proyectos con nivel de integridad 4.
Exige rigurosa independencia en las 3 reas del proyecto.
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.
174
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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
Adquisicin
Suministro
Desarrollo
Operacin
Mantenim.
Verificacin y Validacin
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:
175
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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.
176
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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
177
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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
DE LOS REQUISITOS
Posibles
Necesarios
Priorizados
Correctos
Verificables
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.
178
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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.
179
Verificacin y validacin
Verificacin
Verificacin yy validacin
validacin en
en el
el ciclo
ciclo de
de vida
vida del
del software
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
E5
180
7.- Mantenimiento
E1
E1
181
Mantenimiento
Introduccin
Introduccin
La complejidad del mantenimiento de un sistema de software
CONSUME MUCHOS RECURSOS
El mantenimiento consume ms
del 60% del coste de todo el
ciclo de vida
Mantenimiento
Introduccin
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
IEEE Std.
Std. 1219-1998
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
183
Mantenimiento
Tipos
Tipos de
de mantenimiento
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.
184
Mantenimiento
Tipos
Tipos de
de mantenimiento
mantenimiento
PERFECTIVO
Se realiza para dar respuesta a nuevos requisitos del cliente, o para mejorar el rendimiento del
sistema.
Clasificacin
Porcentajes habituales
Adaptativo
Mantenimiento
De emergencia
Correctivo
De agenda
Perfectivo
[Preventivo]
PREVENTIVO
E2
E2
Mantenimiento
Dificultad
Dificultad del
del mantenimiento
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 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:
186
Mantenimiento
Dificultad
Dificultad del
del mantenimiento
mantenimiento
Dificultad por degradacin del sistema
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
Diseo
Diseo
Cdigo
Cdigo
Datos
Datos
Documentacin
Documentacin
187
Mantenimiento
Dificultad
Dificultad del
del mantenimiento
mantenimiento
Dificultad por degradacin del sistema
DIFICULTAD
DEL MANTENIMIENTO
Factores agravantes
SISTEMA MS DIFCIL
DE MANTENER
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
Mantenimiento
Gestin
Gestin del
del mantenimiento
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.
189
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
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:
Al realizar tareas de mantenimiento, en cada una de estas fases deben considerarse los siguientes
elementos:
EN CADA FASE
Entradas
Procesos
Control
Salidas
Mtricas
190
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
1.- Identificacin del problema, clasificacin y priorizacin
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
Peticin de cambio
Procesos
Asignar n de
identificacin
Clasificar por tipo
de mantenimiento
Analizar y determinar 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
Control
Una vez identificada
la peticin de
cambio, debe
quedar registrada en
un registro de
peticiones de
cambio
Salidas
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
Mtricas
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
191
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
2.- Anlisis
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
Peticin de cambio
validada
Estimacin inicial
de recursos y
dems informacin
registrada.
Documentacin del
proyecto (si la
hay).
Procesos
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)
Control
Salidas
Realizar revisiones
tcnicas y revisar
Estrategia de
pruebas.
Que la documentacin est completa
y actualizada e
incluye parmetros
de seguridad
Informe de
viabilidad de las
P.C.
Informe del anlisis detallado.
Requisitos
actualizados (y
trazables)
Lista preliminar
de mofificaciones.
Plan de pruebas
Plan de
implementacin
Mtricas
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
192
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
3.- Diseo
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
Salidas de la fase
de anlisis.
Documentacin del
sistema y del
proyecto
Cdigo,
comentarios y
bases de datos del
sistema.
Procesos
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)
Control
Inspeccin /
verificacin del
diseo
Inspeccin /
verificacin de la
documentacin
asociada
Salidas
Revisados:
Lista de
modificacines
Anlisis detallado
Plan de
implementacin
actualizado
Lnea base de
diseo
Planes de
pruebas
Mtricas
Complejidad del
software
Cambios diseo
Esfuerzo por rea
Cambios en
planes de prueba
Nmero de
mdulos
N lneas de
cdigo aadidas o
modificadas
193
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
4.- Implementacin
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
Resultados de la
fase de diseo.
Cdigo fuente y
bases de datos del
sistema.
Documentacin del
sistema y del
proyecto.
Procesos
Codificacin y
pruebas unitarias
Integracin
Anlisis de riesgos
Revisin de
pruebas
Control
Revisiones de
cdigo
Verificacin de la
integracin.
Verificacin de
modificaciones y
actualizaciones
de
documentacin.
Gestin de
riesgos y
supervisin
durante las
pruebas
Salidas
Revisados:
Software
actualizado.
Documentacin
de diseo,
pruebas,
manuales
documentacin
de formacin
actualizados.
Definicin de
riesgos e
impactos.
Informe de
revisin de las
pruebas
Mtricas
Volumen (puntos
de funcin /
lneas de cdigo)
Porcentaje de
errores
generados.
194
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
5.- Pruebas de sistema y de regresin
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
Informe de las
pruebas.
Documentacin de
los planes de
prueba, casos de
prueba,
procedimientos de
prueba, manuales
de usuario, diseo.
Sistema
actualizado
Procesos
Prueba funcional
del sistema.
Pruebas de
interfaz.
Pruebas de
regresin.
Control
Salidas
Revisados:
Sistema revisado.
Informes de
pruebas.
Mtricas
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
195
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
6.- Pruebas de aceptacin
Sobre el sistema completamente integrado, el cliente, los usuarios o un tercero nombrado por el
cliente lleva a cabo las pruebas de aceptacin
Entradas
Informes de
pruebas.
Sistema
completamente
integrado.
Planes de pruebas
de aceptacin.
Casos de prueba
de aceptacin.
Procedimientos de
aceptacin
Procesos
Ejecucin de las
pruebas de
aceptacin a nivel
funcional.
Ejecucin de
pruebas de
interoperabilidad.
Ejecucin de
pruebas de
regresin.
Control
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.
Salidas
Mtricas
Porcentajes de
errores por
prioridad y tipo:
Generados y
corregidos.
196
Mantenimiento
Las
Las 77 fases
fases del
del mantenimiento
mantenimiento
7.- Entrega
Entrega del sistema modificado.
Entradas
El sistema
modificado segn
se represente en la
nueva lnea base.
E3
E3
Procesos
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.
Control
Ejecucin de la
auditora fsica de
la configuracin.
Documento de
descripcin de la
versin.
Salidas
Informe de la
auditora fsica.
Documento de
descripcin de la
versin.
Mtricas
Cambios en la
documentacin
(manuales de
usuario, de
operacin,
documento
descripcin de
versin, etc.)
197
Mantenimiento
Mantenibilidad
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:
198
Mantenimiento
Mantenibilidad
Mantenibilidad
Medicin
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:
199
Mantenimiento
Mantenibilidad
Mantenibilidad
Reingeniera
Cmo abordar el mantenimiento de un sistema de software con problemas de
mantenibilidad?
200
Mantenimiento
Mantenibilidad
Mantenibilidad
Modelo de reingeniera del software
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.
Anlisis de
inventario
Qu
hacer?
Reconstruccin
Ingeniera inversa
Ingeniera
Ingeniera
inversa
inversa
Reestructuracin
Reestructuracin
de
de datos
datos
Reestructuracin
Reestructuracin
de
de cdigo
cdigo
Reestructuracin
Reestructuracin
de
de documentos
Ingeniera
Ingeniera
progresiva
progresiva
201
Mantenimiento
Mantenibilidad
Mantenibilidad
Modelo de reingeniera del software
Anlisis de inventario
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:
Mantenimiento
Mantenibilidad
Mantenibilidad
Modelo de reingeniera del software
Reestructuracin de documentos
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:
Mantenimiento
204
Mantenimiento
Mantenibilidad
Mantenibilidad
Modelo de reingeniera del software
Reestructuracin de cdigo
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.
Reestructuracin de datos
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.
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
205
Mantenimiento
Mantenibilidad
Mantenibilidad
Modelo de reingeniera del software
Ingeniera progresiva
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.
E4
E4
206
207
Gestin de la configuracin
Introduccin
Introduccin
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
Gestin de la configuracin
Definicin
Definicin
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.
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.
Temporal
Entorno
Sistema
Desarrollo
Desarrollo
Mantenimiento
Mantenimiento
Ciclo de vida
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
209
Gestin de la configuracin
Conceptos
Conceptos clave
clave
Lnea base
Peticin de
cambio
Comit de
control de la
configuracin
Librera
Elementos de
configuracin
del software
210
Gestin de la configuracin
Conceptos
Conceptos clave
clave
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:
Gestin de la configuracin
Conceptos
Conceptos clave
clave
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.
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.
E1
E1
Categoras
Producto:
Producto: Productos
Productos intermedios
intermedios o
o finales
finales desarrollados
desarrollados durante
durante el
el proyecto.
proyecto.
Software
Software adquirido:
adquirido: Mdulos
Mdulos o
o componentes
componentes adquiridos
adquiridos o
o subcontratados.
subcontratados.
Software
Software suministrado:
suministrado: Software
Software proporcionado
proporcionado por
por el
el cliente
cliente para
para que
que se
se integre
integre en
en el
el sistema.
sistema.
Software
Software de
de pruebas:
pruebas: Software
Software empleado
empleado para
para realizar
realizar las pruebas.
Software
Software de
de apoyo:
apoyo: Software
Software empleado
empleado para
para desarrollar
desarrollar el
el sistema
sistema de software
software (compiladores,
(compiladores, etc.)
etc.)
212
Gestin de la configuracin
Conceptos
Conceptos clave
clave
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.
213
Gestin de la configuracin
Conceptos
Conceptos clave
clave
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.
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.
214
Gestin de la configuracin
Conceptos
Conceptos clave
clave
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:
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.
215
Gestin de la configuracin
Conceptos
Conceptos clave
clave
Libreras
LIBRERA DINMICA
Tambin llamada Directorio de programacin.
Controlada por el equipo de programacin.
LIBRERA CONTROLADA
Tambin llamado Directorio maestro.
Contiene todas las lneas base del proyecto.
LIBRERA ESTTICA
Tambin llamado Repositorio de software
Comprende las lneas base que finalmente se entregan.
Versin 1.0
Versin 1.1
216
Gestin de la configuracin
Funciones
Funciones clave
clave de
de la
la gestin
gestin de
de la
la configuracin
configuracin
Gestin de la configuracin
del software
Identificacin
Identificacin de
de
la
la configuracin
Control
Control de
de la
la
configuracin
configuracin
Medicin
Medicin del
estado
estado de
de la
la
configuracin
configuracin
Auditoras
Auditoras y
y
revisiones
revisiones
Control
Control de
de las
las
relaciones
relaciones de
interfaz
interfaz
217
Gestin de la configuracin
Funciones
Funciones clave
clave de
de la
la gestin
gestin de
de la
la configuracin
configuracin
Identificacin de la configuracin
Identificacin
Seleccin
Seleccin de
de los
los elementos
elementos de
de configuracin
configuracin yy agrupacin
agrupacin en
en lneas
lneas base.
base. Deben
Deben
considerarse
considerarse productos
productos que
que puedan
puedan disearse,
disearse, desarrollarse,
desarrollarse, probarse
probarse yy
modificarse
modificarse de forma independiente.
Documentos
Documentos
Cdigo
Cdigo
Datos
Datos
Seleccin
Seleccin
Revisin
Revisin
tcnica
tcnica y
y
formal
Lneas base
No
No deben
deben identificarse
identificarse muy pocos, ni tampoco demasiados. Los criterios de
seleccin
seleccin deben
deben ser
ser acordes
acordes con
con las
las caractersticas
caractersticas del
del proyecto.
proyecto.
Nomenclatura y
adquisicin
Actividades
Nomenclatura:
Nomenclatura: Cada
Cada elemento
elemento de
de configuracin
configuracin debe
debe nombrarse con un identificador nico. Es
habitual
habitual que el identificador contenga:
contenga:
NOMBRE:
NOMBRE: descriptivo
descriptivo del
del elemento.
elemento.
IDENTIFICADOR
IDENTIFICADOR DE
DE CONFIGURACION: Usado en la gestin interna de la librera.
IDENTIFICADOR
IDENTIFICADOR DE
DE VERSION: Usado para identificar las diferentes
diferentes versiones.
versiones.
Adquisicin:
Adquisicin: Una vez identificado cada elemento, debe incorporarse a su
su respectiva
respectiva librera.
218
Gestin de la configuracin
Funciones
Funciones clave
clave de
de la
la gestin
gestin de
de la
la configuracin
configuracin
Control de la configuracin
Comprende la gestin de las revisiones y de los procesos de aprobacin, para
evitar que se produzcan cambios de forma descontrolada.
Garantiza
Que
Que
Que
Que
Identificacin
Identificacin
del
del cambio
cambio
Comunicacin
formal
formal
Validacin
Validacin
yy evaluacin
evaluacin
Aprobacin
Aprobacin
o
o rechazo
rechazo
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).
Implementacin
Implementacin
EVALUACIN
Tcnico
En los interfaces de configuracin
En la agenda
En el presupuesto
219
Gestin de la configuracin
Funciones
Funciones clave
clave de
de la
la gestin
gestin de
de la
la configuracin
configuracin
Medicin del estado de la configuracin
Medicin y registro de los cambios, contenidos e histricos de la gestin de la
configuracin
Registra
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:
Gestin de la configuracin
Funciones
Funciones clave
clave de
de la
la gestin
gestin de
de la
la configuracin
configuracin
Control de las relaciones de interfaz
El desarrollo y mantenimiento de sistemas de software no suele ser autocontenido. Normalmente el software debe relacionarse con hardware y con otro
software. El control de las relaciones de Interfaz contempla y gestiona las
situaciones posibles:
SITUACIONES
IMPLICCIONES DE INTERFAZ
La gestin de la configuracin
debe registrar tambin las
plataformas y componentes
externos, evaluando las posibles
evoluciones y cambios.
221
Juan Palacio
jpalacio@navegapolis.net
http://www.navegapolis.net