1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ACRNIMOS

CAPTULO 8 GESTIN DE LA INGENIERA DEL SOFTWARE

PMBOK Gua al Proyecto de Gestin del Cuerpo de Conocimientos SQA Garanta de Calidad del Software INTRODUCCIN La Gestin de la Ingeniera del Software puede definirse como la aplicacin para actividades de gestin planificacin, coordinacin, mediciones, monitoreo, control e informes que asegure un desarrollo y mantenimiento del software sistemtico, disciplinado y cuantificado (IEEE610.12-90). El KA de Gestin de la Ingeniera del Software, por tanto, se encarga de la gestin y medicin de la ingeniera del software. A pesar de que medir es un aspecto importante en todas las KAs, no es hasta aqu que se presenta el tema de programas de medicin. Aunque por una parte sea verdad afirmar que, en cierto sentido, debiera ser posible gestionar la ingeniera del software de la misma manera que cualquier otro proceso (complejo) existen aspectos especficos de los productos software y de los procesos del ciclo de vida del software que complican una gestin efectiva slo algunos de los cuales se apuntan a continuacin: La percepcin de los clientes es tal que con frecuencia existe una falta de aprecio de la complejidad inherente a la ingeniera del software, particularmente en relacin al impacto que produce cambiar los requisitos. Es casi inevitable que los propios procesos de ingeniera del software generen la necesidad de nuevos o modificados requisitos del cliente. Como resultado, el software se construye con frecuencia mediante un proceso iterativo en vez de mediante una secuencia de tareas cerradas. La ingeniera del software incorpora necesariamente aspectos de creatividad y de disciplina mantener un balance apropiado entre los dos es con frecuencia difcil. El grado de novedad y de complejidad del software son con frecuencia extremadamente altos. La tasa de cambio de la tecnologa subyacente es muy rpida.

Con respecto a la ingeniera del software, las actividades de gestin tienen lugar en tres niveles:

55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

gestin organizacional y de infraestructura, gestin de proyectos, y programa de planificacin y control de mediciones. Estos dos ltimos se cubren con ms detalle en la descripcin de este KA. A pesar de todo, esto no va en detrimento de la importancia de los temas de gestin organizacional. Dado que la unin con las disciplinas sealadas obviamente, la de gestin es importante, se describir con ms detalle que las otras descripciones del KA. Los aspectos de gestin organizacional son importantes en trminos de su impacto sobre la ingeniera del software en gestin de polticas, por ejemplo: polticas organizativas y estndares que proporcionan el marco en el que se desenvuelve la ingeniera del software. Puede que se necesite que estas polticas se vean afectadas por los requisitos de un software de desarrollo y mantenimiento efectivo, y puede que se necesite establecer un nmero de polticas especficas de ingeniera del software para una gestin eficaz de la ingeniera del software a nivel organizacional. Por ejemplo, normalmente se necesitan polticas para establecer procesos especficos a nivel organizacional o procedimientos para tareas de ingeniera del software tales como el diseo, la implementacin, la estimacin, el seguimiento y los informes. Tales polticas son esenciales, por ejemplo, para una gestin de la ingeniera del software eficaz a largo plazo, ya que establecen una base consistente sobre la que analizar actuaciones anteriores e implementar mejoras. Otro aspecto importante de la gestin es la gestin del personal: las polticas y procedimientos para contratar, entrenar y motivar al personal y actuar como mentor del desarrollo de una carrera son importantes no slo a nivel de proyecto sino tambin para el xito a largo plazo de una organizacin. Todo el personal de desarrollo del software puede haber sido entrenado del mismo modo o puede presentar retos para la gestin del personal (por ejemplo, mantener el capital en un contexto en el que la tecnologa subyacente sufre cambios continuos y rpidos). Con frecuencia tambin se menciona la gestin de la comunicacin como un aspecto pasado por alto pero importante de la actuacin de los individuos en un campo en el que es necesario un entendimiento preciso de las necesidades del usuario y de los complejos, requisitos y diseos. Finalmente, es necesaria la gestin de la cartera de trabajo, que es la capacidad de tener una visin general, no slo del conjunto del software en desarrollo sino tambin del software que ya se est utilizando en la organizacin. Ms an, la reutilizacin del software es un factor

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

