Está en la página 1de 15

CAPTULO 8 1

GESTIN DE LA INGENIERA DEL SOFTWARE 2


3
4
5
ACRNIMOS 6
7
8
9
10
11
12
INTRODUCCIN 13
La Gestin de la Ingeniera del Software puede 14
definirse como la aplicacin para actividades de 15
gestin planificacin, coordinacin, mediciones, 16
monitoreo, control e informes que asegure un 17
desarrollo y mantenimiento del software sistemtico, 18
disciplinado y cuantificado (IEEE610.12-90). 19
El KA de Gestin de la Ingeniera del Software, por 20
tanto, se encarga de la gestin y medicin de la 21
ingeniera del software. A pesar de que medir es un 22
aspecto importante en todas las KAs, no es hasta aqu 23
que se presenta el tema de programas de medicin. 24
Aunque por una parte sea verdad afirmar que, en 25
cierto sentido, debiera ser posible gestionar la 26
ingeniera del software de la misma manera que 27
cualquier otro proceso (complejo) existen aspectos 28
especficos de los productos software y de los 29
procesos del ciclo de vida del software que complican 30
una gestin efectiva slo algunos de los cuales se 31
apuntan a continuacin: 32
La percepcin de los clientes es tal que con 33
frecuencia existe una falta de aprecio de la 34
complejidad inherente a la ingeniera del 35
software, particularmente en relacin al impacto 36
que produce cambiar los requisitos. 37
Es casi inevitable que los propios procesos de 38
ingeniera del software generen la necesidad de 39
nuevos o modificados requisitos del cliente. 40
Como resultado, el software se construye con 41
frecuencia mediante un proceso iterativo en vez 42
de mediante una secuencia de tareas cerradas. 43
La ingeniera del software incorpora 44
necesariamente aspectos de creatividad y de 45
disciplina mantener un balance apropiado entre 46
los dos es con frecuencia difcil. 47
El grado de novedad y de complejidad del 48
software son con frecuencia extremadamente 49
altos. 50
La tasa de cambio de la tecnologa subyacente es 51
muy rpida. 52
Con respecto a la ingeniera del software, las 53
actividades de gestin tienen lugar en tres niveles: 54
gestin organizacional y de infraestructura, gestin 55
de proyectos, y programa de planificacin y control 56
de mediciones. Estos dos ltimos se cubren con ms 57
detalle en la descripcin de este KA. A pesar de todo, 58
esto no va en detrimento de la importancia de los 59
temas de gestin organizacional. 60
Dado que la unin con las disciplinas sealadas 61
obviamente, la de gestin es importante, se 62
describir con ms detalle que las otras descripciones 63
del KA. Los aspectos de gestin organizacional son 64
importantes en trminos de su impacto sobre la 65
ingeniera del software en gestin de polticas, por 66
ejemplo: polticas organizativas y estndares que 67
proporcionan el marco en el que se desenvuelve la 68
ingeniera del software. Puede que se necesite que 69
estas polticas se vean afectadas por los requisitos de 70
un software de desarrollo y mantenimiento efectivo, y 71
puede que se necesite establecer un nmero de 72
polticas especficas de ingeniera del software para 73
una gestin eficaz de la ingeniera del software a 74
nivel organizacional. Por ejemplo, normalmente se 75
necesitan polticas para establecer procesos 76
especficos a nivel organizacional o procedimientos 77
para tareas de ingeniera del software tales como el 78
diseo, la implementacin, la estimacin, el 79
seguimiento y los informes. Tales polticas son 80
esenciales, por ejemplo, para una gestin de la 81
ingeniera del software eficaz a largo plazo, ya que 82
establecen una base consistente sobre la que analizar 83
actuaciones anteriores e implementar mejoras. 84
Otro aspecto importante de la gestin es la gestin 85
del personal: las polticas y procedimientos para 86
contratar, entrenar y motivar al personal y actuar 87
como mentor del desarrollo de una carrera son 88
importantes no slo a nivel de proyecto sino tambin 89
para el xito a largo plazo de una organizacin. Todo 90
el personal de desarrollo del software puede haber 91
sido entrenado del mismo modo o puede presentar 92
retos para la gestin del personal (por ejemplo, 93
mantener el capital en un contexto en el que la 94
tecnologa subyacente sufre cambios continuos y 95
rpidos). Con frecuencia tambin se menciona la 96
gestin de la comunicacin como un aspecto pasado 97
por alto pero importante de la actuacin de los 98
individuos en un campo en el que es necesario un 99
entendimiento preciso de las necesidades del usuario 100
y de los complejos, requisitos y diseos. Finalmente, 101
es necesaria la gestin de la cartera de trabajo, que es 102
la capacidad de tener una visin general, no slo del 103
conjunto del software en desarrollo sino tambin del 104
software que ya se est utilizando en la organizacin. 105
Ms an, la reutilizacin del software es un factor 106
PMBOK Gua al Proyecto de Gestin del Cuerpo de
Conocimientos
SQA Garanta de Calidad del Software
clave en el mantenimiento y mejora de la 1
productividad y competitividad. Una reutilizacin 2
eficaz requiere una visin estratgica que refleje el 3
poder nico y los requisitos de esta tcnica. 4
Los ingenieros del software deben entender los 5
aspectos de gestin que se encuentran influidos de 6
modo singular por el software, y adems conocer sus 7
aspectos ms generales, incluso en los primeros 8
cuatro aos tras graduarse, como est marcado en la 9
Gua. 10
La cultura y comportamiento organizacionales y la 11
gestin comercial funcional en trminos de 12
consecucin de metas, aportan la gestin en cadena, 13
la publicidad, la ventas y la distribucin, todas ellas 14
influyen, aunque sea indirectamente, en el proceso de 15
ingeniera del software de una organizacin. 16
La nocin de gestin de proyectos tiene que ver con 17
esta KA, como la construccin de artefactos de 18
software tiles, se gestiona por lo general como 19
(quizs programas de) proyectos individuales. A este 20
respecto, encontramos un amplio respaldo en la Gua 21
al Proyecto de Gestin del Cuerpo de Conocimientos 22
(PMBOK) (PMI00), que en s misma incluye las 23
siguientes KAs de gestin de proyectos: gestin de 24
integracin del proyecto, gestin de objetivos del 25
proyecto, gestin del tiempo del proyecto, gestin del 26
coste del proyecto, gestin de la calidad del proyecto, 27
gestin de los recursos humanos del proyecto y 28
gestin de las comunicaciones del proyecto. Est 29
claro que todos estos temas tienen una relacin 30
directa con el KA de Gestin de la Ingeniera del 31
Software. Sera imposible e inadecuado intentar 32
duplicar aqu el contenido de la Gua de la PMBOK. 33
En su lugar, sugerimos que el lector que est 34
interesado en la gestin de proyectos ms all de lo 35
que es especfico a los proyectos de ingeniera del 36
software consulte la propia PMBOK. La gestin de 37
proyectos tambin se encuentra en el captulo sobre 38
las Disciplinas Sealadas de la Ingeniera del 39
Software. 40
El KA de Gestin de la Ingeniera del Software 41
consiste tanto en el proceso de gestin del proyecto 42
de software en sus primeras cinco subreas, como en 43
la medicin de la ingeniera del software en su ltima 44
subrea. Aunque estos dos temas se suelen considerar 45
como distintos, y de hecho poseen muchos aspectos 46
nicos en s mismos, su gran cercana ha llevado a 47
que se les trate de manera conjunta en esta KA. 48
Desafortunadamente, se comparte la percepcin 49
comn de que la industria del software entrega sus 50
productos tarde, por encima de lo presupuestado, y de 51
pobre calidad e incierta funcionalidad. Una gestin 52
regulada por la medicin un principio presupuesto 53
en cualquier disciplina de verdadera ingeniera 54
puede ayudar a darle la vuelta a esta percepcin. En 55
esencia, una gestin sin medicin, cualitativa y 56
cuantitativa, da la sensacin de falta de rigor, y medir 57
sin gestionar da la sensacin de una falta de fines o 58
de contexto. De igual manera, sin embargo, gestin y 59
medicin sin conocimientos de expertos es 60
igualmente ineficaz, por lo que debemos tener 61
cuidado para evitar poner un nfasis excesivo en los 62
aspectos cuantitativos de la Gestin de Ingeniera del 63
Software (GIS). Una gestin eficaz requiere la 64
combinacin tanto de nmeros como de experiencia. 65
Aqu se adoptan las siguientes definiciones de 66
trabajo: 67
El proceso de gestin se refiere a las actividades 68
que se emprenden para asegurarse de que los 69
procesos de ingeniera del software se realizan de 70
una manera consistente con las polticas, 71
objetivos y estndares de la organizacin. 72
La medicin se refiere a la asignacin de valores 73
y etiquetas a los aspectos de la ingeniera del 74
software (productos, procesos, y recursos segn 75
los define [Fen98]) y a los modelos que se 76
derivan de ellos, se hayan desarrollado estos 77
modelos utilizando tcnicas estadsticas, 78
conocimientos expertos u otras tcnicas. 79
Las subreas de gestin del proyecto de ingeniera del 80
software hacen un uso extensivo del subrea de 81
gestin de ingeniera del software. 82
No es de extraar que esta KA est relacionada de 83
cerca con otras en la Gua del SWEBOK, y sera de 84
particular utilidad leer las siguientes descripciones 85
del KA junto con sta. 86
Los Requisitos del Software, en donde se 87
describen algunas de las actividades que tendrn 88
que realizarse durante la fase de definicin de 89
Iniciacin y Alcance del proyecto. 90
La Gestin de Configuracin del Software, ya 91
que trata de la identificacin, control, 92
consideraciones de estado, y auditora de la 93
configuracin del software, junto con la gestin 94
de entregas y repartos del software 95
El Proceso de Ingeniera del Software, porque los 96
procesos y los proyectos estn estrechamente 97
relacionados (esta KA tambin describe la 98
medicin de procesos y productos). 99
La Calidad del Software, ya que la calidad es un 100
objetivo constante de la gestin y es una meta 101
con muchas actividades que tiene que 102
gestionarse. 103
DESCOMPOSICIN DE LOS TEMAS DE 104
GESTIN DE LA INGENIERA DEL 105
SOFTWARE 106
Hemos creado una descomposicin basada tanto en 107
temas como en ciclos de vida, ya que el KA de 108
Gestin de Ingeniera del Software se ve aqu como 109
un proceso organizacional que incorpora la nocin de 110
gestin de procesos y proyectos. Sin embargo, la base 111
primaria de la descomposicin de alto nivel es el 112
proceso de gestionar un proyecto de ingeniera del 113
software. Existen seis subreas principales. Las 114
primeras cinco subreas siguen principalmente el 115
Proceso de Gestin IEEE/EIA 12207. Las seis 1
subreas son: 2
Definicin de iniciacin y alcance, que trata de 3
la decisin de iniciar un proyecto de ingeniera 4
del software. 5
Planificacin del proyecto de software, que 6
afronta las actividades emprendidas para 7
prepararse para una ingeniera del software 8
exitosa desde una perspectiva de gestin. 9
Promulgacin del proyecto de software, que trata 10
de las actividades de gestin de ingeniera del 11
software ampliamente aceptadas que tienen lugar 12
durante la ingeniera del software. 13
Repaso y evaluacin, que buscan asegurarse de 14
que el software es satisfactorio. 15
Cierre, que afronta las actividades de post- 16
realizacin de un proyecto de ingeniera del 17
software. 18
Medicin de la ingeniera del software, que trata 19
del desarrollo e implementacin eficaz de los 20
programas de medicin en las organizaciones de 21
ingeniera del software (IEEE12207.0-96) 22
La descomposicin de los temas del KA de Gestin 23
de Ingeniera del Software se muestra en la Figura 1 24
25
Figura 1 Descomposicin de los temas del KA de Gestin de Ingeniera del Software 26
1. Iniciacin y Alcance 1
El enfoque de este conjunto de actividades se centra 2
en la determinacin eficaz de los requisitos del 3
software por medio de varios mtodos de induccin y 4
la valoracin de la viabilidad del proyecto desde 5
distintos puntos de vista. Una vez que se ha 6
establecido la viabilidad, la tarea pendiente dentro de 7
este proceso es la especificacin de la validacin de 8
requisitos y del cambio de procedimientos (ver 9
tambin el KA de Requisitos del Software). 10
1.1. Determinacin y Negociacin de los Requisitos 11
[Dor02: v2c4; Pf101: c4; Pre04: c7; Som05: c5] 12
Los mtodos de requisitos del software para la 13
induccin de los requisitos (por ejemplo, 14
observacin), anlisis (por ejemplo, modelado de 15
datos, modelado de casos de uso), especificacin y 16
validacin (por ejemplo, prototipado) deben 17
seleccionarse y aplicarse, tomando en cuenta las 18
distintas perspectivas del contratista. Esto lleva a la 19
determinacin del alcance del proyecto, de los 20
objetivos, y de las restricciones. sta siempre es una 21
actividad importante, ya que fija las fronteras visibles 22
para el conjunto de tareas que se emprenden, y 23
sucede as especialmente donde la tarea es de gran 24
novedad. Puede encontrarse informacin adicional en 25
el KA de los Requisitos del Software. 26
1.2. Viabilidad, Anlisis (Tcnico, Operacional, 27
Financiero, Social/Poltico) 28
[Pre04: c6; Som05: c6] 29
Se debe asegurar a los ingenieros del software que 30
hay disponibles capacidad y recursos adecuados en 31
forma de personas, pericia, medios, infraestructura y 32
apoyo (sea interna o externamente) para cerciorarse 33
de que el proyecto pueda completarse con xito de un 34
modo oportuno y rentable (utilizando, por ejemplo, 35
una matriz de requisitos y capacidades). A menudo 36
esto requiere un clculo del esfuerzo y del coste 37
basado en los mtodos adecuados (por ejemplo, 38
tcnicas de analoga reguladas por expertos). 39
1.3. Construir para verificar 40
Dado que los cambios son inevitables, es de vital 41
importancia que desde el inicio se llegue a un 42
acuerdo entre los contratistas acerca de los medios 43
por los que se repasarn y revisarn el alcance y 44
requisitos (por ejemplo, por medio de procedimientos 45
pactados para la gestin de cambios). Esto claramente 46
implica que el alcance y los requisitos no quedarn 47
grabados en piedra sino que pueden y deben 48
volverse a revisar en puntos predeterminados segn 49
se vaya desenvolviendo el proyecto (por ejemplo, en 50
las revisiones del diseo, en las revisiones de 51
gestin). Si se aceptan los cambios, deber usarse 52
entonces algn tipo de anlisis de trazabilidad y de 53
anlisis de riesgos (ver el apartado 2.5 Gestin de 54
Riesgos) para determinar el impacto de esos cambios. 55
Tambin resultar til un acercamiento que gestione 56
los cambios cuando llegue el momento de repasar los 57
resultados del proyecto, ya que el alcance y los 58
requisitos tendrn que ser la base para evaluar el 59
xito. [Som05: el c6] Ver tambin la subrea de 60
control de la configuracin del software del KA de 61
Gestin de la Configuracin del Software. 62
2. Planificacin de un Proyecto de Software 63
El proceso de planificacin iterativa est regulado por 64
el alcance y requisitos, y por el establecimiento de la 65
viabilidad. A estas alturas, se evalan los procesos 66
del ciclo de vida del software y se selecciona el ms 67
apropiado (considerando la naturaleza del proyecto, 68
su grado de novedad, su complejidad funcional y 69
tcnica, sus requisitos de calidad, etc). 70
Si la situacin lo aconseja, se planea entonces el 71
propio proyecto en la forma de una descomposicin 72
jerrquica de tareas, se especifican y caracterizan los 73
entregables asociados de cada tarea en trminos de 74
calidad y de otros atributos en la lnea de los 75
requisitos declarados, y se emprende la descripcin 76
detallada del esfuerzo de realizacin, el calendario y 77
la estimacin de costes. 78
Ms adelante se asignan los recursos a las tareas para 79
optimizar la productividad del personal (a nivel de 80
individuo, de equipo y organizacional), el uso de 81
equipos y materiales, y la adhesin a los horarios. Se 82
emprende una gestin de riesgos detallada y se 83
discute el perfil de riesgo entre todos los 84
contratistas de relieve, llegando a un acuerdo. Se 85
determinan los procesos comprehensivos de gestin 86
de la calidad del software como parte del proceso en 87
trminos de procedimientos y responsabilidades para 88
asegurar la calidad del software, la verificacin y la 89
validacin, las revisiones y las auditoras (ver el KA 90
de la Calidad del Software). Ya que es un proceso 91
iterativo, resulta de vital importancia que se declaren 92
y pacten con claridad los procesos y 93
responsabilidades para la gestin, repaso y revisin 94
del plan en ejecucin. 95
2.1. Planificacin de un Proceso 96
La seleccin de un modelo adecuado de ciclo de vida 97
del software (por ejemplo, un prototipado evolutivo 98
en espiral) y la adaptacin y el despliegue de ciclos 99
de vida del software, se emprenden a la luz del 100
alcance particular y de los requisitos del proyecto. 101
Tambin se seleccionan mtodos y herramientas 102
pertinentes. [Dor02: el v1c6,v2c8; Pfl01: el c2; 103
Pre04: el c2; Rei02: el c1,c3,c5; Som05: el c3; 104
Tha97: el c3] A nivel de proyecto, se utilizan 105
mtodos y herramientas adecuados para descomponer 106
el proyecto en tareas, con entradas asociadas, 107
resultados y condiciones de finalizacin de obra (por 108
ejemplo, una estructura para la descomposicin del 109
trabajo). [Dor02: el v2c7; Pfl01: el c3; Pre04: el c21; 110
Rei02: el c4,c5; Som05: el c4; Tha97: el c4,c6] Esto 1
influye a su vez en las decisiones sobre el horario y 2
estructura de la organizacin de alto nivel del 3
proyecto. 4
2.2. Determinar los Entregables 5
Se especifica y caracteriza el producto o productos de 6
cada tarea (por ejemplo, un diseo arquitectnico, un 7
informe de inspeccin). [Pfl01: el c3; Pre04: el c24; 8
Tha97: el c4] Se evalan las oportunidades de 9
reutilizar los componentes del software de desarrollos 10
anteriores o de utilizar productos software del 11
mercado. Se planifica la utilizacin de terceras 12
personas y del software obtenido y se seleccionan los 13
proveedores. 14
2.3. Esfuerzo, Calendario y Clculo del Coste 15
Partiendo de la descomposicin de tareas, entradas y 16
resultados, se determina el rango de esfuerzo 17
esperado que se requiere para cada tarea, utilizando 18
un modelo de estimacin calibrado basado en datos 19
histricos sobre el esfuerzo empleado, cuando estn 20
disponibles y sean pertinentes, u otros mtodos como 21
el juicio de un especialista. Se establecen las 22
dependencias de las tareas y se identifican los cuellos 23
de botella potenciales utilizando los mtodos 24
convenientes (por ejemplo, el anlisis del camino 25
crtico). Cuando sea posible se solucionan los cuellos 26
de botella, y se elabora el esperado cuadro de tareas 27
con los horarios de inicio, duraciones y horarios de 28
finalizacin bien planificados (por ejemplo, el 29
diagrama PERT). Los requisitos de recursos 30
(personas, herramientas) se traducen en estimaciones 31
de costo. [Dor02: el v2c7; Fen98: el c12; Pfl01: el c3; 32
Pre04: el c23, el c24,; Rei02: el c5,c6; Som05: el 33
c4,c23; Tha97: el c5] sta es una actividad muy 34
iterativa que debe ser negociada y revisada hasta que 35
se alcance un acuerdo general entre los contratistas 36
afectados (principalmente de ingeniera y gestin). 37
2.4 Reparto de Recursos 38
[Pf101: c3; Pre04: c24; Rei02: c8,c9; Som05: 39
c4; Tha97: c6,c7] 40
Los equipos, medios y personas se asocian a las 41
tareas programadas, incluyendo la asignacin de 42
responsabilidades de cara a su completa realizacin 43
(usando, por ejemplo, un diagrama de Gantt). Esta 44
actividad est regulada y limitada por la 45
disponibilidad de los recursos y por su uso ptimo 46
bajo estas circunstancias, as como por temas 47
relacionados con el personal (por ejemplo, 48
productividad de los individuos y equipos, dinmicas 49
de equipo, estructuras organizativas y de equipo). 50
2.5 Gestin de Riesgos 51
Se lleva a cabo la identificacin y anlisis de riesgos 52
(lo que puede salir mal, cmo y por qu, y sus 53
posibles consecuencias), la valoracin crtica de 54
riesgos (cules son los riesgos ms significativos a 55
los que se est expuestos, sobre cules podemos 56
hacer algo en cuanto a su influencia), la mitigacin de 57
riesgos y la planificacin de contingencias 58
(formulando una estrategia para controlar los riesgos 59
y gestionar los perfiles de riesgo). Los mtodos de 60
valoracin de riesgos (por ejemplo, los rboles de 61
decisin y los procesos de simulacin) deben 62
utilizarse para resaltar y evaluar riesgos. A estas 63
alturas se deben determinar las polticas de abandono 64
de proyectos en conversaciones con todos los otros 65
contratistas. [Dor02: el v2c7; Pfl01: el c3; Pre04: el 66
c25; Rei02: el c11; Som05: el c4; Tha97: el c4] La 67
gestin de riesgos del proyecto debe influir en 68
aspectos de riesgo nicos en el software, como la 69
tendencia de los ingenieros del software a agregar 70
utilidades no deseadas o como el controlador de 71
riesgos presente en la naturaleza intangible del 72
software. 73
2.6 Gestin de Calidad 74
[Dor02: v1c8,v2c3-c5; Pre04: c26; Rei02: c10; 75
Som05: c24,c25; Tha97: c9,c10] 76
La calidad se define en trminos de atributos 77
pertinentes al proyecto especfico y en los de 78
cualquier producto o productos asociados a ella, 79
probablemente tanto en trminos cuantitativos como 80
cualitativos. Estas caractersticas de la calidad habrn 81
sido determinadas en la especificacin de requisitos 82
detallados del software. Ver tambin el KA de los 83
Requisitos del Software. 84
Los lmites de adhesin a la calidad para cada 85
indicador se colocan de acuerdo a las expectativas 86
que tenga el contratista sobre el software en cuestin. 87
Los procedimientos que hacen referencia a lo largo 88
del proceso a la SQA en curso a lo largo del proceso 89
y a la verificacin y validacin del producto 90
(entregable) tambin se especifican en esta fase (por 91
ejemplo, las revisiones tcnicas e inspecciones) (ver 92
tambin el KA de la Calidad del Software). 93
2.7 Gestin de Planes 94
[Som05: c4; Tha97: c4] 95
Tambin se ha de planificar cmo se gestionar el 96
proyecto y cmo se gestionar la planificacin. Los 97
informes, la supervisin y el control del proyecto 98
deben encajar en el proyecto de ingeniera del 99
software seleccionado y en las realidades del 100
proyecto, y deben reflejarse en los varios artefactos 101
que se usarn para gestionarlo. Pero, en un contexto 102
en donde los cambios son ms una expectativa que un 103
susto, es de vital importancia que se gestionen los 104
propios planes. Esto requiere que sistemticamente se 105
dirija, supervise, repase, informe y, donde as lo 106
requiera, revise, la adhesin a los planes. Los planes 107
asociados a otros procesos de soporte orientados a 108
gestin (por ejemplo, documentacin, gestin de la 109
configuracin del software, y resolucin de 110
problemas) tambin necesitan gestionarse de esa 1
misma manera. 2
3. Promulgacin del Proyecto de Software 3
A continuacin se ejecutan los planes y se promulgan 4
los procesos incluidos en los planes. A lo largo de 5
este proceso todo se centra en la adhesin a los 6
planes, con una expectativa arrolladora de que tal 7
adhesin llevar a la satisfaccin plena de los 8
requisitos del contratista y al logro de los objetivos 9
del proyecto. Las actividades actuales de gestin para 10
medir, supervisar, controlar e informar son 11
fundamentales para la promulgacin. 12
3.1 Implementacin de Planes 13
[Pf101: c3; Som05: c4] 14
Inicia el proyecto y se emprenden las actividades del 15
proyecto segn el horario. En el proceso, se utilizan 16
recursos (por ejemplo, esfuerzo del personal, 17
financiacin) y se producen entregables (por ejemplo, 18
documentos de diseo de arquitectura, casos de 19
pruebas). 20
3.2 Gestin de Contratos con Proveedores 21
[Som05: c4] 22
Preparar y ejecutar acuerdos con los proveedores, 23
supervisar la actuacin del proveedor, y aceptar sus 24
productos, incorporndolos cuando sean adecuados. 25
3.3 Implementacin de Procesos para Medir 26
[Fen98: c13,c14; Pre04: c22; Rei02: c10,c12; 27
Tha97: c3,c10] 28
Se promulga el proceso de medicin junto con el 29
proyecto del software, asegurndose de que se 30
recogen datos relevantes y tiles (ver tambin los 31
apartados 6.2 Planificar el Proceso de Medicin y 6.3 32
Realizar el Proceso de Medicin). 33
3.4 Proceso de Supervisin 34
[Dor02: v1c8, v2c2-c5,c7; Rei02: c10; Som05: 35
c25; Tha97: c3;c9] 36
Se evala continuamente y a intervalos 37
predeterminados la adhesin a los diferentes planes. 38
Se analizan los resultados y las condiciones de 39
acabado de cada tarea. Se evalan los entregables en 40
trminos de las caractersticas que ellos requieren 41
(por ejemplo, por medio de revisiones y auditoras). 42
Se investiga el consumo de fuerzas, la adhesin a 43
horarios, y los costes a da de hoy, y se examina el 44
uso de recursos. Se revisa de nuevo el perfil de riesgo 45
del proyecto y se evala la adhesin a los requisitos 46
de calidad. 47
Se modelan y analizan los datos de medicin. Se 48
emprende el anlisis de variacin basado en la 49
desviacin actual de los resultados y valores 50
esperados. Esto puede darse en forma de 51
desbordamiento de costes, equivocaciones en el 52
horario y similares. Se lleva a cabo la identificacin 53
de la desviacin y el anlisis de calidad y otros datos 54
de medicin (por ejemplo, el anlisis de la densidad 55
de los defectos). Se recalculan la exposicin a riesgos 56
y sus influencias y se ejecutan de nuevo los rboles 57
de decisiones, las simulaciones, etc, a la luz de los 58
nuevos datos. Estas actividades permiten la deteccin 59
de problemas y la identificacin de excepciones 60
basada en la superacin de los lmites existentes. Se 61
informa de los resultados segn se vaya necesitando y 62
sobre todo cuando se hayan superado los lmites 63
aceptables. 64
3.5 Proceso de Control 65
[Dor02: v2c7; Rei02: c10; Tha97: c3,c9] 66
Los resultados de las actividades de supervisin del 67
proceso proporcionan la base sobre la que se toman 68
las decisiones para actuar. Se pueden hacer cambios 69
al proyecto cuando se juzgue oportuno y cuando se 70
modele y gestione el impacto y los riesgos asociados 71
a stos. Esto puede tomar la forma de una accin 72
correctiva (por ejemplo, volviendo a probar ciertos 73
componentes), puede que involucre la incorporacin 74
de contingencias para evitar sucesos semejantes (por 75
ejemplo, la decisin de utilizar prototipados para 76
ayudar en la validacin de los requisitos del 77
software), y/o puede implicar la revisin de los 78
distintos planes y de otros documentos del proyecto 79
(por ejemplo, la especificacin de requisitos) para 80
corregir los resultados inesperados y sus 81
implicaciones. 82
En algunos casos, puede llevar al abandono del 83
proyecto. En todos los casos, se adhiere al control de 84
cambios y a los procedimientos de gestin de 85
configuracin del software (ver tambin el KA de la 86
Gestin de Configuracin del Software) se 87
documentan y comunican decisiones a todos los 88
implicados importantes, se repasan los planes y si es 89
necesario se revisan, y todos los datos importantes se 90
graban en la base de datos central (ver tambin el 91
apartado 6.3 Llevar a cabo el Proceso de Revisin). 92
3.6 Informes 93
[Rei02: c10; Tha97: c3,c10] 94
En perodos especficos y concertados, se informa de 95
la adhesin a los planes dentro de la organizacin 96
(por ejemplo al comit de direccin de cartera del 97
proyecto) y a los contratistas externos (por ejemplo, 98
clientes, usuarios). Informes de esta naturaleza deben 99
orientarse hacia una adhesin global en oposicin a 100
los informes detallados que se requieren 101
frecuentemente dentro del equipo de proyecto. 102
4. Revisin y Evaluacin 103
En puntos crticos del proyecto, se evalan el 104
progreso global hacia el logro de los objetivos 105
prefijados y la satisfaccin de los requisitos del 1
contratista. De igual modo, en hitos particulares se 2
llevan a cabo valoraciones sobre la efectividad del 3
proceso global hasta la fecha, del personal 4
involucrado, y de las herramientas y mtodos 5
utilizados. 6
4.1 Determinar la Satisfaccin de los Requisitos 7
[Rei02: c10; Tha97: c3,c10] 8
Ya que uno de nuestros objetivos principales consiste 9
en lograr la satisfaccin del contratista (usuario o 10
cliente), es importante que el progreso hacia este 11
objetivo sea evaluado formal y peridicamente. Esto 12
ocurre al lograr los principales hitos del proyecto (por 13
ejemplo, la confirmacin de la arquitectura del diseo 14
de software, la revisin tcnica de la integracin del 15
software). Se identifican variaciones a las 16
expectativas y se llevan a cabo acciones adecuadas. 17
Al igual que en la actividad de control del proceso 18
arriba indicada (ver el apartado 3.5 Proceso de 19
Control), en todos los casos, se adhiere al control de 20
cambios y a los procedimientos de gestin de 21
configuracin del software (ver tambin el KA de la 22
Gestin de Configuracin del Software) se 23
documentan y comunican decisiones a todos los 24
implicados importantes, se repasan los planes y si es 25
necesario se revisan, y todos los datos importantes se 26
graban en la base de datos central (ver tambin el 27
apartado 6.3 Llevar a cabo el Proceso de Revisin). 28
Se puede encontrar ms informacin en el KA de las 29
Pruebas del Software, en el apartado 2.2 Objetivos de 30
las Pruebas y en el KA de la Calidad del Software, 31
en el apartado 2.3 Revisiones y Auditoras. 32
4.2 Revisar y Evaluar la Ejecucin 33
[Dor02: v1c8,v2c3,c5; Pfl01: c8,c9; Rei02: c10; 34
Tha97: c3,c10] 35
Las revisiones peridicas de lo realizado, dirigidas al 36
personal del proyecto, proporcionan detalles sobre la 37
probabilidad de ser fiel a los planes as como sobre 38
las posibles reas de dificultad (por ejemplo, 39
conflictos entre miembros del equipo). Se evalan los 40
distintos mtodos, herramientas y tcnicas empleadas 41
para ver su eficacia y adecuacin, y se valora 42
sistemtica y peridicamente el propio proceso para 43
conocer su relevancia, utilidad y eficacia en el 44
contexto del proyecto. Cuando se juzga necesario, se 45
llevan a cabo y se gestionan los cambios. 46
5. Cierre 47
El proyecto llega a su fin cuando todos los planes y 48
procesos implicados se han promulgado y 49
completado. En esta fase, se repasan los criterios para 50
el xito del proyecto. Una vez que se ha establecido 51
el cierre, se llevan a cabo actividades de archivado, 52
post mortem y de mejoras de los procesos. 53
5.1 Determinar el Cierre 54
[Dor02: v1c8,v2c3,c5; Rei02: c10; Tha97: 55
c3,c10] 56
Se han completado las tareas tal y como se 57
especificaron en los planes, y se confirman los 58
criterios para lograr un acabado satisfactorio. Todos 59
los productos planificados han sido entregados con 60
caractersticas aceptables. 61
Se marca y confirma la satisfaccin de los requisitos, 62
se han logrado los objetivos del proyecto. Estos 63
procesos por lo general involucran a todos los 64
contratistas y acaban con la documentacin tanto de 65
la aceptacin del cliente y como de los informes de 66
cualquier otro problema pendiente conocido. 67
5.2 Actividades de Cierre 68
[Pf101: c12; Som05: c4] 69
Tras haberse confirmado el cierre, se archivan los 70
materiales del proyecto de acuerdo a los mtodos, 71
localizacin y duracin pactados con los contratistas. 72
La base de datos de medicin de la organizacin se 73
pone al da con los datos finales del proyecto y se 74
emprenden anlisis post-proyecto. Se inicia un 75
proyecto post mortem con el fin de analizar los 76
temas, problemas y oportunidades encontrados 77
durante el proceso (particularmente por medio de 78
revisiones y evaluaciones, ver el subrea 4 Revisin y 79
Evaluacin) y se sacan lecciones del proceso que 80
luego alimentan los conocimientos de la organizacin 81
y los intentos de mejora (ver tambin el KA del 82
Proceso de Ingeniera del Software). 83
6. Medidas de la Ingeniera del Software 84
[ISO 15939-02] 85
La importancia de la medicin y su papel en las 86
buenas prcticas de gestin est ampliamente 87
reconocido, y es tal que su importancia slo puede 88
aumentar en los prximos aos. Medir con eficacia se 89
ha convertido en una de las piedras angulares de la 90
madurez de una organizacin. Las palabras claves 91
para la medicin del software y para los mtodos de 92
medicin fueron definidas en [ISO15939-02] basadas 93
en el vocabulario internacional de metrologa ISO 94
[ISO93]. No obstante, los lectores encontrarn en la 95
literatura existente diferencias en la terminologa; por 96
ejemplo, el trmino "mtrica" a veces se usa en lugar 97
de "medicin". 98
Este apartado sigue el estndar internacional ISO/IEC 99
15939, que describe el proceso que define las 100
actividades y tareas necesarias para implementar un 101
proceso de medicin e incluye, asimismo, un modelo 102
de medicin de la informacin. 103
6.1 Establecer y Sostener el Compromiso de Medir 104
Aceptar los requisitos de medicin. Cada 105
tentativa de medicin debe estar guiada por 106
objetivos organizacionales, e impulsada por un 107
conjunto de requisitos de medicin establecidos 1
por la organizacin y por el proyecto. Por 2
ejemplo, un objetivo organizacional podra ser 3
ser los primeros en salir al mercado con los 4
nuevos productos." [Fen98: c3,c13; Pre04: c22] 5
Esto a su vez podra generar un requisito para 6
que se midan los factores que contribuyen a este 7
objetivo, y as se puedan gestionar los proyectos 8
para hacer frente a este objetivo. 9
- Definir el alcance de la medicin. Se debe 10
establecer la unidad organizacional a la que 11
se va a aplicar cada requisito de medicin. 12
Esto puede consistir en un rea funcional, en 13
un solo proyecto, en un solo sitio, o incluso 14
en toda la empresa. Todas las subsiguientes 15
tareas de medicin relacionadas con este 16
requisito deben encontrarse dentro del 17
alcance definido. Adems, se debe 18
identificar a los contratistas implicados. 19
- Compromiso de la direccin y del personal 20
con la medicin. El compromiso debe 21
establecerse formalmente, debe 22
comunicarse, y debe apoyarse en los 23
recursos (ver el siguiente artculo). 24
Empear recursos para la medicin. El 25
compromiso de la organizacin con la medicin 26
es un factor esencial para el xito, como 27
demuestra la asignacin de recursos para llevar a 28
cabo el proceso de medicin. El asignar recursos 29
incluye el reparto de responsabilidades para las 30
diferentes tareas del proceso de medicin (tales 31
como usuario, analista y bibliotecario) y el 32
proporcionar una financiacin, entrenamiento, 33
herramientas, y apoyo adecuados para dirigir el 34
proceso de un modo perdurable. 35
6.2 Planificar el Proceso de Medicin 36
Caracterizar la unidad organizacional. La unidad 37
organizacional proporciona el contexto para la 38
medicin as que es importante hacer explcito 39
este contexto y articular las presunciones que 40
ste incluye y las restricciones que va 41
imponiendo. La caracterizacin puede darse en 42
trminos de procesos organizacionales, dominios 43
de aplicaciones, tecnologa e interfaces 44
organizacionales. Un modelo de proceso 45
organizacional tambin es por lo general un 46
elemento de una caracterizacin de la unidad 47
organizacional [ISO15939-02: 5.2.1]. 48
Identificar las necesidades de informacin. Las 49
necesidades de informacin se basan en las 50
metas, restricciones, riesgos y problemas de la 51
unidad organizacional. stas pueden proceder de 52
objetivos comerciales, organizacionales, 53
reguladores y/o del producto. Deben ser 54
identificadas y deben priorizarse. Debe entonces 55
seleccionarse un subconjunto para ser cotejado y 56
los resultados deben ser documentados, 57
comunicados y revisados por los contratistas 58
[ISO 15939-02: 5.2.2]. 59
Seleccionar las mediciones. Se deben elegir las 60
mediciones candidatas al puesto, claramente 61
vinculadas a las necesidades de informacin. Las 62
mediciones deben seleccionarse en base a las 63
prioridades de las necesidades de informacin y 64
otros criterios como el coste de recoleccin de 65
datos, el grado de trastorno del proceso durante 66
la recoleccin, la facilidad de anlisis, la 67
facilidad de obtener datos precisos y 68
consistentes, etc [ISO15939-02: 5.2.3 y 69
Apndice C]. 70
Definir la recoleccin de datos, el anlisis y los 71
procedimientos para informar. Esto abarca los 72
procedimientos y horarios de recoleccin, y la 73
gestin de datos de almacenamiento, 74
verificacin, anlisis, informes y configuracin 75
[ISO15939-02: 5.2.4]. 76
Definir los criterios para evaluar los productos de 77
informacin. Los criterios para evaluar estn 78
influenciados por los objetivos tcnicos y 79
comerciales de la unidad organizacional. Los 80
productos de informacin incluyen los asociados 81
con el producto que est siendo elaborado, as 82
como los asociados con los procesos utilizados 83
para gestionar y medir el proyecto [ISO15939- 84
02: 5.2.5 y Apndices D y E]. 85
Revisar, aprobar y proporcionar recursos para las 86
tareas de medicin. 87
- El plan de medicin debe ser revisado y 88
aprobado por los contratistas adecuados. 89
Esto incluye todos los procedimientos de 90
recoleccin de datos y los procedimientos de 91
almacenamiento, anlisis e informes; los 92
criterios de evaluacin; horarios y 93
responsabilidades. Los criterios para revisar 94
estos artefactos tendran que haberse 95
establecido a un nivel de unidad 96
organizacional o superior y debieran usarse 97
como base para estas revisiones. Tales 98
criterios deben tomar en cuenta experiencias 99
anteriores, disponibilidad de recursos, y 100
trastornos potenciales del proceso cuando se 101
proponen cambios a las prcticas actuales. 102
La aprobacin demuestra que existe un 103
compromiso con el proceso de medicin 104
[ISO15939-02: 5.2.6.1 y Apndice F]. 105
- Hay que hacer que los recursos estn 106
disponibles para implementar las tareas de 107
medicin planeadas y aprobadas. La 108
disponibilidad de los recursos puede 109
organizarse en aquellos casos en donde los 110
cambios han de pilotarse antes de un amplio 111
despliegue. Se debe prestar atencin a los 112
recursos necesarios para un amplio 113
despliegue de los nuevos procedimientos o 1
mediciones [ISO15939-02: 5.2.6.2]. 2
Adquirir y desplegar tecnologas de apoyo. Esto 3
incluye una evaluacin de las tecnologas de 4
apoyo disponibles, la seleccin de las tecnologas 5
ms adecuadas, la adquisicin de esas 6
tecnologas, y el despliegue de esas tecnologas 7
[ISO 15939-02:5.2.7]. 8
6.3 Realizar el Proceso de Medicin 9
Integrar los procedimientos de medicin con los 10
procesos pertinentes. Los procedimientos de 11
medicin, tales como la recoleccin de datos, 12
deben integrarse en los procesos que estn 13
midiendo. Esto puede que implique cambiar los 14
procesos actuales para adaptar la recoleccin de 15
datos o las actividades de generacin. Puede 16
tambin implicar el anlisis de los actuales 17
procesos para minimizar esfuerzos adicionales y 18
evaluaciones del efecto en los empleados, con el 19
fin de asegurarse de que sern aceptados los 20
procedimientos de medicin. Se necesita 21
considerar los temas morales y otros factores 22
humanos. Adems, los procedimientos de 23
medicin deben comunicarse a los proveedores 24
de datos, puede que se tenga que proporcionar 25
entrenamiento, y se debe proporcionar el tpico 26
apoyo. De manera similar, el anlisis de datos y 27
los procedimientos de informacin deben tener la 28
tpica integracin en los procesos 29
organizacionales y/o del proyecto [ISO 15939- 30
02: 5.3.1]. 31
Recolectar datos. Se debe recolectar, verificar y 32
almacenar datos [ISO 1539-02: 5.3.2]. 33
Analizar datos y desarrollar productos de 34
informacin. Se pueden agregar, transformar o 35
recodificar datos como parte del proceso de 36
anlisis, utilizando un grado de rigor adecuado a 37
la naturaleza de los datos y las necesidades de 38
informacin. Los resultados de este anlisis son 39
indicadores tpicos, tales como grficas, nmeros 40
u otras indicaciones que han de ser interpretadas, 41
dando lugar a conclusiones iniciales que han de 42
presentar los contratistas. Los resultados y 43
conclusiones han de consultarse, utilizando un 44
proceso definido por la organizacin (que puede 45
ser formal o informal). Los proveedores de datos 46
y los usuarios de las mediciones deben participar 47
en revisar los datos para asegurar que son 48
significativos y precisos, y que puede llevar a 49
acciones razonables [ISO 15939-02: 5.3.3 y 50
Apndice G]. 51
Comunicar los resultados. Los productos de 52
informacin deben documentarse y comunicarse 53
a los usuarios y contratistas [ISO 15939-02: 54
5.3.4]. 55
6.4 Evaluar las Mediciones 56
Evaluar los productos de informacin. Evaluar 57
los productos de informacin contrastndolos 58
con los criterios de evaluacin especficos y 59
determinar las fuerzas y debilidades de los 60
productos de informacin. Esto puede realizarlo 61
un proceso interno o una auditora externa y debe 62
incluir una retroalimentacin de los usuarios de 63
las mediciones. Grabar las lecciones aprendidas 64
en una base de datos adecuada [ISO 15939-02: 65
5.4.1 y Apndice D]. 66
Evaluar el proceso de medicin. Evaluar el 67
proceso de medicin contrastndolo con los 68
criterios de evaluacin especficos y determinar 69
las fuerzas y debilidades de los procesos. Esto 70
puede realizarlo un proceso interno o una 71
auditora externa y debe incluir una 72
retroalimentacin de los usuarios de las 73
mediciones. Grabar las lecciones aprendidas en 74
una base de datos adecuada [ISO 15939-02: 5.4.1 75
y Apndice D]. 76
Identificar las mejoras potenciales. Tales mejoras 77
pueden consistir en cambios en el formato de los 78
indicadores, cambios en las unidades medidas, o 79
en la reclasificacin de las categoras. 80
Determinar los costes y beneficios de las mejoras 81
potenciales y seleccionar las acciones de mejora 82
adecuadas. Comunicar las mejoras propuestas al 83
dueo del proceso de medicin y a los 84
contratistas para su revisin y aprobacin. 85
Comunicar tambin la falta de mejoras 86
potenciales si el anlisis no identifica ninguna 87
mejora [ISO 15939-02: 5.4.2]. 88
89
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA 1
2
[Dor02]
[ISO15239-
02]
[Fen98] [Pfl01] [Pre04] [Rei02] [Som05] [Tha97]
1.Iniciacin y Alcance


