Академический Документы
Профессиональный Документы
Культура Документы
Agosto 2010 Agosto 2010 Vctor Andrs Ochoa Correa Vctor Andrs Ochoa Correa
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
Introduccin Ingeniera del Software Desarrollo del hardware Desarrollo del hardware
La aparicin de componentes que cada dos aos doblan la capacidad de sus antecesores[1] nos ha rodeado en menos de cuatro dcadas de mquinas capaces de procesar miles de millones de operaciones por segundo (MTOPS). En 1946 ENIAC ocupaba una superficie de 160 m2, pesaba 30 toneladas, y ofreca una capacidad de proceso de 30.000 instrucciones por segundo. En 2002 El microprocesador Pentium IV a 2 Ghz ocupa una superficie de 217 mm2 y tiene una capacidad de proceso de 5.300 MTOPS (Millions of theoretical operations per second) En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware. De ellos, tres son consecuencia de la ley de Moore: Incremento constante de la capacidad de operacin, miniaturizacin y reduccin de costes para la produccin de hardware; y a stos se ha sumado en la ltima dcada el avance de las comunicaciones entre sistemas. La consecuencia es obvia: ordenadores potentes, que pueden llevarse en el bolsillo y en permanente conexin con grandes sistemas, redes de comunicacin pblicas, sistemas de localizacin GPS, etc. Estas cuatro lneas de avance han extendido el mbito de aplicacin del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Los ordenadores ya no son mquinas tiles slo para la banca o el ejrcito. Se encuentran presentes en todos los mbitos, por su capacidad de proceso y de comunicacin pueden ofrecer soluciones a sistemas cada vez ms complejos. Este es el escenario creado por la industria del hardware, y que en las tres ltimas dcadas ha implicado a los desarrolladores de software en retos a los que no han sabido responder con solvencia.
[1] Ley de Moore
Introduccin Ingeniera del Software Desarrollo del hardware Desarrollo del hardware
Desde 1965 la Ley de Moore rige la evolucin de los microprocesadores
100.000.000 Pentium IV Pentium III 10.000.000 Pentium Transistores 486 DX 1.000.000 386 286 100.000 8086 10.000 8080 4004 8008 1970 1975 1980 1985 1990 1995 2000 Pentium II
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
Introduccin Ingeniera del Software Crisis de software Crisis de software Proyectos para el desarrollo de sistemas de software
Fracaso 2004 2000 1998 1995 1994 31% 19% 23% 28% 40% Problemtico 53% 49% 46% 33% 53% xito 29% 28% 26% 27% 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
Introduccin Ingeniera del Software Crisis del software Crisis del software
Este problema se identific por primera vez en 1968, ao en el que la organizacin NATO desarroll la primera conferencia sobre desarrollo de software, y en la que se acuaron los trminos crisis del software para definir a los problemas que surgan en el desarrollo de sistemas de software, e ingeniera del software para describir el conjunto de conocimientos que existan en aquel estado inicial. Algunas referencias tiles para comprender cules eran los conocimientos estables para el desarrollo de software en 1968 son:
En 1962 se public el primer algoritmo para bsquedas binarias. C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la eliminacin de GoTo y la creacin de la programacin estructurada. 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
Introduccin Ingeniera del Software Ingeniera del software Ingeniera del software
Definicin original: Definici Establecimiento y uso de principios de ingeniera para obtener software econmico que trabaje de forma eficiente en mquinas reales.
Fritz Baver, 1968 (conferencia NATO)
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
Introduccin Ingeniera del Software Ingeniera del software Ingeniera del software
Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informtica de las universidades, y por organismos de estandarizacin (SEI, IEEE, ISO) para identificar las causas del problema y definir pautas estndar para la produccin y mantenimiento del software. Los esfuerzos se han encaminado en tres direcciones principales. 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
Los estndares son tiles porque: Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de software. Engloban los conocimientos. Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas.
10
Introduccin Ingeniera del Software Principales organizaciones de estandarizacin Principales organizaciones de estandarizacin
Desde la identificacin del fenmeno crisis del software, han sido muchas las organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores garantas de xito. Han sido muchos los departamentos de universidades, organismos de normalizacin o investigacin nacionales o internacionales, sociedades de profesionales, departamentos de defensa, departamentos de calidad y procesos de empresas los que han ido generando normas y estndares. Este compendio considera como entidades de mayor reconocimiento internacional, por sus trabajos y esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a: ISO, IEEE- Computer Society y SEI.
11
Introduccin Ingeniera del Software Principales organizaciones de estandarizacin Principales organizaciones de estandarizacin
ISO 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: ISO/IEC 12207 ISO/IEC TR 15504
SEI 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
Introduccin Ingeniera del Software Principales organizaciones de estandarizacin Principales organizaciones de estandarizacin
IEEE Computer Society IEEE Computer Society
IEEE Es el Instituto de Ingenieros en electricidad y electrnica (Institute of Electrical and Electronics Engineers). Su misin es preservar, investigar y promover la informacin de las tecnologas elctricas y electrnicas. Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) y el Instituto de Ingenieros de Radio (IRE). La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en la actualidad por ms de 100.000 miembros en todo el mundo. Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares. Estndares para la Ingeniera del Software IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software son:
IEEE IEEE IEEE IEEE IEEE Std. Std. Std. Std. Std. 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
Introduccin Ingeniera del Software Principales estndares y modelos Principales 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? 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
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
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
Introduccin Ingeniera del Software ISO 12207: Propsito ISO 12207: Propsito
Establecer un estndar para evitar una situacin de Torre de Babel en la gestin e ingeniera del software, proporcionando un marco y un lenguaje comn en la disciplina del software
Establece un marco comn para el ciclo de vida del software para Adquisicin, suministro, desarrollo, operacin y mantenimiento del software Gestionar, controlar y mejorar el marco Como base de referencia para el trabajo e intercambio entre organizaciones de software
17
Introduccin Ingeniera del Software ISO 12207: Propsito ISO 12207: Propsito
El estndar no prescribe: Que deba emplearse ningn tipo de documentacin especfica. Que deba emplearse un tipo especfico de ciclo de desarrollo. Mtodos concretos para el desarrollo, mantenimiento u operacin del software.
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
Introduccin Ingeniera del Software ISO 12207: Procesos ISO 12207: Procesos
5. Procesos primarios
5.1 Adquisicin 5.2 Suministro
6.- Procesos de soporte 6.6.1 Documentacin 6.2 Gestin de la configuracin 6.3 Control de calidad
7. Procesos organizacionales
7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin 19
Ciclo de vida
Concepto Retirada
20
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
DO
PROCESO
CHECK
Evaluacin y medicin
FIN
21
Qu es un sistema? 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
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
25
Ingeniera de sistemas Definicin del problema Anlisis de la solucin Planificacin de procesos Control de procesos Evaluacin del producto
Ingeniera del software Diseo del software Codificacin Pruebas unitarias Integracin del subsistema de software
26
28
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
Ciclo de vida del software Procesos primarios del ciclo de vida del software Procesos primarios del ciclo de vida del software
12207 define los siguientes procesos primarios en el ciclo de vida del software: ADQUISICIN Proceso global que sigue el adquiriente para obtener el producto. SUMINISTRO Proceso global que sigue el suministrador para proporcionar el producto. DESARROLLO Proceso empleado por el suministrador para el diseo, construccin y pruebas del producto. OPERACIN Proceso seguido por el operador en el da a da para el uso del producto. MANTENIMIENTO Proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio producto como en su entorno de operacin.
30
Ciclo de vida del software Procesos de soporte del ciclo de vida del software Procesos de soporte del ciclo de vida del software
El estndar 12207 identifica los procesos de soporte que pueden ser utilizados desde un proceso primario, o incluso desde otro proceso de soporte. Los procesos de soporte son: DOCUMENTACIN Actividades empleadas para registrar informacin especfica empleada por otros procesos. GESTIN DE LA CONFIGURACIN Actividades empleadas para mantener un registro de los productos generados en la ejecucin de los procesos. ASEGURAMIENTO DE LA CALIDAD Actividades empleadas para garantizar de forma objetiva que el producto y los procesos asociados son conformes a los requisitos documentados y a las planificaciones. VERIFICACIN Actividades empleadas para verificar el producto. VALIDACIN Actividades empleadas para validar el producto.
31
Ciclo de vida del software Procesos de soporte del ciclo de vida del software Procesos de soporte del ciclo de vida del software
REUNIONES DE REVISIN Reuniones empleadas por las dos partes para evaluar el estado del producto y de las actividades. AUDITORAS Actividades para determinar que el proyecto cumple con los requisitos, planes y contratos. RESOLUCIN DE PROBLEMAS Actividades para analizar y resolver problemas relativas al proyecto, sea cual sea su fuente y naturaleza.
32
E1
33
Ciclo de vida del software VISIN GENERAL DE LOS PROCESOS, RELACIONES Y ROLES VISIN GENERAL DE LOS PROCESOS, RELACIONES Y ROLES
ROL ADQUISICIN emplea
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 Modelos de ciclo de vida para el desarrollo Modelos de ciclo de vida para el desarrollo
Los conceptos bsicos de partida son los definidos y normalizados en el estndar 12207: 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
Ciclo de vida del software Modelos de ciclos de vida Modelos de ciclos de vida
MODIFICADORES
PROTOTIPADO
CONCURRENCIA
36
Ciclo de vida del software Modelos de ciclos de desarrollo Modelos de ciclos de desarrollo
Lineal o secuencial Lineal o secuencial
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y mantenimiento
37
Ciclo de vida del software Modelos de ciclo de desarrollo Modelos de ciclo de desarrollo
Lineal o secuencial Lineal o secuencial
Este modelo refleja un desarrollo marcado por la sucesin escalonada de las etapas que lo componen : requisitos, diseo, codificacin, pruebas e integracin. Es necesario terminar por completo cada etapa para pasar a la siguiente Este modelo, identificado ya a principios de la dcada de los 50, resulta muy rgido porque cada fase requiere como elemento de entrada el resultado completo de la anterior. Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchas veces resulta difcil poder disponer de requisitos completos o del diseo pormenorizado del sistema en las fases iniciales, creando una barrera que impide avanzar. Resulta apropiado para: 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
Ciclo de vida del software Modelos de ciclos de desarrollo Modelos de ciclos de desarrollo
Cascada Cascada
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y mantenimiento
P2
39
Ciclo de vida del software Modelos de ciclos de desarrollo Modelos de ciclos de desarrollo
Cascada Cascada
Requisitos
Diseo
Codificacin
Pruebas
Integracin
Operacin y mantenimiento
40
Ciclo de vida del software Modelos de ciclo de desarrollo Modelos de ciclo de desarrollo
Cascada[1] Cascada[1]
En 1970 Winston Royce defini flujos de retorno sobre el modelo secuencial, acuando as el modelo en cascada. El modelo en cascada refleja la necesidad impuesta por la realidad de retornar con frecuencia desde una fase hacia las anteriores con la informacin generada al avanzar el desarrollo. Las representaciones ms habituales de este modelo son las representadas en las dos figuras anteriores. La primera parece indicar que el retorno posible se da solamente entre una fase y la anterior, mientras que en la segunda se refleja mejor el hecho de que en cualquier fase puede surgir un retorno para modificar cualquiera de las anteriores. Este modelo, como el anterior, reconoce la importancia de disponer de unos requisitos y un diseo previo antes de comenzar con la codificacin del sistema, pero al mismo tiempo se enfrenta al hecho de que en la realidad la dificultad que supone disponer de documentacin elaborada de requisitos y diseo antes de empezar a codificar puede actuar como una barrera que bloquee el comienzo de la siguiente fase. Por estas razones el modelo no se ha hecho muy popular, y los equipos que lo aplican pueden caer en la tentacin de comenzar con el diseo o incluso con la codificacin, sin tener un conocimiento suficiente de los requisitos. Resulta apropiado para: 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
Ciclo de vida del software Modelos de ciclo de desarrollo Modelos de ciclo de desarrollo
Espiral Espiral
DETERMINAR OBJETIVOS, ALTERNATIVAS Y RESTRICCIONES COSTE ACUMULADO EVALUAR ALTERNATIVAS, IDENTIFICAR Y RESOLVER RIESGOS
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
Ciclo de vida del software Modelos de ciclo de desarrollo Modelos de ciclo de desarrollo
Espiral Espiral
Este modelo, definido por Boehm en 1988, presenta un desarrollo evolutivo, en contraste a la linealidad de los anteriores. Tambin introduce como elemento distintivo la actividad de anlisis de riego para guiar la evolucin del proceso de desarrollo. El ciclo de iteracin de este modelo evolutivo se convierte en una espiral, que al representarse sobre ejes cartesianos muestra en cada cuadrante una clase particular de actividad: Planificacin, Anlisis de riesgo, Ingeniera y Evaluacin, que se suceden de forma consecutiva a lo largo del ciclo de vida del desarrollo. La dimensin angular representa el avance relativo en el desarrollo de las actividades de cada cuadrante. En cada ciclo de la espiral se realiza una parte del desarrollo total, a travs de los cuatro tipos de actividades. En la planificacin de cada vuelta se establece el contexto del desarrollo y se decide qu parte del mismo se abordar en el ciclo siguiente. Las actividades de anlisis de riesgo evalan las alternativas posibles para la ejecucin de la siguiente parte del desarrollo, seleccionando la ms ventajosa y previendo los riesgos posibles. Las actividades de ingeniera corresponden a las indicadas en los modelos lineales (secuencial y cascada): anlisis, diseo, codificacin, etc. Las actividades de evaluacin analizan los resultados de la fase de ingeniera, tomando el resultado de la evaluacin como punto de partida para el anlisis de la siguiente fase. Este modelo permite mltiples combinaciones ya que en la planificacin de cada ciclo se determina el avance que se va a ejecutar durante la vuelta. ste puede consistir en la obtencin y validacin de requisitos, o en el desarrollo del diseo, o el diseo junto con la codificacin, o en la obtencin de un subsistema completo (cascada de requisitos diseo codificacin pruebas integracin).
43
Ciclo de vida del software Modelos de ciclo de desarrollo Modelos de ciclo de desarrollo
Espiral Espiral
En funcin de las combinaciones empleadas se podra argumentar que un desarrollo en espiral puede acabar siendo idntico a otro modelo. As por ejemplo si cada vuelta realizase exactamente una de las fases del modelo en cascada, al final se podra argumentar que se ha seguido una cascada. Si por el contrario en cada vuelta se desarrollara una parte del sistema global, se podra decir que se ha seguido no un modelo de ciclo de desarrollo, sino de ciclo de vida, y concretamente el modelo incremental. Aunque a primera vista puede parecer cierto, en realidad no lo es. Si al comenzar el desarrollo se tiene decidido que se van a abordar las fases de una cascada de forma secuencial, indudablemente se va a seguir un modelo en cascada. Si se determina ir elaborando partes del sistema, se opta por un ciclo de vida incremental. Si slo se determina dar un pequeo paso, y despus de conseguido, evaluar el resultado y planificar el siguiente paso, y antes de cada ejecucin se analizan los riesgos, en ese caso, el modelo seguido es un modelo en espiral
P3
44
Ciclo de vida del software Modelos de ciclos de evolucin Modelos de ciclos de evolucin
Incremental Incremental
REQUISITOS
Diseo Codificacin Pruebas Integracin Operacin Mantenim. Sub-sistema
Diseo
Codificacin
Pruebas
Integracin
Sub-sistema
SISTEMA
Diseo
Codificacin
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
Ciclo de vida del software Modelos de ciclos de evolucin Modelos de ciclos de evolucin
Incremental Incremental
Aunque en la representacin grfica de la figura anterior, los desarrollos de cada subsistema se solapan en el tiempo, en su aplicacin real, el segundo y siguientes subsistemas pueden comenzar una vez concluido el anterior. Resulta apropiado: Desarrollo de sistemas en los que el cliente necesita disponer de parte de la funcionalidad antes de lo que costara desarrollar el sistema completo. Desarrollo de sistemas en los que por razones del contexto interesa realizar la obtencin de los requisitos de forma escalonada a travs de subsistemas.
P4
46
Ciclo de vida del software Modelos de ciclos de evolucin Modelos de ciclos de evolucin
Evolutivo Evolutivo
Requisitos 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
Ciclo de vida del software Modelos de ciclos de evolucin Modelos de ciclos de evolucin
Evolutivo Evolutivo
Las circunstancias en las que este modelo puede resultar apropiado son 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
Ciclo de vida del software Modificadores de los modelos Modificadores de los modelos
Prototipado Prototipado
El prototipado consiste en la construccin de modelos de prueba, que simulen el funcionamiento que se pretende conseguir en el sistema. Los prototipos pueden ser: 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
Ciclo de vida del software Modificadores de los modelos Modificadores de los modelos
Concurrencia Concurrencia
Consiste en el solapamiento de un proceso sobre otro. Resulta bastante frecuente que aunque se haya planteado un desarrollo en cascada, se comience con una fase sin haber terminado por completo la anterior; y as por ejemplo quiz el equipo que ha llevado a cabo el diseo detallado de determinados mdulos, quiz comienza ya su codificacin, mientras otros equipos an tienen en su planificacin tareas de diseo pendientes. La concurrencia puede aportar beneficios sobre la planificacin de un proyecto de software, o por el contrario ser origen o consecuencia de problemas. Los factores que deben tenerse en cuenta para analizar cmo ayuda o perjudica al rendimiento son: 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
Ciclo de vida del software Modificadores de los modelos Modificadores de los modelos
Componentes comerciales y reutilizacin Componentes comerciales y reutilizacin
Resulta muy habitual integrar en el desarrollo de un sistema partes pre-construidas: que pueden ser componentes comerciales, o la reutilizacin de componentes o marcos ya desarrollados para otros sistemas. Esta tendencia surge desde tres situaciones: 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
Ciclo de vida del software Creacin del modelo de ciclo de vida Creacin del modelo de ciclo de vida
Al iniciar el proyecto, el responsable de la arquitectura de procesos debe realizar los siguientes pasos: 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.
Debe considerar aspectos como: 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 empleados, etc.
E2
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
55
1X 1X
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo detallado
construccin
Produccin
REQUISITOS
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
59
60
61
62
63
64
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
Obtencin
Especificacin
Anlisis
Gestin
Validacin y verificacin
66
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
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
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
70
71
73
SISTEMA
EVOLUCIN PREVISTA
74
Requisitos del software Especificacin de requisitos del software (SRS) Especificacin de requisitos del software (SRS)
Un documento SRS es la especificacin de las funciones que realiza un determinado producto de software, programa o conjunto de programas en un determinado entorno. El documento de especificacin de requisitos puede desarrollarlo personal representativo de la parte suministradora, o de la parte cliente; si bien es aconsejable la intervencin de ambas partes. Los aspectos bsicos que una descripcin de requisitos debe cubrir son: 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
Requisitos del software Especificacin de requisitos del software (SRS) Especificacin de requisitos del software (SRS)
No deben incluir restricciones de diseo gratuitas No deben incluir restricciones de diseo gratuitas Deben especificar el
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
Requisitos del software Especificacin de requisitos del software (SRS) Especificacin de requisitos del software (SRS)
Restricciones de diseo necesarias Restricciones de diseo necesarias
En algunos casos especiales, los requisitos pueden restringir el diseo de forma severa. Por ejemplo, algunos requisitos de seguridad pueden implicar consideraciones de diseo como: 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.
Exclusin de parmetros y datos de planificacin del proyecto Exclusin de parmetros y datos de planificacin 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: Coste. Agenda de entregas. Procedimientos de seguimiento. Mtodos de desarrollo del software. Control de calidad. Criterios de validacin y verificacin. Procedimientos de aceptacin
77
E3
Requisitos del software Descripcin del sistema SRS: Diferencias Descripcin del sistema SRS: Diferencias
Pertenecen a procesos primarios diferentes Pertenecen a procesos primarios diferentes
DESCRIPCIN DEL SISTEMA
5.1 Adquisicin
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
Requisitos del software Descripcin del sistema SRS: Diferencias Descripcin del sistema SRS: Diferencias
Pertenecen a entornos diferentes Pertenecen a entornos diferentes
ENTORNO DEL PROBLEMA ENTORNO DE LA SOLUCIN
Analizar el problema
Definir el sistema
80
81
82
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
84
Requisitos
Diseo
Codificacin
Integracin/ pruebas 85
E5
87
S pero no exactamente as. Vaya!, pues esto no debera ser as. Ya est todo? Usuarios contra desarrolladores
88
90
91
92
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
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
ENTREVISTAS
ESCENARIOS
TCNICAS
PROTOTIPOS
Prototipos rpidos prototipos evolutivos
OBSERVACIN
E6
99
R E Q U IS IT O T IPO S D E R E Q U IS IT O S N O F U N C IO N A L E S R E S T R IC C I N
R E Q U IS IT O D E IN T E R F A Z R E S T R IC C I N
100
101
104
Requisitos del software Propiedades de los buenos requisitos Propiedades de los buenos requisitos
Posibles
Cada requisito debe poder implementarse dentro de las capacidades y limitaciones conocidas del sistema y su entorno. El director tcnico deber comprobar la viabilidad de los requisitos antes de comprobar el documento.
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
Requisitos del software Propiedades de los buenos requisitos Propiedades de los buenos requisitos
Requisitos priorizados
Los requisitos de una SRS deben incluir una indicacin de la importancia del requisito en el conjunto del sistema. Normalmente todos los requisitos de un producto de software no son igual de importantes. Algunos resultan esenciales, y otros son deseables. Cada requisito debe identificar estas diferencias de forma clara, de esta forma ayuda a: 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
Requisitos del software Propiedades de los buenos requisitos Propiedades de los buenos requisitos
Concretos
Un requisito es concreto si tiene una nica interpretacin. Como mnimo esto requiere que cada caracterstica del producto final se describa empleando un trmino nico. En los casos en los que el trmino puede tener diferentes significados segn el contexto, ste debe incluirse en el glosario de la SRS con el significado con el que se emplea.
Punto ptimo: Mayor grado de comprensin con la menor ambigedad Modos eficaces de evitar la ambigedad: Inspecciones formales de los documentos de requisitos. Escritura de casos de prueba Elaboracin de casos de uso. Elaboracin de diagramas.
Comprensin
Punto ptimo
Ambigedad
107
Requisitos del software Propiedades de los buenos requisitos Propiedades de los buenos requisitos
Verificable
Un requisito es verificable si, y slo si a travs de un proceso concreto y finito es posible comprobar si el software lo cumple. En general los requisitos ambiguos no son verificables. Los requisitos no verificables incluyen sentencias como que trabaje eficientemente,interfaz de usuario amigable, debe responder rpidamente. Estos requisitos no son verificables porque no es posible definir los trminos eficiente, amigable, rpido. La sentencia el programa no debe entrar nunca en un bucle infinito tampoco es verificable porque un nivel de pruebas absoluto es tericamente imposible. Un ejemplo de requisito verificable es: El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el 90% de las veces, y una transaccin de compra de un billete sencillo nunca debe tardar ms de 5 segundos. Esta sentencia es verificable porque emplea trminos concretos y magnitudes medibles y comprobables. Si no es posible establecer un mtodo para comprobar si el software cumple con un determinado requisito, el requisito debe eliminarse o revisarse
108
109
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
A B B C
Requisitos Especificados 111
Revisin y aprobacin
Requisitos Correctos
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
113
114
Desarrollar software
Tomar requisitos del usuario Realizar procesos normalizados para el desarrollo de requisitos
115
MEDIOS
FIN
Conseguir el objetivo
116
117
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
Requisitos
Diseo
Construccin
119
120
Diseo del software Actividades del diseo de software Actividades del diseo de software
El diseo del software comprende dos actividades intermedias entre la fase de requisitos y la de construccin:
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
Diseo del software Razones del diseo del software Razones del diseo del software
Por qu? 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
Diseo del software Razones del diseo de software Razones del diseo de software
Descomposicin de la complejidad Descomposicin de la complejidad
Diseo del software Razones del diseo de software Razones del diseo de software
Anlisis de soluciones posibles a travs de su modelado. Anlisis de soluciones posibles a travs de su modelado.
Requisitos
Etc.
124
Diseo del software Razones del diseo de software Razones del diseo de software
Elemento de comunicacin, Base de planificacin y del desarrollo Elemento de comunicacin, Base de planificacin y del desarrollo
125
Diseo del software Fin del proceso de diseo Fin del proceso de diseo
Se considera que el proceso de diseo se ha completado cuando Se considera que el proceso de diseo se ha completado cuando
Todas las preguntas Como tienen respuesta La descripcin del diseo de la arquitectura est completada La revisin del diseo se ha completado y cada equipo/persona implicado est de acuerdo con el diseo. Los borradores de manuales para mantenimiento y administracin estn realizados Se ha realizado la trazabilidad del diseo Se ha revisado el diseo de la arquitectura Se ha verificado el diseo de la arquitectura Se ha escrito la planificacin de la integracin del software. Se ha establecido la lnea base del producto
126
Diseo del software Vistas del diseo de la arquitectura Vistas del diseo de la arquitectura
Un sistema de software es una entidad ortogonal que puede contemplarse o analizarse desde diferentes vistas: Puede enfocarse la atencin en: Distribucin fsica del software entre los diferentes elementos del sistema. Descomposicin en las diferentes funcionalidades que realiza. Estructuras de la informacin que gestiona. Etc. De esta forma el diseo puede generar modelos para cada una de las diferentes vistas empleadas en su anlisis (modelo fsico, modelo de datos, modelo se procesos, etc.).
127
Diseo del software Estrategias y mtodos para el diseo del software Estrategias y mtodos para el diseo del software
Las principales estrategias que suelen emplearse para el diseo del software son: Orientadas a funciones (estructurada) Orientada a objetos (diseo orientado a objetos) Diseo centrado en las estructuras de datos (menos empleado)
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
129
Estrategias 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 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
133
Diseo del software Descripcin del diseo del software (SDD) Descripcin del diseo del software (SDD)
El resultado del proceso de diseo es la documentacin denominada Descripcin del Diseo del Software. Un estndar empleado para desarrollar esta documentacin de forma normalizada es el IEEE Std. 1016-1998.
134
Diseo del software Descripcin del diseo del software (SDD) Descripcin del diseo del software (SDD)
Ejemplo de una posible organizacin de la informacin en una SDD Ejemplo de una posible organizacin de la informacin en una SDD
1.- Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones y acrnimos 2.- Referencias 3.- Descomposicin de la informacin 3.1 Descomposicin modular 3.1.1. Descripcin del mdulo 1 3.1.2. Descripcin del mdulo 2 3.2 Descomposicin de los proceesos 3.2.1. Descomposicin del proceso 1 3.2.2. Descomposicin del proceso 2 3.3 Descomposicin de los datos 3.3.1. Descripcin de la entidad 1 3.3.2. Descripcin de la entidad 2
4.- Descripcin de las dependencias 4.1 Dependencias intermolulares 4.2 Dependencias inter-procesos 4.3 Dependencias de los datos 5.- Descripcin de interfaces 5.1 Interfaces entre mdulos 5.1.1 Interfaz del mdulo 1 5.1.2 Interfaz del mdulo 2 5.2 Interfaces entre procesos 5.2.1 Interfaz del proceso 1 5.2.2 Interfaz del proceso 2 6.- Diseo detallado 6.1 Diseo detallado de los mdulos 6.1.1 Detalle del mdulo 1 6.1.2 Detalle del mdulo 2 6.2 Diseo detallado de los datos 6.1.1 Detalle de la entidad 1 6.1.2 Detalle de la entidad 2
135
Reunin de revisin del diseo de la arquitectura Reunin de revisin del diseo de la arquitectura
Revisin del diseo de la arquitectura Un equipo apropiado (Usuarios, cliente, ingeniero de soft) revisan el diseo. Una vez aprobado este diseo de puede comenzar a realizar el diseo detallado.
Diseo del software Base para las tareas de planificacin Base para las tareas de planificacin
La planificacin comienza con la misma decisin de desarrollar un sistema de software, y es un esfuerzo continuo que termina cuando el proyecto ha concluido. La planificacin consiste en la especificacin de: Metas y objetivos para el proyecto Estrategias, poltica, y procedimientos Explicndolo de otra forma es la decisin de: qu hacer cmo hacerlo cuando hacerlo quien va a hacerlo. A lo largo del ciclo de vida, desde la concepcin inicial del proyecto, la planificacin se va revisando y depurando, y una vez obtenido el diseo se dispone de una base slida. El diseo es la representacin formal de qu hacer y cmo hacerlo, sobre la que se puede asignar cando y quin.
137
Diseo del software Planificacin = tareas de ingeniera del software y de gestin Planificacin = tareas de ingeniera del software y de gestin
La planificacin del proyecto est dividido entre dos componentes relacionados: Planificacin realizada por el gestor Planificacin realizada por el ingeniero de sistemas
Qu tareas hay que realizar Orden y Dependencias de tareas Tamao (Esfuerzo en horas) Solucin tcnica para la resolucin del problema Qu herramientas de anlisis y diseo hay que utilizar Riesgos tcnicos El modelo de procesos (Tcnicas) Actualizar la planificacin cuando los requisitos o el entorno cambian.
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
139
5.-Documentacin de usuario
140
P1
142
Orientado a la informacin
Formativo
Orientado a tareas
Modos descriptivos
E1
Referencia
143
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
Inexperto[1]
Principiante
Intermedio
Experto
Intermitente
146
E2
147
148
INFORMACIN IDENTIFICATIVA Ttulo del documento Versin del documento y fecha de publicacin Nombre del producto de software y versin Organizacin que edita el documento
TABLA DE CONTENIDOS (ndice) INTRODUCCIN Audiencia Alcance y propsito del documento Descripcin general del propsito y funcionalidad del software, as como del entorno de operacin
E3
149
!
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
Informacin identificativa
Tabla de contenidos
S, en documentos de ms de 8 pginas
Lista de imgenes
Opcional
Introduccin
151
Procedimientos
S, en modo formativo
S, en modo referencia
Glosario
Opcional
ndice
S, en documentos de ms de 40 pginas
Capacidad de bsqueda
Correccin
Los textos deben ser lxica, ortogrfica y sintcticamente correctos.
E1
154
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
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 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 Verificacin y validacin en los procesos de desarrollo Verificacin y validacin en los procesos de desarrollo
5. Procesos primarios
5.1 Adquisicin 5.2 Suministro
6.- Procesos de soporte 6.6.1 Documentacin 6.2 Gestin de la configuracin 6.3 Control de calidad
7. Procesos organizacionales
7.1 Gestin 7.3 Mejora 7.2 Infraestructura 7.4 Formacin 159
Verificacin y validacin Verificacin y validacin en los procesos de desarrollo Verificacin y validacin en los procesos de desarrollo
Procesos de soporte Procesos de soporte
Las actividades de verificacin y validacin pueden realizarse en diversas fases y sobre diversos productos del desarrollo. Por esta razn estn clasificados como procesos de soporte, que son llamados por otros procesos del ciclo de vida. As, por ejemplo, si el estndar 830 de IEEE se emplea para regular cmo debe hacerse el documento de especificacin de requisitos del software, resulta posible y probable que durante el curso del desarrollo se revise el documento para ver si se ajusta a las caractersticas definidas en el estndar (verificacin). Tambin resulta posible (y muy recomendable) que se contraste el documento generado con interlocutores del cliente para comprobar que lo escrito refleja sus necesidades (validacin). Si la agenda del plan de proyecto prevea disponer del diseo en la fecha X, parece lgico que regularmente se verifique si los procesos estn inyectando causas de problemas en el proyecto (incumpliendo agendas, en este caso).
El esfuerzo de verificacin y validacin debe ajustarse a las caractersticas del proyecto. En algunos casos resultar aconsejable o necesario generar un plan de verificacin y validacin del software que se ajuste a estndares como el IEEE 1012-1998, y en otros casos bastar con tareas bsicas de verificacin yvalidacin, contempladas y dimensionadas en el plan del proyecto.
160
Verificacin y validacin Relacin entre V&V y el Aseguramiento de la Calidad Relacin entre V&V y el Aseguramiento de la Calidad
Aseguramiento de la calidad Aseguramiento de la calidad
La funcin del Aseguramiento de la Calidad es garantizar que la organizacin realiza el trabajo conforme a los procedimientos y mtodos establecidos para el proyecto.
IEEE Std. 730-1998
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 Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Definiendo los objetivos Definiendo los objetivos
Las consideraciones que deben contemplarse para evaluar la planificacin de las actividades de Validacin y Verificacin son: Nivel de integridad del proyecto. Concepto desarrollado en las pginas siguientes. Mide la criticidad del software. Mnimo de tareas recomendadas para el nivel de integridad del proyecto. La regulacin interna de la organizacin desarrolladora puede determinar qu tareas de V&V deben realizarse para cada nivel de integridad. El estndar IEEE 1012 define 4 niveles de integridad e incorpora una tabla en la que se estipulan las actividades mnimas de V&V en funcin del nivel. Intensidad y rigor necesarios en las tareas de Validacin y verificacin. El nivel de integridad no slo determina qu tareas deben realizarse, sino tambin su intensidad y rigor. Por ejemplo, si lo realiza el propio personal de desarrollo, otro equipo de desarrollo diferente, o incluso una organizacin externa (auditora). Los criterios que se emplearn en las tareas de V&V para establecer los parmetros mnimos de correccin, consistencia, precisin
162
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Criticidad del producto Criticidad del producto
El estndar IEEE 1012 establece que el plan de validacin y verificacin del software (SVVP) debe especificar un mtodo para clasificar el nivel de integridad del software de cada subsistema de software del proyecto.
E4
163
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad Anlisis de criticidad
Proceso para identificar, evaluar y categorizar el grado de criticidad de los elementos del producto de software. La definicin formal incluida en el estndar IEEE 1012-1998 es: La evaluacin estructurada de las caractersticas del software (p. ej. Seguridad, complejidad, rendimiento) para determinar la severidad del impacto de un fallo del sistema, de su degradacin o de su no cumplimiento con los requisitos o los objetivos del sistema. En otras palabras:
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 Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de daos Anlisis de criticidad: anlisis de daos
La definicin formal del anlisis de daos (a nivel de sistema) es: Anlisis de fuentes potenciales de daos o de situaciones que pueden generar daos en trminos de daos a personas, daos a la salud, o al entorno, o una combinacin de ellos.
IEC 60300-3-9, 1995
No obstante el estndar para validacin y verificacin IEEE 1012-1998 da una definicin ms amplia que incluye tambin prdidas econmicas, fallo en la misin del sistema, o impacto social adverso. Para nosotros dao en el marco de validacin y verificacin de software incluye por tanto:
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 Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos Anlisis de criticidad: anlisis de riesgos
Riesgo: probabilidad de que se produzca un dao identificado
En el desarrollo de un sistema de software se pueden producir adversidades que afecten a: Los planes del proyecto. Al producto o subproductos del desarrollo. Los riesgos inherentes a un proyecto suelen ser de tres naturalezas: Intrnsecos al sistema que se desarrolla Derivados de las particularidades de desarrollo del software. Propios del desarrollo de proyectos.
P2 P3
166
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos Anlisis de criticidad: anlisis de riesgos
NATURALEZA DEL RIESGO Propios del sistema CAUSAS TPICAS
Los identificados en el anlisis de daos Complejidad innecesaria
Complejidad intrnseca del diseo mayor de la necesaria
Baja calidad
Incumplimiento de estndares necesarios
[1] En los proyectos de software se suelen dar con mayor intensidad los riesgos tpicos indicados.
167
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Anlisis de criticidad: anlisis de riesgos Anlisis de criticidad: anlisis de riesgos
Validacin y Verificacin no gestionan las causas de los riesgos. Esa gestin pertenece a la gestin de riesgos, dentro de la gestin del proyecto.
Validacin Verificacin
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 Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Niveles de integridad Niveles de integridad
Anlisis de daos (hazard analysis)
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
El nivel de criticidad depende de dos factores: MAGNITUD DEL DAO POSIBLE POSIBILIDAD DE MITIGACIN DEL DAO
169
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Niveles de integridad Niveles de integridad
El estndar IEEE 1012-1998 define 4 niveles de integridad. En el borrador de 2004 las definiciones que se recogen para cada uno son: Nivel 4 Dimensin del dao por fallo del Software Prdida de vida Prdida del sistema Graves prdidas econmicas o sociales El sistema no realiza el fin previsto ni en todo ni en parte. Graves prdidas econmicas o sociales No se pueden realizar funcionalidades parciales del sistema. Prdidas econmicas o sociales importantes Una determinada funcionalidad del sistema no se realiza. Consecuencias mnimas Mitigacin aplicable No es posible mitigar los daos producidos
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 Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Independencia Independencia
La determinacin de las personas responsables de las tareas de verificacin y validacin, depende de: Caractersticas y naturaleza del proyecto
P4
Nivel de integridad La independencia puede aplicarse a distintas reas del proyecto: Independencia de gestin Las personas que realizan las tareas de verificacin y validacin se gestion al margen de la organizacin que realiza el desarrollo. Tienen la autoridad para tomar decisiones sobre el trabajo de V&V, incluyendo qu elementos se van a analizar, con qu herramientas. Facilitan la informacin de sus conclusiones tanto a los desarrolladores como al adquiriente, pero slo el adquiriente puede modificar la lnea de trabajo de validacin y verificacin. Independencia tcnica Las personas que analizan el proyecto son ajenas al grupo de desarrollo. Emplean sus propias herramientas, mtodos y recursos. Independencia financiera Las tareas de verificacin y validacin cuentan con presupuesto propio, y la autoridad para modificar su presupuesto est fuera de la organizacin desarrolladora.
P5
171
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Tipos de independencia Tipos de independencia
La validacin y verificacin independiente (IV&V) se clasifica en 4 tipos, en funcin del rigor con el que se realiza: clsica, modificada, interna y domstica. Los proyectos con nivel de integridad 4 requieren independencia rigurosa en todas sus reas. El estndar IEEE 1012-1998 muestra con la siguiente tabla el grado de independencia generalmente proporcionado por cada tipo, para cada faceta del proyecto.
Tipos de independencia
reas Gestin I I-R I-R I-M Tcnica I I I-R I-M Financiera I I I-R I-M
IM: Independencia mnima
172
Verificacin y validacin Adecuacin de V&V a las caractersticas del proyecto Adecuacin de V&V a las caractersticas del proyecto
Tipos de independencia Tipos de independencia
IV&V CLSICA Normalmente requerida para proyectos con nivel de integridad 4. Exige rigurosa independencia en las 3 reas del proyecto. IV&V MODIFICADA Suele emplearse en proyectos con nivel de integridad 3. El desarrollo y la V&V lo realizan organizaciones diferentes, pero la responsabilidad de la gestin en el proyecto es nica, y es la que recibe la informacin de ambas partes. No obstante, los presupuestos y el personal tcnico estn separados. IV&V INTERNA Se emplea cuando el equipo de V&V pertenece a la misma organizacin desarrolladora, pero en la forma de una entidad diferenciada del grupo de desarrollo del proyecto. IV&V DOMSTICA Se emplea personal de la organizacin desarrolladora para realizar la V&V. El personal de desarrollo y de validacin y verificacin trabaja conjuntamente. No se puede garantizar la independencia tcnica, y la gestin y el presupuesto son nicos para desarrollo y V&V.
173
Verificacin y validacin Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
Las tareas de verificacin y validacin se deben realizar en paralelo con los procesos del ciclo de vida, incluyendo tambin la gestin del proyecto.
Gestin
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 Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
ADQUISICIN En el proceso de adquisicin el trabajo de verificacin y validacin debe incluir siempre Revisin de la descripcin del sistema. En funcin del nivel de integridad del proyecto, puede cubrir tambin: Valoracin de la dimensin y alcance de los trabajos de V&V. Planificacin de la comunicacin entre los trabajos de V&V y la organizacin desarrolladora. SUMINISTRO El proceso de verificacin y validacin comienza cuando un suministrador decide atender la peticin de adquisicin. V&V se enfoca en determinar si la documentacin e informacin facilitada por el adquiriente es consistente y si, en opinin del suministrador, la solucin satisfar las necesidades de los clientes. Este proceso se denomina verificacin del contrato.
175
Verificacin y validacin Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
DESARROLLO La verificacin y validacin en el desarrollo centra su actividad en 6 tareas, que corresponden a las 5 tpicas de los ciclos de desarrollo en cascada, ms instalacin. V&V EN EL PROCESO DE DESARROLLO CONCEPTO IMPLEMENTACIN REQUISITOS PRUEBAS DISEO INSTALACIN
Si en el ciclo de vida empleado por el proyecto, la incorporacin de estas actividades est modificada, el proceso de verificacin y validacin tambin se adecuar a las caractersticas del proyecto. V & V CONCEPTO La verificacin y validacin del concepto trabaja sobre la descripcin del sistema, lleva a cabo el anlisis de criticidad, estudiando y evaluando daos y riesgos; y genera o actualiza el plan de validacin y verificacin.
176
Verificacin y validacin Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
V & V REQUISITOS En esta fase, la verificacin y validacin comprueba el principal producto generado en esta fase: la especificacin de requisitos del software. Se analizan las propiedades de calidad DEL DOCUMENTO Completo Correcto Consistente Modificable Trazable 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 Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
V & V IMPLEMENTACIN La implementacin transforma la descripcin del diseo en componentes de que juntos integran el producto final de software. La labor de verificacin y validacin comprueba: Conformidad del cdigo Con las especificaciones del diseo Con los estndares aplicables La idoneidad del cdigo para obtener el producto con el nivel de integridad deseado.
V & V PRUEBAS La verificacin y validacin de las pruebas garantiza que se han cumplido los requisitos del sistema y del software, alcanzando los niveles de integridad requeridos. En sistemas con niveles de integridad 3 y 4 es necesario que el equipo de verificacin y validacin realice los planes y procesos de prueba, as como su ejecucin. Para niveles 1 y 2 es suficiente con verificar las pruebas realizadas por el equipo de desarrollo. V & V INSTALACIN Se comprueba el rendimiento del sistema de software al ejecutarse en el entorno del cliente, as como que los procedimientos de instalacin son correctos.
178
Verificacin y validacin Verificacin y validacin en el ciclo de vida del software Verificacin y validacin en el ciclo de vida del software
V & V OPERACIN Una vez instalado y puesto en servicio el sistema de software, la verificacin y validacin valora el impacto que los cambios pueden suponer en el nivel de integridad del sistema, o los riesgos o daos que pueden introducir. Incluye la monitorizacin y evaluacin del entorno de operacin.
V & V MANTENIMIENTO Una vez puesto en servicio el sistema de software, las modificaciones del entorno, o la presencia de errores, o la necesidad de ampliar su funcionalidad requerirn emprender tareas de mantenimiento, que en esencia, y a menor escala son pequeas acciones de desarrollo que pueden introducir modificaciones en el nivel de integridad, y requerir revisiones en los anlisis de criticidad, daos y riesgos, as como requerir posteriores acciones de verificacin y validacin sobre las modificaciones de requisitos, diseo, desarrollo y pruebas.
E5
179
7.- Mantenimiento
E1
180
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.
Producto de software no comprende slo el cdigo. Incluye tambin la documentacin y los datos de configuracin PRODUCTO DE SOFTWARE
Cdigo Datos de configuracin y estructuras de datos Requisitos, documentos de anlisis, plan de V&V Manuales y documentacin de usuario 182
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
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
185
Diseo
Cdigo
Datos
Documentacin
186
187
188
EN CADA FASE
Entradas
Procesos
Control
Salidas
Mtricas
189
Entradas
Peticin de cambio
Procesos
Asignar n de identificacin Clasificar por tipo de mantenimiento Analizar y determinar se se acepta rechaza o pospone Primera estimacin de su magnitud Priorizar la modificacin Asignar la peticin a qu bloque de modificaciones prevista va a ir
Control
Una vez identificada la peticin de cambio, debe quedar registrada en un registro de peticiones de cambio
Salidas
Peticin de cambio validada que queda en un registro con la siguiente informacin: Definicin del problema o del nuevo requisito Evaluacin Tipo de mantenim. Prioridad inicial Estimacin inicial de recursos necesarios
Mtricas
N de omisiones en la P.C. N de P.C. enviadas N de peticiones de cambio duplicadas Tiempo invertido en la validacin. Factores medidos: correccin y mantenibilidad
190
Entradas
Peticin de cambio validada Estimacin inicial de recursos y dems informacin registrada. Documentacin del proyecto (si la hay).
Procesos
Anlisis de viabilidad (impacto, soluciones alternativas, implicaciones de seguridad, coste y beneficio de la modificacin) Anlisis detallado (SRS de la modificacin, elementos a modificar, estrategia de pruebas)
Control
Realizar revisiones tcnicas y revisar Estrategia de pruebas. Que la documentacin est completa y actualizada e incluye parmetros de seguridad
Salidas
Informe de viabilidad de las P.C. Informe del anlisis detallado. Requisitos actualizados (y trazables) Lista preliminar de mofificaciones. Plan de pruebas Plan de implementacin
Mtricas
Modificaciones de requisitos % de errores en la documentacin Esfuerzo por rea (SQA, SE, etc.) Tiempo empleado % de errores generados por prioridad y tipo. Factores: flexibilidad trazabilidad usabilidad mantenibilidad reusabilidad 191
Entradas
Salidas de la fase de anlisis. Documentacin del sistema y del proyecto Cdigo, comentarios y bases de datos del sistema.
Procesos
Identificacin de los mdulos afectados. Documentacin de las modificaciones Creacin de casos de prueba para las modificaciones Identificacin y creacin de pruebas de regresin Actualizacin de documentacin (SRS manuales)
Control
Inspeccin / verificacin del diseo Inspeccin / verificacin de la documentacin asociada
Salidas
Revisados: Lista de modificacines Anlisis detallado Plan de implementacin actualizado Lnea base de diseo Planes de pruebas
Mtricas
Complejidad del software Cambios diseo Esfuerzo por rea Cambios en planes de prueba Nmero de mdulos N lneas de cdigo aadidas o modificadas
192
Entradas
Resultados de la fase de diseo. Cdigo fuente y bases de datos del sistema. Documentacin del sistema y del proyecto.
Procesos
Codificacin y pruebas unitarias Integracin Anlisis de riesgos Revisin de pruebas
Control
Revisiones de cdigo Verificacin de la integracin. Verificacin de modificaciones y actualizaciones de documentacin. Gestin de riesgos y supervisin durante las pruebas
Salidas
Revisados: Software actualizado. Documentacin de diseo, pruebas, manuales documentacin de formacin actualizados. Definicin de riesgos e impactos. Informe de revisin de las pruebas
Mtricas
Volumen (puntos de funcin / lneas de cdigo) Porcentaje de errores generados.
193
Entradas
Informe de las pruebas. Documentacin de los planes de prueba, casos de prueba, procedimientos de prueba, manuales de usuario, diseo. Sistema actualizado
Procesos
Prueba funcional del sistema. Pruebas de interfaz. Pruebas de regresin.
Control
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
Salidas
Revisados: Sistema revisado. Informes de pruebas.
Mtricas
Porcentajes de errores por prioridad y tipo: Generados y corregidos.
194
Entradas
Informes de pruebas. Sistema completamente integrado. Planes de pruebas de aceptacin. Casos de prueba de aceptacin. Procedimientos de aceptacin
Procesos
Ejecucin de las pruebas de aceptacin a nivel funcional. Ejecucin de pruebas de interoperabilidad. Ejecucin de pruebas de regresin.
Control
Ejecucin de planes de aceptacin. Auditora funcional. Puesta bajo control de configuracin de la nueva documentcin. Establecimiento de la nueva lnea base del sistema. Informe de los resultados de auditora funcional.
Salidas
Nueva lnea base del sistema. Informe de auditora funcional. Informe de pruebas de aceptacin.
Mtricas
Porcentajes de errores por prioridad y tipo: Generados y corregidos.
195
Entradas
El sistema modificado segn se represente en la nueva lnea base.
Procesos
Auditora fsica de la configuracin. Notificacin a la comunidad de usuarios. Desarrollo y archivo de una copia de seguridad del nuevo sistema. Instalacin y formacin de usuarios.
Control
Ejecucin de la auditora fsica de la configuracin. Documento de descripcin de la versin.
Salidas
Informe de la auditora fsica. Documento de descripcin de la versin.
Mtricas
Cambios en la documentacin (manuales de usuario, de operacin, documento descripcin de versin, etc.)
E3
196
197
198
Analizar el sistema y decidir si conviene rehacerlo de nuevo, o por el contrario resulta ms apropiado aplicar tcnicas de reingeniera.
199
Qu hacer?
Reconstruccin
Ingeniera inversa
Ingeniera inversa
Reestructuracin de datos
Reestructuracin de cdigo
Reestructuracin de documentos
Ingeniera progresiva
200
Mantenimiento
203
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
E4
205
206
Consecuencias 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
Temporal
Desde el inicio del proyecto hasta que se deja de usar y se retira.
Ciclo de vida
[1] En la exposicin del captulo se abordan con detalle cada una de ellas.
208
Lnea base
Peticin de cambio
Librera
209
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
212
213
214
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 Funciones clave de la gestin de la configuracin Funciones clave de la gestin de la configuracin
Identificacin de la configuracin
Control de la configuracin
Auditoras y revisiones
216
Gestin de la configuracin Funciones clave de la gestin de la configuracin Funciones clave de la gestin de la configuracin
Identificacin de la configuracin Identificacin de la configuracin
Determinacin de los elementos de configuracin del software y de las lneas base a las que pertenecen.
Seleccin de los elementos de configuracin y agrupacin en lneas base. Deben considerarse productos que puedan disearse, desarrollarse, probarse y modificarse de forma independiente. Documentos Cdigo Datos Seleccin
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: NOMBRE: descriptivo del elemento. IDENTIFICADOR DE CONFIGURACION: Usado en la gestin interna de la librera. IDENTIFICADOR DE VERSION: Usado para identificar las diferentes versiones.
Nomenclatura y adquisicin
Adquisicin: Una vez identificado cada elemento, debe incorporarse a su respectiva librera.
217
Gestin de la configuracin Funciones clave de la gestin de la configuracin Funciones clave de la gestin de la configuracin
Control de la configuracin Control de la configuracin
Comprende la gestin de las revisiones y de los procesos de aprobacin, para evitar que se produzcan cambios de forma descontrolada.
Garantiza
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 Tcnico En los interfaces de configuracin En la agenda En el presupuesto Check-out lnea base Ejecucin de cambios Pruebas y verificacin Aprobacin de la ejecucin Chech-in lnea base
Validacin y evaluacin
218
Gestin de la configuracin Funciones clave de la gestin de la configuracin Funciones clave de la gestin de la configuracin
Medicin del estado de la configuracin Medicin del estado de la configuracin
Medicin y registro de los cambios, contenidos e histricos de la 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.
Gestin de la configuracin Funciones clave de la gestin de la configuracin Funciones clave de la gestin de la configuracin
Control de las relaciones de interfaz Control de las relaciones de interfaz
El desarrollo y mantenimiento de sistemas de software no suele ser autocontenido. Normalmente el software debe relacionarse con hardware y con otro software. El control de las relaciones de Interfaz contempla y gestiona las situaciones posibles: SITUACIONES 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. IMPLICCIONES DE INTERFAZ La gestin de la configuracin debe registrar tambin las plataformas y componentes externos, evaluando las posibles evoluciones y cambios.
Las gestiones de configuracin del proyecto de software y del subcontratado deben comunicarse y gestionar las implicaciones de cambio derivadas de uno a otro. 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