clave en el mantenimiento y mejora de la productividad y competitividad. Una reutilizacin eficaz requiere una visin estratgica que refleje el poder nico y los requisitos de esta tcnica. Los ingenieros del software deben entender los aspectos de gestin que se encuentran influidos de modo singular por el software, y adems conocer sus aspectos ms generales, incluso en los primeros cuatro aos tras graduarse, como est marcado en la Gua. La cultura y comportamiento organizacionales y la gestin comercial funcional en trminos de consecucin de metas, aportan la gestin en cadena, la publicidad, la ventas y la distribucin, todas ellas influyen, aunque sea indirectamente, en el proceso de ingeniera del software de una organizacin. La nocin de gestin de proyectos tiene que ver con esta KA, como la construccin de artefactos de software tiles, se gestiona por lo general como (quizs programas de) proyectos individuales. A este respecto, encontramos un amplio respaldo en la Gua al Proyecto de Gestin del Cuerpo de Conocimientos (PMBOK) (PMI00), que en s misma incluye las siguientes KAs de gestin de proyectos: gestin de integracin del proyecto, gestin de objetivos del proyecto, gestin del tiempo del proyecto, gestin del coste del proyecto, gestin de la calidad del proyecto, gestin de los recursos humanos del proyecto y gestin de las comunicaciones del proyecto. Est claro que todos estos temas tienen una relacin directa con el KA de Gestin de la Ingeniera del Software. Sera imposible e inadecuado intentar duplicar aqu el contenido de la Gua de la PMBOK. En su lugar, sugerimos que el lector que est interesado en la gestin de proyectos ms all de lo que es especfico a los proyectos de ingeniera del software consulte la propia PMBOK. La gestin de proyectos tambin se encuentra en el captulo sobre las Disciplinas Sealadas de la Ingeniera del Software. El KA de Gestin de la Ingeniera del Software consiste tanto en el proceso de gestin del proyecto de software en sus primeras cinco subreas, como en la medicin de la ingeniera del software en su ltima subrea. Aunque estos dos temas se suelen considerar como distintos, y de hecho poseen muchos aspectos nicos en s mismos, su gran cercana ha llevado a que se les trate de manera conjunta en esta KA. Desafortunadamente, se comparte la percepcin comn de que la industria del software entrega sus productos tarde, por encima de lo presupuestado, y de pobre calidad e incierta funcionalidad. Una gestin regulada por la medicin un principio presupuesto en cualquier disciplina de verdadera ingeniera puede ayudar a darle la vuelta a esta percepcin. En esencia, una gestin sin medicin, cualitativa y cuantitativa, da la sensacin de falta de rigor, y medir sin gestionar da la sensacin de una falta de fines o de contexto. De igual manera, sin embargo, gestin y medicin sin conocimientos de expertos es

61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115

igualmente ineficaz, por lo que debemos tener cuidado para evitar poner un nfasis excesivo en los aspectos cuantitativos de la Gestin de Ingeniera del Software (GIS). Una gestin eficaz requiere la combinacin tanto de nmeros como de experiencia. Aqu se adoptan las siguientes definiciones de trabajo: El proceso de gestin se refiere a las actividades que se emprenden para asegurarse de que los procesos de ingeniera del software se realizan de una 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 del software (productos, procesos, y recursos segn los define [Fen98]) y a los modelos que se derivan de ellos, se hayan desarrollado estos modelos utilizando tcnicas estadsticas, conocimientos expertos u otras tcnicas.

