1 Introduccin a la gua.......................................................................................................................................... 1 1.1 Que es ingeniera del software?................................................................................................................... 1 1.2 Que es una profesin reconocida?............................................................................................................. 1 1.

3 Cuales son las caractersticas de una profesin?......................................................................................1 1.4 Cuales son los objetivos del proyecto SWEBOK?......................................................................................1 1.5 Organizacin Jerrquica............................................................................................................................... 1 1.6 Matriz y material de referencia..................................................................................................................... 1 1.7 Profundidad del tratamiento......................................................................................................................... 1 1.8 Restricciones relativas al formato del libro................................................................................................... 1 1.9 Las reas de conocimiento........................................................................................................................... 1 1.9.1 Estructura para la descripcin de las reas de conocimiento...............................................................1 1.9.2 rea de Conocimiento de Requerimientos de software........................................................................1 1.9.3 rea de Conocimiento de Diseo de software......................................................................................2 1.9.4 rea de Conocimiento de Construccin de software.............................................................................2 1.9.5 rea de Conocimiento de Pruebas de software....................................................................................3 1.9.6 rea de Conocimiento de Mantenimiento de software..........................................................................3 1.9.7 rea de Conocimiento de Gestin de la configuracin de software......................................................3 1.9.8 rea de Conocimiento de Gestin de ingeniera de software...............................................................4 1.9.9 rea de Conocimiento de Proceso de Ingeniera de software..............................................................4 1.9.10 rea de Conocimiento de Mtodos y Herramientas de Ingeniera de software...................................5 1.9.11 rea de Conocimiento de Calidad de software...................................................................................5 1.9.12 Disciplinas relativas a la Ingeniera del software.................................................................................5 2 Requerimientos de software................................................................................................................................ 6 2.1 Fundamentos de requerimientos de software............................................................................................... 6 2.1.1 Definicin de Requerimiento Software ................................................................................................. 6 2.1.2 Requerimientos de Producto y de Proceso........................................................................................... 7 2.1.3 Requerimientos funcionales y no funcionales.......................................................................................7 2.1.4 Propiedades emergentes...................................................................................................................... 7 2.1.5 Requerimientos cuantificables.............................................................................................................. 7 2.1.6 Requerimientos del Sistema y requerimientos del Software.................................................................8 2.2 Proceso de Requerimientos......................................................................................................................... 8 2.2.1 Modelos del Proceso............................................................................................................................. 8 2.2.2 Actores del Proceso.............................................................................................................................. 8 2.2.3 Soporte y gestin del proceso............................................................................................................... 9 2.2.4 Calidad y mejora de proceso................................................................................................................. 9 2.3 Obtencin de Requerimientos...................................................................................................................... 9 2.3.1 Fuentes de los requerimientos............................................................................................................ 10

2.3.2 Tcnicas de obtencin de requerimientos...........................................................................................10 2.4 Anlisis de requerimientos......................................................................................................................... 11 2.4.1 Clasificacin de los requerimientos.................................................................................................... 11 2.4.2 El modelo conceptual......................................................................................................................... 12 2.4.3 Asignacin de requerimientos y diseo arquitectnico ......................................................................13 2.4.4 Negociacin de requerimientos........................................................................................................... 14 2.5 Especificacin de requerimientos............................................................................................................... 14 2.5.1 El documento de la definicin de sistema........................................................................................... 14 2.5.2 Especificacin de requerimientos del sistema.....................................................................................14 2.5.3 Especificacin de requerimientos del software...................................................................................15 2.6 Validacin de Requerimientos.................................................................................................................... 15 2.6.1 Revisin de requerimientos ................................................................................................................ 16 2.6.2 Prototipado.......................................................................................................................................... 16 2.6.3 Validacin del Modelo......................................................................................................................... 16 2.6.4 Pruebas de Aceptacin....................................................................................................................... 16 2.7 Consideraciones prcticas......................................................................................................................... 17 2.7.1 Naturaleza iterativa del proceso de Requerimientos .........................................................................17 2.7.2 Gestin del Cambio ............................................................................................................................ 17 2.7.3 Atributos de los requerimientos .......................................................................................................... 18 2.7.4 Seguimiento de requerimientos........................................................................................................... 18 2.7.5 Medicin de Requerimientos............................................................................................................... 18 3 Diseo de software............................................................................................................................................ 19 3.1 Fundamentos de diseo de software.......................................................................................................... 20 3.1.1 Conceptos generales de diseo.......................................................................................................... 20 3.1.2 Contexto del Diseo de Software........................................................................................................ 20 3.1.3 Procesos de diseo de Software......................................................................................................... 20 3.1.4 Principios de diseo ........................................................................................................................... 20 3.2 Problemas claves en el diseo de software................................................................................................ 21 3.2.1 Concurrencia....................................................................................................................................... 21 3.2.2 Control y Manejo de Eventos ............................................................................................................. 21 3.2.3 Distribucin de los componentes......................................................................................................... 22 3.2.4 Manejo de errores ,excepciones y tolerancia a fallos..........................................................................22 3.2.5 Interaccin y Presentacin.................................................................................................................. 22 3.2.6 Persistencia de datos.......................................................................................................................... 22 3.3 Estructura y Arquitectura de Software........................................................................................................ 22 3.3.1 Estructuras Arquitectnicas y puntos de vista.....................................................................................22 3.3.2 Patrones de diseo (patrones micro arquitectnicos)........................................................................23 3.3.3 Las familias de los programas y Frameworks.....................................................................................23 3.4 Anlisis y evaluacin de la calidad del diseo del software........................................................................23

3.4.1 Atributos de Calidad............................................................................................................................ 23 3.4.2 Anlisis de la Calidad y Tcnicas de Evaluacin................................................................................24 3.4.3 Medidas............................................................................................................................................... 24 3.5 Notaciones del diseo de software............................................................................................................. 24 3.5.1 Descripcin Estructural (Vista esttica)............................................................................................... 24 3.5.2 Descripcin del comportamiento......................................................................................................... 25 3.6 Estrategias y Mtodos Diseo de software ................................................................................................ 26 3.6.1 Estrategias generales.......................................................................................................................... 26 3.6.2 Diseo orientado a funciones(Diseo estructurado)............................................................................26 3.6.3 Diseo orientado a Objetos................................................................................................................. 26 3.6.4 Diseo Centrado en Datos.................................................................................................................. 26 3.6.5 Diseo basado en componentes (CDB)..............................................................................................27 3.6.6 Otros mtodos..................................................................................................................................... 27 4 Construccin de software.................................................................................................................................. 28 4.1 Fundamentos de la construccin de software............................................................................................29 4.1.1 Minimizar la complejidad..................................................................................................................... 29 4.1.2 Anticipar cambios................................................................................................................................ 29 4.1.3 Construir para verificar:....................................................................................................................... 30 4.1.4 Estndares en construccin:............................................................................................................... 30 4.2 Gestin de la Construccin......................................................................................................................... 30 4.2.1 Modelos de Construccin.................................................................................................................... 30 4.2.2 Planificacin de la Construccin [Bec99; McC04]...............................................................................31 4.2.3 Medicin de la Construccin [McC04]................................................................................................. 31 4.3 Consideraciones Prcticas......................................................................................................................... 31 4.3.1 Diseo de Construccin...................................................................................................................... 31 4.3.2 Lenguajes de Construccin ................................................................................................................ 31 4.3.3 Codificacin ........................................................................................................................................ 32 4.3.4 Pruebas de Construccin.................................................................................................................... 33 4.3.5 Reutilizacin ....................................................................................................................................... 33 4.3.6 Calidad de la Construccin................................................................................................................. 34 4.3.7 Integracin.......................................................................................................................................... 34 5 Pruebas de software.......................................................................................................................................... 35 5.1 Fundamentos de las Pruebas del Software ...............................................................................................36 5.1.1 Terminologa relacionada con las pruebas..........................................................................................36 5.1.2 Cuestiones clave................................................................................................................................. 37 5.1.3 Relacin de las pruebas con otras actividades...................................................................................38 5.2 Niveles de Pruebas.................................................................................................................................... 38 5.2.1 El objeto de la prueba......................................................................................................................... 38 5.2.2 Objetivos de las pruebas..................................................................................................................... 39

5.3 Tcnicas de pruebas.................................................................................................................................. 41 5.3.1 Pruebas basadas en la intuicin y experiencia del ingeniero de software...........................................42 5.3.2 Tcnicas basadas en la especificacin............................................................................................... 42 5.3.3 Tcnicas basadas en el cdigo........................................................................................................... 43 5.3.4 Tcnicas basadas en errores ............................................................................................................. 44 5.3.5 Tcnicas basadas en el uso ............................................................................................................... 44 5.3.6 Tcnicas basadas en la naturaleza de la aplicacin...........................................................................44 5.3.7 Seleccionando y combinando tcnicas...............................................................................................45 5.4 Medidas de las pruebas............................................................................................................................. 45 5.4.1 Evaluacin de un programa durante las pruebas................................................................................45 5.4.2 Evaluacin de las pruebas realizadas................................................................................................. 46 5.5 El Proceso de las Pruebas......................................................................................................................... 47 5.5.1 Consideraciones prcticas.................................................................................................................. 47 5.5.2 Actividades de las pruebas................................................................................................................. 49 6 Mantenimiento de software................................................................................................................................ 51 6.1 Fundamentos del mantenimiento de software............................................................................................ 51 6.1.1 Definiciones y terminologa................................................................................................................. 51 6.1.2 Naturaleza del mantenimiento............................................................................................................. 52 6.1.3 Necesidad por el mantenimiento......................................................................................................... 52 6.1.4 La mayora de los costos de mantenimiento.......................................................................................53 6.1.5 Evolucin del Software........................................................................................................................ 53 6.1.6 categoras de mantenimiento.............................................................................................................. 53 6.2 Problemas clave en el mantenimiento de software....................................................................................54 6.2.1 Problemas tcnicos............................................................................................................................. 54 6.2.2 Problemas de gestin.......................................................................................................................... 56 6.2.3 Estimacin de costos de mantenimiento............................................................................................. 57 6.3 Medidas del mantenimiento de software.................................................................................................... 57 6.4 Proceso del mantenimiento........................................................................................................................ 58 6.4.1 Procesos de mantenimiento................................................................................................................ 58 6.4.2 Actividades de mantenimiento............................................................................................................ 59 6.5 Tcnicas para el mantenimiento................................................................................................................. 61 6.5.1 Comprensin del programa................................................................................................................. 62 6.5.2 Reingeniera........................................................................................................................................ 62 6.5.3 Ingeniera inversa............................................................................................................................... 62 7 Gestin de la configuracin software................................................................................................................. 63 7.1 Gestin del proceso de la SCM.................................................................................................................. 64 7.1.1 Contexto de Organizacin para la SCM..............................................................................................65 7.1.2 Restricciones y guias para el proceso de la SCM ..............................................................................65 7.1.3 Planificar la SCM................................................................................................................................. 65

7.1.4 Plan de la SCM .................................................................................................................................. 67 7.1.5 Seguimiento de la Gestin de la Configuracin del Software .............................................................68 7.2 Identificacin de la Configuracin del Software .........................................................................................68 7.2.1 Identificacin de los Elementos a Controlar........................................................................................69 7.2.2 Libreras de Software.......................................................................................................................... 71 7.3 Control de la Configuracin del Software .................................................................................................. 71 7.3.1 Peticin, Evaluacin y Aprobacin de Cambios del Software ...........................................................71 7.3.2 Implementacin de Cambios en el Software ......................................................................................72 7.3.3 Desviaciones y Remisiones ............................................................................................................... 73 7.4 Reporte del Estado de la Configuracin del Software ..............................................................................73 7.4.1 Informacin del Estado de la Configuracin del Software ..................................................................73 7.4.2 Informes del Estado de la Configuracin del Software .......................................................................73 7.5 Auditoria de la Configuracin del Software................................................................................................. 73 7.5.1 Auditoria de la Configuracin Funcional del Software.........................................................................74 7.5.2 Auditora de la Configuracin Fsica del Software...............................................................................74 7.5.3 Auditoras durante el proceso de una Lnea Base de Software..........................................................74 7.6 Gestin del Lanzamiento y Distribucin del Software.................................................................................74 7.6.1 Construccin del Software.................................................................................................................. 74 7.6.2 Gestin del Lanzamiento del Software................................................................................................75 8 Gestin de ingeniera del software.................................................................................................................... 76 8.1 Iniciacin y Definicin del Alcance.............................................................................................................. 79 8.1.1 Determinacin y negociacin de requerimientos.................................................................................79 8.1.2 Anlisis de factibilidad (Tcnica, Operacional, financiera y socio poltica)..........................................79 8.1.3 Procesos para el anlisis y revisin de requerimientos.......................................................................80 8.2 Planeacin de Proyectos de Software........................................................................................................ 80 8.2.1 Planeacin del proceso....................................................................................................................... 80 8.2.2 Determinar los entregables................................................................................................................. 80 8.2.3 Estimacin de Esfuerzo, calendario y costo........................................................................................81 8.2.4 Asignacin de recursos....................................................................................................................... 81 8.2.5 Gestin de riesgos.............................................................................................................................. 81 8.2.6 Gestin de Calidad.............................................................................................................................. 81 8.2.7 Gestin de Planes............................................................................................................................... 81 8.3 Ejecucin del Proyecto de Software.......................................................................................................... 82 8.3.1 Implementacin de Planes.................................................................................................................. 82 8.3.2 Gestin de Contratos con Proveedores.............................................................................................. 82 8.3.3 Implementacin de Procesos de medicin.......................................................................................... 82 8.3.4 Proceso de Supervisin...................................................................................................................... 82 8.3.5 Proceso de Control.............................................................................................................................. 83 8.3.6 Informes.............................................................................................................................................. 83

8.4 Revisin y Evaluacin................................................................................................................................ 83 8.4.1 Determinar la Satisfaccin de los Requerimientos..............................................................................83 8.4.2 Revisar y Evaluar la Ejecucin............................................................................................................ 83 8.5 Cierre.......................................................................................................................................................... 84 8.5.1 Determinar el Cierre............................................................................................................................ 84 8.5.2 Actividades de Cierre.......................................................................................................................... 84 8.6 Medidas de la Ingeniera del Software....................................................................................................... 84 8.6.1 Establecer y Sostener el Compromiso de Medir.................................................................................84 8.6.2 Planificar el Proceso de Medicin....................................................................................................... 85 8.6.3 Realizar el Proceso de Medicin......................................................................................................... 86 8.6.4 Evaluar las Mediciones....................................................................................................................... 86 9 Proceso de Ingeniera del software................................................................................................................... 93 9.1 Implementacin y Cambios de Proceso..................................................................................................... 94 9.1.1 Infraestructura del Proceso................................................................................................................. 95 9.1.2 Ciclo de Gestin del Proceso del Software.........................................................................................95 9.1.3 Modelos Para el Proceso de Implementacin y Cambios...................................................................96 9.1.4 Consideraciones Prcticas................................................................................................................. 96 9.2 Definicin de Procesos............................................................................................................................... 96 9.2.1 Modelos de Ciclo de Vida del Software............................................................................................... 96 9.2.2 Procesos del Ciclo de Vida del Software............................................................................................. 97 9.2.3 Notaciones para las Definiciones de los Procesos..............................................................................97 9.2.4 Adaptacin del Proceso...................................................................................................................... 97 9.2.5 Automatizacin.................................................................................................................................... 98 9.3 Valoracin del Proceso............................................................................................................................... 98 9.3.1 Modelos de Valoracin del Proceso.................................................................................................... 98 9.3.2 Mtodos de Valoracin del Proceso.................................................................................................... 98 9.4 Medicin de los Procesos y Productos....................................................................................................... 99 9.4.1 Medicin del Proceso.......................................................................................................................... 99 9.4.2 Medicin del producto software......................................................................................................... 100 9.4.3 Calidad de los resultados de medicin..............................................................................................101 9.4.4 Modelos de informacin software...................................................................................................... 101 9.4.5 Tcnicas de medicin de procesos................................................................................................... 101 10 Mtodos y herramientas de ingeniera del software......................................................................................104 11 Calidad de Software....................................................................................................................................... 105 11.1 Fundamentos de calidad de software..................................................................................................... 105 11.1.1 Cultura y tica en la Ingeniera de Software...................................................................................106 11.1.2 Valores y Costos de la calidad........................................................................................................ 106 11.1.3 Modelos y caractersticas de calidad............................................................................................... 107 11.1.4 Mejoramiento de la calidad ............................................................................................................ 108

11.2 Procesos de Gestin de Calidad de Software........................................................................................ 108 11.2.1 Aseguramiento de la Calidad de Software......................................................................................109 11.2.2 Verificacin y Validacin................................................................................................................. 110 11.2.3 Revisiones y Auditorias................................................................................................................... 111 11.3 Consideraciones prcticas...................................................................................................................... 113 11.3.1 Requisitos de calidad de software................................................................................................... 113 11.3.2 Caracterizacin de Defectos........................................................................................................... 114 11.3.3 Tcnicas de Gestin de la Calidad del Software.............................................................................115 11.3.4 Medicin de la Calidad del Software...............................................................................................116 12 Disciplinas relativas a la Ingeniera del software........................................................................................... 119

1 Introduccin a la gua
1.1 Que es ingeniera del software? 1.2 Que es una profesin reconocida? 1.3 Cuales son las caractersticas de una profesin? 1.4 Cuales son los objetivos del proyecto SWEBOK? 1.5 Organizacin Jerrquica 1.6 Matriz y material de referencia 1.7 Profundidad del tratamiento 1.8 Restricciones relativas al formato del libro 1.9 Las reas de conocimiento 1.9.1 Estructura para la descripcin de las reas de conocimiento 1.9.2 rea de Conocimiento de Requerimientos de software
Un requerimiento es definido como una propiedad que debe tener con el fin de resolver algunos problemas del mundo real. La primera subrea del conocimiento es Fundamentos de Requerimientos del software . Se incluyeron las definiciones de Requerimientos del Software, tambin los principales tipos de requerimientos: producto vs proceso, funcional vs no funcional y propiedades emergentes del producto. El subrea tambin describe la importancia de requerimientos cuantificables y diferencia entre requerimientos de sistemas y del software. La segunda subrea es el Proceso de Requerimientos, que introduce el proceso en s, orientando las otras cinco subreas y muestra como la ingeniera de requerimientos encaja dentro de otros procesos de ingeniera del software. En l se describen los modelos de procesos, los actores de los procesos, el soporte y gestin de procesos, mejora y calidad de procesos La tercera subrea es Obtencin de requerimientos, que se ocupa de donde vienen los requerimientos del software y como el ingeniero del software puede recogerlos. Incluye Fuentes de requerimientos y tcnicas de obtencin. La cuarta subrea, Anlisis de Requerimientos, tiene que ver con el proceso de analizar los requerimientos para: Detectar y resolver los conflictos entre los requerimientos. Descubrir los lmites del software y la forma en que deben interactuar con su entorno Elaborar los requerimientos del software para el sistema. En el anlisis de requerimientos incluye clasificacin de requerimientos, modelado conceptual, diseo Arquitectnico y la asignacin de requerimientos, y la negociacin de requerimientos. La quinta es la subrea es la especificacin de requerimientos. Se refiere a la produccin de un documento, o su equivalente electrnico, que puede ser sistemticamente revisado,

evaluado, y aprobado. Para sistemas complejos, hay tres tipos diferentes de documentos que se producen: definicin del sistema, especificacin de los requerimientos del sistema, especificacin de requerimientos del software. Esta subrea describe los tres documentos y sus actividades. La sexta es la subrea es validacin de requerimientos , cuyo objetivo es recoger todos los problemas antes de que se comprometan los recursos dirigidos a los requerimientos. Validacin de requerimientos se refiere al proceso de examinar los documentos necesarios para asegurar que estn definiendo el sistema correcto (es decir, el sistema que el usuario espera). Se subdivide en las descripciones de la conducta de revisin de requerimientos, de prototipos, y validacin de modelos y pruebas de aceptacin. En la sptima y ltima subarea se encuentran las Consideraciones prcticas. En la cual se describen los temas que deben entenderse en la prctica. El primer tema es el carcter iterativo de los procesos de requerimientos. Los siguientes tres temas son fundamentalmente sobre la gestin del cambio y el mantenimiento de los requerimientos en un estado que con precisin refleja el software a ser construido, o que ya se ha construido. Incluye la gestin del cambio, los atributos de requerimientos, y la localizacin de los requerimientos. El ltimo tema es la medicin de requerimientos.

1.9.3 rea de Conocimiento de Diseo de software

De acuerdo con la definicin de IEEE [IEEE610.12-90], diseo es "el proceso de definicin de la arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente" y "el resultado de [ese proceso]." Esta rea del conocimiento (AC) se divide en seis sub-reas El primer sub-rea presenta los fundamentos diseo de software, que forman una base subyacente a la comprensin de la funcin y el alcance del diseo de software. Estos son conceptos generales de software, el contexto de diseo de software, el proceso de diseo de software, y las tcnicas que permiten el diseo de software. La segunda del sub-rea agrupa a las principales asuntos claves de diseo software. Estos incluyen la concurrencia, el control y manejo de eventos, la distribucin de los componentes, errores y manejo de excepciones y tolerancia a fallos, la interaccin y presentacin, y la persistencia de datos La tercera sub-rea es la estructura y la arquitectura del software, los temas, cuales son estructuras arquitectnicas y puntos de vista, estilos arquitectnicos, patrones de diseo, y finalmente, las familias de los programas y frameworks. La cuarta sub- rea describe la calidad del diseo software anlisis y evaluacin. Si bien existe una rea de Conocimiento (AC) dedicado a la calidad del software, est sub-rea presenta los temas relacionados con el diseo de software. Estos aspectos son los atributos de calidad, anlisis de calidad, y tcnicas de evaluacin y medicin. La quinta sub-rea son tcnicas de diseo de software, que estn divididas en las descripciones estructurales y de comportamiento En la ltima sub-rea describe las estrategias y mtodos de diseo de software. En primer lugar, se describen las estrategias generales, seguido por mtodos de diseo orientados a funciones y mtodo de diseo orientado a objetos, estructura de datos centrados en el diseo, diseo basado en componentes, y otros.

1.9.4 rea de Conocimiento de Construccin de software

La construccin de software se refiere a los detalles de creacin de funcionalidad, principalmente por medio de la combinacin de cdigos, verificacin, pruebas de unidad, pruebas de integracin y depuracin. EL AREA DE CONOCIMIENTO. Incluye tres subareas. La primera es la subarea de Fundamentos de la Construccin Software. Los tres primeros temas son los principios bsicos de la construccin: reduccin al mnimo de complejidad, la anticipacin del cambio, y la construccin para la verificacin. El ltimo tema trata las normas para la construccin.

La segunda subarea describe la Gestin de la Construccin. Los temas son los Modelos de Construccin, la Construccin de Planificacin, y Medicin de la Construccin. La tercera subarea abarca las Consideraciones prcticas. Los temas son el diseo de construccin, lenguajes de construccin, codificacin, pruebas de construccin, la reutilizacin, la calidad de la construccin, y la integracin.

1.9.5 rea de Conocimiento de Pruebas de software

Las pruebas del software consisten en verificar el comportamiento de un programa dinmicamente a travs de un grupo finito de casos de prueba, debidamente seleccionados del, tpicamente, mbito de ejecuciones infinito, en relacin al comportamiento esperado. Incluye cinco subreas Comienza con una descripcin de fundamentos de pruebas de software. En primer lugar, se presenta la terminologa relacionada con las pruebas, se describen los asuntos claves y finalmente, la relacin de las pruebas con otras actividades. La segunda subrea es niveles de prueba. Estos se dividen entre el objeto de las prueba y los objetivos de las pruebas. La tercera subrea es tcnicas de pruebas. La primera categora incluye las pruebas basadas en la intuicin y la experiencia. Un segundo grupo comprende las tcnicas basadas en la especificacin, seguida de las tcnicas basadas en cdigo, las tcnicas basadas en los errores, las tcnicas basadas en uso, y las tcnicas basadas en la naturaleza de la aplicacin. Se presenta tambin una discusin de cmo seleccionar y combinar las tcnicas adecuadas. La cuarta est dedicada a la subrea de medidas relativas a pruebas. Las medidas se agrupan en las relacionadas con la evaluacin del programa mediante pruebas y la evaluacin de las pruebas realizadas. La ultima subrea, describe el proceso de pruebas e incluye consideraciones prcticas y las actividades de prueba.

1.9.6 rea de Conocimiento de Mantenimiento de software

No enviaron la correccion

1.9.7 rea de Conocimiento de Gestin de la configuracin de software

La Gestin de configuracin de software es una disciplina que identifica la configuracin de un sistema en puntos distintos del tiempo para ver los cambios sistemticamente controlados de la configuracin del software y mantener la integridad de la configuracin en todo el ciclo de vida del sistema. Este incluye seis reas de conocimientos. 1 - La primera rea es la gestin del proceso de Gestin de Configuracin. Cubre los temas del contexto organizativo, las restricciones y la orientacin; teniendo en cuenta la visita, la gestin de configuracin se planea y vigilancia. 2 - La segunda rea es la identificacin de configuracin de software, que identifica los items a ser controlados, Establece los planes de identificacin para los items y sus versiones, y establece las herramientas y las tcnicas que van a ser usadas para adquirir y dirigir los items controlados. En esta rea primero identificamos los items a ser controlados y la biblioteca de software. 3 - La tercera rea es el control de configuracin de software, que es la direccin de los cambios durante la vida del software en un ciclo. Los temas son; primero, obtener, valorar y aprobar los cambios de software; segundo, implementar Cambios de software, y tercero desviaciones y privilegios. 4 - La cuarta rea es la contabilidad de estado de configuracin de software. Sus temas son la Informacin y el sealamiento del estado de configuracin del software.

5 - La quinta rea es la auditora de configuracin de software. Consta de una configuracin funcional, una configuracin fsica y auditoras de un punto de partida del software. 6 - La sexta rea es la gestin de lanzamiento y entrega del software, cubriendo la construccin del software y de la gestin de lanzamiento

1.9.8 rea de Conocimiento de Gestin de ingeniera de software

La Gestin de Ingeniera de Software EL AREA DE CONOCIMIENTO (AC) se refiere a la gestin y medicin de la ingeniera de software. Mientras que medicin es un aspecto importante de todos los KAS, es aqu donde el tema de los programas de medicin se presenta. Hay seis sub-reas para la gestin de ingeniera de software. Los primeros cinco abarcan la gestin de proyectos de software y el sexto describe programas de software de medicin. La primera es la sub-rea Iniciacin y mbito de aplicacin de definicin, que comprende la determinacin y la negociacin de los requerimientos, anlisis de viabilidad, y el proceso para el examen y revisin de requerimientos. La segunda es la sub-rea de Planificacin de Proyecto de Software e incluye proceso de planificacin, la determinacin de los resultados, el esfuerzo, el horario y estimacin de costos, asignacin de recursos, gestin de riesgos, gestin de la calidad, y plan de manejo. La tercera es la sub-rea de incorporacin de Proyecto de Software al derecho interno. Los temas aqu son la implementacin de planes, gestin de contrato de abastecimiento, la ejecucin del proceso de medicin, proceso de seguimiento, control de procesos, y presentacin de informes. La cuarta es la sub-rea de Revisin y Evaluacin, que incluye los temas de determinar la satisfaccin de los requerimientos y revisar y evaluar el desempeo. La quinta describe la sub-rea de cierre: el cierre y la determinacin actividades de cierre. Por ltimo, la sexta sub-rea describe la medicin orientada a la Ingeniera del Software, ms concretamente, los programas de medicin. Producto y medidas de proceso se describen en el Software el Area de Conocimiento (AC) Ingeniera de Procesos. Muchos de los otros KAS tambin describen medidas especficas para su el Area de Conocimiento (AC). Los temas de esta sub-rea incluyen el establecimiento y el mantenimiento del compromiso de medicin, la planificacin del proceso de medicin, realizando el proceso de medicin, y evaluacin de medicin.

1.9.9 rea de Conocimiento de Proceso de Ingeniera de software

El rea de Conocimiento (AC) proceso de Ingeniera de Software se encarga de la definicin, implementacin, evaluacin, medicin, gestin, cambio y mejora del proceso de ingeniera del software. Se divide en cuatro sub-reas: La primera sub-rea presenta proceso de aplicacin y modificacin. Los temas aqu son la infraestructura de proceso, ciclo de gestin del proceso del software, modelos para aplicacin y modificacin, y consideraciones prcticas. La segunda sub-rea es la definicin de procesos. Incluye los temas de; modelos de ciclo de vida del software, procesos del ciclo de vida del software, notaciones para la definicin de los proceso, adaptacin del proceso y la automatizacin. La tercera sub-rea es la valoracin del proceso. Los temas aqu incluyen modelos de valoracin del proceso y mtodos de valoracin del proceso. La cuarta sub-rea es mediciones de productos y procesos. El proceso de ingeniera de software abarca medicin general de los productos, as como el proceso de medicin en general. Medidas especficas para las otras AC se describen en la correspondiente el rea de Conocimiento (AC). Los temas son medicin del proceso, medicin de productos software, calidad de los resultados de la medicin, modelos de informacin software y tcnicas de medicin de procesos.

1.9.10 rea de Conocimiento de Mtodos y Herramientas de Ingeniera de software

1.9.11

rea de Conocimiento de Calidad de software

El rea de Conocimiento de Calidad del Software se ocupa de la calidad del software, consideraciones que trascienden los procesos del ciclo de vida del software. Dado que la calidad del software es una preocupacin omnipresente en la ingeniera de software, tambin se considera en muchas de las otras (reas de conocimiento SWEBOK), y el lector se dar cuenta de los punteros a lo largo de esta (reas de conocimiento SWEBOK (el Area de Conocimiento (AC))). La descripcin de este (reas de conocimiento SWEBOK), abarca tres sub-reas. La primera describe la sub-rea Fundamentos de Calidad de Software tales como la cultura de ingeniera de software y la tica, el valor y los costos de calidad, modelos y caractersticas de calidad y la mejora de la calidad. El segundo abarca la sub-rea de Gestin de Calidad de Procesos de Software. Los temas son el aseguramiento de la calidad de software, verificacin y validacin, y las revisiones y auditoras. La tercera y ltima sub-rea describe Consideraciones prcticas relacionadas con la calidad del software. Los temas son los requisitos de calidad del software, la caracterizacin de defectos, tcnicas de gestin de calidad de software y medicin de la calidad del software

1.9.12

Disciplinas relativas a la Ingeniera del software

2 Requerimientos de software
Acrnimos DAG El Grafico Acclico Dirigido FSM Medicin del tamao funcional INCOSE Consejo Internacional de Ingeniera de Sistemas SADT Tcnica de diseo y anlisis estructurado UML Lenguaje de modelado unificado INTRODUCCION El rea de conocimiento (AC) de requerimientos del software se refiere a la obtencin, anlisis, especificacin, y validacin de requerimientos del software. Est ampliamente reconocido dentro de la industria del software que los proyectos de ingeniera de software son crticamente vulnerables cuando estas actividades se realizan mal. Los requerimientos del software expresan las necesidades y restricciones impuestas en un producto de software que contribuye a la solucin de algunos problemas de la vida real [kot00] El termino ingeniera de requerimientos es ampliamente usado en el campo para denotar la manipulacin sistemtica de requerimientos. Por razones de consistencia, este trmino no ser usado en la gua, Se ha decidido el uso del trmino de ingeniera para las actividades que se tratan sobre ingeniera del software. Por la misma razn Ingeniero de requerimientos un termino que aparece en algunas literaturas, tampoco se utilizar. En su lugar se utilizar el termino Ingeniero del software o, en algunos casos especficos, puede ser usado especialista de los requerimientos. La descomposicin del el rea de Conocimiento (AC) es ampliamente compatible con las secciones de IEE 12207 que se refiere a las actividades de requerimientos.(IEEE12207.1-96). Un riesgo inherente en la descomposicin propuesta es que el proceso de cascada puede ser inferido. Para evitar esto, la segunda subarea Proceso de requerimientos, es diseada para proporcionar una descripcin de alto nivel del proceso de requerimientos partiendo de los recursos y obligaciones bajo las cuales el proceso funciona y las cuales actan para configurarlo. Una descomposicin alternativa podra utilizar una estructura basada el producto (requerimientos del software, requerimientos del sistema, propiedades, casos de uso, y otras). El proceso basado en la descomposicin reflejan el hecho de que el proceso de requerimientos, si este es acertado, se debe considerar como un proceso que implica actividades complejas, firmemente unidas(ambas secuenciales y concurrentes), mas que una actividad discreta, una nica actividad realizada al principio de un proyecto de desarrollo de software.

2.1 Fundamentos de requerimientos de software 2.1.1 Definicin de Requerimiento Software

Bsicamente, un requerimiento del software es una propiedad que debe exhibirse para resolver algn problema en el mundo real. La Gua se refiere a los requerimientos del software porque se preocupa por los problemas que tratan del software. Por lo tanto, un requerimiento del software es una propiedad que debe exhibirse por el software desarrollado o adaptado para resolver un problema particular. El problema puede ser automatizar parte de una tarea de alguien que usar el software, para apoyar los procesos de negocio de la organizacin que ha comisionado el software, corregir limitaciones de software existente, controlar un dispositivo, y

muchas ms. Las funcionalidades de usuarios, los procesos de negocio, y los dispositivos son tpicamente complejos. Por consiguiente, los requerimientos, en particular de software son tpicamente una combinacin compleja de requerimientos de personas diferentes en niveles diferentes de una organizacin y del ambiente en que el software operar. Una propiedad esencial de todos los requerimientos del software es que son verificables. Puede ser difcil o costoso verificar ciertos requerimientos del software. Por ejemplo, la comprobacin del requerimiento de procesamientos en un call center, puede hacer necesario el desarrollo de un software de simulacin. Los requerimientos del software y el personal de calidad de software deben asegurar que los requerimientos puedan verificarse dentro de las restricciones en los recursos disponibles. Los requerimientos tienen otros atributos adems de las propiedades de comportamiento que ellos expresan. Los ejemplos comunes incluyen una tasa de prioridad para permitir los intercambios frente a los recursos finitos y un valor de estado para permitir supervisar el progreso del proyecto. Tpicamente, se identifican los requerimientos del software nicamente para que ellos puedan sujetarse al control de configuracin de software y pueden manejarse durante todo el ciclo de vida del software. [Kot00; Pfl01; Som05; Tha97]

2.1.2 Requerimientos de Producto y de Proceso

Una distincin puede hacerse entre los parmetros del producto y los parmetros del proceso. Los parmetros del producto son los requerimientos de software para ser desarrollado (por ejemplo, El software verificar que un estudiante rena todos los prerrequisitos antes de que l o ella se registren en un curso.). Un parmetro del proceso es esencialmente una restriccin en el desarrollo del software (por ejemplo, El software se escribir en Ada.). stos a veces se conocen como los requerimientos del proceso. Algunos requerimientos del software generan implcitamente los requerimientos del proceso. La seleccin de tcnica de la comprobacin es un ejemplo. Otro podra ser el uso de tcnicas del anlisis particularmente rigurosas (como los mtodos formales de especificacin) para reducir fallas que pueden conducir a una fiabilidad inadecuada. Los requerimientos del proceso tambin pueden ser impuestos directamente por la organizacin de desarrollo, su cliente, o terceros tales como una entidad reguladora de seguridad [Kot00; Som97].

2.1.3 Requerimientos funcionales y no funcionales

Los requerimientos Funcionales describen las funciones que el software va a ejecutar; por ejemplo, ajustarse a un formato de texto o modular una seal. Tambin se conocen como las capacidades. Los requerimientos no funcionales son los que actan para restringir la solucin. Los requerimientos no funcionales a veces se conocen como restricciones o requerimientos de calidad. Pueden ser clasificados ms a fondo segn si son los requerimientos de funcionamiento, requerimientos de capacidad de mantenimiento, requerimientos de seguridad, requerimientos de fiabilidad, o uno de muchos otros tipos de requerimientos del software. Estos temas tambin se discuten en rea de Conocimiento de Calidad del Software. [Kot00; Som97].

2.1.4 Propiedades emergentes

Algunos requerimientos representan propiedades emergentes (inesperadas) del softwareque son, requerimientos que no pueden ser direccionados a un solo componente, pero su satisfaccin depende de cmo nteroperan todos los componentes del software. El requerimiento de rendimiento de procesamiento para un call center, depender de cmo el sistema de telefnico, el sistema de informacin, y los operadores, interactan recprocamente bajo las condiciones de funcionamiento reales. Las propiedades emergentes son crucialmente dependientes de la arquitectura del sistema. [Som05]

2.1.5 Requerimientos cuantificables

Los requerimientos del software deben definirse tan clara e inequvocamente y donde sea posible cuantitativamente. Es importante evitar requerimientos vagos e inverificables, que dependen para su interpretacin del juicio subjetivo (el software ser fiable; el software ser

amigable al usuario). Esto es particularmente importante para los requerimientos no funcionales. Dos ejemplos de requerimientos cuantificados son los siguientes: el software para un call center debe aumentar el rendimiento del procesamiento del centro por un 20%; y un sistema tendr una probabilidad de generar un error fatal durante cualquier hora de funcionamiento de menos de 1 * 10-8. El requerimiento de rendimiento de procesamiento est en un nivel muy alto y necesitar ser derivado en varios requerimientos detallados. El requerimiento de fiabilidad determinar firmemente la arquitectura del sistema. [Dav93; Som05]

2.1.6 Requerimientos del Sistema y requerimientos del Software

En este tema, sistema significa una combinacin interactuante de elementos para lograr un objetivo definido. stos incluyen hardware, software, firmware (soporte lgico), personas, informacin, tcnicas, medios, servicios, y otros elementos de apoyo, segn lo definido por el Consejo Internacional de la Ingeniera de Sistemas (INCOSE00). Los requerimientos del Sistema son los requerimientos del sistema como un todo. En un sistema que contiene componentes software, los requerimientos del software se derivan de los requerimientos del sistema. La literatura sobre los requerimientos algunas veces llama a los requerimientos del sistema los requerimientos del usuario. La Gua define los requerimientos del usuario de una manera restringida como los requerimientos de los clientes del sistema o usuarios finales. Los requerimientos del Sistema, por el contrario, abarcan los requerimientos del usuario, requerimientos de otros involucrados (como las autoridades reguladoras), y requerimientos sin una fuente humana identificable.

2.2 Proceso de Requerimientos

Esta seccin introduce el proceso de requerimientos de software, orientado a las cinco subreas restantes y mostrando cmo encaja con el proceso de ingeniera del software.

2.2.1 Modelos del Proceso

El objetivo de este tema es proporcionar una comprensin de que el proceso de requerimientos: No es actividad discreta anticipada del ciclo de vida del software, sino un proceso inicial sobre el principio de un proyecto y continuamente refinado a lo largo del ciclo de vida del software. Identifica los requerimientos como elementos de configuracin, y los maneja utilizando las mismas prcticas de gestin de configuracin del software como otros productos del ciclo de vida del software. Necesita ser adaptado por la organizacin y el contexto del proyecto.

Particularmente, el tema trata de como las actividades de obtencin, anlisis, especificacin y validacin se configuran para diferentes tipos de proyectos y de restricciones. El tema tambin incluye actividades que proporcionan entrada al proceso de requerimientos, tal como estudios de mercadeo y de viabilidad [Kot00; Rob99; Som97; Som05]

2.2.2 Actores del Proceso

Este tema introduce los roles de las personas que participan en el proceso de requerimientos. Este proceso es fundamentalmente interdisciplinario y el especialista de requerimientos necesita mediar entre el dominio de los involucrados y de los ingenieros del software. Hay a menudo muchas personas involucradas adems del especialista de requerimientos, cada uno de ellos tiene su inters en el software. Los involucrados varan a travs del proyecto, pero siempre incluyen usuario/operador y clientes (quienes no necesitan ser el mismo). [Gog93] Los ejemplos tpicos de los involucrados del software incluyen (pero no restringen) Usuarios: Este grupo abarca a los que utilizan el software. Es a menudo un grupo heterogneo que comprende a personas con diversos roles y requerimientos.

Clientes: Este grupo abarca aqullos han comisionado el software o quien representa el mercado del software de destino. Analistas de mercado: Un producto de mercadeo masivo no tendr un cliente comisionado as que las personas de marketing a menudo necesitan establecer lo que el mercado requiere y actuar como un cliente intermediario. Reguladores: Muchos dominios de aplicacin como por ejemplo el transporte pblico o la banca son regulados. El software en estos dominios debe cumplir con los requerimientos de estas autoridades reguladoras. Ingenieros de software: Estos individuos tienen un inters legtimo en beneficiarse del desarrollo del software, por ejemplo, reutilizando componentes en otros productos. Si, en este escenario, un cliente de un producto particular tiene requerimientos especficos que comprometen el potencial rehso de componentes, entonces los ingenieros de software deben pesar cuidadosamente sus propios intereses contra los del cliente.

No ser posible satisfacer perfectamente los requerimientos de cada involucrado, y es el trabajo de los ingenieros de software negociar los beneficios que son aceptables para los involucrados principales y dentro de presupuestario, tcnico, regulador, y otras obligaciones. Un pre requerimiento para esto es que se identifiquen a todos los involucrados, la naturaleza de sus intereses, y capturen sus requerimientos. [Dav93; Kot00; Rob99; Som97; You01]

2.2.3 Soporte y gestin del proceso

Este tema introduce los recursos de la gestin de los proyectos requeridos y consumidos por el proceso de requerimientos. l establece el contexto para la primera subrea (definicin de la iniciacin y del alcance) del KA de gestin de ingeniera del software. Su propsito principal es hacer el acoplamiento entre las actividades de proceso identificadas en el 2.1 y los problemas de coste, recursos humanos, entrenamiento, y herramientas. [Rob99; Som97; You01]

2.2.4 Calidad y mejora de proceso

Este tema se refiere a la valoracin de la calidad y de la mejora del proceso de los requerimientos. Su propsito es enfocar el rol dominante que el proceso de requerimientos desempea en trminos de costo y tiempo de un producto de software, y de la satisfaccin del cliente con este [Som97]. Esto ayudar a orientar el proceso de requerimientos con estndares de calidad y modelos de mejora de procesos para el software y los sistemas. La calidad del proceso y la mejora se relacionan de cerca con KA de calidad del software y KA Proceso de ingeniera del software. De inters particular estn los problemas de calidad del software, sus atributos y la mediacin, y la definicin de proceso de software. Este tema abarca Cobertura de procesos de requerimientos mediante modelos y estndares de mejora de procesos Estudio comparativo y medida del proceso de los requerimientos y benchmarking. Planeacin e implementacin de mejora[Kot00; Som97; You01]

2.3 Obtencin de Requerimientos

[Dav93; Gog93; Lou95; Pfl01] La obtencin de requerimientos se refiere a de donde vienen los requerimientos del software y cmo el ingeniero de software puede recogerlos. Es la primera etapa en la construccin de una comprensin del problema del software que se requiere solucionar. Es fundamentalmente una actividad humana, y es donde se identifican a los involucrados y las relaciones establecidas entre el equipo de desarrollo y el cliente. Tambin se conoce como captura de requerimientos, descubrimiento de requerimientos y adquisicin de requerimientos.

Uno de los aspectos fundamentales de la buena ingeniera de software es que haya buena comunicacin entre los usuarios del software y los ingenieros. Antes de comenzar el desarrollo, los especialistas de requerimientos pueden formar el conducto para esta comunicacin. Ellos deben mediar entre el dominio de los usuarios del software (y otros involucrados) y el mundo tcnico del ingeniero de software.

2.3.1 Fuentes de los requerimientos

[Dav93; Gog93; Pfl01] Los requerimientos tienen muchas fuentes en un tpico software, y es esencial que todas las fuentes potenciales estn identificadas y evaluar el impacto en el proyecto. Este tema se disea para promover el conocimiento de varias fuentes de requerimientos del software y de los frameworks para manejarlos. Los puntos principales cubiertos son: Metas: El trmino meta (a veces llamada finalidad del negocio o factor del critico del xito) se refiere sobretodo, a los objetivos de alto nivel del software. Las metas proporcionan la motivacin para el software, pero a menudo son formuladas vagamente. Los ingenieros del software necesitan prestar particular atencin a valorar (concerniente a prioridad) y costear las metas. Un estudio de viabilidad es relativamente una manera de bajo costo para hacer esto. [Lou95]. Conocimiento del dominio: Los ingenieros del software necesitan adquirir, o tener disponible, conocimiento sobre el dominio de aplicacin. Esto permite deducir el conocimiento que los involucrados no articularon, ni valoraron los costos que sern necesarios entre los requerimientos contradictorios, y, a veces, para actuar como un usuario experto. Involucrados: (ver tema 2.2 actores de proceso). Mucho software se ha probado de manera insatisfactoria porque este ha resaltado los requerimientos de un grupo de involucrados a expensas de los de otros. Por lo tanto, se entrega un software que es difcil de utilizar o que derriba las estructuras culturales o polticas de la organizacin del cliente. Los ingenieros del software necesitan identificar, representar, y manejar los puntos de vista de muchos diversos tipos de involucrados. [Kot00] El entorno operacional: Los requerimientos sern derivados del ambiente en el cual el software ser ejecutado. stos pueden ser, por ejemplo, restricciones de tiempo en software de tiempo real o restricciones de interoperabilidad en un ambiente de oficina. stos deben ser activamente buscados, porque pueden afectar grandemente a la viabilidad y el costo del software, y restringen las opciones de diseo. [Tha97] El entorno organizacional: El software se requiere a menudo para apoyar un proceso del negocio, la seleccin de este se puede condicionar por la estructura, la cultura, y la poltica interna de la organizacin. Los ingenieros del software necesitan ser sensibles a stos, puesto que, el nuevo software no debe forzar generalmente cambios imprevistos en el proceso del negocio.

2.3.2 Tcnicas de obtencin de requerimientos

[Dav93; Kot00; Lou95; Pfl01] Una vez que se hayan identificado las fuentes de los requerimientos, los ingenieros de software pueden comenzar a obtener los requerimientos de ellas. Este tema se concentra en las tcnicas para conseguir que los involucrados articulen sus requerimientos. Es un rea muy difcil y los ingenieros de software necesitan sensibilizarse al hecho que (por ejemplo) los usuarios pueden tener dificultad para describir sus tareas, puede dejar la informacin importante sin especificar, o pueden estar poco dispuestos o cooperar. Es particularmente importante entender que la obtencin no es una actividad pasiva, y que, incluso las partes interesadas deben estar disponibles para articular y cooperar. Los ingenieros del software tienen que trabajar duro para obtener la informacin adecuada. Existe un nmero de tcnicas para hacer esto, las principales son [Gog93] Entrevista: Un medio tradicional de obtener requerimientos. Es importante entender las ventajas y limitaciones de las entrevistas y cmo deben ser conducidas.

10

 Escenarios: Valiosos medios para proporcionar contexto a los requerimientos del usuario. Ellos permiten a los ingenieros del software proveer un marco de trabajo para cuestionar acerca de tareas de usuario por medio de preguntas como que ocurre si y cmo se hace esto. El tipo ms comn de escenario es el caso de uso. Hay un vnculo aqu con el tema (Modelo conceptual) porque la notacin de escenarios tales como los casos de uso y los diagramas son comunes en el modelado de software. Prototipos: Una herramienta valiosa para clarificar requerimientos confusos. Pueden actuar de una manera similar a los escenarios, proveyendo a los usuarios con un contexto dentro del cul pueden entender mejor la informacin que necesitan proporcionar. Hay un amplia gama de tcnicas de prototipado, desde bocetos de papel de diseos de pantalla, hasta versiones de prueba beta de productos software y una fuerte relacin de su uso para la obtencin de los requerimientos y el uso de prototipos para la validacin de los requerimientos (vase el tema 6.2 Prototipado). Reuniones de Facilitacin: El propsito de estas es intentar alcanzar un efecto aditivo por el que un grupo de personas puede obtener ms visin en los requerimientos del software que trabajado individualmente. Ellos pueden inspirarse y refinar las ideas que pueden ser difciles de traer a la superficie usando entrevistas. Otra ventaja es que se deje a los involucrados reconocer donde hay requerimientos en conflicto. Cuando se aplica bien, esta tcnica puede resultar en un rico y constante sistema de requerimientos que difcilmente sera realizable de otro modo. Sin embargo, las reuniones necesitan ser manejadas cuidadosamente (por lo tanto es necesario un facilitador) para evitar que una situacin que puede ocurra donde las capacidades crticas del equipo son erosionadas por lealtad del grupo, o los requerimientos reflejan de la poca franqueza de las personas y favoreciendo. Observacin: La importancia del contexto del software dentro del ambiente de organizacin ha conducido a la adaptacin de las tcnicas de observacin para la obtencin de los requerimientos. Los ingenieros del software aprenden sobre las tareas del usuario sumergindose en la observacin de cmo los usuarios obran recprocamente con su software. Estas tcnicas son relativamente costosas, pero son instructivas porque ilustran que muchas tareas del usuario y procesos del negocio son demasiado sutiles y complejas para que sus a personas los describan fcilmente.

2.4 Anlisis de requerimientos

[Som05] Este tema se refiere al proceso de analizar requerimientos para: Detectar y resolver los conflictos entre los requerimientos Descubrir los lmites del software y cmo debe interactan con su ambiente Elaborar los requerimientos del sistema para derivar requerimientos del software La vista tradicional del anlisis de requerimientos ha sido que est reducida al modelado conceptual utilizando uno de varios mtodos de anlisis tales como Tcnicas de Anlisis y Diseo Estructurado y (SADT). Mientras que el modelado conceptual es importante, nosotros incluimos la clasificacin de requerimientos para ayudar a informar beneficios entre los requerimientos (clasificacin de requerimientos) y el proceso de establecer estos beneficios (negociacin de los requerimientos). [Dav93] Se debe tener cuidado para describir requerimientos con exactitud, suficientemente como para permitir que los requerimientos sean validados, su implementacin sea verificada, y sus costes estimados.

2.4.1 Clasificacin de los requerimientos

[Dav93; Kot00; Som05] Los requerimientos pueden ser clasificados en un nmero de dimensiones. Los ejemplos incluyen:

11

Si el requerimiento es funcional o no funcional (vase el tema 1.3 requerimientos funcionales y no funcionales). Si el requerimiento est derivado de uno o ms requerimientos de alto nivel o una propiedad emergentes (vase las caractersticas emergentes del tema 1.4) o est impuesto directamente ante el software por un involucrado u otra fuente. Si el requerimiento es sobre en el producto o sobre el proceso. Los requerimientos sobre el proceso pueden restringir la eleccin de promovedores, a adaptar el proceso de ingeniera del software o los estndares que an sido adheridos. La prioridad del requerimiento. Generalmente la ms alta prioridad, la ms esencial es el requerimiento para satisfacer las metas finales del software. A menudo clasificado en una escala de punto fijo tal como obligatorio, altamente deseable, deseable u opcional, la prioridad a menudo tiene que ser equilibrada con el coste de desarrollo e implementacin. El alcance del requerimiento. El alcance se refiere al grado al cual un requerimiento afecta el software y componentes del software. Algunos requerimientos, particularmente los no funcionales, tienen un alcance global que no puede ser asignado a un componente discreto. Por lo tanto, el requerimiento con alcance global puede afectar fuertemente a la arquitectura del software y el diseo de muchos componentes, mientras que uno puede con un alcance estrecho ofrecer un nmero de opciones del diseo y no afectar demasiado a la satisfaccin de otros requerimientos. Volatilidad/estabilidad. Algunos requerimientos cambiarn durante el ciclo de vida del software, y nivelarse durante el proceso de desarrollo. Es til hacer estimaciones de la probabilidad de que un requerimiento cambie. Por ejemplo, en una aplicacin bancaria, los requerimientos para las funciones que calculan los intereses de las cuentas de usuario son mas estables que los requerimientos para soportar un tipo particular de cuenta exenta de impuestos. Lo anterior refleja una caracterstica fundamental del dominio de las actividades bancarias (esas cuentas pueden ganar intereses), mientras que el ltimo se puede dejar obsoleto por un cambio en la legislacin del gobierno. Sealar requerimientos potencialmente voltiles puede ayudar al ingeniero del software a establecer un diseo que sea ms tolerante al cambio.

Otras clasificaciones pueden ser apropiadas, dependiendo de la prctica normal y del uso que se le d. Hay un fuerte solapamiento entre la clasificacin de los requerimientos y las cualidades de los requerimiento (vase las cualidades de los requerimiento del punto 7.3).

2.4.2 El modelo conceptual

[Dav93; Kot00; Som05] El desarrollo de modelos de un problema del mundo real es clave para el anlisis de requerimientos del software. Su propsito es ayudar a entender el problema, ms que iniciar el diseo de la solucin. Por lo tanto, modelos conceptuales abarcan modelos de entidades desde el dominio del problema, configurados para reflejar sus relaciones y dependencias con el mundo real. Varias clases de modelos pueden ser desarrollados. stos incluyen flujos de datos y de controlan, modelos de estado, seguimientos de evento, interacciones con el usuario, modelos de objeto, modelos de datos y muchos otros. Los factores que influyen en la seleccin del modelo incluyen: La naturaleza del problema. Algunos tipos de software exigen que ciertos aspectos estn analizados rigurosamente. Por ejemplo, los flujos de control y los modelos de estado son probablemente ms importantes para el software en tiempo real que para el software de gestin de informacin, mientras que es generalmente lo contrario para los modelos de datos. La experticia del ingeniero del software . Es a menudo ms productivo adoptar un modelo de notacin o un mtodo de notacin con el cual el ingeniero del software tenga una experiencia.

12

 Los requerimientos de proceso del cliente. Los clientes pueden imponer su notacin o mtodo favorecido, o prohibir cualquiera que le sea desconocido. Este factor puede estar en conflicto con el factor anterior. La disponibilidad de mtodos y de herramientas. Notaciones o mtodos que son mal apoyados por el entrenamiento y las herramientas pueden no alcanzar la aceptacin esperada aunque se satisfagan tipos particulares de problemas. Ntese que, en casi todos los casos, es til comenzar construyendo un modelo de contexto del software. El contexto del software proporciona una conexin entre el software previsto y su ambiente externo. Esto es crucial para entender el contexto del software en su ambiente operacional e identificar sus interfaces con el ambiente. El tema de modelado se junta firmemente con la de los mtodos. Para los propsitos prcticos, un mtodo es una notacin (o sistema de notaciones) apoyada por un proceso que dirige la utilizacin de la notacin. Hay escasa evidencia emprica para apoyar las demandas de superioridad de una notacin sobre otra. Sin embargo, la extensa aceptacin de un mtodo o de una notacin particular puede conducir a nivel industrial al beneficio de habilidades y de conocimientos. sta es actualmente la situacin con el UML (Lenguaje de Modelado Unificado). (UML04) El modelado formal usa notaciones basadas en matemtica discreta, y que son detectables al razonamiento lgico, han tenido impacto en algunos dominios especializados. stos puede ser impuesto por los clientes o los estndares y puede ofrecer ventajas que obligan al anlisis de ciertas funciones o componentes crticos. Este tema no busca ensear un estilo o una notacin de modelado particular sino proporcionar una gua con el propsito de modelar. Dos estndares proporcionan las notaciones que pueden ser tiles en desarrollo conceptual realizando modelado-IEEE conceptual Std 1320.1, IDEF0 para el modelado funcional; e IEEE Std 1320.2, IDEF1X97 (IDEFObject) para modelado de la informacin.

2.4.3 Asignacin de requerimientos y diseo arquitectnico

[Dav93; Som05] En un cierto punto, la arquitectura de la solucin debe ser derivada. El diseo arquitectnico es el punto en el cual el proceso de requerimientos se solapa con el diseo de software o sistema e ilustra cuan imposible es desacoplar ambas tareas. [Som01]. Este tema est relacionado de cerca con el captulo de estructura y arquitectura del software en el KA del diseo del software. En muchos casos, el ingeniero del software acta como arquitecto del software porque el proceso de analizar y de elaborar los requerimientos exige que los componentes que sern responsables de satisfacer los requerimientos estn identificados. Esto es asignar responsabilidad a un componente para la satisfaccin del requerimiento. La asignacin es importante para permitir un anlisis detallado de requerimientos. Por ejemplo, una vez un sistema de requerimientos se han asignado a un componente, los requerimientos individuales se pueden analizar ms a fondo para descubrir otros requerimientos de cmo el componente necesita interactuar con otros componentes para satisfacer los requerimientos asignados. En proyectos grandes, la asignacin estimula un nuevo anlisis para cada subsistema. Como ejemplo, requerimientos para el funcionamiento de los frenos de un carro (distancia que frena, seguridad en condiciones en que conducen, suavidad del uso, la presin del pedal requerida, y as sucesivamente) se puede asignar un hardware que frena (montajes mecnicos e hidrulicos) y un sistema de frenos antibloqueo (ABS). Solamente cuando un requerimiento para un sistema de frenos antibloqueo ha sido identificado, y los requerimientos asignados a l, pueden usarse las del ABS, el hardware de frenado identificado, y las caractersticas indefinidas (tales como el peso del coche) para identificar los requerimientos detallados del software del ABS. El diseo arquitectnico se identifica de cerca con el modelado conceptual. El mapeado desde las entidades del dominio del mundo real hasta los componentes del software no siempre es obvio, as que el diseo arquitectnico se identifica como un tema separado. Los requerimientos de notaciones y los mtodos son ampliamente iguales para el modelado conceptual y el diseo arquitectnico.

13

IEEE Std 1471-2000, prctica recomendada para la descripcin arquitectnica de sistemas orientados al software, sugiere un enfoque de las mltiples vistas para describir la arquitectura de sistemas y de sus tems del software. (IEEE1471-00)

2.4.4 Negociacin de requerimientos

Otro trmino comnmente utilizado para este tema es resolucin del conflicto. Esto se refiere a problemas de resolucin de los requerimientos donde los conflictos ocurren entre dos involucrados que requieren caractersticas mutuamente incompatibles, entre los requerimientos y los recursos, o en entre requerimientos funcionales y no funcionales, por ejemplo. [Kot00, Som97] en la mayora de los casos, es imprudente para el ingeniero del software tomar una decisin unilateral, y hace necesario consultar con los involucrados para alcanzar un consenso en una compensacin apropiada. Es a menudo importante por esas razones contractuales que tales decisiones sean identificables de nuevo al cliente. Hemos clasificado esto como tema de anlisis de requerimientos del software porque los problemas emergen como resultado del anlisis. Sin embargo, un caso extremo se puede tambin hacer para considerar los requerimientos como tema de validacin.

2.5 Especificacin de requerimientos

Para la mayora de las profesiones de la ingeniera, el trmino especificacin se refiere a la asignacin de valores o lmites numricos para metas del diseo del producto. (Vin90) Los sistemas fsicos tpicos tienen un nmero relativamente pequeo de tales valores. Tpicamente el software tiene una gran cantidad de requerimientos, y el nfasis se comparte entre la ejecucin de la cuantificacin numrica y el manejo de la complejidad de la interaccin entre el gran nmero de requerimientos. As pues, en software el trmino, especificacin de requerimientos del software se refiere tpicamente a la produccin de un documento, o a su equivalente electrnico, que puede estar sistemticamente repasado, evaluado, y aprobado. Para los sistemas complejos, particularmente sos que implican componentes no-software, se elaboran tres tipos de documentos: definicin del sistema, requerimientos del sistema, y requerimientos del software. Para sistemas simples, solamente el tercero de stos es requerido. Los tres documentos se describen aqu, entendiendo que combinados pueden ser apropiados. Una descripcin de la ingeniera de sistemas se puede encontrar en el Captulo 12, disciplinas relacionadas de la tecnologa de dotacin lgica.

2.5.1 El documento de la definicin de sistema

Este documento (conocido a veces como documento de requerimientos del usuario o concepto de operaciones) registra los requerimientos del sistema. Define los requerimientos del sistema de alto nivel desde la perspectiva del dominio. Su nmero total de lectores incluye los representantes de los usuarios del sistema/clientes (la comercializacin puede desempear estos roles del mercado del software), as que su contenido debe estar en trminos de dominio. El documento enumera los requerimientos del sistema junto con informacin de fondo sobre los objetivos totales para el sistema, su ambiente de misin y una declaracin de apremios, asunciones, y requerimientos no funcionales. Puede incluir los modelos conceptuales diseados para ilustrar el contexto del sistema, panoramas del uso y las entidades principales del dominio, as como datos, la informacin, y el flujo del trabajo. IEEE Std 1362, concepto del documento de las operaciones, proporciona consejo sobre la preparacin y contenido de tal documento. (IEEE1362-98)

2.5.2 Especificacin de requerimientos del sistema

[Dav93; Kot00; Rob99; Tha97] Desarrolladores de sistemas con los componentes del software y no-software, un avin de pasajeros moderno, por ejemplo, separa a menudo la descripcin de los requerimientos del sistema de la descripcin de los requerimientos del software. En esto se especifica la visin, requerimientos del sistema, los requerimientos del software que se derivan de los requerimientos del sistema, y entonces los requerimientos para los componentes de software

14

se especifican. En sentido estricto, la especificacin de requerimientos del sistema es una actividad de la ingeniera de sistemas y esta fuera del alcance de esta gua. IEEE Std 1233 es una gua para la evolucin de los requerimientos del sistema. (IEEE1233-98)

2.5.3 Especificacin de requerimientos del software

[Kot00; Rob99] La especificacin de requerimientos del software establece la base para el acuerdo entre los clientes y los contratistas o los proveedores (en proyectos del mercado, estos roles se pueden desempear por las divisiones de comercializacin y desarrollo) en los que hay que hacer el producto de software, as como lo que no esperados. Para los lectores no tcnicos, el documento de la especificacin de los requerimientos es acompaado a menudo por un documento de la definicin de los requerimientos del software. La especificacin de requerimientos del software permite un riguroso gravamen de requerimientos antes de que el diseo pueda comenzar y reducir un reajuste final. Debe tambin proporcionar una base realista para estimar costes, riesgos, y cronograma del producto. Las organizaciones pueden tambin utilizar un documento de especificacin de requerimientos de software para desarrollar su propia validacin y que la verificacin sea ms productiva. La especificacin de requerimientos de software proporciona una base informada para transferir un producto de software a los nuevos usuarios o a las mquinas nuevas. Finalmente, puede proporcionar una base para el realce del software. Los requerimientos del software se escriben a menudo en lenguaje natural, pero, en la especificacin de requerimientos del software, sta se puede suplir por formal o semi-formal. La seleccin de notaciones apropiadas permite requerimientos y los aspectos particulares de la arquitectura del software que se describir ms ajustadamente que en lengua natural. La regla general es que las notaciones deben ser utilizadas para que permitan a los requerimientos ser descritos tan exactamente como sea posible. Esto es particularmente crucial para otros tipos de seguridad crtica y casos de software confiable. Sin embargo, la opcin de la notacin es obligada a menudo por el entrenamiento, las habilidades y las preferencias de los autores y de los lectores del documento. Se han desarrollado un nmero de indicadores de la calidad para relacionar la calidad de la especificacin de requerimientos del software a otras variables del proyecto por ejemplo coste, aceptacin, funcionamiento, horario, reproducibilidad, indicadores de la calidad etc. para el individuo las declaraciones de la especificacin de requerimientos del software incluyen imperativos, directorios, frases dbiles, opciones, y continuaciones. Indicadores para el documento de especificacin de requerimientos del software incluye tamao, legibilidad, especificacin, profundidad, y estructura del texto. [Dav93; Tha97] (Ros98) IEEE tiene un estndar, IEEE Std 830 [IEEE830-98], para produccin y contenido de la especificacin de los requerimientos del software. Tambin, IEEE 1465 (similar a ISO/IEC 12119) es un estndar que trata de la calidad de requerimientos en paquetes de software. (IEEE1465-98)

2.6 Validacin de Requerimientos

Los documentos de requerimientos pueden ser objeto los procedimientos de validacin y de verificacin. Los requerimientos pueden ser validados para asegurar que el ingeniero de software ha entendido los requerimientos, y tambin es importante verificar que un documento se ajusta a los requerimientos estndares de la compaa, y que es comprensible, consistente y completo.las notaciones formales ofrecen una ventaja importante que permite las dos ltimas propiedades para ser probado (en sentido restringido, por lo menos). Las diferentes partes interesadas, incluyendo representantes del cliente y desarrollador, deben revisar el documento (s). Los documentos de los requerimientos estn sujetos a la misma gestin configuracin de software a las mismas prcticas de gestin de configuracin de software como otras entregables del ciclo de vida de los procesos del software. (Bry94, Ros98) Es normal planear explcitamente uno o ms puntos en el proceso de los requerimientos donde

15

los requerimientos son validados. El objetivo es recoger cualquier problema antes de que los recursos se comprometan a abordar los requerimientos. La validacin de requerimientos se refiere al proceso de examinar el documento de los requerimientos para asegurarse de que este define el software adecuadamente (es decir, el software que la los usuarios esperan). [Kot00]

2.6.1 Revisin de requerimientos

Tal vez el medio ms comn de validacin se realiza mediante inspeccin o revisiones del documento de requerimientos (s). Un grupo de revisores se le asigna para buscar errores, hiptesis errneas, falta de claridad, y la desviacin de una prctica estndar. La composicin del grupo que lleva a cabo la revisin es importante (al menos un representante del cliente debe ser incluido para proyectos dirigidos por el cliente por ejemplo), y puede ayudar a proporcionar orientacin sobre lo que debe buscar en forma de listas de verificacin. Las revisiones pueden constituirse sobre el final del documento de definicin del sistema, el documento de especificacin del sistema, el documento de especificacin de los requerimientos del software, la lnea de base para la especificacin de una nueva versin, o en cualquier otra pas en el proceso. IEEE Std. 1028 proporciona orientacin sobre la realizacin de estas revisiones. (IEEE1028-97) Las revisiones tambin se tratan en el KA Calidad del Software, el tema 2.3 revisiones y Auditorias.

2.6.2 Prototipado
Prototipos es comnmente un medio para validar interpretacin de los requerimientos del software por parte del ingeniero software, as como para capturar nuevos requerimientos. Al igual que con obtencin de requerimientos, hay una serie de tcnicas de prototipado y un numero de puntos en el proceso donde la validacin de prototipos puede ser apropiado. La ventaja de los prototipos es que pueda hacer que sea ms fcil de interpretar las suposiciones del ingeniero de software y, en caso necesario, dar informacin til sobre por qu estn equivocados. Por ejemplo, la dinmica del comportamiento de una interfaz de usuario se puede entender mejor a travs de un prototipo de animacin que a travs de la descripcin textual o modelos grficos. Tambin hay desventajas, sin embargo. Estos incluyen el peligro de distraer la atencin de los usuarios de la funcionalidad bsica subyacente por cuestiones de esttica o problemas de calidad con el prototipo. Por esta razn, varias personas recomiendan prototipos que eviten el software, tales como bocetos, basada en maquetas. Los prototipos pueden ser costosos para el desarrollo. Sin embargo, si evitan el despilfarro de recursos por tratar de satisfacer los requerimientos errneos, su costo puede ser ms fcilmente justificable.

2.6.3 Validacin del Modelo

No suele ser necesario para validar la calidad de los modelos desarrollados durante el anlisis. Por ejemplo, en el modelo de objeto, es til realizar un anlisis esttico para verificar que las rutas de comunicacin existentes entre objetos, en dominio de las partes interesadas, el intercambio de datos. Si usa notaciones formales de especificaciones se utilizan, es posible el uso formal del razonamiento formal para demostrar las propiedades de la especificacin.

2.6.4 Pruebas de Aceptacin

[Dav93] Una caracterstica esencial de un requerimiento de software es que debera ser posible para validar que el producto final satisface el requerimiento. Requerimientos que no pueden ser validados realmente deseos '. Una tarea importante es por lo tanto planear cmo verificar cada requerimiento. En la mayora de los casos, el diseo de pruebas de aceptacin hace esto. La identificacin y el diseo de pruebas de aceptacin puede ser difcil para los requerimientos no funcionales (ver tema 1.3 funcional y requisitos no funcionales). Para ser validado, primero deben ser analizados hasta el punto en que estos puede expresarse cuantitativamente. Informacin adicional puede encontrarse en la Pruebas de software KA, subtema 2.2.4 Pruebas de Conformidad.

16

2.7 Consideraciones prcticas

El primer nivel de descomposicin de la sub-reas se presentadas en este KA pueden describir una secuencia lineal de actividades. Esta es una visin simplificada del proceso. [Dav93] El proceso de los requerimientos abarca todo el ciclo de vida del software. La Gestin del cambio y el mantenimiento de los requerimientos en un estado que refleja con precisin el software que se construir, o que se ha construido, son claves para el xito del proceso de ingeniera de software. [Kot00; Lou95] No todas las organizaciones tienen una cultura de documentar y la gestionar los requerimientos. Es frecuente en la dinmica puesta en marcha en las empresas, impulsada por un fuerte "visin del producto y limitada por recursos, para ver la documentacin de requerimientos como una sobrecarga innecesaria. Muy a menudo, sin embargo, como estas empresas se expanden, ya que su base de clientes crece, y como su producto empieza a evolucionar, descubren que necesitan recuperar los requerimientos que motivaron caractersticas del producto con el fin de evaluar el impacto de los cambios propuestos. Por lo tanto, la documentacin de los requerimientos y gestin del cambio son claves para el xito de cualquier proceso de los requerimientos.

2.7.1 Naturaleza iterativa del proceso de Requerimientos

Hay una presin general en la industria del software para que todo ciclo de desarrollo sea corto, y esto es particularmente promulgado en los sectores orientados al mercado altamente competitivo. Por otra parte, la mayora de los proyectos estn limitados de alguna manera por su entorno, y muchos son actualizaciones o revisiones de software existente, donde la arquitectura esta dada. En prctica, por lo tanto, es casi siempre muy difcil de aplicar los procesos de los requerimientos como un proceso lineal y determinista en el cual los requerimientos de software son capturados para los interesados, lnea base, asignados, y manejados por el equipo de desarrollo. Es sin duda un mito de que los requerimientos para grandes proyectos de software son siempre perfectamente entendidos o se especifica perfectamente. [Som97] En cambio, los requerimientos suelen iterar hacia un nivel de calidad y el detalle que sea suficiente para permitir el diseo y la las decisiones de contratacin a realizar. En algunos proyectos, esta puede dar lugar a los requisitos de ser lnea de base antes de que todas sus propiedades se en tienden completamente. Se corre el riesgo costoso reproceso, si surgen problemas al final del proceso de ingeniera de software. Sin embargo, los ingenieros de software son necesariamente limitados por los planes de gestin de proyectos y por lo tanto debe tomar medidas para asegurarse de que la "calidad" de los requisitos es tan alta como sea posible con los recursos disponibles. Deben, por ejemplo, hacer explcitas las suposiciones elementos esenciales de las necesidades, as como las conocidas los problemas. En casi todos los casos, la comprensin de los requisitos contina evolucionando a medida que los procesos de diseo y desarrollo avanzan. Esto a menudo conduce a la revisin de los requisitos tarda en el ciclo de vida. Tal vez el punto ms crucial en la comprensin de los requisitos de ingeniera es que una proporcin significativa de los requerimientos van a cambiar. Esto es a veces debido a errores en el anlisis, pero es con frecuencia una consecuencia inevitable de cambio en el ambiente": por ejemplo, el ambiente empresarial o operativo del cliente, o el mercado en la que el software debe vender. Cualquiera que sea la causa, Es importante reconocer la inevitabilidad del cambio y tomar medidas para mitigar sus efectos. El cambio tiene que ser gestionados velando por que los cambios propuestos pasan por un definido proceso de revisin y aprobacin, y, mediante la aplicacin cuidadosa del seguimiento de requerimientos, anlisis de impacto, y el software gestin de la configuracin (ver el software de configuracin Gestin KA). Por lo tanto, proceso de requerimientos no es slo una tarea inicial en el desarrollo de software, sino que abarca todo el ciclo de vida del software completo. En un proyecto tpico, las actividades los requerimientos de software evolucionan con el tiempo desde la obtencin hasta la gestin del cambio.

2.7.2 Gestin del Cambio

[Kot00] La gestin del cambio es fundamental para la gestin de requisitos. En este tema se describe el papel de la gestin del cambio, los procedimientos que deben estar en su lugar, y el anlisis

17

que debe aplicarse a los cambios propuestos. Este tiene fuertes vnculos con AK gestin de configuracin de software KA.

2.7.3 Atributos de los requerimientos

[Kot00] Requisitos debe consistir no slo de una especificacin de lo que se requiere, sino tambin de informacin adicional que 10.02 IEEE - 2004 Versin ayuda a manejar e interpretar los requisitos. Esto debera incluir diferentes dimensiones de clasificacin de requerimientos de (Vase el tema 4.1 Requisitos de clasificacin) y el mtodo de verificacin o un plan de prueba de aceptacin. Se puede tambin incluyen informacin adicional, como un resumen justificacin para cada requerimiento, Los atributos de requisitos ms importantes, sin embargo, es un identificador que permite identificar los requisitos de forma inequvoca y sin ambigedades.

2.7.4 Seguimiento de requerimientos

[Kot00] el seguimiento de requerimientos se refiere a la recuperacin de la fuente de los requerimientos y prediccin de los efectos de los requerimientos. El seguimiento es fundamental para realizar anlisis de impacto cuando las requerimientos de cambian. Un requisito debe ser la trazable hacia atrs con los requisitos y las partes interesadas que lo motivaron (desde un requisito de software hacia atrs hasta requisitos del sistema (s) que ayuda a satisfacerlo, por ejemplo). Por el contrario, un requisito debera ser traceable hacia delante en los requisitos y las entidades de diseo que satisfacer la misma (por ejemplo, desde un requisito del sistema en el requisitos de software que han sido elaborados a partir de este, y en el cdigo de los mdulos que lo implementan). El seguimiento de los requerimientos para un proyecto tpico formara un complejo grafo dirigido a cclico (DAG) de los requisitos.

2.7.5 Medicin de Requerimientos

En la prctica, a menudo es til disponer de algn concepto de volumen de los requisitos para un determinado producto de software. Este nmero es til en la evaluacin el 'tamao' de un cambio en los requisitos, en la estimacin del costo de una tarea de desarrollo o mantenimiento, o simplemente para utilizarse como denominador en otras mediciones. La medida de tamao funcional (FSM) es una tcnica para evaluar el tamao de un conjunto de requerimientos funcionales. IEEE Std. 14.143,1 define el concepto FSM. [IEEE14143.1-00] Normas de ISO / IEC y otras fuentes describen mtodos particulares de FSM Informacin adicional sobre la medida del tamao y las normas se encuentran en el KA Proceso de Ingeniera de Software.

18

3 Diseo de software
SIGLAS LDA Lenguajes de Descripcin de Arquitectura DER Diagramas Entidad-Relacin IDL Interfaz de descripcin de lenguajes DFA Diagrama de flujo de datos PLD Pseudo-cdigo y de Lenguajes Diseo del Programa DBC diseo basado en componentes El diseo es definido en [IEEE610.12-90] tanto como "el proceso de definir la arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente "y" el resultado de [ese proceso]. Visto como un proceso, en la ingeniera de software, el diseo es la actividad del ciclo de vida en la que se analizan los requerimientos de software para producir una descripcin de la estructura interna del software que servir como base para su construccin. Ms precisamente, un diseo de software (el resultado) debe describir la arquitectura del software, es decir, cmo el software se descompone y organizados en los componentes y las interfaces entre esos componentes. Tambin debe describir los componentes en un nivel de detalle que permiten su construccin. El diseo de software juega un papel importante en el desarrollo software: permite a los ingenieros de software: producir varios modelos que forman una especie de prototipo de la solucin que se implementara. Podemos analizar y evaluar estos modelos para determinar si nos van a permitir cumplir con los requerimientos. Tambin se puede examinar y evaluar varias soluciones alternativas para evaluar ventajas y desventajas. Por ltimo, podemos utilizar los modelos resultantes para planificar el desarrollo de actividades, adems de utilizarlos como entrada y punto de partida de construccin y de pruebas. En una lista de modelos de los procesos de ciclo de vida del software IEEE / EIA 12207, tales como los procesos del ciclo de vida del software [IEEE12207.0-96], diseo de software consta de dos actividades que se ajustan entre el anlisis de requerimientos de software y la construccin de software: Diseo arquitectnico de software (A veces llamado diseo nivel superior): describe la estructura de software de nivel superior y la organizacin y la identificacin de los distintos componentes Diseo detallado de software: describiendo cada componente lo suficiente como para permitir su construccin. En cuanto al alcance del rea del conocimiento de diseo de software (AC), la actual descripcin de rea del conocimiento (AC) no discute todos los temas cuyo nombre contenga la palabra "diseo". En la terminologa de Tom DeMarco (DeM99), el rea de Conocimiento (AC) discutida en este captulo trata principalmente el diseo (la descomposicin diseo, asignacin de partes de componentes de software). Sin embargo, debido a su importancia en el creciente campo de la arquitectura software, tambin se ocupar del diseo (Familias patrones de diseo). Poe el contario el rea del conocimiento de diseo de software no se ocupa de que el diseo (lnea del diseo, generalmente se realiza durante el proceso de requerimientos de software con el objetivo de conceptualizar y especificando el software para satisfacer las necesidades descubiertas y requerimientos), ya que este tema debe ser considerado parte de los requerimientos anlisis y especificacin de condiciones. La descripcin del rea de conocimiento de diseo de software esta relaciona especficamente con los requerimientos de Software, Construccin de Software, Gestin de Ingeniera de software, Calidad de Software y dems disciplinas relacionadas con la Ingeniera de Software.

19

Desglose de temas para el Diseo de Software

3.1 Fundamentos de diseo de software

Los conceptos, nociones y terminologa introducida aqu constituyen una base fundamental para el conocimiento del papel y alcance del diseo de software

3.1.1 Conceptos generales de diseo.

El software no es el nico campo donde se tratara el diseo. En el sentido general, podemos considerar el diseo como una forma de resolucin de problemas. [Bud03:c1] Por ejemplo, el concepto de un malicioso problema-un problema sin solucin definitiva, es interesante en trminos de comprensin de los lmites de diseo. [Bud04:c1] Un nmero de otras nociones y conceptos son tambin de inters en el entendimiento del diseo en su sentido general: objetivos, limitaciones, alternativas, representaciones y soluciones. [Smi93]

3.1.2 Contexto del Diseo de Software

Para entender el papel del diseo de software, es importante comprender el contexto en el que se sita, el ciclo de vida de ingeniera del software. Por lo tanto, es importante entender las principales caractersticas de anlisis de requisitos de software vs diseo de software vs construccin de software vs pruebas de software. [IEEE12207.0-96]; Lis01:c11; Mar02; Pfl01:c2; Pre04:c2]

3.1.3 Procesos de diseo de Software

El diseo de software se considera generalmente un proceso de dos pasos: [Bas03; Dor02:v1c4s2; Fre83: I; IEEE12207.0-96]; Lis01:c13; Mar02: D]

3.1.3.1

El diseo arquitectnico

El diseo arquitectnico describe cmo el software es descompuesto y organizado en componentes (La arquitectura de software) [IEEEP1471-00]

3.1.3.2

Diseo detallado
se describe como el comportamiento especfico de

El diseo detallado estos componentes.

El resultado de este proceso es un conjunto de modelos y artefactos que registran las decisiones ms importantes que se han adoptado. [Bud04:c2; IEE1016-98; Lis01:c13; Pre04:c9]

3.1.4 Principios de diseo

Segn el Diccionario Ingls de Oxford, un principio es "Una verdad bsica o una ley general... que es usada como base para el razonamiento o una gua para la accin". Los principios de diseo de software, tambin se llama tcnicas disponibles [Bus96], son nociones clave que se consideran fundamentales para muchos diferentes enfoques y conceptos de diseo de software. Los principios son los siguientes: [Bas98:c6; Bus96:c6; IEEE1016-98; Jal97:c5,c6; Lis01:c1,c3; Pfl01:c5; Pre04:c9]

3.1.4.1

Abstraccin

La abstraccin es "el proceso de descomposicin de la informacin para que las cosas que son diferentes pueden ser tratados como si fueran los mismos. " [Lis01] En el contexto de diseo de software, hay dos mecanismos de abstraccin clave: parametrizacin y especificacin. La abstraccin por especificacin da lugar a tres tipos principales de abstraccin: de

20

procedimientos, de datos, y de control (iteracin) [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1]

3.1.4.2

Acoplamiento y cohesin

Acoplamiento se define como la fuerza de la relaciones entre los mdulos, mientras que la cohesin se define por la relacin entre los elementos que componen un mdulo [Bas98:c6; Jal97:c5; Pfl01:c5; Pre04:c9]

3.1.4.3

La descomposicin y la modularizacin

Descomposicin y modularizacin de un software de gran tamao, en un nmero de pequeos programas independependientes, por lo general con el objetivo de ubicar diferentes funcionalidades o responsabilidades sobre los diferentes componentes [Bas98:c6; Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9]

3.1.4.4

Encapsulacin / ocultamiento de informacin

Encapsulacin / ocultacin de informacin significa agrupar y empaquetar los elementos y los detalles internos de una abstraccin y haciendo estos detalles inaccesibles. [Bas98:c6; Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9]

3.1.4.5

Separacin de la interfaz y de la implementacin

La separacin de la interfaz y de la implementacin, implica la definicin de un componente mediante la especificacin de un interfaz pblica, conocida por los clientes, separada de los detalles de cmo el componente es realizado. [Bas98:c6; Bos00:c10; Lis01:c1, c9]

3.1.4.6

Suficiencia, completitud y primitivismo

El logro de la suficiencia, completitud, y primitivismo significa garantizar que un componente de software capture todas las caractersticas importantes de una abstraccin, y nada ms [Bus96:c6; Lis01:c5]

3.2 Problemas claves en el diseo de software

Una serie de asuntos fundamentales deben ser tratados en el diseo de software. Algunos son problemas de calidad que todo el software debe incluir por ejemplo el rendimiento. Otro importante asunto es cmo se descomponen, organizan y constituyen los paquetes de software. Esto es tan fundamental que todos los enfoques del diseo deben tratarlo de un modo u otro (Vase el tema 1.4 Principios de diseo y la sub-rea 6 mtodos y estrategias de diseo de software). En cambio, otros asuntos se ocupan de un cierto aspecto del comportamiento del software que no est en el dominio de la aplicacin pero que abordan algunas de los dominios de soporte". [Bos00] Estos asuntos que a menudo son aspectos transversales de la funcionalidad del sistema. Que han hecho referencia a aspectos como: Aspectos que no tienden a ser unidades funcionales de descomposicin de software, sino ms bien a ser propiedades que afectan al rendimiento o la semntica de los componentes de forma sistemtica (Kic97. Algunas de estos asuntos transversales fundamentales, son los siguientes (Presentados en orden alfabtico):

3.2.1 Concurrencia
Cmo descomponer el software en procesos, tareas e hilos y tratar temas relacionados con la eficiencia, la atomicidad, la sincronizacin, y los asuntos de planificacin . [Bos00: c5; Mar02: CDS; Mey97: C30; Pre04: c9]

3.2.2 Control y Manejo de Eventos

Cmo organizar los datos y controlar el flujo, cmo manejar eventos reactivos y temporales a travs de diversos mecanismos, tales como invocacin implcita y call-back. [Bas98: c5; Mey97: C32; Pfl01: c5]

21

3.2.3 Distribucin de los componentes

Cmo distribuir el software a travs hardware, cmo los componentes se comunican, como el middleware puede ser usado para tratar con el software heterogneo. [Bas03: C16; Bos00: c5; Bus96: c2 Mar94: DD; Mey97: C30; Pre04: C30]

3.2.4 Manejo de errores ,excepciones y tolerancia a fallos

Cmo prevenir y tolerar los fallos y hacer frente a condiciones excepcionales. [Lis01: c4; Mey97: c12; Pfl01: c5]

3.2.5 Interaccin y Presentacin

Cmo estructurar y organizar las interacciones con los usuarios y la presentacin de la informacin (Por ejemplo, la separacin de presentacin y lgica de negocio utilizando el enfoque modelo-vista-controlador). [Bas98:c6; Bos00:c5; Bus96:c2; Lis01:c13; Mey97:c32] Cabe sealar que este tema no trata de especificar los detalles de interfaz de usuario, que es una tarea del diseo de interfaz de usuario (una parte de ergonma del software); ver disciplinas afines de la ingeniera de software

3.2.6 Persistencia de datos

Cmo manejar los datos a larga vida. [Bos00:c5; Mey97:c31]

3.3 Estructura y Arquitectura de Software

En su sentido estricto, una arquitectura de software es "una descripcin de los subsistemas y componentes de un sistema de software y las relaciones entre ellos. (Bus96: c6) La arquitectura por lo tanto intenta definir la estructura interna del software resultante. Segn el Diccionario Ingls de Oxford, "La forma en que algo se construye u organizada". A mediados de la dcada de 1990, sin embargo, la arquitectura de software comenz a emerger como una disciplina ms amplia que involucra el estudio de las estructuras de software y arquitecturas en una forma ms genrica [Sha96]. Esto dio lugar a una serie de ideas interesantes sobre el diseo de software en diferentes niveles de abstraccin. Algunos de estos conceptos pueden ser tiles durante el diseo arquitectnico (Por ejemplo, el estilo arquitectnico) de software especfico, as como en su diseo de detallado (por ejemplo, patrones de bajo nivel de diseo). Pero tambin puede ser til para el diseo de sistemas genricos, conduciendo al diseo de familias de los programas (Tambin conocidos como lneas de producto). Curiosamente, la mayora de estos conceptos pueden ser vistos como intentos para describir y reutilizar, el conocimiento de diseo genricos.

3.3.1 Estructuras Arquitectnicas y puntos de vista

Las diferentes facetas del diseo de software de alto nivel pueden y deben ser descritas y documentadas. Estas facetas son a menudo llamados vistas: "Una vista representa un aspecto parcial de una arquitectura de software que muestra las propiedades especficas de un sistema de software "[Bus96: C6]. Estos distintas vista se refieren a temas distintos relacionados con el diseo de software, por ejemplo, la vista lgica (Que cumple los requerimientos funcionales) vs vista de procesos (problemas de concurrencia) vs vista fsica (problemas de distribucin) vs vista de desarrollo (cmo el diseo se descompone en unidades de ejecucin). Otros autores utilizan diferentes terminologas como: vista de comportamiento vs funcionalidad vs estructura vs modelo de datos. En resumen, un diseo de software es un artefacto de mltiples facetas producidas por el proceso de diseo y, en generalmente compuesto de vistas relativamente independientes y ortogonales. [Bas03:c2; Boo99:c31; Bud04:c5; Bus96:c6; IEEE1016-98; IEEE1471-00] Estilos arquitectnicos (patrones macro arquitectnicos) Un estilo arquitectnico es "un conjunto de restricciones en una arquitectura [que] define un conjunto o familia de arquitecturas que los satisfaga " [Bas03: c2]. Un estilo arquitectnico por lo tanto puede ser visto como un meta-modelo que provee una organizacin software de alto nivel (su Macro Arquitectura). Varios autores han identificado algunos de los principales estilos arquitectnicos. [Bas03: c5; Boo99: C28; Bos00: c6; Bus96: c1, c6; Pfl01: c5]

22

Estructura general (por ejemplo, las capas, las tuberas y los filtros, black-board) Sistemas distribuidos (por ejemplo, cliente-servidor, tres niveles, broker) Sistemas interactivos (por ejemplo, Model0-Vista-Controdor, Presentacin-AbstraccinControl) Sistemas adaptable (por ejemplo, micro-kernel, reflexin) Otros (por ejemplo, basado en reglas). por lotes, los intrpretes, control de procesos,

3.3.2 Patrones de diseo (patrones micro arquitectnicos)

Resumido brevemente, un patrn es "una solucin comn a un problema comn en un contexto dado". (Jac99) Mientras que los estilos arquitectnicos se pueden ver como los patrones que describen la organizacin de software de alto nivel (Su Macro Arquitectura), otros patrones de diseo se puede utilizar para describir los detalles en un nivel menor, ms local (su micro arquitectura).[Bas98: c13, Boo99: C28; Bus96: c1; Mar02: DP] Patrones de creacin (por ejemplo, constructor, fbrica, prototipo, y semifallo) Patrones estructurales (por ejemplo, adaptador, el puente, compuesto fachada, flyweight, y proxy) Patrones de comportamiento (por ejemplo, dominio, intrprete, iterador, mediador, recuerdo, observador, estado, la estrategia, plantilla, visitante)

3.3.3 Las familias de los programas y Frameworks

Un enfoque posible para permitir la reutilizacin de diseos y componentes de software es el diseo de familias de software, tambin conocido como lneas de producto de software. Esto puede hacerse mediante la identificacin de los puntos en comn entre los miembros de estas familias y mediante el uso de componentes reutilizables y personalizables para dar cuenta de la variabilidad entre los miembros de la familia [Bos00:c7,c10; Bas98:c15; Pre04:c30] En la programacin orientada a objetos, un concepto clave es el Frameworks: un subsistema software parcialmente completo que puede ser ampliado instalando apropiadamente complementos especficos (Tambin conocidos como puntos calientes). [Bos00:c11; Boo99:c28; Bus96:c6].

3.4 Anlisis y evaluacin de la calidad del diseo del software

En esta seccin se incluye una serie de temas de calidad y evaluacin que estn especficamente relacionados con el diseo de software. La mayora estn cubiertos de manera general en el rea del conocimiento (KA) Calidad del Software.

3.4.1 Atributos de Calidad

Varios son los atributos generales que consideran importantes para obtener un diseo de software de buena calidad (Mantenibilidad, portabilidad, capacidad de prueba, la trazabilidad), varias "debilidades" (correccin, robustez), incluyendo "la aptitud de propsito". [Bos00:c5; Bud04:c4; Bus96:c6; ISO9126.1-01; ISO15026-98; Mar94:D; Mey97:c3; Una interesante distincin es la que existe entre los atributos de calidad apreciable en tiempo de ejecucin (Rendimiento, seguridad, disponibilidad, funcionalidad, facilidad de uso), los que no son discernible en tiempo de ejecucin (Modificabilidad, portabilidad, reusabilidad, integrabilidad y capacidad de prueba), y las relacionadas a las cualidades intrnsecas de la arquitectura (Integridad conceptual, correccin, integridad, construbilidad). [Bas03: c4]

23

3.4.2 Anlisis de la Calidad y Tcnicas de Evaluacin

Diversas herramientas y tcnicas pueden ayudar a garantizar la calidad de un diseo de software. Revisiones de diseo de software: informal o semiformal, a menudo basada en grupos, las tcnicas para comprobar y garantizar la calidad de artefactos de diseo (Por ejemplo, revisiones de arquitectura [Bas03: C11], revisiones de diseo e inspecciones [Bud04: c4; Fre83:VIII; IEEE1028-97; Jal97:c5,c7; Lis01:c14; Pfl01:c5], tcnicas basadas en escenarios [Bas98:c9; Bos00:c5], seguimiento de requerimientos [Dor02:v1c4s2; Pfl01:c11]) Anlisis esttico: formal o semiformal esttica (No ejecutable) anlisis que se pueden utilizar para evaluar un diseo (Por ejemplo, el anlisis de rbol de fallos o comparacin automatizada) Simulacin y prototipado: tcnicas dinmicas para evaluar un diseo (Por ejemplo, la simulacin de rendimiento o prototipo de viabilidad [Bas98: c10; Bos00: c5; Bud04: c4; Pfl01: c5])

3.4.3 Medidas
Las medidas pueden ser utilizadas para evaluar o estimar cuantitativamente diversos aspectos del tamao de un diseo de software, estructura, o la calidad. La mayora de las medidas que se han propuesto por lo general dependen del enfoque utilizado para la produccin del diseo. Estas medidas se clasifican en dos grandes categoras: Medidas de diseo orientadas a funcin (Estructurado): la estructura del diseo, obtenidos principalmente a travs de la descomposicin funcional; generalmente representado como un grfico de la estructura (A veces llamado un diagrama jerrquico) en el que las diversas medidas se pueden calcular [Jal97: C5, C7, Pre04: C15] Medidas de diseo orientado a objetos: La estructura general del diseo es a menudo representado como un diagrama de clase, en el que las diversas medidas se pueden calcular. Las medidas de las propiedades del contenido interno de cada clase tambin se puede calcular [Jal97:c6, c7; Pre04:c15]

3.5 Notaciones del diseo de software

Muchas notaciones y lenguajes existen para representar los artefactos del diseo de software. Algunos se utilizan principalmente para describir un diseo de organizacin estructural del diseo, otros para representar el comportamiento software. Algunas notaciones se utilizan sobre todo en el diseo arquitectonico y otros, principalmente durante el diseo detallado. Aunque algunas notaciones pueden ser utilizadas en ambas etapas. Adems, algunas notaciones se utilizan sobre todo en el contexto especfico de los mtodos (ver las estrategias de diseo de software y Mtodos). En este caso, se clasifican las notaciones para describir la estructura (esttica) vs. El comportamiento (Dinmico).

3.5.1 Descripcin Estructural (Vista esttica)

Las siguientes notaciones sobre todo (pero no siempre) grfica. Describe y representa los aspectos estructurales del diseo de software, es decir, se describen los principales componentes y la forma en que se interconectan. Lenguajes de descripcin de arquitecturas (ADLs): Textuales, tienden a ser formales, lenguajes usados para describir una arquitectura de software en trminos de componentes y conectores. [Bas03:c12]. Diagramas de clases y de objetos: Usado para representar un conjunto de clases (y objetos) y sus interrelaciones. [Boo99:c8,c14; Jal97:c5,c6].

24

Diagramas de componentes: Usado para representar un conjunto de componentes ("Parte fsica y reemplazable [s] de un sistema que [conforme] y [proporcionar] la realizacin de un conjunto de las interfaces " [Boo99]) y sus interrelaciones [Boo99:c12,c31]. Tarjetas de clase responsabilidad y colaboracion (CRCs): Usadas para indicar los nombres de los componentes (clase), sus responsabilidades, y los nombres de los componentes que colaboran " [Boo99: c4; Bus96]. Diagramas de Despliege: Usados para representar un conjunto de nodos (Fsica) y sus interrelaciones, y, por tanto, para moldear los aspectos fsicos de un sistema [Boo99: C30]. Diagramas de entidad-relacin (ERDs): utilizados para representar los modelos conceptuales de los datos almacenados en sistemas de informacin [Bud04: c6; Dor02: v1c5; Mar02: RD]. Lenguajes descripcin de Interfaz (IDLs): Lenguajes de programacin que se utilizan para definir las interfaces (nombres y tipos de operaciones de exportacin) de los componentes de software [Bas98: c8, Boo99: C11]. Diagramas de estructurales de Jackson: se utiliza para describir las estructuras de datos en trminos de secuencia, seleccin e iteracin [Bud04: c6; Mar02: RD]. Diagramas de estructura: se utiliza para describir la estructura de llamada de los programas (En el cual describe el llamado de los mdulos, y como un modulo es llamado por otro modulo) [Bud04: c6; Jal97: c5; Mar02: DR;Pre04: C10].

3.5.2 Descripcin del comportamiento

Las siguientes notaciones y los lenguajes, algunos grficos y algunos textos, se utilizan para describir el comportamiento dinmico del software y componentes. Muchas de estas notaciones son tiles sobre todo durante el diseo detallado, pero no exclusivamente. Diagramas de actividad: utilizado para mostrar el flujo de control de una actividad ("En curso de ejecucin no atmica dentro de un estado mquina ") a otra actividad [Boo99: C19]. Diagramas de colaboracin: utiliza para mostrar el resultado de las interacciones que se producen entre un grupo de objetos, sus vnculos, y los mensajes de intercambio en estos enlaces [Boo99: C18]. Diagramas de flujo de datos (DFDs): utiliza para mostrar el flujo de datos entre un conjunto de procesos [Bud04: c6; Mar02: DR; Pre04: c8]. Diagramas y tablas de decisin: utilizados para representar combinaciones complejas de condiciones y acciones [Pre04: C11]. Diagramas de flujo y diagramas de flujo estructurado: utilizado para representar el flujo de control y las acciones realizadas asociadas [Fre83: VII; Mar02: DR; Pre04: C11]. Diagramas de secuencia: utiliza para mostrar el resultado de las interacciones entre un grupo de objetos, con nfasis en el tiempo-pedido de mensajes [Boo99:c18]. Diagramas de estados y transicin de estdaos: utilizado para mostrar el flujo de control de estado a estado en una mquina de estados [Boo99: C24; Bud04: c6; Mar02: DR; Jal97: c7]. Lenguajes de especificacin formal : lenguajes textuales que utilizan conceptos bsicos de las matemticas (Por ejemplo, lgica, ju, secuencia) de forma rigurosa y abstracta definen el software interfaces, componentes y comportamiento, a menudo en trminos de pre-y post-condiciones [Bud04: C18;Dor02: v1c6s5; Mey97: C11]. Pseudo-cdigo y lenguajes de programacin de diseo (PDLs): Lenguajes estructurados, como los lenguajes de programacin utilizados para describir el

25

comportamiento de un procedimiento o mtodo generalmente en la fase de proyecto. [Bud04: c6; Fre83: VII;Jal97: c7; Pre04: c8, c11].

3.6 Estrategias y Mtodos Diseo de software

Existen varias estrategias generales para ayudar a guiar el proceso de diseo. [Bud04: c9, Mar02: D] En contraste con estrategias generales, los mtodos son ms especficos por lo general sugieren y proporcionan un conjunto de anotaciones para ser utilizado con el mtodo, una descripcin del proceso que se utiliza siguiendo el mtodo y un conjunto de directrices en el uso del mtodo. [Bud04: c8] Estos mtodos son tiles como medio de la transferencia de los conocimientos y como un marco comn para los equipos de ingenieros de software. [Bud03:c8]

3.6.1 Estrategias generales

Algunos ejemplos citados con frecuencia de estrategias generales tiles para el proceso de diseo es divide y vencers, y paso a paso perfeccionamiento [Bud04: c12; Fre83: V], de arriba hacia abajo vs. de abajo hacia arriba estrategia [Jal97: c5; Lis01: C13], de extraccin de datos y ocultamiento de informacin [Fre83: V], el uso de la heurstica [Bud04: c8], uso de patrones y patrones de lenguajes [Bud04: c10; Bus96: c5], uso de un enfoque iterativo e incremental. [Pfl01: c2]

3.6.2 Diseo orientado a funciones(Diseo estructurado)

[Bud04:c14; Dor02:v1c6s4; Fre83:V; Jal97:c5; Pre04:c9, c10] Este es uno de los mtodos clsicos de diseo de software, donde los centros de descomposicin en la identificacin de las principales funciones del software y a continuacin, la elaboracin y refinacin de manera de arriba hacia abajo. Diseo estructurado se utiliza generalmente despus de un anlisis estructurado, lo que produce, entre otras cosas, los datos de diagramas de flujo y descripciones de procesos asociados. Los investigadores han propuesto diversas estrategias (Por ejemplo, analisis transformacin, anlisis de transacciones) y heursticas (Por ejemplo, fan-in/fan-out, el alcance del efecto vs. control de alcanze) para transformar un DFD en una arquitectura de software generalmente es representado con un grfico de la estructura.

3.6.3 Diseo orientado a Objetos

[Bud0:c16; Dor02:v1:c6s2,s3; Fre83:VI; Jal97:c6; Mar02:D; Pre04:c9] Numerosos mtodos de diseo de software basados en objetos se han propuesto. El campo ha evolucionado a partir de principios de los aos basado en el diseo de objetos de mediados de 1980 (Sustantivo = objeto; verbo =mtodo; adjetivo =atributo) a travs del diseo OO, donde la herencia y polimorfismo desempean un papel clave, en el campo del diseo basado en componentes, donde la meta-informacin se define y se accede (a travs de la reflexin, por ejemplo). Aunque las races del diseo orientado a objetos se derivan de la nocin del abstraccin de datos de, diseos guiados por la responsabilidad tambin ha sido propuesto como un enfoque alternativo al diseo orientado a objetos.

3.6.4 Diseo Centrado en Datos

[Bud04:c15; Fre83:III,VII; Mar02:D] Datos de estructura centrada en el diseo (por ejemplo, Jackson,Warnier-Orr) parte de las estructuras de los datos de un programa que manipula la funcin que realiza. El ingeniero de software describe en primer lugar los datos de entrada y salidas de estructuras, (Usando diagramas de Jackson estructura, Por ejemplo) y, a continuacin se desarrolla la estructura del programa de control sobre la base de estos diagramas de estructuras de datos. Varias heursticas Se han propuesto para hacer frente a casos especiales, por ejemplo, cuando hay un desequilibrio entre las estructuras entrada y estructura salida de estructuras.

26

3.6.5 Diseo basado en componentes (CDB)

Un componente de software es una unidad independiente, que tiene bien definida interfaces y dependencias que se pueden componer y desplegar en forma independiente. Diseo basado en componentes aborda temas relacionados con la prestacin, desarrollo y la integracin de dichos componentes con el fin de mejorar la reutilizacin.[Bud04: C11].

3.6.6 Otros mtodos

Otros enfoques de la corriente principal, pero menos interesante tambin existen: formales y rigurosos mtodos [Bud04: C18; Dor02: c5; Fre83;Mey97: c11; Pre04: C29] y los mtodos de transformacin.[Pfl98: c2]

27

4 Construccin de software
Acrnimos OMG: Grupo de manejo de objetos UML: Lenguaje de Modelado Unificado INTRODUCCION El termino construccin de software hace referencia a la creacin detallada de funcionalidad a travs de una combinacin de cdigos, verificacin, pruebas de unidad, pruebas de integracin y depuracin. El rea de conocimiento de la construccin de software esta unido a todas las reas de conocimiento, mas fuertemente al diseo y prueba de software. Esto se debe a que el proceso mismo de construccin de software involucra tanto el diseo significativo de software como las actividades de prueba. Tambin utiliza las salidas del diseo y proporciona una de las entradas para las pruebas, consistiendo estas actividades en el diseo y en las pruebas, y en este caso no en las KAs. Las fronteras detalladas entre el diseo, construccin y prueba (si es que hay alguna) variarn dependiendo de los procesos del ciclo de vida del software que estn siendo usados en el proyecto. A pesar de que se pueda realizar parte del diseo detallado antes de la construccin, mucho del trabajo del diseo se lleva a cabo durante la actividad misma de la construccin. Por lo que el KA de Construccin del Software est vinculado muy de cerca al KA de Diseo del Software. Por medio de la construccin los ingenieros del software realizan tanto pruebas de unidad, como pruebas de integracin de su trabajo. As que el rea del conocimiento de la construccin de software tambin esta muy relacionado a el rea de conocimiento de prueba de de software. La construccin de software tpicamente produce los volmenes mas altos de tems de configuracin que necesitan ser manejados en un proyecto de software (archivos fuentes, contenidos, casos de prueba y dems). As que el rea de conocimiento de construccin de software esta tambin muy relacionada el rea de conocimiento Gestin de la configuracin del software. Ya que la construccin de software confa fuertemente en herramientas y mtodos y es probablemente el rea de conocimiento que ms los usa, estas se encuentran relacionadas a las herramientas de la ingeniera del software y al rea del conocimiento de los mtodos y herramientas. Mientras que la calidad del software es importante en todas las reas del conocimiento, el cdigo es lo ltimo que se entrega en un proyecto de software. As que la calidad del software esta tambin unida a la construccin de software. Entre las Disciplinas Descritas de la Ingeniera del Software el KA de Construccin del Software es lo ms parecido a la ciencia informtica en su uso del conocimiento de algoritmos y de las prcticas detalladas de codificacin, ambas son consideradas, con frecuencia, como pertenecientes al dominio de la ciencia informtica. Tambin est relacionada con la gestin del proyecto en la medida en que la gestin de la construccin pueda presentar retos considerables. Descomposicin de los temas de Construccin de Software A continuacin se presenta la descomposicin del KA de la Construccin del Software junto con breves descripciones de los temas ms importantes asociados a este. La figura 1 ofrece una representacin grfica de la descomposicin de alto nivel de las divisiones de esta KA.

28

4.1 Fundamentos de la construccin de software.

Los fundamentos para la construccin de software incluyen: Minimizar la complejidad Anticipar a los cambios Construir para verificar Estndares en construccin

Los primeros tres conceptos aplican tanto al diseo como a la construccin. Las siguientes secciones definen estos conceptos y describen como aplican a la construccin.

4.1.1 Minimizar la complejidad

Un principal factor en el cual la gente difiere del computador, es la habilidad limitada de las personas para guardar complejas estructuras e informacin en sus memorias de trabajo, especialmente por largos periodos de tiempo. Esto lleva a uno de las ms fuertes directrices en la construccin de software: Minimizar la Complejidad. La necesidad para reducir la complejidad aplica esencialmente a cada aspecto de la construccin del software, y es particularmente crtico para el proceso de verificacin y prueba de las construcciones de software. En la construccin de software, la reduccin complejidad se alcanza a travs del nfasis en la creacin de un cdigo que sea simple y legible, ms que inteligente. Minimizar la complejidad se alcanza, haciendo uso de estndares, los cuales son tratados en el tema 1.4 estndares en construccin, y mediante numerosas tcnicas especificas las cuales estn resumidas en el tema 3.3 codificacin. Esta tambin apoyada en las tcnicas de calidad enfocadas a la construccin resumidas en el tema 3.5 calidad de la construccin.

4.1.2 Anticipar cambios

La mayora del software cambiar con el pasar del tiempo, y la anticipacin conlleva a muchos aspectos de la construccin del software. El cambio de ambientes externos es una parte inevitable del software, y estos cambios lo afectan de diversas formas.

29

La anticipacin al cambio esta soportada en muchas tcnicas especficas resumidas en el tema 3.3 Codificacin.

4.1.3 Construir para verificar:

Construir para verificar significa la creacin de software de tal manera que las fallas puedan ser encontradas fcilmente por los Ingenieros del software, mientras escriben el software, tambin durante las pruebas independientes y las actividades operacionales. Las tcnicas especificas que apoyan la construccin para verificacin incluyen los siguientes: estndares de codificacin para apoyar la revisin de cdigos, pruebas de unidad, organizacin de cdigos para apoyar la prueba automticas, y uso restringido de complejidad o estructuras de lenguajes difcil de entender, entre otros.

4.1.4 Estndares en construccin:

Los estndares que afectan directamente los aspectos de construccin incluyen: Mtodos de comunicacin (por ejemplo: estndares para documentos, formatos y contenidos). Lenguajes de programacin (por ejemplo: lenguajes estndares tales como java, c++). Plataformas(por ejemplo: interfase estndares de programacin para llamadas al sistema operativo) Herramientas(por ejemplo: estndares de diagramacin para notaciones como UML)

Uso de estndares externos. La construccin depende del uso de estndares externos para lenguajes de construccin, herramientas de construccin, interface tcnicas e interacciones entre construccin de software y otras reas de conocimiento. Los estndares provienen de numerosas fuentes, incluyendo especificaciones de interfaces de Hardware y software tales como las de OMG Object Management Group, IEEE (Instituto de Ingenieros de Elctrica y Electrnica) o la ISO (Organizacin de estndares Internos). Uso de estndares internos. Los estndares pueden ser tambin creados en una base organizacional a nivel corporativo o para uso en proyectos especficos. Estos estndares apoyan la coordinacin de actividades en grupo, minimizan la complejidad, anticipan el cambio y construyen para verificar.

4.2 Gestin de la Construccin 4.2.1 Modelos de Construccin

[Bec99; McC04] Se han creado numerosos modelos para el desarrollo de software, algunos de los cuales ponen ms nfasis en la construccin que otros. Algunos modelos son ms lineales que otros desde el punto de vista de la construccin tales como los modelos en cascada y los modelos de ciclo de vida de entrega por etapas. Estos modelos tratan la construccin como una actividad que sucede slo despus de que se haya completado un trabajo significativo con los prerrequisitos incluyendo un trabajo detallado sobre los requisitos, un extensivo trabajo sobre el diseo y una planificacin detallada. Los enfoques ms lineales tienden a poner el nfasis en las actividades que preceden a la construccin (requerimientos y diseo), y tienden a crear separaciones ms marcadas entre las actividades. En estos modelos, la codificacin sera el punto de mayor nfasis de la construccin. Otros modelos son ms iterativos, tales como el prototipado evolutivo, Programacin Extrema y Scrum. Estos enfoques tienden a tratar la construccin como una actividad que ocurre en forma concurrente o solapada con otras actividades de desarrollo de software incluyendo los requerimientos, el diseo y la planificacin. Estos enfoques tienden a mezclar el diseo, la codificacin y las actividades de pruebas, y con frecuencia tratan la combinacin de actividades como construccin.

30

Por consiguiente, lo que est considerado como construccin depende hasta cierto grado del modelo de ciclo de vida utilizado.

4.2.2 Planificacin de la Construccin [Bec99; McC04]

La eleccin de un mtodo de construccin es un aspecto clave de la actividad de planificacin de la construccin. La eleccin de un mtodo de construccin afecta el alcance para el cual los prerrequisitos de construccin son ejecutados, el orden en el que se ejecutan, y el grado hasta el que se espera que sean completados antes de que comience el trabajo de construccin. El enfoque de la construccin afecta la capacidad del proyecto para reducir la complejidad, anticiparse al cambio y construir para verificar. Cada uno de estos objetivos puede ser dirigido en el proceso, requerimientos y niveles de diseo pero tambin estarn influenciados por la eleccin de un mtodo de construccin. La planificacin de la construccin tambin define el orden en el cual los componentes se crean e integran, los procesos de gestin de la calidad del software, la asignacin de tareas especficas a ingenieros del software y otras tareas de acuerdo al mtodo elegido.

4.2.3 Medicin de la Construccin [McC04]

Se pueden medir numerosas actividades de construccin y artefactos, incluidos el cdigo desarrollado, el cdigo modificado, el cdigo reutilizado, el cdigo destruido, la complejidad del cdigo, las estadsticas de la inspeccin del cdigo, las tasas de errores encontrados y errores corregidos, el esfuerzo y los cronogramas. Estas mediciones pueden ser tiles para propsitos de gestin de la construccin, asegurando la calidad durante la construccin, mejorando los procesos de construccin, tambin para otras razones.

4.3 Consideraciones Prcticas

La construccin es una actividad en la cual el software se las tiene que ver con restricciones arbitrarias y caticas del mundo real, y hacerlas exactamente. Gracias a su proximidad con las restricciones del mundo real, la construccin est guiada por consideraciones prcticas ms que otras KAs, y la ingeniera del software es quizs el rea de construccin ms artesanal.

4.3.1 Diseo de Construccin

[Bec99; Ben00; Hun00; IEEE12207-95; Mag93; McC04] Algunos proyectos asignan mas actividad al diseo que a la construccin; otros a una fase explcitamente enfocada en el diseo. Independientemente de su asignacin exacta, en el nivel de construccin tambin se trabaja algo el diseo detallado y ese trabajo de diseo tiende a estar dictaminado por restricciones inamovibles impuestas por un problema del mundo real que est siendo afrontado por el software. As como los obreros de un edificio tienen que realizar modificaciones a pequea escala en su estructura fsica para cubrir huecos no previstos en los planes del constructor, los obreros de la construccin del software tendrn que hacer modificaciones en una mayor o menor escala para revelar los detalles del diseo de software durante la construccin. Los detalles de la actividad de diseo a nivel de la construccin son esencialmente los mismos que se describen en el KA del Diseo del Software, pero se aplican en una escala inferior.

4.3.2 Lenguajes de Construccin

[Hun00; McC04] Los lenguajes de construccin incluyen todos los tipos de comunicacin mediante los cuales un humano puede especificar una solucin ejecutable para un problema en un computador. El tipo ms simple de lenguaje de construccin es un lenguaje de configuracin en el que los ingenieros del software eligen de entre un conjunto limitado de opciones predefinidas para crear nuevas o tpicas instalaciones del software. Los archivos de configuracin basados en 31

texto utilizados tanto en los sistemas operativos de Windows como de Unix son ejemplos de esto, y otro ejemplo son las listas de seleccin en forma de men de algunos generadores de programas. Los lenguajes de herramientas se utilizan para construir aplicaciones partiendo de las herramientas (conjuntos integrados de partes reutilizables especficas de las aplicaciones), y son ms complejos que los lenguajes de configuracin. Los lenguajes de herramientas pueden definirse explcitamente como lenguajes de programacin de aplicaciones (por ejemplo, scripts), o pueden simplemente estar implcitos en el conjunto de interfaces de las herramientas. Los lenguajes de programacin son el tipo ms flexible de lenguaje de construccin. Tambin son los que menos informacin contienen acerca de las reas especficas de la aplicacin y los procesos de desarrollo, y por tanto requieren el mayor entrenamiento y destreza posibles para utilizarlo con eficacia. Existen tres tipos generales de notacin utilizados para los lenguajes de programacin, a saber: Lingsticos Formales Visuales

Las notaciones lingsticas se distinguen en particular por la utilizacin de cadenas de texto del tipo palabra para representar construcciones complejas de software, y por la combinacin en patrones de tales cadenas del tipo palabra que tienen una sintaxis del tipo sentencia. Utilizadas adecuadamente, cada una de estas cadenas debera tener una fuerte connotacin semntica ofreciendo un entendimiento intuitivo inmediato de lo que sucedera cuando se ejecute la construccin del software subyacente. Las notaciones formales se apoyan menos en los significados de las palabras y cadenas de texto intuitivos y de todos los das, y ms en las definiciones respaldadas por definiciones precisas, sin ambigedad, y formales (o matemticas). Las notaciones de construccin formal y los mtodos formales estn en el corazn de la mayora de las formas de programacin de sistemas, donde la precisin, el comportamiento del tiempo, y la capacidad de realizar pruebas son ms importantes que la facilidad de mapeo a un lenguaje natural. Las construcciones formales tambin utilizan modos de combinar smbolos definidos con precisin que evitan la ambigedad de muchas construcciones del lenguaje natural. Las notaciones visuales se apoyan bastante poco en las notaciones orientadas al texto tanto de la construccin lingstica como de la formal, y en cambio s se apoyan en una interpretacin visual directa y en la colocacin de las entidades visuales que representan al software subyacente. La construccin visual tiende a estar un tanto limitada por la dificultad de hacer declaraciones complejas utilizando slo el movimiento de entidades visuales en un despliegue. Sin embargo, tambin puede convertirse en un arma poderosa en los casos en donde la principal tarea de programacin es simplemente construir y ajustar una interfaz visual a un programa, cuyo comportamiento detallado ha sido definido anteriormente.

4.3.3 Codificacin
[Ben00; IEEE12207-95; McC04] Las consideraciones siguientes se aplican a la actividad de construccin del cdigo del software: Tcnicas para crear cdigo fuente comprensible, que incluye la asignacin de nombres y el esquema del cdigo fuente. Utilizacin de clases, tipos enumerados, variables, constantes predefinidas, y otras entidades similares Utilizacin de estructuras de control. Manejo de las condiciones de error tanto lo errores planeados como las excepciones (la entrada de datos malos, por ejemplo)

32

Prevencin de brechas en la seguridad a nivel de cdigo (el bfer o el ndice de la matriz se desborda, por ejemplo) Utilizacin de recursos por medio del uso de mecanismos de exclusin y disciplina en el acceso serial a recursos reutilizables (incluyendo hilos o bloqueos de bases de datos) Organizacin del cdigo fuente (en declaraciones, rutinas, clases, paquetes u otras estructuras) Documentacin del cdigo Puesta a punto del cdigo

4.3.4 Pruebas de Construccin

[Bec99; Hun00; Mag93; McC04] Construir implica dos tipos de pruebas, que por lo general las realiza el mismo ingeniero del software que escribi el cdigo: Pruebas unitarias Pruebas de integracin

El propsito de las pruebas de construccin es reducir la brecha entre el tiempo en el que se introducen fallos en el cdigo y el tiempo en el que se detectan esos fallos. En algunos casos, las pruebas de construccin se llevan a cabo despus de la escritura del cdigo. En otros casos, se pueden elaborar casos de pruebas antes de que se escriba el cdigo. Es tpico de las pruebas de construccin el incluir un subconjunto de tipos de pruebas, que se describen en el KA de Pruebas del Software. Por ejemplo, no es tpico de las pruebas de construccin el incluir las pruebas del sistema, las pruebas alfa, las pruebas beta, las pruebas de estrs, las pruebas de construccin, las pruebas de facilidad de uso, u otros tipos de pruebas ms especializadas. Se han publicado dos estndares sobre dicho tema: IEEE Std 829-1998, IEEE Standard for Software Test Documentation and IEEE Std 1008-1987, IEEE Standard for Software Unit Testing. Se pueden ver tambin los sub-temas correspondientes en el KA de Pruebas del Software: 2.1.1 Pruebas Unitarias y 2.1.2 Pruebas de Integracin para un material de referencia ms especializado.

4.3.5 Reutilizacin
[IEEE1517-99; Som05]. Tal y como se afirma en la introduccin del (IEEE1517-99): El implementar la reutilizacin del software conlleva algo ms que crear y utilizar libreras de recursos. Requiere formalizar la prctica de la reutilizacin por medio de la integracin de procesos y actividades de reutilizacin en el ciclo de vida del software. Sin embargo, la reutilizacin tiene suficiente importancia en la construccin del software como para dedicarle aqu un tema. Las tareas relacionadas con la reutilizacin en la construccin del software durante su codificacin y pruebas son: La seleccin de unidades, bases de datos, procedimientos de pruebas o datos de pruebas reutilizables. La evaluacin de la posibilidad de reutilizacin del cdigo o de las pruebas. Comunicar la informacin sobre reutilizacin realizada en el cdigo nuevo, los procedimientos de pruebas o los datos de pruebas.

33

4.3.6 Calidad de la Construccin

[Bec99; Hun00; IEEE12207-95; Mag93; McC04] Existen numerosas tcnicas para garantizar la calidad del cdigo mientras est siendo elaborado. Las tcnicas ms importantes utilizadas para la construccin incluyen: Las pruebas unitarias y las pruebas de integracin (tal y como se describen en el punto 3.4 Pruebas de Construccin) El desarrollo de primero-haz-pruebas (ver tambin el KA de las Pruebas del Software, punto 2.2 Objetivos de las Pruebas) El cdigo paso a paso Utilizacin de aserciones Depuracin Revisiones Tcnicas (ver tambin el KA de la Calidad del Software, en la subrea 2.3.2 Revisiones Tcnicas) Anlisis esttico (IEEE1028) (ver tambin el KA de la Calidad del Software, punto 2.3 Revisiones y Auditorias)

La tcnica o tcnicas especficas elegidas dependen de la naturaleza del software que se est construyendo, as como del conjunto de habilidades de los ingenieros del software que llevan a cabo la construccin. Las actividades de calidad de la construccin se distinguen de las otras actividades de calidad por su enfoque. Las actividades de calidad de la construccin se centran en el cdigo y en los artefactos que estn estrechamente relacionados con el cdigo: diseos en pequea escala en oposicin a otros artefactos que estn menos directamente ligados al cdigo, tales como requisitos, diseos de alto nivel y planes.

4.3.7 Integracin
[Bec99; IEEE12207-95; McC04] Una actividad clave durante la construccin es la integracin de rutinas, clases, componentes y subsistemas construidos por separado. Adems, un sistema particular del software podra necesitar ser integrado con otros sistemas de software o de hardware. Los intereses relacionados con la integracin de la construccin incluyen planificar la secuencia en la que se integrarn los componentes, crear andamiajes que soporten versiones provisionales del software, determinar el grado de pruebas y la calidad del trabajo realizado sobre los componentes antes de que sean integrados, y determinar los puntos en el proyecto en los que se prueban las versiones provisionales del software.

34

5 Pruebas de software
INTRODUCCIN Hacer pruebas es una actividad que tiene el objetivo de evaluar y mejorar la calidad del producto, identificando defectos y problemas. Las pruebas del software consisten en verificar el comportamiento de un programa dinmicamente a travs de un grupo finito de casos de prueba, debidamente seleccionados del, tpicamente, mbito de ejecuciones infinito, en relacin al comportamiento esperado. En la definicin anterior las palabras en itlica se corresponden con aspectos esenciales en la identificacin del rea de Conocimiento de las Pruebas del Software. En particular: Dinmicamente: Este trmino significa que hacer pruebas siempre supone ejecutar el programa con entrada de datos (valorados). Es preciso afirmar que la entrada de valores no es siempre suficiente para definir una prueba, dado que un sistema complejo y no determinista podra tener diferentes comportamientos con las mismas entradas de datos, dependiendo del estado en el que se encuentre. En cualquier caso, en esta rea de Conocimiento (AC), mantendremos el trmino de entrada de datos, asumiendo la convencin de que el trmino incluye un estado del sistema especfico, en los casos en que sea necesario. Existen otras tcnicas complementarias a las pruebas, aunque diferentes, descritas en el rea de Conocimiento (AC) sobre la Calidad del Software. Finito: Incluso en programas sencillos, tericamente podra haber tantas pruebas que realizar, que hacer pruebas exhaustivas podra llevar meses o aos. Esta es la razn por la que en la prctica el conjunto completo de pruebas se podra considerar infinito. Hacer pruebas siempre supone un compromiso entre recursos y calendarios de trabajo limitados, por un lado, y necesidades inherentes de pruebas ilimitadas, por otro. Seleccionados: La diferencia esencial entre las distintas tcnicas de pruebas propuestas se encuentra en cmo se escoge el conjunto de pruebas. Los ingenieros de software deben ser conscientes de que criterios de seleccin distintos pueden producir grados de efectividad muy diferentes. La forma de identificar el criterio de seleccin de pruebas ms apropiado para un conjunto de condiciones particulares es un problema complejo; en la prctica se usa la experiencia en el diseo de pruebas y tcnicas de anlisis de riesgo. Esperado: Debera ser posible, aunque a veces no sea fcil, decidir si el resultado observado de la ejecucin de un programa es aceptable o no, porque si no el esfuerzo de realizar las pruebas sera intil. El comportamiento observado se puede comprobar con los resultados esperados por el usuario (normalmente conocido como pruebas de validacin), con las especificaciones (pruebas de verificacin), o, finalmente, contra el comportamiento esperado de los requisitos implcitos o expectativas razonables. Vea ms detalles en el rea de Conocimiento (AC) de Requerimientos del Software, punto 6.4 Pruebas de Aceptacin. La apreciacin de las pruebas del software ha evolucionado hacia una forma ms constructiva. Ya no se asume que realizar pruebas es una tarea que empieza solamente cuando la fase de programacin se ha completado, y que tiene el nico propsito de detectar errores. Las pruebas del software se ven ahora como una actividad que debera estar presente durante todo el proceso de desarrollo y mantenimiento y es en s misma una parte importante de la construccin del producto. Es ms, la planificacin de las pruebas debera empezar en las primeras etapas del proceso de requisitos, mientras que los planes y procedimientos de pruebas deberan desarrollarse y posiblemente refinarse sistemticamente segn avanza el desarrollo. La planificacin de las pruebas y las propias actividades de diseo constituyen una informacin muy til que ayuda a los diseadores de software a identificar debilidades potenciales (tales como elementos del diseo que han pasado desapercibidos, contradicciones de diseo, u omisiones o ambigedades en la documentacin). En la actualidad se considera que la prevencin es la actitud adecuada en lo que respecta a la calidad: obviamente es mejor evitar problemas que solucionarlos. Realizar pruebas debe verse

35

como un medio para verificar, no slo si la prevencin ha sido efectiva, si no para identificar fallos en aquellos casos en los que, por alguna razn, no lo ha sido. Aunque quizs sea obvio, vale la pena reconocer que, incluso despus de una jornada de pruebas extensiva, el software an podra contener errores. Las acciones de mantenimiento correctivas proporcionan la solucin a errores en el software, despus de que ste ha sido entregado. El rea de Conocimiento (AC) del Mantenimiento del Software aborda los temas relacionados con el mantenimiento del software. En el rea de Conocimiento (AC) del Mantenimiento del Software (vase punto 3.3 Tcnicas de Gestin de Calidad del Software), las tcnicas de gestin de la calidad del software se dividen entre tcnicas estticas (sin ejecucin de cdigo) y tcnicas dinmicas (con ejecucin de cdigo). Ambas categoras son tiles. Esta rea de Conocimiento (AC) se centra en tcnicas dinmicas. Las pruebas del software tambin estn relacionadas con la construccin del software (vase la seccin 3.4 tcnicas basadas en defectos). Las pruebas de unidad y de integracin estn ntimamente relacionadas con la construccin del software, si no son parte de la misma. Descomposicin de temas La primera subrea describe los Fundamentos de las Pruebas del Software. Cubre las definiciones bsicas del rea de pruebas del software, la terminologa bsica y los trminos clave, as como las relaciones con otras actividades. La segunda subrea, Niveles de Pruebas, est formada por dos puntos ortogonales: el primero (2.1) enumera los niveles en que tradicionalmente se subdividen de manera amplia las pruebas de software, mientras que el segundo (2.2) considera las pruebas para situaciones o propiedades especficas y se conoce como objetivos de las pruebas. No todos los tipos de pruebas se pueden aplicar a todos los productos de software, tampoco se han enumerado todos los tipos posibles. El objeto y los objetivos de las pruebas determinan la forma en que un grupo de pruebas se identifica, en lo que se refiere a su consistencia cuntas pruebas son suficientes para conseguir el objetivo especificado y su composicin qu casos de prueba se deberan seleccionar para conseguir el objetivo especificado (aunque normalmente la parte para conseguir el objetivo especificado es implcita y slo se usa la primera parte de las dos frases anteriores). Los criterios para responder a la primera cuestin se denominan criterios de idoneidad las pruebas, mientras que los que se refieren a la segunda cuestin se denominan criterios de seleccin de las pruebas. En las ltimas dcadas se han desarrollado varias Tcnicas de Pruebas y an se estn proponiendo nuevas tcnicas. El conjunto de pruebas comnmente aceptadas estn enumeradas en la subrea 3. Las Mediciones de Pruebas se enumeran en la subrea 4. Finalmente, los aspectos relacionados con el Proceso de las Pruebas estn enumerados en la subrea 5.

5.1 Fundamentos de las Pruebas del Software 5.1.1 Terminologa relacionada con las pruebas 5.1.1.1 Definiciones de pruebas y terminologa relacionada

[Bei90:c1; Jor02:c2; Lyu96:c2s2.2] (IEEE610.12-90) Vea una introduccin detallada del KA de las Pruebas del Software en las referencias recomendadas.

5.1.1.2

Errores Vs. Fallos

[Jor02:c2; Lyu96:c2s2.2; Per95:c1; Pfl01:c8] (IEEE610.12-90; IEEE982.1-88)

36

En la literatura sobre Ingeniera del Software, se usan diversos trminos para describir un funcionamiento incorrecto, particularmente falta, error, fallo y otros trminos. Esta terminologa se define detalladamente en el estndar IEEE 610.12- 1990, Standard Glossary of Software Engineering Terminology (IEEE610-90) y tambin se discute en el KA de la Calidad del Software. Es esencial distinguir claramente entre la causa de un funcionamiento incorrecto, en cuyo caso se usan trminos como error y defecto, y los efectos no deseados observados en los servicios proporcionados por un sistema, que se llamarn fallos. Hacer pruebas puede descubrir fallos, pero es el error el que se puede, y se debe, eliminar. En cualquier caso, debera aceptarse que no es siempre posible identificar unvocamente las causas de un fallo. No existe ningn criterio terico que pueda usarse para determinar qu error produce el fallo observado. Podra decirse que hay que corregir el error para eliminar el problema, pero otros cambios tambin podran funcionar. Para evitar ambigedades, algunos autores prefieren hablar de entradas que causan fallos (Fra98) en vez de errores o lo que es lo mismo, aquellos grupos de entradas de datos que hacen que el fallo aparezca.

5.1.2 Cuestiones clave 5.1.2.1 Criterios de seleccin de pruebas/Criterios de idoneidad de pruebas (o finalizacin de pruebas)

[Pfl01:c8s7.3; Zhu97:s1.1] (Wey83; Wey91; Zhu97) Un criterio de seleccin de pruebas es un medio para decidir cules deben ser los casos de prueba adecuados. Un criterio de seleccin se puede usar para seleccionar casos de pruebas o para comprobar si el grupo de casos de prueba es apropiado o sea, para decidir si se puede terminar de hacer pruebas. Vase el apartado Finalizacin de la seccin 5.1 Consideraciones prcticas.

5.1.2.2

Efectividad de las pruebas/Objetivos para las pruebas

[Bei90:c1s1.4; Per95:c21] (Fra98) Realizar pruebas consiste en observar un conjunto de ejecuciones del programa. Hay diferentes objetivos que nos pueden guiar en la seleccin del conjunto de pruebas: la efectividad del grupo de pruebas slo se puede evaluar en funcin del objetivo seleccionado.

5.1.2.3

Realizar pruebas para la identificacin de defectos

[Bei90:c1; Kan99:c1] Cuando realizamos pruebas para la identificacin de defectos, una prueba es satisfactoria si produce un error en el sistema. Es ste un enfoque completamente diferente al de realizar pruebas para demostrar que el software satisface las especificaciones u otro conjunto de propiedades deseadas, en cuyo caso una prueba satisfactoria es aquella en la que no se observan errores (al menos significativos).

5.1.2.4

El problema del orculo

[Bei90:c1] (Ber96, Wey83) Un orculo es cualquier agente (humano o mecnico) que decide si un programa se comporta correctamente durante una prueba y consecuentemente produce un veredicto de superada o fallida. Hay varios tipos diferentes de orculos, y la automatizacin de orculos puede ser muy difcil y costosa.

5.1.2.5

Limitaciones tericas y prcticas de las pruebas

[Kan99:c2] (How76) La teora de pruebas advierte en contra de un nivel injustificado de confianza en una serie de pruebas superadas. Desafortunadamente, la mayor parte de los resultados establecidos en la teora de pruebas son negativos, en el sentido de que establecen aquello que la prueba no puede conseguir, en vez de lo que consigui. La ms famosa cita a este respecto es el

37

aforismo de Dijkstra que dice las pruebas de un programa se pueden usar para mostrar las presencia de errores, pero nunca para demostrar su ausencia. La razn obvia es que realizar un grupo completo de pruebas no es posible en el software real. Como consecuencia, las pruebas deben dirigirse en funcin de los riesgos y por tanto pueden verse como una estrategia de gestin de riesgo.

5.1.2.6
[Bei90:c3]

El problema de los caminos no alcanzables

Los caminos no alcanzables son aquellos caminos de control que no pueden ejecutarse para ninguna entrada de datos. Son un problema importante en las pruebas orientadas por caminos y particularmente en las derivaciones automticas de entradas de pruebas que se emplean en las tcnicas de pruebas basadas en cdigo.

5.1.2.7

Posibilidad de hacer pruebas

[Bei90:c3, c13] (Bac90; Ber96a; Voa95) El trmino posibilidad de hacer pruebas tiene dos significados relacionados pero diferentes: por un lado, se refiere al grado de facilidad del software para satisfacer un determinado criterio de cobertura de pruebas, como se describe en (Bac90); por otro, se define como la probabilidad, posiblemente cualificada estadsticamente, de que los errores del software queden expuestos durante las pruebas, si es errneo, tal y como se describe en (Voa95, Ber96a). Ambos significados son importantes.

5.1.3 Relacin de las pruebas con otras actividades

Las pruebas del software, aunque diferentes, estn relacionadas con las tcnicas esttica de gestin de la calidad del software, las pruebas de validez del software, la depuracin y la programacin. Sin embargo, es til considerar las pruebas desde el punto de vista del analista de calidad del software o certificador. Pruebas vs. Tcnicas de Gestin de Calidad del Software Esttico. Vase tambin el KA de la Calidad del Software, punto 2. Proceso de Gestin de la Calidad del Software. [Bei90:c1; Per95:c17] (IEEE1008-87) Pruebas vs. Pruebas de Validez y Verificacin Formal [Bei90:c1s5; Pfl01:c8]. Pruebas vs. Depuracin. Vase tambin el KA de la Construccin del Software, punto 3.4 Pruebas de la construccin [Bei90:c1s2.1] (IEEE1008-87). Pruebas vs. Programacin. Vase tambin el KA de la Construccin del Software, punto 3.4 Pruebas de la construccin [Bei90:c1s2.1] (IEEE1008-87). Pruebas y Certificacin (Wak99).

5.2 Niveles de Pruebas 5.2.1 El objeto de la prueba

Las pruebas del software se realizan normalmente a diferentes niveles durante los procesos de desarrollo y mantenimiento. Esto significa que el objeto de las pruebas puede cambiar: un mdulo, un grupo de dichos mdulos (relacionados por propsito, uso, comportamiento, o estructura), o un sistema completo. [Bei90:c1; Jor02:c12; Pfl01:c8] Conceptualmente se pueden distinguir tres grandes niveles de pruebas, llamadas de Unidad, de Integracin y del Sistema. No hay un modelo de proceso implcito, ni se asume que ninguno de estos tres niveles tiene mayor importancia que los otros dos.

5.2.1.1

Pruebas de Unidad

[Bei90:c1; Per95:c17; Pfl01:c8s7.3] (IEEE1008-87) Las pruebas de unidad verifican el funcionamiento aislado de partes del software que se pueden probar independientemente. Dependiendo del contexto, estas partes podran ser

38

subprogramas individuales o un componente ms grande formado por unidades muy relacionadas. Hay una definicin ms precisa de prueba de unidad en el estndar IEEE de pruebas de unidad del software (IEEE1008-87), que tambin describe un enfoque integrado para realizar y documentar pruebas de unidad sistemticamente. Normalmente, las pruebas de unidad se realizan con acceso al cdigo fuente y con el soporte de herramientas de depuracin, pudiendo involucrar a los programadores que escribieron el cdigo

5.2.1.2

Pruebas de Integracin

[Jor02:c13, 14; Pfl01:c8s7.4] Una prueba de integracin es el proceso de verificar la interaccin entre componentes de software. Estrategias clsicas de integracin, como arriba hacia abajo o abajo hacia arriba, se usan, tradicionalmente, con software estructurado jerrquicamente. Las estrategias modernas de integracin estn dirigidas por la arquitectura, lo que supone integrar los componentes de software o subsistemas basndose en caminos de funcionalidad identificada. Las pruebas de integracin son una actividad continua, que sucede en cada fase en que los ingenieros de software tienen que hacer abstracciones de las perspectivas de bajo nivel y concentrarse en las perspectivas del nivel que estn integrando. Con la excepcin de software sencillo y pequeo, las estrategias de pruebas de integracin sistemticas e incrementales son preferibles a probar todos los componentes juntos al final, lo que se conoce (de forma grfica), como pruebas en big bang.

5.2.1.3

Pruebas del sistema

[Jor02:c15; Pfl01:c9] Las pruebas del sistema se ocupan del comportamiento de un sistema completo. La mayora de los fallos funcionales deberan haber sido identificados antes, durante las fases de pruebas de unidad y pruebas de integracin. Las pruebas del sistema se consideran normalmente como las apropiadas para comparar el sistema con los requerimientos no funcionales del sistema, como seguridad, velocidad, exactitud y confiabilidad. Las interconexiones externas con otras aplicaciones, utilidades, dispositivos hardware o con el sistema operativo, tambin se evalan en este nivel. Vase el AC de Requerimientos del Software para ms informacin acerca de requerimientos funcionales y no funcionales.

5.2.2 Objetivos de las pruebas

[Per95:c8; Pfl01:c9s8.3] Las pruebas se realizan en relacin a conseguir un determinado objetivo, que se ha definido ms o menos explcitamente y con diversos niveles de precisin. Definir el objetivo, en trminos precisos y cuantitativos, permite establecer controles en el proceso de las pruebas. Las pruebas se pueden realizar para verificar varias propiedades. Se pueden asignar casos de prueba para comprobar que las especificaciones funcionales se han implementado correctamente, a lo que la literatura se refiere como pruebas de conformidad, pruebas de correccin o pruebas de funcionalidad. Sin embargo, tambin se pueden hacer pruebas a otras muchas propiedades no funcionales, como rendimiento, confiabilidad y facilidad de uso, entre otras muchas. Otros objetivos importantes de las pruebas incluyen (aunque no se limitan a) mediciones de confiabilidad, evaluacin de la facilidad de uso y aceptacin, para los cuales se utilizaran enfoques diferentes. Se debe tener en cuenta que los objetivos de las pruebas varan con el objeto de las pruebas; en general, propsitos diferentes son tratados con diferentes niveles de pruebas. Las referencias recomendadas para este tema describen el conjunto de objetivos de pruebas potenciales. Los subtemas enumerados seguidamente son los que se citan ms frecuentemente en la literatura. Tngase en cuenta que algunos tipos de pruebas son ms apropiados por ejemplo; para paquetes de software hechos a medida, pruebas de instalacin, mientras otros son ms apropiados para productos ms genricos, como pruebas beta.

39

5.2.2.1

Pruebas de aceptacin/cualificacin

[Per95:c10; Pfl01:c9s8.5] (IEEE12207.0- 96:s5.3.9) Las pruebas de aceptacin comparan el comportamiento del sistema con los requerimientos del cliente, sea cual sea la forma en que stos se hayan expresado. El cliente realiza, o especifica, tareas tpicas para comprobar que se satisfacen sus requerimientos o que la organizacin los ha identificado para el mercado al que se destina el software. Esta actividad de pruebas puede incluir o no a los desarrolladores del sistema.

5.2.2.2

Pruebas de instalacin

[Per95:c9; Pfl01:c9s8.6] Normalmente, cuando las pruebas de aceptacin han terminado, el software se puede comprobar una vez instalado en el entorno de destino. Las pruebas de instalacin se pueden ver como pruebas del sistema realizadas en relacin con los requerimientos de la configuracin de hardware. Los procedimientos para la instalacin tambin se podran verificar.

5.2.2.3
[Kan99:c13]

Pruebas alfa y beta

A veces, antes de poner el software en distribucin, ste se proporciona a un grupo representativo de usuarios potenciales para que puedan usarlo en pruebas en las instalaciones del desarrollador (pruebas alpha) o externamente (pruebas beta). Dichos usuarios notifican problemas con el producto. Normalmente, el uso de versiones alfa y beta sucede en entornos no controlados y no siempre se le hace referencia en los planes de pruebas.

5.2.2.4

Pruebas de conformidad/pruebas funcionales/pruebas de correccin

[Kan99:c7; Per95:c8] (Wak99) Las pruebas de conformidad tienen el objetivo de verificar si el comportamiento del software se corresponde con las especificaciones.

5.2.2.5

Evaluacin y Logros de confiabilidad

[Lyu96:c7; Pfl01:c9s.8.4] (Pos96) Las pruebas, al ayudar a identificar errores, son un medio para mejorar la confiabilidad. Por contraste, generando casos de prueba aleatorios siguiendo el perfil de operaciones, se pueden derivar aproximaciones estadsticas de confiabilidad. Cuando se usan modelos que potencian la confiabilidad, ambos objetivos se pueden alcanzar al mismo tiempo (vase tambin el punto 4.1.4 Pruebas de ejecucin, evaluacin de la confiabilidad)

5.2.2.6

Pruebas de regresin

[Kan99:c7; Per95:c11, c12; Pfl01:c9s8.1] (Rot96) Segn (IEEE610.12-90), las pruebas de regresin son pruebas selectivas que se repiten en un componente para verificar que los cambios no han producido efectos indeseados... En la prctica, la idea es demostrar que cierto software que previamente pas un conjunto de pruebas, an las pasa. Beizer (Bei90) las define como cualquier repeticin de pruebas que tiene como objetivo demostrar que el comportamiento del software no ha cambiado, excepto en aquellos aspectos en que se haya requerido as. Por supuesto se tiene que llegar a un compromiso entre realizar pruebas de regresin cada vez que se hace un cambio y los medios de que se dispone para realizar las pruebas. Las pruebas de regresin se pueden realizar en cada uno de los niveles de pruebas descritos en el punto 2.1 El objeto de la prueba y son vlidas tanto para pruebas funcionales como no funcionales.

5.2.2.7

Pruebas de rendimiento

[Per95:c17; Pfl01:c9s8.3] (Wak99)

40

Estas pruebas tienen el objetivo de verificar que el software alcanza los requerimientos de rendimiento especificados, particularmente los de capacidad y tiempo de respuesta. Un tipo particular de pruebas de rendimiento son las pruebas de volumen (Per95:p185, p487; Pfl01:p401), en los que las limitaciones internas del programa o sistema se ponen a prueba.

5.2.2.8

Pruebas de estrs

[Per95:c17; Pfl01:c9s8.3] Las pruebas de estrs hacen funcionar el software a la mxima capacidad para la que fue diseado, y por encima de ella.

5.2.2.9

Pruebas de continuidad

Un grupo de pruebas se ejecuta en dos versiones diferentes de un producto software y los resultados se comparan.

5.2.2.10

Pruebas de recuperacin

[Per95:c17; Pfl01:c9s8.3] El objetivo de las pruebas de recuperacin es verificar la capacidad del software para reiniciarse despus de un desastre.

5.2.2.11

Pruebas de configuracin

[Kan99:c8; Pfl01:c9s8.3] En los casos en los que el software se construye para dar servicio a distintos usuarios, las pruebas de configuracin analizan el software en las diferentes configuraciones especificadas.

5.2.2.12

Pruebas de usabilidad

[Per95:c8; Pfl01:c9s8.3] Este proceso evala lo fcil que le resulta usar y aprender a usar el software al usuario, incluyendo la documentacin del usuario, la efectividad de las funciones del software para soportar las tareas de usuario y, finalmente, la habilidad de recuperarse de errores provocados por el usuario.

5.2.2.13
[Bec02]

Desarrollo dirigido por pruebas

El desarrollo dirigido por pruebas no es una tcnica en s misma, pero promociona el uso de pruebas como una parte subordinada al documento de especificacin de requerimientos en vez de una comprobacin independiente de que el software implementa dichos requerimientos correctamente.

5.3 Tcnicas de pruebas

Uno de los objetivos de las pruebas es revelar el mximo nmero posible de fallos potenciales y muchas tcnicas se han desarrollado con este objetivo, intentando romper el programa ejecutando una o ms pruebas seleccionadas de un cierto grupo de ejecuciones considerado equivalente. El principio subyacente de estas tcnicas es tratar de ser lo ms sistemtico posible identificando un conjunto representativo de comportamientos del programa; por ejemplo, identificando subclases del dominio de entrada de datos, de los escenarios, de los estados y del flujo de datos. Es difcil encontrar una base homognea para clasificar todas las tcnicas, por lo que la aqu utilizada debe entenderse como un compromiso. La clasificacin se basa en cmo los ingenieros del software generan las pruebas basndose en su intuicin y experiencia, en las especificaciones, la estructura del cdigo, los errores a descubrir (reales o artificiales), el uso de campos de entrada de datos o, en ltimo trmino, la naturaleza de la aplicacin. Algunas

41

veces, estas tcnicas se clasifican como de caja blanca (tambin conocidas como caja de cristal), si las pruebas estn basadas en informacin acerca de cmo se ha diseado o programado el software, o como de caja negra si los casos de prueba se basan solamente en el comportamiento de la entrada y salida de datos. Una ltima categora se basa en el uso combinado de dos o ms tcnicas. Obviamente, no todo el mundo usa estas tcnicas con la misma frecuencia. La siguiente lista incluye las tcnicas que los ingenieros de software deberan conocer.

5.3.1 Pruebas basadas en la intuicin y experiencia del ingeniero de software 5.3.1.1

[Kan99:c1] Quizs la tcnica usada ms globalmente continan siendo las pruebas ad hoc: las pruebas se generan a partir la habilidad, intuicin y experiencia en programas similares del ingeniero de software. Las pruebas ad hoc pueden ser tiles para identificar casos de prueba especiales, aquellos que no se pueden extraer fcilmente mediante tcnicas formales.

Pruebas ad hoc

5.3.1.2

Pruebas por exploracin

Las pruebas por exploracin se definen como aprendizaje, diseo de pruebas y ejecucin de pruebas al mismo tiempo. Esto significa que las pruebas no se definen primero como parte de un plan de pruebas establecido, si no que se disean, ejecutan y se modifican dinmicamente. La efectividad de las pruebas por exploracin se basa en el conocimiento del ingeniero de software, que se puede derivar de varias fuentes: el comportamiento observado del producto durante las pruebas, su familiaridad con la aplicacin, la plataforma o el proceso de fallos, los posibles tipos de errores y fallos, el riesgo asociado con un producto en particular, etc. [Kan01:c3]

5.3.2 Tcnicas basadas en la especificacin 5.3.2.1 Particiones de equivalencia

[Jor02:c7; Kan99:c7] El dominio de la entrada de datos se subdivide en colecciones de subconjuntos, o clases de equivalencia, las cuales se consideran equivalentes de acuerdo con la relacin especificada. Un grupo representativo de pruebas (a veces solo uno) se toma de cada clase.

5.3.2.2

Anlisis de los valores lmite

[Jor02:c6; Kan99:c7] Casos de prueba se seleccionan en y cerca de los lmites del dominio de las variables de la entrada de datos, basndose en la idea de que una gran parte de los errores se concentran cerca de los valores extremos de la entrada de datos. Una extensin de esta tcnica son las pruebas de robustez, donde se seleccionan casos de prueba que se encuentran fuera del dominio de las variables de la entrada de datos, para comprobar la robustez del programa con entradas de datos errneos e inesperados.

5.3.2.3

Tablas de decisin

[Bei90:c10s3] (Jor02) Las tablas de decisin representan relaciones lgicas entre condiciones (mayoritariamente entradas) y acciones (mayoritariamente salidas). Los casos de prueba se derivan sistemticamente considerando cada combinacin de condiciones y acciones posibles. Una tcnica relacionada es el grfico causa-efecto. [Pfl01:c9]

42

5.3.2.4

Basadas en mquinas de estado finito

[Bei90:c11; Jor02:c8] Al modelar un programa como una mquina de estado finito, se pueden seleccionar las pruebas de manera que cubran estados y sus transiciones.

5.3.2.5

Pruebas basadas en las especificaciones formales

[Zhu97:s2.2] (Ber91; Dic93; Hor95) Si las especificaciones se proporcionan en un lenguaje formal, es posible realizar una derivacin automtica de los casos de prueba funcionales y, al mismo tiempo, proporcionar unos resultados de referencia, un orculo, que se usa para comprobar los resultados de las pruebas. Existen mtodos para derivar casos de prueba de especificaciones basadas en el modelo (Dic93, Hor95) o especificaciones algebraicas. (Ber91)

5.3.2.6

Pruebas aleatorias

[Bei90:c13; Kan99:c7] En este caso las pruebas se generan de una manera completamente aleatoria, lo que no debe confundirse con las pruebas estadsticas basadas en el perfil operativo descritas en el punto 3.5.1 Perfil Operativo. Esta forma de realizar pruebas se incluye en la categora de entradas basadas en la especificacin, ya que el domino de las entradas de datos se debe conocer para ser capaces de seleccionar elementos aleatorios del mismo.

5.3.3 Tcnicas basadas en el cdigo 5.3.3.1 Criterio basado en el flujo de control

[Bei90:c3; Jor02:c10] (Zhu97) Los criterios de cobertura estn basados en el flujo de control se usan para cubrir todos los bloques de cdigo o lneas de cdigo individuales o una combinacin especifica de los mismos. Hay varios criterios de cobertura propuestos. Como cobertura de condicin/decisin. El criterio basado en el flujo de control ms efectivo son las pruebas de caminos, cuyo objetivo es verificar todos los caminos de control de tipo entrada-salida del grfico de flujos. Como, en general, las pruebas de caminos no son posibles debido a los bucles, en la prctica se usan otros criterios menos exigentes, como pruebas de lneas de cdigo, pruebas de condiciones y pruebas de decisin. La idoneidad de dichas pruebas se mide en porcentajes; por ejemplo, cuando las pruebas han ejecutado todas las condiciones al menos una vez, se dice que se ha conseguido una cobertura de condiciones del 100%.

5.3.3.2

Criterio basado en el flujo de datos

[Bei90:c5] (Jor02; Zhu97) En las pruebas basadas en el flujo de datos, el grfico de flujos de control tiene anotaciones con informacin acerca de como las variables del programa se definen, usan y destruyen. El criterio ms efectivo, todos los caminos de uso-definicin, requiere que para cada variable, se ejecute cada uno de los segmentos del camino del flujo de control de esa variable a un usa de esa definicin. Para reducir el nmero de caminos necesarios, se emplean estrategias menos efectivas como todas las definiciones y todos los usos.

5.3.3.3

Modelos de referencia para pruebas basadas en el cdigo (grfico de flujos, grfico de llamadas)

[Bei90:c3; Jor02:c5] Aunque no es una tcnica en s misma, la estructura de control de un programa se representa usando grficos de flujo en las tcnicas de pruebas basadas en cdigo. Un grfico de flujo es un grfico dirigido cuyos nodos y arcos se corresponden con elementos del programa. Por ejemplo, los nodos podran representar lneas de cdigo o secuencias de lneas de cdigo ininterrumpidas y los arcos la transferencia de control entre nodos.

43

5.3.4 Tcnicas basadas en errores

(Mor90) Con diferentes niveles de formalizacin, las tcnicas basadas en errores idean casos de prueba que estn especialmente orientados a descubrir categoras de errores probables o predefinidos.

5.3.4.1
[Kan99:c7]

Inducir errores

Inducir errores, en los casos de pruebas se han diseado especficamente por ingenieros de software intentando imaginar los errores ms probables en un programa determinado. La historia de errores descubiertos en proyectos anteriores es una buena fuente de informacin, como lo es tambin la experiencia del ingeniero.

5.3.4.2

Pruebas por mutacin

[Per95:c17; Zhu97:s3.2-s3.3] Un mutante es una versin ligeramente modificada de un programa al que se le est haciendo pruebas, diferencindose tan solo en un pequeo cambio sintctico. Cada caso de prueba se aplica al original y a los mutantes generados: si una prueba consigue identificar la diferencia entre el programa y el mutante, se dice que se ha matado al mutante. Esta tcnica se concibi originalmente para evaluar un conjunto de pruebas (vase 4.2), las pruebas por mutacin son un criterio de pruebas en s mismas: o se generan pruebas aleatorias hasta que se han matado los mutantes suficientes, o se disean pruebas especficas para matar a los mutantes supervivientes. En el ltimo caso, las pruebas por mutacin se pueden clasificar como tcnicas basadas en cdigo. El efecto de acoplamiento, que es la base asumida en las pruebas de mutacin, consiste en asumir que buscando errores sintcticos simples, se encontrarn otros ms complejos pero existentes. Para que esta tcnica sea efectiva, se debe poder derivar un nmero importante de mutantes de una manera sistemtica.

5.3.5 Tcnicas basadas en el uso 5.3.5.1 Perfil operativo

[Jor02:c15; Lyu96:c5; Pfl01:c9] Durante pruebas para la evaluacin de la confiabilidad, el entorno de pruebas debe reproducir el entorno operativo del software tan fielmente como sea posible. La idea es deducir la futura confiabilidad del software durante su use real desde los resultados de las pruebas. Para conseguir esto, se le asigna una probabilidad de distribucin, o perfil, a las entradas de datos, basndose en la frecuencia en que suceden durante el funcionamiento real.

5.3.5.2
[Lyu96:c6]

Pruebas Orientadas a la Confiabilidad del Software

Las pruebas orientadas a la confiabilidad del software (SRET) son un mtodo de pruebas que forma parte del proceso de desarrollo completo, donde la realizacin de pruebas est diseada y guiada por los objetivos de confiabilidad y el uso relativo esperado y lo crticas que sean las distintas funciones en ese mbito

5.3.6 Tcnicas basadas en la naturaleza de la aplicacin

Las tcnicas anteriores se pueden aplicar a cualquier tipo de software. Sin embargo, para algunos tipos de aplicaciones, es necesario conocimientos especficos adicionales para derivar las pruebas. La siguiente lista proporciona unas cuantas reas de pruebas especializadas, basndose en la naturaleza de la aplicacin que se est comprobando: Pruebas Orientadas a Objetos [Jor02:c17; Pfl01:c8s7.5] (Bin00) Pruebas basadas en componentes

44

 Pruebas para Internet Pruebas para GUI [Jor20] Pruebas para programas concurrentes (Car91) Pruebas de conformidad de protocolos (Pos96; Boc94) Pruebas para sistemas de tiempo real (Sch94) Pruebas para sistemas de seguridad crtica (IEEE1228-94)

5.3.7 Seleccionando y combinando tcnicas 5.3.7.1 Funcional y estructuralmente

[Bei90:c1s.2.2; Jor02:c2, c9, c12; Per95:c17] (Pos96) Las tcnicas de pruebas basadas en las especificaciones y el cdigo se contrastan frecuentemente como pruebas funcionales vs estructurales. Estos dos mtodos de seleccin de pruebas no se deber ver como alternativos si no como complementarios; de hecho, usan fuentes de informacin diferentes y se ha comprobado que remarcan diferentes tipos de problemas. Estas tcnicas se pueden combinar, dependiendo del presupuesto para pruebas.

5.3.7.2

Deterministas vs aleatorias

(Ham92; Lyu96:p541-547) Los casos de pruebas se pueden seleccionar de una forma determinista, de acuerdo con una de las varias tcnicas enunciadas, o seleccionadas aleatoriamente de una distribucin de entradas de datos, como se hace normalmente en las pruebas de confiabilidad. Existen varias comparaciones analticas y empricas que analizan las condiciones en que uno de los mtodos es ms efectivo que el otro.

5.4 Medidas de las pruebas

Algunas veces, las tcnicas de pruebas se confunden con los objetivos de las pruebas. Las tcnicas de pruebas se deben ver como medios que ayudan a conseguir los objetivos de las pruebas. Por ejemplo, la cobertura de condiciones es una tcnica de pruebas muy popular. Conseguir el valor de la cobertura de condiciones no debera ser un objetivo de las pruebas en s mismo: es solo un medio para mejorar las posibilidades de encontrar fallos realizando pruebas sistemticas en cada condicin del programa para un punto de decisiones. Para prevenir dichas interpretaciones errneas, debera hacerse una distincin muy clara entre las medidas de las pruebas, que proporcionan una evaluacin del programa que se est comprobando, basada en los resultados observados de las pruebas y aquellas que evalan la completitud del conjunto de pruebas. Se proporciona ms informacin acerca de medidas para programas en el AC de la Gestin del la Ingeniera del Software, punto 6, Medidas en la ingeniera del software. Se puede encontrar ms informacin en el AC de la Gestin del la Ingeniera del Software, punto 4, Proceso y medidas del producto. Las medidas se consideran, normalmente, como esenciales en los anlisis de calidad. Las medidas tambin se pueden utilizar para optimizar la planificacin y ejecuciones de las pruebas. La gestin de pruebas puede utilizar varios procesos para medir o vigilar el progreso realizado. Las medidas relacionadas con el proceso de gestin de pruebas se abordan en el punto 5.1 Consideraciones prcticas.

5.4.1 Evaluacin de un programa durante las pruebas

(IEEE982.1-98)

45

5.4.1.1

Medidas para ayudar en la planificacin y diseo de pruebas de programas

[Bei90:c7s4.2; Jor02:c9] (Ber96; IEEE982.1-88) Las medidas basadas en el tamao de un programa (por ejemplo, nmero de lneas de cdigo o mtodos) o en la estructura de un programa (como la complejidad), se usan para guiar a las pruebas. Las medidas estructurales pueden incluir medidas entre mdulos del programa, en trminos de la frecuencia en que cada mdulo llama a los otros.

5.4.1.2

Tipos de errores, clasificacin y estadsticas

[Bei90:c2; Jor02:c2; Pfl01:c8] (Bei90; IEEE1044-93; Kan99; Lyu96) La literatura de pruebas es rica a la hora de clasificar y analizar errores. Con el objetivo de hacer las pruebas ms efectivas, es importante saber que tipos de errores se pueden encontrar en un programa que se est comprobando y la frecuencia relativa en que estos errores han sucedido antes. Esta informacin puede ser muy til para realizar predicciones de calidad y tambin para mejorar el proceso. Se puede encontrar ms informacin en el AC de la Calidad del Software, punto 3.2 Caracterizacin de defectos. Existe un estndar del IEEE acerca de como clasificar anomalas del software (IEEE1044-93).

5.4.1.3

Densidad de fallos

[Per95:c20] (IEEE982.1-88; Lyu96:c9) Un programa que se est comprobando se puede valorar contando y clasificando los errores descubiertos por su tipo. Parra cada tipo de error, la densidad de errores se mide como la razn entre el nmero de errores encontrados y el tamao del programa.

5.4.1.4

Vida de las pruebas, evaluacin de confiabilidad

[Pfl01:c9] (Pos96:p146-154) Una estimacin estadstica de la confiabilidad del software, que se puede conseguir mediante la realizacin y evaluacin de la confiabilidad (vase 51 punto 2.2.5), se puede usar para evaluar un producto y decidir si las pruebas se pueden detener o no.

5.4.1.5

Modelos de crecimiento de la confiabilidad

[Lyu96:c7; Pfl01:c9] (Lyu96:c3, c4) Los modelos de crecimiento de la confiabilidad proporcionan una prediccin de confiabilidad basada en los fallos observados durante la realizacin y evaluacin de la confiabilidad (vase punto 2.2.5). Estos modelos asumen, en general, que los errores que causan los fallos observados se han arreglado (aunque algunos modelos tambin aceptan arreglos imperfectos), y por tanto, el producto muestra una confiabilidad incremental de promedio. Existen docenas de modelos publicados en la actualidad. Muchos se basan en algunas presunciones comunes, y otros no. Mayoritariamente, estos modelos se dividen en modelos de cuenta de fallos y tiempo entre fallos.

5.4.2 Evaluacin de las pruebas realizadas 5.4.2.1 Medidas de la cobertura/completitud

[Jor02:c9; Pfl01:c8] (IEEE982.1-88) Varios criterios de idoneidad de las pruebas necesitan que los casos de pruebas ejecuten sistemticamente un conjunto de elementos identificados en el programa o en la especificacin (vase punto 3). Para evaluar la completitud de las pruebas realizadas, los ingenieros de pruebas pueden monitorizar los elementos cubiertos y su nmero total. Por ejemplo, es posible medir el porcentaje de condiciones cubiertas ejecutadas entre las definidas en la

46

especificacin. La idoneidad de los criterios basados en cdigo necesita la instrumentacin adecuada del programa que se est comprobando.

5.4.2.2

Introduccin de errores

[Pfl01:c8] (Zhu97:s3.1) Algunas veces se introducen errores artificialmente en un programa antes de comprobarlo. Cuando las pruebas se realizan, algunos de estos errores aparecern y posiblemente algunos otros que ya estaban en el software tambin aparecern. En teora, dependiendo de cul de los errores artificiales aparezca y cuntos de ellos, se puede evaluar la efectividad de las pruebas y se puede estimar el nmero restante de errores genuinos. En la prctica, los matemticos estadsticos se cuestionan la distribucin y representatividad de los errores introducidos en relacin con los errores genuinos y el tamao pequeo de la muestra en la que se basa cualquier extrapolacin. Algunos incluso afirman que esta tcnica debera usarse con sumo cuidado, ya que introducir errores en el software acarrea el riesgo obvio de olvidarlos all.

5.4.2.3

Puntuacin de la mutacin

[Zhu97:s3.2-s3.3] En las pruebas por mutacin (vase el punto 3.4.2), la razn de mutantes matados por nmero total de mutantes generados puede ser una medida de la efectividad del conjunto de pruebas realizadas.

5.4.2.4

Comparacin y efectividad relativa de las diferentes tcnicas

[Jor02:c9, c12; Per95:c17; Zhu97:s5] (Fra93; Fra98; Pos96: p64-72) Se han llevado a cabo varios estudios para comparar la efectividad relativa de las diferentes tcnicas de pruebas. Es importante ser preciso acerca de la propiedad contra la cual las tcnicas se han calificado; cual, por ejemplo, es el significado exacto dado al trmino efectividad? Las interpretaciones posibles son: el nmero de pruebas necesarias para encontrar el primer fallo, la razn entre el nmero de errores encontrados durante las pruebas y todos los errores encontrados durante y despus de las pruebas, o cual fue la mejora de la confiabilidad. Se han llevado a cabo comparaciones analticas y empricas entre las diferentes tcnicas, de acuerdo con cada uno de los significados de efectividad especificados antes.

5.5 El Proceso de las Pruebas

Los conceptos de pruebas, estrategias, tcnicas y medidas han de ser integrados en un proceso definido y controlado, que debe ser gestionado por personas. El proceso de las pruebas soporta actividades y sirve de gua a los equipos de pruebas, desde la planificacin de las pruebas hasta la evaluacin de los resultados de las pruebas, de tal manera que se puede proporcionar una garanta justificada de que los objetivos de las pruebas se conseguirn de una manera econmica.

5.5.1 Consideraciones prcticas 5.5.1.1 Actitudes y programacin sin ego

[Bei90:c13s3.2; Pfl01:c8] Un elemento muy importante para el xito de las pruebas es una actitud de colaboracin respecto a las actividades de pruebas y garanta de calidad. Los jefes de proyecto tienen un papel fundamental en fomentar una recepcin favorable en general respecto al descubrimiento de fallos durante el desarrollo y mantenimiento; particularmente, previniendo que los programadores se obsesionen con quien es el dueo del cdigo, de tal forma que ninguno se sienta responsable por los fallos que aparezcan en su cdigo.

47

5.5.1.2
[Kan01]

Guas para las pruebas

Se pueden guiar las fases de pruebas con varios mecanismos, por ejemplo; en pruebas basadas en el riego, que usa los riesgos en el producto para asignar prioridad y centrar la atencin de las estrategias de pruebas; o en las pruebas basadas en situaciones, en las que los casos de pruebas se definen y basan en escenarios de software especificados.

5.5.1.3

Gestin del proceso de las pruebas

[Bec02: III; Per95:c1-c4; Pfl01:c9] (IEEE1074-97; IEEE12207.0-96:s5.3.9, s5.4.2, s6.4, s6.5) Las actividades de pruebas realizadas a diferentes niveles (vase punto 2, Niveles de pruebas) se deben organizar, junto con las personas, herramientas, normas y medidas, en un proceso bien definido que ser una parte integral del ciclo de vida del software. En el estndar IEEE/EIA 12207.0, las pruebas no se describen como un proceso independiente, si no que los principios de las actividades de las pruebas se encuentran incluidos con los cinco procesos primarios del ciclo de vida y con los procesos de soporte. En el estndar IEEE 1074, las pruebas se agrupan con otras actividades de evaluacin como una parte integral del ciclo de vida completo.

5.5.1.4

Documentacin y productos de las pruebas

[Bei90:c13s5; Kan99:c12; Per95:c19; Pfl01:c9s8.8] (IEEE829-98) La documentacin es una parte integral de la formalizacin del proceso de las pruebas. El estndar del IEEE Estndar para la Documentacin de las Pruebas del Software (IEEE829-98) proporciona una buena descripcin de los documentos de las pruebas y su relacin entre cada uno y con el proceso de las pruebas. La documentacin de pruebas puede incluir, entre otros, el Plan de Pruebas, la Especificacin del Diseo de las Pruebas, la Especificacin del Procedimiento de las Pruebas, la Especificacin de los Casos de Pruebas, el Diario de las Pruebas y el Informe de Problemas o de Incidentes durante las Pruebas. El software que se est comprobando se documenta como el Artculo en Pruebas. La documentacin de las pruebas se debe generar y actualizar continuamente, con el mismo nivel de calidad que cualquier otro tipo de documentacin en la ingeniera del software.

5.5.1.5

Equipo de pruebas interno vs equipo independiente

[Bei90:c13s2.2-c13s2.3; Kan99:c15; Per95:c4; Pfl01:c9] La formalizacin del proceso de pruebas tambin puede formalizar la organizacin del equipo de pruebas. El equipo de pruebas puede estar compuesto por miembros internos (parte del equipo del proyecto, involucrados o no en la construccin del software), o de miembros externos, con la esperanza de contar con una perspectiva independiente y sin prejuicios, o, finalmente, de miembros internos y externos. La decisin puede ser afectada por consideraciones como coste, planificacin, nivel de madurez de las organizacin involucradas y como de crtica sea la aplicacin.

5.5.1.6

Estimacin coste/esfuerzo y otras medidas del proceso

[Per95:c4, c21] (Per95: Apndice B; Pos96:p139-145; IEEE982.1-88) Los jefes de proyectos pueden usar varias medidas, acerca de los recursos invertidos en las pruebas y de la efectividad de las varias fases de pruebas en encontrar fallos, para controlar y mejorar el proceso de las pruebas. Estas medidas de las pruebas pueden cubrir, entre otros, aspectos como el nmero de casos de pruebas especificados, el nmero de casos de pruebas ejecutados, el nmero de casos de pruebas superados y el nmero de casos de pruebas no superados. La evaluacin de los informes de las fases de pruebas se puede combinar con anlisis de las races de las causas para evaluar la efectividad del proceso de las pruebas en encontrar errores tan pronto como sea posible. Dicha evaluacin se puede asociar con el anlisis de riesgos. Lo que es ms, los recursos que merece la pena invertir en las pruebas deberan ser proporcionales al uso/importancia de la aplicacin: diferentes tcnicas tienen distinto coste y proporcionan diferentes niveles de seguridad en la confiabilidad del producto.

48

5.5.1.7

Finalizacin

[Bei90:c2s2.4; Per95:c2] Se debe tomar una decisin acerca de cuantas pruebas son suficientes y cuando la fase de pruebas se puede finalizar. Las medidas concienzudas, como las conseguidas mediante cobertura de cdigo o completitud funcional y la estimacin de densidad de errores o de confiabilidad operativa, proporcionan un suporte muy til, pero no son suficientes por s mismas. Esta decisin tambin incluye consideraciones acerca del coste y los riesgos en que se incurrir debido a los fallos potenciales que an queden, en vez del coste que conllevara continuar realizando pruebas. Vase tambin el punto 1.2.1 Criterios de seleccin de pruebas/Criterios de idoneidad de pruebas.

5.5.1.8
[Bei90:c13s5]

Reutilizacin de pruebas y patrones de pruebas

Con el objetivo de realizar pruebas o mantenimiento de una forma organizada y efectiva respecto al coste, los medios usados para realizar pruebas en cada parte del software se deberan reutilizar de una forma sistemtica. Dicho repositorio de material de pruebas debe estar bajo el control de un software de gestin de configuraciones, de forma que los cambios en los requerimientos del software o el diseo queden reflejados en cambios en el alcance de las pruebas realizadas. Las soluciones adoptadas para realizar pruebas en determinados tipos de aplicaciones bajo determinada circunstancias, teniendo en cuenta los motivos detrs de las decisiones que se han tomado, forman un patrn de pruebas que se puede documentar y ser reutilizado en proyectos similares.

5.5.2 Actividades de las pruebas

En este punto, se ver una pequea introduccin a las actividades del software; gestionar con xito las actividades relacionada con las pruebas, como la siguiente descripcin da a entender, depende en gran medida del proceso de Gestin de Configuracin del Software.

5.5.2.1

Planificacin

[Kan99:c12; Per95:c19; Pfl01:c8s7.6] (IEEE829-98:s4; IEEE1008-87:s1-s3) Como cualquier otro aspecto de la gestin de proyectos, las actividades de las pruebas se deben planificar. Algunos aspectos clave de la planificacin de las pruebas incluyen la coordinacin de personal, la gestin de instalaciones y equipos disponibles (que pueden incluir soportes magnticos, planes de pruebas y procedimientos) y planificar en caso de posibles situaciones no deseables. Si se mantiene ms de una lnea base del software al mismo tiempo, una importante consideracin de planificacin es el tiempo y esfuerzo necesario para asegurarse de que se ha usado la configuracin correcta para establecer el entorno de pruebas.

5.5.2.2

Generacin de casos de pruebas

[Kan99:c7] (Pos96:c2; IEEE1008-87:s4, s5) La generacin de caos de pruebas se basa en el nivel de pruebas que se vaya a realizar y en las tcnicas de pruebas a usar. Los casos de pruebas deberan estar bajo el control de un software de gestin de configuraciones e incluir los resultados esperados para cada prueba.

5.5.2.3
[Kan99:c11]

Desarrollo en el entorno de pruebas

El entorno usado para las pruebas debera ser compatible con las herramientas de ingeniera de software. Debera facilitar el desarrollo y control de casos de pruebas y la anotacin y recuperacin de los resultados esperados, los scripts y otros materiales de pruebas.

49

5.5.2.4

Ejecucin

[Bei90:c13; Kan99:c11] (IEEE1008-87:s6, s7) La ejecucin de las pruebas deberan incluir un principio bsico de experimentacin cientfica: todos los pasos durante las pruebas se deberan realizar y documentar de una forma lo suficientemente clara, que cualquier otra persona debera ser capaz de reproducir los resultados. Por tanto, las pruebas deben realizarse de acuerdo con los procedimientos documentados y usando una versin claramente definida del software que se est comprobando.

5.5.2.5

Evaluacin de los resultados de las pruebas

[Per95:c20, c21] (Pos96:p18-20, p131-138) Los resultados de las pruebas se deben evaluar para determinar si las pruebas han sido satisfactorias o no. En la mayora de los casos, satisfactorias significa que el software se ha ejecutado como se esperaba y no ha tenido ningn resultado inesperado importante. No todos los resultados inesperados son necesariamente errores, ya que se podra considerar que algunos son simple ruido. Antes de que se pueda arreglar un error, se necesita realizar un anlisis y algn trabajo de depuracin para identificarlo, aislarlo y describirlo. Cuando los resultados de las pruebas son particularmente importantes, puede que se convoque una revisin formal para evaluarlas.

5.5.2.6

Notificacin de problemas/Diario de pruebas

[Kan99:c5; Per95:c20] (IEEE829-98:s9-s10) Las actividades de las pruebas se pueden aadir a un diario de pruebas para identificar cuando una prueba se ha ejecutado, quien la ha realizado, que configuracin del software se ha utilizado y cualquier otra informacin relevante de identificacin. Resultados inesperados o incorrectos se pueden aadir a un sistema de notificacin de problemas, cuyos datos sern la base para procesos de depuracin posteriormente y para arreglar los errores que causaron problemas durante las pruebas. Las anomalas no clasificadas como errores tambin se podran documentar, en caso de que ms tarde resulte que producen problemas ms serios de lo que se pens originalmente. Los informes de pruebas tambin son una entrada para los procesos de requerimientos de cambi de gestin (vase el AC de la Gestin de la Configuracin del Software, punto 3, Control de la configuracin del software)

5.5.2.7
[Kan99:c6]

Seguimiento de defectos

Los fallos observados durante las pruebas son, en la mayora de los casos, debidos a errores o defectos en el software. Dichos defectos se pueden analizar para determinar cuando fueron introducidos en el software, que clase de error produjo que se aparecieran (por ejemplo requerimientos definidos pobremente, declaraciones incorrectas de variables, fallo de memoria o errores de programacin) y cuando deberan haber sido observados en el software por primera vez. La informacin del seguimiento de defectos se usa para determinar qu aspectos de la ingeniera del software necesitan mejorase y la efectividad de anlisis y pruebas anteriores.

50

6 Mantenimiento de software
Los esfuerzos del desarrollo de software resultan en la entrega de un producto de software el cual satisface los requerimientos de usuario. Por consecuencia, el producto de software debe cambiar o evolucionar. Una vez en operacin, los defectos se descubren, los entornos de operacin cambian y nuevos requerimientos de usuario aparecen. La fase de mantenimiento del ciclo de vida comienza siguiendo un periodo de garanta o entrega de soporte post-implementacin, sin embargo las actividades de mantenimiento suceden mucho antes. El mantenimiento de software es una parte integral del ciclo de vida del software. Sin embargo histricamente no ha recibido el mismo grado de atencin que las otras fases existentes. Histricamente, el desarrollo de software ha tenido un perfil mucho ms alto que el mantenimiento en muchas organizaciones. Esto ahora est cambiando, como algunas organizaciones que se esfuerzan por exprimir en la mayora sus investigaciones de desarrollo de software manteniendo la operabilidad del sistema el mayor tiempo posible. Las preocupaciones acerca del ao 2000 se hallaron enfocadas significantemente en la fase de mantenimiento de software, y el paradigma de cdigo abierto ha prestado ms atencin al problema de artefactos de mantenimiento de software desarrollado por otros. En la gua, el mantenimiento de software est definido como la totalidad de acciones necesarias para proveer soporte rentable (econmico y fiable) al software. Las actividades se presentan durante el escenario de pre-entrega, as como durante el escenario de post-entrega. Las actividades de pre-entrega incluyen: planeamiento para operaciones post-entrega, planeamiento para mantenimiento, planeamiento para determinacin logstica de las actividades de transicin. Las actividades de post-entrega incluyen: Modificacin de Software, Entrenamiento , funcionamiento o interfaces para un servicio de asistencia. Las reas del conocimiento del mantenimiento de software esta relacionados con todos los aspectos de la ingeniera del software, por lo tanto, esta descripcin de las reas del conocimiento estn enlazadas a todos los captulos de la gua. Descomposicin de temas para Mantenimiento de software

6.1 Fundamentos del mantenimiento de software

Esta primera seccin introduce los conceptos y terminologa que forman una base subyacente para entender el papel y enfoque del mantenimiento de software. Los tpicos proveen definiciones y enfatizan porque hay una necesidad de mantenimiento. Las categoras del mantenimiento de software son crticas para entender los significados subyacentes.

6.1.1 Definiciones y terminologa

El mantenimiento de software es definido en la norma IEEE para mantenimiento de software, IEEE 1219, como la modificacin de un producto de software despus de la entrega para corregir fallas, para mejorar desempeo u otros atributos, o para adaptar el producto a un entorno modificado. La norma tambin se dirige a actividades de mantenimiento antes de la entrega del producto de software, pero solo en un apndice de informacin de la norma. La norma IEEE/EIA 12207 para el ciclo de vida de vida de software ilustra esencialmente como uno de los procesos principales del ciclo de vida del software, y describe mantenimiento como el proceso de un producto de software el cual sufre modificacin cdigo y documentacin asociada debido a un problema o la necesidad de mejoramiento. el el al El

51

objetivo es modificar el producto de software existente mientras se preserva su integridad. ISO/IEC 14764, la norma internacional para el mantenimiento de software, define el mantenimiento del software en los mismos trminos que el IEEE/EIA 12207 y enfatiza los aspectos de pre-entrega, del mantenimiento, por ejemplo, planeacin.

6.1.2 Naturaleza del mantenimiento

El mantenimiento de software sostiene el producto de software a lo largo de su ciclo de vida operacional. Las peticiones de modificacin se registran y rastrean, el impacto de los cambios propuestos es determinado, el cdigo y otros artefactos son modificados, las pruebas son ejecutadas, y las nuevas versiones de un producto de software son lanzadas. Tambin, el entrenamiento y soporte diario son provedos a los usuarios. Pfleeger declara que el mantenimiento tiene un amplio alcance, mas all del seguimiento y control que el desarrollo. Un mantenedor (el que hace mantenimiento) est definido por el IEEE/EIA 12207 como una organizacin en la cual se presenta actividades de mantenimiento. En esta rea del conocimiento, el trmino se referir algunas veces a los individuos que realizan esas actividades, contrastndolos con los desarrolladores. El IEEE/EIA 12207 identifica las actividades primarias de mantenimiento de software como: - Implementacin de procesos - Anlisis de problema y modificacin - Implementacin de modificacin - Aceptacin/revisin de mantenimiento - Migracin - Retiro Estas actividades se discutirn en el tpico de actividades de mantenimiento. Los mantenedores pueden aprender del conocimiento de los desarrolladores de software. El contacto con los desarrolladores y la inclusin temprana por parte del mantenedor ayuda a reducir el esfuerzo de mantenimiento. En algunas instancias, el ingeniero de software no puede ser contactado o se ha trasladado a otras tareas, lo cual crea un reto adicional para los mantenedores. El mantenimiento debe tomar los productos del desarrollo, cdigo, o documentacin por ejemplo, y apoyarlos inmediatamente y mantenerlos/envolverlos progresivamente durante el ciclo de vida del software.

6.1.3 Necesidad por el mantenimiento

El mantenimiento es necesario para asegurar que el software contina satisfaciendo los requerimientos de usuario. El mantenimiento es aplicable al software desarrollado usando cualquier modelo de ciclo de vida de software (por ejemplo, espiral). El sistema cambia debido a las acciones de software correctivas y no correctivas. El mantenimiento debe presentarse con el fin de: -Corregir fallas -Mejorar el diseo -Implementar mejoras -Interfaces con otros sistemas -Adaptar programas de diferentes hardwares, software, caractersticas de sistema, y facilidades de telecomunicaciones que puedan ser usadas -Migrar legado de software -Retirar software Las actividades del mantenedor comprenden cuatro caractersticas clave, de acuerdo con Pfleeger: -Mantener el control sobre las funciones del da a da del software 52

-Mantener el control sobre las modificaciones de software -Perfeccionar funciones existentes -Prevenir la degradacin del desempeo de software a nivelen inaceptables

6.1.4 La mayora de los costos de mantenimiento

El mantenimiento consume una parte importante de los recursos financieros del ciclo de vida del software. Una percepcin comn del mantenimiento de software es que se limita a corregir las fallas. Sin embargo, los estudios y encuestas en los ltimos aos han indicado que la mayora, ms del 80%, del esfuerzo de mantenimiento de software se utiliza para acciones no correctivas. Jones (Jon91) describe la forma en que los gerentes del mantenimiento del software a menudo agrupan las mejoras y las correcciones en los informes de gestin. Esta inclusin de las solicitudes de mejora con los reportes de problemas, contribuye a algunos de los conceptos errneos sobre el alto costo de correcciones. Comprender las categoras de mantenimiento de software ayuda a entender el costo de la estructura del mantenimiento de software. Adems, la comprensin de los factores que influyen en el mantenimiento de un sistema puede ayudar a contener los costos. Pfleeger [Pfl01] presenta algunas de los factores tcnicos y no tcnicos que afectan los costos del mantenimiento de software, de la siguiente manera: Tipo de aplicacin Novedad de software Disponibilidad de personal de Mantenimiento de software Prolongacin de la vida del software Caractersticas de hardware Calidad de diseo, construccin, documentacin y pruebas de software

6.1.5 Evolucin del Software

Lehman abord por primera vez el mantenimiento del software y evolucin de los sistemas en 1969. Durante un perodo de veinte aos, su investigacin condujo a la formulacin de las ocho "Leyes de Evolucin". Las principales conclusiones incluyen el hecho de que el mantenimiento es desarrollo evolutivo, y que las decisiones de mantenimiento estn soportadas por el entendimiento de lo que sucede a los sistemas (y software) a travs del tiempo. Otros afirman que el mantenimiento es un desarrollo continuo, excepto que hay una entrada extra (o limitacin)-existente y un software extenso nunca es completo y contina evolucionando. A medida que evoluciona, se vuelve ms complejo a menos que se tomen medidas para reducir esta complejidad. Desde que el software muestre tendencias y un comportamiento regular, estas se pueden medir. Los intentos de desarrollar modelos predictivos para estimar los esfuerzos de mantenimiento que se hayan hecho, y, como consecuencia, se han desarrollados herramientas tiles de gestin.

6.1.6 categoras de mantenimiento

Lientz y Swanson inicialmente definen tres categoras de mantenimiento: correctiva, adaptativa y perfectiva. Esta definicin fue actualizada despus en la norma para mantenimiento de software de ingeniera-software, ISO/IEC 14764 para incluir cuatro categoras como sigue:

53

Mantenimiento correctivo: modificacin reactiva de un producto de software presentada despus de la entrega para corregir problemas descubiertos. Mantenimiento adaptativo: modificacin de un producto de software presentada despus de la entrega para mantener un producto de software utilizable en un entorno cambiado o cambiante. Mantenimiento perfectivo: modificacin de un producto de software despus de la entrega para mejorar el desempeo o mantenimiento. Mantenimiento preventivo: modificacin de un producto de software despus de ser entregado para detectar y corregir fallas latentes en el producto de software antes que estas se conviertan en fallas efectivas. ISO/IEC 14764 clasifica el mantenimiento adaptativo y perfectivo como mejoras. Tambin agrupa juntas las categoras de mantenimiento preventivo y correctivo en una categora de correccin, como se muestra en la tabla 1. El mantenimiento preventivo, la categora ms reciente, se presenta en su mayora en los productos de software cuya seguridad es crtica. Correccin Proactiva Reactiva preventiva correctiva Mejoramiento Perfectiva Adaptativa

Tabla 1: categoras del mantenimiento de software.

6.2 Problemas clave en el mantenimiento de software

Una cantidad de problemas clave deben ser tratados con el fin de asegurar un mantenimiento de software efectivo. Esto es importante para entender que el mantenimiento de software provee retos tcnicos y de gestin nicos para los ingenieros de software. Un buen ejemplo podra ser: Tratar de encontrar fallas en un software que contiene 500K lneas de cdigo que el ingeniero de software no desarroll. De manera similar, competir con los desarrolladores de software por recursos es una batalla constante. Planeando para un futuro lanzamiento, mientras se codifica el siguiente lanzamiento y enviando parches de emergencia para el lanzamiento actual, tambin crea un reto. La siguiente seccin presenta algunos de los problemas tcnicos y de gestin relacionados al mantenimiento de software. Ellos han sido agrupados bajo los siguientes encabezados de ttulos: Problemas tcnicos Problemas de gestin Estimacin de costos Medidas

6.2.1 Problemas tcnicos 6.2.1.1 Entendimiento limitado

El entendimiento limitado se refiere a cun rpido un ingeniero de software puede entender donde hacer cambios o una correccin en un software que el mismo no ha desarrollado. Las investigaciones indican que de un 40% a 60% del esfuerzo de mantenimiento es dedicado al entendimiento del software para ser modificado, as, el tema de la compresin de software es de gran inters para los ingenieros de software. La comprensin es ms difcil en una representacin orientada- texto, en cdigo fuente, por ejemplo, donde a menudo es difcil de rastrear la evolucin de software a travs de sus versiones(lanzamientos) si los cambios no estn documentados y cuando los desarrolladores no estn disponibles para explicarlo, que es frecuentemente el caso. As, los ingenieros de

54

software debern tener inicialmente un entendimiento limitado del software, y mucho mas debe realizarse para remediar esto.

6.2.1.2

Pruebas

El costo de repetir pruebas completas en un componente mayor de un software puede ser significante en trminos de tiempo y dinero. Pruebas de regresin, la repeticin de pruebas selectiva de un software o componente para verificar que las modificaciones no han causados efectos no intencionados, es importante para el mantenimiento. As como encontrar el tiempo para las pruebas es a menudo difcil. Existe el reto de pruebas coordinadas cuando los diferentes miembros del equipo de mantenimiento estn trabajando en diferentes problemas al mismo tiempo. Cuando el software muestra funciones criticas, puede ser imposible desconectarlo para pruebas. El rea de conocimiento de pruebas de software provee informacin y referencias en su subtema pruebas de regresin.

6.2.1.3

Anlisis de impacto

El anlisis de impacto describe como conducir, de manera econmica t completa, un anlisis completo sobre la temtica del impacto en un software existente. Los mantenedores debern poseer un ntimo conocimiento de la estructura y contenido de software. Ellos usan ese conocimiento para realizar anlisis de impacto el cual identifica todos los sistemas y productos de software afectados por una peticin de cambio en software y desarrolla un estimado de los recursos necesitados para el logro del cambio. Adicionalmente, el riesgo de hacer el cambio es determinado. La peticin de cambio, algunas veces llamada una peticin de modificacin, y frecuentemente llamada un reporte de problema, debe ser analizada primera y traducida en trminos de software. Eso es presentado despus de que una peticin de cambio entra al proceso de gestin de la configuracin de software. Arthur declara que los objetivos del anlisis de impacto son: Determinacin del alcance de un cambio de acuerdo a un plan y trabajo de implementacin Desarrollo de estimaciones exactas de los recursos necesitados para realizar el trabajo Anlisis de los costos y/o beneficios del cambio solicitado Comunicacin hacia los otros de la complejidad de un cambio dado

La gravedad de un problema es usualmente usada para decidir cmo y cuando un problema ser reparado. El ingeniero de software entonces identifica los componentes afectados. Varias soluciones potenciales son ofrecidas y por consecuente una recomendacin es hecha para el mejor va de accin. El software desarrollado con mantenibilidad en mente facilita en gran manera el anlisis de impacto. Ms informacin puede ser encontrada en el rea de conocimiento de gestin de configuracin de software.

6.2.1.4

Mantenibilidad

Cmo se promueve y se hace seguimiento a los problemas de mantenibilidad a lo largo del desarrollo?, la IEEE define la mantenibilidad como la facilidad con la cual un software puede ser mantenido, mejorado, adaptado, o corregido para satisfacer requerimientos especificados. ISO/IEC define la mantenibilidad como una de las caractersticas de calidad. Las sub-caractersticas de la mantenibilidad deben ser especificadas, repasadas, y controladas durante las actividades de desarrollo de software con el fin de reducir los costos de mantenimiento. Si esto se realiza con xito, la mantenibilidad de software ser mejorada. Esto es frecuentemente una dificultad para lograr porque las sub-caractersticas de la mantenibilidad no son un enfoque importante durante el proceso de desarrollo de software. Los desarrolladores estn preocupados con muchas otras cosas y frecuentemente descuidan los requerimientos del mantenedor. Esto puede a su vez, y frecuentemente lo hace, resulta en una falta de la documentacin del sistema, lo cual es una causa principal de dificultades en comprensin del programa y anlisis de impacto. Tambin ha sido observado que la presencia

55

de procesos maduros y sistemticos, tcnicas, y herramientas ayuda al mejorar mantenibilidad de un sistema.

la

6.2.2 Problemas de gestin 6.2.2.1 Alineacin con los objetivos organizacionales

El principal nfasis es entregar a tiempo y sobre el presupuesto los requerimientos de usuario. Los objetivos organizacionales describen como demostrar el retorno en la inversin de actividades de mantenimiento de software. Bennett declara que el desarrollo inicial de software es usualmente basado-proyecto, con una escala de tiempo y presupuesto definidos para conocer las necesidades del usuario, en contraste, el mantenimiento de software frecuentemente tiene el objetivo de extender la vida del software lo ms posible, adems, deben ser manejados por la necesidad de encontrarse con la demanda del usuario para las actualizaciones de software y mejoras. En ambos casos, el retorno en inversin es mucho menos claro, as que la vista desde un nivel de gestin mayor es usualmente de una actividad mayor consumiendo recursos significativos sin beneficios cuantificables claros para la organizacin.

6.2.2.2

Personal

Esto se refiere a como atraer y mantener un personal de mantenimiento. El mantenimiento usualmente no es visto como un trabajo glamoroso. Deklava provee una lista de problemas relacionados con el personal basado en el estudio de datos. Como resultado, el personal de mantenimiento de software es visto frecuentemente como ciudadanos de segunda clase y la moral sufre.

6.2.2.3

Proceso

El proceso de software es un conjunto de actividades, mtodos, prcticas, y transformaciones las cuales la gente usa para desarrollar y mantener software y sus productos asociados. En el nivel de proceso, las actividades de mantenimiento comparten mucho en comn con el desarrollo de software (por ejemplo, la gestin de configuracin de software es una actividad crucial en ambos). El mantenimiento tambin requiere varias actividades que no se encuentran en el desarrollo de software (vea la seccin 3.2 en actividades nicas para detalles.) esas actividades presentan retos para el mantenimiento.

6.2.2.4

Aspectos organizacionales del mantenimiento

Los aspectos organizacionales describen como identificar cual organizacin y/ o funcin sera responsable por el mantenimiento de software. El equipo que desarrolla el software no es asignado necesariamente en mantener el software una vez esta en operacin. En la decisin en la cual la funcin de mantenimiento de software se ubicara, las organizaciones de ingeniera del software deben, por ejemplo, estar con el desarrollador original o ir a un equipo separado (o mantenedor). A menudo, la opcin del mantenedor se escoge para asegurar que el software se ejecuta apropiadamente y evoluciona para satisfacer las necesidades cambiantes del usuario. Ya que hay muchos pros y contras para cada una de esas opciones, la decisin debe ser tomada por una base caso-por-caso. Lo que importa es la delegacin o asignacin de la responsabilidad de mantenimiento a un grupo sencillo o persona, indiferentemente de la estructura de la organizacin.

6.2.2.5

Subcontratacin

La subcontratacin del mantenimiento se est convirtiendo en una industria grande. Grandes corporaciones estn subcontratacin portafolios enteras de sistemas de software, incluyendo mantenimiento de software. Ms aun, la opcin de subcontratacin es seleccionada para software de menos misin crtica, as es como las compaas estn dispuestas a perder el control del software usado en los ncleos de sus negocios. Carey reporta que algunos externalizaran solamente si ellos pueden encontrar formas de control estratgico de mantenimiento. Sin embargo, las medidas de control son difciles de encontrar. Uno de los mayores retos para los subcontratadores es determinar el alcance de los servicios de

56

mantenimiento requeridos y los detalles contractuales. McCracken declara que 50% de los subcontratadores provee servicios sin ningn acuerdo claro de nivel de servicio. Las compaas de subcontratacin tpicamente gastan un nmero de meses evaluando el software antes que ellos entren en la relacin contractual. Otro reto identificado es la transicin del software hacia el subcontratador.

6.2.3 Estimacin de costos de mantenimiento

Los ingenieros de software deben entender las diferentes categoras del mantenimiento de software, discutidas anteriormente, con el fin de direccionar la pregunta de estimacin de costos de mantenimiento de software. Para propsitos de planeacin, los costos de estimacin son un aspecto importante del mantenimiento de software.

6.2.3.1

Estimacin de costos

Esto fue mencionado en el subtema 2.1.3, anlisis de impacto, que el anlisis de impacto identifica todos los sistemas y productos de software afectados por una peticin de cambio de software y desarrolla una estimacin de los recursos necesitados para lograr el cambio. Las estimaciones de costos de mantenimiento son afectados por muchos factores tcnicos y no tcnicos. La ISO/IEC 14764 declara que los dos enfoques ms populares para estimar recursos para el mantenimiento de software son el uso de modelos paramtricos y el uso de experiencia. Ms a menudo, una combinacin de estas es usada.

6.2.3.2

Modelos paramtricos.

Algn trabajo ha sido emprendido en aplicar modelamiento de costos parametricos al mantenimiento de software. Lo significativo es que datos de proyectos pasados son necesitados para usar modelos. Jones discute todos los aspectos de estimacin de costos, incluyendo puntos de funcin, y provee un capitulo detallado en la estimacin de mantenimiento.

6.2.3.3

Experiencia

Experiencia, en la forma del juicio de experto (usando la tcnica delphi, por ejemplo), analogas, y una estructura de desglose del trabajo, varios enfoques que deberan ser usados para aumentar los datos de los modelos parametricos. Claramente el mejor enfoque a la estimacin del mantenimiento es combinar datos empricos y experiencia. Esa informacin deber ser proveda como resultado de un programa de medidas.

6.3 Medidas del mantenimiento de software

Grady y Caswell discute estableciendo un programa de medidas de software transversal a la organizacin, en el cual la colecciona y describe datos y formatos de medida de mantenimiento de software. El proyecto PSM (practical software mesure) describe un proceso de medicin que es usado por muchas organizaciones en la prctica. Hay algunas mediciones de software que son comunes a todas las categoras, las siguientes Categoras de las cuales el instituto de ingeniera de software a identificado: tamao, soporte, cronograma y cualidad. Estas mediciones constituyen un buen punto de partido para el mantenedor. Divisiones y mediciones de productos de procesos son presentadas en el KA proceso de ingeniera de software. El programa de medicin de software esta descrito en la KA Gestin de ingeniera de software.

6.3.1.1

Mediciones especficas

Abran [Abr93] presenta estudios comparativos internos para comparar diferentes organizaciones de mantenimiento interno. El mantenedor debe determinar que mediciones son apropiadas para la organizacin en cuestin.

57

Sugiere mediciones que sean mas especificas a mantenimiento de software de programas de medicin. Esa lista incluye un numero de mediciones por cada uno de las 4 subcateristicas de mantenibilidad: Analizabilidad: Mediciones del mantenedor de soporte o recursos gastados en el intento de diagnostico, deficiencias o causas de falla o en identificacin de partes a ser modificadas Cambiabilidad: Mediciones del mantenedor de soporte asociado a la implementacin de una modificacin especifica. Estabilidad: Medicin del comportamiento inesperado de software, incluyendo aquel encontrado durante el testeo. Pruebabilidad (testing): medicin del soporte del mantenedor y el usuario, en el intento de probar el software modificado, algunas mediciones de mantenibilidad del software pueden obtenerse usando herramientas comerciales.

6.4 Proceso del mantenimiento

La sub rea del proceso del mantenimiento proporciona referencias y Estndares usados para implementar el proceso del mantenimiento de software. El tema de actividades del mantenimiento diferencia el mantenimiento del desarrollo y muestra su relacin con las otras actividades de la ingeniera del software. La necesidad por el proceso de ingeniera del software est bien documentada. Los modelos CMMI aplican para los procesos de mantenimiento de software, y son similares a los procesos de los desarrolladores. Los modelos de capacidad del mantenimiento de software los cuales direccionan los nicos procesos del mantenimiento de software se describen en (Apr03, Nie02, Kaj01).

6.4.1 Procesos de mantenimiento

Los procesos de mantenimiento proporcionan actividades necesarias y entradas/salidas detalladas para esas actividades, y son descritas en los estndares para el mantenimiento de software IEEE 1219 y ISO/IEC 14764. El modelo de proceso de mantenimiento descrito en el estndar para mantenimiento de software (IEEE1219) comienza con el esfuerzo de mantenimiento de software durante el escenario de post-entrega y discute temas como la planeacin para el mantenimiento. El proceso se describe en la figura 2.

ISO/IEC 14764 es una elaboracin del proceso de la IEEE/EIA 12207.0-96. Las actividades de los procesos de mantenimiento de la ISO/IEC son similares a esos de la IEEE, excepto que

58

ellos han agregado una pequea diferencia. Las actividades del proceso de mantenimiento de software desarrolladas por la ISO/IEC se muestran en la figura 3.

Cada una de las actividades de mantenimiento principales de la ISO/IEC 14764 se subdivide aun ms en tareas, como sigue: Implementacin de proceso Anlisis de problema y modificacin Implementacin de modificacin Revisin/aceptacin de mantenimiento Migracin Retiro de software

Takang y Grubb proporcionan una historia de los modelos de procesos de mantenimiento previos al desarrollo de los modelos de procesos de la IEEE y la ISO/IEC. Parikh tambin da un buen resumen de un proceso de mantenimiento genrico. Recientemente, metodologas agiles han emergido las cuales promueven procesos ligeros. Este requerimiento emerge de la creciente demanda por cambio rpido de servicios de mantenimiento. Algunos experimentos con mantenimiento extremo son presentados en (Poo01).

6.4.2 Actividades de mantenimiento

Como se ha dicho, muchas actividades de mantenimiento son similares a aquellas del desarrollo de software. Los mantenedores presentan anlisis, diseo, codificacin, pruebas, y documentacin. Ellos deben rastrear requerimientos en sus actividades as como se hace en el desarrollo, y actualizar documentacin como cambio de lneas base. La ISO.IEC 14764 recomienda que, cuando un mantenedor consulta un proceso similar de desarrollo, debe

59

adaptarlo para encontrar sus necesidades especficas. Sin embargo, para el mantenimiento de software, algunas actividades incluyen procesos nicos para el mantenimiento de software.

6.4.2.1

Actividades nicas

Hay gran cantidad de procesos, actividades y prcticas que son nicas para el mantenimiento de software, por ejemplo: Transicin: es una secuencia controlada y coordinada de actividades durante las cuales un software es transferido progresivamente del desarrollador al mantenedor. Peticin de modificacin aceptacin/rechazo: la peticin de modificacin trabajo sobre cierto tamao/esfuerzo/complejidad que pueden ser rechazados por mantenedores y reencaminados al desarrollador. Peticin de modificacin y ayuda del servicio de asistencia de problemas: una funcin de soporte para el usuario final que dispara la valoracin, priorizacin, y costos de las peticiones de modificacin. Anlisis de impacto Soporte de software: ayuda y aconseja a los usuarios con respecto a peticiones de informacin(por ejemplo, reglas de negocios, validacin, significado de datos y peticiones/reportes ad-hoc) Acuerdos del nivel de servicio (SLAs) y contratos especializados de mantenimiento los cuales son la responsabilidad de los mantenedores.

6.4.2.2

Actividades de soporte

Los mantenedores deben presentar actividades de soporte, como la planeacin de mantenimiento de software, gestin de configuracin de software, verificacin y validacin, garanta de calidad de software, revisiones, autoras, y entrenamiento de usuarios. Otra actividad de soporte, entrenamiento del mantenedor, tambin es necesaria.

6.4.2.3

Actividad de planeacin de mantenimiento

Una importante actividad para el mantenimiento de software es planear, y los mantenedores deben direccionar los problemas relacionados con un nmero de perspectivas de planeacin: Planeamiento de negocios (nivel organizacional) Planeamiento de mantenimiento (nivel de transicin) Planeamiento de lanzamiento/versin (nivel de software) Planeamiento de Peticiones individuales de cambio de software (nivel de requisitos)

En el nivel de peticin individual, el planeamiento es llevado a cabo durante el anlisis de impacto (refirase al sub-tpico 2.1.3 anlisis de impacto para mas detalles). La actividad de planeamiento de lanzamiento/versin requiere que el mantenedor: Coleccione los datos de disponibilidad de peticiones individuales Estar de acuerdo con los usuarios en el contenido de los lanzamientos/versiones subsecuentes Identificar conflictos potenciales y desarrollar alternativas Evaluar el riesgo de un lanzamiento dado y desarrollar un plan de apagado en caso de que se levanten problemas Informar a todos los interesados

Mientras que los proyectos de desarrollo de software pueden tpicamente dura desde algunos meses a algunos aos, la fase de mantenimiento usualmente dura muchos aos. Haciendo estimados de recursos es un elemento clave de la planeacin del mantenimiento. Esos

60

recursos debern ser incluidos en los presupuestos del proyecto de planeacin de los desarrolladores. La planeacin del mantenimiento de software debe empezar con la decisin de desarrollar un nuevo sistema y debe considerar objetivos de calidad. Un documento conceptual debe ser desarrollado, seguido por un plan de mantenimiento. El documento conceptual para mantenimiento debe aadir: El alcance del mantenimiento de software Adaptacin del proceso de mantenimiento de software Identificacin de la organizacin de mantenimiento de software Una estimacin de costos de mantenimiento de software

El siguiente paso es desarrollar un plan de mantenimiento de software correspondiente. Este plan debe ser preparado durante el desarrollo de software, y debe especificar como los usuarios van a pedir modificaciones de software o reportar problemas. El planeamiento de mantenimiento de software es direccionado en la IEEE 1219 e ISO/IEC 14764. ISO/IEC14764 provee guas para el plan de mantenimiento. Finalmente, en el nivel ms superior, la organizacin de mantenimiento tendr que conducir las actividades de planeamiento de negocios (presupuestos, financiamientos, recursos humanos) as como todas las otras divisiones de la organizacin. El conocimiento de mantenimiento requerido para hacerlo puede ser encontrado en las disciplinas relacionadas con el captulo de ingeniera del software.

6.4.2.4

Gestin de configuracin de software

El estndar para el mantenimiento de software de la IEEE, IEEE 1219, describe la gestin de configuracin de software como un elemento crtico del proceso de mantenimiento. Los procedimientos de gestin de configuracin de software deben proporcionar para la verificacin, validacin y auditoria de cada paso requerido para identificar, autorizar, implementar y lanzar el producto de software. No es suficiente simplemente rastrear peticiones de modificacin o reportes de problemas. El producto de software y cualquier cambio hecho a l debe ser controlado. Este control es establecido por medio de la implementacin y reforzamiento de un proceso de gestin de configuracin de software aprobado. El rea de conocimiento de gestin de configuracin de software proporciona detalles de SCM y discute el proceso por el cual las peticiones de cambio de software son presentadas, evaluadas y aprobadas. El SCM para mantenimiento de software es diferente del SCM para desarrollo de software en el nmero de pequeos cambios que deben ser controlados en un software operacional. El proceso de SCM es implementado al desarrollar y seguir un plan de gestin de configuracin y operando procedimientos. Los mantenedores participan en tablas de control de configuracin para determinar el contenido del siguiente lanzamiento/versin.

6.4.2.5

Calidad de software

No es suficiente, tampoco, con solo esperar que la calidad incrementada resultara del mantenimiento de software. Esta debe ser planeada e implementada en procesos para apoyar el proceso de mantenimiento. Las actividades y tcnicas para garantizar la calidad de software (SQA), V&V, revisiones y auditorias deben ser seleccionadas concerniendo con todos los otros procesos para lograr el nivel deseado de calidad. Tambin es recomendado que el mantenedor adapte los procesos de desarrollo de software, tcnicas y entregas, para instanciar documentacin de prueba, y resultados de pruebas. Mas detalles pueden encontrarse en el rea de conocimiento de CALIDAD DE SOFTWARE.

6.5 Tcnicas para el mantenimiento

Esta subarea introduce algunas de las generalmente aceptadas tcnicas usadas en el mantenimiento de software.

61

6.5.1 Comprensin del programa

Los programadores gastan tiempo considerable en leer y entender programas con el fin de implementar cambios. Exploradores de cdigo son herramientas clave para la comprensin de programas. Documentacin clara y concisa puede ayudar en la comprensin de un programa.

6.5.2 Reingeniera
Reingeniera es definida como la exanimacin y alteracin de software para reconstituirlo en una nueva forma, incluye la implementacin subsecuente de la nueva forma. Dorfman and Thayer declaran que la reingeniera es la ms radical (y costosa) forma de alteracin. Otros creen que la reingeniera puede ser usada para cambios menores. A menudo no es realizado para mejorar la Mantenibilidad, pero para reemplazar el envejecimiento del legado de software. Arnold provee un compendio comprensivo de temas, por ejemplo, conceptos, herramientas y tcnicas, estudios de casos y riesgos y beneficios asociados con la reingeniera.

6.5.3 Ingeniera inversa

La ingeniera inversa es el proceso de analizar software para identificar los componentes del software y sus relaciones para crear representaciones del software en otra forma o en niveles altos de abstraccin. La ingeniera de reversa es pasiva; no cambia el software, o resulta en un nuevo software. Los esfuerzos de La ingeniera inversa producen llamados grficos y grficos de flujo de control del cdigo fuente. Un tipo de ingeniera inversa es la redocumentacin. Otro tipo es la recuperacin de diseo. Refactorizacin es transformacin de programa la cual reorganiza un programa sin cambiar su comportamiento, y es una forma de ingeniera de reversa que busca mejorar la estructura del programa. Finalmente, la informacin de ingeniera de reversa ha ganado importancia en los ltimos pocos anos donde los esquemas lgicos son recuperados de bases de datos fsicas.

62

7 Gestin de la configuracin software

ACRNIMOS CCB Junta de Control de la Configuracin CM Gestin de configuracin FCA Auditora de la Configuracin Funcional MTBF Tiempo significativo entre fallos. PCA Auditora de la Configuracin Fsica SCCB Consejo de Control de Configuracin del Software SCI Elemento de configuracin de software SCM Gestin de la configuracin del software SCMP Plan de gestin de la configuracin del software SCR Peticin de cambios del software SCSA Contabilidad del Estado de la Configuracin del Software SEI/CMMI Instituto de Ingenieros Software/ Modelo de la Capacidad de Madurez Integrado SQA Control de calidad del software SRS Especificacin de Requisitos Software USNRC Comisin Reguladora

INTRODUCCIN: Un sistema se puede definir como una coleccin de componentes que se organizan con el objetivo de proporcionar una funcin o conjunto de funciones determinadas (IEEE 610.12-90). La configuracin de un sistema son las caractersticas funcionales y/o fsicas del hardware, firmware, software o una combinacin de las mismas, segn lo dispuesto en la documentacin tcnica y el resultado obtenido en un producto. (Buc96) Tambin se puede considerar como una coleccin de versiones especficas de elementos de hardware, firmware o software que se combinan de acuerdo con un proceso de construccin especfico para un satisfacer un propsito particular. Por tanto la gestin de configuracin es la disciplina de identificar la configuracin de un sistema en momentos diferentes con el propsito de controlar de una manera sistemtica los cambios en la configuracin y mantener la integridad y el seguimiento de los cambios en la configuracin durante el ciclo de vida del sistema. (Ber97) Se define formalmente (IEEE610.12-90) como Una disciplina que establece direccin y seguimiento tcnicos y administrativos a: la identificacin y documentacin de las caractersticas funcionales y fsicas de un elemento de configuracin, toma notas y produce informes de cambios en el proceso y en el estado de implementacin y verifica el cumplimiento de los requerimientos especificados. La gestin de la configuracin del software (SCM) es un proceso que soporta el ciclo de vida del software (IEEE12207.0-96) que beneficia a la gestin de proyectos, las actividades de desarrollo y mantenimiento, las actividades de control y a los clientes y usuarios del producto final. El concepto de gestin de configuracin es aplicable a todos los elementos que se pueden controlar, aunque existen algunas diferencias de implementacin entre CM del hardware y CM del software.

63

La SCM est ntimamente relacionada con la actividad de control de calidad del software (SQA). Tal y como se define en la auditoria de configuracin (AC) de la Calidad del Software, los procesos de la SQA proporcionan la garanta de que los procesos y productos de software en el ciclo de vida del proyecto cumplen los requerimientos especificados gracias a la planificacin, la publicacin y ejecucin de un conjunto de actividades que proporcionan la confidencia necesaria de que se est teniendo en cuenta la calidad al construir el software. Las actividades de la SCM ayudan a conseguir estos objetivos de la SQA. En el contexto de algunos proyectos (vase, por ejemplo, IEEE730-02), requerimientos especficos de las SQA requieren ciertas actividades de la SCM. Las actividades de la SCM son: gestin y planificacin de los procesos de la SCM, identificacin de la configuracin del software, control de la configuracin del software, contabilizacin del estado de la configuracin del software, auditora de la configuracin del software y gestin del lanzamiento y entrega del software. Descomposicin de temas para la gestin de configuracin software

7.1 Gestin del proceso de la SCM

La SCM controla la evolucin e integridad de un producto identificando sus elementos, gestionando y controlando los cambios y verificando, guardando y produciendo reportes de la informacin de configuracin. Desde la perspectiva del ingeniero de software, la SCM facilita las actividades del desarrollo e implementacin de cambios. El xito de una implementacin de la SCM requiere una planificacin y gestin cuidadosas. Lo que al mismo tiempo requiere que se conozca el contexto de la organizacin y las restricciones impuestas en el diseo e implementacin del proceso de la SCM.

64

7.1.1 Contexto de Organizacin para la SCM

[Ber92:c4; Dar90:c2; IEEE828-98:c4s2.1] Para planificar un proceso de la SCM en un proyecto, se necesita comprender el contexto de organizacin y la relacin entre los distintos elementos de la organizacin. La SCM interactua con otras actividades o elementos de la organizacin. Los elementos de la organizacin responsables de los procesos de soporte de la ingeniera del software se pueden estructurar de diferentes formas. Aunque la responsabilidad de realizar algunas de las tareas de la SCM se podra asignar a otra de las partes de la organizacin como por ejemplo la organizacin de desarrollo, normalmente es un elemento definido de la organizacin o un individuo especialmente designado quien tiene la responsabilidad general de la SCM. El software se desarrolla frecuentemente como una parte de un sistema mayor que contiene elementos de hardware y firmware. En ese caso, las actividades de la SCM suceden en paralelo con las actividades de CM del hardware y firmware y debe ser consistente con la CM del sistema. Buckley [Buc96:c2] describe la SCM en este contexto. Tenga en cuenta que el firmware contiene hardware y software, as que son aplicables los conceptos de CM de ambos, hardware y software. La SCM puede interactuar con la actividad de aseguramiento de la calidad de la organizacin en lo que se refiere a temas como gestin de registros y de elementos no conformes. Respecto a gestin de registros, algunos elementos bajo el control de la SCM podran ser tambin registros del proyecto, dependiendo del programa de aseguramiento de calidad de la organizacin. Normalmente la gestin de elementos no conformes, es responsabilidad de la actividad de aseguramiento de la calidad; sin embargo, la SCM pude ayudar mediante el seguimiento e reporte de configuracin del software que corresponda a esta categora. Quizs su relacin ms cercana sea con las organizaciones de desarrollo y mantenimiento de software. Muchas de las tareas de control de configuracin del software se realizan en este contexto. Frecuentemente las mismas herramientas proporcionan soporte para los propsitos del desarrollo, mantenimiento y la SCM.

7.1.2 Restricciones y guias para el proceso de la SCM

[Ber92:c5; IEEE828-98:c4s1,c4s2.3; Moo98] Las restricciones y guas para el proceso de la SCM pueden venir de diferentes fuentes. Las normas y procedimientos definidos a nivel corporativo o de la organizacin pueden tener influencia o prescribir el diseo e implementacin de los procesos de la SCM en un determinado proyecto. Adems, el contrato entre el proveedor y el cliente podra contener estipulaciones que afecten los procesos de la SCM. Por ejemplo, podra ser necesaria una auditoria de configuracin o podra ser necesario poner ciertos elementos bajo el control de la CM. Entidades de regulacin externas podran imponer restricciones a productos de software que se vayan a desarrollar, cuando estos puedan afectar potencialmente a la seguridad pblica (vase, por ejemplo, USNRC1.169-97). Finalmente, el proceso del ciclo de vida del software elegido para un proyecto de software en particular y las herramientas elegidas para la implementacin de dicho software, afectan el diseo e implementacin de los procesos de la SCM. [Ber92] Las mejores prcticas, como se reflejan en los estndares de la ingeniera del software publicados por varias organizaciones de estndares, se pueden usar como guas para el diseo e implementacin de un proceso de la SCM. Moore [Moo98] proporciona una gua para dichas organizaciones y sus estndares. Las mejores prcticas se reflejan tambin en modelos de mejora del proceso de Gestin de Configuracin del Software y la valoracin de procesos como el Modelo de la Capacidad de Madurez Integrado del Instituto de la Ingeniera del Software (SEI/CMMI) (SEI01) y el estndar ISO/IEC15504 de la Valoracin del Proceso de la Ingeniera del Software (ISO/IEC15504-98).

7.1.3 Planificar la SCM

[Dar90:c2; IEEE12207.0-96 :c6.s2.1;Som01:c29] La planificacin de un proceso de la SCM para un proyecto dado debera ser consistente con el contexto de la organizacin, las restricciones que sean aplicables, las guas comnmente

65

aceptadas y la naturaleza del proyecto (por ejemplo, el tamao o lo crtico que sea). Las actividades ms importantes cubiertas son: Identificacin de la Configuracin del Software, Control de la Configuracin del Software, Reporte del Estado de la Configuracin del Software, Auditoria de la Configuracin del Software y la Gestin de Lanzamiento y Entrega de Software. Adems, se suelen considerar puntos como organizacin y responsabilidades, recursos y calendarios, seleccin de herramientas e implementacin, control de proveedores y subcontratos y control de la interfaz. Los resultados de las actividades de planificacin se registran en un Plan de SCM, que normalmente est sujeto a revisin y auditoria de la SQA.

7.1.3.1

Organizacin y responsabilidades de la SCM

[Ber92:c7; Buc96:c3; IEEE828-98:c4s2] Para prevenir confusin acerca de quin debe realizar determinadas tareas de la SCM, se deben identificar claramente las organizaciones involucradas en el proceso de la SCM. Las responsabilidades especficas para una actividad o tarea de la SCM tambin deben ser asignadas a organizaciones, bien por ttulo o por elemento de la organizacin. Se debe identificar tambin la autoridad general y los canales de comunicacin de la SCM, aunque se podra realizar como parte de la fase de planificacin del aseguramiento de la calidad o al nivel de la gestin de proyectos.

7.1.3.2

Recursos y planificacin de la SCM

[Ber92:c7; Buc96:c3; IEEE828-98:c4s4; c4s5] Planificar para la SCM ayuda identifica las necesidades de personal y herramientas que se requieren para realizar las tareas y actividades de la SCM. Aborda cuestiones de planificacin estableciendo las secuencias de tareas de la SCM necesarias e identifica sus relaciones con los planes de proyecto y los hitos establecidos en la fase de planificacin del proyecto. Tambin se especifican las necesidades de formacin requeridas para la implementacin de los planes y formacin de personal.

7.1.3.3

Seleccin e implementacin de herramientas

[Ber92:c15; Con98:c6; Pre01:c31] Las actividades de la SCM son soportadas por diferentes tipos de herramientas y procedimientos para su uso. Dependiendo de la situacin, se pueden combinar estas habilidades de herramientas con herramientas manuales, herramientas automticas que proporcionan una habilidad simple de la SCM, herramientas automticas que integran una coleccin de habilidades de la SCM (e incluso otras habilidades). O entornos de herramientas integrados que cubren las necesidades de mltiples participantes en el proceso de ingeniera del software (por ejemplo, SCM, desarrollo, V&V). El apoyo de herramientas automticas comienza a ser ms importante y difcil de establecer, segn los proyectos crecen en tamao y el entorno del proyecto se hace ms complejo. Las habilidades de estas herramientas proporcionan apoyo para: La biblioteca de la SCM Procedimientos de de peticin y aprobacin de cambios del software (SCR) Cdigo (y los productos relacionados) y las tareas de gestin de cambios Reportes del estado de configuracin del software y recoleccin de medidas de la SCM Auditora de la configuracin del software Gestin y seguimiento de la documentacin del software Construccin del software Gestin y seguimiento de los lanzamientos del software y su entrega Las herramientas utilizadas en estas reas, tambin pueden proporcionar medidas para mejorar el proceso. Royce [Roy98] describe siete medidas principales, tiles para gestionar procesos de la ingeniera del software. La informacin disponible de las varias herramientas de la SCM es afn al indicador de Trabajo y Progreso de Royce y a sus indicadores de calidad de

66

Cambio de Trfico y Estabilidad, Ruptura y Modularidad, Reprocesamiento de Trabajo y Adaptabilidad y TMEF (Tiempo medio entre fallos) y Madurez. Los informes para estos indicadores se pueden organizar de varias maneras, como por elemento de configuracin del software o por tipo de cambio requerido.

7.1.3.4

Control de Proveedores/Subcontratistas

[Ber92:c13; Buc96:c11; IEEE828-98:c4s3.6] Un proyecto de software podra hacer uso o adquirir productos software que se hayan comprado, como compiladores u otras herramientas. La planificacin de la SCM considera que elementos y como se pondrn estos elementos bajo control de configuracin (por ejemplo, integrados en bibliotecas de proyecto) y como se evaluarn y gestionarn los cambios y actualizaciones. Consideraciones similares son aplicables al software subcontratado. En este caso, tambin se deben establecer los requerimientos de la SCM a ser impuestos a los procesos de la SCM del subcontratista como parte del subcontrato y los medios para monitorizar que se cumple con ellos. El ltimo incluye consideraciones acerca de que informacin de la SCM ha de estar disponible para poder monitorizar, de una manera eficiente, que se cumplen los requerimientos.

7.1.3.5

Control de Interaccin

[IEEE828-98:c4s3.5] Cuando un elemento de software interacciona con otro elemento de software o hardware, un cambio a cualquiera de los dos elementos puede afectar al otro. La planificacin para los procesos de la SCM considera como se identificarn los elementos que interaccionan y como se gestionarn y comunicarn los cambios a dichos elementos. El papel de la SCM puede ser parte de un proceso ms general a nivel de sistema, para el control y especificacin de las interacciones y podra afectar a las especificaciones de las interacciones, los planes de control de las interacciones y los documentos de control de las interacciones. En este caso, la planificacin de la SCM para el control de las interacciones ocurre dentro del contexto del proceso a nivel de sistema. Se puede encontrar una discusin del rendimiento de las actividades del control de las interacciones en [Ber92:c12].

7.1.4 Plan de la SCM

[Ber92:c7; Buc96:c3; Pau93:L2-81] Los resultados de la planificacin de la SCM para un proyecto dado, se reflejan en un Plan de Gestin de la Configuracin del Software, que es un documento vivo que sirve como referencia para los procesos de la SCM. El documento se mantiene (o sea, se actualiza y aprueba) segn vaya siendo necesario durante el ciclo de vida del software. Al implementar un SCMP, normalmente es necesario desarrollar un conjunto de procedimientos subordinados ms detallados, que definirn la forma en que se realizan requerimientos especficos durante las actividades del da a da. Se pueden utilizar varias fuentes de informacin para encontrar guas, basado en la informacin producida durante la actividad de planificacin, acerca de la creacin y mantenimiento de un SCMP, como en [IEEE828-98:c4]. Esta referencia proporciona requerimientos para la informacin que un SCMP ha de contener. Tambin define y describe seis categoras de informacin de la GCS que se han de incluir en un SCMP: Introduccin (propsito, extensin, trminos usados) Gestin de la SCM (organizacin, responsabilidades, autoridades, normas aplicables, directivas y procedimientos) Actividades de la SCM (identificacin de la configuracin, control de la configuracin, etc.) Planificacin de la SCM (coordinacin con otras actividades del proyecto) Recursos de la SCM (herramientas, recursos fsicos y recursos humanos) Mantenimiento del SCMP

67

7.1.5 Seguimiento de la Gestin de la Configuracin del Software

[Pau93:L2-87] Despus de que el proceso de la SCM se ha implementado, puede ser necesario un cierto nivel de seguimiento para asegurarse de que las previsiones de la SCM se llevan a cabo adecuadamente. Probablemente habr requerimientos especficos de la SQA para asegurarse de que se cumplen los procesos y procedimientos especficos de la SCM. Esto podra requerir que una autoridad de la SCM se asegure de que aquellos que tengan responsabilidades asignadas realizan las tareas de la SCM definidas de una manera correcta. Este seguimiento podra ser realizado, como parte de una actividad de cumplimiento de auditoria, por la autoridad del aseguramiento de la calidad del software. El uso de herramientas integradas de la SCM con posibilidades de control de procesos puede hacer la tarea de seguimiento ms fcil. Algunas herramientas facilitan comprobar que el proceso se cumple al mismo tiempo que proporcionan al ingeniero de software la flexibilidad de adaptar procedimientos. Otras herramientas se aseguran de que el proceso se siga, dejando menos flexibilidad al ingeniero de software. Los requerimientos de seguimiento y los niveles de flexibilidad que se proporcionarn al ingeniero de software son criterios importantes durante la seleccin de herramientas.

7.1.5.1

Medidas y mediciones de la SCM

[Buc96:c3; Roy98] Se pueden asignar medidas de la SCM para proporcionar informacin especfica acerca de la evolucin del producto o una visin interna de cmo funcionan los procesos de la SCM. Un objetivo relacionado con el seguimiento de los procesos de la SCM es descubrir oportunidades para mejorar los procesos. Las mediciones de procesos de la SCM proporcionan un buen medio para monitorizar la efectividad de las actividades de la SCM de una manera continuada. Estas mediciones son tiles para caracterizar el estado actual del proceso y para proporcionar una base para hacer comparaciones en el tiempo. Los anlisis de las mediciones pueden proporcionar ideas que lleven a cambios en el proceso y a las correspondientes actualizaciones del SCMP. Las bibliotecas de software y las diferentes capacidades de las herramientas de la SCM proporcionan fuentes para extraer informacin acerca de las caractersticas de los procesos de la SCM (e informacin del proyecto y de gestin). Por ejemplo, sera til para evaluar los criterios usados para determinar qu niveles de autoridad son los ptimos para autorizar ciertos tipos de cambios, el tener informacin acerca del tiempo necesario para realizar distintos tipos de cambios. Se debe tener cuidado en asegurarse de mantener el objetivo del seguimiento en los hallazgos que pueden surgir de las mediciones y no en las mediciones en s mismas. El KA del Proceso de la Ingeniera del Software presenta una discusin acerca de medidas del producto y de los procesos. El programa de medidas del software se describe en el KA de la Gestin del Ingeniera del Software.

7.1.5.2
[Buc96:c15]

Auditoras durante el proceso de la SCM

Se pueden llevar a cabo auditorias durante el proceso de ingeniera del software para investigar el estado actual de elementos especficos de la configuracin o para evaluar la implementacin del proceso de la SCM. Las auditorias durante el proceso de la SCM proporcionan un mecanismo ms formal para monitorizar aspectos seleccionados del proceso y se podra coordinar con la funcin del SQA. Vase tambin el punto 5 Auditoria la Configuracin del Software.

7.2 Identificacin de la Configuracin del Software

[IEEE12207.0-96:c6s2.2]

68

La actividad de la identificacin de la configuracin del software identifica los elementos que deben ser controlados, establece esquemas de identificacin para los elementos y sus versiones, y establece las herramientas y las tcnicas que se utilizarn en la adquisicin y gestin de elementos sujetos a control. Estas actividades constituyen la base para las otras actividades de SCM.

7.2.1 Identificacin de los Elementos a Controlar

[Ber92:c8; IEEE828-98:c4s3.1; Pau93:L2-83; Som05:c29] Un primer paso para controlar cambios es identificar los elementos de software a ser controlados. Esto requiere comprender la configuracin del software en el contexto de la configuracin del sistema, la seleccin de elementos de configuracin de software, el desarrollo de estrategias para etiquetar elementos de software y describir las relaciones entre ellos y la identificacin de las lneas base que se usarn, adems de los procedimientos de adquisicin de elementos para una lnea base.

7.2.1.1

Configuracin del software

[Buc96:c4; c6, Pre04:c27] Una configuracin del software es el conjunto de caractersticas funcionales y fsicas del software tal y como se han definido en la documentacin tcnica o conseguido en un producto final (IEEE610.12-90). Se puede ver como parte de una configuracin del sistema ms general.

7.2.1.2

Elemento de configuracin del software

[Buc96:c4;c6; Con98:c2; Pre04:c27] Un elemento de configuracin de software (SCI) es una agregacin de software, asignado para tener gestin de configuracin y se trata como una sola entidad en el proceso de la SCM (IEEE610.12-90). La SCM controla un conjunto variado de elementos adems del cdigo. Los elementos de software con potencial posibilidad de llegar a ser elementos de configuracin incluyen: Planes, documentacin de especificaciones y diseo, material de pruebas, herramientas de software, cdigo fuente y ejecutable, libreras de cdigo, datos y diccionarios de datos, documentacin para la instalacin, para mantenimiento, para operacin y uso del software. La seleccin de SCIs es un proceso importante en el que se ha de conseguir un equilibrio entre proporcionar una visibilidad adecuada para el control del proyecto y proporcionar un nmero manejable de elementos a controlar. Se puede encontrar una lista con criterios para la seleccin de SCIs en [Ber92].

7.2.1.3

Relaciones entre elementos de la configuracin del software

[Con98:c2; Pre04:c27] La relacin estructural entre los SCIs seleccionados y sus partes constituyentes, afectan a otras actividades o tareas de la SCM tales como la construccin del software o el anlisis del impacto de los cambios propuestos. El seguimiento adecuado de estas relaciones es tambin importante como soporte a las operaciones de seguimiento. La necesidad de asignar los elementos identificados a la estructura del software y la necesidad de soportar la evolucin de los elementos de software y sus relaciones, se deberan considerar durante el diseo de los mtodos de identificacin para los SCIs.

7.2.1.4
[Bab86:c2]

Versiones del software

Los elementos de software evolucionan al mismo tiempo que el proyecto de software avanza. Una versin de un elemento de software es un elemento identificado y especificado particularmente. Se puede pensar en ella como el estado de un elemento que evoluciona. [Con98:c3-c5] Una revisin es una nueva versin de un elemento que reemplazar la versin

69

anterior. Una variante es una nueva versin de un elemento que se aadir a la configuracin sin reemplazar la versin anterior.

7.2.1.5

Lnea base

[Bab86:c5; Buc96:c4; Pre04:c27] La lnea base de un software es un conjunto de elementos de configuracin del software que se han designado formalmente y fijados en un momento determinado durante el ciclo de vida del software. El trmino se usa tambin para referirse a una versin en particular de un elemento de la configuracin del software acordada previamente. En cualquiera de los casos, la lnea base solo se puede cambiar por medio de procedimientos de control de cambios formales. Una lnea base junto con todos los cambios aprobados para la lnea base, representa la configuracin actual aprobada. Algunas lneas base comnmente utilizadas son la funcional, la asignada, la de desarrollo y la de productos (vase por ejemplo [Ber92]). La lnea base funcional se corresponde con los requerimientos del sistema ya verificados. La lnea base asignada se corresponde con las especificaciones de los requerimientos del sistema y las especificaciones de los requerimientos de las interfaces de software. La lnea base de desarrollo representa la configuracin evolutiva del software en momentos determinados durante el ciclo de vida del proyecto. La autoridad de cambios para dicha lnea base es normalmente la responsabilidad de la organizacin de desarrollo, pero se podra compartir con otras organizaciones (por ejemplo la de SCM o la de Pruebas). La lnea base del producto corresponde a el producto de software completo, entregado para la integracin de sistemas. Las lneas base a usar en un proyecto determinado, junto con los niveles de autoridad asociados necesarios para la aprobacin de cambios, se identifican normalmente en el SCMP.

7.2.1.6
[Buc96:c4]

Adquisicin de elementos de configuracin del software

Diferentes elementos de configuracin del software se ponen bajo el control de la SCM en momentos distintos; lo que significa que se aaden a una lnea base en particular en puntos especficos del ciclo de vida del software. El evento que da comienzo al proceso es la terminacin de alguna tarea formal de aceptacin tal como una revisin formal. La figura 2 caracteriza el crecimiento de elementos en una lnea base durante el ciclo de vida. Esta figura se basa en el modelo de cascada solamente por motivos ilustrativos; los subndices usados en la figura indican la versin de los elementos durante su evolucin. La solicitud de cambios del software (SCR) se describe en el punto 3.1 Solicitud, Evaluacin y Aprobacin de Cambios del Software.

70

Seguidamente de la adquisicin de un SCI, los cambios a dicho elemento se deben aprobar formalmente de la manera apropiada para el elemento y la lnea base involucrados, como se define en el SCMP. Despus de la aprobacin, el elemento se incorpora en la lnea base del software siguiendo el procedimiento apropiado.

7.2.2 Libreras de Software

[Bab86:c2; c5; Buc96:c4; IEEE828- 98:c4s3.1; Pau93:L2-82; Som01:c29] Una librera de software es una coleccin controlada de software y los documentos relacionados, y est diseada para ayudar en el desarrollo, uso y mantenimiento del software (IEEE610.12-90). Tambin tiene un papel durante las actividades de entrega y gestin de versiones del software. Se pueden usar varios tipos de libreras de software, cada una de la cuales corresponde a un nivel de madurez determinado del elemento de software. Por ejemplo, una librera de desarrollo podra dar soporte durante la codificacin y una librera de soporte de proyectos podra dar soporte a las pruebas, mientras que una librera maestra se podra utilizar en el producto final. Se ha de asociar el nivel apropiado de control de la SCM (la lnea base asociada y el nivel de autoridad para cambios) a cada librera. La seguridad, en trminos de control de acceso y medios de copia de seguridad, es un aspecto clave en la gestin de librera. Un modelo de una librera de software se puede encontrar en [Ber92:c14]. La herramienta/s que se usan en cada librera deben soportar los controles de la SCM que sean necesarios para dicha librera, en trminos de control de los SCIs y de acceso a la librera. En el nivel de la librera de desarrollo, esto significa la capacidad de gestin de cdigo que dar servicio a desarrolladores, ingenieros de mantenimiento y SCM. Est enfocada a gestionar las versiones de los elementos de software al mismo tiempo que da soporte a las actividades de mltiples desarrolladores. A mayores niveles de control, el acceso es ms restringido y la SCM es el usuario principal. Estas libreras son tambin una fuente importante de informacin para mediciones del trabajo realizado y del progreso.

7.3 Control de la Configuracin del Software

[IEEE12207.0-96:c6s2.3; Pau93:L2-84] Al control de la configuracin del software le concierne la gestin de cambios durante el ciclo de vida del software. Cubre los procesos que determinan los cambios que se realizarn, la autoridad requerida para aprobar ciertos cambios, el soporte para la implementacin de dichos cambios y el concepto de desviacin formal de los requerimientos del proyecto, adems de las cancelaciones de requerimientos. La derivada de estas actividades es til para medir el trfico de cambios y ruptura y aspectos por rehacer.

7.3.1 Peticin, Evaluacin y Aprobacin de Cambios del Software

[IEEE828-98:c4s3.2; Pre04:c27; Som05:c29] El primer paso para gestionar cambios en elementos controlados es determinar los cambios a realizar. El proceso de peticin de cambio del software (vase la siguiente Figura) proporciona procedimientos formales para recoger y registrar peticiones de cambios, evaluando el coste e impacto potencial de un cambio propuesto y aceptar, modificar o rechazar el cambio propuesto. Las peticiones de cambios de elementos de la configuracin del software los puede originar cualquiera durante cualquier momento del ciclo de vida del software y puede incluir una solucin propuesta y una prioridad. Una fuente de peticin de cambios es la iniciacin de correctivas en respuesta a los informes de problemas. El tipo de cambio (por ejemplo, un defecto o mejora) se registra normalmente en la SCR, sin importar la fuente. Esto proporciona la oportunidad de seguir defectos y recoger mediciones de la actividad de cambios por tipo de cambio. Una vez se ha recibido un SCR, se realiza una evaluacin tcnica (tambin conocida como anlisis del impacto) para determinar el tamao de las modificaciones necesarias en caso de que se aceptara la peticin de cambio. Para realizar esta tarea es importante un buen entendimiento de las relaciones entre elementos de software (y posiblemente hardware). Finalmente, la evaluacin de los aspectos tcnicos y de gestin de la peticin de cambios, ser realizada por una autoridad establecida, de acuerdo con la lnea base afectada, el SCI involucrado y la naturaleza del cambio y entonces se aceptar, modificar, rechazar o pospondr el cambio propuesto.

71

7.3.1.1

Consejo de Control de la Configuracin del Software

[Ber92:c9; Buc96:c9, c11; Pre04:c27] La autoridad para aceptar o rechazar los cambios propuestos, es normalmente la responsabilidad de una entidad conocida como Consejo de Control de la Configuracin (CCB). En proyectos pequeos, dicha autoridad normalmente reside en el Jefe de Proyecto o algn otro individuo elegido, en vez de en un consejo de varias personas. Puede haber mltiples niveles de autoridad de cambios, dependiendo de una variedad de criterios, como cuan crtico sea el elemento involucrado, la naturaleza del cambio (por ejemplo, el impacto en el presupuesto y planificacin), o el momento actual en el ciclo de vida. La composicin de CCBs que se utilice para un sistema determinado varia en relacin a estos criterios (siempre atendera un representante de la SCM). Cuando el alcance de la autoridad de un CCB es est limitado solamente al software, se le conoce como Consejo de Control de Configuracin del Software (CCBS). Las actividades del CCB estn sujetas normalmente a auditoras de la calidad de software o revisiones.

7.3.1.2

Proceso de peticin de cambios del software

[Buc96:c9, c11; Pre04:c27] Un proceso efectivo de peticin de cambio del software (SCR) requiere el uso de herramientas de soporte y procedimientos, desde formularios de papel y un procedimientos documentado hasta la herramienta electrnica para generar peticiones de cambio, imponiendo el flujo del proceso de cambios, capturando las decisiones del CCB y produciendo informacin del proceso de cambio. Un enlace entre las habilidades de esta herramienta y el sistema de informe de errores puede facilitar el seguimiento de soluciones para los informes de errores. Las descripciones del proceso de cambios y los formularios de soporte (informacin) aparecen en gran nmero de las referencias, por ejemplo [Ber92:c9].

7.3.2 Implementacin de Cambios en el Software

[Bab86:c6; Ber92:c9; Buc96:c9,c11; IEEE828- 98:c4s3.2.4; Pre04:c27; Som05:c29] Las PCBs aprobadas se implementan utilizando los procedimientos de software definidos, de acuerdo con los requerimientos de planificacin aplicables. Como se podra implementar simultneamente un nmero de PCBs, es necesario proporcionar los medios para seguir que PCBs se aaden a que versiones de software y lneas bases particulares. Como parte de la finalizacin del proceso de cambios, los cambios completados podran sufrir auditoras de configuracin y verificacin de la calidad del software. Esto incluye asegurarse de que solo se han realizado los cambios aprobados. El proceso de peticin de cambios mencionado anteriormente, aadir la informacin de la aprobacin para el cambio a la documentacin de la SCM (y otras). La implementacin real de un cambio est soportada por las habilidades de la herramienta de libreras, que proporciona gestin de versiones y soporte para el almacenamiento de cdigo. Estas herramientas proporcionan como mnimo habilidades para llevar a cabo el control de las versiones asociadas. Herramientas ms potentes pueden dar soporte al desarrollo en paralelo y entornos geogrficamente distribuidos. Estas herramientas

72

podran aparecer como aplicaciones especializadas separadas, bajo el control de un grupo independiente de la SCM. Tambin podran aparecer integradas como parte del entorno de la ingeniera del software. Finalmente, podran ser tan elementales como un sistema de control de cambios rudimentario proporcionado por el sistema operativo.

7.3.3 Desviaciones y Remisiones

[Ber92:c9; Buc96:c12] Las limitaciones impuestas al esfuerzo de la ingeniera del software o las especificaciones producidas durante las actividades de desarrollo podran contener necesidades que no pueden ser satisfechas en el punto designado del ciclo de vida. Una remisin es la autorizacin para abandonar una necesidad antes del desarrollo del elemento. Un rechazo es la autorizacin para utilizar un elemento, despus de su desarrollo, que se aleja de la necesidad de alguna manera. En estos casos se usa un procedimiento formal para ganar la aprobacin para la desviacin o remisin de las necesidades.

7.4 Reporte del Estado de la Configuracin del Software

[IEEE12207.0-96:c6s2.4; Pau93:L2-85; Pre04:c27; Som05:c29] La contabilidad del estado de la configuracin del software (SCSA) es la actividad de registrar y proporcionar la informacin necesaria para una gestin efectiva de la configuracin del software.

7.4.1 Informacin del Estado de la Configuracin del Software

[Buc96:c13; IEEE828-98:c4s3.3] La actividad de la SCSA disea y opera un sistema para la captura y generacin de los informes necesarios durante el ciclo de vida. Como en cualquier sistema de informacin, se debe identificar, recoger y mantener la informacin del estado de la configuracin que se ha de gestionar segn las configuraciones cmo evoluciona. Se necesitan varias mediciones e informacin para dar soporte al proceso de la SCM y para cubrir las necesidades de informes del estado de la configuracin de las actividades de gestin, ingeniera del software y otras actividades relacionadas. Los tipos de informacin disponible incluyen la identificacin de la configuracin aprobada y la identificacin y estado de implementacin actual de cambios, desviaciones y remisiones. Se puede encontrar una lista parcial con elementos de datos importantes en [Ber92:c10] Es necesario algn tipo de soporte de herramientas automticas para llevar a cabo las tareas de recogida de datos y generacin de informes de la SCSA. Podra ser una habilidad de la base de datos o una herramienta independiente o la habilidad del entorno de una herramienta integrada ms grande.

7.4.2 Informes del Estado de la Configuracin del Software

[Ber92:c10; Buc96:c13] Los informes generados pueden ser usados por varios elementos de la organizacin o del proyecto, incluyendo el equipo de desarrollo, el equipo de mantenimiento, la gestin del proyecto y las actividades de calidad de software. Los informes pueden tener la forma de respuestas inmediatas a preguntas especficas o ser informes prediseados producidos peridicamente. Alguna de la informacin producida por las actividades de contabilidad del estado durante el curso del ciclo de vida podra acabar siendo registros de la garanta de la calidad. Adems de informar del estado actual de la configuracin, la informacin obtenida por la SCSA puede usarse como base para varias mediciones tiles para la gestin, desarrollo y SCM. Un ejemplo podra ser el nmero de cambios pedidos por SCI y el tiempo medio necesario para implementar una peticin de cambio.

7.5 Auditoria de la Configuracin del Software

La auditoria de software es una actividad que se realiza para evaluar independientemente la conformidad de productos de software y procesos con las mediciones, estndares, guas,

73

planes y procedimientos (IEEE1028-97). Las auditorias se llevan a cabo de acuerdo con un proceso bien definido que consiste en varias responsabilidades y papeles de auditoria. En consecuencia, cada auditoria se debe planear con cuidado. Una auditoria requiere un nmero de personas que realizarn una variedad de tareas en un periodo de tiempo bastante reducido. Herramientas que den soporte a la planificacin y ejecucin de la auditoria pueden facilitar mucho el proceso. Se pueden encontrar consejos para realizar auditorias de software en varias referencias, como [Ber92:c11, Buc96:c15] y (IEEE1028-97). La actividad de auditoria de la configuracin del software determina el grado en que un elemento satisface las caractersticas funcionales y fsicas. Se pueden realizar auditorias informales de este tipo en momentos clave del ciclo de vida. Hay dos tipos de auditoras que podran ser requeridas por el contrato (por ejemplo, en contratos para software crtico): la Auditoria de la Configuracin Funcional (FCA) y la Auditora de la Configuracin Fsica (PCA). El completar con xito estas auditoras puede ser un prerrequisito para establecer la lnea base del producto. Buckley [Buc96:c15] contrasta los objetivos de las FCA y PCA en los contextos de software y hardware y recomienda que se evale cuidadosamente la necesidad de una FCA y PCA de software antes de realizarlas.

7.5.1 Auditoria de la Configuracin Funcional del Software

El propsito de la FCA del software es asegurarse de que el elemento de software que se audita tenga coherencia con la especificacin. Los resultados de la verificacin y validacin del software son actividades clave como entrada de datos para esta auditora.

7.5.2 Auditora de la Configuracin Fsica del Software

El propsito de la auditora de la configuracin fsica del software (PCA) es asegurarse de que el diseo y la documentacin de referencia tengan coherencia con el producto de software tal y como se ha construido.

7.5.3 Auditoras durante el proceso de una Lnea Base de Software

Tal y como se menciona anteriormente, las auditoras se pueden llevar a cabo durante el proceso de desarrollo para investigar el estado actual de un elemento de la configuracin especfico. En dicho caso, se podra aplicar una auditora a elementos seleccionados de la lnea base para asegurarse de que el rendimiento tenga coherencia con las especificaciones o para asegurarse de que la documentacin continua teniendo coherencia con el elemento de la lnea base que se est desarrollando.

7.6 Gestin del Lanzamiento y Distribucin del Software

El trmino lanzamiento se usa en este contexto para referirse a la distribucin de un elemento de la configuracin del software fuera de la actividad de desarrollo. Esto incluye tanto lanzamientos internos como la distribucin a clientes. Cuando una versin diferente de un elemento de software est disponible para ser entregada, como las versiones para diferentes plataformas o versiones con diferentes capacidades, es normalmente necesario preparar una versin especfica y empaquetar los materiales adecuados para distribuirla. La librera de software es un elemento clave para realizar las tareas de lanzamiento y distribucin.

7.6.1 Construccin del Software

La construccin del software es la actividad de combinar la versin correcta de los elementos de configuracin del software, usando la configuracin de datos apropiada, en un programa ejecutable para su distribucin a los clientes u otros receptores, como la actividad de pruebas. Las instrucciones de construccin se aseguran de que se toman los pasos de construccin adecuados y en la secuencia correcta. Adems de construir software para un nuevo lanzamiento, la SCM normalmente necesita ser capaz de reproducir lanzamientos previos para recuperacin, pruebas, mantenimiento u otros propsitos de lanzamiento adicionales. El software se construye usando versiones particulares de las herramientas de soporte, como

74

compiladores. Podra ser necesario reconstruir una copia exacta de un elemento de configuracin que se haya construido previamente. En ese caso, las herramientas de soporte y las instrucciones de construccin asociadas deben de estar bajo el control de la SCM para asegurarse de la disponibilidad de la las versiones correctas de las herramientas. Las habilidades de una herramienta son tiles para seleccionar la versin correcta de elementos de software para un entorno destino determinado y para el proceso de construir el software automticamente con las versiones seleccionadas y los datos de configuracin apropiados. En proyectos grandes con desarrollo en paralelo o en entornos de desarrollo distribuido, estas habilidades de las herramientas son necesarias. La mayora de los entornos de ingeniera del software proporcionan esta habilidad. Estas herramientas varan en complejidad, desde las que requieren que el ingeniero de software aprenda un lenguaje de guiones especfico a soluciones grficas que ocultan la mayor parte de la complejidad en una solucin de construccin inteligente. El proceso y los productos de la construccin estn sujetos, normalmente, a verificacin de la calidad del software. Los resultados de un proceso de construccin se podran necesitar para futuras referencias y podran convertirse en registros de la garanta del software.

7.6.2 Gestin del Lanzamiento del Software

La gestin de lanzamiento del software conlleva la identificacin, empaquetamiento y distribucin de los elementos de un producto, por ejemplo, programas ejecutables, documentacin, notas de lanzamiento y datos de configuracin. Dado que los cambios pueden ocurrir constantemente, una de las preocupaciones en la gestin del lanzamientos es determinar cuando realizar un lanzamiento. La severidad de los problemas solucionados por el lanzamiento afecta a esta decisin. La tarea de empaquetamiento debe identificar que elementos del producto se deben distribuir y por tanto seleccionar las variantes correctas de dichos elementos, dada la aplicacin que se le quiere dar al producto. La informacin que documenta el contenido fsico del lanzamiento se conoce como documento de descripcin de la versin. Las notas del lanzamiento normalmente describen nuevas habilidades, problemas conocidos y requisitos necesarios de la plataforma para la operacin adecuada del producto. El paquete que se distribuir tambin contiene instrucciones de instalacin o actualizacin. El ltimo se puede complicar porque algunos usuarios podran tener productos que son antiguos por varias versiones. Finalmente, en algunos casos, se podran requerir la actividad de gestin de lanzamientos para el seguimiento de la distribucin del producto a varios clientes o sistemas objetivo. Un ejemplo sera el caso en el que se requiriese que un proveedor tiene que notificar a un cliente de nuevos problemas. Las habilidades de una herramienta son necesarias para dar soporte a estas funciones de gestin de los lanzamientos. Es til tener una conexin con las habilidades de la herramienta para dar soporte a los procesos de peticiones de cambios, de tal forma que se puedan relacionar los contenidos de un lanzamiento con los SCR que se han recibido. Esta habilidad de las herramientas tambin podra mantener informacin en varias plataformas destino y de varios entornos de clientes.

75

8 Gestin de ingeniera del software

ACRONIMOS: SQA Aseguramiento de la Calidad de PMBOOK Cuerpo de Conocimiento de la Gua de Gestin de proyectos Software. INTRODUCCION La Gestin de Ingeniera de Software puede ser definida como la aplicacin para la gestin de actividades planeacin, coordinacin, mediciones, monitoreo, control e informes que aseguren el desarrollo y mantenimiento del software de forma sistemtica, disciplinado y cuantificada. (IEEE610.12-09). Las reas del conocimiento (KA) de la Gestin de la Ingeniera del Software, por tanto, se encargan de la gestin y medicin de la Ingeniera del Software. Aunque la medicin es un aspecto importante de todas las KAs, es hasta ahora que el tpico de medir software est presente. Aunque sea verdad decir que en cierta forma, debera ser posible la gestin de la ingeniera del software de la misma manera que algunos otros procesos (complejos), existen aspectos especficos a los productos software y a los procesos del ciclo de vida del software los cuales de forma efectiva complican la gestin algunos de los cuales se muestran a continuacin: La percepcin de los clientes es tal que hay con frecuencia una falta de apreciacin de la complejidad inherente en la Ingeniera de Software, particularmente en relacin a el impacto de cambiar los requerimientos del software. Es casi inevitable que los procesos de la Ingeniera de Software generen la necesidad para nuevos y cambiados requerimientos del cliente. Como un resultado, el software es con frecuencia construido por un proceso iterativo y no por una secuencia de tares cerradas. La Ingeniera de Software incorpora necesariamente aspectos de creatividad y disciplina tratar de mantener un balance apropiado entre ellos es frecuentemente difcil. Los grados de novedad y complejidad del software son con frecuencia extremadamente altos. Hay una rpida tasa de cambio en las tecnologas subyacentes. Con respecto a la Ingeniera de Software, las actividades de gestin ocurren a tres niveles: gestin organizacional y de infraestructura, la gestin de proyectos y la medicin de programas de planeacin y control. Los dos ltimos son detallados en la descripcin del KA. Sin embargo, esto no est disminuyendo la importancia de los temas de la gestin organizacional. Ya que las conexiones a las disciplinas relacionadas obviamente las de gestin son importantes, estas sern descritas con ms detalle que en las otras descripciones de las KA. Aspectos de la gestin de la organizacin son importantes en trminos de su impacto en gestin de software en la gestin de polticas, por ejemplo: polticas organizacionales y estndares que provean el marco en el cual la ingeniera de software est comprometido. Estas polticas pueden necesitar ser influenciadas por los requerimientos del efectivo desarrollo y mantenimiento de software, y un nmero de polticas especficas de ingeniera de software pueden necesitar ser establecidas para la efectiva gestin de la ingeniera de software en un nivel organizacional. Por ejemplo: las polticas son necesarias usualmente de establecer a procesos especficos a nivel organizacional o procedimientos para los cuales las tareas de la ingeniera de software como diseo, implementacin, estimacin, seguimiento e informes. Estas polticas son esenciales, por ejemplo, para una efectiva gestin de la ingeniera de software a largo tiempo, para establecer unas bases consistentes con las cuales se analicen su desempeo anterior y se implementen mejoras. Otro aspecto importante de la gestin es la gestin de personal: procedimientos y polticas para la contratacin, capacitacin y motivacin del personal y ser mentor de una carrera de

76

desarrollo son importantes no solo a nivel del proyecto sino tambin para el xito a largo plazo de una organizacin. El personal de ingeniera de software puede presentar una nica formacin o retos en la gestin de personal (por ejemplo, la gestin econmica en un contexto donde la tecnologa emergente sufre cambios rpidos y continuos). La gestin de la comunicacin es tambin a menudo mencionada como un aspecto pasado por alto pero importante en la actuacin de los individuos en un campo donde se precise el entendimiento de las necesidades de los usuarios y de los complejos requerimientos y diseos que sean necesarios. Finalmente, es necesaria la gestin del portafolio, la cual est en la capacidad de tener una visin general no solo del conjunto de software bajo desarrollo sino tambin del software ya en uso en una organizacin. Adems, la reutilizacin de software es un factor clave en el mantenimiento y mejoras en la productividad y competitividad. La reutilizacin efectiva requiere una visin estratgica que refleje el poder nico y los requerimientos de esta tcnica. En adicin para entender los aspectos de la gestin que son nicamente influenciados por el software, los ingenieros de software deben tener algunos conocimientos de los aspectos generales, adquiridos en los primeros cuatro aos antes de graduarse que son mencionados en la gua. La cultura y comportamiento organizacional, y la gestin empresarial funcional en trminos de consecucin, la gestin de suministros en cadena, el mercadeo, las ventas y la distribucin, todos tienen una influencia, aunque indirectamente, en los procesos de ingeniera de software en las organizaciones. Relevantes a estas KA son las nociones de gestin de proyectos, como la construccin de productos de software tiles es gestionado normalmente en la forma de (tal vez programas de) proyectos individuales. A este respecto, nosotros encontramos amplios soportes en la Gua de la Gestin de Proyectos del Cuerpo de Conocimiento (PMBOOK)(PMI00), en el cual se incluyen las siguientes KAs de la gestin de proyectos: gestin de la integracin de proyectos, gestin del mbito del proyecto, gestin del tiempo del proyecto, gestin de los costos del proyecto, gestin de la calidad del proyecto, gestin de los recursos humanos del proyecto, gestin de las comunicaciones del proyecto. Claramente, todos estos tpicos tienen relevancia directa con la KA de la gestin de la ingeniera de software. Un intento de duplicar el contenido de la Gua del PMBOOK sera casi imposible e inapropiado. En su lugar, sugerimos que el lector interesado en la gestin de proyectos adems consulte lo que es especfico al proyecto de la ingeniera de software del PMBOOK el mismo. La Gestin de proyectos es tambin encontrada en los captulos de las Disciplinas Relacionadas con la Ingeniera de Software. Las KA de la Gestin de la Ingeniera de Software consisten de ambos, los procesos de la gestin de proyectos de software, en estas primeras cinco subreas, y la medicin de la ingeniera de software en las siguientes subreas. Aunque estos dos temas pueden aparecer por separado, y en realidad poseen muchos aspectos nicos, su gran relacin los ha llevado a ser tratados en conjunto en las KA. Desafortunadamente, se asume comnmente en la industria del software que los productos se entregan tarde, por encima de lo presupuestado, y de baja calidad e incierta funcionalidad. En la gestin de informes de medicin - un principio asumido por algunas disciplinas de ingeniera como verdad puede ayudar a cambiar esta percepcin. En esencia, una gestin sin medicin, cualitativa y cuantitativa, sugiera una falta clara de rigor, y medicin sin gestin sugiere una falta de propsitos o contexto. De igual manera, sin embargo, gestin y medicin sin conocimientos es igualmente ineficaz, por eso debemos ser cuidadosos en enfatizar excesivamente en los aspectos cuantitativos de la Gestin de la Ingeniera de Software (SEM). Efectivamente la gestin requiere de ambos y de la experiencia. Las siguientes definiciones de trabajo se adoptan aqu: La Gestin de Procesos, se refiere a las actividades que son tomadas en orden para asegurar que los procesos de ingeniera de software sean realizados de manera consistente con las polticas, objetivos y estndares de la organizacin. La Medicin se refiere a la asignacin de valores y etiquetas a los aspectos de la ingeniera de software (productos, procesos y recursos como fue definido por[Fen98]) y los modelos que son derivados de estos, sean estos modelos desarrollados usando estadsticas, conocimientos expertos u otras tcnicas.

77

Las subreas de la gestin de proyectos de ingeniera de software hacen extensivo el uso de la subrea de medicin de la ingeniera de software. No es de extraar, que estas KA estn estrechamente relacionadas con otras en la gua de el SWEBOK, y leer las siguientes descripciones de las KA en conjunto con ellas seria particularmente til. Requerimientos del Software, son descritas algunas de las actividades a ser desarrolladas durante la fase de iniciacin y definicin de alcances del proyecto. Gestin de configuracin de software, trata sobre la identificacin, control, estado de cuentas, y la auditoria de la configuracin de software junto con el software relacionado con la gestin y los entregables. Procesos de Ingeniera de Software, porque los procesos y proyectos estn estrechamente relacionados (estas KA solo describen procesos y productos medibles). Calidad de Software, como la calidad es constantemente un objetivo de la gestin y es un propsito de muchas actividades que deben ser gestionadas. Descomposicin de los tpicos de la Gestin de la Ingeniera de Software Como las KA de la gestin de la ingeniera de software estn expuestas aqu como unos procesos organizacionales los cuales incorporan las nociones de gestin de procesos y proyectos, debemos crear una descomposicin que est basada en ambos tpicos y en el ciclo de vida del software. Sin embargo la base primaria para un nivel alto de descomposicin esta en los procesos de gestin en un proyecto de ingeniera de software. Existen seis subreas principales. Las primeras cinco subreas en siguen gran parte los procesos de gestin de la IEEE/EIA 12207. Las seis subreas son: Iniciacin y definicin de alcance, la cual se ocupa de las decisiones de iniciar un proyecto de ingeniera de software. Planeacin de proyectos de software, la cual dirige las actividades emprendidas a preparase para una ingeniera de software exitosa de una perspectiva de gestin. Promulgacin del proyecto de software, la cual se ocupa de las actividades de la gestin de la ingeniera de software generalmente aceptadas que ocurren durante la ingeniera de software. Revisin y evaluacin, la cual se ocupa de garantizar que el software es satisfactorio. Cierre, el cual dirige las actividades complementarias de un proyecto de ingeniera de software. Medicin de Ingeniera de Software, la cual se ocupa de el desarrollo e implementacin efectiva de programas de medicin en las organizaciones de ingeniera de software (IEEE 12207.0-96). La descomposicin de los tpicos para las KA de la ingeniera de software se muestra en la figura 1.

78

Gestin de la Ingeniera de software

Iniciacin y definicin de alcances

Determinacin y Determinacin anlisis de de y anlisis requerimientos requerimientos Anlisis de factibilidad Procesos para anlisis y revisin de requerimientos

Planeacin Proyectos de software

Ejecucin Proyectos de software

Revisin y evaluacin

Cierre

Proceso de planeacin Proceso de entregables Esfuerzo, cronograma y costos de estimacin Asignar recursos

Implementaci n de planes Gestionar los contratos de distribucin Implementar procesos de medicin Procesos de monitoreo Procesos de control

Determinar la satisfaccin de s requerimientos Revisin y evaluacin del rendimiento

Medicin ingeniera de software Proyectos de software

Determinacin del cierre

Establecer y apoyar compromisos evaluacin Plan de procesos de medicin Realizar los procesos de medicin Evaluar la medicin

Actividades del cierre

Gestin del riesgo Gestin de la calidad Gestin de la planeacin

Reportes

Descomposicin de los tpicos de las KA de la Gestin de la Ingeniera de Software

8.1 Iniciacin y Definicin del Alcance

El foco de este juego de actividades est en la efectiva determinacin de los requerimientos del software por varios mtodos de obtencin y en la valoracin de la viabilidad de los proyectos desde una variedad de puntos de vista. Una vez establecida la viabilidad, la tarea pendiente dentro de este proceso es la especificacin de la validacin y procedimientos de cambios de los requerimientos (ver tambin las KA de los requerimientos del software)

8.1.1 Determinacin y negociacin de requerimientos

[Dor02:v2ca; Pfl01:c4; Pre04:c7; Som05:c5] Los mtodos de requerimientos de software para la obtencin de requerimientos (por ejemplo: la observacin), anlisis (por ejemplo, modelamiento de datos, modelamiento de casos de uso), especificacin y evaluacin (por ejemplo, prototipos) tienen que ser seleccionados y aplicados, tomando en cuenta las diferentes perspectivas del contratista. Esto nos lleva a la determinacin de los alcances, objetivos y las restricciones del proyecto. Esta es siempre una actividad importante, ya que fija los limites visibles para el conjunto de tareas emprendidas, y es particularmente donde la novedad de lo emprendido es alta. Informacin adicional puede ser encontrada en las KA de los requerimientos del software.

8.1.2 Anlisis de factibilidad (Tcnica, Operacional, financiera y socio poltica)

[Pre04:c6; Som05:c6] Los Ingenieros de software deben asegurarse que las capacidades adecuadas y los recursos estn disponibles en la forma de personas, experticia, facilidades, infraestructura y soporte

79

(sean internos o externos) para asegurar que el proyecto puede ser completado a satisfaccin en una manera oportuna y rentable (usando, por ejemplo, una matriz de requerimientos y capacidades). Esto a menudo requiere de alguna estimacin ballpark (en el contexto) del esfuerzo y el costo basados en mtodos apropiados (por ejemplo, tcnicas anlogas de informes expertos).

8.1.3 Procesos para el anlisis y revisin de requerimientos

Dado lo inevitable de los cambios, es imprescindible que el contrato entre los contratistas tenga incorporado en principio puntos acerca de las formas en las que se sern analizadas y revisados los alcances y requerimientos (por ejemplo, con procedimientos de gestin de cambios a acuerdos). Esto claramente implica que los alcances y requerimientos no sern grabados en piedra sino que podrn y sern revisados en puntos determinados del desarrollo de un proceso (por ejemplo, en el anlisis del diseo, en el anlisis de gestin). Si los cambios son aceptados, entonces algunas formas de anlisis de rastreo y anlisis de riesgo (ver tpico 2.5 de Gestin del Riesgo) sern usados para determinar el impacto de estos cambios. Un acercamiento a los cambios de gestin tambin resultara til cuan llegue el tiempo de analizar los resultados del proyecto, ya que los alcances y requerimientos formaran las bases para evaluar el xito. [Som05: c6] ver tambin la subrea de control de configuracin del software de las KA de Gestin de Configuracin de Software.

8.2 Planeacin de Proyectos de Software

El proceso de planeacin interactiva est regulado por los alcances y requerimientos y por el establecimiento de factibilidades. En este punto, los proceso del ciclo de vida del software son evaluados y los ms apropiados (considerando la naturaleza del proyecto, su grado de novedad, su funcionalidad y complejidad tcnica, su calidad de requerimientos, etc.) son seleccionados. Si es relevante, el mismo proyecto estar planeado en forma de una descomposicin jerrquica de tareas, los entregables asociados a cada tarea sern especificados y caracterizados en trminos de calidad y otros atributos de acuerdo con los requerimientos establecidos, los esfuerzos detallados, el calendario y la estimacin de costos sern emprendidos. Los recursos sern asignados a las tareas para optimizar la productividad del personal (en los niveles individual, grupal y organizacional), utilizacin de materiales y equipos, cumplimiento del calendario. La gestin detallada de riegos es emprendida y el perfil del riesgo del proyecto es discutido entre, y aceptado, por todos los contratistas relevantes. Los procesos de gestin de la calidad del software comprensivo son determinados como una parte de los procesos de planeacin en la forma de procedimientos y responsabilidades para asegurar la calidad, verificacin y validacin, anlisis y auditoria del software (ver las KA de la calidad del software). Como un proceso interactivo, es de vital importancia que los procesos y responsabilidades para el plan de gestin continuo, anlisis y revisin sean claramente establecidos y acordados.

8.2.1 Planeacin del proceso

Seleccin del modelo del ciclo d vida del software apropiado (por ejemplo, espiral, prototipo evolucionado) y la adaptacin y despliegue apropiado de procesos del ciclo de vida del software son emprendidos a la luz de alcances y requerimientos particulares de el proyecto. Mtodos y herramientas relevantes son tambin seleccionadas. [Dor02: v1c6,v2c8; Pfl01: c2; Pre04:c2; Rei02: c1,c3,c5; Som05: c3; Tha97: c3] A nivel del proyecto, los mtodos y herramientas apropiados son usados para descomponer el proyecto en tareas, con entradas asociadas, salidas y condiciones complementarias (por ejemplo, estructura para la descomposicin del trabajo). [Dor02: v2c7: Pfl01: c3; Pre04: c21; Rei02: c4,c5; Som05: c4; Tha97: c4,c6] Esto influye a su vez en las decisiones sobre el calendario y estructura de la organizacin.

8.2.2 Determinar los entregables.

El producto(s) de cada tarea (por ejemplo, diseo de arquitectura, reportes de inspeccin) son especificados y caracterizados. [Pfl01: c3; Pre04: c24; Tha97: c4] son evaluadas las oportunidades de reutilizar componentes de software de desarrollos anteriores o de utilizar

80

productos de software del mercado. El uso de la tercera parte y el software obtenido son planeados y suministrados para ser seleccionados.

8.2.3 Estimacin de Esfuerzo, calendario y costo

Basado en la descomposicin de tareas, entradas y salidas, el esperado rango de esfuerzo requerido para cada tarea es determinado usando un modelo de estimacin calibrado basado en un historia de datos del tamao del esfuerzo empleado y relevante, u otros mtodos como el juicio de expertos. Las dependencias de las tareas son establecidas y los cuellos de botella son identificados usando los mtodos convenientes (por ejemplo, el anlisis de la ruta crtica). Los cuellos de botella son resueltos donde sea posible, y el esperado cuadro de tareas es producido con proyeccin de tiempos de inicio, duracin y tiempos de finalizacin (por ejemplo, Diagrama de PERT). Los requerimientos de recursos (personas, herramientas) son traducidos en estimaciones de costo. [Dor02: v2c7; Fen98: c12; Pfl01: c3; Pre04: c23,c24; Rei02: c5,c6; Som05: c4,c23; Tha97: c5] Esta es una gran actividad interactiva la cual puede ser negociada y revisada hasta que se alcance un consenso entre los contratistas afectados (principalmente ingenieros y administradores).

8.2.4 Asignacin de recursos

El equipo, las facilidades y las personas son asociados con las tareas programadas, incluyendo la asignacin de responsabilidades por completo (usando, por ejemplo, un Diagrama de Gantt). Estas actividades estn reguladas y limitadas por las capacidades de los recursos y su ptimo use bajo estas circunstancias, as como por temas relacionados con el personal (por ejemplo, productividad de individuos o equipos, dinmica de los equipos, la organizacin y estructura de los equipos).

8.2.5 Gestin de riesgos

La identificacin y anlisis de riesgos (que puede ser inconveniente, cmo y por qu, y cules son sus posibles consecuencias), valoracin de riesgos crticos (los cuales son los y riesgos ms significativos en trminos de exposicin, los cuales podemos hacer algo en trminos de incidencia), la disminucin del riesgo y los planes de contingencia (formulacin de estrategias para el control del riesgo y la gestin de los perfiles del riesgo) son todos gestionados. Los mtodos de valoracin de riesgos (por ejemplo, los arboles de decisin y la simulacin de procesos) pueden utilizarse en razn de resaltar y evaluar los riesgos. Las polticas de abandono de proyectos deben ser determinadas en este punto de discusin con todos los otros contratistas. [Dor02: el v2c7; Pfl01: el c3; Pre04: el c25; Rei02: el c11; Som05: el c4; Tha97: el c4] La gestin de riesgos del proyecto debe influir en aspectos de riesgo nicos en el software, como la tendencia de los ingenieros del software a agregar utilidades no deseadas o como el controlador de riesgos presente en la naturaleza intangible del software.

8.2.6 Gestin de Calidad

[Dor02: v1c8,v2c3-c5; Pre04: c26; Rei02: c10; Som05: c24,c25; Tha97: c9,c10] La calidad se define en trminos de atributos pertinentes al proyecto especfico y en los de cualquier producto o productos asociados a ella, probablemente tanto en trminos cuantitativos como cualitativos. Estas caractersticas de la calidad habrn sido determinadas en la especificacin de requerimientos detallados del software. Ver tambin el KA de los Requerimientos del Software. Los lmites de unin a la calidad para cada indicador se colocan de acuerdo a las expectativas que tenga el contratista sobre el software en cuestin. Los procedimientos que hacen referencia a lo largo del proceso a la SQA en curso a lo largo del proceso y a la verificacin y validacin del producto (entregable) tambin se especifican en esta fase (por ejemplo, las revisiones tcnicas e inspecciones) (ver tambin el KA de la Calidad del Software).

8.2.7 Gestin de Planes

[Som05: c4; Tha97: c4]

81

Tambin se ha de planificar cmo se gestionar el proyecto y cmo se gestionar la planificacin. Los informes, la supervisin y el control del proyecto deben encajar en el proyecto de ingeniera del software seleccionado y en las realidades del proyecto, y deben reflejarse en los varios artefactos que se usarn para gestionarlo. Pero, en un contexto en donde los cambios son ms una expectativa que un susto, es de vital importancia que se gestionen los propios planes. Esto requiere que sistemticamente se dirija, supervise, repase, informe y, donde as lo requiera, revise, la unin a los planes. Los planes asociados a otros procesos de soporte orientados a gestin (por ejemplo, documentacin, gestin de la configuracin del software, y resolucin de problemas) tambin necesitan gestionarse de esa misma manera.

8.3 Ejecucin del Proyecto de Software

A continuacin se ejecutan los planes y se promulgan los procesos incluidos en los planes. A lo largo de este proceso todo se centra en la unin a los planes, con una expectativa arrolladora de que tal unin llevar a la satisfaccin plena de los requerimientos del contratista y al logro de los objetivos del proyecto. Las actividades actuales de gestin para medir, supervisar, controlar e informar son fundamentales para la promulgacin.

8.3.1 Implementacin de Planes

[Pf101: c3; Som05: c4] Inicia el proyecto y se emprenden las actividades del proyecto segn el horario. En el proceso, se utilizan recursos (por ejemplo, esfuerzo del personal, financiacin) y se producen entregables (por ejemplo, documentos de diseo de arquitectura, casos de pruebas).

8.3.2 Gestin de Contratos con Proveedores

[Som05: c4] Preparar y ejecutar acuerdos con los proveedores, supervisar la actuacin del proveedor, y aceptar sus productos, incorporndolos cuando sean adecuados.

8.3.3 Implementacin de Procesos de medicin

[Fen98: c13,c14; Pre04: c22; Rei02: c10,c12; Tha97: c3,c10] Se promulga el proceso de medicin junto con el proyecto del software, asegurndose de que se recogen datos relevantes y tiles (ver tambin los apartados 6.2 Planificar el Proceso de Medicin y 6.3 Realizar el Proceso de Medicin).

8.3.4 Proceso de Supervisin

[Dor02: v1c8, v2c2-c5,c7; Rei02: c10; Som05: c25; Tha97: c3;c9] Se evala continuamente y a intervalos predeterminados la unin a los diferentes planes. Se analizan los resultados y las condiciones de acabado de cada tarea. Se evalan los entregables en trminos de las caractersticas que ellos requieren (por ejemplo, por medio de revisiones y auditoras). Se investiga el consumo de fuerzas, la unin a horarios, y los costes a da de hoy, y se examina el uso de recursos. Se revisa de nuevo el perfil de riesgo del proyecto y se evala la unin a los requerimientos de calidad. Se modelan y analizan los datos de medicin. Se emprende el anlisis de variacin basado en la desviacin actual de los resultados y valores esperados. Esto puede darse en forma de desbordamiento de costes, equivocaciones en el horario y similares. Se lleva a cabo la identificacin de la desviacin y el anlisis de calidad y otros datos de medicin (por ejemplo, el anlisis de la densidad de los defectos). Se recalculan la exposicin a riesgos y sus influencias y se ejecutan de nuevo los rboles de decisiones, las simulaciones, etc, a la luz de los nuevos datos. Estas actividades permiten la deteccin de problemas y la identificacin de excepciones basada en la superacin de los lmites existentes. Se informa de los resultados segn se vaya necesitando y sobre todo cuando se hayan superado los lmites aceptables.

82

8.3.5 Proceso de Control

[Dor02: v2c7; Rei02: c10; Tha97: c3,c9] Los resultados de las actividades de supervisin del proceso proporcionan la base sobre la que se toman las decisiones para actuar. Se pueden hacer cambios al proyecto cuando se juzgue oportuno y cuando se modele y gestione el impacto y los riesgos asociados a stos. Esto puede tomar la forma de una accin correctiva (por ejemplo, volviendo a probar ciertos componentes), puede que involucre la incorporacin de contingencias para evitar sucesos semejantes (por ejemplo, la decisin de utilizar prototipos para ayudar en la validacin de los requerimientos del software), y/o puede implicar la revisin de los distintos planes y de otros documentos del proyecto (por ejemplo, la especificacin de requerimientos) para corregir los resultados inesperados y sus implicaciones. En algunos casos, puede llevar al abandono del proyecto. En todos los casos, se adhiere al control de cambios y a los procedimientos de gestin de configuracin del software (ver tambin el KA de la Gestin de Configuracin del Software) se documentan y comunican decisiones a todos los implicados importantes, se repasan los planes y si es necesario se revisan, y todos los datos importantes se graban en la base de datos central (ver tambin el apartado 6.3 Llevar a cabo el Proceso de Revisin).

8.3.6 Informes
[Rei02: c10; Tha97: c3,c10] En perodos especficos y concertados, se informa de la unin a los planes dentro de la organizacin (por ejemplo al comit de direccin de cartera del proyecto) y a los contratistas externos (por ejemplo, clientes, usuarios). Informes de esta naturaleza deben orientarse hacia una unin global en oposicin a los informes detallados que se requieren frecuentemente dentro del equipo de proyecto.

8.4 Revisin y Evaluacin

En puntos crticos del proyecto, se evalan el progreso global hacia el logro de los objetivos prefijados y la satisfaccin d 1 e los requerimientos del contratista. De igual modo, en hitos particulares se llevan a cabo valoraciones sobre la efectividad del proceso global hasta la fecha, del personal involucrado, y de las herramientas y mtodos utilizados.

8.4.1 Determinar la Satisfaccin de los Requerimientos

[Rei02: c10; Tha97: c3,c10] Ya que uno de nuestros objetivos principales consiste en lograr la satisfaccin del contratista (usuario o cliente), es importante que el progreso hacia este objetivo sea evaluado formal y peridicamente. Esto ocurre al lograr los principales hitos del proyecto (por ejemplo, la confirmacin de la arquitectura del diseo de software, la revisin tcnica de la integracin del software). Se identifican variaciones a las expectativas y se llevan a cabo acciones adecuadas. Al igual que en la actividad de control del proceso arriba indicada (ver el apartado 3.5 Proceso de Control), en todos los casos, se adhiere al control de cambios y a los procedimientos de gestin de configuracin del software (ver tambin el KA de la Gestin de Configuracin del Software) se documentan y comunican decisiones a todos los implicados importantes, se repasan los planes y si es necesario se revisan, y todos los datos importantes se graban en la base de datos central (ver tambin el apartado 6.3 Llevar a cabo el Proceso de Revisin).Se puede encontrar ms informacin en el KA de las Pruebas del Software, en el apartado 2.2 Objetivos de las Pruebas y en el KA de la Calidad del Software, en el apartado 2.3 Revisiones y Auditoras.

8.4.2 Revisar y Evaluar la Ejecucin

[Dor02: v1c8,v2c3,c5; Pfl01: c8,c9; Rei02: c10; Tha97: c3,c10] Las revisiones peridicas de lo realizado, dirigidas al personal del proyecto, proporcionan detalles sobre la probabilidad de ser fiel a los planes as como sobre las posibles reas de

83

dificultad (por ejemplo, conflictos entre miembros del equipo). Se evalan los distintos mtodos, herramientas y tcnicas empleadas para ver su eficacia y adecuacin, y se valora sistemtica y peridicamente el propio proceso para conocer su relevancia, utilidad y eficacia en el contexto del proyecto. Cuando se juzga necesario, se llevan a cabo y se gestionan los cambios.

8.5 Cierre
El proyecto llega a su fin cuando todos los planes y procesos implicados se han promulgado y completado. En esta fase, se repasan los criterios para el xito del proyecto. Una vez que se ha establecido el cierre, se llevan a cabo actividades de archivado, post mortem y de mejoras de los procesos.

8.5.1 Determinar el Cierre

[Dor02: v1c8,v2c3,c5; Rei02: c10; Tha97: c3,c10] Se han completado las tareas tal y como se especificaron en los planes, y se confirman los criterios para lograr un acabado satisfactorio. Todos los productos planificados han sido entregados con caractersticas aceptables. Se marca y confirma la satisfaccin de los requerimientos, se han logrado los objetivos del proyecto. Estos procesos por lo general involucran a todos los contratistas y acaban con la documentacin tanto de la aceptacin del cliente y como de los informes de cualquier otro problema pendiente conocido.

8.5.2 Actividades de Cierre

[Pf101: c12; Som05: c4] Tras haberse confirmado el cierre, se archivan los materiales del proyecto de acuerdo a los mtodos, localizacin y duracin pactados con los contratistas. La base de datos de medicin de la organizacin se pone al da con los datos finales del proyecto y se emprenden anlisis post-proyecto. Se inicia un proyecto post mortem con el fin de analizar los temas, problemas y oportunidades encontrados durante el proceso (particularmente por medio de revisiones y evaluaciones, ver el subrea 4 Revisin y Evaluacin) y se sacan lecciones del proceso que luego alimentan los conocimientos de la organizacin y los intentos de mejora (ver tambin el KA del Proceso de Ingeniera del Software).

8.6 Medidas de la Ingeniera del Software

[ISO 15939-02] La importancia de la medicin y su papel en las buenas prcticas de gestin est ampliamente reconocido, y es tal que su importancia slo puede aumentar en los prximos aos. Medir con eficacia se ha convertido en una de las piedras angulares de la madurez de una organizacin. Las palabras claves para la medicin del software y para los mtodos de medicin fueron definidas en [ISO15939-02] basadas en el vocabulario internacional de metrologa ISO [ISO93]. No obstante, los lectores encontrarn en la literatura existente diferencias en la terminologa; por ejemplo, el trmino "mtrica" a veces se usa en lugar de "medicin". Este apartado sigue el estndar internacional ISO/IEC 15939, que describe el proceso que define las actividades y tareas necesarias para implementar un proceso de medicin e incluye, asimismo, un modelo de medicin de la informacin.

8.6.1 Establecer y Sostener el Compromiso de Medir

Aceptar los requerimientos de medicin. Cada tentativa de medicin debe estar guiada por objetivos organizacionales, e impulsada por un conjunto de 1 requerimientos de medicin establecidos por la organizacin y por el proyecto. Por ejemplo, un objetivo organizacional podra ser ser los primeros en salir al mercado con los nuevos productos." [Fen98: c3,c13; Pre04: c22] Esto a su vez podra generar un requisito para que se midan los factores que contribuyen a este objetivo, y as se puedan gestionar los proyectos para hacer frente a este objetivo.

84

Definir el alcance de la medicin. Se debe establecer la unidad organizacional a la que se va a aplicar cada requisito de medicin. Esto puede consistir en un rea funcional, en un solo proyecto, en un solo sitio, o incluso en toda la empresa. Todas las subsiguientes tareas de medicin relacionadas con este requisito deben encontrarse dentro del alcance definido. Adems, se debe identificar a los contratistas implicados. Compromiso de la direccin y del personal con la medicin. El compromiso debe establecerse formalmente, debe comunicarse, y debe apoyarse en los recursos (ver el siguiente artculo).

Empear recursos para la medicin. El compromiso de la organizacin con la medicin es un factor esencial para el xito, como demuestra la asignacin de recursos para llevar a cabo el proceso de medicin. El asignar recursos incluye el reparto de responsabilidades para las diferentes tareas del proceso de medicin (tales como usuario, analista y bibliotecario) y el proporcionar una financiacin, entrenamiento, herramientas, y apoyo adecuados para dirigir el proceso de un modo perdurable.

8.6.2 Planificar el Proceso de Medicin

Caracterizar la unidad organizacional. La unidad organizacional proporciona el contexto para la medicin as que es importante hacer explcito este contexto y articular las presunciones que ste incluye y las restricciones que va imponiendo. La caracterizacin puede darse en trminos de procesos organizacionales, dominios de aplicaciones, tecnologa e interfaces organizacionales. Un modelo de proceso organizacional tambin es por lo general un elemento de una caracterizacin de la unidad organizacional [ISO15939-02: 5.2.1]. Identificar las necesidades de informacin. Las necesidades de informacin se basan en las metas, restricciones, riesgos y problemas de la unidad organizacional. stas pueden proceder de objetivos comerciales, organizacionales, reguladores y/o del producto. Deben ser identificadas y deben priorizarse. Debe entonces seleccionarse un subconjunto para ser cotejado y los resultados deben ser documentados, comunicados y revisados por los contratistas [ISO 15939-02: 5.2.2]. Seleccionar las mediciones. Se deben elegir las mediciones candidatas al puesto, claramente vinculadas a las necesidades de informacin. Las mediciones deben seleccionarse en base a las prioridades de las necesidades de informacin y otros criterios como el coste de recoleccin de datos, el grado de trastorno del proceso durante la recoleccin, la facilidad de anlisis, la facilidad de obtener datos precisos y consistentes, etc [ISO15939-02: 5.2.3 y Apndice C]. Definir la recoleccin de datos, el anlisis y los procedimientos para informar. Esto abarca los procedimientos y horarios de recoleccin, y la gestin de datos de almacenamiento, verificacin, anlisis, informes y configuracin [ISO15939-02: 5.2.4]. Definir los criterios para evaluar los productos de informacin. Los criterios para evaluar estn influenciados por los objetivos tcnicos y comerciales de la unidad organizacional. Los productos de informacin incluyen los asociados con el producto que est siendo elaborado, as como los asociados con los procesos utilizados para gestionar y medir el proyecto [ISO15939- 02: 5.2.5 y Apndices D y E]. Revisar, aprobar y proporcionar recursos para las tareas de medicin. o El plan de medicin debe ser revisado y aprobado por los contratistas adecuados. Esto incluye todos los procedimientos de recoleccin de datos y los procedimientos de almacenamiento, anlisis e informes; los criterios de evaluacin; horarios y responsabilidades. Los criterios para revisar estos artefactos tendran que haberse establecido a un nivel de unidad organizacional o superior y debieran usarse como base para estas revisiones. Tales criterios deben tomar en cuenta experiencias anteriores, disponibilidad de recursos, y trastornos potenciales del proceso cuando se proponen cambios

85

a las prcticas actuales. La aprobacin demuestra que existe un compromiso con el proceso de medicin [ISO15939-02: 5.2.6.1 y Apndice F]. o Hay que hacer que los recursos estn disponibles para implementar las tareas de medicin planeadas y aprobadas. La disponibilidad de los recursos puede organizarse en aquellos casos en donde los cambios han de pilotarse antes de un amplio despliegue. Se debe prestar atencin a los recursos necesarios para un amplio despliegue de los nuevos procedimientos o mediciones [ISO1593902: 5.2.6.2].

Adquirir y desplegar tecnologas de apoyo. Esto incluye una evaluacin de las tecnologas de apoyo disponibles, la seleccin de las tecnologas ms adecuadas, la adquisicin de esas tecnologas, y el despliegue de esas tecnologas [ISO 1593902:5.2.7].

8.6.3 Realizar el Proceso de Medicin

Integrar los procedimientos de medicin con los procesos pertinentes. Los procedimientos de medicin, tales como la recoleccin de datos, deben integrarse en los procesos que estn midiendo. Esto puede que implique cambiar los procesos actuales para adaptar la recoleccin de datos o las actividades de generacin. Puede tambin implicar el anlisis de los actuales procesos para minimizar esfuerzos adicionales y evaluaciones del efecto en los empleados, con el fin de asegurarse de que sern aceptados los procedimientos de medicin. Se necesita considerar los temas morales y otros factores humanos. Adems, los procedimientos de medicin deben comunicarse a los proveedores de datos, puede que se tenga que proporcionar entrenamiento, y se debe proporcionar el tpico apoyo. De manera similar, el anlisis de datos y los procedimientos de informacin deben tener la tpica integracin en los procesos organizacionales y/o del proyecto [ISO 15939-02: 5.3.1]. Recolectar datos. Se debe recolectar, verificar y almacenar datos [ISO 1539-02: 5.3.2]. Analizar datos y desarrollar productos de informacin. Se pueden agregar, transformar o recodificar datos como parte del proceso de anlisis, utilizando un grado de rigor adecuado a la naturaleza de los datos y las necesidades de informacin. Los resultados de este anlisis son indicadores tpicos, tales como grficas, nmeros u otras indicaciones que han de ser interpretadas, dando lugar a conclusiones iniciales que han de presentar los contratistas. Los resultados y conclusiones han de consultarse, utilizando un proceso definido por la organizacin (que puede ser formal o informal). Los proveedores de datos y los usuarios de las mediciones deben participar en revisar los datos para asegurar que son significativos y precisos, y que puede llevar a acciones razonables [ISO 15939-02: 5.3.3 y Apndice G]. Comunicar los resultados. Los productos de informacin deben documentarse y comunicarse a los usuarios y contratistas [ISO 15939-02: 5.3.4].

8.6.4 Evaluar las Mediciones

Evaluar los productos de informacin. Evaluar los productos de informacin contrastndolos con los criterios de evaluacin especficos y determinar las fuerzas y debilidades de los productos de informacin. Esto puede realizarlo un proceso interno o una auditora externa y debe incluir una retroalimentacin de los usuarios de las mediciones. Grabar las lecciones aprendidas en una base de datos adecuada [ISO 15939-02: 5.4.1 y Apndice D]. Evaluar el proceso de medicin. Evaluar el proceso de medicin contrastndolo con los criterios de evaluacin especficos y determinar las fuerzas y debilidades de los procesos. Esto puede realizarlo un proceso interno o una auditora externa y debe incluir una retroalimentacin de los usuarios de las mediciones. Grabar las lecciones aprendidas en una base de datos adecuada [ISO 15939-02: 5.4.1 y Apndice D]. Identificar las mejoras potenciales. Tales mejoras pueden consistir en cambios en el formato de los indicadores, cambios en las unidades medidas, o en la reclasificacin de

86

las categoras. Determinar los costes y beneficios de las mejoras potenciales y seleccionar las acciones de mejora adecuadas. Comunicar las mejoras propuestas al dueo del proceso de medicin y a los contratistas para su revisin y aprobacin. Comunicar tambin la falta de mejoras potenciales si el anlisis no identifica ninguna mejora [ISO 15939-02: 5.4.2].

Matriz de temas vs. Material de referencia

[Dor02]

[ISO15239 02]

[Fen98]

[Pfl01]

[Pre0 4]

[Rei02]

[Som05 ]

[Tha97 ]

1.Iniciacin y Alcance

1.1 Determinacin y Negociacin de Requerimientos 1.2 Viabilidad, Anlisis 1.3 Construir Verificar para

v2c4

C4

C7

C5

C6

C6 C6

2. Planificacin de un Proyecto Software 2.1 Planificacin de un Proceso 2.2 Determinar los entregables 2.3 Esfuerzo, Horario y Clculo del Coste 2.4 Reparto de Recursos 2.5 Gestin de Riesgos 2.6 Gestin de Calidad 2.7 Gestin de Planes 3. Promulgacin del Proyecto Software 3.1 Implementacin de Planes C3 C4 V2c7 V1c8, v2c3-c5 C3 C3 V2c7 C12 C3 c23,c 24 C24 C25 C26 c5,c6 C4,c23 C5 v1c6,v2c7 ,v2c8 c2,c3 c2,c2 1 C24 c1,c3, c5 c3,c4 C3,c4, c6 C4

C3

C8,c9 C11 C10

C4 C4 C24,c2 5 C4

C6,c7 C4 C9,c10 C4

87

3.2 Gestin de Contratos con Proveedores 3.3 Implementacin de Procesos para medir 3.4 Proceso Supervisin de V1c8, v2c2-c5, c7 V2c7 C13,c1 4 C22 C10,c1 2 C10

C4

C3,c10

C25

C3,c10

3.5 Proceso de Control 3.6 Informes 4. Revisin y Evaluacin 4.1 Determinar la satisfaccin de Requerimientos los

C10 C10

C3,c9 C3,c10

C10

C3,c10

4.2 Revisar y Evaluar la Ejecucin 5. Cierre 5.1 Determinar el Cierre 5.2 Actividades Cierre 6. Medida Ingeniera del Software 6.1 Establecer Sostener el compromiso de Medir 6.2 Planificar el Proceso de Medicin 6.3 Realizar el Proceso de Medicin 6.4 Evaluar Mediciones las y de del la

v1c8,v2c3 ,c5

C8,c9

C10

C3,c10

V1c8,v2c3 ,c5 C12 *

C10 C4

C3,c10

C3,c13

C22

C5,C,D,E, F

C5,G

C5,D

Referencias recomendadas para la gestin del software

88

[Dor02] M. Dorfman and R.H. Thayer, eds., Software Engineering, IEEE Computer Society Press, 2002, Vol. 1, Chap. 6, 8, Vol. 2, Chap. 3, 4, 5, 7, 8. [Fen98] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, second ed., International Thomson Computer Press, 1998, Chap. 1-14. [ISO15939-02] ISO/IEC 15939:2002, Software Engineering Software Measurement Process, ISO and IEC, 2002. [Pfl01] S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice Hall, 2001, Chap. 2-4, 8, 9, 12, 13. [Pre04] R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGrawHill, 2004, Chap. 2, 6, 7, 22-26. [Rei02] D.J. Reifer, ed., Software Management, IEEE Computer Society Press, 2002, Chap. 16, 7-12, 13. [Som05] I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005, Chap. 3-6, 23- 25. [Tha97] R.H. Thayer, ed., Software Engineering Project Management, IEEE Computer Society Press, 1997, Chap. 1-10. Apndice a. Lista de lecturas adicionales (Adl99) T.R. Adler, J.G. Leonard, and R.K. Nordgren, Improving Risk Management: Moving from Risk Elimination to Risk Avoidance, Information and Software Technology, vol. 41, 1999, pp. 29-34. (Bai98) R. Baines, Across Disciplines: Risk, Design, Method, Process, and Tools, IEEE Software, July/August 1998, pp. 61-64. (Bin97) R.V. Binder, Can a Manufacturing Quality Model Work for Software? IEEE Software, September/October 1997, pp. 101-102,105. (Boe97) B.W. Boehm and T. DeMarco, Software Risk Management, IEEE Software, May/June 1997, pp. 17-19. (Bri96) L.C. Briand, S. Morasca, and V.R. Basili, Property-Based Software Engineering Measurement, IEEE Transactions on Software Engineering, vol. 22, iss. 1, 1996, pp. 68-86. (Bri96a) L. Briand, K.E. Emam, and S. Morasca, On the Application of Measurement Theory in Software Engineering, Empirical Software Engineering, vol. 1, 1996, pp. 61-88. (Bri97) L.C. Briand, S. Morasca, and V.R. Basili, Response to: Comments on Property-based Software Engineering Measurement: Refining the Addivity Properties, IEEE Transactions on Software Engineering, vol. 23, iss. 3, 1997, pp. 196- 197. (Bro87) F.P.J. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Apr. 1987, pp. 10-19. (Cap96) J. Capers, Applied Software Measurement: Assuring Productivity and Quality, second ed., McGraw-Hill, 1996. (Car97) M.J. Carr, Risk Management May Not Be For Everyone, IEEE Software, May/June 1997, pp. 21-24. (Cha96) R.N. Charette, Large-Scale Project Management Is Risk Management, IEEE Software, July 1996, pp. 110-117. (Cha97) R.N. Charette, K.M. Adams, and M.B. White, Managing Risk in Software Maintenance, IEEE Software, May/June 1997, pp. 43-50. (Col96) B. Collier, T. DeMarco,and P. Fearey, A Defined Process for Project Postmortem Review, IEEE Software, July 1996, pp. 65-72. (Con97) E.H. Conrow and P.S. Shishido, Implementing Risk Management on Software Intensive Projects, IEEE Software, May/June 1997, pp. 83-89. (Dav98) A.M. Davis, Predictions and Farewells, IEEE Software, July/August 1998, pp. 6-9.

89

(Dem87) T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, Dorset House Publishing, 1987. (Dem96) T. DeMarco and A. Miller, Managing Large Software Projects, IEEE Software, July 1996, pp. 24-27. (Fav98) J. Favaro and S.L. Pfleeger, Making Software Development Investment Decisions, ACM SIGSoft Software Engineering Notes, vol. 23, iss. 5, 1998, pp. 69-74. (Fay96) M.E. Fayad and M. Cline, Managing Object-Oriented Software Development, Computer, September 1996, pp. 26-31. (Fen98) N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, second ed., International Thomson Computer Press, 1998. (Fle99) R. Fleming, A Fresh Perspective on Old Problems, IEEE Software, January/February 1999, pp. 106-113. (Fug98) A. Fuggetta et al., Applying GQM in an Industrial Software Factory, ACM Transactions on Software Engineering and Methodology, vol. 7, iss. 4, 1998, pp. 411-448. (Gar97) P.R. Garvey, D.J. Phair, and J.A. Wilson, An Information Architecture for Risk Assessment and Management, IEEE Software, May/June 1997, pp. 25-34. (Gem97) A. Gemmer, Risk Management: Moving beyond Process, Computer, May 1997, pp. 33-43. (Gla97) R.L. Glass, The Ups and Downs of Programmer Stress, Communications of the ACM, vol. 40, iss. 4, 1997, pp. 17-19. (Gla98) R.L. Glass, Short-Term and Long-Term Remedies for Runaway Projects, Communications of the ACM, vol. 41, iss. 7, 1998, pp. 13-15. (Gla98a) R.L. Glass, How Not to Prepare for a Consulting Assignment, and Other Ugly Consultancy Truths, Communications o 1 f the ACM, vol. 41, iss. 12, 1998, pp. 11-13. (Gla99) R.L. Glass, The Realities of Software Technology Payoffs, Communications of the ACM, vol. 42, iss. 2, 1999, pp. 74-79. (Gra99) R. Grable et al., Metrics for Small Projects: Experiences at the SED, IEEE Software, March/April 1999, pp. 21-29. (Gra87) R.B. Grady and D.L. Caswell, Software Metrics: Establishing A Company-Wide Program. Prentice Hall, 1987. (Hal97) T. Hall and N. Fenton, Implementing Effective Software Metrics Programs, IEEE Software, March/April 1997, pp. 55-64. (Hen99) S.M. Henry and K.T. Stevens, Using Belbins Leadership Role to Improve Team Effectiveness: An Empirical Investigation, Journal of Systems and Software, vol. 44, 1999, pp. 241-250. (Hoh99) L. Hohmann, Coaching the Rookie Manager, IEEE Software, January/February 1999, pp. 16-19. (Hsi96) P. Hsia, Making Software Development Visible, IEEE Software, March 1996, pp. 2326. (Hum97) W.S. Humphrey, Managing Technical People: Innovation, Teamwork, and the Software Process: Addison-Wesley, 1997. (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996. (Jac98) M. Jackman, Homeopathic Remedies for Team Toxicity, IEEE Software, July/August 1998, pp. 43-45. (Kan97) K. Kansala, Integrating Risk Assessment with Cost 812 IEEE 2004 Version Estimation, IEEE Software, May/June 1997, pp. 61-67. (Kar97) J. Karlsson and K. Ryan, A Cost-Value Aproach for Prioritizing Requirements, IEEE Software, September/October 1997, pp. 87-74.

90

(Kar96) D.W. Karolak, Software Engineering Risk Management, IEEE Computer Society Press, 1996. (Kau99) K. Kautz, Making Sense of Measurement for Small Organizations, IEEE Software, March/April 1999, pp. 14-20. (Kei98) M. Keil et al., A Framework for Identifying Software Project Risks, Communications of the ACM, vol. 41, iss. 11, 1998, pp. 76-83. (Ker99) B. Kernighan and R. Pike, Finding Performance Improvements, IEEE Software, March/April 1999, pp. 61-65. (Kit97) B. Kitchenham and S. Linkman, Estimates, Uncertainty, and Risk, IEEE Software, May/June 1997, pp. 69-74. (Lat98) F. v. Latum et al., Adopting GQM-Based Measurement in an Industrial Environment, IEEE Software, January-February 1998, pp. 78-86. (Leu96) H.K.N. Leung, A Risk Index for Software Producers, Software Maintenance: Research and Practice, vol. 8, 1996, pp. 281-294. (Lis97) T. Lister, Risk Management Is Project Management for Adults, IEEE Software, May/June 1997, pp. 20-22. (Mac96) K. Mackey, Why Bad Things Happen to Good Projects, IEEE Software, May 1996, pp. 27- 32. (Mac98) K. Mackey, Beyond Dilbert: Creating Cultures that Work, IEEE Software, January/February 1998, pp. 48-49. (Mad97) R.J. Madachy, Heuristic Risk Assessment Using Cost Factors, IEEE Software, May/June 1997, pp. 51-59. (McC96) S.C. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996. (McC97) S.C. McConnell, Software Project Survival Guide, Microsoft Press, 1997. (McC99) S.C. McConnell, Software Engineering Principles, IEEE Software, March/April 1999, pp. 6- 8. (Moy97) T. Moynihan, How Experienced Project Managers Assess Risk, IEEE Software, May/June 1997, pp. 35-41. (Ncs98) P. Ncsi, Managing OO Projects Better, IEEE Software, July/August 1998, pp. 50-60. (Nol99) A.J. Nolan, Learning From Success, IEEE Software, January/February 1999, pp. 97105. (Off97) R.J. Offen and R. Jeffery, Establishing Software Measurement Programs, IEEE Software, March/April 1997, pp. 45-53. (Par96) K.V.C. Parris, Implementing Accountability, IEEE Software, July/August 1996, pp. 8393. (Pfl97) S.L. Pfleeger, Assessing Measurement (Guest Editors Introduction), IEEE Software, March/April 1997, pp. 25-26. (Pfl97a) S.L. Pfleeger et al., Status Report on Software Measurement, IEEE Software, March/April 1997, pp. 33-43. (Put97) L.H. Putman and W. Myers, Industrial Strength Software Effective Management Using Measurement, IEEE Computer Society Press, 1997. (Rob99) P.N. Robillard, The Role of Knowledge in Software Development, Communications of the ACM, vol. 42, iss. 1, 1999, pp. 87-92. (Rod97) A.G. Rodrigues and T.M. Williams, System Dynamics in Software Project Management: Towards the Development of a Formal Integrated Framework, European Journal of Information Systems, vol. 6, 1997, pp. 51-66.

91

(Rop97) J. Ropponen and K. Lyytinen, Can Software Risk Management Improve System Development: An Exploratory Study, European Journal of Information Systems, vol. 6, 1997, pp. 41- 50. (Sch99) C. Schmidt et al., Disincentives for Communicating Risk: A Risk Paradox, Information and Software Technology, vol. 41, 1999, pp. 403-411. (Sco92) R.L. v. Scoy, Software Development Risk: Opportunity, Not Problem, Software Engineering Institute, Carnegie Mellon University CMU/SEI-92- TR-30, 1992. (Sla98) S.A. Slaughter, D.E. Harter, and M.S. Krishnan, Evaluating the Cost of Software Quality, Communications of the ACM, vol. 41, iss. 8, 1998, pp. 67-73. (Sol98) R. v. Solingen, R. Berghout, and F. v. Latum, Interrupts: Just a Minute Never Is, IEEE Software, September/October 1998, pp. 97-103. (Whi95) N. Whitten, Managing Software Development Projects: Formulas for Success, Wiley, 1995. (Wil99) B. Wiley, Essential System Requirements: A Practical Guide to Event-Driven Methods, Addison- Wesley, 1999. (Zel98) M.V. Zelkowitz and D.R. Wallace, Experimental Models for Validating Technology, Computer, vol. 31, iss. 5, 1998, pp. 23-31. Apndice b. Lista de estndares (IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990. (IEEE12207.0-96) IEEE/EIA 12207.0- 1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996. (ISO15939-02) ISO/IEC 15939:2002, Software Engineering-Software Measurement Process, ISO and IEC, 2002. (PMI00) Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, 2000.

92

9 Proceso de Ingeniera del software

ACRNIMOS CMMI EF FP HRM IDEAL OMG QIP SCAMPI CMMI SCE SEPG Modelo de Capacidad de Madurez Integrado Fbrica de Experiencia Punto de Funcin Gestin de Recursos Humanos (Modelo de) Iniciacin-Diagnstico-Establecimiento-Actuacin-Apoyo Grupo de Gestin de Objetos Paradigma de Mejoras de la Calidad Evaluacin Basada en el MCM para Mejoras de los Procesos utilizando la Evaluacin de la Capacidad del Software Grupo de Proceso de la Ingeniera de Software

INTRODUCCIN El rea de Conocimiento (AC) del Proceso de Ingeniera del Software puede examinarse en dos niveles. El primer nivel engloba las actividades tcnicas y de gestin dentro de los procesos del ciclo de vida del software realizadas durante la adquisicin, desarrollo, mantenimiento y retirada del software. El segundo es un meta-nivel, que se refiere a la definicin, implementacin, valoracin, medicin, gestin, cambios y mejoras de los procesos mismos del ciclo de vida del software. El primer nivel lo cubren las otras AC en la Gua. Este el rea de Conocimiento (AC) se ocupa del segundo nivel. El trmino proceso de ingeniera del software puede interpretarse de diversas maneras, y esto puede llevar a confusiones. Un significado, donde se usa la palabra el, como en el caso de el proceso de ingeniera del software, podra implicar que existe slo un modo correcto de realizar tareas de ingeniera del software. En la Gua se evita este significado porque no existe tal proceso. Los estndares como IEEE12207 hablan de procesos de ingeniera del software, lo que significa que hay muchos procesos involucrados, tales como el proceso de desarrollo o proceso de administracin de configuracin. Un segundo significado se refiere a una discusin general sobre procesos relacionados con la ingeniera del software. Este es el significado que se pretende con el ttulo de esta el rea de Conocimiento (AC) y el que se usa con ms frecuencia en la descripcin del el rea de Conocimiento (AC). Finalmente, un tercer significado podra referirse al conjunto actual de actividades realizadas dentro de una organizacin, que podra verse como un solo proceso, especialmente desde dentro de la organizacin. Se utiliza este significado en el rea de Conocimiento (AC) en muy pocos casos. Esta el rea de Conocimiento (AC) se aplica a cualquier parte de la gestin de los procesos del ciclo de vida del software en la que se introduzcan cambios tecnolgicos o de procedimiento para la mejora de proceso o producto. Los procesos de ingeniera del software tienen importancia no slo para las grandes organizaciones. Ms an, las actividades relacionadas con los procesos pueden ser, y han sido, realizadas con xito por pequeas organizaciones, equipos e individuos.

93

El objetivo de gestionar los procesos del ciclo de vida del software es implementar nuevos o mejores procesos en las prcticas actuales, sean stos individuales, proyectos u organizacionales. Esta el rea de Conocimiento (AC) no aborda explcitamente la Gestin de Recursos Humanos (HRM), por ejemplo, que estn consagrados en la gente CMM (Cur02) y procesos de ingeniera de sistemas [ISO1528-028; IEEE 1220-67 98]. Tambin debera reconocerse que muchos temas de procesos de ingeniera del software estn relacionados de cerca con otras disciplinas, tales como la gestin, incluso a veces utilizando una terminologa diferente. Desglose de temas para el proceso de ingeniera

9.1 Implementacin y Cambios de Proceso

sta sub-rea se centra en los cambios organizacionales. Describe la infraestructura, actividades, modelos y consideraciones prcticas de la implementacin y cambios de un proceso. Aqu se describe la situacin en la que los procesos se despliegan por primera vez (por ejemplo, introduciendo un proceso de inspeccin en un proyecto o un mtodo que cubra todo el ciclo de vida), y donde se cambian los procesos actuales (por ejemplo, introduciendo una

94

herramienta u optimizando un procedimiento). A esto tambin se le puede denominar evolucin del proceso. En ambos casos hay que modificar las prcticas actuales. Si resulta que se extienden las modificaciones, puede que tambin sean necesarios cambios en la cultura organizacional.

9.1.1 Infraestructura del Proceso

[IEEE12207.0-96; ISO15504; SEL96] Este tema incluye el conocimiento relacionado con la infraestructura del proceso de ingeniera del software. Para establecer procesos de ciclo de vida del software, es necesario que la adecuada infraestructura est en su lugar, es decir que los recursos estn al alcance de la mano (personal competente, herramientas y financiacin) y que se hayan asignado responsabilidades. Cuando stas tareas se han completado, indica el compromiso de la administracin y los propios compromisos han surtido efecto en el proceso de ingeniera del software. Puede que haya que establecer diversos comits, tales como un comit de direccin que supervise el esfuerzo del proceso de ingeniera del software. En [McF96] se ofrece una descripcin de la infraestructura para la mejora de los procesos en general. En la prctica se utilizan dos tipos principales de infraestructura: el Grupo de Proceso de Ingeniera del Software y la fbrica de experiencias.

9.1.1.1

Grupo de Proceso de la Ingeniera del Software (SEPG)

Se pretende que el SEPG sea el foco central de mejoras del proceso de la ingeniera del software y tiene cierto nmero de responsabilidades en trminos de inicializacin y mantenimiento. stos se describen en [Fow90].

9.1.1.2

Fabrica de Experiencia (EF)

El concepto de EF separa la organizacin del proyecto (la organizacin del desarrollo del software, por ejemplo) de la organizacin de las mejoras. La organizacin del proyecto se centra en el desarrollo y en el mantenimiento del software, mientras que la EF se ocupa de mejoras del proceso de la ingeniera del software. Se trata de que la EF institucionalice el aprendizaje colectivo de una organizacin, desarrollando, actualizando, y entregando a la organizacin del proyecto los paquetes de experiencia (por ejemplo, guas, modelos y cursos de entrenamiento), tambin conocidos como validaciones de procesos. La organizacin del proceso ofrece a la EF sus productos, los planes utilizados en su desarrollo, y los datos reunidos durante su desarrollo y operacin. En [Bas92] se presentan ejemplos de paquetes de experiencia.

9.1.2 Ciclo de Gestin del Proceso del Software

[Bas92; Fow90; IEEE12207.0-96; ISO15504-98; McF96; SEL96] La gestin de los procesos del software consiste en cuatro actividades secuenciadas en un ciclo iterativo, permitiendo una retroalimentacin continua y mejoras del proceso del software: La actividad del Establecimiento de la Infraestructura de un Proceso consiste en establecer un acuerdo para la implementacin y cambios del proceso (que incluya la gestin de compra) y levantar una adecuada infraestructura (recursos y responsabilidades) a que tenga lugar. El propsito de la actividad de Planificacin es comprender los actuales objetivos de negocio y el proceso necesario del proyecto u organizacin particular, para identificar sus fortalezas y debilidades, y elaborar un plan para la implementacin y cambio del proceso. El propsito de la Implementacin y Cambios del Proceso, consiste en llevar a cabo el plan, desplegar nuevos procesos (que pueden implicar, por ejemplo, el desarrollo de herramientas y el entrenamiento del personal) y/o cambiar procesos ya existentes. La Evaluacin del Proceso se encarga de descubrir lo bien que se ha llevado a cabo la implementacin y cambios, y si se materializaron o no los beneficios esperados. Los resultados se utilizarn ms adelante como entradas para ciclos subsiguientes.

95

9.1.3 Modelos Para el Proceso de Implementacin y Cambios

Han surgido dos modelos generalizados para llevar a cabo la implementacin y cambios de procesos que son el paradigma de Mejoras de la Calidad (QIP) [SEL96] y el modelo IDEAL [McF96]. En [SEL96] se comparan los dos paradigmas. La evaluacin de la implementacin del proceso y de los resultados de los cambios puede ser cualitativa o cuantitativa.

9.1.4 Consideraciones Prcticas

La implementacin y cambios de procesos, se constituye en una instancia del cambio organizacional. Los esfuerzos de ms xito en los cambios organizacionales, tratan el cambio como un proyecto en toda regla, con planes adecuados, monitoreo y revisiones. En [Moi98; San98; Sti99] se encuentran las directrices sobre la implementacin y cambios de procesos dentro de las organizaciones de ingeniera del software, incluyendo la planificacin de las acciones, entrenamientos, gestin de patrocinadores, compromisos, y la seleccin de proyectos piloto, y abarcan tanto los procesos como las herramientas. En [EIE99a] se sealan los estudios empricos sobre factores de xito para los cambios en los procesos. El papel de los agentes de cambio en esta actividad se discute en (Hut94). La implementacin y cambio de procesos puede verse asimismo como una instancia de consultora (sea interna o externa). Uno tambin puede ver cambios organizacionales desde la perspectiva de la transferencia de tecnologa (Rog83). Los artculos de ingeniera del software que se ocupan de la transferencia de tecnologa y de las caractersticas de los receptores de nuevas tecnologas (que podran incluir tecnologas relacionadas con los procesos) son (Pfl99; Rag89). Hay dos formas de acercarse la evaluacin de la implementacin y cambios de un proceso, sea en trminos de cambios al proceso mismo o en trminos de cambios en las salidas de los procesos (por ejemplo, midiendo el retorno de una inversin tras realizar un cambio). Una visin pragmtica de lo que se puede lograr con estas evaluaciones se da en (Her98). Las investigaciones sobre cmo evaluar la implementacin y cambio del procesos, y los casos de estudios dedicados a ello, se encuentran en [Gol99], (Kit98; Kra99; McG94).

9.2 Definicin de Procesos

Una definicin de un proceso puede ser un procedimiento, una poltica, o un estndar. Los procesos de ciclo de vida del software se definen por muchas razones, que incluira el incrementar la calidad el producto, el facilitar el entendimiento y la comunicacin humana, apoyar las mejoras de los procesos, apoyar la gestin de los procesos, suministrar una gua automatizada para los procesos, y suministrar un apoyo para ejecuciones automatizadas. Los tipos de definiciones de procesos requeridos dependern, al menos parcialmente, de las razones para la definicin. Habra que sealar tambin que el contexto del proyecto y de la organizacin determinar el tipo de definicin del proceso que resulte ms til. Algunas variables importantes que hay que considerar incluyen la naturaleza del trabajo (por ejemplo, mantenimiento o desarrollo), el dominio de la aplicacin, el modelo de ciclo de vida, y la madurez de la organizacin.

9.2.1 Modelos de Ciclo de Vida del Software

[Pf101:c2; IEEE12207.0-96] Los modelos del ciclo de vida del software sirven como definiciones alto nivel de las fases que tienen lugar durante el desarrollo. No estn enfocadas a ofrecer definiciones detalladas sino ms bien a sobresaltar las actividades clave y sus interdependencias. Algunos ejemplos de modelos de ciclo de vida del software son el modelo de cascada, el modelo de prototipado de usar y tirar lo desechable, desarrollo evolutivo, entrega incremental/iterativa, el modelo en espiral, el modelo de reutilizacin de software, y la sntesis de software automatizado. Las comparaciones entre estos modelos se encuentran en [Como97], (Dav88), y un mtodo para seleccionar entre muchos de ellos en (Ale91).

96

9.2.2 Procesos del Ciclo de Vida del Software

Las definiciones de los procesos de ciclo de vida del software tienden a ser ms detalladas que los modelos de ciclo de vida del software. Sin embargo, los procesos del ciclo de vida del software no pretenden ordenar sus procesos en el tiempo. Esto significa que, en principio, los procesos del ciclo de vida del software pueden adaptarse para tener cabida en cualquiera de los modelos del ciclo de vida del software. La principal referencia sobre esta rea se encuentra en IEEE/EIA 12207.0: Informacin Tecnolgica Procesos del Ciclo de Vida del Software [IEEE 12207.0-96]. El estndar IEEE 1074:1997 para desarrollar procesos de ciclo de vida ofrece tambin una lista de procesos y actividades para el desarrollo y el mantenimiento del software [IEEE1074-97], adems de ofrecer una lista de actividades del ciclo de vida que pueden mapearse hacia procesos y organizarse del mismo modo que cualquiera de los modelos de ciclo de vida del software. Adems, identifica y une a estas actividades otros estndares de software IEEE. En principio, el estndar IEEE 1074 puede utilizarse para construir procesos de acuerdo a cualquiera de los modelos de ciclo de vida. Los estndares enfocados al mantenimiento de procesos son el estndar IEEE 1219-1998 y la ISO 14764:1998 [IEEE 1219-98]. Otros estndares importantes que ofrecen definiciones de procesos son: Estndar IEEE 1540: Gestin de Riesgos del Software. Estndar IEEE 1517: Procesos de Reutilizacin del Software (IEEE 1517-99). ISO/IEC 15939: Proceso de Medicin del Software [IEEE 15939-02]. Ver tambin el AC de Gestin de Ingeniera del Software para una descripcin detallada de este proceso. En algunas ocasiones se han de definir los procesos de ingeniera del software tomando en cuenta los procesos organizacionales para la gestin de la calidad. La ISO 9001 ofrece los requisitos para los procesos de gestin de la calidad y la ISO/IEC 90003 interpreta esos requerimientos para organizaciones que desarrollan software (ISO90003-04). Algunos procesos del ciclo de vida del software ponen nfasis en entregas rpidas y en una fuerte participacin de los usuarios, como por ejemplo mtodos giles tales como la Programacin Extrema [Bec99]. Un tipo de problema de seleccin tiene que ver con la eleccin realizable a lo largo del eje del mtodo basado en planificacin. Un acercamiento basado en riesgos para tomar tal decisin se describe en (Boe03a).

9.2.3 Notaciones para las Definiciones de los Procesos

Se pueden describir los procesos en diferentes niveles de abstraccin (por ejemplo, definiciones genricas contrapuestas a definiciones adaptadas, descriptivas contrapuestas a prescriptivas contrapuestas a proscriptivas [Pf101]. Varios elementos de un proceso pueden definirse, por ejemplo, actividades, productos (artefactos), y recursos. Los marcos detallados que estructuran los tipos de informacin requeridos para definir los procesos estn descritos en (Mad94). Existen algunas notaciones que se utilizan para definir procesos (SPC92). Una diferencia clave entre ellas reside en el tipo de informacin que definen, capturan y utilizan los marcos mencionados anteriormente. El ingeniero del software debera ser consciente de las siguientes aproximaciones al asunto: diagramas de flujo de datos, en trminos de la finalidad del proceso y de las salidas [ISO15504-98], como una lista de procesos descompuestos en actividades constituyentes y tareas definidas en lenguaje natural [IEEE12207.0-96], Grficos de Estados (Har98), EVTX (Rad85), modelado de Dependencia del Actor (Yu94), notacin SADT (Mcg93), redes Petri (Ban95); IDEF0 (IEEE 1320.1-111 98), y los basados en reglas (Bar95). Ms recientemente, un estndar de modelado del proceso ha sido publicado por el OMG que tiene como fin armonizar las notaciones de modelado. A esto se le llama la especificacin MPIS (Meta-Modelo del Proceso de Ingeniera del Software). [OMG02]

9.2.4 Adaptacin del Proceso

[IEEE 12007.0-96; ISO15504-98; Joh99] Es importante sealar que los procesos predefinidos incluso los estandarizados deben adaptarse a las necesidades locales, por ejemplo, el contexto organizacional, el tamao del

97

proyecto, los requisitos reguladores, las prcticas industriales y las culturas corporativas. Algunos estndares, tales como IEEE/EIA 12207, contienen mecanismos y recomendaciones para lograr la adaptacin.

9.2.5 Automatizacin
[Pf101:c2] Las herramientas automatizadas o apoyan la ejecucin de las definiciones del proceso o aportan una gua a los humanos que desarrollan los procesos definidos. En los casos en los que se realiza el anlisis de un proceso, algunas herramientas permiten distintos tipos de simulaciones (por ejemplo, la simulacin de un evento discreto). Adems, existen herramientas que apoyan cada una de las notaciones de la definicin del proceso citados anteriormente. Ms an, estas herramientas pueden ejecutar las definiciones de procesos para otorgar una ayuda automatizada a los procesos actuales, o en algunos casos para automatizarlos plenamente. Una visin general de las herramientas de modelado de procesos puede encontrarse en [Fin94] y de los entornos centrados en procesos en (Gar96). Los trabajos sobre cmo aplicar Internet al suministro de una gua de un proceso en tiempo real est descrita en (Kel98).

9.3 Valoracin del Proceso

La valoracin del proceso se lleva a cabo utilizando tanto un modelo de valoracin como un mtodo de valoracin. En algunas instancias, el trmino apreciacin se utiliza en vez de valoracin, y el trmino evaluacin de la capabilidad se utiliza cuando el apreciacin tiene como propsito la adjudicacin de un contrato.

9.3.1 Modelos de Valoracin del Proceso

Un modelo de valoracin recoge lo que se reconoce como buenas prcticas. Estas prcticas pueden referirse slo a las actividades tcnicas de ingeniera del software, o puede que se refieran tambin, por ejemplo, a actividades de gestin, de ingeniera de sistemas, y tambin de gestin de recursos humanos. La ISO/IEC 15504 [ISO15504-98] define un modelo ejemplar de valoracin y de requisitos de conformidad con otros modelos de valoracin. Los modelos de valoracin especficos disponibles y en uso son SW-CMM (SEI95), CMMI [SEI01], y Bootstrap [Sti99]. Se han definido muchos otros modelos de capacidad y madurez por ejemplo, para diseo, documentacin y mtodos formales, por nombrar algunos. La ISO 9001 es otro modelo comn de validacin que ha sido aplicado por organizaciones de software (ISO9001-00). Se ha desarrollado asimismo un modelo de madurez para sistemas de ingeniera, que puede resultar til cuando un proyecto u organizacin est implicado en el desarrollo y mantenimiento de sistemas, incluido el software (EIA/IS731-99). En [Joh99; San98] se examina la aplicabilidad de los modelos de valoracin a pequeas organizaciones. Existen dos arquitecturas generales para un modelo de valoracin que ofrecen diversas conjeturas sobre el orden en el que los procesos han de ser valorados: continua y escalonadamente (Pau94). Son muy diferentes entre s y la organizacin debera evaluarlos sopesndolos para determinar cules son los ms pertinentes para sus necesidades y objetivos.

9.3.2 Mtodos de Valoracin del Proceso

[Go199] Para poder realizar una valoracin, se necesita seguir un mtodo especfico de valoracin para producir un resultado cuantitativo que caracterizara la capacidad del proceso (o madurez de la organizacin). El mtodo de valoracin CBA-IPI, por ejemplo, se centra en la mejora de proceso (Dun96), y el mtodo SCE se centra en evaluar la capacidad de los proveedores (Bar95). Ambos mtodos fueron desarrollados para el SW-CMM. En [ISO15504-98], (Mas95) se ofrecen los requisitos de ambos tipos de mtodos que reflejan lo que se cree que seran buenas prcticas de valoracin.

98

Los mtodos SCAMPI giran en torno a las valoraciones CMMI [SEI01]. Las actividades realizadas durante una valoracin, la distribucin de esfuerzos en estas actividades, as como la atmsfera durante una valoracin son muy diferentes dependiendo de que sean para una mejora o para la adjudicacin de un contrato. Se han criticado los modelos y mtodos de las valoraciones de los procesos, por ejemplo (Fay97; Gra98). La mayora de estas crticas se refieren a la evidencia emprica que apoya el uso de modelos y mtodos de valoracin. Sin embargo, desde la publicacin de estos artculos, ha existido alguna evidencia sistemtica que apoyaba la eficacia de las valoraciones de los procesos (Cla97; Ele00; Ele00a;106 Kri99).

9.4 Medicin de los Procesos y Productos

Mientras que la aplicacin de mediciones a la ingeniera del software puede resultar compleja, particularmente en trminos de modelado y anlisis de mtodos, existen varios aspectos de las mediciones en la ingeniera del software que resultan fundamentales y que estn a la base de muchos de los procesos de medicin y anlisis ms avanzados. Ms an, los esfuerzos para mejorar el logro de procesos y productos slo puede valorarse si se ha establecido un conjunto de medidas de base. La medicin puede realizarse para apoyar la iniciacin de un proceso de implementacin y cambio o para evaluar las consecuencias de un proceso de implementacin y cambio, o puede realizarse en el producto mismo. Los trminos clave de medicin del software y de mtodos de medicin han sido definidos en la ISO/IEC 15939 basados en el vocabulario ISO internacional de metrologa. La ISO/IEC 15359 tambin ofrece un proceso estndar para medir tanto los procesos como las caractersticas de los productos [VIM93]. A pesar de todo, los lectores encontrarn diferencias terminolgicas en la literatura; por ejemplo, el trmino mtrica se utiliza a veces en vez de medida.

9.4.1 Medicin del Proceso

[ISO15539-02] El trmino medicin del proceso, tal y como se utiliza aqu, significa que se recoge, analiza e interpreta informacin cuantitativa sobre el proceso. Se utiliza la medicin para identificar las fortalezas y las debilidades de los procesos y para evaluar los procesos despus de que hayan sido implementados y/o cambiados. La medicin del proceso tambin puede servir para otros propsitos. Por ejemplo, la medicin del proceso es til para gestionar un proyecto de ingeniera del software. Aqu, el enfoque est en la medicin del proceso con el propsito de la implementacin y cambio del proceso. El diagrama de caminos de la Figura 2 ilustra algo que se dar por supuesto en la mayora de los proyectos de ingeniera del software, que indica que normalmente el proceso tiene un impacto en los resultados de un proyecto. No todo proceso va a tener un impacto positivo en todas sus salidas. Por ejemplo, la introduccin de inspecciones del software puede reducir esfuerzos y costes de las pruebas, pero puede incrementar el tiempo de espera si cada inspeccin introduce largas esperas a causa de haber calendarizado reuniones de larga inspeccin (Vot93). Por tanto, es preferible utilizar medidas para salidas de mltiples procesos que resultan importantes para la organizacin de la empresa. Mientras que se pueden hacer algunos esfuerzos para valorar la utilizacin de herramientas y de hardware, el recurso principal que necesita ser gestionado en la ingeniera del software es el personal. Como resultado de esto, las principales mediciones del inters son aqullas relacionadas con la productividad de los equipos o procesos (por ejemplo, utilizando una medida de puntos funcin producidos por unidad de persona-esfuerzo) y sus niveles asociados de experiencia en la ingeniera del software en general, y quizs en particulares tecnologas [Fen98: c3, c11;70 Som05: c25]. Las salidas de los procesos pueden ser, por ejemplo, calidad del producto (errores por KLOC (Kilo Lneas de Cdigo) o por Punto Funcin (FP)), mantenibilidad (el esfuerzo para hacer un

99

cierto tipo de cambio), productividad (LDC (Lneas de Cdigo)) o Puntos Funcin por personames), tiempo-de mercado, o satisfaccin del cliente (como medidos por medio de una encuesta a clientes). Esta relacin depende del contexto particular (por ejemplo, el tamao de la organizacin o el tamao del proyecto). En general, estamos mucho ms preocupados acerca del proceso de salidas. Sin embargo, con el objetivo de conseguir las salidas del proceso que deseamos (por ejemplo, mayor facilidad de mantenimiento, mayor satisfaccin del cliente), debemos haber implementado los procesos adecuados. Por supuesto que no son nicamente los procesos lo que tiene incidencia en las salidas. Otros factores como la capacidad del equipo y las herramientas que utilizan juegan un importante papel. Por ejemplo, cuando se evala el impacto de cambio en un proceso, es importante poner de relieve esas otras influencias. Adems es importante considerar el grado en el que el proceso ha sido institucionalizado (que fidelidad hay al proceso) para poder explicar porqu buenos procesos no siempre proporcionan las salidas deseadas en una situacin dada.

Figura 2 Diagrama que muestra la relacin entre un proceso y los resultados obtenidos

9.4.2 Medicin del producto software

[ISO9126-01] La medicin de un producto software incluye, principalmente, la medicin del tamao del producto, la estructura del producto y la calidad del producto.

9.4.2.1

Medicin del Tamao

El tamao de un producto software es evaluado a menudo mediante medidas de longitud (por ejemplo, lneas de cdigo fuente en un mdulo, pginas en documento de especificacin de los requisitos del software), o funcionalidad (por ejemplo, puntos de funcin en una especificacin). El Estndar IEEE Std 14143.1 proporciona los principios de medicin funcional del software. Los estndares internacionales para la medicin funcional del software incluyen el ISO/IEC 19761, 20926, y el 20968 [IEEE 14143.1- 00; ISO19761-03; ISO20926-03; ISO20968-02].

9.4.2.2

Estructura del producto

Una amplia gama de medidas de la estructura de productos de software se puede aplicar el diseo tanto a los de alto y de bajo nivel y el cdigo artefactos para reflejar el flujo de control (por ejemplo, el ciclomtico nmero, cdigo de nudos), de flujo de datos (por ejemplo, las medidas de corte), de anidacin (por ejemplo, el polinomio de anidacin medida, la medida BAND), estructuras de control (por ejemplo, la medida del vector, la medida NPATH), y estructura modular y la interaccin (por ejemplo, la informacin flujo, las medidas basadas en los rboles, el acoplamiento y la cohesin). [Fen98:c8; Pre04: C15]

9.4.2.3

Calidad del producto

Como un atributo multi-dimensional, medicin de la calidad es menos sencillo de definir que los de arriba. Adems, algunas de las dimensiones de la calidad es probable que exigen una valoracin cualitativa en lugar de forma cuantitativa . Una discusin ms detallada de la medicin de calidad del software se proporciona en el AC Calidad del Software, el tema 4.4.

100

ISO modelos de calidad de productos de software y de las correspondientes medidas se describen en ISO9126, partes 1 a 4 [ISO9126-01]. [Fen98: C9, C10; Pre04: C15; Som05: C24]

9.4.3 Calidad de los resultados de medicin

La calidad de los resultados de la medicin (precisin, reproducibilidad, repetibilidad, la convertibilidad, errores aleatorios de la medicin) es esencial para los programas de medicin para proporcionar resultados efectivos y delimitados. Las caractersticas clave de los resultados de medicin y de calidad relacionados con los instrumentos de medida han sido definidas en el vocabulario ISO internacional en materia de metrologa [Kan02]. La medicin se define en la teora como "la asignacin de nmeros a los objetos de una manera sistemtica para representar propiedades del objeto. " Una apreciacin de las escalas de medicin de software y la implicaciones de cada tipo de escala en relacin con la posterior seleccin de mtodos de anlisis de datos es especialmente importante.[Abr96; Fen98: c2; Pfl01: C11] escalas significativas se relacionan a una clasificacin de las escalas. Para ellos, la medicin teora proporciona una sucesin de ms y ms restricciones formas de asignacin de las medidas. Si los nmeros asignados se limitan a la etiquetas para clasificar los objetos, que son llama nominal. Si se asignan de manera que las filas de la objetos (por ejemplo, bueno, mejor, mejor), se les llama ordinales. Si tratan con magnitudes de la propiedad en relacin a una unidad de medida definida, se les llama intervalo de (Y los intervalos son uniformes entre los nmeros, a menos se especifique lo contrario, y por lo tanto aditivo). Mediciones se encuentran en el nivel de relacin de si tienen un cero absoluto punto, por lo que razones de las distancias al punto cero son significativas.

9.4.4 Modelos de informacin software

Como los datos se recogen y el repositorio de medicin es de poblacin, somos capaces de construir modelos a partir de datos y el conocimiento. Estos modelos existen para los fines del anlisis, clasificacin, y prediccin. Estos modelos deben ser evaluados para asegurarse de que sus niveles de precisin son suficientes y que sus limitaciones son conocidas y comprendidas. El refinamiento de modelos, que tiene lugar durante y despus de los proyectos se han completado, es otra actividad importante.

9.4.4.1

Construccin del Modelo

La construccin de modelos incluye la calibracin y evaluacin del modelo. El enfoque metaconducido a la medicin informa el proceso de construccin de modelos en la medida en que los modelos se construyen para responder a las preguntas pertinentes y lograr objetivos de mejora del software. Este proceso tambin se ve influido por las limitaciones implcitas de medicin en particular escalas en relacin a la eleccin del mtodo de anlisis. Los modelos se calibran (utilizando en particular las observaciones pertinentes, por ejemplo, los proyectos de los ltimos proyectos que utilizan una tecnologa similar) y su eficacia se evala (por ejemplo, mediante pruebas de su desempeo en las muestras de retencin). [Fen98: c4, c6, c13; Pfl01: c3, c11, c12, Som05: C25]

9.4.4.2

Implementacin del Modelo

El modelo de implementacin incluye tanto la interpretacin y el refinamiento de los modelos, los modelos calibrados se aplican al proceso, sus resultados se interpretan y evalan en el contexto del proceso o proyecto, y los modelos son luego refinados en su caso. [Fen98: c6; Pfl01: c3, C11, C12; Pre04: C22; Som05: C25]

9.4.5 Tcnicas de medicin de procesos

Las tcnicas de medicin pueden ser utilizadas para analizar procesos de ingeniera de software y para identificar las fortalezas y debilidades. Esto puede llevar a cabo para iniciar proceso de implementacin y el cambio, o para evaluar las consecuencias del proceso de aplicacin y el cambio.

101

La calidad de los resultados de las mediciones, tales como la precisin, repetibilidad y reproducibilidad, son problemas en la medicin de los procesos de ingeniera de software, ya que son medidas basados en instrumentos y prejuicios, como, por ejemplo, cuando los evaluadores de asignar puntajes a un proceso particular. Una discusin y un mtodo para lograr la calidad de la medicin se presentan en [Gol99]. Tcnicas del proceso de medicin se han clasificado en dos tipos generales: anlisis y evaluacin comparativa. Los dos tipos de tcnicas se pueden utilizar juntos desde que se basan en diferentes tipos de informacin. (Car91)

9.4.5.1

Tcnicas analticas

Las tcnicas analticas se caracterizan por basarse en "pruebas cuantitativas para determinar dnde se necesitan mejoras, y si una iniciativa de mejora ha sido un xito." El tipo de anlisis se ejemplifica con el Paradigma de Mejoramiento de la Calidad (PMC) que consiste en un ciclo de entender, evaluar y empaquetar [SEL96]. Las tcnicas presentadas a continuacin se destinan como otros ejemplos de las tcnicas analticas, y reflejan lo que se hace en la prctica. [Fen98; Mus99], (Lyu96; Wei93, Zel98) Sea o no una organizacin especfica utiliza todas estas tcnicas depende, al menos parcialmente, en su madurez. Estudios experimentales: La experimentacin consiste en la creacin de experimentos controlados o casi en la organizacin para evaluar los procesos. (McG94) Por lo general, un nuevo proceso se compara con el actual proceso para determinar si el primero tiene mejores resultados del proceso. Otro tipo de estudio experimental es la simulacin de procesos. Este tipo de estudio puede ser utilizado para analizar el comportamiento del proceso, explorar el potencial de mejora de procesos, predecir los resultados del proceso si el proceso actual ha cambiado en cierto modo, la ejecucin y control de procesos. Los datos iniciales sobre el rendimiento del proceso actual son necesarios recoger, sin embargo, como base para la simulacin. Revisin del proceso de definicin: es un medio por el cual una definicin de proceso (ya sea descriptivo o normativo, o ambos) se revisa, y las deficiencias y las posibles mejoras de procesos identificados. Ejemplos tpicos de esto son presentados en (Ban95; Kel98). Una manera fcil de funcionamiento para analizar un proceso es compararlo con una norma vigente (nacional, internacional o cuerpo profesional), como IEEE/EIA12207.0 [IEEE12207.0-96]. Con este enfoque, no hay datos cuantitativos recogidos en el proceso, o, si lo son, juegan un papel de apoyo. Los individuos que realizan el anlisis de la definicin del proceso utilizan sus conocimientos y capacidades para decidir qu cambios en el proceso potencialmente llevara a resultados convenientes del proceso. Los estudios observacionales tambin pueden proporcionar informacin til para la identificacin de mejoras en los procesos. (Agr99) Clasificacin ortogonal del defecto: es una tcnica que puede ser utilizada para conectar las fallas que se encuentran con las posibles causas. Se basa en una asignacin entre los tipos de fallas y provoca culpa. (Chi92; Chi96) El estndar de IEEE en la clasificacin de las fallas (o anomalas) pueden ser tiles en este contexto (el estndar IEEE para la Clasificacin de Software de anomalas (IEEE1044-93). Anlisis de Causa Raz es otra tcnica comn de anlisis que se utiliza en la prctica. Esto implica el seguimiento posterior de los problemas detectados (por ejemplo, fallos) para identificar las causas del proceso, con el objetivo de cambiar el proceso para evitar estos problemas en el futuro. Ejemplos de diferentes tipos de procesos se describen en (Col93; Ele97; Nak91). La tcnica de clasificacin de defectos ortogonal descrito anteriormente se puede utilizar para encontrar categoras en las que existen muchos problemas, momento en el que se pueden analizar. Clasificacin del defecto ortogonal es, pues, una tcnica utilizada para realizar una seleccin cuantitativa de dnde aplicar Anlisis de Causa Raz. Control Estadstico de Procesos: es una forma efectiva de identificar la estabilidad, o la falta de ella, en el proceso a travs del uso de grficos de control y sus interpretaciones. Una buena introduccin a SPC en el contexto de la ingeniera de software se presenta en un (Flo99). El Proceso Personal software define una serie de mejoras en las prcticas de desarrollo de un individuo en un determinado orden [Hum95]. Se trata de "abajo hacia arriba" en el sentido

102

de que establece la recogida de datos personales y de mejoras basadas en las interpretaciones de los datos.

9.4.5.2

Evaluacin comparativa de las tcnicas

El segundo tipo de tcnica, la evaluacin comparativa, "depende de la identificacin de un" excelente "la organizacin en un campo y documentar sus prcticas y herramientas." La evaluacin comparativa se supone que si una organizacin menos competente adopta las prcticas de la excelente organizacin, tambin se convertir en un excelente. Evaluacin comparativa incluye la evaluacin de la madurez de una organizacin o la capacidad de sus procesos. Esto es ejemplificado por el trabajo de evaluacin de software de proceso. Una visin general introductoria de las evaluaciones de proceso y su aplicacin se proporciona en (Zah98).

103

10 Mtodos y herramientas de ingeniera del software

Herramientas de desarrollo de software son las herramientas informticas que tienen como objeto ayudar a los procesos de desarrollo de software. Permite herramientas repetitivas, acciones bien definidas para ser automatizado, lo que reduce la carga cognitiva en el ingeniero de software que es libre para concentrarse en los aspectos creativos del proceso. Las herramientas son a menudo diseadas para ayudar en especial a los mtodos de ingeniera de software, reduciendo la carga administrativa asociada con alguna aplicacin de mtodo manual. Al igual que los mtodos de ingeniera de software, tiene como propsito sistematizar mas la ingeniera de software, que varan en alcance de apoyo a tareas individuales para que abarque el ciclo de vida completo. Los mtodos de ingeniera de software imponen una estructura sobre las actividades de ingeniera de software con el fin de hacer la actividad sistemtica y en ltima instancia con ms probabilidades de xito. Mtodos suelen proporcionar una notacin y el vocabulario, los procedimientos para realizar tareas de identificacin, y las directrices para el control tanto del proceso y del producto. Varan ampliamente en su alcance, de una fase del ciclo de vida nico para el ciclo de vida completo. El nfasis en este el Area de Conocimiento (AC) es sobre los mtodos de ingeniera de software que abarca mltiples fases del ciclo de vida, ya que los mtodos especficos de eliminacin son cubiertos por otros KAs. Si bien hay manuales detallados sobre las herramientas especficas y numerosos trabajos de investigacin sobre los instrumentos innovadores, genricos escritos tcnicos en las herramientas de ingeniera de software son relativamente escasos. Una primera dificultad es la alta tasa de cambio de herramientas de software en general. Los detalles especficos modificar regularmente, lo que hace difcil dar ejemplos concretos, hasta al da. Las herramientas y mtodos de ingeniera del software el Area de Conocimiento (AC) cubren el ciclo completo del proceso de vida y por lo tanto en relacin con todo el Area de Conocimiento (AC) en la gua. Las herramientas y mtodos de la ingeniera de software incluyen el Area de Conocimiento (AC) tanto en las herramientas de ingeniera de software como los mtodos de ingeniera de software Las herramientas de la ingeniera de software es una sub-rea que usa la misma estructura de esta gua, con un tema para cada uno de los otros nueve el Area de Conocimiento (AC) de ingeniera de software. Otra cuestin es que siempre: hay herramientas en diversas cuestiones, como herramienta de integracin de tcnicas, que son potencialmente aplicables a todas las clases de herramientas. Los mtodos de ingeniera de software es una sub-rea que esta dividida en cuatro subsecciones: mtodo heurstico se ocupa de los enfoques informales, mtodo formal se ocupa de enfoques basados matemticamente, y mtodos de prototipos que se basa en varias formas de prototipado.

104

11 Calidad de Software
SIGLAS MICM (CMMI) CEPS (COTS) PDCA ACS (SQA) GCS (SQM) GCT (TQM) VyV (V&V) Modelo integrado de capacidad y madurez Periodo comercial del software Planear, hacer, evaluar, actuar Aseguramiento de la calidad de software Gestin de la calidad del software Gestin de la calidad total Verificacin y validacin

INTRODUCCION Qu es la calidad del software y porque la calidad del software es tan importante y tan nombrada en la gua de SWEBOK? con el paso de los aos distintas organizaciones y autores han definido el trmino calidad de forma diferente. Para Phil crosby (Cro79) es la conformidad a las requerimientos de los usuarios. Para Watts humprey (Hum89) se refiere a ella como El logro de excelentes niveles de uso de aptitud mientras que para IBM era la tpica frase la calidad dirigida por el mercado que se basaba en lograr la satisfaccin completa del cliente. El criterio de Baldrige a la calidad de organizacin (NIST03) usaba una frase muy similar la calidad orientada el cliente e incluye la satisfaccin del cliente como primera prioridad. Ms recientemente, la calidad se ha definido en (ISO9001-00) como el grado en que un conjunto de caractersticas inherentes cumple requisitos. Este captulo trata con los asuntos de calidad del software que trascienden los procesos de ciclo de vida. La calidad de software es una preocupacin (un inters) ubicua en la ingeniera de software, y entonces tambin es considerado en mucho del KAS. En resumen en la gua SWEBOK se describe una determinada cantidad de maneras de alcanzar la calidad del software. Aunque Particularmente esta el rea de Conocimiento (AC) cubre las tcnicas bsicas, de aquellos que no necesitan la ejecucin del software mientras se evala. Sin embargo las tcnicas dinmicas estn cubiertas en el rea de Conocimiento (AC) de pruebas de software. Desglose de los temas de Calidad de Software

11.1 Fundamentos de calidad de software

Acuerdo sobre requisitos de calidad, as como la comunicacin clara con el ingeniero de software en la esencia de la calidad, exigir que los muchos aspectos de la calidad estn formalmente definidos y discutidos. Un ingeniero de software debe comprender los significados subyacentes de los conceptos de calidad sus caractersticas y valores, para el desarrollo o el mantenimiento de software. El concepto importante es que los requisitos de software definen las caractersticas de calidad requeridas para el software y la influencia de los mtodos de medicin y criterios de aceptacin para la evaluacin de estas caractersticas.

105

11.1.1

Cultura y tica en la Ingeniera de Software

Se espera de los ingenieros de software que tenga un compromiso con la calidad del software como parte de su cultura. Una cultura de ingeniera de software saludable es descrita en (Wie96). La tica puede desempear un papel significativo en la calidad del software, la cultura y las actitudes de los ingenieros de software. La IEEE computer society y el ACM (IEEE99) han desarrollado un cdigo de tica y prctica profesional basada en 8 principios para ayudar a los ingenieros de software a reforzar las actitudes relacionadas con la calidad y la independencia de su trabajo.

11.1.2

Valores y Costos de la calidad

(Boe78; NIST03;Pre04;Wei93) La nocin de Calidad no es tan simple como puede parecer. Para cualquier producto de la ingeniera, hay muchas cualidades deseadas de inters, para una perspectiva particular del producto, para ser discutidas y decididas en el momento en que los requisitos de los productos se definen. Las caractersticas de calidad pueden ser necesarias o no, o podr ser obligado a un mayor o menor grado y las compensaciones podrn hacerse entre ellos. (Pfl01) El coste de la calidad se puede diferenciar en los costes de la prevencin, evaluacin de costos, el costo de fallas internas y el costo de falla externa. (Hou99). Una de las motivaciones detrs de un proyecto de software es el deseo de crear un software que tiene valor y este valor puede o no puede cuantificarse como un costo. El cliente tendr algn costo mximo en cuenta, en cambio de lo cual se espera que el propsito bsico del software se cumpla. El cliente tambin puede tener algunas expectativas en cuanto a la calidad del software. A veces los clientes no pueden haber pensado a treves de los problemas de calidad o los costos relacionados. Es la caracterstica meramente decorativa, o es esencial para el software? Si la respuesta se encuentra en algn punto intermedio, como es casi siempre el caso, se trata de hacer al cliente parte del proceso de decisin y plenamente consciente de los costos y beneficios. Lo ideal sera que la mayora de estas decisiones se tomaran en el proceso de software necesario (Vase el rea de conocimiento de requerimientos de software), pero estos problemas pueden seguir a lo largo del ciclo de vida del software. No existe una regla de cmo estas decisiones se deben tomar, pero el ingeniero de software debe ser capaz de presentar alternativas de calidad y sus costos. Un debate sobre el costo y el valor de los requerimientos de calidad se puede encontrar en (Jon96: C5; Wei96:C11) CALIDAD DEL SOFTWARE FUNDAMENTOS CALIDAD SOFTWARE Cultura y tica en Ingeniera de Software DE DE la PROCESOS DE GESTION DE CALIDAD DE SOFTWARE Aseguramiento de calidad de Software Verificacin y Validacin Revisiones y Auditorias la CONSIDERACIONES PRACTICAS Requisitos de la Solicitud de Calidad Caracterizacin de defectos Tcnicas de Gestin de la Calidad de Software Medicin de la Calidad del Software

Relacin y costo de la Calidad Modelos y Caractersticas de Calidad Mejoramiento Calidad de la

Figura 1 Desglose de los Temas Para el KA Calidad del Software

106

11.1.3

Modelos y caractersticas de calidad

(DAC01;Kia95; Lap 91; LEW92; Mus99;NIST;PRE01;RAK97;Sei02;Wal96) La terminologa para las caractersticas de calidad del software difiere de una taxonoma (o modelo de calidad de software) a otro, tal vez cada modelo tiene un nmero diferente de niveles jerrquicos y un nmero total caractersticas diferentes. Varios autores han elaborado modelos de caractersticas o atributos de calidad del software que puede ser til para la discusin, planificacin y evaluacin de la calidad de los productos de software. (Boe78; McC77) ISO / IEC ha definido tres modelos relacionados con la calidad del producto de software (Calidad interna, la calidad externa y la calidad en uso) (ISO9126-01) y un conjunto de partes relacionadas (ISO14598-98).

11.1.3.1

Calidad del proceso de ingeniera del software

La Gestin de la calidad del software y el proceso de la calidad de ingeniera del software, tienen una influencia directa sobre la calidad del producto del software. Modelos y criterios que evalan las capacidades de las organizaciones de software son principalmente consideraciones de la gestin y la organizacin del proyecto y como tales, se contemplan en la el rea de gestin de ingeniera del software y el rea de proceso de ingeniera de software Por supuesto, no es posible distinguir por completo la calidad del proceso, desde la calidad del producto. La calidad de los procesos, discutidos en el rea de proceso de ingeniera de software de esta gua, influencian las caractersticas cualitativas de los productos de software, que a su vez afectan a la calidad en uso, segn lo percibido por el cliente. Dos normas de calidad son importantes (Ticklt Lio03) y una que tiene un impacto en la calidad del software es la norma (ISO 9001-00), junto con sus directrices para la aplicacin a software (ISO 90003-04). Otro estndar de la industria sobre la calidad de software es (CMMI (SEI02)), tambin se discute en el rea de procesos de ingeniera de software. CMMI tiene la intencin de proporcionar una gua para la mejora de procesos en las reas especficas relacionadas con el proceso de gestin de calidad son: (a) Aseguramiento de la calidad del proceso y del producto (b) La verificacin de proceso y (C) La validacin de proceso. CMMI clasifica las revisiones y las auditorias como mtodos de verificacin y no como procesos especficos como (IEEE 12207.096). Hubo inicialmente un cierto debate sobre si ISO 9001 o CMMI deben ser utilizados por los ingenieros de software para asegurar la calidad. Este debate ha sido ampliamente publicado y en consecuencia, se ha llegado a la conclusin que los dos son complementario y que la certificacin ISO 9001 puede ayudar enormemente en la obtencin de los niveles de madures ms alto de la CMMI.

11.1.3.2

Calidad de los Productos de Software

El ingeniero de software necesita, en primer lugar, determinar el propsito real del software . En este sentido, es de vital importancia tener en cuenta que los requerimientos del cliente son lo primero y que incluyan los requisitos de calidad, no solo los requerimientos funcionales. As, el ingeniero de software tiene la responsabilidad de obtener los requisitos de calidad que no puede ser explicito desde el principio y discutir su importancia, as como el nivel de dificultad en la obtencin de ellos. Todos los procesos asociados con la calidad del software (por ejemplo, la construccin, verificacin y mejora de la calidad) sern diseados con estos requisitos en mente y que conlleva costos adicionales. La Norma (ISO 9126-01) define, para dos de sus tres modelos de calidad las caractersticas d y las sub caractersticas de calidad, y medidas que son tiles para evaluar la calidad del producto de software. (SUR 03). El significado del trmino producto se amplia para incluir cualquier artefacto que es la salida de cualquier proceso que se utiliza para construir el producto de software final. Ejemplo de un producto incluyen, pero no limitado a: Una especificacin de requisito del sistema, una especificacin de software necesario para un componente de software de un sistema, un diseo de un modulo, cdigo, documentacin de las pruebas o reportes producidos como resultado de las tareas de anlisis de calidad. Aunque la mayora de tratamiento de calidad se describe en trminos del software final y el rendimiento

107

del sistema, en la prctica se requiere que los productos relevantes intermedios sean evaluados a lo largo del proceso de ingeniera de software.

11.1.4

Mejoramiento de la calidad

(NIST 03; PRE 04; WEI 96) La calidad de los productos de software se puede mejorar mediante un proceso iterativo de mejora continua que requiere control de la gestin, coordinacin, y retroalimentacin de muchos procesos en paralelo: (1) Los procesos del ciclo de vida del software, (2) los proceso de deteccion, eliminacin y prevencin de errores/defectos (3) El proceso de mejora de la calidad. (KIN 92) La teora y los conceptos detrs de mejora de calidad, tales como la construccin de la calidad a travs de la prevencin y deteccin temprana de errores, la mejora continua y orientacin al cliente, son pertinentes a la ingeniera de software. Estos conceptos se basan en el trabajo de los expertos en la calidad que han declarado que la calidad de un producto est directamente relacionada con la calidad del proceso utilizado para crearlo. (CRO79, DEM 86, JUR 89). Enfoques tales como la gestin de calidad total (TQM), procesos de planear, hacer, verificar y actuar (PHVA) son herramientas con las que los objetivos de calidad que pueden obtener. Gestin de patrocinio apoya el proceso y las evaluaciones del producto y las conclusiones resultantes. Entonces, un programa de mejora se desarrolla identificando las acciones detalladas y mejorando los proyectos que deben abordarse en un marco de tiempo factible. El apoyo a la gestin implica que cada proyecto de mejora tiene suficiente recursos para lograr el objetivo definido para ello. El Patrocinio de gestin debe ser solicitado con frecuencia por la ejecucin de actividades proactivas de comunicacin. La participacin de los grupos de trabajo, as como los medios de apoyo administrativo y los recursos asignados a nivel de proyectos, se discuten en el rea de proceso de ingeniera.

11.2 Procesos de Gestin de Calidad de Software

La Gestin de calidad de software (GCS), se aplica a todas las perspectivas de procesos de software, productos, recursos. Esto define procesos, propietarios de proceso, y exigencias para aquellos procesos, medidas del proceso y sus salidas, y canales de regeneracin. (Art93) Los procesos de Gestin de calidad de software consisten en muchas actividades. Algunos pueden encontrar defectos de forma directa, mientras que otros indican que el examen puede ser ms valioso. Estos ltimos tambin se conocen como actividades directas de investigacin de defectos. Muchas actividades a menudo sirven como ambos. La planificacin para la calidad de software implica: Definicin del producto requerido en trminos de sus caractersticas de calidad (descrito ms detalladamente en, por ejemplo, la Gestin de Ingeniera de Software KA) Planificacin de los procesos para alcanzar el producto requerido (descrito en, por ejemplo, el Diseo de Software y la Construccin de Software KAs). Estos aspectos se diferencian de, por ejemplo, la planificacin de procesos propios de SQM, que evalan las caractersticas de calidad planificadas contra la puesta en prctica real de aquellos proyectos. Los procesos de Gestin de calidad de software deben abordar como bien los productos de software, o hacer, satisfacer las necesidades de el cliente y partes interesadas, proporcionar el valor a los clientes y otras partes interesadas, y proporcionar la calidad del software necesaria para satisfacer los requisitos de software. SQM se puede utilizar para evaluar los productos intermedios, as como el producto final. Algunos de los procesos especficos de SQM son definidos en el estndar (IEEE12207.0-96): Proceso de aseguramiento de calidad Proceso de verificacin

108

Proceso de validacin Proceso de revisin Proceso de auditoria

Estos procesos fomentan la calidad y tambin encuentran posibles problemas. Sin embargo, difieren un tanto en su nfasis. La ayuda de procesos de SQM garantiza una mejor calidad de software en un proyecto determinado. Ellos tambin ofrecen, como un subproducto, la informacin a la gestion, incluyendo una indicacin de la calidad del proceso de ingeniera de software completo. El Proceso de Ingeniera de Software y la gestin de Ingeniera de Software KAs hablan de programas de calidad para la organizacin que desarrolla el software. SQM puede proporcionar informacin relevante para estas reas. Los procesos de SQM consisten en tareas y tcnicas para indicar como proyectos de software (por ejemplo, la gestion, el desarrollo, la gestin de configuracion) est siendo puesto en prctica y tambien los productos intermedios y finales cumplen con sus requisitos especificadas. Los resultaodos de estas tareas son montados en informes para la gestion antes de que la accin correctiva sea tomada. La gestin de un proceso de SQM se encarga de garantizar que los resultados de estos informes son exactos. Como se describe en este KA, los procesos de SQM estn estrechamente relacionados, ya que pueden superponerse e incluso a veces se combinan. Ellos parecen en gran parte reactivos de naturaleza porque dirigen los procesos tan expertos y los productos tal como se producen; pero ellos tienen un papel principal en la etapa de planificacin en ser proactivos en trminos de los procesos y los procedimientos necesarios para alcanzar los niveles de calidad y el grado de calidad que necesitan los interesados en el software. La gestin de riesgos tambin puede jugar un papel importante en el suministro de calidad de software. La incorporacin de anlisis disciplinado de riesgos y tcnica de gestin en los procesos de ciclo de vida del software puede aumentar el potencial de producir un producto de calidad (Cha89). Consulte la Gestin de Ingeniera del Software KA para el material relacionado sobre la gestin de riesgo.

11.2.1

Aseguramiento de la Calidad de Software

[Ack02; Ebe94; Fre98; Gra92; Hor03; Pfl01; Pre04; Rak97; Sch99; Som05; Voa99; Wal89; Wal96]. SQA, Procesos que garantizan el aseguramiento de los productos de software y procesos en el ciclo de vida del proyecto, se ajusten a sus necesidades especificadas por la planificacin, la promulgacin, realizando una serie de actividades para proporcionar la confianza adecuada de que la calidad est siendo construida en el software. Esto quiere decir asegurar de forma clara el problema y que estn debidamente declarados y que los requisitos de la solucin estn bien definidas y expresadas. SQA busca mantener la calidad durante todo el desarrollo y el mantenimiento del producto por la ejecucin de una variedad de actividades en cada etapa que puede resultar en la identificacin temprana de problemas, una caracterstica casi inevitable de cualquier actividad compleja. El papel de SQA con respecto al proceso es asegurar que los procesos previstos sean adecuados y ms tarde ejecutado de acuerdo con el plan, y que los procesos de medicin pertinentes se proporcionan a la organizacin correspondiente.

109

El plan de SQA define los medios que se utilizarn para asegurar que el software desarrollado para un determinado producto cumple los requisitos del usuario y de la ms alta calidad posible dentro de las limitaciones del proyecto. Para hacer as, primero debe asegurarse de que el objetivo de calidad est claramente definido y entendido. Se debe considerar la gestin, el desarrollo y proyectos de mantenimiento para el software. Referencia al estndar (IEEE730-98) para ms detalles. Las actividades especficas de calidad y las tareas son presentadas, con sus costos y las exigencias de recursos, sus objetivos de manejo, y su horario en relacin con los objetivos en la gestin de ingeniera de software, el desarrollo o proyectos de mantenimiento. El plan de SQA debe ser coherente con el plan de gestin de la configuracin de software (vase la Gestin de Configuracin de Software KA). El plan de SQA identifica los documentos, normas, prcticas y convenciones que rigen el proyecto y cmo ellos sern controlados y supervisados para garantizar la suficiencia y cumplimiento. El plan de SQA tambin identifica medidas, tcnicas estadsticas, los procedimientos para reportar problemas y medidas correctivas, los recursos tales como herramientas, tcnicas y metodologas, la seguridad para medios de comunicacin fsicos, formacin y generacin de informes y la documentacin SQA. Por otra parte, el plan de SQA dirige las actividades de aseguramiento de la calidad del software de cualquier otro tipo de actividad descrita en los proyectos de software, como la contratacin de proveedores de software para el proyecto de instalacin o software comercial fuera de la plataforma de software (COTS), y el servicio despus de la entrega de el software. Esto tambin puede contener los criterios de aceptacin, as como actividades de informacin y gestin que son crticos para la calidad del software.

11.2.2

Verificacin y Validacin

[Fre98; Hor03; Pfl01; Pre04; Som05; Wal89; Wal96] Para los objetivos de brevedad, Verificacin y Validacin (V*V) son tratadas como un solo tema en esta gua y no como dos temas separados, como en el estndar (IEEE12207.0-96). "Software de V & V es un enfoque disciplinado para evaluar los productos de software en todo el ciclo de vida del producto. Un esfuerzo de V & V, se esfuerza por asegurar que la calidad es construida en el software y que el software satisface las necesidades del usuario " (IEEE105993). V & V se ocupa directamente de la calidad del producto software y utiliza tcnicas de prueba que puede localizar defectos para que puedan ser tratados. Tambin evala el producto intermedio, sin embargo, y, en esta capacidad, los pasos intermedios de los procesos del ciclo de vida del software. El proceso de V & V determina si realmente o no los productos de un desarrollo o una actividad de mantenimiento se ajustan a la exigencia de la actividad, y si es o no el producto de software que cumple con su propsito y cumple con los requisitos del usuario. La verificacin es un intento de garantizar que el producto se construye correctamente, en el sentido de que los productos de salida de una actividad cumplen con las especificaciones que se les imponen en las actividades anteriores. La validacin es un intento de garantizar que el producto se construye, es decir, el producto cumple con su finalidad especfica. Tanto el proceso de verificacin y el proceso de validacin comienzan temprano en la fase de desarrollo o mantenimiento. Proporcionan un examen de las caractersticas claves del producto en relacin tanto con antecedentes inmediatos del producto y las especificaciones que deben cumplir. El propsito de la planificacin de V & V es asegurar que cada recurso, el papel y la responsabilidad son claramente asignados. El resultado de V & V Plan de documentos y describe los diversos recursos y sus funciones y actividades, as como las tcnicas y herramientas que se utilizarn. La comprensin de las distintas finalidades de cada actividad de V & V le ayudar en la planificacin cuidadosa de las tcnicas y los recursos necesarios para cumplir sus

110

propsitos. Normas (IEEE1012-98: S7 y IEEE1059 93: Apndice A) especificar lo que normalmente entra en un plan de V & V. El plan tambin se ocupa de la gestin, la comunicacin, polticas y procedimientos de las actividades de V & V y su interaccin, as como la presentacin de informes de defectos y los requisitos de documentacin.

11.2.3

Revisiones y Auditorias

Para los propsitos de la brevedad, las revisiones y auditoras son tratados como un solo tema en esta gua, en lugar de dos temas separados, como en (IEEE12207.0-96). La revisin y proceso de auditora es ampliamente definida en (IEEE12207.0-96) y en ms detalle en (IEEE1028-97). Cinco tipos de revisiones o auditoras se presentan en el IEEE1028-97 estndar: Revisiones por la administracin Revisiones tcnicas Inspecciones Tutoriales Auditoras

11.2.3.1

Revisiones de gestin

"El propsito de un examen de la administracin es seguir la evolucin, determinar el estado de los planes y programas, confirmar los requisitos y su distribucin en el sistema, o evaluar la eficacia de la gestin de los enfoques utilizados para lograr la adecuacin a un fin" [IEEE102897]. Apoyan las decisiones sobre los cambios y las acciones correctivas que se requieren durante un proyecto de software. Revisin de administracin de determina la adecuacin de los planes, programas, y los requisitos y supervisa su progreso o inconsistencias. Estos exmenes se pueden realizar sobre los productos tales como los informes de auditora, informes de situacin, informes de V & V, y los planes de muchos tipos, incluyendo la gestin de riesgos, gestin de proyectos, gestin de configuracin de software, la seguridad del software, y la evaluacin de riesgos, entre otros. Consulte a la Direccin de Ingeniera del Software y el KAs el material relacionado con la gestin de configuracin de software.

11.2.3.2

Revisiones tcnicas

[Fre98; Hor03; Lew92; Pfl01; Pre04; Som05; Voa99; Wal89; Wal96] "El propsito de una revisin tcnica es evaluar un producto de software para determinar su idoneidad para el uso previsto. El objetivo es identificar las discrepancias de las especificaciones y normas aprobadas. Los resultados deben proporcionar a la direccin pruebas que confirmen (o no) que el producto cumple con las especificaciones y se adhiere a las normas, y que los cambios son controlados " (IEEE1028-97). Funciones especficas deben estar establecidos en una revisin tcnica: una toma de decisiones, un lder de revisin, una grabadora, y el personal tcnico para apoyar las actividades de examen. Una revisin tcnica requiere que los insumos obligatorios estn en su lugar a fin de proceder: Declaracin de objetivos Un producto de software especfico Gestin de proyecto de plan especfico La lista de temas relacionados con este producto El procedimiento de revisin tcnica

El equipo sigue el procedimiento de revisin. Un individuo tcnicamente calificado presenta una visin general del producto, y el examen se lleva a cabo durante una o ms reuniones. El examen tcnico se completa una vez que todas las actividades enumeradas en el examen se han completado.

111

11.2.3.3

Inspecciones

[Ack02; Fre98; Gil93; Rad02; Rak97] "La finalidad de la inspeccin es detectar e identificar anomalas de productos de software" (IEEE1028-97). Dos diferenciadores importantes de las inspecciones en contraposicin a los exmenes son los siguientes Un individuo que ocupa una posicin de gestin de ningn miembro del equipo de inspeccin no participar en la inspeccin. La inspeccin debe ser dirigido por un mediador imparcial que est entrenado en tcnicas de inspeccin.

Inspecciones de software implican siempre el autor de un producto intermedio o final, mientras que en los otros no. Las inspecciones tambin incluyen un lder de la inspeccin, la grabadora, un lector, y unos pocos (2-5) los inspectores. Los miembros de un equipo de inspeccin puede poseer conocimientos diferentes, tales como experiencia en el campo, mtodo de diseo experiencia o conocimientos lingsticos. Las inspecciones se realizan normalmente en una parte relativamente pequea del producto a la vez. Cada miembro del equipo debe examinar el software producto y otros insumos de revisin antes de la reunin de examen, tal vez mediante la aplicacin de una tcnica analtica (consulte la seccin 3.3.3) a una pequea seccin del producto, o a todo el producto con un enfoque slo en un aspecto, por ejemplo, las interfaces. Cualquier anomala detectada se documenta y se enva al jefe de inspeccin. Durante la inspeccin, el jefe de inspeccin realiza la sesin y verifica que todo el mundo ha preparado para la inspeccin. Una lista de verificacin, con anomalas y preguntas germano a las cuestiones de inters, es una herramienta comn utilizada en las inspecciones. La lista resultante a menudo se clasifica a las anomalas (ver IEEE1044-93 para ms detalles) y se revisa para exhaustividad y precisin por el equipo. La decisin de salir de inspeccin debe corresponder a uno de los tres criterios siguientes: Aceptar sin volver a trabajar o en la mayora de menores Aceptar con la verificacin de reproceso Vuelva a inspeccionar

Las Reuniones de inspeccin suelen durar unas horas, mientras que las revisiones tcnicas y las auditoras son por lo general ms amplias en su alcance y toman ms tiempo.

11.2.3.4

Tutoriales

[Fre98; Hor03; Pfl01; Pre04; Som05; Wal89; Wal96] "El propsito de un tutorial es evaluar un producto de software. Un tutorial puede ser realizado con el propsito de educar a una audiencia en relacin con un producto de software " (IEEE1028-97) Los objetivos principales son [IEEE1028-97]: Buscar anomalas. Mejorar el producto de software. Considerar la posibilidad de implementaciones alternativas. Evaluar la conformidad con las normas y especificaciones.

El tutorial es similar a una inspeccin, pero se suele realizar de manera menos formal. El tutorial, organizado esencialmente por el ingeniero de software para dar a sus compaeros de equipo la oportunidad de revisar su trabajo, como una tcnica de aseguramiento.

112

11.2.3.5

Auditoras

[Fre98; Hor03; Pfl01; Pre01; Som05;Voa99; Wal89; Wal96] "El propsito de una auditora de software es proporcionar una evaluacin independiente de la conformidad de los productos de software y los procesos a la normativa aplicable, normas, directrices, planes y procedimientos " [IEEE1028-97]. La auditora es una actividad organizada formalmente, con los participantes que tienen funciones especficas, tales como auditor principal, otro auditor, un grabador o un iniciador, e incluye un representante de la organizacin auditada. La auditora determinar los casos de no conformidad y elaborara un informe que requiere el equipo para tomar medidas correctivas. Si bien puede haber muchos nombres oficiales para los exmenes y auditoras, como las sealadas en la norma (IEEE1028-97), el punto importante es que pueden ocurrir en casi cualquier producto en cualquier etapa del desarrollo o proceso de mantenimiento.

11.3 Consideraciones prcticas 11.3.1 Requisitos de calidad de software

[Hor03; Lew92; Rak97; Sch99; Wal89; Wal96]

11.3.1.1

Factores de influencia

Varios factores influyen en la planificacin, gestin y seleccin de las tcnicas y actividades de SQM, incluyendo: El dominio del sistema en el cual el software residir (de seguridad crtica, de misin crtica, crucial) Requisitos del sistema y del software Los componentes comerciales (externos) o estndares (internos) para ser usados en el sistema Las normas especficas aplicables de ingeniera de software Los mtodos y herramientas de software que se utilizar para el desarrollo y mantenimiento y para la evaluacin de la mejora de la calidad El presupuesto, el personal, organizacin de proyecto, planes, y la planificacin de todos los procesos Los usuarios previstos y el uso del sistema El nivel de integridad del sistema

La informacin sobre estos factores influye en cmo los procesos de SQM son organizados y documentados, como las, actividades especficas de SQM se seleccionan, qu recursos se necesitan, y que se impongan lmites a los esfuerzos.

11.3.1.2

Fiabilidad

En los casos en que un fallo del sistema puede tener consecuencias muy graves, la fiabilidad general (el hardware, el software y los humanos) es la principal exigencia de calidad por encima de la funcionalidad bsica. la fiabilidad del software incluye caractersticas tales como tolerancia a fallos, seguridad y la utilidad. La fiabilidad es tambin un criterio que puede ser definido en trminos de confiabilidad (ISO9126). El cuerpo de la literatura para los sistemas debe ser altamente confiable (" la alta confianza" o "sistemas de alta integridad"). La terminologa para los sistemas tradicionales mecnicos y elctricos que no pueden incluir el software ha sido importada para discutir las amenazas o peligros, los riesgos, la integridad del sistema, y los conceptos relacionados, y se puede encontrar en las referencias citadas para esta seccin.

113

11.3.1.3

Niveles de integridad de software

El nivel de integridad se determina sobre la base de las posibles consecuencias de la falla del software y la probabilidad de fracaso. Para el software en el que la seguridad es importante, las tcnicas tales como anlisis de riesgos para la seguridad o el anlisis de amenaza, para la seguridad, puede ser utilizado para desarrollar una actividad de planificacin que servirn para identificar donde se encuentran posibles reas problemticas. Similar al historial de fallos de software, tambin puede ayudar en la identificacin de cuales tcnicas sern ms tiles en el descubrimiento de fallas y evaluacin de la calidad. Los niveles de Integridad proponen (por ejemplo, la sucesin de la integridad) en (IEEE1012-98).

11.3.2

Caracterizacin de Defectos

[Fri95; Hor03; Lew92; Rub94; Wak99; Wal89] Los procesos SQM encuentran defectos. La caracterizacin de defectos conduce a una comprensin del producto, facilita las correcciones al proceso o el producto, e informa a la gestin de proyectos o al cliente del estado del proceso o producto. Muchos defectos (fallos) las taxonomas existentes, y, si bien se han hecho intentos para obtener un consenso sobre una taxonoma de fallas y fracaso, la literatura indica que hay unos cuantos en el uso de [Bei90, Chi96, Gra92], IEEE1044-93) La caracterizacin de defectos (anomalas) tambin se utiliza en las auditoras y revisiones, El lder de revisin a menudo presenta una lista de anomalas proporcionada por los miembros del equipo para su examen en una reunin de revisin. Cmo evolucionan nuevos mtodos de diseo y lenguajes, junto con los avances en tecnologas de software en general, aparecen nuevos tipos de fallas, esto requiere una gran cantidad de esfuerzo para interpretar las clases definidas previamente. Cuando se le hace seguimiento a los fallos, el ingeniero de software est interesado no slo en el nmero de fallos, sino tambin en los tipos. Por s sola la informacin, sin una clasificacin, no es realmente de alguna utilidad en la identificacin de las causas de los fallos, ya que determinados tipos de problemas deben ser agrupados con el fin de realizar determinaciones sobre ellos. El punto es establecer una taxonoma de fallos que sea significativo para la organizacin y los ingenieros de software. SQM descubre la informacin en todas las etapas de desarrollo y mantenimiento de software. Por lo general, donde la palabra "defecto" se utiliza, se refiere a una "falla", como se define a continuacin. Sin embargo, las diferentes culturas y normas podrn utilizar significados algo diferentes para estos trminos, que han llevado a los intentos de definirlos. Definiciones parciales adoptadas de la norma (IEEE610.12-90) son los siguientes: Error: " una diferencia... entre el resultado calculado y el resultado correcto". Fallo: "Un paso incorrecto, proceso, o de definicin de datos en un programa de ordenador". Fracaso: "El resultado [incorrecto] de un fallo". Equivocacin: "Una accin humana que produce un resultado incorrecto".

Los fracasos que se encuentran en la prueba como consecuencia de fallos de software se incluyen como defectos en la discusin en esta seccin. Los modelos de fiabilidad se construyen a partir de datos recogidos de fracasos durante las pruebas de software o desde el software en servicio, y por lo tanto pueden ser utilizados para predecir futuros fracasos y ayudar en las decisiones sobre cundo dejar de probar. [Mus89]. Una accin probable resultado de las conclusiones de SQM es eliminar los defectos del producto objeto en el examen. Otras acciones permiten el logro de todo el valor de los resultados de las actividades de SQM. Estas acciones incluyen el anlisis y resumen de los resultados, y el uso de tcnicas de medicin para mejorar el producto y el proceso, as como para realizar un seguimiento de los defectos y su eliminacin. La mejora de procesos se

114

discuten principalmente en el Proceso de Ingeniera de Software KA, siendo una fuente de informacin el proceso de SQM. Los datos sobre las insuficiencias y los defectos encontrados durante la aplicacin de las tcnicas de SQM podra perderse si no se registran. Para algunas tcnicas (por ejemplo,revisiones tcnicas, auditoras e inspecciones), los registradores estn presentes para establecer dicha informacin, junto con las publicaciones y decisiones. Cuando se utilizan herramientas automticas, el instrumento salida puede proporcionar la informacin defecto. Los datos sobre los defectos pueden ser recogidos y registrados en un SCR (solicitud de cambio de software) se forma y puede ser posteriormente ingresado en algn tipo de base de datos, ya sea manualmente o automticamente, a partir de una herramienta de anlisis Los informes sobre fallos son proporcionados a la direccin de la organizacin.

11.3.3

Tcnicas de Gestin de la Calidad del Software

[Bas94; Bei90; Con86; Chi96; Fen97; Fri95; Lev95; Mus89; Pen93; Sch99; Wak99; Wei93; Zel98] Las tcnicas de SQM se pueden clasificar de muchas maneras: Esttica, uso Intensivo de Personas, analtico y dinmico.

11.3.3.1

Tcnicas Estticas

Incluye un examen de la documentacin del proyecto y el software, y otra informacin sobre los productos de software sin ejecutarlas. Estas tcnicas pueden incluir actividades de uso Intensivo de Personas (Como se define en el punto 3.3.2.) o actividades de anlisis (como se define en el punto 3.3.3.), realizado por personas, con o sin la asistencia de herramientas automatizadas.

11.3.3.2

Tcnicas de uso Intensivo de Personas

El ajuste de las Tcnicas de uso Intensivo de Personas, incluidas las revisiones y auditorias, pueden variar de una reunin formal a una reunin informal o una situacin de comprobacin de escritorio, pero (por lo general, por lo menos) dos o ms personas estn involucradas. La preparacin antes de tiempo puede ser necesaria. Los recursos que no sean los artculos de objetos de examen pueden incluir listas de comprobacin y los resultados de las tcnicas analticas y pruebas de los recursos. Estas actividades sobre exmenes y auditorias se describen en (IEEE 1028-97). [Fre98, Hor03] y [Jon96, Rak97]

11.3.3.3

Tcnicas analticas:

Un ingeniero de software generalmente aplica tcnicas analticas. A veces varios ingenieros de software usan la misma tcnica, pero cada uno lo aplica a las partes diferentes del producto. Algunas tcnicas son conducidas por instrumento; los otros son manuales. Unos pueden encontrar defectos directamente, pero ellos tpicamente son usados apoyar otras tcnicas. Unos tambin incluyen varias evaluaciones como la parte de anlisis de calidad total. Los ejemplos de tales tcnicas incluyen el anlisis de complejidad, anlisis de control de flujo y el anlisis algortmico. Cada tipo de anlisis tiene un propsito especfico, y no todos los tipos se aplican a cada proyecto. Un ejemplo de una tcnica de apoyo es el anlisis de la complejidad, que es til para determinar si el diseo o la implementacin es demasiado compleja para su correcto desarrollo, para poner a prueba, o mantener. Los resultados de un anlisis de la complejidad se pueden tambin utilizar en el desarrollo de casos de prueba. Tcnicas de bsqueda de defectos, tales como el anlisis de control de flujo, tambin se puede utilizar para apoyar a otra actividad. Para el software con muchos algoritmos, anlisis algortmico es importante, especialmente cuando un algoritmo incorrecto puede causar un resultado catastrfico. Existen demasiadas tcnicas analticas como para mencionarlos todos aqu. La lista y las referencias siempre pueden ofrecer ideas sobre la seleccin de una tcnica, as como sugerencias para la lectura adicional.

115

Otros, ms formal, los tipos de tcnicas analticas que se conoce como mtodos formales. Se utilizan para verificar los requisitos de software y diseos. La prueba de la correccin se aplica a las zonas crticas de software. Se han utilizado principalmente en la verificacin de las piezas fundamentales de los sistemas crticos, tales como la seguridad y los requisitos especficos de seguridad.

11.3.3.4

Tcnicas dinmicas

Diferentes tipos de tcnicas dinmicas se realizan durante todo el desarrollo y mantenimiento de software. En general, se trata de las pruebas tcnicas, pero las tcnicas como la simulacin, verificacin de modelos, y la ejecucin simblica puede ser considerada dinmica. La lectura del Cdigo se considera una tcnica esttica, pero los ingenieros de software con experiencia pueden ejecutar el cdigo a medida que leen a travs de l. En este sentido, la lectura de cdigo tambin se puede calificar como una tcnica dinmica. Esta discrepancia en la categorizacin indica que las personas con diferentes roles en la organizacin puede considerar y aplicar estas tcnicas de forma diferente. Algunas pruebas de lo que se puede realizar en el proceso de desarrollo, proceso de SQA, o proceso de V & V, una vez ms en funcin de la organizacin del proyecto, como pruebas de direccin de proyectos de SQM, esta seccin incluye algunos comentarios durante las pruebas. El software que prueba KA proporciona la discusin y referencias tcnicas a la teora, las tcnicas para las pruebas, y la automatizacin.

11.3.3.5

Pruebas

Los procesos de aseguramiento descritos en SQA y V*V examinan cada producto en relacin con la especificacin de requisitos de software para garantizar la capacidad de rastreo de la produccin, la consistencia, integridad, exactitud y rendimiento. Esta confirmacin tambin incluye los resultados de los procesos de desarrollo y mantenimiento, recogida, anlisis y medicin de los resultados. SQA se asegura de que los tipos adecuados de las pruebas sean planificados, desarrollado e implementado, y V & V desarrolla proyectos de prueba, las estrategias, casos y procedimientos. Las pruebas se analizan en detalle en el KA de pruebas de software. Dos tipos de pruebas pueden caer en el inicio de SQA y V & V, debido a su responsabilidad por la calidad de los materiales utilizados en el proyecto: Evaluacin y prueba de herramientas que se utilizarn en el proyecto (IEEE1462-98) Prueba de conformidad (o la revisin de pruebas de conformidad) de componentes y productos COTS para ser utilizado en el producto, ahora existe un estndar para los paquetes de software (IEEE1465-98) A veces, una organizacin independiente de V & V se le puede pedir para supervisar el proceso de prueba y, a veces a presenciar la ejecucin real para garantizar que se lleve a cabo conforme con los procedimientos establecidos. Una vez ms, de V & V pueden ser llamados a evaluar la prueba en s: la adecuacin de los planes y procedimientos, y la suficiencia y exactitud de los resultados. Otro tipo de pruebas que puedan caer bajo el ttulo de la organizacin de V & V es la prueba de terceros. El tercero no es el desarrollador, ni es de ninguna manera asociados con el desarrollo del producto. En cambio, el tercero es un servicio independiente, por lo general acreditados por algn organismo de la autoridad. Su propsito es poner a prueba un producto para el cumplimiento de un conjunto especfico de requerimientos.

11.3.4

Medicin de la Calidad del Software

Los modelos de calidad de productos de software a menudo incluyen medidas para determinar el grado de cada caracterstica de calidad alcanzado por el producto. Si se seleccionan adecuadamente, las medidas pueden apoyar la calidad del software (entre otros aspectos de los procesos del ciclo de vida del software) de mltiples maneras. Ellos

116

pueden ayudar en el proceso de gestin de la toma de decisiones. Se pueden encontrar reas problemticas y los cuellos de botella en el proceso de software, y pueden ayudar a los ingenieros de software a evaluar la calidad de su trabajo para objetivos de SQA y para la mejora de procesos de calidad a largo plazo. Con la creciente sofisticacin del software, las cuestiones de calidad van ms all de si realmente el software funciona bien a como se logren las metas medibles de calidad. Hay algunos temas ms que la medicin de SQM apoya directamente. Estos incluyen la asistencia para decidir cundo debe dejar de probar. Para ello, los modelos de fiabilidad y puntos de referencia, tanto de defecto y utilizacin de datos de fracaso, son tiles. El costo de los procesos de SQM es un tema que casi siempre se plantea en la decisin de cmo un proyecto debe ser organizado. A menudo, se utilizan en los modelos genricos de costes, que se basan, en cuando se encuentra un defecto y cunto esfuerzo se necesita para corregir el defecto, en relacin con la constatacin del defecto temprano en el proceso de desarrollo. Datos del proyecto puede dar una idea ms clara de los costos. La discusin sobre este tema puede encontrarse en [Rak97: pp 39-50]. Informacin relacionada se puede encontrar en el Proceso de Ingeniera de Software y Gestin de Ingeniera del Software KAs. Por ltimo, los informes de SQM proporcionan valiosa informacin no slo sobre estos procesos, sino tambin de cmo todos los procesos de ciclo de vida del software se pueden mejorar. Los debates sobre estos temas se encuentran en [McC04] y (IEEE1012-98). Si bien las medidas para las caractersticas de calidad y las caractersticas de produccin pueden ser til en ellos (por ejemplo, el nmero de exigencias defectuosas o la proporcin de exigencias defectuosas) tcnicas matemticas y graficas pueden ser aplicadas para ayudar en la interpretacin de las medidas. Estos sistemas se adaptan a las siguientes categoras y se discuten en [Fen97, Jon96, Kan02, Lyu96, Mus99]. De base estadstica (por ejemplo, anlisis de Pareto, diagramas de ejecucin, diagramas de dispersin, distribucin normal). Las pruebas estadsticas (por ejemplo, la prueba binomial, prueba de ji cuadrado). Anlisis de tendencias. Prediccin (por ejemplo, modelos de fiabilidad). Las tcnicas de base estadstica y las pruebas a menudo proporcionan una imagen de las reas ms problemticas del producto de software en el examen. Las tablas y las grficas resultantes son los artculos de visualizacin que los tomadores de decisiones pueden utilizar para concentrar los recursos en las que parecen son ms necesarios. Los resultados de los anlisis de tendencias pueden indicar que un apndice no se ha respetado, como en las pruebas, o que ciertas clases de defectos se har ms intensa a menos que se tomen medidas correctivas en el desarrollo. Las tcnicas de prediccin ayudan en la planificacin del tiempo de prueba y en la prediccin de fracaso. Ms discusiones sobre la medicin en general aparecen en el Proceso de Ingeniera de Software y en la Gestin de Ingeniera del Software. Informacin ms especfica sobre la medicin de las pruebas se presenta en el KA de pruebas de software. Las referencias [Fen97, Jon96, Kan02, Pfl01] proporcionan debates sobre el anlisis de defecto, que consiste en medir presencias de defecto y luego aplicar mtodos estadsticos para la comprensin de los tipos de los defectos que se producen con mayor frecuencia, es decir contestando a preguntas para evaluar su densidad. Tambin ayuda en la comprensin de las tendencias y lo bien que las tcnicas de deteccin trabajan, el desarrollo y los procesos de mantenimiento estn progresando. La medicin de la cobertura de la prueba ayuda a estimar la cantidad de esfuerzo de la prueba que queda por hacer, y para predecir los posibles defectos restantes. A partir de estos mtodos de medicin, los perfiles de defecto pueden ser desarrollados para un dominio de aplicacin especfico. Entonces, para el siguiente sistema de software dentro de esa organizacin, los perfiles se pueden utilizar para guiar los procesos de SQM, es decir, hacer el esfuerzo, donde los problemas son ms probables que ocurran.

117

Del mismo modo, los puntos de referencia, o el recuento de defectos tpicos de ese dominio, puede servir como una ayuda para determinar si el producto est listo para la entrega. Discusin sobre el uso de datos del SQM para mejorar los procesos de desarrollo y mantenimiento aparece en la Gestin de Ingeniera del Software y en el Proceso de Ingeniera de Software KAs.

118

12 Disciplinas relativas a la Ingeniera del software

119