1.1 Determinacin y
Negociacin de Requisitos
v2c4 c4 c7 c5
1.2 Viabilidad, Anlisis c6 c6
1.3 Construir para Verificar c6
2. Planificacin de un
Proyecto Software

2.1 Planificacin de un
Proceso
v1c6, v2c7,
v2c8
c2, c3 c2, c21
c1, c3,
c5
c3, c4
c3, c4,
c6
2.2 Determinar los
entregables
c3 c24 c4
2.3 Esfuerzo, Horario y
Clculo del Coste
v2c7 c12 c3
c23,
c24
c5, c6 c4, c23 c5
2.4 Reparto de Recursos c3 c24 c8, c9 c4 c6, c7
2.5 Gestin de Riesgos v2c7 c3 c25 c11 c4 c4
2.6 Gestin de Calidad v1c8,
v2c3-c5
c26 c10
c24,
c25
c9, c10
2.7 Gestin de Planes c4 c4
3. Promulgacin del
Proyecto Software

3.1 Implementacin de
Planes
c3 c4
3.2 Gestin de Contratos con
Proveedores
c4
3.3 Implementacin de
Procesos para medir

c13,
c14
c22
c10,
c12
c3, c10
3.4 Proceso de Supervisin v1c8,
v2c2-c5,
c7
c10 c25 c3, c10
3.5 Proceso de Control v2c7 c10 c3, c9
3.6 Informes c10 c3, c10
4. Revisin y Evaluacin
4.1 Determinar la
satisfaccin de los Requisitos
c10 c3, c10
4.2 Revisar y Evaluar la
Ejecucin
v1c8, v2c3,
c5
c8, c9 c10 c3, c10
5. Cierre
5.1 Determinar el Cierre v1c8, v2c3,
c5
c10 c3, c10
5.2 Actividades del Cierre c12 c4
6. Medida de la Ingeniera
del Software
*
6.1 Establecer y Sostener el
compromiso de Medir
c3, c13 c22
6.2 Planificar el Proceso de
Medicin
c5, C,D,E,F
6.3 Realizar el Proceso de
Medicin
c5, G
6.4 Evaluar las Mediciones
c5, D
3
4
5
6
1
REFERENCIAS RECOMENDADAS PARA LA GESTIN 2
DEL SOFTWARE 3
4
[Dor02] M. Dorfman and R.H. Thayer, eds., Software 5
Engineering, IEEE Computer Society Press, 2002, 6
Vol. 1, Chap. 6, 8, Vol. 2, Chap. 3, 4, 5, 7, 8. 7
8
[Fen98] N.E. Fenton and S.L. Pfleeger, Software 9
Metrics: A Rigorous & Practical Approach, second 10
ed., International Thomson Computer Press, 1998, 11
Chap. 1-14. 12
13
[ISO15939-02] ISO/IEC 15939:2002, Software 14
Engineering Software Measurement Process, ISO 15
and IEC, 2002. 16
[Pfl01] S.L. Pfleeger, Software Engineering: Theory 17
and Practice, second ed., Prentice Hall, 2001, Chap. 18
2-4, 8, 9, 12, 13. 19
20
[Pre04] R.S. Pressman, Software Engineering: A 21
Practitioner's Approach, sixth ed., McGraw-Hill, 22
2004, Chap. 2, 6, 7, 22-26. 23
24
[Rei02] D.J . Reifer, ed., Software Management, IEEE 25
Computer Society Press, 2002, Chap. 1-6, 7-12, 13. 26
27
[Som05] I. Sommerville, Software Engineering, 28
seventh ed., Addison-Wesley, 2005, Chap. 3-6, 23- 29
25. 30
31
[Tha97] R.H. Thayer, ed., Software Engineering 32
Project Management, IEEE Computer Society Press, 33
1997, Chap. 1-10. 34
APNDICE A. LISTA DE LECTURAS 1
ADICIONALES 2
3
(Adl99) T.R. Adler, J .G. Leonard, and R.K. 4
Nordgren, Improving Risk Management: Moving 5
from Risk Elimination to Risk Avoidance, 6
Information and Software Technology, vol. 41, 1999, 7
pp. 29-34. 8
9
(Bai98) R. Baines, Across Disciplines: Risk, Design, 10
Method, Process, and Tools, IEEE Software, 11
J uly/August 1998, pp. 61-64. 12
13
(Bin97) R.V. Binder, Can a Manufacturing Quality 14
Model Work for Software? IEEE Software, 15
September/October 1997, pp. 101-102,105. 16
17
(Boe97) B.W. Boehm and T. DeMarco, Software 18
Risk Management, IEEE Software, May/J une 1997, 19
pp. 17-19. 20
21
(Bri96) L.C. Briand, S. Morasca, and V.R. Basili, 22
Property-Based Software Engineering 23
Measurement, IEEE Transactions on Software 24
Engineering, vol. 22, iss. 1, 1996, pp. 68-86. 25
26
(Bri96a) L. Briand, K.E. Emam, and S. Morasca, On 27
the Application of Measurement Theory in Software 28
Engineering, Empirical Software Engineering, vol. 29
1, 1996, pp. 61-88. 30
31
(Bri97) L.C. Briand, S. Morasca, and V.R. Basili, 32
Response to: Comments on Property-based 33
Software Engineering Measurement: Refining the 34
Addivity Properties, IEEE Transactions on 35
Software Engineering, vol. 23, iss. 3, 1997, pp. 196- 36
197. 37
38
(Bro87) F.P.J . Brooks, No Silver Bullet: Essence 39
and Accidents of Software Engineering, Computer, 40
Apr. 1987, pp. 10-19. 41
42
(Cap96) J . Capers, Applied Software Measurement: 43
Assuring Productivity and Quality, second ed., 44
McGraw-Hill, 1996. 45
46
(Car97) M.J . Carr, Risk Management May Not Be 47
For Everyone, IEEE Software, May/June 1997, pp. 48
21-24. 49
50
(Cha96) R.N. Charette, Large-Scale Project 51
Management Is Risk Management, IEEE Software, 52
J uly 1996, pp. 110-117. 53
54
(Cha97) R.N. Charette, K.M. Adams, and M.B. 55
White, Managing Risk in Software Maintenance, 56
IEEE Software, May/June 1997, pp. 43-50. 57
58
(Col96) B. Collier, T. DeMarco,and P. Fearey, A 59
Defined Process for Project Postmortem Review, 60
IEEE Software, J uly 1996, pp. 65-72. 61
62
(Con97) E.H. Conrow and P.S. Shishido, 63
Implementing Risk Management on Software 64
Intensive Projects, IEEE Software, May/J une 1997, 65
pp. 83-89. 66
67
(Dav98) A.M. Davis, Predictions and Farewells, 68
IEEE Software, J uly/August 1998, pp. 6-9. 69
70
(Dem87) T. DeMarco and T. Lister, Peopleware: 71
Productive Projects and Teams, Dorset House 72
Publishing, 1987. 73
74
(Dem96) T. DeMarco and A. Miller, Managing 75
Large Software Projects, IEEE Software, J uly 1996, 76
pp. 24-27. 77
78
(Fav98) J . Favaro and S.L. Pfleeger, Making 79
Software Development Investment Decisions, ACM 80
SIGSoft Software Engineering Notes, vol. 23, iss. 5, 81
1998, pp. 69-74. 82
83
(Fay96) M.E. Fayad and M. Cline, Managing 84
Object-Oriented Software Development, Computer, 85
September 1996, pp. 26-31. 86
87
(Fen98) N.E. Fenton and S.L. Pfleeger, Software 88
Metrics: A Rigorous & Practical Approach, second 89
ed., International Thomson Computer Press, 1998. 90
91
(Fle99) R. Fleming, A Fresh Perspective on Old 92
Problems, IEEE Software, J anuary/February 1999, 93
pp. 106-113. 94
95
(Fug98) A. Fuggetta et al., Applying GQM in an 96
Industrial Software Factory, ACM Transactions on 97
Software Engineering and Methodology, vol. 7, iss. 4, 98
1998, pp. 411-448. 99
100
(Gar97) P.R. Garvey, D.J . Phair, and J .A. Wilson, 101
An Information Architecture for Risk Assessment 102
and Management, IEEE Software, May/J une 1997, 103
pp. 25-34. 104
105
(Gem97) A. Gemmer, Risk Management: Moving 106
beyond Process, Computer, May 1997, pp. 33-43. 107
108
(Gla97) R.L. Glass, The Ups and Downs of 109
Programmer Stress, Communications of the ACM, 110
vol. 40, iss. 4, 1997, pp. 17-19. 111
112
(Gla98) R.L. Glass, Short-Term and Long-Term 113
Remedies for Runaway Projects, Communications of 114
the ACM, vol. 41, iss. 7, 1998, pp. 13-15. 115
116
(Gla98a) R.L. Glass, How Not to Prepare for a 117
Consulting Assignment, and Other Ugly Consultancy 118
Truths, Communications of the ACM, vol. 41, iss. 1
12, 1998, pp. 11-13. 2
3
(Gla99) R.L. Glass, The Realities of Software 4
Technology Payoffs, Communications of the ACM, 5
vol. 42, iss. 2, 1999, pp. 74-79. 6
(Gra99) R. Grable et al., Metrics for Small Projects: 7
Experiences at the SED, IEEE Software, 8
March/April 1999, pp. 21-29. 9
10
(Gra87) R.B. Grady and D.L. Caswell, Software 11
Metrics: Establishing A Company-Wide Program. 12
Prentice Hall, 1987. 13
14
(Hal97) T. Hall and N. Fenton, Implementing 15
Effective Software Metrics Programs, IEEE 16
Software, March/April 1997, pp. 55-64. 17
18
(Hen99) S.M. Henry and K.T. Stevens, Using 19
Belbins Leadership Role to Improve Team 20
Effectiveness: An Empirical Investigation, Journal 21
of Systems and Software, vol. 44, 1999, pp. 241-250. 22
23
(Hoh99) L. Hohmann, Coaching the Rookie 24
Manager, IEEE Software, J anuary/February 1999, 25
pp. 16-19. 26
27
(Hsi96) P. Hsia, Making Software Development 28
Visible, IEEE Software, March 1996, pp. 23-26. 29
30
(Hum97) W.S. Humphrey, Managing Technical 31
People: Innovation, Teamwork, and the Software 32
Process: Addison-Wesley, 1997. 33
34
(IEEE12207.0-96) IEEE/EIA 12207.0- 35
1996//ISO/IEC12207:1995, Industry Implementation 36
of Int. Std. ISO/IEC 12207:95, Standard for 37
Information Technology-Software Life Cycle 38
Processes, IEEE, 39
1996. 40
41
(J ac98) M. J ackman, Homeopathic Remedies for 42
Team Toxicity, IEEE Software, J uly/August 1998, 43
pp. 43-45. 44
45
(Kan97) K. Kansala, Integrating Risk Assessment 46
with Cost 812 IEEE 2004 Version Estimation, 47
IEEE Software, May/June 1997, pp. 61-67. 48
49
(Kar97) J . Karlsson and K. Ryan, A Cost-Value 50
Aproach for Prioritizing Requirements, IEEE 51
Software, September/October 1997, pp. 87-74. 52
53
(Kar96) D.W. Karolak, Software Engineering Risk 54
Management, IEEE Computer Society Press, 1996. 55
56
(Kau99) K. Kautz, Making Sense of Measurement 57
for Small Organizations, IEEE Software, 58
March/April 1999, pp. 14-20. 59
60
(Kei98) M. Keil et al., A Framework for Identifying 61
Software Project Risks, Communications of the 62
ACM, vol. 41, iss. 11, 1998, pp. 76-83. 63
64
(Ker99) B. Kernighan and R. Pike, Finding 65
Performance Improvements, IEEE Software, 66
March/April 1999, pp. 61-65. 67
(Kit97) B. Kitchenham and S. Linkman, Estimates, 68
Uncertainty, and Risk, IEEE Software, May/J une 69
1997, pp. 69-74. 70
71
(Lat98) F. v. Latum et al., Adopting GQM-Based 72
Measurement in an Industrial Environment, IEEE 73
Software, J anuary-February 1998, pp. 78-86. 74
75
(Leu96) H.K.N. Leung, A Risk Index for Software 76
Producers, Software Maintenance: Research and 77
Practice, vol. 8, 1996, pp. 281-294. 78
79
(Lis97) T. Lister, Risk Management Is Project 80
Management for Adults, IEEE Software, May/June 81
1997, pp. 20-22. 82
83
(Mac96) K. Mackey, Why Bad Things Happen to 84
Good Projects, IEEE Software, May 1996, pp. 27- 85
32. 86
87
(Mac98) K. Mackey, Beyond Dilbert: Creating 88
Cultures that Work, IEEE Software, 89
J anuary/February 1998, pp. 48-49. 90
91
(Mad97) R.J . Madachy, Heuristic Risk Assessment 92
Using Cost Factors, IEEE Software, May/June 1997, 93
pp. 51-59. 94
95
(McC96) S.C. McConnell, Rapid Development: 96
Taming Wild Software Schedules, Microsoft Press, 97
1996. 98
99
(McC97) S.C. McConnell, Software Project Survival 100
Guide, Microsoft Press, 1997. 101
102
(McC99) S.C. McConnell, Software Engineering 103
Principles, IEEE Software, March/April 1999, pp. 6- 104
8. 105
106
(Moy97) T. Moynihan, How Experienced Project 107
Managers Assess Risk, IEEE Software, May/J une 108
1997, pp. 35-41. 109
110
(Ncs98) P. Ncsi, Managing OO Projects Better, 111
IEEE Software, J uly/August 1998, pp. 50-60. 112
113
(Nol99) A.J . Nolan, Learning From Success, IEEE 114
Software, J anuary/February 1999, pp. 97-105. 115
116
(Off97) R.J . Offen and R. J effery, Establishing 117
Software Measurement Programs, IEEE Software, 118
March/April 1997, pp. 45-53. 119
120
(Par96) K.V.C. Parris, Implementing 1
Accountability, IEEE Software, J uly/August 1996, 2
pp. 83-93. 3
4
(Pfl97) S.L. Pfleeger, Assessing Measurement 5
(Guest Editors Introduction), IEEE Software, 6
March/April 1997, pp. 25-26. 7
8
(Pfl97a) S.L. Pfleeger et al., Status Report on 9
Software Measurement, IEEE Software, 10
March/April 1997, pp. 33-43. 11
(Put97) L.H. Putman and W. Myers, Industrial 12
Strength Software Effective Management Using 13
Measurement, IEEE Computer Society Press, 1997. 14
15
(Rob99) P.N. Robillard, The Role of Knowledge in 16
Software Development, Communications of the 17
ACM, vol. 42, iss. 1, 1999, pp. 87-92. 18
19
(Rod97) A.G. Rodrigues and T.M. Williams, 20
System Dynamics in Software Project Management: 21
Towards the Development of a Formal Integrated 22
Framework, European Journal of Information 23
Systems, vol. 6, 1997, pp. 51-66. 24
25
(Rop97) J . Ropponen and K. Lyytinen, Can 26
Software Risk Management Improve System 27
Development: An Exploratory Study, European 28
Journal of Information Systems, vol. 6, 1997, pp. 41- 29
50. 30
31
(Sch99) C. Schmidt et al., Disincentives for 32
Communicating Risk: A Risk Paradox, Information 33
and Software Technology, vol. 41, 1999, pp. 403-411. 34
35
(Sco92) R.L. v. Scoy, Software Development Risk: 36
Opportunity, Not Problem, Software Engineering 37
Institute, Carnegie Mellon University CMU/SEI-92- 38
TR-30, 1992. 39
40
(Sla98) S.A. Slaughter, D.E. Harter, and M.S. 41
Krishnan, Evaluating the Cost of Software Quality, 42
Communications of the ACM, vol. 41, iss. 8, 1998, 43
pp. 67-73. 44
45
(Sol98) R. v. Solingen, R. Berghout, and F. v. Latum, 46
Interrupts: J ust a Minute Never Is, IEEE Software, 47
September/October 1998, pp. 97-103. 48
49
(Whi95) N. Whitten, Managing Software 50
Development Projects: Formulas for Success, Wiley, 51
1995. 52
53
(Wil99) B. Wiley, Essential System Requirements: A 54
Practical Guide to Event-Driven Methods, Addison- 55
Wesley, 1999. 56
57
(Zel98) M.V. Zelkowitz and D.R. Wallace, 58
Experimental Models for Validating Technology, 59
Computer, vol. 31, iss. 5, 1998, pp. 23-31. 60
61
62
63
APNDICE B. LISTA DE ESTNDARES 1
2
(IEEE610.12-90) IEEE Std 610.12-1990 (R2002), 3
IEEE Standard Glossary of Software Engineering 4
Terminology, IEEE, 1990. 5
6
(IEEE12207.0-96) IEEE/EIA 12207.0- 7
1996//ISO/IEC12207:1995, Industry Implementation 8
of Int. Std. ISO/IEC 12207:95, Standard for 9
Information Technology-Software Life Cycle 10
Processes, IEEE, 1996. 11
12
(ISO15939-02) ISO/IEC 15939:2002, Software 13
Engineering-Software Measurement Process, ISO 14
and IEC, 2002. 15
16
(PMI00) Project Management Institute Standards 17
Committee, A Guide to the Project Management 18
Body of Knowledge (PMBOK), Project Management 19
Institute, 2000. 20
21
22