Las subreas de gestin del proyecto de ingeniera del software hacen un uso extensivo del subrea de gestin de ingeniera del software. No es de extraar que esta KA est relacionada de cerca con otras en la Gua del SWEBOK, y sera de particular utilidad leer las siguientes descripciones del KA junto con sta. Los Requisitos del Software, en donde se describen algunas de las actividades que tendrn que realizarse durante la fase de definicin de Iniciacin y Alcance del proyecto. La Gestin de Configuracin del Software, ya que trata de la identificacin, control, consideraciones de estado, y auditora de la configuracin del software, junto con la gestin de entregas y repartos del software El Proceso de Ingeniera del Software, porque los procesos y los proyectos estn estrechamente relacionados (esta KA tambin describe la medicin de procesos y productos). La Calidad del Software, ya que la calidad es un objetivo constante de la gestin y es una meta con muchas actividades que tiene que gestionarse.
DE DEL

DESCOMPOSICIN DE LOS TEMAS GESTIN DE LA INGENIERA SOFTWARE

Hemos creado una descomposicin basada tanto en temas como en ciclos de vida, ya que el KA de Gestin de Ingeniera del Software se ve aqu como un proceso organizacional que incorpora la nocin de gestin de procesos y proyectos. Sin embargo, la base primaria de la descomposicin de alto nivel es el proceso de gestionar un proyecto de ingeniera del software. Existen seis subreas principales. Las primeras cinco subreas siguen principalmente el

1 Proceso de Gestin IEEE/EIA 12207. Las seis 2 subreas son:

3 Definicin de iniciacin y alcance, que trata de 4 la decisin de iniciar un proyecto de ingeniera 5 del software. 19 Medicin de la ingeniera del software, que trata 6 Planificacin del proyecto de software, que 20 del desarrollo e implementacin eficaz de los 7 afronta las actividades emprendidas para 21 programas de medicin en las organizaciones de 8 prepararse para una ingeniera del software 22 ingeniera del software (IEEE12207.0-96) 9 exitosa desde una perspectiva de gestin. 10 Promulgacin del proyecto de software, que trata 23 La descomposicin de los temas del KA de Gestin 11 de las actividades de gestin de ingeniera del 24 de Ingeniera del Software se muestra en la Figura 1 12 software ampliamente aceptadas que tienen lugar 13 durante la ingeniera del software. 25 26 Figura 1 Descomposicin de los temas del KA de Gestin de Ingeniera del Software

14 Repaso y evaluacin, que buscan asegurarse de 15 que el software es satisfactorio. 16 Cierre, que afronta las actividades de post17 realizacin de un proyecto de ingeniera del 18 software.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

1.

Iniciacin y Alcance

El enfoque de este conjunto de actividades se centra en la determinacin eficaz de los requisitos del software por medio de varios mtodos de induccin y la valoracin de la viabilidad del proyecto desde distintos puntos de vista. Una vez que se ha establecido la viabilidad, la tarea pendiente dentro de este proceso es la especificacin de la validacin de requisitos y del cambio de procedimientos (ver tambin el KA de Requisitos del Software). 1.1. Determinacin y Negociacin de los Requisitos [Dor02: v2c4; Pf101: c4; Pre04: c7; Som05: c5] Los mtodos de requisitos del software para la induccin de los requisitos (por ejemplo, observacin), anlisis (por ejemplo, modelado de datos, modelado de casos de uso), especificacin y validacin (por ejemplo, prototipado) deben seleccionarse y aplicarse, tomando en cuenta las distintas perspectivas del contratista. Esto lleva a la determinacin del alcance del proyecto, de los objetivos, y de las restricciones. sta siempre es una actividad importante, ya que fija las fronteras visibles para el conjunto de tareas que se emprenden, y sucede as especialmente donde la tarea es de gran novedad. Puede encontrarse informacin adicional en el KA de los Requisitos del Software. 1.2. Viabilidad, Anlisis (Tcnico, Operacional, Financiero, Social/Poltico) [Pre04: c6; Som05: c6] Se debe asegurar a los ingenieros del software que hay disponibles capacidad y recursos adecuados en forma de personas, pericia, medios, infraestructura y apoyo (sea interna o externamente) para cerciorarse de que el proyecto pueda completarse con xito de un modo oportuno y rentable (utilizando, por ejemplo, una matriz de requisitos y capacidades). A menudo esto requiere un clculo del esfuerzo y del coste basado en los mtodos adecuados (por ejemplo, tcnicas de analoga reguladas por expertos). 1.3. Construir para verificar Dado que los cambios son inevitables, es de vital importancia que desde el inicio se llegue a un acuerdo entre los contratistas acerca de los medios por los que se repasarn y revisarn el alcance y requisitos (por ejemplo, por medio de procedimientos pactados para la gestin de cambios). Esto claramente implica que el alcance y los requisitos no quedarn grabados en piedra sino que pueden y deben volverse a revisar en puntos predeterminados segn se vaya desenvolviendo el proyecto (por ejemplo, en las revisiones del diseo, en las revisiones de gestin). Si se aceptan los cambios, deber usarse entonces algn tipo de anlisis de trazabilidad y de anlisis de riesgos (ver el apartado 2.5 Gestin de

55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

Riesgos) para determinar el impacto de esos cambios. Tambin resultar til un acercamiento que gestione los cambios cuando llegue el momento de repasar los resultados del proyecto, ya que el alcance y los requisitos tendrn que ser la base para evaluar el xito. [Som05: el c6] Ver tambin la subrea de control de la configuracin del software del KA de Gestin de la Configuracin del Software. 2. Planificacin de un Proyecto de Software

