Escolar Documentos
Profissional Documentos
Cultura Documentos
Tabla de 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
Factores que imprimen aceleracin al ritmo de crecimiento del hardware: Incremento de la capacidad de operacin. Consecuencias de la ley de Moore Incremento de la miniaturizacin. Reduccin de costes en la produccin. Comunicaciones entre sistemas
5
Transistores
1998
1995 1994
31%
53%
16%
El proyecto se aborta o el sistema no se llega a utilizar Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionales Proyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey, 6
En 1962 se public el primer algoritmo para bsquedas binarias. C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin
eliminacin de GoTo y la creacin de la programacin estructurada.
para la
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. El primero sobre anlisis de requisitos apareci en 1979
Otras definiciones Disciplina para producir software de calidad desarrollado sobre las agendas y costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el desarrollo, operacin y mantenimiento de software; esto es, la aplicacin de la ingeniera al software. (2) El estudio de (1).
IEEE 1993
Identificacin de los factores clave que determinan la calidad del software. Identificacin de los procesos necesarios para producir y mantener software. Acotacin, estructuracin y desarrollo de la base de conocimiento necesaria para la produccin y mantenimiento de software.
El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y operacin de los sistemas de software, introduciendo mtodos y formas de trabajo sistemticos, disciplinados y cuantificables. La forma de trabajo de programadores individuales surgida por la necesidad de los primeros programas, ha creado una cultura de la programacin heroica, para el desarrollo de software que es la principal causa de los problemas apuntados, y en la actualidad una de las principales resistencias a la implantacin de tcnicas de ingeniera para el desarrollo de sistemas
Estndares y modelos
La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse a s misma: Cules son las reas de conocimiento que la comprenden? Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del software De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para evitar los problemas de la crisis del software Definir criterios unificadores para las tareas de requisitos, pruebas, gestin de la configuracin, etc.
10
11
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
Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la Universidad Carnegie Mellon. Los trabajos y aportaciones realizadas por el Instituto de Ingeniera del Software a la Ingeniera del software son tambin referente mundial de primer orden, siendo la aportacin ms significativa los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi 15 aos de implantacin efectiva en entornos de produccin de software han demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de resultados previsibles de una organizacin de software.
12
830 Prcticas recomendadas para las especificaciones de software. 1362 Gua para la especificacin del documento de requisitos ConOps 1063 Estndar para la documentacin de usuario de software. 1012 Estndar para la verificacin y validacin de software. 1219 Estndar para el mantenimiento del software
13
Definirse a s misma: Cules son las reas de conocimiento que la comprenden? SWEBOK: Software Engineering Body of knowledge
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del software ISO/IEC 12207: Procesos del ciclo de vida del software
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
Definir estndares menores para dibujar criterios unificadores en requisitos, pruebas, gestin de la configuracin, etc. IEEE 830 - IEEE 1362 - ISO/IEC 14764
14
SWEBOK
El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de manera efectiva dentro del SWECC1 en 1997 (aunque el comit SWECC se cre en 1993). En el proyecto tambin estn representados: los dos principales organizaciones de estandarizacin en Ingeniera del Software: IEEE e ISO/IEC JTC1/SC/.
Los autores de las tres principales obras de Ingeniera del Software: Steve Mc Connell, Roger Pressman e Ian Sommerville.
Universidad de Qubec (Montreal) Empresas y organizaciones como: Rational, SAP, Boeing, Construx, MITRE, Raytheon, En 2001 el proyecto public ya una definicin consensuada del cuerpo de conocimiento aceptado en la ingeniera del software (http://www.swebok.org).
Las fuentes de informacin para la identificacin de las reas de conocimiento han sido los ndices de textos genricos sobre la Ingeniera del Software, los curricula para licenciatura y postgrado en Ingeniera de Software, y los criterios de admisin que se utilizan en el postgrado. Todos estos datos se han organizado siguiendo el estndar ISO/IEC 12207.
El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio ms relevante y como la referencia de ms autoridad en toda la comunidad informtica para la acotacin y descripcin de los conocimientos que configuran la Ingeniera del software.
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
15
SWEBOK
SWEBOK da el primer paso necesario para constituir a la Ingeniera del Software como profesin: la delimitacin del cuerpo de conocimiento que comprende la profesin. Sin esta delimitacin no es posible validar de forma universal exmenes de licenciatura, no es posible la preparacin para acceder a la profesin, y no hay un consenso sobre el contenido de su currculo. El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento que deben conocer los ingenieros del software, y en su desarrollo ha agrupado este conocimiento en 10 reas
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.
16
17
Define el QU, no el CMO. Dice cules son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y operacin de los sistemas de software, asentando un marco estndar de referencia internacional, pero no se ocupa ni prescribe tcnicas especficas.
El estndar sirve de referencia desde dos perspectivas diferentes: Para la adquisicin de sistemas y servicios de software. Para el suministro, desarrollo, mantenimiento y operacin de productos de software.
El estndar no cubre el desarrollo de productos de software para distribucin comercial masiva (productos en caja). No se trata de un estndar de certificacin, tipo ISO 9000, sino de un estndar para la normalizacin.
18
6.4 Verificacin 6.5 Validacin 6.6 Reuniones 6.7 Auditora 6.8 Resolucin de problemas
7. Procesos organizacionales
7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin 19
ISO 12207
ISO 1227 define los procesos que componen el ciclo de vida del software
Tarea n
Proceso N Actividad n
Ciclo de vida
Concepto Retirada
Tarea 1
Tarea 2
Tarea n
20
ISO 12207
PROCESO
TAREA 1
TAREA X
TAREA 1
La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de mejora PDCA Plan Do Chek Act (Planificacin, ejecucin, medicin y mejora)
INICIO
PLAN
Tareas, agenda, asignaciones
ACT
Problemas y acciones correctivas
PROCESO
DO
Ejecicin de planes y tareas
CHECK
Evaluacin y medicin
FIN
21
INGENIERA DE SISTEMAS
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
Sistema
Sistema de Salida
INGENIERA DE SISTEMAS
Sistema
conjunto de elementos de hardware, software, personas, procedimientos, herramientas y otros factores organizativos, organizados para llevar a cabo un objetivo comn.
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.
23
INGENIERA DE SISTEMAS
Algunas definiciones
Ingeniera de sistemas comprende la funcin de gestionar todo el esfuerzo de desarrollo para conseguir un balance ptimo entre todos los elementos del sistema. Es el proceso que transforma la necesidad operacional en la descripcin de los parmetros del sistema, e integra esos parmetros para mejorar la eficiencia general del sistema. 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.
24
INGENIERA DE SISTEMAS
Funciones de la Ingeniera de sistemas
Definicin del problema: Determinacin de las expectativas hacia el producto, necesidades y restricciones obtenidas y analizadas en los requisitos del sistema. Trabaja cerca del cliente para establecer las necesidades operacionales. 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. Evaluacin del producto: Determinar la calidad y cantidad de los productos elaborados, a travs de evaluaciones, pruebas, anlisis, inspecciones
25
INGENIERA DE SISTEMAS
Ingeniera de sistemas Gestin de proyectos Ingeniera del Soft.
Gestin de proyectos
Ingeniera de sistemas
Definicin del problema Anlisis de la solucin Planificacin de procesos Control de procesos Evaluacin del producto
Diseo del software Codificacin Pruebas unitarias Integracin del subsistema de software
26
INGENIERA DE SISTEMAS
Ingeniera de sistemas Ingeniera de sistemas de software Ingeniera del software
28
Introduccin
En este tema se tratan los siguientes conceptos:
Ciclo de vida del software. Procesos del ciclo de vida. Modelos de ciclo de vida.
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.
29
30
VALIDACIN
Actividades empleadas para validar el producto.
31
32
Procesos organizacionales
El estndar 12207 identifica los procesos que deben realizarse en el contexto de la organizacin que va a ejecutar el proyecto. Normalmente estos procesos se aplican de forma comn sobre mltiples proyectos. De hecho las organizaciones ms maduras los identifican e institucionalizan. GESTIN Describe las actividades de gestin de la organizacin, incluyendo tambin la gestin de proyectos. INFRAESTRUCTURA Actividades necesarias para que puedan realizarse otros procesos del ciclo de vida. Incluye entre otros el capital y el personal. MEJORA Actividades realizadas para mejorar la capacidad del resto de procesos. FORMACIN
E1
33
contrato emplea ROL SUMINISTRO emplea ROL OPERACIN emplea emplea emplea
Suministrador
PROCESO DE SUMINISTRO
Operador Usuario
PROCESO DE OPERACIN
usa
ROL INGENIERA
Desarrollador Mantenedor
PROCESO DE DESARROLLO
emplea
ROL SOPORTE
ROL ORGANIZACIONAL
Gestor
Gestin
Infraestructura
Mejora
Formacin
PROCESOS DE SOPORTE 34
Adquiriente
PROCESO DE ADQUISICIN
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.
La aplicacin de los procesos, tanto en el desarrollo como en el posterior mantenimiento y operacin del software, se dibuja a travs de unos patrones fijos que configuran el esquema de mapa de situacin, relacin y continuidad entre los diferentes procesos, actividades y tareas. En la etapa de desarrollo los patrones bsicos son: Desarrollo en cascada. (o variante secuencial) Desarrollo en espiral. Una vez desarrollada la primera versin, el ciclo de vida del sistema discurre en cada momento segn uno de los siguientes patrones. Desarrollo incremental del sistema. Desarrollo evolutivo del sistema. Sobre estos patrones bsicos, en las diferentes etapas del ciclo de vida pueden intervenir como modificadores los siguientes factores: Prototipado. Concurrencia. Componentes comerciales y reutilizacin. generando la riqueza de modelos y sub-modelos de patrones que algunos textos clasifican de forma lineal y agrupada como modelos de ciclos de vida
35
MODIFICADORES
PROTOTIPADO
CONCURRENCIA
36
Requisitos Diseo
Codificacin
Pruebas
37
Desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operacin no plantea riesgos. Sistemas pequeos, sin previsin de evolucin a corto plazo.
El modelo prcticamente idntico, que evita esta rigidez es el de cascada, que se expone a continuacin.
P1
38
Requisitos Diseo
Codificacin
Pruebas
P2
39
Requisitos Diseo
Codificacin
Pruebas
40
Desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operacin no plantean riesgos. Sistemas pequeos, sin previsin de evolucin a corto plazo.
[1] Algunos textos llaman cascada al modelo lineal, y cascada modificada al modelo de cascada
41
ANLISIS DE RIESGOS
ANLISIS DE RIESGOS
ANLISIS DE RIESGOS
SIMULACIONES, MODELOS REQUISITOS PLAN CICLO DESARROLLO DESCRIPCIN DE SISTEMA REQUISITOS DE SOFTWARE DISEO DEL SOFTWARE DISEO DETALLADO
PLAN DE DESARROLLO
VALIDACIN DE REQUISITOS
CODIFICACI N
VERIFICACIN
IMPLEMENTACIN
42
P3
44
Sub-sistema
Diseo
Codificacin
Pruebas
Integracin
Operacin Mantenim.
Sub-sistema
SISTEMA
Diseo
Codificacin
Pruebas
El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo (en cascada en la representacin grfica siguiente). Las ventajas que ofrece son:
El usuario dispone de pequeos subsistemas operativos que ayudan a perfilar mejor las necesidades reales del sistema en su conjunto. El modelo produce entregas parciales en periodos cortos de tiempo, comparados con el tiempo necesario para la construccin del sistema en su conjunto, y permite la incorporacin de nuevos requisitos que pueden no estar disponibles o no ser conocidos al iniciar el desarrollo.
45
P4
46
Diseo
Codificacin
Pruebas
Integracin
Operacin Mantenim.
Sistema
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin Mantenim.
Sistema
Requisitos
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.
47
Desconocimiento inicial de todas las necesidades operativas que sern precisas, generalmente por tratarse del desarrollo de un sistema que operar en un entorno nuevo sin experiencia previa. Necesidad de que el sistema entre en operacin en tiempos inferiores a los que seran necesarios para disearlo y elaborarlo de forma exhaustiva. Necesidad de desarrollar sistemas en entornos cambiantes (sujetos a normas legislativas, mejora continua del producto para hacer frente a desarrollos de la competencia, etc.).
Aunque en su concepcin inicial contempla desarrollos internos en cascada, tambin podra plantearse, por ejemplo, un ciclo de vida evolutivo con desarrollos internos en espiral.
P5
P6
48
Ligeros: dibujos de pantallas de interfaz con simulacin de funcionamiento por enlaces a otros dibujos 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:
Como puede parecer que se ha desarrollado un interfaz de usuario sofisticado y elaborado, el cliente puede llegar a pensar que ya se ha realizado el grueso del trabajo. Si se trata de un prototipo operativo, puede empezar a crecer al margen de la planificacin, ms all de los objetivos previstos, desbordando agendas y recursos. Si se trata de un prototipo ligero desarrollado fuera del departamento de desarrollo (ej. Marketing), puede mostrar al cliente funcionalidades no implementables. El prototipo puede llegar a ofrecer funcionalidades superiores a lo conseguible, por estar construido en un entorno diferente al de desarrollo, o no incluir toda la funcionalidad del sistema.
49
ndice de concurrencia. Se produce en un grado reducido, generando un escaso flujo de modificaciones; o por el contrario se da de forma intensiva generando situaciones problemticas en la planificacin o en la distribucin del trabajo. Gestin de la concurrencia. La concurrencia puede producirse en un proyecto de forma planificada o inducida por las circunstancias. En ambos casos resulta muy importante la labor de gestin del proyecto para tratarla de forma adecuada con el mayor beneficio, o el menor perjuicio a los planes y la calidad del proyecto.
50
Presin competitiva para reducir agendas y costes. Incremento de la complejidad y estandarizacin de los entornos de operacin. Aparicin de las lneas de produccin en las que se desarrollan mltiples sistemas de software re-utilizando partes de diseo y componentes.
El uso de componentes o partes ya desarrolladas tienen implicaciones en el ciclo de desarrollo, diferentes segn las circunstancias. As por ejemplo, si gran parte del sistema consta de componentes ya desarrollados y probados, el periodo de pruebas se acortar sustancialmente. Si un proyecto va a delegar funcionalidades crticas en un componente comercial, que no ha empleado previamente la organizacin desarrolladora, es posible que incorpore en su ciclo de desarrollo una fase de pruebas de ese componente, antes del diseo, para obtener la certeza previa de que el componente se comporta como se espera.
51
Anlisis de las circunstancias ambientales del proyecto. 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. Mapeo de las actividades sobre el modelo. Desarrollo del plan para la gestin del ciclo de vida del proyecto.
Posibilidad de descomposicin del sistema en subsistemas de software, con agendas y entregas diferenciadas.
Estabilidad esperada de los requisitos. Novedad del proceso o procesos gestionados por el sistema en el entorno del cliente. Criticidad de las agendas y presupuestos. Grado de complejidad del interfaz de operacin, criticidad de la usuabilidad. Grado de conocimiento y familiaridad con el entorno de desarrollo, componentes externos
E2
empleados, etc.
52
53
Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseado o codificado que est un programa, si se ha analizado y especificado pobremente, decepcionar al usuario y desprestigiar al que lo ha desarrollado.
Roger S. Pressman Ingeniera del Software Mc Graw Hill 1995
La parte ms difcil en la construccin de sistemas software es decidir precisamente qu construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los requerimientos tcnicos detallados, incluyendo todas las interfaces con humanos, mquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto el resultado final si se realiza de forma errnea. Ninguna otra parte es tan difcil de rectificar posteriormente.
Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1995.
54
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
Sin desviaciones en las fechas previstas. Sin desviaciones en los costes estimados. Que el producto final cubra las expectativas y necesidades del cliente. Que funcione correctamente.
55
TOTAL: 52%
56
1X 1X
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo detallado
construccin
Produccin
Estimacin
Planificacin
Diseo
Construccin
V&V
E1
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.
58
Requisitos innecesarios
Requisitos mnimos (insuficientes)
59
60
61
62
63
64
Beneficios
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. Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.) Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento. Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de partes ya desarrolladas, etc.
65
E2
Ingeniera de requisitos
Conceptos clave.
Obtencin
Especificacin
Anlisis
Gestin
Validacin y verificacin
66
Ingeniera de requisitos
Ingeniera de requisitos
Procesos
mbitos
Obtencin
Anlisis
Especif.
V&V
Gestin
Sistema
Software
La ingeniera del software y la ingeniera de requisitos son ingenieras muy recientes. En la actualidad acaba de cerrarse la versin 1.0 de SWEBOK, que constituye el esfuerzo ms serio y consensuado hasta la fecha para definir las reas de conocimiento que la integran. En este estado de cosas no es extrao encontrar que, diferentes autores clasifican o presentan los conceptos clave de forma diferente, si bien los conceptos bsicos siempre son los mismos: Obtencin, anlisis, especificacin, validacin y verificacin y gestin. As por ejemplo, Karl Wiegers centra su inters clasificatorio en la diferencia entre el desarrollo de lo requisitos y su posterior gestin. SWEBOK plantea una representacin esquemtica plana (no distingue entre gestin y desarrollo) y centra su inters slo en los requisitos del software. IEEE carga el peso de la clasificacin en la diferencia entre requisitos del sistema y del software. Nuestro punto de vista contempla las 5 reas clave, que se trabajan tanto en el mbito de los requisitos del sistema como en los requisitos del software.
67
Ingeniera de requisitos
Obtener informacin Registro y contrastacin Controlar las modificaciones
Obtener informacin
OBTENCIN
ANLISIS
ESPECIFICACIN
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.
68
Ingeniera de requisitos
Especificacin
Cuando ya se conoce el entorno del cliente y sus necesidades, es necesario plasmarlas en forma de requisitos en los documentos que sirven de base de entendimiento y acuerdo entre cliente y desarrollador, y que establecern tanto la gua desarrollo como los criterios de validacin del producto final. Documentar los requisitos es la condicin ms importante para gestionarlos correctamente. Verificacin y validacin Los requisitos deben ser formal y tcnicamente correctos (verificacin), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validacin). El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico que los diferencia es que verificacin se refiere a la calidad formal, en este caso de los documentos de requisitos (no son ambiguos, no son incompletos, son posibles, verificables, etc.) y validacin comprende la adecuacin en el entorno de produccin, en el caso de la documentacin de requisitos, la conformidad por parte del cliente de que reflejan lo que l quiere. Gestin Los requisitos cambiarn durante el desarrollo del sistema, y es necesario poder trazar en cada cambio todas las partes afectadas, as como poder medir el impacto que cada modificacin implica en la planificacin del proyecto.
69
mbitos
Software Requisitos del software SRS
Descripcin
Definicin:
del sistema
Documento, tambin denominado ConOps y normalizado en el estndar IEEE Std. 1362-1998. Documento dirigido a los usuarios, que describe las caractersticas de un sistema propuesto, desde el punto de vista del usuario. La Descripcin del Sistema es el medio de comunicacin que recoge la visin general, cualitativa y cuantitativa de las caractersticas del sistema; compartido por la parte cliente y desarrolladora.
70
Propsito
El desarrollo de la Descripcin del Sistema proporciona una actividad de anlisis y un documento que tiene la funcin de enlace entre las necesidades del usuario, y las especificaciones tcnicas del desarrollo. La Descripcin del sistema proporciona:
La descripcin de las necesidades operacionales del usuario sin entrar en detalles tcnicos. La documentacin de las caractersticas del sistema y las necesidades operacionales del usuario, de forma que puedan ser verificadas sin requerir conocimientos tcnicos. 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. El documento en el que, comprador y suministrador, reflejan las posibles estrategias de solucin, y las restricciones que deben respetarse.
71
Propsito
Ofrece un formato y contenidos para la confeccin de las descripciones de sistema en los desarrollos y modificaciones de sistemas intensivos de software. El estndar no especifica tcnicas exactas, sino que proporciona las lneas generales que deben respetarse. No es por tanto un modelo final, sino una gua de referencia sobre la que cada organizacin debe desarrollar sus propias prcticas y procedimientos para preparar y actualizar su documentacin con las descripciones de los sistemas.
73
SISTEMA
EVOLUCIN PREVISTA
74
Funcionalidad. Descripcin de lo que el software debe hacer. Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de hardware, o con otros sistemas (software y hardware). Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta, tiempos de recuperacin, tiempos de determinadas funciones. Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad, etc. Restricciones de diseo en la implementacin. Indicacin de las restricciones que puedan afectar por la necesidad de sometimiento a estndares, lenguajes, polticas de integridad de bases de datos, lmites de recursos disponibles para el desarrollo, sistema operativo, etc.
Las especificaciones de requisitos de software deben evitar incluir requisitos de diseo o de proyecto.
75
QU, no el CMO
Una descripcin de requisitos del sistema limita las alternativas de diseo posibles, pero esto no significa que deba decidir cul debe ser la solucin de diseo del sistema. La especificacin de requisitos de software determina qu funcionalidades deben realizarse, qu datos deben generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe centrarse en los servicios que se realizarn, pero, en general, no debe especificar elementos de diseo como los siguientes:
Divisin del software en mdulos. Distribucin de funciones en los mdulos. Descripcin del flujo de informacin entre los mdulos. Eleccin de las estructuras de datos.
Deben centrarse nicamente en el punto de vista externo del sistema, y no en el funcionamiento interno
76
Mantener ciertas funciones en mdulos separados. Permitir o limitar la comunicacin entre determinadas reas del programa. Comprobar la integridad de los datos en variables crticas.
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.
del proyecto
La especificacin de requisitos de software se centra en el producto, no en el proceso de produccin del producto. Los requisitos de proyecto representan los trminos contractuales entre el cliente y el suministrador, y no deben incluirse en la SRS. Normalmente incluyen informacin relativa a los procesos de adquisicin o de suministro:
E3
Coste. Agenda de entregas. Procedimientos de seguimiento. Mtodos de desarrollo del software. Control de calidad. Criterios de validacin y verificacin. Procedimientos de aceptacin
77
SRS
5.1 Adquisicin
5.2 Suministro
5.2 Suministro
5.4 Operacin
5.4 Operacin
5.3 Desarrollo
5.3 Desarrollo
5.5 Mantenimiento
5.5 Mantenimiento
78
Conceptos clave
Independientemente de las tcnicas o procesos que se apliquen para realizar las diferentes tareas relacionadas con el rea de requisitos, son cinco los objetivos que hay que cubrir:
ANALIZAR EL PROBLEMA COMPRENDER LAS NECESIDADES DE LOS USUARIOS DEFINIR EL SISTEMA DESARROLLAR LOS REQUISITOS DEL SOFTWARE GESTIONAR LOS REQUISITOS
Analizar el problema
Definir el sistema
80
Conceptos clave
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.Identificacin del problema. Identificacin de las partes implicadas. Delimitacin de la solucin. Identificacin de las restricciones.
81
Conceptos clave
Comprender
La obtencin de los requisitos es sin duda la parte ms difcil del desarrollo de un sistema, y en la actualidad es la principal causa de problemas. En el apartado Obtencin de requisitos desarrolla de forma exclusiva este punto.
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).
82
Conceptos clave
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:
Descripcin del sistema o de la situacin actual. Descripcin de las necesidades que han motivado el desarrollo de un sistema nuevo, o de la necesidad de modificar el actual. Modos de operacin propuestos para el nuevo sistema. Tipos de usuarios y caractersticas. Funcionalidades propuestas. Restricciones que debe respetar el sistema.
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.).
83
Conceptos clave
Los requisitos del software tambin deben verificarse y validarse, para garantizar, por un lado, que son formalmente correctos, y por otro que dan respuesta a las necesidades de todas las partes implicadas.
84
Conceptos clave
Requisitos
Diseo
Codificacin
Integracin/ pruebas 85
Conceptos clave
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
Conceptos clave
Debe provenir de una fuente autorizada. Debe alcanzar el consenso de las partes implicadas. Obliga a un anlisis del impacto. Implica una revisin de la planificacin del proyecto. Debe informarse al cliente de los efectos sobre la planificacin y recursos necesarios, para obtener su aprobacin. Debe incorporarse formalmente a la documentacin de requisitos
E5
87
S pero no exactamente as. Vaya!, pues esto no debera ser as. Ya est todo? Usuarios contra desarrolladores
88
Evitar quedarse con las primeras descripciones genricas. No dar nada por supuesto. Evitar las ambigedades. Conocer el entorno y las necesidades del cliente. Dedicar esfuerzo y tiempo para la obtencin de requisitos, adecuado al tamao y complejidad del sistema. 89
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.
90
Este sndrome tambin es inherente al desarrollo de sistemas de software, y con l resulta fcil deducir las funciones y competencias que debe cubrir el ingeniero de requisitos, as como de ser persona con ojo clnico y registro amplio de recursos.
Si se enfrenta a procesos poco maduros deber involucrarse en mayor medida en el entorno organizacional del cliente y aportar en su trabajo parte ms propia de consultora que de analista de requisitos.
91
92
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.
93
95
Problemas
97
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
98
ESCENARIOS
TCNICAS
PROTOTIPOS
Prototipos rpidos prototipos evolutivos
OBSERVACIN
E6
99
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.
100
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:
101
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:
En la libertad de los analistas al realizar el diseo del sistema. En los procesos o formas de trabajar que se emplearn en el desarrollo del sistema.
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...
102
Problemas
Para nosotros la base terica de clasificacin es un marco de referencia con la definicin de los criterios de clasificacin. En la relacin de requisitos de un sistema, no resulta interesante entrar en anlisis puristas para determinar si cada requisito lo es de interfaz, funcional, etc. La diferencia entre: El sistema comprueba la autentificacin y autorizacin del usuario y le da acceso a una pantalla con el men general o en caso de error le redirige a la pantalla de usuario y contrasea otra vez Y: RS. 3 El sistema slo permite el acceso al men principal a usuarios autorizados. RT.3.1 El sistema identifica al usuario solicitando a travs de la pantalla de operacin su nombre y contrasea de acceso. En el segundo caso, el equipo de trabajo sabe que debe descartar opciones de identificacin a travs de tarjetas, o dispositivos biomtricos, o cualquier otra opcin posible. Se trata por tanto de conocer y comprender el concepto de restriccin, para aplicarlas slo cuando son necesarias, dejando as el mayor margen posible de libertad para el diseo de la solucin de software.
103
Calidad de la documentacin
de requisitos
Especificacin
Posibles
Necesarios Priorizados Concretos Verificables
Completa
Correcta Consistente Modificable Trazable
104
Necesarios
Un requisito es necesario si es algo:
que el cliente realmente necesita requerido para la conformidad con un requisito requerido para la conformidad con un interfaz,
externo o estndar.
Para evitar requisitos innecesarios, el cliente debe valorar cada funcionalidad y como afectar al sistema si esta o no.
Alto
Coste
Alto Valor
105
Los clientes tengan una consideracin ms adecuada de cada requisito, y a menudo clarifica asunciones que pudieran estar ocultas. Que los desarrolladores tomen decisiones de diseo correctas y dediquen niveles de esfuerzo apropiado a las diferentes partes del producto. Que el gestor del proyecto pueda establecer prioridades de ejecucin, y disponga de informacin adicional en caso de problemas de agenda.
106
Punto ptimo: Mayor grado de comprensin con la menor ambigedad Modos eficaces de evitar la ambigedad:
Comprensin
Punto ptimo
Ambigedad
Inspecciones formales de los documentos de requisitos. Escritura de casos de prueba Elaboracin de casos de uso. Elaboracin de diagramas.
107
108
Propiedades de la documentacin
Completa
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
109
Propiedades de la documentacin
Completos Conocemos No Conocemos
Entrevistas y revisiones
A Entendemos
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.
Prototipado
C No Entendemos
Este bloque pertenece a los requisitos que sabemos que son aplicables al problema pero que no entendemos
D
Este bloque pertenece a los requisitos que no conocemos y tampoco sabemos que no conocemos
110
Propiedades de la documentacin
Correcta
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
Necesidades
del Usuario
A B C
Requisitos Especificados 111
B
Revisin y aprobacin
Requisitos
Correctos
Propiedades de la documentacin
Consistente
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:
Conflictos
Objetos
Lgicos
Trminos
RF 10 Informe A cierre de caja RF 50 Informe A cierre diario de operaciones
C=A+B C=A*B
112
Propiedades de la documentacin
Modificable
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.
113
Propiedades de la documentacin
Trazable
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
114
Conclusiones OBJETIVO
Desarrollar software
115
Conclusiones
MEDIOS
FIN
Conseguir el objetivo
116
117
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
118
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
119
Diseo
120
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
121
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.
122
Descomposicin
de la complejidad
Requisitos
Etc.
124
y del desarrollo
125
Los borradores de manuales para mantenimiento y administracin 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
126
127
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.
128
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).
129
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.
130
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
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.
131
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).
132
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.)
Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de actividad Diagrama de colaboracin Diagrama de estados
133
134
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
135
Prcticas recomendadas
Trazabilidad
del diseo
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
QU
CMO
136
137
Ingeniero de Software decide: 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.
Gestor de Proyecto 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. 138
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.
139
5.-Documentacin de usuario
140
Documentacin de usuario
Conceptos 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.
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.
Documentacin de usuario
Conceptos 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
142
Documentacin de usuario
Conceptos 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).
Referencia
143
Documentacin de usuario
Desarrollo de la documentacin
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.
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.
144
Documentacin de usuario
Desarrollo de la 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
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.
[1] Brockmann, R.J. (1990). Writing Better Computer Documentation: From Paper to Hypertext
145
Documentacin de usuario
Desarrollo de la documentacin
Clasificacin de usuarios
Nivel de sofisticacin informtica Caractersticas
Inexperto[1]
Muy poca o ninguna experiencia con ordenadores Tratan volmenes reducidos de informacin No confan en la informtica Trabajadores concretos
Principiante
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
Intermedio
Experto
Intermitente
146
Documentacin de usuario
E2
147
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.
148
Documentacin de usuario
Ttulo del documento Versin del documento y fecha de publicacin Nombre del producto de software y versin Organizacin que edita el documento
E3
Audiencia Alcance y propsito del documento Descripcin general del propsito y funcionalidad del software, as como del entorno de operacin
149
Documentacin de usuario
!
Contenido
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
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.
150
Documentacin de usuario
Informacin identificativa
Tabla de contenidos
S, en documentos de ms de 8 pginas
Lista de imgenes
Opcional
Introduccin
151
Documentacin de usuario
Procedimientos
S, en modo formativo
S, en modo referencia
Glosario
Opcional
ndice
S, en documentos de ms de 40 pginas
Capacidad de bsqueda
Documentacin de usuario
Correccin
Los textos deben ser lxica, ortogrfica y sintcticamente correctos.
E1
154
Verificacin y validacin
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.
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
155
Verificacin y validacin
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:
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.
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
156
Verificacin y validacin
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:
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: 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.
157
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
158
Verificacin y validacin
6.4 Verificacin 6.5 Validacin 6.6 Reuniones 6.7 Auditora 6.8 Resolucin de problemas
7. Procesos organizacionales
7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin 159
Verificacin y validacin
160
Verificacin y validacin
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.
161
Verificacin y validacin
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
162
Verificacin y validacin
E4
163
Verificacin y validacin
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?
Anlisis de criticidad
Anlisis de riesgos (risk analysis)
164
Verificacin y validacin
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).
165
Verificacin y validacin
P2 P3
166
Verificacin y validacin
Propios del desarrollo de software
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.
167
Verificacin y validacin
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.
Gestin de proyecto
(Gestin de riesgos)
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.
[1] En los proyectos de software se suelen dar con mayor intensidad los riestos tpicos indicados.
168
Verificacin y validacin
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.
NIVEL DE INTEGRIDAD
VALIDACIN
y
VERIFICACIN
Verificacin y validacin
El modelo del estndar resulta vlido, pero cualquier modelo, adecuado a las circunstancias del sistema y del entorno de desarrollo, puede resultar igualmente vlido.
170
Verificacin y validacin
P4
P5
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.
171
Verificacin y validacin
Tipos de independencia
reas
Gestin
I
Tcnica
I
Financiera
I
CLSICA
MODIFICADA
INTERNA DOMSTICA
I: Independencia rigurosa
I-R
I-R I-M
I
I-R I-M
I
I-R I-M
172
Verificacin y validacin
173
Verificacin y validacin
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:
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.
174
Verificacin y validacin
175
Verificacin y validacin
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.
176
Verificacin y validacin
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 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.
177
Verificacin y validacin
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.
178
Verificacin y validacin
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
179
7.- Mantenimiento
E1
180
Mantenimiento
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
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.
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
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.
183
Mantenimiento
Tipos de 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
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.
184
Mantenimiento
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 preestablecidos, 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:
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.
185
Mantenimiento
Diseo
Cdigo
Datos
Documentacin
186
Mantenimiento
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
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
187
Mantenimiento
188
Mantenimiento
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
189
Mantenimiento
Entradas
Procesos
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:
Mtricas
Peticin de cambio
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
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.
190
Mantenimiento
Entradas
Procesos
Control
Realizar revisiones tcnicas y revisar
Salidas
Mtricas
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)
Estrategia
de
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
Modificaciones de requisitos % de errores en la documentacin Esfuerzo por rea (SQA, SE, etc.) Tiempo empleado % de errores generados por prioridad y tipo.
Mantenimiento
Entradas
Procesos
Control
Salidas
Revisados: Lista de modificacines Anlisis detallado Plan de implementacin actualizado Lnea base de diseo Planes de pruebas
Mtricas
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)
Complejidad del software Cambios diseo Esfuerzo por rea Cambios en planes de prueba Nmero de mdulos N lneas de cdigo aadidas o modificadas
192
Mantenimiento
Entradas
Procesos
Control
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
Resultados
de la fase de diseo. Cdigo fuente y bases de datos del sistema. Documentacin del sistema y del proyecto.
Codificacin y
Revisiones de cdigo Verificacin de la integracin. Verificacin de modificaciones y actualizaciones de documentacin. Gestin de riesgos y supervisin durante las pruebas
193
Mantenimiento
Entradas
Procesos
Control
Salidas
Revisados: Sistema revisado. Informes de pruebas.
Mtricas
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
194
Mantenimiento
Entradas
Procesos
Control
Salidas
Mtricas
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.
195
Mantenimiento
Entradas
Procesos
Control
Salidas
Mtricas
El sistema
Auditora fsica de
E3
la configuracin. Notificacin a la comunidad de usuarios. Desarrollo y archivo de una copia de seguridad del nuevo sistema. Instalacin y formacin de usuarios.
196
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:
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.
197
Mantenimiento
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:
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.
198
Mantenimiento
Mantenibilidad
Reingeniera
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.
Analizar el sistema y decidir si conviene rehacerlo de nuevo, o por el contrario resulta ms apropiado aplicar tcnicas de reingeniera.
199
Mantenimiento
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 inversa
Reestructuracin de datos
Reestructuracin de cdigo
Reestructuracin de documentos
Ingeniera progresiva
200
Mantenimiento
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:
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
201
Mantenimiento
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:
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
202
Mantenimiento
203
Mantenimiento
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 204
Mantenimiento
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
205
206
Gestin de la configuracin
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
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.
207
Gestin de la configuracin
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
Desarrollo
Mantenimiento
Ciclo de vida
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
208
Gestin de la configuracin
Conceptos clave
Lnea base
Peticin de cambio
Librera
209
Gestin de la configuracin
Conceptos 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:
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.
210
Gestin de la configuracin
Conceptos 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.
Producto: Productos intermedios o finales desarrollados durante el proyecto.
Categoras
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.) 211
E1
Gestin de la configuracin
Conceptos 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.
212
Gestin de la configuracin
Conceptos 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.
213
Gestin de la configuracin
Conceptos 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.
214
Gestin de la configuracin
Conceptos 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 215
Gestin de la configuracin
Identificacin de la configuracin
Control de la configuracin
Auditoras y revisiones
216
Gestin de la configuracin
Identificacin
Lneas base
Actividades
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:
Nomenclatura y adquisicin
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.
217
Gestin de la configuracin
Garantiza
para cada cambio se evala y considera el impacto en el proyecto. slo se implementan los cambios aprobados. todos los cambios aprobados se implementan. las lneas base se mantienen controladas y actualizadas.
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).
Aprobacin o rechazo
Comunicacin formal
Implementacin EVALUACIN
Validacin y evaluacin
Check-out lnea base Ejecucin de cambios Pruebas y verificacin Aprobacin de la ejecucin Chech-in lnea base
218
Gestin de la configuracin
Registra
Versin inicial aprobada de los elementos de la configuracin. Estado de las peticiones de cambio. Estado de implantacin de los cambios aprobados.
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.
219
Gestin de la configuracin
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.
Las gestiones de configuracin del proyecto de software y del subcontratado deben comunicarse y gestionar las implicaciones de cambio derivadas de uno a otro. 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.
220