El proceso de planificacin iterativa est regulado por el alcance y requisitos, y por el establecimiento de la viabilidad. A estas alturas, se evalan los procesos del ciclo de vida del software y se selecciona el ms apropiado (considerando la naturaleza del proyecto, su grado de novedad, su complejidad funcional y tcnica, sus requisitos de calidad, etc). Si la situacin lo aconseja, se planea entonces el propio proyecto en la forma de una descomposicin jerrquica de tareas, se especifican y caracterizan los entregables asociados de cada tarea en trminos de calidad y de otros atributos en la lnea de los requisitos declarados, y se emprende la descripcin detallada del esfuerzo de realizacin, el calendario y la estimacin de costes. Ms adelante se asignan los recursos a las tareas para optimizar la productividad del personal (a nivel de individuo, de equipo y organizacional), el uso de equipos y materiales, y la adhesin a los horarios. Se emprende una gestin de riesgos detallada y se discute el perfil de riesgo entre todos los contratistas de relieve, llegando a un acuerdo. Se determinan los procesos comprehensivos de gestin de la calidad del software como parte del proceso en trminos de procedimientos y responsabilidades para asegurar la calidad del software, la verificacin y la validacin, las revisiones y las auditoras (ver el KA de la Calidad del Software). Ya que es un proceso iterativo, resulta de vital importancia que se declaren y pacten con claridad los procesos y responsabilidades para la gestin, repaso y revisin del plan en ejecucin. 2.1. Planificacin de un Proceso La seleccin de un modelo adecuado de ciclo de vida del software (por ejemplo, un prototipado evolutivo en espiral) y la adaptacin y el despliegue de ciclos de vida del software, se emprenden a la luz del alcance particular y de los requisitos del proyecto. Tambin se seleccionan mtodos y herramientas pertinentes. [Dor02: el v1c6,v2c8; Pfl01: el c2; Pre04: el c2; Rei02: el c1,c3,c5; Som05: el c3; Tha97: el c3] A nivel de proyecto, se utilizan mtodos y herramientas adecuados para descomponer el proyecto en tareas, con entradas asociadas, resultados y condiciones de finalizacin de obra (por ejemplo, una estructura para la descomposicin del trabajo). [Dor02: el v2c7; Pfl01: el c3; Pre04: el c21;

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

Rei02: el c4,c5; Som05: el c4; Tha97: el c4,c6] Esto influye a su vez en las decisiones sobre el horario y estructura de la organizacin de alto nivel del proyecto. 2.2. Determinar los Entregables Se especifica y caracteriza el producto o productos de cada tarea (por ejemplo, un diseo arquitectnico, un informe de inspeccin). [Pfl01: el c3; Pre04: el c24; Tha97: el c4] Se evalan las oportunidades de reutilizar los componentes del software de desarrollos anteriores o de utilizar productos software del mercado. Se planifica la utilizacin de terceras personas y del software obtenido y se seleccionan los proveedores. 2.3. Esfuerzo, Calendario y Clculo del Coste Partiendo de la descomposicin de tareas, entradas y resultados, se determina el rango de esfuerzo esperado que se requiere para cada tarea, utilizando un modelo de estimacin calibrado basado en datos histricos sobre el esfuerzo empleado, cuando estn disponibles y sean pertinentes, u otros mtodos como el juicio de un especialista. Se establecen las dependencias de las tareas y se identifican los cuellos de botella potenciales utilizando los mtodos convenientes (por ejemplo, el anlisis del camino crtico). Cuando sea posible se solucionan los cuellos de botella, y se elabora el esperado cuadro de tareas con los horarios de inicio, duraciones y horarios de finalizacin bien planificados (por ejemplo, el diagrama PERT). Los requisitos de recursos (personas, herramientas) se traducen en estimaciones de costo. [Dor02: el v2c7; Fen98: el c12; Pfl01: el c3; Pre04: el c23, el c24,; Rei02: el c5,c6; Som05: el c4,c23; Tha97: el c5] sta es una actividad muy iterativa que debe ser negociada y revisada hasta que se alcance un acuerdo general entre los contratistas afectados (principalmente de ingeniera y gestin). 2.4 Reparto de Recursos [Pf101: c3; Pre04: c24; Rei02: c8,c9; Som05: c4; Tha97: c6,c7] Los equipos, medios y personas se asocian a las tareas programadas, incluyendo la asignacin de responsabilidades de cara a su completa realizacin (usando, por ejemplo, un diagrama de Gantt). Esta actividad est regulada y limitada por la disponibilidad de los recursos y por su uso ptimo bajo estas circunstancias, as como por temas relacionados con el personal (por ejemplo, productividad de los individuos y equipos, dinmicas de equipo, estructuras organizativas y de equipo). 2.5 Gestin de Riesgos Se lleva a cabo la identificacin y anlisis de riesgos (lo que puede salir mal, cmo y por qu, y sus posibles consecuencias), la valoracin crtica de

55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

riesgos (cules son los riesgos ms significativos a los que se est expuestos, sobre cules podemos hacer algo en cuanto a su influencia), la mitigacin de riesgos y la planificacin de contingencias (formulando una estrategia para controlar los riesgos y gestionar los perfiles de riesgo). Los mtodos de valoracin de riesgos (por ejemplo, los rboles de decisin y los procesos de simulacin) deben utilizarse para resaltar y evaluar riesgos. A estas alturas se deben determinar las polticas de abandono de proyectos en conversaciones 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. 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 requisitos detallados del software. Ver tambin el KA de los Requisitos del Software. Los lmites de adhesin 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). 2.7 Gestin de Planes [Som05: c4; Tha97: c4] 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 adhesin 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

1 problemas) tambin necesitan gestionarse de esa 2 misma manera. 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

3. Promulgacin 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 adhesin a los planes, con una expectativa arrolladora de que tal adhesin llevar a la satisfaccin plena de los requisitos 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. 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). 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. 3.3 Implementacin de Procesos para Medir [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). 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 adhesin 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 adhesin 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 adhesin a los requisitos 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

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102

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. 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 prototipados para ayudar en la validacin de los requisitos del software), y/o puede implicar la revisin de los distintos planes y de otros documentos del proyecto (por ejemplo, la especificacin de requisitos) 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). 3.6 Informes [Rei02: c10; Tha97: c3,c10] En perodos especficos y concertados, se informa de la adhesin 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 adhesin global en oposicin a los informes detallados que se requieren frecuentemente dentro del equipo de proyecto.

103 4. Revisin y Evaluacin 104 En puntos crticos del proyecto, se evalan el 105 progreso global hacia el logro de los objetivos

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

prefijados y la satisfaccin de los requisitos 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. 4.1 Determinar la Satisfaccin de los Requisitos [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. 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 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. 5. Cierre

55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103

[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 requisitos, 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. 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). 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.

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.

104 6.1 Establecer y Sostener el Compromiso de Medir 105 Aceptar los requisitos de medicin. Cada 106 tentativa de medicin debe estar guiada por 107 objetivos organizacionales, e impulsada por un

54 5.1 Determinar el Cierre

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

conjunto de requisitos 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. 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).

58 59

comunicados y revisados por los contratistas [ISO 15939-02: 5.2.2].

60 Seleccionar las mediciones. Se deben elegir las 61 mediciones candidatas al puesto, claramente 62 vinculadas a las necesidades de informacin. Las 63 mediciones deben seleccionarse en base a las 64 prioridades de las necesidades de informacin y 65 otros criterios como el coste de recoleccin de 66 datos, el grado de trastorno del proceso durante 67 la recoleccin, la facilidad de anlisis, la 68 facilidad de obtener datos precisos y 69 consistentes, etc [ISO15939-02: 5.2.3 y 70 Apndice C]. 71 Definir la recoleccin de datos, el anlisis y los 72 procedimientos para informar. Esto abarca los 73 procedimientos y horarios de recoleccin, y la 74 gestin de datos de almacenamiento, 75 verificacin, anlisis, informes y configuracin 76 [ISO15939-02: 5.2.4]. 77 Definir los criterios para evaluar los productos de 78 informacin. Los criterios para evaluar estn 79 influenciados por los objetivos tcnicos y 80 comerciales de la unidad organizacional. Los 81 productos de informacin incluyen los asociados 82 con el producto que est siendo elaborado, as 83 como los asociados con los procesos utilizados 84 para gestionar y medir el proyecto [ISO1593985 02: 5.2.5 y Apndices D y E]. 86 Revisar, aprobar y proporcionar recursos para las 87 tareas de medicin. 88 - El plan de medicin debe ser revisado y 89 aprobado por los contratistas adecuados. 90 Esto incluye todos los procedimientos de 91 recoleccin de datos y los procedimientos de 92 almacenamiento, anlisis e informes; los 93 criterios de evaluacin; horarios y 94 responsabilidades. Los criterios para revisar 95 estos artefactos tendran que haberse 96 establecido a un nivel de unidad 97 organizacional o superior y debieran usarse 98 como base para estas revisiones. Tales 99 criterios deben tomar en cuenta experiencias 100 anteriores, disponibilidad de recursos, y 101 trastornos potenciales del proceso cuando se 102 proponen cambios a las prcticas actuales. 103 La aprobacin demuestra que existe un 104 compromiso con el proceso de medicin 105 [ISO15939-02: 5.2.6.1 y Apndice F]. 106 - Hay que hacer que los recursos estn 107 disponibles para implementar las tareas de 108 medicin planeadas y aprobadas. La 109 disponibilidad de los recursos puede 110 organizarse en aquellos casos en donde los 111 cambios han de pilotarse antes de un amplio 112 despliegue. Se debe prestar atencin a los 113 recursos necesarios para un amplio

25 Empear recursos para la medicin. El 26 compromiso de la organizacin con la medicin 27 es un factor esencial para el xito, como 28 demuestra la asignacin de recursos para llevar a 29 cabo el proceso de medicin. El asignar recursos 30 incluye el reparto de responsabilidades para las 31 diferentes tareas del proceso de medicin (tales 32 como usuario, analista y bibliotecario) y el 33 proporcionar una financiacin, entrenamiento, 34 herramientas, y apoyo adecuados para dirigir el 35 proceso de un modo perdurable. 36 6.2 Planificar el Proceso de Medicin 37 Caracterizar la unidad organizacional. La unidad 38 organizacional proporciona el contexto para la 39 medicin as que es importante hacer explcito 40 este contexto y articular las presunciones que 41 ste incluye y las restricciones que va 42 imponiendo. La caracterizacin puede darse en 43 trminos de procesos organizacionales, dominios 44 de aplicaciones, tecnologa e interfaces 45 organizacionales. Un modelo de proceso 46 organizacional tambin es por lo general un 47 elemento de una caracterizacin de la unidad 48 organizacional [ISO15939-02: 5.2.1]. 49 Identificar las necesidades de informacin. Las 50 necesidades de informacin se basan en las 51 metas, restricciones, riesgos y problemas de la 52 unidad organizacional. stas pueden proceder de 53 objetivos comerciales, organizacionales, 54 reguladores y/o del producto. Deben ser 55 identificadas y deben priorizarse. Debe entonces 56 seleccionarse un subconjunto para ser cotejado y 57 los resultados deben ser documentados,

1 2

despliegue de los nuevos procedimientos o mediciones [ISO15939-02: 5.2.6.2].

3 Adquirir y desplegar tecnologas de apoyo. Esto 4 incluye una evaluacin de las tecnologas de 5 apoyo disponibles, la seleccin de las tecnologas 6 ms adecuadas, la adquisicin de esas 7 tecnologas, y el despliegue de esas tecnologas 8 [ISO 15939-02:5.2.7]. 9 6.3 Realizar el Proceso de Medicin 10 Integrar los procedimientos de medicin con los 11 procesos pertinentes. Los procedimientos de 12 medicin, tales como la recoleccin de datos, 13 deben integrarse en los procesos que estn 14 midiendo. Esto puede que implique cambiar los 15 procesos actuales para adaptar la recoleccin de 16 datos o las actividades de generacin. Puede 17 tambin implicar el anlisis de los actuales 18 procesos para minimizar esfuerzos adicionales y 19 evaluaciones del efecto en los empleados, con el 20 fin de asegurarse de que sern aceptados los 21 procedimientos de medicin. Se necesita 22 considerar los temas morales y otros factores 23 humanos. Adems, los procedimientos de 24 medicin deben comunicarse a los proveedores 25 de datos, puede que se tenga que proporcionar 26 entrenamiento, y se debe proporcionar el tpico 27 apoyo. De manera similar, el anlisis de datos y 28 los procedimientos de informacin deben tener la 29 tpica integracin en los procesos 30 organizacionales y/o del proyecto [ISO 1593931 02: 5.3.1]. 32 Recolectar datos. Se debe recolectar, verificar y 33 almacenar datos [ISO 1539-02: 5.3.2]. 34 Analizar datos y desarrollar productos de 35 informacin. Se pueden agregar, transformar o 36 recodificar datos como parte del proceso de 37 anlisis, utilizando un grado de rigor adecuado a 38 la naturaleza de los datos y las necesidades de 39 informacin. Los resultados de este anlisis son 40 indicadores tpicos, tales como grficas, nmeros 41 u otras indicaciones que han de ser interpretadas, 42 dando lugar a conclusiones iniciales que han de 43 presentar los contratistas. Los resultados y 44 conclusiones han de consultarse, utilizando un 89

45 46 47 48 49 50 51

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].

52 Comunicar los resultados. Los productos de 53 informacin deben documentarse y comunicarse 54 a los usuarios y contratistas [ISO 15939-02: 55 5.3.4]. 56 6.4 Evaluar las Mediciones 57 Evaluar los productos de informacin. Evaluar 58 los productos de informacin contrastndolos 59 con los criterios de evaluacin especficos y 60 determinar las fuerzas y debilidades de los 61 productos de informacin. Esto puede realizarlo 62 un proceso interno o una auditora externa y debe 63 incluir una retroalimentacin de los usuarios de 64 las mediciones. Grabar las lecciones aprendidas 65 en una base de datos adecuada [ISO 15939-02: 66 5.4.1 y Apndice D]. 67 Evaluar el proceso de medicin. Evaluar el 68 proceso de medicin contrastndolo con los 69 criterios de evaluacin especficos y determinar 70 las fuerzas y debilidades de los procesos. Esto 71 puede realizarlo un proceso interno o una 72 auditora externa y debe incluir una 73 retroalimentacin de los usuarios de las 74 mediciones. Grabar las lecciones aprendidas en 75 una base de datos adecuada [ISO 15939-02: 5.4.1 76 y Apndice D]. 77 Identificar las mejoras potenciales. Tales mejoras 78 pueden consistir en cambios en el formato de los 79 indicadores, cambios en las unidades medidas, o 80 en la reclasificacin de las categoras. 81 Determinar los costes y beneficios de las mejoras 82 potenciales y seleccionar las acciones de mejora 83 adecuadas. Comunicar las mejoras propuestas al 84 dueo del proceso de medicin y a los 85 contratistas para su revisin y aprobacin. 86 Comunicar tambin la falta de mejoras 87 potenciales si el anlisis no identifica ninguna 88 mejora [ISO 15939-02: 5.4.2].

1 2

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

[Dor02] [ISO1523902] [Fen98] [Pfl01] [Pre04] [Rei02] [Som05] [Tha97]

1.Iniciacin y Alcance 1.1 Determinacin y Negociacin de Requisitos 1.2 Viabilidad, Anlisis 1.3 Construir para Verificar 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 3.2 Gestin de Contratos con Proveedores 3.3 Implementacin de Procesos para medir 3.4 Proceso de Supervisin v2c4 c4 c7 c6 c5 c6 c6

v1c6, v2c7, v2c8

c2, c3 c3

c2, c21 c24 c23, c24 c24 c25 c26

c1, c3, c5

c3, c4

c3, c4, c6 c4

v2c7 v2c7 v1c8, v2c3-c5

c12

c3 c3 c3

c5, c6 c8, c9 c11 c10

c4, c23 c4 c4 c24, c25 c4

c5 c6, c7 c4 c9, c10 c4

c3

c4 c4

c13, c14 v1c8, v2c2-c5, c7 v2c7

c22

c10, c12 c10 c10 c10 c10 c25

c3, c10 c3, c10 c3, c9 c3, c10 c3, c10 c3, c10

3.5 Proceso de Control 3.6 Informes 4. Revisin y Evaluacin 4.1 Determinar la satisfaccin de los Requisitos 4.2 Revisar y Evaluar la Ejecucin 5. Cierre 5.1 Determinar el Cierre 5.2 Actividades del Cierre 6. Medida de la Ingeniera del Software 6.1 Establecer y Sostener el compromiso de Medir 6.2 Planificar el Proceso de Medicin 6.3 Realizar el Proceso de Medicin 6.4 Evaluar las Mediciones

v1c8, v2c3, c5 v1c8, v2c3, c5

c8, c9

c10

c10 c12 * c3, c13 c5, C,D,E,F c5, G c5, D c22 c4

c3, c10

3 4 5 6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
REFERENCIAS RECOMENDADAS DEL SOFTWARE
PARA LA

GESTIN

[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.

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

[Pre04] R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGraw-Hill, 2004, Chap. 2, 6, 7, 22-26. [Rei02] D.J. Reifer, ed., Software Management, IEEE Computer Society Press, 2002, Chap. 1-6, 7-12, 13. [Som05] I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005, Chap. 3-6, 2325. [Tha97] R.H. Thayer, ed., Software Engineering Project Management, IEEE Computer Society Press, 1997, Chap. 1-10.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

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. 196197. (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.

59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118

(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. (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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

Truths, Communications of 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. 23-26. (Hum97) W.S. Humphrey, Managing Technical People: Innovation, Teamwork, and the Software Process: Addison-Wesley, 1997. (IEEE12207.0-96) IEEE/EIA 12207.01996//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. (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.

61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120

(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. 2732. (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. 68. (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. 97-105. (Off97) R.J. Offen and R. Jeffery, Establishing Software Measurement Programs, IEEE Software, March/April 1997, pp. 45-53.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 61 62 63

(Par96) K.V.C. Parris, Implementing Accountability, IEEE Software, July/August 1996, pp. 83-93. (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. (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. 4150.

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

(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-92TR-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, AddisonWesley, 1999. (Zel98) M.V. Zelkowitz and D.R. Wallace, Experimental Models for Validating Technology, Computer, vol. 31, iss. 5, 1998, pp. 23-31.

1 2 3 4 5 6 7 8 9 10 11 21 22

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.01996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996.

12 13 14 15 16 17 18 19 20

(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.