Fair PDF

www.it-ebooks.
info
La gestión y dirección de
proyectos SOFTWARE
www.it-ebooks.info
Prensa Comité Operativo
Silla
Linda Shafer
ex Director del Instituto de Calidad de
Software de la Universidad de Texas en
Austin
Editor en jefe
Alan Clements
Profesor de la
Universidad de Teesside
Miembros de la Junta
David Anderson, Profesor Principal de la Universidad de Portsmouth
Mark J. Christensen, Consultor Independiente
James Conrad, Profesor Asociado de la UNC Charlotte
Michael G. Hinchey, Director del Laboratorio de Ingeniería de Software, la NASA Goddard Space Flight
Center
Phillip Laplante, Profesor Asociado, Ingeniería de Software, Universidad del Estado
de Penn Richard Thayer, profesor emérito de la Universidad del Estado de California,
Sacramento Donald F. Shafer, Director de Tecnología, Atenas Group, Inc.
Evan Butterfield, Director de Productos y Servicios
Kate Guillemette, Editor Desarrollo del producto, CS Press
Publicaciones IEEE Computer Society

El IEEE Computer Society de renombre mundial publica, promueve y distribuye una amplia variedad
de textos de informática e ingeniería de autoridad. Estos libros están disponibles en la mayoría de los
puntos de venta. Visitar la tienda en CShttp://computer.org/cspress para una lista de productos.
IEEE Computer Society / Wiley Asociación

La Sociedad y Wiley asociación IEEE Computer permite que el programa de libros autor CS Pulse
para producir una serie de emocionantes nuevos títulos en las áreas de ciencias de la computación, la
informática y de redes con un enfoque especial en la ingeniería de software. miembros de la Sociedad
IEEE Computer continúan recibiendo un descuento del 15% en estos títulos cuando se compran a
través de Wiley o al wiley.com/ieeecs
Para enviar preguntas sobre el programa o enviar propuestas envíe un correo electrónico
kguillemette@computer.org o escribir a los libros, IEEE Computer Society, 10662 Los Vaqueros
Circle, Los Alamitos, CA 90720-1314. Teléfono 1-714-821-8380. información adicional sobre el
programa de libros autor Computer Society también se puede acceder desde nuestro sitio Web
enhttp://computer.org/cspress.
www.it-ebooks.info
La gestión y dirección
de proyectos
SOFTWARE
RICHARD E. (DICK) FAIRLEY
A John Wiley & Sons, INC., Publicación
www.it-ebooks.info
Copyright © 2009 por la IEEE Computer Society. Todos los derechos
reservados. Publicado por John Wiley & Sons, Inc., Hoboken, Nueva
Jersey.
Publicado simultáneamente en Canadá.
Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación, o
transmitida en cualquier forma o por cualquier medio, electrónico, mecánico, de fotocopiado, de
grabación, de exploración, o de otra manera, excepto como se permite bajo la Sección 107 o 108 de la
1976 Estados Ley de Propiedad Intelectual Unidos, sin que el permiso previo por escrito del editor, o
autorización mediante el pago de la tarifa correspondiente por copia al copyright Clearance Center, Inc.,
222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, o en la web en
www.copyright.com. Las solicitudes para la Editorial autorización deberán dirigirse al Departamento de
Permisos, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748 a 6011, fax (201)
748 a 6.008, o en línea en http://www.wiley.com/go/permission.
Límite de responsabilidad / Exención de garantía: Mientras que el editor y el autor han utilizado sus
mejores esfuerzos en la preparación de este libro, que no hacen ninguna representación o garantía con
respecto a la exactitud o integridad de los contenidos de este libro y niegan específicamente cualquier
garantía implícita de comerciabilidad o idoneidad para un propósito en particular. No hay garantía
puede ser creado o ampliado por representantes de ventas o ventas de materiales escritos. Los
consejos y estrategias contenidas en el presente documento pueden no ser adecuados para su
situación. Deberías consultar con un profesional apropiado. Ni el editor ni el autor será responsable de
cualquier pérdida de beneficios o cualquier otro daño comercial, incluyendo pero no limitado a, daños
especiales, incidentales, consecuenciales o de otro tipo.
Para obtener información general sobre nuestros productos y servicios por favor, póngase en contacto
con nuestro departamento de atención al cliente dentro de los Estados Unidos al (800) 762-2974, fuera
de los Estados Unidos al (317) 572-3993 o fax (317) 572 a 4002.
Wiley también publica sus libros en una variedad de formatos electrónicos. Parte del contenido que
aparece en la impresión puede no estar disponible en formatos electrónicos. Para obtener más
información acerca de los productos Wiley, visite nuestro sitio Web enwww.wiley.com.
Biblioteca del Congreso de datos de catalogación en publicación está

disponible.
ISBN: 978-0-470-29455-0
Impreso en los Estados Unidos de
América. 10 9 8 7 6 5 4 3 2 1
www.it-ebooks.info
CONTENIDO
Prefacexv
1 Introducción1
1.1 Introducción a la gestión de proyectos software, 1
1.2 Objetivos de este capítulo, 2
1.3 ¿Por qué Gestión y dirección de proyectos de
software es difícil, 2
1.3.1 La complejidad del software, 3
1.3.2 Conformidad software, 4
1.3.3 Cambiabilidad software, 4
1.3.4 La invisibilidad de software, 5
1.3.5 Orientado al equipo, trabajo intelecto-intensivo, 6
1.4 La naturaleza de las limitaciones del proyecto, 9
1.5 Un modelo de flujo de trabajo para la gestión de proyectos de software,
13
1.6 Estructuras organizativas para los proyectos de software, 16
1.6.1 Estructuras funcionales, 16
1.6.2 Estructuras de proyectos, 17
1.6.3 Las estructuras matriciales, 17
1.6.4 Las estructuras híbridas, 18
1.7 La organización del equipo de proyecto, 19
1.7.1 El Equipo de Ingeniería de Sistemas, 19
1.7.2 El Equipo de Ingeniería de Software, 20
1.8 El mantenimiento de la visión del proyecto y la visión del producto, 21
1.9 Marcos, estándares y directrices, el 22
1.10 Puntos clave del capítulo 1, 23
1.11 Descripción general del
texto, 23 Referencias, 24
Ejercicios, 25
v
www.it-ebooks.info
vi CONTENIDO
Apéndice 1A: Marcos, estándares y directrices para la gestión de proyectos

de software, 28
1A.1 El CMMI-DEV-v1.2 Marco de
Procesos, 28
1A.2 ISO / IEC e IEEE / EIA 12207, 34
1A.3 IEEE / EIA Estándar 1058, 36
1A.4 El PMI Cuerpo de Conocimiento, 37
2 Los modelos de proceso para Software Development39

2.1 Introducción al proceso basado en modelos, 39
2.3 Un marco de desarrollo-Proceso, 42
2.3.1 Usuarios, clientes y adquirentes, 43
2.3.2 Requisitos del sistema y diseño del sistema, 46
2.3.3 Requisitos de software, arquitectura e
implementación, 47
2.3.4 Verificación y validación, 50
2.4 Adaptando el Marco de Ingeniería de Sistemas
para proyectos de software de sólo 52
2.5 Los modelos de proceso de desarrollo de software tradicionales, 54
2.5.1 Hacking, 54
2.5.2 Requisitos-a-Code, 55
2.5.3 El modelo de desarrollo de la cascada, 55
2.5.4 Directrices para la planificación y control de
proyectos de software tradicionales, 58
2.6 Iterativo de desarrollo de modelos de procesos, 58
2.6.1 El modelo incremental-Build, 59
2.6.2 El modelo evolutivo, 64
2.6.3 Modelos de desarrollo ágiles, 66
2.6.4 El modelo Scrum, 68
2.6.5 La espiral Meta-Modelo, 69
2.6.6 Directrices para la planificación y proyectos de
desarrollo Iterative- de control, 71
2.7 El diseño de un proceso iterativo-Desarrollo, 72
2.8 El papel de la creación de prototipos en desarrollo de software, 74
2.9 Puntos clave de Capítulo 2,
75 Referencias, 76
Ejercicios, 77
2A Apéndice: Marcos, estándares y directrices para los modelos de procesos
de desarrollo de software, 79
2A.1 La CMMI-DEV-v1.2 Solución técnica en
procesos en Áreas, 79
Procesos de Desarrollo 2A.2 en la norma ISO / IEC
e IEEE / EIA 12207, 80
2A.3 Proceso Técnico Planes de IEEE / EIA Estándar
1058, 81
2A.4 El PMI Cuerpo de Conocimiento, 81
www.it-ebooks.info
CONTENIDO vii
Apéndice 2B: Consideraciones para la Selección un

modelo de desarrollo Iterative-, 82
3 Proyecto de establecimiento de Foundations85

3.1 Introducción a los Fundamentos del proyecto, 85
3.3 Software de Adquisición, 87
3.4 Ingeniería de Requisitos, 88
3.4.1 Desarrollo de requisitos, 89
3.4.2 Análisis de Requerimientos, 96
3.4.3 Especificaciones técnicas, 98
3.4.4 Requisitos de verificación, 105
3.4.5 Gestión de requisitos, 106
3.5 Fundamentos de proceso, 109
3.5.1 Especificando el alcance de su proyecto, 110
3.5.2 El acuerdo contractual, 110
3.6 Puntos clave del capítulo 3,
Referencias 112, 113
Ejercicios, 114
3A Apéndice: Marcos, estándares y directrices para las fundaciones
del producto, 116
3A.1 La CMMI-DEV-v1.2 Áreas de Proceso para
el Desarrollo y Gestión de Requisitos
Requisitos, 116
3A.2 Fundamentos de producto en la norma ISO /
IEC e IEEE / EIA 12207, 117
3A.4 El PMI Cuerpo de Conocimientos, 118
4 planes y Planning119
4.1 Introducción al proceso de planificación, 119
4.3 El proceso de planificación, 121
4.4 El CMMI-DEV-v1.2 Proceso Área de Planificación de proyectos, 125
4.4.1 Una rápida planificación de proyectos, 128
4.4.2 Equilibrar la agilidad y la disciplina, 129
4.5 Un Plan Mínimo de proyectos, 129
4.6 Un modelo para los planes de gestión de proyectos de software, 130
4.6.1 Letra pequeña, 130
4.6.2 Resumen del proyecto, 132
4.6.3 Evolución, definiciones y referencias, 134
4.6.4 Organización del proyecto, 136
4.6.5 Procesos de gestión, 137
4.6.6 Procesos técnicos, 143
4.6.7 Procesos de apoyo, 145
4.6.8 Planes adicionales, apéndices, Índice, 149
www.it-ebooks.info
viii CONTENIDO
4.7 Las técnicas para la preparación de un plan de proyecto, 150

4.7.1 Adaptación de la plantilla de plan de proyecto, 150
4.7.2 Incluyendo predefinidas Elementos, 152
4.7.3 Usando Apoyo Organizacional, 152
4.7.4 Al frente de un equipo de planificación, 153
4.7.5 Planificación incremental, 153
154 referencias, 154
Ejercicios, 155
Apéndice 4A: Marcos, estándares y directrices para la planificación
de proyectos, 156
4A.1 La CMMI-DEV-v1.2 Planificación de
proyectos Proceso de área, 156
4a.4 El PMI Cuerpo de Conocimientos, 158
Apéndice 4B: anotado del examen de Software Planes de
Gestión de proyecto, basado en el estándar IEEE
1058, 159
4B.1 Propósito, 159
4B.2 evolución de los planes,
160 4B.3 Overview, 160
4B.4 Formato de un plan de gestión de proyectos
software, 160
Estructura 4b.5 y contenido del Plan, 162
5 Planificación de proyectos Techniques173

5.1 Introducción a Project Técnicas de Planificación, 173
5.3 El alcance de la planificación, 175
5.4 Balanceo-Wave Planificación, 175
5.5 Escenarios para Desarrollar un plan de proyecto, 176
5.6 El desarrollo de la arquitectura y de la
descomposición Ver la estructura del proyecto, 177
5.7 Directrices para el diseño de estructuras de
división del trabajo, 182
5.8 El desarrollo de la Lista de Proyectos, 188
5.8.1 La ruta crítica Método, 190
5.8.2 El Método PERT, 190
5.8.3 Listas de tareas de Gantt, 193
5.9 El desarrollo de perfiles de recursos, 193
5.10 Gráficas de Recursos-Gantt, 199
5.11 Estimación de Esfuerzo proyecto, costo, y horario, 199
Ejercicios, 202
www.it-ebooks.info
CONTENIDO ix
Apéndice 5A: Marcos, estándares y directrices para las técnicas de

planificación de proyectos, 204
A5.1 Prácticas específicos del CMMI-DEV-v1.2
Planificación de proyectos Proceso de Área,
204
5a.4 El PMI Cuerpo de Conocimientos, 206
6 Estimacion Techniques207
6.1 Introducción a las técnicas de estimación, 207
6.3 Principios fundamentales de Estimación, 209
6.4 El diseño de las limitaciones al proyecto, 214
6.5 La estimación del tamaño del producto, 216
6.6 Las técnicas de estimación pragmáticos, 224
6.6.1 La regla de oro, 224
6.6.2 Analogía, 226
6.6.3 El juicio de expertos, 227
6.6.4 Delphi Estimación, 227
6.6.5 EDT / CPM / PERT, 229
6.7 Modelos de estimación Teoría-base, 230
6.7.1 Dinámica de Sistemas, 230
6.7.2 SLIM, 231
6.8 Modelos de estimación de regresión-base, 234
6.8.1 Modelos de COCOMO, 238
6.8.2 Estimación de Monte Carlo, 244
6.8.3 Calibración local, 244
6.9 Herramientas de estimación, 249
6.10 Estimación de Recursos del ciclo de vida, esfuerzo y costo, 249
6.11 Un procedimiento de estimación, 251
6.12 Un Modelo para la grabación Estimates, 256
258 Referencias, 258
Ejercicios, 259
Apéndice 6A: Marcos, estándares y directrices para la estimación,
262
Objetivos 6A.1 Estimación y prácticas del
CMMI-DEV-v1.2 Proyecto Proceso de
planificación de área, 262
7 Medir y controlar el trabajo Products265

7.1 Introducción a la medición y control de productos de trabajo, 265
www.it-ebooks.info
x CONTENIDO
7.3 ¿Por qué medir ?, 268

7.4 Lo que se debe medir ?, 269
7.5 Medidas y de medición, 270
7.6 Atributos de la medición del producto, 276
7.6.1 La medición de las necesidades operacionales y
especificaciones técnicas, 276
7.6.2 La medición y el control de cambios para
trabajar los productos, 281
7.6.3 Los atributos de medición Especificaciones de
diseño arquitectónico, 285
7.6.4 Medición de atributos de implementación de software, 288
7.6.5 Medidas de complejidad para el código de software, 293
7.6.6 Medición de Integración y Verificación de Software
Unidades, 298
7.6.7 La medición de Verificación y validación del sistema, 299
7.7 Medición y análisis de defectos de software, 301
7.8 La elección de Medidas del Producto, 309
7.9 Software de medición práctico, 311
7.10 Directrices para la medición y control de productos de trabajo, 311
7.11 Ajustes del balanceo-Wave basados en medidas y medición
del producto, 313
Ejercicios, 315
Apéndice 7A: Marcos, estándares y directrices para la medición y
control de productos de trabajo, 319
7A.1 El CMMI-DEV-v1.2 Supervisión y Control de
Procesos Area, 319
7A.5 Practical Software y Sistemas de Medición
(PSM), 321
Apéndice 7B: Procedimientos y Formularios de software
Inspecciones, 322 7B.1 realizar una inspección de
software, 322
7B.2 El defecto Lista de verificación, 324
7B.3 La realización de una Reunión de inspección, 325
8 Medir y controlar el trabajo Processes333

8.1 Introducción a la medición y control de procesos de trabajo, 333
8.3 Medir y analizar Esfuerzo, 336
8.4 La medición y análisis de la reanudación Esfuerzo, 339
8.5 Seguimiento de Esfuerzo, Programación y Costo;
Estimación de Estado Futuro, 342
8.5.1 Seguimiento binario, 342
8.5.2 Estimación de Estado Futuro, 345
www.it-ebooks.info
CONTENIDO xi
8.6 Valor Ganado de informes, 347

8.7 Panel de control del Proyecto®, 353
Ejercicios, 358
Apéndice 8A: Marcos, estándares y directrices para la medición y
control de procesos de trabajo, 361
9 Proyecto de gestión de Risk363

9.1 Introducción a la administración de riesgos del proyecto, 363
9.3 Una visión general de la gestión de riesgos para
proyectos de software, 366
9.4 Técnicas de Gestión de Proyectos convencionales, 369
9.5 Técnicas de Identificación de Riesgos, 373
9.5.1 Listas de comprobación, 373
9.5.2 Tormenta de ideas, 375
9.5.3 El juicio de expertos, 375
9.5.4 FODA, 375
9.5.5 Análisis de Suposiciones y Restricciones, 375
9.5.6 Lecciones aprendidas Archivos, 376
9.5.7 El costo y horario de modelado, 376
9.5.8 Requisitos Triage, 379
9.5.9 Inventario de activos, 380
9.5.10 Análisis disyuntiva, 380
9.6 Análisis de Riesgos y Priorización, 381
9.7 Estrategias de mitigación de riesgo, 382
9.7.1 Evitar riesgos, 382
9.7.2 La transferencia del riesgo, 383
9.7.3 La aceptación del riesgo, 383
9.7.4 Acción Inmediata, 384
9.7.5 Acción contingente, 385
9.8 Top-N Seguimiento de Riesgos y registros de riesgos, 388
9.9 Control del proceso de Gestión de Riesgos, 392
9.10 Gestión de Crisis, 394
9.11 Gestión del riesgo en el nivel de organización, 395
9.12 Gestión de Riesgos conjunta, 396
Ejercicios, 397
Apéndice 9A: Marcos, estándares y directrices para la gestión de
riesgos, 399
9A.1 La CMMI-DEV-v1.2 Proceso de Gestión de
Riesgos de área, 399
9A.2 ISO / EIC y los estándares de IEEE
/ EIA 12207, 400
www.it-ebooks.info
xii CONTENIDO
9A.4 El PMI Cuerpo de Conocimientos,

401 9A.5 Norma IEEE 1540, 402
Apéndice 9B: Software de Gestión de Riesgos Glosario, 404
10 Equipos, trabajo en equipo, motivación, liderazgo, y Communication407

10.1 Introducción, 407
10.3 La gestión frente Liderar, 408
10.4 Equipos y trabajo en equipo, 410
10.5 Manteniendo el ánimo y la motivación, 417
10.6 No se puede frente no lo hará, 418
10.7 Estilos de personalidad, 420
10.7.1 Rasgos de la personalidad de Jung, 420
10.7.2 MBTI tipos de personalidad, 421
10.7.3 Dimensiones de Estilos Sociales, 425
10.8 El Cinco de capa modelo de comportamiento, 427
Ejercicios, 432
Apéndice 10A: Marcos, estándares y directrices para el trabajo en
equipo y liderazgo, 433
10A.1 El CMMI-DEV-v1.2 procesos del
Marco, 433
10a.3 IEEE / EIA Estándar 1058, 433
10A.4 El PMI Cuerpo de Conocimientos,
434 10A.5 Otras fuentes de información,
434
10A.5.1 El People CMM, 434
El 10A.5.2 Personal Software Process, 435
10A.5.3 El Team Software Process, 436
10A.5.4 Peopleware, 436
11 Organizativo Issues439
11.1 Introducción a las cuestiones de organización, 439
11.3 La influencia de la cultura corporativa, 441
11.4 La evaluación y el cuidado de Capital Intelectual, 443
11.5 Roles del personal clave, 444
11.6 Quince Directrices para organizar y dirigir equipos de
Ingeniería de Software, 449
11.6.1 Introducción a las Directrices, 449
11.6.2 Las Directrices, 450
11.6.3 Resumen de las Directrices, 463
www.it-ebooks.info
CONTENIDO xiii
Ejercicios, 465
Apéndice 11: Marcos, estándares y Directrices para las
cuestiones de organización, 467
A11.1 El CMMI-DEV-v1.2 Marco de
Proceso, 467
A11.2 ISO 12207 y los estándares de IEEE,
IEEE 469 A11.3 / EIA Estándar 1058, 470
A11.4 El PMI Cuerpo de Conocimientos, 470
Glosario de Terms471
Plazo para la orientación Projects481
Index487
www.it-ebooks.info
PREFACIO
Con demasiada frecuencia, los que desarrollar y modificar el software y los que
manejan el desarrollo de software son como los trenes que viajan diferentes rutas
hacia un destino común. Los gerentes quieren llegar a la estación del cliente con
un producto aceptable, a tiempo y dentro del presupuesto. Los desarrolladores
quieren ofrecer a los usuarios un tren cargado de características y atributos de
calidad; van a retrasar el momento de la llegada a hacerlo, si lo permiten. A veces
los dos trenes parecen estar en el mismo horario, pero a menudo se toma la
delantera sólo para ser desviados por el tráfico de mayor prioridad, mientras que
los otros Chugs adelante. Uno o ambos pueden ser desviados de forma
inesperada, lo que hace difícil para encontrarse en la ruta y en el destino final.
Los gerentes que viajan en el tren a menudo se preguntan por qué los
programadores no pueden simplemente escribir el código que necesita ser escrita,
correcta y completamente, y entregarla cuando sea necesario. Los desarrolladores
de software que viajan en el tren se preguntan cuáles son sus ERS manag- hacen
todo el día. Este texto ofrece las penetraciones, métodos, herramientas y técnicas
necesarias para mantener las dos trenes en movimiento al unísono a través de sus
señales e interruptores y, mejor aún, muestra cómo se pueden combinar sus
motores y de carga para formar un solo tren expreso que se ejecuta en un par de
carriles, uno técnico, otro directivo.
Mediante la lectura de este texto y de trabajo a través de los ejercicios, los
estudiantes, los Ircops desa- software, gerentes de proyecto, y los candidatos a
administradores aprenderán por qué
la gestión de un proyecto de programación informática es grande como la gestión de

cualesquiera otros grandes más formas de compromiso en que la mayoría de los
programadores creen. Sin embargo, en muchos sentidos, es diferente en más de la
mayoría de los administradores profesionales esperan. 1
Los lectores aprenderán cómo los proyectos de software difieren de otros tipos
de proyectos (es decir, la construcción, la agricultura, la industria manufacturera,
administrativas y proyectos de inge- niería tradicionales), y van a aprender los
métodos y técnicas de gestión de proyectos deben ser modificados y adaptados
para el software proyectos.
www.it-ebooks.info
1
El mes laboral mítico, edición de aniversario, Frederick P. Brooks Jr., Addison Wesley, 1995; pp. x.
xv
www.it-ebooks.info
xvi PREFACIO
Los que son, o van a convertirse en gestores de proyectos de software,

adquirirá los métodos, herramientas y técnicas necesarias para gestionar
eficazmente los proyectos de software, tanto grandes como pequeñas. Los
desarrolladores de software, tanto para el estudiante neófito y oficiales / distas
profesional neywoman, obtendrán una mayor comprensión de lo que hacen los
gerentes, o debería estar haciendo todo el día y por qué los gerentes les pido que
hagan las cosas que piden / demanda. Estos lectores obtendrán los conocimientos
necesarios para convertirse en res manag- proyecto. Aquellos estudiantes y
desarrolladores de software que no tienen ningún deseo de convertirse en
gestores de proyectos se beneficiarán mediante la obtención de una mayor
comprensión de lo que esas otras personas hacen todo el día y por qué las cosas
aparentemente extrañas que, los desarrolladores, se les pide hacer son
importantes para el éxito de su proyectos.
Este texto pretende ser un libro de texto para los estudiantes de la división
superior y gradu- comió estudiantes, así como para los profesionales de software
y administradores de proyectos de software actuales y potenciales. Los ejercicios
se incluyen en cada capítulo. consejos y directrices prácticas se incluyen en el
texto, por lo que es adecuado para cursos cortos industriales y para el
autoaprendizaje por los profesionales y gestores.
Capítulos 1 a 3 proporcionan el contexto para el resto del texto: Capítulo 1
proporciona una introducción a la gestión de proyectos de software; Capítulo 2 se
refiere a los modelos de procesos para el desarrollo de sistemas intensivos en
software; El capítulo 3 se ocupa de establecer las bases de productos para
proyectos de software.
Los capítulos 4 al 10 cubren las cuatro actividades principales de la gestión de
proyectos de software:
• Planificación y estimación está cubierto en los capítulos 4 a 6.
• Medición y control se tratan en los capítulos 7 y 8.
• La gestión del riesgo está cubierto en el Capítulo 9.
• Liderazgo, motivación, comunicación y están cubiertos en el Capítulo 10.
Capítulo 11 cubre las cuestiones de organización y concluye el texto con un
resumen de 15 directrices para organizar y dirigir equipos de ingeniería de
software.
Para cada tema, el enfoque adoptado es presentar toda la gama de actividades de
los proyectos más grandes y complejos, y para mostrar cómo esas actividades se
pueden adaptar, adaptados, y escala para ajustarse a las necesidades de los proyectos
de diversos tamaños y complejidades .
Los objetivos de aprendizaje se presentan al comienzo de cada capítulo y cada
concluye con un resumen de los puntos clave del capítulo. barras laterales
ocasionales elaborar el material a mano. Un apéndice de cada capítulo se refiere a
los temas tratados en ese capítulo cuatro fuentes principales de información
relativa ción manage- de proyectos de software:
1. marco de proceso CMMI-DEV-v1.2
2. ISO / IEC e IEEE / EIA 12207
3. IEEE / EIA Estándar 1058
4. Cuerpo de PMI del Conocimiento (PMBOK®)
El texto está en consonancia con las directrices contenidas en el PMBOK y
recomendaciones ACM / IEEE plan de estudios.
diapositivas de la presentación, plantillas de documentos y otros
materiales de apoyo para el texto y para proyectos a largo plazo están
www.it-ebooks.info
disponibles en la siguiente URL:
computer.org/book_extras/fairley_software_projects
www.it-ebooks.info
PREFACIO xvii
Los términos usados en todo este texto se definen en el glosario al final del
texto. Temas, calendario, y una plantilla para proyectos a largo plazo siguen el
Glosario y se incluyen algunos proyectos hipotéticos que pueden utilizarse como
base para proyectos a largo plazo en un curso o como ejemplos que los
profesionales y los administradores pueden utilizar para ganar experiencia en la
preparación de proyectos de software planes de gestión. Programar y placas tem-
para entregables de los proyectos hipotéticos También se proporcionan; copias
electrónicas de las plantillas y algunas herramientas de software se proporcionan
en la URL anteriormente citado. Por otra parte, los profesionales y los
administradores pueden aplicar las plantillas y herramientas para un pasado,
presente o futuro proyecto.
Un ejemplo continuo para la planificación y la realización de un proyecto para
construir el elemento de software de un sistema de cajero automático se presenta
para motivar y explicar el material contenido en cada capítulo.
Como es bien sabido, uno aprende mejor haciendo. Me recomienda
encarecidamente que los ejercicios al final de cada capítulo se complete y que el
progreso a través del material ir acompañados de un ejercicio prolongado (es
decir, un proyecto a largo plazo) para desarrollar algunos elementos de un plan
de proyecto para un proyecto de software real o hipotética. El ejercicio Ning
plan- se puede basar en un proyecto real que el lector ha sido, es actualmente, o
se involucran en; o puede estar basada en uno de los hipotéticos al final del texto;
o puede estar basado en un proyecto asignado por el instructor. Se proporciona
un horario de la semana a semana para completar el proyecto a largo plazo sobre
una base trimestre o semestre. La finalización del ejercicio de planificación dará
lugar a un informe que contiene elementos similares a los presentados en IEEE
estándar EIA / 1058 para los planes de Ment manage- de proyectos de software.
El material puede ser presentado en formato de lectura / conferencia / debate o
mediante lecturas asignadas seguido de aula o discusiones en línea sobre la base
de los ejercicios y el proyecto a largo plazo.
Estoy en deuda con los pioneros que inspeccionó el terreno, prepararon el
firme de la carretera, ha establecido las pistas, y condujo el punto de oro para que
nuestros trenes de proyectos pueden proceder a sus destinos. Esos pioneros
incluyen Fred Brooks, el padre intelectual de todos nosotros; Winston Royce, que
nos mostró enfoques sistemáticos para el desarrollo y gestión de proyectos de
software de software; Barry Boehm, quien fue el primero en abordar los
problemas de la economía de ingeniería de software, gestión de riesgos, y mucho
más; Tom DeMarco, el maestro de la táctica de desarrollo de software, manage-
ment proyecto y peopleware; y los muchos otros que prepararon el camino para
este texto. Acepto la responsabilidad por cualquier mala interpretación o
inexactitudes de su trabajo. Mis disculpas a los que he fallado al crédito en el
texto, ya sea por ignorancia o por descuido.
Gracias a Mary Jane Fairley, Linda Shafer, y los otros revisores del
manuscrito por tomarse el tiempo para leerlo y para los muchos comentarios
interesantes que ofrecían. Un agradecimiento especial a los muchos estudiantes a
los que he presentado este material y de quien he aprendido todo lo que han
aprendido de mí.
Condado de Teller, Richard E. (Dick) Fairley

Colorado
www.it-ebooks.info
1
INTRODUCCIÓN
En muchos aspectos, la gestión de un proyecto de programación informática es

grande como la gestión de cualesquiera otros grandes más formas de compromiso en
que la mayoría de los programadores creen. Pero en muchos otros aspectos, es
diferente en más de la mayoría de los administradores profesionales esperan. 1
-Fred Brooks
1.1 INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS DE SOFTWARE
Cuando se convierte en (o quizás ya está) el encargado de un proyecto de

software se encuentra que la experiencia de ser una de las tareas más difíciles y
más gratificantes de su carrera. Usted, como director del proyecto, será (o son)
responsable de
(1) la entrega de un producto aceptable, (2) en la fecha de entrega especificado, y
(3) dentro de las limitaciones del presupuesto, los recursos y la tecnología
especificada. A cambio, usted tiene, o debería tener, autoridad para utilizar los
recursos disponibles para usted de la manera que mejor le parezca para lograr los
objetivos del proyecto dentro de las limitaciones de producto aceptable, fecha de
entrega, y el presupuesto, los recursos y la tecnología.
Por desgracia, los proyectos de software tienen la (a menudo merecida)
reputación del costando más de lo estimado, teniendo más de lo previsto, y la
entrega en menos cantidad y la calidad del producto de lo esperado o requerido.
Evitar esta situación estereotipada es el reto de gestionar y dirigir proyectos de
software.
Hay cuatro actividades fundamentales que debe cumplir si va a ser un director
del proyecto éxito:
1
El mes laboral mítico, edición de aniversario, Frederick P. Brooks Jr., Addison Wesley, 1995; px
La gestión y dirección de proyectos de software, Por Richard E.

Fairley Copyright © 2009 IEEE Computer Society
1
www.it-ebooks.info
2 INTRODUCCIÓN
1. la planificación y la estimación,
2. medición y control,
3. comunicar, coordinar, y que conduce, y
4. la gestión del riesgo.
Estos son los temas principales de este texto.
1.2 OBJETIVOS DE ESTE CAPÍTULO
Después de leer este capítulo y completar los ejercicios, usted debe entender:
• ¿Por qué la gestión y dirección de proyectos de software es difícil,

• la naturaleza de las limitaciones del proyecto,
• un modelo de flujo de trabajo para proyectos de software,
• los productos de trabajo de los proyectos de software,
• el contexto de la organización de proyectos de software,
• la organización de un equipo de desarrollo de software,
• el mantenimiento de los objetivos de la visión del proyecto y del producto, y
• la naturaleza de los marcos de procesos, estándares de ingeniería de software
y directrices del proceso.
Apéndice 1A a este capítulo se proporciona una introducción a los elementos de los

siguientes marcos, normas y directrices que se ocupan de la gestión de proyectos de
software: la madurez de la capacidad SEI Model® Integración CMMI-DEV-v1.2,
ISO / IEC e IEEE / EIA 12207, IEEE / EIA estándar de 1058, y la Dirección de
Proyectos del conocimiento (PMBOK). Los términos utilizados en este capítulo y en
todo este texto se definen en un glosario al final del texto. diapositivas de la
presentación de este capítulo y otro material de apoyo están disponibles en la URL
que aparece en el Prefacio.
1.3 ¿POR ADMINISTRACIÓN Y PROYECTOS software líder es

difícil
Un proyecto es un conjunto de actividades coordinadas llevadas a cabo dentro de

un marco de tiempo específico con el propósito de lograr los objetivos
especificados. Algunos proyectos son de naturaleza personal, por ejemplo, la
construcción de una casa de perro o pintar un dormitorio. Otros proyectos se
llevan a cabo por las organizaciones. El objetivo de este texto es en proyectos
llevados a cabo dentro de las organizaciones de software. En un sentido general,
todos los proyectos de la organización son similares:
• objetivos deben especificarse,

• un programa de actividades debe ser planificada,
• recursos asignados,
• responsabilidades asignadas,
www.it-ebooks.info
1.3 ¿Por qué GESTIÓN Y PROYECTOS software líder es difícil 3
• actividades de trabajo coordinadas,

• progresos constatados,
• la comunicación mantenida,
• factores de riesgo identificados y enfrentados, y
• las acciones correctivas aplicadas según sea necesario.
En un sentido específico, los métodos, herramientas y técnicas utilizadas para

administrar un proyecto dependen de la naturaleza del trabajo a realizar y los
productos de trabajo para ser producidos. proyectos de fabricación son diferentes
de los proyectos de construcción, que son diferentes de los proyectos agrícolas,
que son diferentes de los proyectos informáticos de hardware, que son diferentes
de los proyectos de ingeniería de software, y así sucesivamente. Cada tipo de
proyecto, incluyendo los proyectos de software, se adapta y adapta los procedi-
mientos generales de gestión de proyectos para dar cabida a los aspectos únicos
de los procesos de desarrollo y la naturaleza del producto a desarrollar.
Fred Brooks ha observado famoso que cuatro propiedades esenciales del
software de la diferencian de otros tipos de artefactos de ingeniería y hacen que
los proyectos de software difficult2:
1. complejidad,
2. conformidad,
3. mutabilidad, y
4. invisibilidad de software.
1.3.1 La complejidad del software

El software es más complejo, por el esfuerzo y el gasto requeridos para su
construcción, que la mayoría de los artefactos producidos por la actividad
humana. Suponiendo que cuesta $ 50 (USD) por cada línea de código para
construir un programa de línea de un millón (especificar, diseñar, implementar,
verificar, validar y entregarla), el costo resultante será de $ 50.000.000. Si bien
esto es una gran suma de dinero, que es una pequeña fracción del costo de
construcción de una nave espacial compleja, un rascacielos o un portaaviones de
la marina.
Brooks dice, “entidades de software son más complejos para su tamaño
[énfasis añadido] que quizás cualquier otra construcción humana, porque no hay
dos piezas iguales (al menos por encima del nivel de los estados).” 3 Es difícil
visualizar el tamaño de un software programa ya que el software no tiene
atributos físicos; Sin embargo, si uno fuera a imprimir un programa de uno
millones de línea de la pila de papel sería de unos 10 pies (unos 3 metros) de
altura si el programa se imprimieron 50 líneas por página. La impresión ocuparía
un volumen de aproximadamente 6,5 pies cúbicos. entidades biológicas tales
como los seres humanos son de volumen similar y son mucho más complejos que
los programas informáticos, pero hay pocas, o ninguna, artefactos hechos por el
hombre de tamaño comparable que son tan complejo como el software.
La complejidad del software se debe a la gran cantidad de piezas únicas, que
interactúan en un sistema de software. Las piezas son únicas, ya que, en su mayor
parte, que se encapsulan como funciones, subrutinas u objetos e invocados como
sea necesario en vez
2
Ibídem, Pp. 182-186.
3
Ibídem, pag. 182.
www.it-ebooks.info
4 INTRODUCCIÓN
de ser replicado. piezas de software tienen diferentes tipos de interacciones,

incluidas las invocaciones de serie y concurrentes, las transiciones de estado,
acoplamientos de datos e interfaces a bases de datos y sistemas externos.
Representación de una entidad de software a menudo requiere varias
representaciones diferentes para representar las numerosas estructuras estáticas,
dinámicas, acoplamientos y modos de interacción que existen en los programas
informáticos.
Un cambio aparentemente “pequeño” en los requisitos es una de las muchas
maneras que com- complejidad del producto puede afectar a la gestión de un
proyecto. La complejidad dentro de las partes y en las conexiones entre las partes
puede dar lugar a una gran cantidad de retrabajo Evolución- aria para el cambio
“pequeño” en los requisitos, alterando así la capacidad de progresar de acuerdo al
plan. Por esta razón, muchos administradores de proyectos experimentados dicen
que no hay requisitos de pequeños cambios. El tamaño y la complejidad también
pueden ocultar defectos que no pueden ser descubiertos de inmediato y por lo
tanto requieren retrabajo correctiva adicional, no planificado después.
1.3.2 conformidad de software

La conformidad es el segundo número citado por Brooks. Software debe
ajustarse a las especificaciones exigentes en la representación de cada parte, en
las interfaces a otras partes internas, y en las conexiones para el medio ambiente
en el que opera. A falta punto y coma u otro error sintáctico pueden ser
detectados por un compilador pero un defecto en la lógica del programa, o un
error de temporización causados por no cumplir con los requisitos puede ser
difícil de detectar hasta que produzcan en la conducción. A diferencia de
software, la tolerancia entre las interfaces de entidades físicas es la base de la
fabricación y la construcción; no hay dos partes físicas que están unidas entre sí
tienen, o están obligados a tener, coincidencias exactas. Eli Whitney (de algodón
fama ginebra) realizado en 1798 que si partes de mosquete fueron fabricados a
tolerancias especificadas,
No hay tolerancias correspondientes en las interfaces entre entidades de
software o entre entidades de software y sus entornos. Interfaces entre las piezas
de software deben estar de acuerdo exactamente en el número y tipo de
parámetros y tipo de acoplamientos. No hay especificaciones de interfaz para el
software que indican que un parámetro puede ser “un número entero de más o
menos 2%.”
La falta de conformidad puede causar problemas cuando un componente de
software existente no se puede reutilizar como estaba previsto, ya que no se
ajusta a las necesidades del producto en fase de desarrollo. La falta de
conformidad no puede ser descubierta hasta el final de un proyecto, necesitando
por lo tanto el desarrollo y la integración de un componente aceptable para
sustituir a la que no se puede volver a utilizar. Esto requiere la asignación de los
recursos y no planificado puede retrasar la terminación del producto.
Complejidad puede haber hecho que sea difícil de determinar que el componente
de reutilización carecía de la conformidad necesaria hasta que los componentes
sería interactuar con fueron completado.
1.3.3 Variabilidad de software

Mutabilidad es tercer factor de Brooks que hace que los proyectos de software
difícil. software coordina el funcionamiento de los componentes físicos y
www.it-ebooks.info
proporciona la funcional-
www.it-ebooks.info
1.3 ¿Por qué GESTIÓN Y PROYECTOS software líder es difícil 5
dad en systems.4 intensivos en software Dado que el software es el elemento

cambiado más fácilmente (es decir, el más maleable) en un sistema de software
intensivo, es el elemento consiguiente modificados los más fre-, particularmente
en las últimas etapas de un proyecto. Los cambios pueden ocurrir porque los
clientes cambian de opinión; productos de la competencia cambian; objetivos de
la misión cambian; leyes, regulaciones y prácticas de negocio cambian; Ware y la
tecnología de software de los cambios subyacentes hard- (procesadores, sistemas
operativos, paquetes de aplicaciones); y / o el entorno operativo de los cambios
en el software. Si una primera versión del producto final se instala en el entorno
operativo, que va a cambiar ese ambiente y dar lugar a nuevas exigencias que se
requieren cambios en el producto. En pocas palabras, ahora que el nuevo sistema
me permite hacer A y B,
Cada cambio propuesto en los requisitos del producto debe ir acompañado de
un análisis del impacto de los cambios en las actividades de trabajo del proyecto:
• qué productos de trabajo tendrá que ser cambiado?

• la cantidad de tiempo y esfuerzo se requerirá?
• que está disponible para hacer los cambios?
• ¿Cómo afectará el cambio de sus planes para el horario, presupuesto,
recursos, tecnolo- gía, otras características del producto, y los atributos de
calidad del producto?
El objetivo del análisis de impacto es determinar si un cambio propuesto es “de

alcance” o “fuera de alcance”. En-scope cambios en un producto de software son
los cambios que se pueden realizar con poca o ninguna interrupción de las
actividades de trabajo previstas. La aceptación de un cambio fuera de alcance a
los requisitos del producto debe ir acompañado de ajustes correspondientes al
presupuesto, los recursos y / o programa; y / ción o modifica- o eliminación de
otros requisitos del producto. Estas acciones pueden traer un cambio propuesto
requisito fuera de alcance en el alcance revisado.
Una fuente que se produce habitualmente de problemas en la gestión de
proyectos de software es un cambio de producto fuera del alcance que no se
acompaña de cambios en la programación, los recursos, el presupuesto y / o la
tecnología correspondiente. Los problemas creados por tanto, incluyen
agotamiento del personal del exceso de horas extraordinarias, y la reducción en la
calidad debido a la gente cansada cometen más errores. En las revisiones
Además, las pruebas, y otras técnicas de control de calidad a menudo se reduce o
se elimina debido a la falta de tiempo y recursos para llevar a cabo el cambio y
mantener estas otras actividades.
1.3.4 La invisibilidad de software

El cuarto de los factores de Brooks es la invisibilidad. Software se dice que es
invisible porque no tiene propiedades físicas. Si bien los efectos de ejecutar el
software en un ordenador digital son observables, el software en sí no puede ser
vista, sabor, aroma, tocado, o escuchado. Nuestros cinco sentidos humanos son
incapaces de software directamente de detección; software es por lo tanto una
entidad intangible. productos de trabajo, tales como especificaciones de
requisitos, documentos de diseño, código fuente y código objeto son
representaciones de software, pero
4
sistemas intensivos en software contienen uno o más dispositivos digitales y pueden incluir otros
tipos de hardware, además de operadores capacitados que realizan funciones manuales. reactores
www.it-ebooks.info
nucleares, aviones modernos, automóviles, servidores de red y computadoras portátiles son ejemplos
de sistemas intensivos en software.
www.it-ebooks.info
6 INTRODUCCIÓN
no son el software. En el nivel más elemental, el software reside en el netization

MAG y el flujo de corriente en un gran número de elementos electrónicos dentro
de un dispositivo digital. Dado que el software no tiene una presencia física que
utilizar diferentes representaciones, en diferentes niveles de abstracción, en un
intento de visualizar la entidad intrínsecamente invisible.
Dado que el software no puede ser observado directamente como pueden, por
ejemplo, un edificio en construcción o un terreno agrícola siendo preparado para
la siembra, las técnicas presentadas en este texto pueden ser usados para
determinar el verdadero estado de progreso de un proyecto de software. Un
resultado desafortunado de no utilizar estas técnicas es que los productos de
software en desarrollo a menudo se informó a ser “casi completa” durante largos
períodos de tiempo sin evidencia objetiva para apoyar o refutar la reclamación;
este es el conocido “síndrome del 90% completa” de los proyectos de software.
Muchos proyectos de software se han cancelado después de grandes inversiones
de esfuerzo, tiempo y dinero porque nadie podía determinar objetivamente el
estado de los productos de trabajo o proporcionar una estimación fiable de una
fecha de terminación o el costo para completar el proyecto. Triste pero cierto,
esto ocurrirá de nuevo.
1.3.5 Orientado al equipo, trabajo intelecto-intensivo

Además de las propiedades esenciales de software (complejidad, la conformidad,
la capacidad de cambio-, y la invisibilidad), un factor adicional que distingue a
los proyectos de software de otros tipos de proyectos: proyectos de software son
un equipo-orientado, intelecto-intensiva endeav- ORS. Por el contrario, la
fabricación de la línea de montaje, construcción de edificios y carreteras, la
plantación de arroz, y la cosecha de la fruta son actividades intensivas en mano
de obra; el trabajo está dispuesto de manera que cada persona puede realizar una
tarea con un alto grado de autonomía y una pequeña cantidad de interacción con
otros. La productividad aumenta linealmente con el número de trabajadores
adicionales; la obra se procederá más o menos el doble de rápido si se duplica el
número de trabajadores. Aunque las máquinas que ahorran trabajo han
aumentado la productividad en algunas de estas áreas,
El software se desarrolla por equipos de personas que se dedican a la solución
creativa de problemas. Los equipos son necesarios porque llevaría demasiado
tiempo para una persona para desarrollar un sistema de software moderno y
porque es poco probable que un individuo podría poseer la necesaria gama de
habilidades. Supongamos, por ejemplo, que el esfuerzo total para desarrollar un
producto de software o resultados System5 en un nivel de productividad de 1000
líneas de código por el personal de meses (más sobre esto más adelante). Un
programa de un millón línea requeriría 1.000 personas-mes. Porque el esfuerzo
(meses-personal) es el producto de personas y el tiempo, sería necesario 1
persona 1000 meses (aproximadamente 83 años) para completa del proyecto.
Una combinación posible de personas y el tiempo para un proyecto personal de
1.000 meses podría ser un equipo de 50 personas que trabajan durante 20 meses, pero
no 1.000 personas que trabajan durante 1 mes o incluso 200 personas que trabajan
durante 5 meses. Las propuestas posteriores (1000 1 y
5
productos de software se construyen por los vendedores para la venta a los numerosos clientes;
sistemas de software son construidos por contratistas para clientes específicos sobre una base
contractual. El “sistema” y “productos” términos se utilizan indistintamente en este texto a menos que
la distinción es importante; la distinción se aclarará en estos casos.
www.it-ebooks.info
1.3 ¿POR ADMINISTRACIÓN Y PROYECTOS software líder es difícil 7
200 5) no son factibles debido a limitaciones de programación entre las

actividades laborales establecen que algunas actividades no pueden comenzar
antes de que se completaron otras actividades de trabajo: no se puede diseñar
(una parte de un sistema) sin algunos requisitos correspondientes, no se debe
escribir código sin una especificación de diseño para el (la parte de) el sistema,
no se puede revisar o código de prueba hasta que un código ha sido escrito, no se
puede integrar módulos de software hasta que estén disponibles para la
integración, y así sucesivamente.
Añadir personas a un equipo de desarrollo de software no es así, por regla
general, a aumentar la productividad global de una manera lineal debido a que el
aumento de la sobrecarga de nicating comu- con las actividades de trabajo y de
coordinación entre la gente agregados disminuye la productividad del equipo
existente. Para citar Fred Brooks, una vez más, el número de rutas de
comunicación entre n trabajadores es n (n 1) / 2, que es el número de enlaces
en un gráfico totalmente conectado. Cinco trabajadores tienen 20 rutas de
comunicación 10, con 45 rutas y 20 tienen 190. El aumento del tamaño de un
equipo de programación de 5 a 10 miembros podría, por ejemplo, podría
aumentar la tasa de producción del equipo a partir de 5000 líneas de código por
semana a 7500 líneas de código por semana, pero no de 10.000 líneas de código
por semana como ocurriría con la escala lineal. En el mes laboral mítico, Brooks
describe este fenómeno como ley6 de Brooks:
Adición de mano de obra para un proyecto de software hace que

sea tarde tarde.
la ley de Brooks se basa en tres factores:
1. el tiempo necesario para que los miembros del equipo existentes para
adoctrinar a los nuevos miembros del equipo,
2. La curva de aprendizaje para los nuevos miembros, y
3. el aumento de la sobrecarga de comunicación que resulta de los miembros
nuevos y existentes que trabajan juntos.
la ley de Brooks no sería cierto si el trabajo asignado a los nuevos miembros no

invoca ninguna de estas tres condiciones.
Un símil que ilustra los problemas de desarrollo de software orientado al
equipo es la de un equipo de autores que escriben un libro como un proyecto de
colaboración; un equipo de autores se parece mucho a un equipo de
desarrolladores de software. En un principio, los requisitos de análi- sis debe
llevarse a cabo para determinar el tipo de libro que será escrita y las straints
confirma que se aplican a escribirlo. El número y las habilidades de los miembros
del equipo restringir el tipo y el tamaño del libro que puede ser escrito por el
equipo disponible de los autores dentro de un marco de tiempo especificado. Las
restricciones pueden incluir el número de personas en la escritura equipo, los
conocimientos y habilidades de los miembros del equipo, la fecha de terminación
requerida, y el hardware de procesamiento de textos y el software disponible para
ser utilizado.
A continuación, la estructura del libro se debe diseñar: el número de capítulos,
una breve sinopsis de cada uno, y las relaciones (interfaces) entre los capítulos
deben ser manera especificada. El libro puede estar estructurada en secciones que
contienen varios capítulos cada uno (subsistemas), o el texto puede estar
estructurada en múltiples volúmenes (un sistema de sistemas). La estructura
dinámica del texto puede fluir linealmente en el tiempo o puede moverse hacia
www.it-ebooks.info
atrás y hacia adelante en el tiempo entre capítulos sucesivos; primaria y
6
Ibídem, Pp. 25 y 274.
www.it-ebooks.info
8 INTRODUCCIÓN
líneas de la trama secundaria pueden ser intercalados. Una limitación importante

es el desarrollo de una estructura de diseño que permitirá a cada miembro del
equipo para llevar a cabo algún trabajo, mientras que otros miembros del equipo
están cumpliendo su trabajo para que las actividades de trabajo pueden realizarse
de forma paralela. Algunos libros son hábilmente estructurado para tener
múltiples finales; lectores elegir el que más le guste.
Los detalles de diseño que se decidirán incluyen el formato de diseño de texto,
tipos de letra a utilizar, una nota al pie y haciendo referencia a las convenciones y
directrices estilísticas (uso de la voz activa y pasiva, el uso de dialectos e
idiomas). Redacción del texto se produce dentro de un horario termined predeter-
de producción que incluye las críticas de otros miembros del equipo (revisiones
por pares) y revisiones independientes de correctores (verificación
independiente). Las revisiones determinados por las revisiones deben llevarse a
cabo. El objetivo del equipo de redacción es producir un texto sin costuras, que
parece haber sido escrito por una persona en un único entorno.
Una desviación de la narrativa planeada por uno o más miembros del equipo
podría producir un efecto dominó que requeriría extensa revisión del texto. Si el
libro terminado fuera de software, una sola puntuacion o error gramatical en el
texto se hacen del libro ilegible hasta que los escritores o su editor de textos
reparan el defecto. Un editor determina que cada iteración de los elementos del
texto satisface las condiciones puestas en ella por otros elementos (verificación).
Por último, las críticas de los críticos y las compras efectuadas por los lectores
determinar el grado en el que el libro satisface su propósito previsto en su
entorno previsto (validación).
Las diversas fases de desarrollo de la escritura (análisis, diseño de alto nivel,
diseño detallado, implementación, revisión por pares, una verificación
independiente, la revisión y validación ción) son actividades creativas y por lo
tanto rara vez se presentan en forma lineal, de forma secuencial. análisis Con-
conductos, preparar y revisar el diseño del texto, y la producción, revisión, y la
revisión de las diversas partes pueden solaparse, intercalada, y ITER ated. Los
miembros del equipo deben hacer cada una de sus tareas asignadas, coordinan su
trabajo con otros miembros del equipo, y comunicar ideas, problemas y cambios
de forma continua- ous. La narración anterior representa un enfoque denominado
plan impulsado a escribir un libro y, por analogía, con el desarrollo de software.
Una alternativa es buscar un enfoque ágil por el cual los miembros del equipo
comienzan con un concepto básico y evolucionar el texto de una manera iterativa.
• si el equipo es pequeño, digamos cinco o seis miembros (para limitar la

complejidad de la comunicación);
• si todos los miembros tienen en mente una comprensión común de la
estructura deseada del texto (es decir, una “metáfora diseño”);
• si hay un límite de páginas estricta y una fecha de finalización (las
restricciones del proyecto);
• si cada iteración se produce en uno o unos pocos días (para facilitar
revisiones en curso en la estructura; conocidos como “refactoring”); y
• Si el lector versado (conocido como el “cliente”) está disponible para revisar
cada iteración y proporcionar orientación de los contenidos de la siguiente
iteración.
En algunos casos, los miembros del equipo pueden trabajar en pares (

“programación en parejas”) para mejorar la sinergia de esfuerzos.
En realidad, la mayoría de los proyectos de software incorporan elementos de
www.it-ebooks.info
un enfoque impulsado por el plan y un enfoque ágil. En el ejercicio de un
enfoque ágil, los miembros del equipo deben
www.it-ebooks.info
1.4 La naturaleza de la limitaciones del proyecto 9
entender la naturaleza del producto deseado a entregar, se debe establecer una

metáfora de diseño, y las limitaciones de la programación, presupuesto, recursos
y tecnolo- gía que debe ser observada; así cierta definición de requerimientos,
diseño y planificación de proyectos debe hacerse. Aquellos que persiguen una
estrategia del plan impulsado a menudo persiguen un enfoque iterativo (ágil) para
desarrollar, verificar y validar el producto a entregar; manifestaciones frecuentes
proporcionan evidencia tangible del progreso y permitir la incorporación de los
cambios en forma incremental.
El enfoque adoptado en este texto es presentar un plan de estrategia impulsada,
basado en el desarrollo iterativo, que es adecuado para los proyectos más grandes
y complejos, y para mostrar cómo las técnicas se pueden adaptar y adaptada para
satisfacer las necesidades del pequeño, sencillo proyectos, así como los grandes y
complejos. Los modelos de proceso de desarrollo de software se presentan en el
Capítulo 2.
Con el tiempo los seres humanos han aprendido a conducir la agricultura, la
construcción y los proyectos de manufactura que emplean equipos de
trabajadores que cumplen las funciones eficientemente y effectively.7 Dado que
el software se caracteriza por la complejidad, la conformidad, la mutabilidad, y la
invisibilidad, y debido a los proyectos de software se llevan a cabo por equipos
de personas que participan en el trabajo en equipo-intelecto intensiva, que los
seres humanos no siempre son tan expertos en la realización de proyectos de
software como estamos en la realización de las clases tradicionales de proyectos
en la agricultura, la construcción y la fabricación. Sin embargo, las técnicas que
se presentan en este texto le ayudará a gestionar proyectos de software de manera
eficiente y efectiva, es decir, con el uso económico de tiempo y recursos para
lograr los resultados deseados.
Su papel como jefe de proyecto es planificar y coordinar las actividades de
trabajo de su equipo de proyecto para que el equipo pueda lograr más trabajando
de manera coordinada que podría llevarse a cabo por cada persona que trabaja
con total autonomía.
1.4 La naturaleza de la limitaciones del proyecto
Muchos de los problemas que se encontrará, o haber tenido, en los proyectos de

software son causados por dificultades de gestión y dirección (es decir, planificación,
estimación, medición, control, comunicación, coordinación y gestión del riesgo) en
lugar de cuestiones técnicas (es decir, el análisis , diseño, codificación y pruebas).
Estas dificultades se derivan de varias fuentes; algunos se pueden controlar como jefe
de proyecto y algunos no se puede. Factores que no puedes controlar se llaman
restricciones, que son limitaciones impuestas por los agentes externos sobre parte o la
totalidad del dominio operativo, los requisitos operacionales, los requisitos del
producto, el alcance del proyecto, el presupuesto, los recursos, la fecha de
finalización, y la tecnología de la plataforma. Tabla 1.1 enumera algunas limitaciones
típicas de proyectos de software y proporciona una breve explicación.
El dominio operativo es el entorno en el que se utilizará el software entregado.
dominios operacionales incluyen prácticamente todas las áreas de la sociedad
moderna, INCLUYENDO cuidado de la salud, las finanzas, el transporte, la
comunicación, el entretenimiento, los negocios y entornos de fabricación.
Comprender el dominio operacional en el que operará el software es esencial
para el éxito. Los requisitos operativos describen el
7
Para ser eficaz consiste en realizar una tarea sin perder tiempo ni recursos; para ser eficaz es obtener el
www.it-ebooks.info
resultado deseado.
www.it-ebooks.info
10 INTRODUCCIÓN
TABLA 1.1 limitaciones típicas en los proyectos de software

ConstraintExplanation
Operacional domainEnvironment de la usuarios
Operacional necesidades y requirementsUsers' deseos
Producto requirementsFunctional capacidades y calidad atributos
Científico knowledgeAlgorithms y datos estructuras
Proceso standardsWays de trabajo la realización de ocupaciones
Proyecto scopeWork actividades a ser consumado
ResourcesAssets disponibles para llevar a cabo una proyecto
BudgetMoney utiliza para adquirir recursos
Terminación dateDelivery fecha para el trabajo productos
Plataforma technologySoftware herramientas y hardware / software base
Negocio goalsProfit, la estabilidad, crecimiento
Ético considerationsServing mejores intereses de los seres humanos y sociedad
vista de los usuarios (es decir, la vista externa) del sistema a ser entregado.
Algunas de las características deseadas, como se especifica en los requisitos
operacionales, pueden estar más allá del estado actual de los conocimientos
científicos, ya sea en general o dentro de su organización. los requisitos del
producto son vistas de los desarrolladores (es decir, la vista interna) del sistema a
ser construido; que incluyen las capacidades funcionales y atributos de calidad
del producto entregado debe poseer con el fin de satisfacer los requisitos
operacionales.
Las normas de elaboración especificar las formas de realización de las
actividades de trabajo de los proyectos de software. Su organización puede tener
formas estandarizadas de la realización de actividades específicas, tales como la
planificación y estimación de proyectos, y la medición de los factores de
proyectos tales como la conformidad con el calendario, el gasto de los recursos, y
la medición de los atributos de calidad del producto en evolución. En algunos
casos, el cliente puede especificar normas y directrices para la realización de un
proyecto. Cuatro de los marcos más comúnmente usados para los estándares de
proceso son el Capability Maturity Model Integración (CMMI), ISO / IEEE
12207, el estándar IEEE 1058, y el medio de Proyectos Manage- del
Conocimiento (PMBOK). Elementos de estas normas y directrices están
contenidas en anexos a los capítulos de este texto.
El alcance de un proyecto es el conjunto de actividades que deben realizarse
para entregar un producto aceptable en la fecha prevista y dentro del presupuesto.
Los recursos son los activos, tanto corporativos y externos, que pueden ser
aplicados al proyecto. Los recursos tienen la calidad y cantidad de atributos; por
ejemplo, puede tener un número suficiente de desarrolladores de software
disponibles (cantidad de activos), pero es posible que no tenga las habilidades
necesarios (calidad de los activos). El presupuesto es el dinero disponible para
adquirir y utilizar los recursos; el presupuesto para su proyecto puede verse
limitada por lo que no se pueden utilizar los recursos dispo- capaces dentro de la
organización. La fecha de terminación es la fecha en que debe ser terminado el
producto y listo para su entrega. En algunos casos, puede haber varias fechas de
terminación en la que subconjuntos del producto final debe ser Ered deliv-.
La tecnología de plataforma incluye el conjunto de métodos, herramientas y
entornos de desarrollo utilizadas para producir o modificar un producto de
software. Los ejemplos incluyen herramientas para desarrollar y requisitos de
documentación y diseños, compiladores y depuradores de generaciones
www.it-ebooks.info
1.4 La naturaleza de la limitaciones del proyecto 11
eRate y comprobar el código, herramientas de control de versiones para realizar

un seguimiento de las versiones de los productos de trabajo de un proyecto en
evolución, y las herramientas para ayudar en la verificación de la pruebas de
software. La tecnología de plataforma también incluye los procesadores de
hardware y sistemas operativos en los que se desarrolla el software y en el que
funcionará (que puede ser el mismo o diferente). Uno o más aspectos de la
tecnología de la plataforma pueden ser obsoletos o de otra manera inapropiada
para el trabajo a realizar.
Objetivos de negocio puede limitar su proyecto para completar el producto tan
pronto como sea posible (para maximizar los ingresos a corto plazo), o para producir
la más alta calidad posible (para mantener la credibilidad con los clientes existentes).
Consideraciones éticas pueden limitar su proyecto a partir de la entrega de un
producto con defectos conocidos o desde el conocimiento poración de incor-
producto de la competencia adquirida por métodos poco éticos.
Algunos de los problemas más difíciles que se encontrará en la gestión de
proyectos de software surgen de establecer y mantener un equilibrio entre las
limitaciones en el alcance del proyecto, el presupuesto, los recursos, la tecnología
y la fecha de entrega programada:
1. ámbito de aplicación: el trabajo a realizar;

2. Presupuesto: el dinero para adquirir los recursos;
3. recursos: los activos para hacer el trabajo;
4. tecnología: métodos y herramientas que se utilizarán; y
5. fecha de entrega: la fecha en que el sistema debe estar listo para la entrega.
Se establece el equilibrio inicial entre estos factores en su plan inicial del

proyecto. El alcance de su proyecto puede cambiar durante la ejecución del
proyecto debido a los cambios en los requisitos del producto u otros factores tales
como el presupuesto o la fecha de entrega. Las restricciones en su presupuesto,
recursos, y el horario pueden cambiar debido a factores internos de la
organización, los cambios en el entorno operacional del producto a entregar, o las
presiones competitivas. Los cambios en el alcance del proyecto siempre deben ir
acompañados de cambios en el presupuesto, los recursos y la tecnología de
programación (tal vez) correspondiente.
Las limitaciones que figuran en la Tabla 1.1 reducen el espacio conceptual
disponible en el que planificar y llevar a cabo su proyecto. Por ejemplo, puede
que no sea posible entregar un producto satisfactorio usando 10 personas durante
12 meses, pero podría ser posible si el calendario se extendió a 15 meses o si el
número de personas que se aumentó de 10 a 15, o si los requisitos para el
producto se redujeron a la dad funcional- que puede ser entregado con una
calidad aceptable por 10 personas en 12 meses. Además de las limitaciones que
figuran en la Tabla 1.1, puede haber factores políticos y sociológicos que no se
puede controlar.
Algunas de las primeras cosas que debe hacer en la gestión de un proyecto de
software son:
1. establecer los criterios de éxito para su proyecto,

2. aclarar las restricciones sobre el proyecto y el producto, y
3. determinar si existe una posibilidad razonable de que satisfacen los criterios
de éxito dentro de las limitaciones.
Las restricciones deben aclararse para determinar si existe alguna flexibilidad

www.it-ebooks.info
o la posibilidad de compensaciones entre las limitaciones debido a que menos o
más flojas restricciones
www.it-ebooks.info
12 INTRODUCCIÓN
aumentar las opciones para la planificación y ejecución de su proyecto. Es

posible que haya lazos prioridades entre los criterios de éxito de la entrega de un
producto aceptable a tiempo y dentro del presupuesto; por ejemplo, la entrega en
horario puede ser más importante que el número de características entregado, o
características suministrado puede ser más importante que el costo. Puede haber
criterios de éxito adicionales, tales como el establecimiento de una relación
tionship trabajar con un nuevo cliente, o el desarrollo de una arquitectura de
producto que proporciona una base para el desarrollo de futuros productos, es
decir, el desarrollo de una arquitectura de la línea de productos que consta de
elementos de base y configurable elementos.
Los factores que se tienen (o deberían tener) alguna influencia sobre incluir:
1. el establecimiento de los criterios de éxito,

2. la negociación de las restricciones del proyecto,
3. la obtención de consenso entre los interesados en el proyecto de un
conjunto inicial de requisitos funcional, y
4. la obtención de consenso entre los interesados en el proyecto de un
conjunto inicial de los requisitos del producto.
Los factores que usted será responsable de las siguientes:
5. hacer estimaciones y planes iniciales;

6. el mantenimiento de un equilibrio entre los requisitos, calendario, y los
recursos que el proyecto evoluciona;
7. medir y controlar el progreso de la obra;
8. líder del equipo del proyecto y la coordinación de sus actividades de
trabajo;
9. la comunicación con las partes interesadas; y
10. la gestión de los factores de riesgo que podrían afectar o impedir el logro
de un resultado exitoso.
Las principales actividades de gestión de proyectos son la planificación y la

estimación, mensurables ing y controlar, comunicar y dirigir y controlar los
factores de riesgo. La planificación y la estimación se refieren a la determinación
del alcance de las actividades que deben llevarse a cabo, la estimación de
esfuerzo y calendario para el proyecto en su conjunto, y el desarrollo de
estimaciones y planes para cada actividad de trabajo importante. La planificación
de medición implica el establecimiento de un sistema de recolección de datos y
que se utilizará para determinar e informar el estado real de las actividades de
trabajo y productos de trabajo sobre una base continua de informes. De control
implica la aplicación de acciones correctivas cuando el estado real, tal como se
indica por las mediciones, no está de acuerdo con el estado planificada.
La comunicación implica establecer y mantener canales de comunicación
adecuados entre todas las partes implicadas para que todos estén al tanto de los
avances y dificultades, y para que se les recuerda constantemente de los objetivos
y criterios de éxito para el proyecto. Líder se refiere a proporcionar dirección a,
la eliminación de bloques ROAD- para, y el mantenimiento de la moral del
personal del proyecto.
La gestión del riesgo se refiere a la identificación de factores de riesgo
(problemas potenciales), tanto al inicio como sobre una base continua; el
seguimiento de los factores de riesgo identificados; y participar en actividades de
www.it-ebooks.info
mitigación de riesgos, tales como la preparación de planes de contingencia y los
eje- cuting cuando sea necesario.
www.it-ebooks.info
1.5 UN MODELO DE FLUJO DE TRABAJO PARA LA GESTIÓN DE
PROYECTOS DE SOFTWARE 13
1.5 MODELO DE UN FLUJO DE TRABAJO PARA LA GESTIÓN DE

PROYECTOS DE SOFTWARE
El objetivo principal de un proyecto de software es desarrollar y entregar uno o

más productos de trabajo aceptables dentro de las limitaciones de las
características requeridas, atribuye calidad, el alcance del proyecto, el
presupuesto, los recursos, la fecha de finalización, la tecnología y otros factores.
Los productos de trabajo para ser entregados (por ejemplo, código objeto,
materiales de formación, y las instrucciones de instalación) resultado del flujo de
productos de trabajo intermedios que son producidos por y fluyen a través de los
procesos de trabajo (requisitos, escenarios de diseño, código fuente, y de prueba).
El modelo de flujo de trabajo de proyecto utilizado en este texto se presenta en
la Figura 1.1. Todos los modelos, incluyendo el de la figura 1.1, son
abstracciones de las situaciones reales que hacen hincapié en algunos aspectos de
interés y suprimen detalles que no son importantes para los fines del modelo.
Detalles importantes se pueden expresar en modelos subordinadas. modelos
subordinadas a la figura 1.1 se presentan a lo largo de este texto.
La figura 1.1 indica algunos de los procesos que apoyan la actividad primaria
de desarrollo de productos; que incluyen Verificación y Validación (V & V),
garantía de calidad de los procesos de trabajo y productos de trabajo (QA),
Gestión de la Configuración (CM), y otros. Algunos procesos de apoyo y sus
propósitos se enumeran en la tabla
1.2. Cada proceso de soporte debe llevarse a cabo de conformidad con un modelo
bien definido para llevar a cabo las actividades de trabajo de ese proceso.
El modelo de la figura 1.1 se denomina un modelo de proceso, ya que hace
hincapié en las actividades de trabajo y el flujo de productos de trabajo entre las
actividades de trabajo. Cada actividad de trabajo en un modelo de proceso produce
uno o más productos de trabajo que proporcionan entradas a las actividades de
trabajo posteriores. Por producto del trabajo nos referimos a cualquier documento
producido por un proyecto de software (incluyendo el código fuente). Algunos
productos de trabajo se entregan al cliente (los llamados productos entregables de
trabajo), mientras que otros son productos de trabajo intermedios desarrollados para
avanzar en el proceso creativo de resolución de problemas de una manera ordenada.
Algunos de los productos de trabajo de los proyectos de software se enumeran en la
Tabla 1.3.
Cambio RequestsProblem Informes
Empieza
aqui requisitos
Proceso de
y limitaciones
desarroll
o
Cliente Planificaci Asigna termina
ón y Activida Verificación aquí
d ciones y Validación
Los replanifica de
ción Definición
gestores trabajo
Seguro de Entregar
directivas y
restricciones calidad Producto
la estimación y s de
Re-estimar trabajo
Controlador Configuración
administración
Retenció
n de Otros
datos procesos
de apoyo
Informes del Los informes
proyecto informes Medición de estado
www.it-ebooks.info
FIGURA 1.1 Un modelo de flujo de trabajo para la gestión de proyectos de
software
www.it-ebooks.info
14 INTRODUCCIÓN
TABLA 1.2 Algunos procesos de apoyo para el desarrollo de software

Secundario ProcessPurpose
Configuración Control managementChange, la gestión de la línea de base,
auditorías de producto, el producto se acumula
VerificationDetermining el grado en que el trabajo productos cumplen las condiciones
que les impone otros productos de trabajo y los
procesos de trabajo
ValidationDetermining el grado de aptitud de los trabajos productos para su uso
previsto en sus entornos destinados
Calidad AssuranceDetermining conformidad de los procesos de trabajo y trabajo
productos a las políticas, planes y procedimientos
DocumentationPreparation y actualización de productos de trabajo
intermedios y entregables
Desarrollador trainingMaintaining adecuada y apropiada habilidades
El usuario y el operador habilidades necesarias para utilizar con eficacia y trainingImparting
funcionar
sistemas
TABLA 1.3 Algunos documentos de trabajo de productos producidos por los proyectos de
software
DocumentContent de Documento
Proyecto planRoadmap para la realización de la proyecto
Estado reportsState de progreso, costos, plazos, y notas de reunión y de calidad
minutesIssues, problemas, recomendaciones, y
resoluciones
correo electrónico messagesOngoing comunicaciones
Operacional requirementsUser necesidades, deseos y esperanzas de heredar
Técnico características y specificationProduct atribuye la calidad del
diseño arquitectónico documentComponents y las interfaces
Diseño detallado specificationAlgorithms, estructuras de datos, y la interfaz de detalles
de módulos individuales
Fuente codeProduct implementación
Prueba planProduct criterios de verificación, prueba escenarios e instalaciones
Referencia manualProduct enciclopedia
Ayuda messagesGuidance de usuarios
Lanzamiento notesKnown problemas, consejos, y directrices
Instalación instructionsGuidance de operadores
guideGuidance de mantenimiento para mantenedores
Como se ha observado Michael Jackson, toda la descripción de un sistema de

software o producto suele ser demasiado complejo para toda la descripción que
se escribe directamente en un lenguaje de programación, por lo que debemos
preparar diferentes descripciones en diferentes niveles de abstracción, y para
diferentes propósitos [Jack02 ]. Tenga en cuenta que cada uno de los productos
de trabajo que figuran en la Tabla 1.3 es un documento; desarrolladores de
software y administradores de proyectos de software no producen artefactos
físicos que no sean documentos, que pueden existir en forma impresa o
electrónica.
Como se ilustra en el modelo de flujo de trabajo representada en la Figura 1.1,
un proyecto de software es iniciado por el cliente y de administración. Un cliente
es la persona u organización que
www.it-ebooks.info
1.5 UN MODELO DE FLUJO DE TRABAJO PARA LA GESTIÓN DE
PROYECTOS DE SOFTWARE 15
proporciona los requisitos para y acepta los productos de trabajo entregables. Los
clientes pueden colocar restricciones en un proyecto, como la especificación de
una interfaz requerida de base de datos (una restricción de producto) o la fecha en
que el sistema entregado debe estar disponible para su uso (una restricción de
proceso). Los gerentes incluyen su gestión y que, el director del proyecto. Los
gerentes especifican las restricciones y directivas. Una restricción proceso de su
administrador podría poner un límite en el número de personas disponibles para
llevar a cabo el proyecto; una directiva de gestión podría requerir que todos los
proyectos de software en la organización realizan una actividad de diseño. Usted,
el director del proyecto, puede emitir las Directivas que requieren que el diseño
se documentará mediante UML (lenguaje universal de modelado) y que una o
varias revisiones de diseño se celebrarán.
Requisitos, restricciones y directivas suministran las entradas para el proceso
de planificación, que es (o debería ser) una actividad de grupo dirigida por usted,
el director del proyecto. Usted debe involucrar al cliente, miembros
seleccionados del equipo de desarrollo, y otros actores principales en el proceso
de planificación. La planificación implica la estimación. Factores que deben ser
estimados inicialmente incluyen un calendario para la realización de las
principales actividades de trabajo; tipos y cantidades de recursos necesarios,
cuándo van a ser necesarias, y por cuánto tiempo; y los hitos del proyecto (puntos
en el tiempo cuando se evalúa el progreso). La estimación se logra mejor
mediante el uso de datos históricos de un repositorio de datos. Los datos en la
realización de su proyecto pueden ser colocados en un repositorio para ayudar en
la estimación de los proyectos futuros. Los datos intermedios pueden ser
retenidos para evaluar el progreso y preparar estimaciones de terminación,
La salida de su proceso de planificación incluirá la identificación de las
funciones que deben desempeñar en la realización del proyecto, que se traduce en
la asignación de personal a esas funciones. Durante la planificación inicial, las
principales actividades de trabajo que ser planificado incluyen el desarrollo de
software y los diversos procesos de apoyo tales como la configuración Hombre-
agement, processandproductqualityassurance, verificación, validación,
usertraining; además de otras actividades necesarias que constituyen el alcance
de su proyecto. Los planes detallados para estas actividades evolucionarán a
medida que el proyecto evoluciona.
Durante la ejecución del proyecto, se recogen datos y los informes de estado
se pre recortaron de forma periódica por usted y su personal. Los informes de
estado serán utilizados por usted (el director del proyecto), sus clientes, sus
directivos, grupos de apoyo, y otros interesados en el proyecto. Los informes de
estado se comparan los avances previstos para el progreso real; que pueden hacer
que usted y su cliente, trabajando juntos, para revisar los planes y requisitos, o
puede que, por ejemplo, reasignar parte del personal a los diferentes roles de
proyecto (por ejemplo, un diseñador de software podría ser movido al equipo
ción validación independiente). Los datos de estado también se utilizan para
proporcionar una base para estimar el progreso futuro basado en el progreso hasta
la fecha (que puede resultar en la replanificación), y se conserva para
proporcionar una base de estimación para proyectos futuros.
Los informes de problemas se generan a defectos de documentos descubiertos
en los productos de trabajo que deben ser modificados. Los informes de estado,
los nuevos requisitos, y cambios en los requisitos, restricciones, directivas, así
como los informes de problemas proporcionan los datos necesarios para la
actualización permanentem ente, elaborar y revisar su plan de proyecto.
Cada organización que desarrolla y mantiene el software, incluyendo el suyo,
www.it-ebooks.info
debe tener uno o más modelos de flujo de trabajo de desarrollo de software que
representa las principales actividades de trabajo y flujo de productos de trabajo.
Cada miembro de la organización debe estar familiarizado con el modelo (s) de
flujo de trabajo y comprender las formas en que sus actividades de trabajo y
productos de trabajo encajan en el modelo (s). Cada uno en su software de
organización desarrollo debe ser capaz de dibujar y describir el modelo de flujo
de trabajo (s)
www.it-ebooks.info
dieciséis INTRODUCCIÓN
utilizado en la organización. Si hay más de un modelo de flujo de trabajo, todo el

mundo debe entender los tipos de proyectos para los cuales los diversos modelos
son apropiados.
1.6 Estructuras organizativas para los proyectos de software
Los proyectos son de una sola vez, los eventos transitorios que se inician para
lograr un propósito específico y se terminan cuando se alcanzan los objetivos del
proyecto (y, a veces se cancelan antes de alcanzar los objetivos). Existe un
proyecto dentro del contexto de la organización en la que se lleva a cabo; cada
proyecto debe cumplir con el modelo estructural de la organización.
Departamentos que llevan a cabo proyectos de ingeniería, incluyendo los
proyectos de software, están organizados típicamente en una de cuatro maneras:
la estructura funcional, estructura del proyecto, estructura de la matriz o
estructura híbrida.
1.6.1 Las estructuras funcionales

Como su nombre indica, los trabajadores de una organización funcional se
agrupan por las funciones que realizan. Los grupos funcionales pueden ser
orientado al proceso o producto orientado. Un grupo funcional orientada al
proceso podría, por ejemplo, se especializan en ingeniería de los requisitos, otro
en el diseño de interfaces de usuario, otra en el diseño e implementación de
código, otra en la validación del producto, y otro más en la formación de
usuarios. Cuando se organizan por especialidad producto, un grupo podría
especializarse en la comunicación de datos, otro de los sistemas de bases de
datos, otro en las interfaces de usuario, y otro más en algoritmos numéricos. La
figura 1.2 ilustra una organización funcional orientado al proceso, y la figura 1.3
ilustra un grupo funcional orientado al producto.
Cada grupo funcional tiene un gerente funcional cuyo trabajo consiste en
adquirir y mantener la cantidad y calidad de los trabajadores necesarios para
apoyar los proyectos dentro de la organización, formarlos como sea necesario,
proporcionar las herramientas necesarias, y la coordinación nar sus actividades de
trabajo en varios proyectos. Diferentes miembros del grupo aplican su
Gerente de
departamento
requisitos Design Grupo de ...

Grupo Group aplicación Grupo
Figura 1.2 Una organización funcional orientado al proceso
Gerente de
departamento
Grupo de U a o
Interfaz s r
de u i
www.it-ebooks.info
Grupo algoritmos Bas ...
e Grupo
d
e
d
at
o
s
G
ru
p
o
FIGURA 1.3 Una organización funcional orientado al producto
www.it-ebooks.info
1,6 estructuras organizativas para los proyectos de software 17
experiencia para diferentes proyectos, según sea necesario. Como jefe de

proyecto en una organiza- ción funcional, responsable de la entrega de un
producto aceptable a tiempo y dentro del presupuesto, su capacidad para llevar a
cabo su proyecto con éxito dependerá de su habilidad para trabajar con los
gerentes funcionales y sus miembros del equipo para completar los diversos
trabajos actividades y desarrollar los diversos productos de trabajo para su
proyecto.
1.6.2 Estructuras de proyectos

En una organización puramente estructurado proyecto, que, como director del
proyecto, tiene plena autoridad y responsabilidad para la gestión de presupuesto y
recursos. A adquirir las clases de trabajadores que necesita para realizar su
proyecto y todos los miembros del proyecto reportará directamente a usted; usted
puede adquirir sus trabajadores de los grupos funcionales o podría contratar
desde el exterior. Usted, el director del proyecto, tiene la autoridad para adquirir
los miembros del personal dentro de las limitaciones de su presupuesto y para
eliminarlos cuando ya no son necesarios o no, se ajustan a sus expectativas. Su
capacidad para llevar a cabo con éxito su proyecto depende de la adquisición de
la cantidad y calidad de trabajadores necesarios, formándolos como sea
necesario, proporcionando las herramientas necesarias, y coordinar sus
actividades de trabajo. Una organización estructurada proyecto se ilustra en la
Figura 1.4.
1.6.3 Estructuras de matriz

El objetivo de una organización matricial es obtener las ventajas de ambas
estructuras funcionales y de proyectos; especialistas funcionales son asignados a
los proyectos según sea necesario y trabajar para usted, el director del proyecto,
mientras que la aplicación de sus conocimientos para su proyecto. Cuando se
hayan completado sus tareas, regresan a sus grupos de funciones y se les asigna,
según sea necesario, con otros proyectos. Los trabajadores de una organización
matriz así tienen dos jefes: el gerente funcional y su jefe de proyecto.
Un ejemplo de una organización matriz se ilustra en la Figura 1.5. Los grupos
funcionales pueden ser, por ejemplo, un grupo de interfaz de usuario, un grupo de
algoritmos, un grupo base de datos, y un grupo protocolo de comunicaciones. Los
números de la matriz indican el número de trabajadores de cada tipo funcional
asignado a cada proyecto; por ejemplo, proyecto # 1 tiene 10 miembros: 2 de # 1
(interfaz de usuario) tipo funcional, 5 de tipo funcional # 3 (base de datos), y 2 de
tipo funcional # 4 (comunicaciones). Proyecto # 3 es el más grande; Cuenta con
23 miembros. Actualmente 6 miembros del grupo de interfaz de usuario se
asignan a este proyecto, 8 del grupo algoritmos, 2 del grupo base de datos y 7 de
comunicaciones.
Las organizaciones matriciales pueden ser caracterizados como débiles o
fuertes, dependiendo de la autoridad relativa de los gerentes funcionales y los
responsables del proyecto. En una fuerte
Gerente de
departamento
www.it-ebooks.info
Proyecto # 1 Proyecto # 2Project # 3 #n proyecto
Figura 1.4 Una organización orientada a proyectos
www.it-ebooks.info
18 INTRODUCCIÓN
Departame
nto Gerente
Funcional Funcional Funcional Funcional

Gestor # 1 Gestor # 2 Gestor # 3 Gerente #
Gerente de 4
Proyecto # 2 5 3
1
Gerente de
3 4 7 9
Proyecto #
2
6 8 2 7
Gerente de
Proyecto #
3 1 2 4 6
# m Director
de Proyectos
Figura 1.5 Una organización matriz estructurada
matriz, los gerentes funcionales tienen autoridad para asignar a los trabajadores a
los proyectos, y los directores de proyectos deben aceptar los trabajadores
asignados a ellos. En una matriz débil, el director del proyecto controla el
presupuesto del proyecto, puede rechazar los trabajadores de grupos funcionales
y contratar a los trabajadores fuera de si los grupos funcionales no tienen
suficientes lazos cantida- o cualidades de los trabajadores.
Cuando una organización matriz realiza según lo previsto, los trabajadores
funcionales aplican sus especialidades para diferentes proyectos, bajo la
dirección de los directores de proyectos, con el tiempo, manteniendo la
pertenencia a un grupo de expertos de ideas afines. Dos problemas que pueden
ocurrir en las organizaciones matriciales son (1) los conflictos entre los gerentes
funcionales y los directores de proyectos sobre la asignación de los recursos de
los trabajadores (que pone a los trabajadores en situaciones insostenibles), y (2)
cambio frecuente de los trabajadores de un proyecto a medida que se producen
las crisis (conocido como modo de “lucha contra el fuego”).
1.6.4 Las estructuras híbridas

Pocos, si alguno, las organizaciones son puramente funcional, proyecto, o matriz
en la naturaleza. En una organización puramente funcional, no habría gestores de
proyectos; un coordinador a nivel de departamento sería asignar tareas a los
grupos funcionales y trabajar productos se pasó de un grupo a medida que estén
disponibles. En una organización puramente proyecto, éste sería una
organización totalmente independiente. El director del proyecto sería responsable
de las instalaciones físicas, servicio de limpieza, recursos humanos (es decir, la
contratación, despido, nómina, seguro de salud, y la resolución de conflictos), y
otras funciones de organización. Del mismo modo los proyectos organizados en
formato de matriz no operan de manera aislada sino dependen de otros elementos
funcionales de la organiza- ción para proporcionar las instalaciones físicas, el
procesamiento de nóminas, y servicio de limpieza. Figura
1.6 ilustra el continuo de la organización de la función pura a proyecto puro con
organizaciones matriciales que ocupan la región media [Youk77].
Usted, como director del proyecto, tendrá menos o más responsabilidades y
www.it-ebooks.info
más o menos limitaciones en su autoridad en función de si su organización tiene
predominantemente una matriz o estructura del proyecto funcional.
www.it-ebooks.info
1.7 La organización del equipo PROYECTO 19
100% 0%
Funcional
énfasis funcional Matriz El énfasis

del
proyecto
Proyecto
0% 100%
Coordinador del Gerente de
proyecto proyecto
FIGURA 1.6 El continuo organizativa [Youk77]
1.7 La organización del equipo PROYECTO
La forma en que se estructura su organización determina la forma en que se

adquiere los miembros de su proyecto. Es su trabajo para organizar su equipo de
proyecto, y para participar, según sea apropiado como miembro de otros equipos,
tales como el sistema Engineer- ing equipo.
1.7.1 El Equipo de Ingeniería de Sistemas

Las responsabilidades de los ingenieros de sistemas incluyen:
• definir los requisitos operacionales;

• especificando los requisitos del sistema;
• desarrollar el diseño del sistema;
• la asignación de los requisitos del sistema a los componentes del sistema;
• la integración de los componentes del sistema a medida que estén disponibles;
• verificar que el sistema para ser entregado es correcta, completa y consistente
con respecto a sus especificaciones técnicas; y
• funcionamiento del sistema de validación con sus usuarios previstos en su
entorno funcional previsto.
La ingeniería de sistemas, cuando existe como una entidad separada, es

típicamente una función de la especialidad en una organización. Los ingenieros
de sistemas pueden ser asignados a los proyectos de un grupo funcional dentro de
una organización matricial, o pueden proporcionar ing consul- interna para
proyectos mientras permanecen en su grupo funcional. Los ingenieros de
sistemas deben ser expertos en sus dominios de cliente y conocedor de capaci-
dades de su organización; que son más propensos a ser miembros de la
organización a largo plazo que para ser contratados fuera de la organización por
un jefe de proyecto.
Tenga en cuenta que los ingenieros de sistemas son especialistas no
componentes; que son generalistas (que entienden debe entender) los dominios
operativos de sus clientes y usuarios y las capacidades de sus organizaciones para
desarrollar sistemas para esos dominios.
www.it-ebooks.info
20 INTRODUCCIÓN
Los ingenieros de sistemas trabajan con especialistas de componentes para

especificar colecciones de componentes que satisfagan las necesidades del
usuario y las expectativas del cliente.
Un equipo de ingenieros de sistema para un sistema complejo, intensivos en
software debe incluir hardware, software y especialistas en factores humanos
como apropiados para los distintos tipos de hardware, software y operaciones
manuales del sistema previsto. Usted, como gerente del proyecto de software
para un sistema de software intensivo, debe ser (debe ser) un miembro del equipo
de ingeniería de sistemas. Además la persona responsable técnico en su equipo de
software (si no es esa persona) y un representativo del grupo que va a mantener la
parte de software del sistema (si eso no es su equipo) también deben ser
miembros del sistema Equipo de ingeniería.
1.7.2 El Equipo de Ingeniería de Software

Cada proyecto de software, ya sea independiente o un subproyecto de un
programa a nivel de sistema, debe incluir un jefe de proyecto, una ventaja de
arquitecto diseñador / software, y uno o más equipos de desarrollo pequeños,
cada uno con un jefe de equipo designado. En un proyecto pequeño (hasta 10
miembros), el papel de líder del equipo, el director del proyecto, y el diseñador
de plomo pueden ser jugados por un solo individuo (usted). O bien, un jefe de
proyecto puede ser asignada sobre una base a tiempo parcial con otro individuo
que juega el papel de diseñador jefe y líder del equipo. Para los proyectos de
tamaño intermedio (11 a 20 miembros), habrá (debe haber) separan a las personas
que juegan el papel de diseñador jefe y director del proyecto a tiempo completo.
En proyectos grandes (más de 20 miembros), puede haber un equipo de diseño
con un arquitecto en jefe designado, los miembros del personal de apoyo al
director del proyecto, y varios equipos de desarrollo.
Figura 1.7 ilustra un modelo jerárquico de la organización de proyectos de
software que puede ser expandido o contraído para acomodar varios tamaños de
Cliente
Gerente de
proyecto
Arquitecto de
software
Equipo Equipo Líder del V&V CM XX

Líder # 1 Líder # 2 Equipo # 3
... ...
Miembr Miembr
o o
Miembr Miembr
o o
Cada equipo tiene de 2 a 5
miembros más un jefe
de equipo
V & V: Verificación y validación
CM: Configuration Management
XX: otros procesos de apoyo
FIGURA 1.7 Un modelo de organización para proyectos de software

www.it-ebooks.info
1.8 MANTENIMIENTO DE LA VISION PROYECTO Y EL visión del producto 21
Un proyecto muy pequeño (5 o menos miembros) puede tener sólo un equipo

cuyo líder es el gerente y el software arquitecto del proyecto; un proyecto que
tiene de 5 a 10 miembros puede incluir dos equipos y un arquitecto del proyecto
encargado / software. proyectos de tamaño intermedio tendrán un individuo que
juega el papel de jefe de proyecto y otro como diseñador de plomo; un proyecto
que tiene 20 desarrolladores de software podría tener 4 equipos de
5 miembros, con un miembro de cada equipo que juega el papel de líder del
equipo. Para proyectos de más de 50 miembros, los líderes de los equipos
representados en la figura 1.7 serán los administradores de subsistemas y los
diseñadores de subsistemas con los jefes de equipo y sus equipos de informes a
los mismos; un proyecto que tiene 100 desarrolladores de software puede ser
descompuesto en 4 subsistemas con, por ejemplo, 5 equipos de 5 asignados a
cada subsistema.
Una estructura de proyecto jerárquica, tal como se representa en la Figura 1.7,
por lo tanto proporciona un modelo flexible que puede ser expandido y contraído
como las necesidades de los diversos proyectos dictan. El propósito de las
estructuras jerárquicas no es restringir el flujo de comunicación dentro del
proyecto, sino más bien proporcionar actividades bien definidas de trabajo, los
roles, las autoridades y las responsabilidades en cada nivel de la jerarquía que
minimiza la necesidad de comunicación entre los diferentes grupos. caminos
comu- nicación entre los equipos no están restringidos a la jerarquía; las rutas de
comunicación son redes informales que se establecen y disuelto en su caso de
forma dinámica.
Para facilitar la comunicación, un principio fundamental de análisis y diseño
de software es que los requisitos deben ser divididos y el diseño estructurado de
manera que el trabajo de cada equipo pequeño puede realizar de forma
concurrente con el trabajo de otros equipos. La razón para limitar el tamaño de
cada equipo es controlar el número de vías de comunicación intensiva entre los
desarrolladores de software que se dedican a actividades de trabajo
estrechamente coordinados. Como se mencionó anteriormente, las rutas de
comunicación se pueden modelar como enlaces en un gráfico totalmente
conectado donde cada miembro del equipo es un nodo en el gráfico. El número
de enlaces en un gráfico totalmente conectada de n nodos es n (n 1) / 2. por lo
tanto cinco miembros tienen 10 caminos; 10 miembros tienen 45.
La necesidad de partición de la obra en actividades de trabajo bien definidas
para múltiples equipos ya sea por función de proceso (por ejemplo, diseño,
codificación, pruebas) o la función del producto (por ejemplo, base de datos,
algoritmos, interfaz de usuario) es particularmente importante si los miembros
del equipo residen en grupos funcionales o están distribuidos geográficamente.
En estos casos el trabajo a realizar debe ser particionada de manera que cada
grupo funcional o grupo geográfico pueden proceder con sus actividades de
trabajo con un alto grado de autonomía con respecto a los otros grupos.
1.8 MANTENER la visión del proyecto Y EL visión

del producto
Cada proyecto de software, grandes o pequeños, simples o complejas, debe

mantener la visión de proceso (la hoja de ruta del proyecto) y la visión del
producto (las metas para el producto) de principio a fin; de lo contrario, es fácil
perder de vista de la visión y los objetivos en medio de las actividades diarias de
trabajo de un proyecto. Usted, como el director del proyecto, es el guardián de la
www.it-ebooks.info
visión de proceso, que se documenta en el plan del proyecto (y se actualiza a
medida que evoluciona el proyecto). La arquitectura de software es el guardián
de la visión del producto,
www.it-ebooks.info
22 INTRODUCCIÓN
que está documentado en los requisitos y especificaciones de diseño

arquitectónico (y se actualiza como el producto evoluciona) 0,8
El jefe de proyecto puede ser comparado con un productor de la película y el
software arquitect a un director de cine. El productor tiene la responsabilidad
general de horarios, presupuestos, recursos, relaciones con los clientes, y la
entrega de un producto satisfactorio a tiempo y dentro del presupuesto. El
director es responsable del contenido del producto. ductor pro y el director deben
trabajar juntos para mantener y comunicar constantemente la visión del proceso y
la visión del producto en el reparto de los desarrolladores y el apoyo personal,
así como todos los demás interesados en el proyecto.
Fred Brooks observa que el productor y el director pueden ser la misma
persona en un proyecto pequeño (de cinco a siete desarrolladores), pero tienen
que ser diferentes individuos en proyectos de mayor envergadura debido a las
habilidades requeridas diferentes y el número de tareas a realizar. Como señala
Brooks, si usted, como jefe de proyecto (productor) no son también el director (es
decir, el diseñador jefe), debe “anunciar autoridad técnica del director. . . . Para
que esto sea posible, el productor y el director deben ver por igual en la filosofía
técnica fundamental; deben hablar a cabo las principales cuestiones técnicas PRI
vately, antes de que realmente se convierten oportuna; y el productor debe tener
un gran respeto por la destreza técnica del director.”9 Hay que añadir que, por el
contrario, el director debe tener un gran respeto por la destreza de dirección del
productor.
1.9 Marcos, estándares y directrices
Un marco de proceso es un modelo de proceso genérico que se puede adaptar y

adaptada para ajustarse a las necesidades de los proyectos y organizaciones
particulares. Un estándar de ingeniería es una codificación de métodos, prácticas
y procedimientos que por lo general se desarrolla y respaldados por una sociedad
profesional o agencia independiente. Directrices son declaraciones pragmáticos
de las prácticas que se han encontrado para ser eficaz en muchas situaciones
prácticas.
Algunos conocidos marcos, normas y directrices para la ingeniería de software
y las URL asociadas son:
• el Modelo de Madurez de la Capacidad® Integración para el desarrollo (CMMI

v1.2-DEV-) [www.sei.cmu.edu/cmmi/models];
• ISO / IEC e IEEE / EIA 12207 [www.iso.org], [Standards.ieee. org /
software];
• IEEE / EIA Standard 1058 [standards.ieee.org/software]; y
• la Dirección de Proyectos (PMBOK ®) [Www.pmibookstore. org].
Los elementos de estos modelos que son relevantes para la gestión y el líder de
proyectos de software se presentan en los apéndices de los capítulos de este
texto, incluyendo el Apéndice 1A a este capítulo.
8
Ibídem, Pp. 79-83.
9
Ibídem, pag. 79.
www.it-ebooks.info
1,11 DESCRIPCIÓN GENERAL DEL
TEXTO 23
1.10 Puntos clave de CAPÍTULO 1
• Un proyecto es un conjunto coordinado de actividades que tienen lugar

dentro de un marco de tiempo específico para alcanzar objetivos específicos.
• Las actividades principales de la gestión de proyectos de software son la
planificación y estimación; medición y control; comunicarse, coordinar y
dirigir; y la gestión del riesgo.
• proyectos de software son inherentemente difícil porque el software es
complejo, capaz de cambio-, conformables, e invisible.
• proyectos de software se llevan a cabo por equipos de personas que
participan en el trabajo en equipo-tual lect intensiva.
• restricciones del proyecto consisten en limitaciones impuestas por los
agentes externos sobre parte o la totalidad del dominio operativo, los
requisitos operacionales, los requisitos del producto, el alcance del proyecto,
el presupuesto, los recursos, la fecha de finalización, y la tecnología de la
plataforma.
• Un modelo de flujo de trabajo representa las actividades de trabajo y el flujo de
productos de trabajo entre las actividades de trabajo en un proyecto de software.
• Toda la descripción de un sistema de software o producto suele ser
demasiado complejo para toda la descripción que se escribe directamente en
un lenguaje de programación, por lo que debemos preparar diferentes
descripciones en diferentes niveles de abstracción, y para diferentes
propósitos.
• Las organizaciones que llevan a cabo proyectos de software utilizan
funcional, proyecto, matriz débil, y las estructuras matriciales fuertes.
• proyectos de software organizados de manera jerárquica proporcionan
actividades bien definidas de trabajo, los roles, las autoridades y las
responsabilidades de cada nivel en el archy quía; jerarquías pueden ampliar y
reducir el tamaño para adaptarse a las necesidades de cada proyecto.
• Los requisitos deben ser asignados y el diseño estructurado de manera que el
trabajo de cada equipo pequeño puede realizar de forma concurrente con el
trabajo de otros equipos.
• El director del proyecto mantiene la visión del proyecto, tal como se
documenta en el plan del proyecto, y el arquitecto de software mantiene los
objetivos del producto, como se documenta en los requisitos y el diseño
arquitectónico.
• Un marco de procesos de software es un modelo de proceso genérico que se
puede adaptar y adaptada para ajustarse a las necesidades de los proyectos y
organizaciones particulares.
• Un estándar de la ingeniería de software es una codificación de métodos,
prácticas y procedimientos, generalmente desarrollados y aprobados por una
asociación profesional o agencia independiente.
• SEI, ISO, IEEE, y PMI proporcionar marcos de procesos, normas y líneas
directrices que contienen información relevante para la gestión de proyectos
de software (véase el Apéndice 1A de este capítulo).
1.11 RESUMEN DEL TEXTO
Este texto está organizado en 11 capítulos. Los 3 primeros capítulos presentan el

www.it-ebooks.info
contexto en el que se llevan a cabo proyectos de software. En este capítulo se
proporciona una visión general de y una introducción a la gestión de proyectos de
software. El capítulo 2 presenta comúnmente usado
www.it-ebooks.info
24 INTRODUCCIÓN
modelos de procesos de desarrollo de software y la gestión de proyectos

consideraciones ciones para cada uno de los modelos. El capítulo 3 describe los
productos y procesos bases de proyectos de software. fundaciones de productos
incluyen las necesidades operacionales, requisitos del sistema y el diseño del
sistema, las restricciones de diseño y requisitos de software. fundamentos del
proceso incluyen el modelo de flujo de trabajo, el modelo de desarrollo de
software, el acuerdo contractual, y el plan del proyecto.
Los capítulos 4, 5 y 6 se refieren a la planificación y estimación. Capítulo 4 se
describe el proceso de planificación y el formato y contenido de los planes de
gestión de proyectos. El capítulo 5 presenta técnicas, incluyendo turas de
desglose de trabajo turas, paquetes de trabajo, redes de actividad (caminos
críticos y PERT), diagramas de Gantt, histogramas de recursos y la planificación
de carga. El capítulo 6 se ocupa de las técnicas de estimación, incluyendo las
técnicas pragmáticas, basadas en la teoría, y basada en regresión.
El capítulo 7 presenta una introducción a las medidas y medición, y la
medición y control de los productos de trabajo, incluyendo las técnicas para
medir y analizar los defectos de software. El capítulo 8 presenta la medición y
control de los procesos de trabajo, incluidas las técnicas de medición y control de
programación, presupuesto, progreso, y el riesgo. Capítulo 9 se refiere a la
gestión de riesgos, incluyendo la identificación de riesgos, análisis y priorización,
las estrategias de mitigación, planes de acción y elementos de acción, planes de
contingencia y acciones contingentes, y la gestión de crisis.
Capítulo 10 cubre el trabajo en equipo, motivación, estilos de personalidad y
estilos de liderazgo. Capítulo 11 cubre las cuestiones de organización; concluye
con 15 directrices para ING organiz- y dirección de equipos de ingeniería de
software.
Cada capítulo contiene ejercicios; completarlas serán aún más su ing comprensión
de los temas tratados en el capítulo. Un apéndice de cada capítulo de este texto
incluye temas relevantes, la forma adecuada para ese capítulo, a partir de la madurez
de la capacidad SEI Model® Integración CMMI-DEV-v1.2, ISO / IEC e IEEE / EIA
12207, IEEE estándar EIA / 1058, y el PMI Project Management Body of
Knowledge (PMBOK).
Apéndice A del presente texto proporciona un glosario de términos utilizados
en el texto. Apéndice B describe algunos temas para proyectos a largo plazo y un
calendario de tareas para un proyecto a largo plazo para desarrollar un plan de
gestión de proyectos de software. diapositivas de la presentación de cada capítulo
y otro material de apoyo están disponibles en la URL que aparece en el Prefacio.
Referencias
[Brooks95] Brooks, FP El mes laboral mítico. Addison Wesley, 1995.

[CMMI06] SEI. CMMI ® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[IEEE1058] IEEE Std 1058 ™ -1998 Norma IEEE para los planes de gestión de proyectos
de software. IEEE Press, Nueva York, 1998. También en Estándares de
Ingeniería de colección. IEEE producto: SE113. Instituto de Ingenieros
Eléctricos y Electrónicos, agosto de 2003.
[IEEE12207] Industria Implementación de la Norma Internacional ISO / IEC 12207: 1995
estándar para la Tecnología de la Información-Software Procesos del ciclo de
vida. IEEE / EIA 12207.0 / 0,1 / 0,2 hasta 1996 (marzo), IEEE Press, Nueva
York, 1996. También en Ingeniería
www.it-ebooks.info
CEREMONIAS 25
Colección normas. IEEE producto: SE113. Institute of Electrical and Elec-

tronic Ingenieros, agosto de 2003.
[Jack02] Jackson, M. Descripciones en desarrollo de software. Lecture Notes in
Computer Science. Springer Verlag, 2002.
[PMI04] PMI, Una guía para la Dirección de Proyectos del Conocimiento, 3ª ed.
(PMBOK® Guía). Project Management Institute, 2004.
[Youk77] Youker, R. alternativas de organización para los administradores de
proyectos. Proyecto Manage- ment Quarterly, vol. VIII, No. 1, (marzo de
1977).
URL
SEI Capability Maturity Model Integration (CMMI ®) [www.sei.cmu.edu/cmmi/models]. ISO /

IEC 12207-1995 estándar [www.iso.org].
EIA / Software Engineering estándares IEEE, incluyendo IEEE estándar EIA / 12207-1996
e IEEE estándar EIA / 1058 [standards.ieee.org/software].
PMI Project Management Body of Knowledge (PMBOK® Guía), 3ª Ed., 2004 [www.
pmibookstore.org].
CEREMONIAS
1.1. Un proyecto es un conjunto de actividades llevadas a cabo trabajo

coordinados dentro de un marco de tiempo específico que utiliza recursos
para lograr objetivos específicos.
a. Brevemente describa un proyecto de su vida personal que recientemente
ha completado. Indicar la naturaleza del proyecto, los objetivos iniciales,
y planificado la fecha inicial y final y el inicio real y finalización del
proyecto. Enumerar todos los recursos utilizados (dinero, herramientas,
materiales, mano de obra).
b. Enumerar y comparar el resultado de su proyecto a los objetivos iniciales.
1.2. Diferentes tipos de proyectos a medida y adaptar las técnicas genéricas de
gestión de proyectos (planificación, estimación, medición, control,
comunicación, coordinación, lo que lleva, la gestión del riesgo) para
adaptarse a las necesidades de los proyectos. Para cada uno de los
siguientes tipos de proyectos, haga una lista de algunos factores que puedan
influir en la forma que lo haría planear, estimar, medir, controlar,
comunicar, coordinar, dirigir y gestionar los proyectos de riesgo:
a. Construcción de edificio
b. cocina de un restaurante
c. Recogida de fruta
do. Handcrafting de coches de carreras
1.3. Una línea de programa de código 1000000, cuando se imprime a 50 líneas
por página, da lugar a la pila de papel de unos 10 pies de altura (3 metros).
Mostrar el cálculo de este resultado. Detalle las suposiciones hechas.
1.4. En el texto El mes laboral mítico, Fred Brooks diferencia dificultades
accidentales de las dificultades esenciales en la ingeniería de software.
Accidental
www.it-ebooks.info
26 INTRODUCCIÓN
dificultades son las que surgen debido al estado actual de nuestros

conocimientos, procesos, herramientas y tecnología. las dificultades
esenciales surgen de la complejidad inherente, la conformidad, la
mutabilidad, y la invisibilidad de software.
a. Describa brevemente cinco dificultades accidentales que hacen difícil el
desarrollo de software.
b. Comparar y contrastar el estado actual de sus cinco dificultades
accidentales al estado de esas dificultades en 1960.
1.5. Describir una circunstancia en la que la adición de más personas a un
proyecto de software no invocar la ley de Brooks; es decir, una situación en
la que no se aplicarían los 3 factores enumerados en el texto.
1.6. El texto describe las formas en que un equipo de gente que escribe un libro
es como un equipo de personas que escriben software. Leer la descripción y
desarrollar una tabla de dos columnas en las que las actividades de escribir
un libro se enumeran en la primera columna y actividades comparables de
software de escritura se enumeran en las filas de la segunda columna.
1.7. Describe tres formas en que un esfuerzo de equipo para el desarrollo de
software no es similar a un esfuerzo de equipo para escribir un libro.
1.8. Describir una circunstancia en la que un equipo de software sería:
a. eficiente pero no es eficaz y
b. eficaz pero no eficiente.
1.9. Describe brevemente un ejemplo de cada tipo de limitación que figuran en la
Tabla 1.1.
1.10. En un ejemplo en el texto, se hace constar que el proyecto podría ser
discutido Suc cessfully completa con 10 desarrolladores en 12 meses si el
10 eran miembros del equipo de pendientes. Enumerar cinco atributos de un
miembro de equipo excepcional; incluir algún individuo y algunas
habilidades de miembros del equipo.
1.11. La Tabla 1.2 enumera algunos procesos de apoyo para el desarrollo de
software. Describa brevemente tres procesos de apoyo adicionales que
podrían ser necesarias para algunos proyectos de software.
1.12. Autoridad y responsabilidad son los principales problemas para los
administradores de proyectos.
a. Explique brevemente qué se entiende por autoridad.
b. Explique brevemente qué se entiende por responsabilidad.
c. Se puede delegar la autoridad? Si no es así, ¿por qué no? Si es así, dar un
ejemplo.
d. Se puede delegar la responsabilidad? Si no es así, ¿por qué no? Si es así,
dar un ejemplo.
e. Explique brevemente por qué autoridad debe ser proporcional a la
responsabilidad.
1.13. Brevemente describa el ambiente de trabajo de un desarrollador de software

que trabaja en un departamento de software organizada como:
a. una organización funcional
www.it-ebooks.info
b. una organización del proyecto
c. una organización matricial
www.it-ebooks.info
CEREMONIAS 27
1.14. Figura 1.3 ilustra un modelo de organización de proyectos de software.

Enumerar el tipo de trabajo de cada uno de los tres equipos podrían hacer si
se organiza el proyecto:
a. por componente de proceso
b. por componente de producto
1.15. En el texto, los directores de proyectos de software se comparan con los
productores de cine y arquitectos de software a los directores de cine.
Explicar brevemente los papeles comparables a jefe de proyecto y
arquitecto de software, si los proyectos de software se comparan con:
a. orquesta sinfónica
b. equipos de deportes (béisbol, fútbol)
c. un pelotón del ejército
1.16. Las normas ISO 12207 e IEEE incluyen cinco actividades para la gestión
de proyectos de software: iniciación y el alcance definición, planificación,
ejecución y control, revisión y evaluación, y de cierre. Consultar una copia
de las normas ISO 12207 y 12207 o IEEE resumir brevemente los temas
incluidos en cada una de estas cinco actividades.
1.17. Los siete procesos incluidos en el nivel 2 de la representación por etapas de
CMMI- DEV-v1.2 son algunos de los procesos más importantes para la gestión
de proyectos de software. Acceso CMMI-DEV-v1.2 en
www.sei.cmu.edu/cmmi/models.
a. Resumir brevemente, en sus propias palabras, el propósito de cada uno
de estos siete procesos.
b. Resumir brevemente, en sus propias palabras, las notas introductorias
para cada uno de estos siete procesos.
c. Resumir brevemente, en sus propias palabras, las áreas de procesos
relacionados para cada uno de estos siete procesos.
d. Explicar brevemente por qué y cómo las áreas de procesos relacionados
son importantes para los fines de la gestión de proyectos de software.
www.it-ebooks.info
ANEXO 1A
MARCOS, normas y directrices para la

gestión de proyectos de software
1A.1 LA CMMI-DEV-v1.2 marco de proceso
marcos de procesos CMMI son desarrollados y apoyados por el Instituto ing

Engineer- Software, que es una filial de la Carnegie Mellon University [CMMI06].
Como se indica en la página principal de CMMI
[http://www.sei.cmu.edu/cmmi/general/general. html]:
Modelo de Capacidad de Madurez® Integración (CMMI) es un enfoque de mejora de

procesos que proporciona a las organizaciones los elementos esenciales de procesos
eficaces. Se puede utilizar para guiar la mejora del proceso a través de un proyecto,
una división, o todo un orga- nización. CMMI ayuda a integrar funciones de
organización tradicionalmente independientes, objetivos y prioridades de mejora de
procesos conjunto, proporcionan una guía para los procesos de calidad, y
proporcionar un punto de referencia para evaluar los procesos actuales.
Este texto no se centra principalmente en la mejora de procesos. Sin embargo,

La comprensión de las metas y adoptar las prácticas específicas de las áreas de
proceso de gestión de proyectos en los marcos de CMMI va a mejorar su
capacidad y la capacidad de su organiza- ción a la gestión de proyectos de
software. De esta manera se pueden mejorar sus posibilidades de entregar
productos aceptables a tiempo y dentro del presupuesto.
Versión 1.2 de CMMI está estructurado como un marco a partir del cual se pueden
derivar varios “constelaciones”. CMMI-DEV-v1.2 es la primera constelación;
verwww.sei.cmu.edu / CMMI / modelos. CMMI-ACQ a la versión 1.2 para los
procesos de adquisición acaba de ser lanzado en el momento de escribir este texto.
Otras constelaciones del marco de la versión 1.2 están en desarrollo. Es importante
tener en cuenta que las constelaciones v1.2 no son modelos de proceso, sino más bien
los marcos para el desarrollo y la mejora de los procesos que satisfagan los objetivos
de los marcos de CMMI.
Este texto se refiere principalmente a las áreas de procesos relacionados con la
gestión de proyectos de mercancías y sistemas blandos en CMMI-DEV-v1.2, que
contiene 22 áreas de proceso. Tanto por etapas y se proporcionan
representaciones continuas. La representación por etapas
28
www.it-ebooks.info
1A.1 LA CMMI-DEV-v1.2 marco de proceso 29
lugares ción cada área de proceso en uno de cinco niveles de madurez numerados
del 1 al 5 y la representación continua proporciona niveles de capacidad para
cada área de proceso en una escala de 0 a 5. En la representación por etapas cada
nivel superior añade más cesos pro. Los niveles de madurez y sus nombres se
enumeran en la Tabla 1A.1.
Las 22 áreas de proceso en la representación por etapas de CMMI-DEV-v1.2
son ilustró en la Figura 1A.1. Los efectos de cada proceso en la Figura 1A.1 se
enumeran en la Tabla 1A.4 de este apéndice. En la representación continua de
CMMI-DEV-v1.2 un nivel de capacidad se determina para cada área de proceso
individual seleccionado para Assessment. Todos los procesos de CMMI o
cualquier subconjunto de ellos pueden ser evaluados y mejorados, como se
determina por las necesidades de negocio de la organización. Hay seis niveles de
capacidad, numerados de 0 a 5 y nombrados como se indica en la Tabla 1A.2.
En la representación continua de los procesos CMMI se agrupan en cuatro
categorías. Las categorías no son los niveles; que son una forma de agrupar las
áreas de procesos relacionados. Las áreas de proceso en cada categoría son los
siguientes:
TABLA niveles de madurez CMMI 1A.1

Madurez LevelName
Nivel 1Initial
Nivel 2Managed
Nivel 3Defined
Nivel 4Quantitatively gestionado
Nivel 5Optimizing
nivel innovación organizativa.

5 análisis y resolución causal
(Optimizaci
nivel rendimiento de proceso de
4 ón)organización
(Gestionado cuantitativamente) la gestión cuantitativa
del proyecto
el desarrollo de los requisitos
de solución técnica
Verificación de la integración
nivel validación
de productos
3 procesos de la organización se centran
(Definid programa de formación de la
organización IPPD definición del
o) proceso de organización +
la gestión integrada de software de
gestión de riesgos + IPPD
Análisis de decisiones y resolución
gestión de requerimientos
planificación de proyectos
seguimiento de los proyectos y la
nivel 2 medición de gestión de acuerdo con
(administr el proveedor de control y análisis
ado) procesos y aseguramiento de la
calidad del producto gestión de la
configuración
FIGURA 1A.1 representación por etapas del CMMI-DEV-v1.2
www.it-ebooks.info
30 INTRODUCCIÓN
TABLA 1A.2 niveles de capacidad en las representaciones

continuas CMMI
Capacidad LevelName
Nivel 0Incomplete
Nivel 1Performed
Nivel 2Managed
Nivel 3Defined
Nivel 4Quantitatively gestionado
Nivel 5Optimizing
• Gestión de proyectos
° Planificación de proyectos
° el seguimiento y control de proyectos
° gestión de acuerdo con el proveedor
° La gestión integrada de proyecto + IPPD
° Gestión de riesgos
° gestión de proyectos cuantitativa
• Ingenieria
° requisitos desarrollo
° Gestión de requerimientos
° Solución técnica
° La integración de productos
° Verificación
° Validación
• Apoyo
° gestión de la configuración
° Proceso y aseguramiento de la calidad del
producto
° Medición y análisis
° El análisis de decisiones y la resolución
° análisis y resolución Causal
• Gestión de proceso
° enfoque proceso de organización
° Organizacional de definición de procesos +
IPPD
° la formación de la organización
° el rendimiento del proceso de organización
° La innovación organizativa y el despliegue
Cada una de las cuatro categorías de procesos se divide en áreas básicas y

avanzadas de proceso. Las áreas básicas y avanzadas del proceso de gestión de
proyectos se enumeran en la Tabla 1A.3. Tenga en cuenta que las áreas básicas
de proceso en la Tabla 1A.3 son de nivel 2 procesos en la representación por
etapas de CMMI-DEV-v1.2 y los procesos avanzados están en el nivel 3 en la
representación por etapas.
www.it-ebooks.info
Cada una de las 22 áreas de proceso de CMMI-DEV-V1.2 tiene:
• metas genéricas y específicas (componentes necesarios),

• prácticas genéricas y específicas (componentes), y se espera
• componentes informativos, que incluyen productos típicos de trabajo,
ejemplos, notas y referencias
TABLA 1A.3 áreas de proceso para la gestión de proyectos en la representación

continua de CMMI-DEV-v1.2
áreas básicas del proceso de proyecto administración • Planificación de proyectos
• el seguimiento y control de proyectos
• gestión de acuerdo con el proveedor
áreas de proceso avanzadas para la • La gestión integrada de proyecto + IPPD
gestión de proyectos • Gestión de riesgos

• gestión de proyectos cuantitativa
Los objetivos genéricos y metas específicas para un determinado nivel, además

de todos los objetivos para los niveles inferiores, se deben cumplir para llegar a
ese nivel. Se espera que las prácticas genéricas y específicas se llevarán a cabo a
menos que pueda demostrar que está utilizando valente valente o procesos
superiores. componentes informativos son ilustrativos en la naturaleza; que no se
requiere ni se espera.
objetivos genéricos y prácticas genéricas se aplican a cada área de proceso; su
propósito es institucionalizar las áreas de proceso a fin de que se incrustan en la
memoria corporativa y procedimientos corporativos. meta genérica 2 (GG2), por
ejemplo, debe ser satisfecho por el nivel 2 (administrado) procesos. Las prácticas
genéricas de GG2 son los siguientes:
GG 2 institucionalizar un proceso
gestionado GP 2.1 Establecer un plan de
organización política 2.2 GP del proceso
GP 2.3 Proporcionar
recursos GP 2.4 Asignar la
responsabilidad GP 2.5
Capacitar a la gente
GP 2.6 Administrar configuraciones
GP 2.7 Identificar e involucrar a las partes
interesadas pertinentes GP 2.8 Monitorear y
controlar el proceso de
GP 2.9 Evaluar objetivamente la adherencia
2.10 Revisión estado de GP con la gestión de nivel superior
GG3 satisfactorio para un área de proceso supone que existe un proceso de

organización estándar y que ha adaptado para que se adapte a las necesidades de
su proyecto. En el nivel 3 (administrado) se documenta cada proceso (a nivel de
organización) para especificar:
www.it-ebooks.info
32 INTRODUCCIÓN
• propósito
• entradas
• criterio para entrar
• ocupaciones
• papeles
• medidas
• pasos de verificación
• salidas
• criterio de salida
En el nivel 2, cada proyecto puede satisfacer las metas genéricas y específicas,

siguiendo diferentes formatos, pero en el nivel 3, todos los proyectos en una
organización implementar las áreas de proceso de una manera uniforme, de modo
que los datos consistentes se pueden recoger de proyectos en toda la
organización. Los niveles 4 y 5 se refieren a analizar los datos de proceso y de
producto y el uso de los resultados de realizar mejoras en los procesos y la
tecnología.
Las metas específicas y prácticas específicas son, como su nombre lo indica,
específico para cada área de proceso. Por ejemplo, los objetivos específicos y las
prácticas específicas de plan- proyecto Ning son los siguientes:
SG 1 Establecer estimaciones
SP 1.1 Estimar el alcance del proyecto
SP 1.2 Establecer las estimaciones del producto de trabajo y
la tarea atributos SP 1.3 Definición del ciclo de vida del
proyecto
SP 1.4 Determinar las estimaciones de
esfuerzo y costo SG 2 Desarrollar un plan de
proyecto
SP 2.1 Establecer el presupuesto y el
calendario SP 2.2 Identificar los riesgos del
proyecto
SP 2.3 Plan para la gestión de
datos SP 2.4 Plan de recursos del
proyecto
SP 2.5 Plan de conocimientos y habilidades
SP participación de los interesados 2.6 Plan
de necesaria
SP 2.7 Establecer el plan de
proyecto SG 3 Obtener compromiso
con el plan
planes SP 3.1 Revisión que afectan el
proyecto SP de trabajo y los niveles de
recursos 3.2 Conciliar SP 3.3 Obtener el
compromiso del plan
El propósito del área de proceso de gestión cuantitativa del proyecto (MPT)

www.it-ebooks.info
(un proceso de nivel 3 en la representación por etapas) es gestionar
cuantitativamente el proceso definido del proyecto para lograr los objetivos de
calidad y de rendimiento del proceso especificados del proyecto, a saber, la
gestión de proyectos “por los números .”Se trata de medidas que determinen para
cada fase del proyecto y cada tipo de proceso de trabajo, la recogida cuantitativa
www.it-ebooks.info
TABLA 1A.4 Propósitos de los procesos CMMI-DEV-v1.2

Proceso AreaPurpose
requisitos requisitos managementControl y mantener la consistencia de
requisitos con los planes y productos de trabajo
Proyecto planningEstablish y mantener los planes que definen las actividades
de trabajo del proyecto
El seguimiento del proyecto y controlCompare progresar a planes y aplicar correctivos
comportamiento
según sea necesario
gestión de acuerdo Gestionar la adquisición de elementos de productos de
con el proveedor los proveedores y subcontratistas
medición y información de estado analysisSupply necesaria para apoyar decisiones
Proceso y aseguramiento Evaluar los procesos y productos de trabajo para
de la calidad del identificar áreas de incumplimiento
producto
Configuración managementEstablish y mantener el control de Productos de trabajo
Requisitos developmentObtain, analizar y desarrollar clientes, productos, y
requisitos de producto componentes
Técnico solutionDesign, desarrollar e implementar soluciones que satisfacer los
requisitos
Producto componentes integrationIntegrate, validar general funcionalidad, y entregar el
producto
VerificationEnsure que los productos de trabajo seleccionados se reúnen sus
requisitos especificados
ValidationEnsure que selecciona los productos de trabajo satisfacen su uso previsto
cuando se coloca en sus entornos destinados
proceso organizativo focusPlan e implementar procesos de la organización mejora
Organizacional de Establecer y mantener un conjunto útil de los
definición de activos de proceso de la organización
procesos + IPPD
habilidades y conocimientos trainingDevelop de organización para que las personas
poder
realizar su trabajo de manera eficiente y eficaz
La gestión integrada Desarrollar y utilizar un conjunto integrado y definido
de proyecto + IPPD de procesos que se adapta a partir del conjunto de
procesos estándar de la organización
Riesgo managementIdentify problemas potenciales; desarrollar y implementar
estrategias y técnicas para la mitigación de los mismos
El análisis de decisiones y la Identificar las posibles decisiones usando un proceso de
resolución evaluación formal que evalúa las alternativas contra
criterios establecidos
gestión de Utilizar los datos cuantificados para gestionar los
proyectos objetivos de calidad y de rendimiento del proceso de
cuantitativa cada proyecto
el rendimiento del proceso de Proporcionar datos de rendimiento de los procesos
organización y modelos cuantitativos para entender los
procesos estándar de la organización
La innovación organizativa y Seleccionar e implementar mejoras
el despliegue incrementales e innovadoras que mejoran
apreciablemente los procesos y las
tecnologías de la organización
El análisis causal y resolutionIdentify causas de los defectos y otros problemas y
tomar
medidas para evitar que se produzcan en el futuro
www.it-ebooks.info
34 INTRODUCCIÓN
tivos de datos, la realización de análisis estadísticos, y comparar los resultados a

los planes y tación tivas sobre una base continua.
A nivel de madurez por etapas no puede alcanzarse hasta que todas las metas
genéricas y específicas de todos los procesos en los niveles inferiores, además de los
objetivos genéricos y específicos para los procesos en ese nivel son satisfechos. A
nivel de capacidad más alta para un proceso individual no puede alcanzarse hasta que
todas las metas genéricas y específicas de los niveles inferiores, además de los
objetivos genéricos y específicos para ese nivel se han alcanzado para ese proceso.
En general, realizaron representaciones proporcionan un enfoque sistemático
para la construcción de la madurez del proceso, nivel por nivel. representaciones
continuas permiten diferentes organizaciones para elegir los procesos a ser
mejorados de acuerdo con las prioridades establecido por dichas
organizaciones.
Tenga en cuenta que los niveles 4 y 5, tanto en las representaciones por etapas
y continuas se denominan “gestionado cuantitativamente y optimización.” Áreas
de proceso gestionado cuantitativamente son aquellos para los que se recogen de
manera uniforme datos definidos y medidos de todos los proyectos a través de
una organización y se analizaron para fortalezas y debilidades. En el nivel 5 se
utilizan los resultados del análisis de datos de nivel 4 para mejorar las áreas de
proceso y para introducir nuevas tecnologías en apoyo de las áreas de proceso. El
nivel 5 es “optimizar” y no “optimizado”. Este último término (optimizado)
implica que los procesos de la organización son tan buenos como sea posible. Por
el contrario, el primer término (optimizar) implica que los procesos de la
organización se están mejorando continuamente, pero no son óptimas; siempre
hay margen de mejora.
El propósito de cada uno de los 22 procesos en CMMI-DEV-v1.2 está brevemente
summa- AUTORIZADO en la Tabla 1A.4. elementos pertinentes de CMMI-DEV-
v1.2 se presentan en dixes appen- a los capítulos de este texto.
1A.2 ISO / IEC e IEEE / EIA NORMAS 12207
ISO / CEI 12207 es un marco para la organización y realización de los procesos

del ciclo de vida del software. ISO / IEC 12207 fue publicada en 1995 y
modificada en 2002 y 2004. Las enmiendas 1 y 2 Revisar 12207 para incorporar
las lecciones aprendidas en el uso de 12207 y para alinear más estrechamente con
la norma ISO 15504, que es un estándar para la evaluación de los procesos de
software dentro de una organización para determinar las áreas de fortaleza y
debilidad.
ISO / CEI 12207 proporciona un amplio conjunto de procesos del ciclo de vida
para la adquisición, suministro, desarrollo, operación, andmaintenance de
software. Itincludes 17 procesos:
• 5 procesos del ciclo de vida primarios,
• 8 procesos de apoyo, y
• 4 procesos de
organización. Los cinco
procesos principales son:

• adquisición,
• suministro,
www.it-ebooks.info
• desarrollo,
www.it-ebooks.info
1A.2 ISO / IEC e IEEE / EIA NORMAS 12207 35
• operación, y
• mantenimiento.
Los procesos de adquisición y suministro tienen que ver con las relaciones
entre un cliente y un proveedor. En la norma ISO / IEC 12207, el proceso de
desarrollo consta de 13 actividades:
1. implementación de procesos
2. análisis de los requisitos del sistema
3. diseño de la arquitectura del sistema
4. análisis de los requisitos de software
5. diseño de la arquitectura de software
6. diseño detallado del software
7. codificación y pruebas de software
8. la integración de software
9. las pruebas de calificación de software
10. Integración de sistema
11. Sistema de pruebas de calificación
12. Instalación de software
13. el apoyo de aceptación del software
Los ocho procesos de apoyo en ISO / IEC 12207 son:
• documentación,
• gestión de la configuración,
• seguro de calidad,
• verificación,
• validación,
• revisión conjunta,
• auditoría, y
• la resolución de problemas.
Los cuatro procesos del ciclo de vida de la

organización son:
• administración,
• infraestructura,
• mejora y
• formación.
El proceso de gestión de la norma ISO / IEC 12207 incluye cinco actividades

para la gestión de proyectos de software:
• iniciación y definición del alcance,

• planificación,
www.it-ebooks.info
36 INTRODUCCIÓN
• la ejecución y el control,
• revisión y evaluación, y
• cierre.
ISO / IEC 12207 se envasa en tres volúmenes:
• 12207.0, los procesos del ciclo de vida del software;

• 12207.1, datos del ciclo de vida; y
• 12207.2, las consideraciones de implementación.
ISO / IEC 12207.0 es el documento primaria; además de especificar los

procesos del ciclo de vida primaria, los procesos y los procesos del ciclo de vida
de la organización de apoyo, que incluye apéndices que proporcionan una guía
para la adaptación de los distintos procesos para adaptarse a situaciones
particulares.
ISO / IEC 12207.1 (datos de ciclo de vida) incluye indicaciones generales para
los 7 tipos de documentos (por ejemplo, planes, descripciones, registros) y
directrices específicas para 30 tipos de documentos (por ejemplo, planes de
gestión de proyectos, descripciones de diseño de software, software registros de
control de calidad).
ISO / IEC (consideraciones de implementación) 12.207,2 proporciona
orientación, sobre la base de experiencias de la industria, para la implementación
de los procesos del ciclo de vida en 12.207,0.
La versión IEEE / EIA de la norma ISO / IEC 12207 fue desarrollado por el
Comité de Normas de Sistemas de Ingeniería de la IEEE Computer Society
[IEEE12207] cerámica Flexible y de. En pocas palabras, IEEE / EIA 12207 es la
norma ISO / IEC 12207 con las modificaciones y aclaraciones de redacción y la
adición de algunos apéndices. Es el estándar general para conjunto de
aproximadamente 40 estándares para la ingeniería de software documentos y
procesos [] standards.ieee.org/software del IEEE; cada una de estas normas es
(pretende ser) armoniosa con la norma IEEE / EIA 12207.
De acuerdo con el resumen en IEEE estándar EIA / 12.207,0-1996, el estándar
incluye aclaraciones, adiciones y cambios aceptados por el Instituto de Ingenieros
Eléctricos y Electrónicos (IEEE) y la Asociación de Industrias Electrónicas
(EIA). El objetivo de la norma es proporcionar una mejor comprensión y una
base para las prácticas de software en los negocios tanto nacionales como
internacionales. De acuerdo con la palabra de extremidades anteriores IEEE /
EIA 12207.2, que resume las mejores prácticas de la industria del software de
Estados Unidos en el contexto de la estructura del proceso proporcionado por la
norma ISO / IEC 12207. elementos Vant vantes de las normas ISO 12207 e IEEE
se presentan en anexos a los capítulos de este texto.
1A.3 IEEE / EIA STANDARD 1058
planes de gestión de proyectos basados en el estándar IEEE Std 1058 ™ -1998

Norma IEEE para los planes de gestión de proyectos de software incluirán planes
para [IEEE1058]:
• procesos de gestión,
www.it-ebooks.info
• procesos técnicos,
www.it-ebooks.info
1A.4 el PMI cuerpo de conocimientos 37
• procesos de apoyo, y
• procesos adicionales.
Los planes para los procesos de gestión incluyen:
• un plan de puesta en marcha,

• un plan de trabajo,
• un plan de control,
• un plan de gestión de riesgos, y
• un plan de cierre.
Los planes para procesos técnicos incluyen planes para un modelo de proceso
de desarrollo; métodos, herramientas y técnicas; infraestructura; y la aceptación
del producto. Apoyando planes de proceso incluyen planes para los ocho
procesos de apoyo en IEEE / EIA Normaliza- 12207 dard; a saber, la gestión de
la configuración, verificación y validación, docu- mentación, control de calidad,
revisiones y auditorías, resolución de problemas, gestión de subcontratistas, y la
mejora de procesos.
Los planes para procesos adicionales incluyen planes para otros procesos
como la formación de los usuarios, instalación o mantenimiento continuo y el
apoyo que puede no ser necesaria en algunos proyectos.
Una visión general de IEEE estándar EIA / 1058 se presenta en el Capítulo 4
de este texto. Una plantilla para la preparación de planes de gestión de proyectos
basadas en IEEE estándar EIA / 1058 está contenida en el Apéndice 4B con el
Capítulo 4 de este texto; una copia electrónica de la plantilla se puede acceder en
la dirección del texto, que aparece en el Prefacio. elementos pertinentes del IEEE
estándar EIA / 1058 se presentan en los apéndices de los capítulos de este texto.
1A.4 el PMI cuerpo de conocimientos
El cuerpo del PMI del Conocimiento fue desarrollado por el Instituto de Gestión
de Proyectos, que es una organización sin ánimo de lucro que promueve la
profesión de management por capítulos patrocinadoras, grupos de intereses
especiales, y sus afiliaciones con escuelas y universidades
[proyectowww.pmi.org]. PMI tiene más de 200.000 miembros en todo el mundo.
actividades de PMI incluyen la educación y la adquisición de conocimiento,
como al desarrollo profesional y la creación de redes, la promoción profesional y
las normas profesionales, y los productos y servicios. PMI ofrece un examen
certificado por el cual uno puede convertirse en un profesional de la gestión de
proyectos cado certifi-.
La Guía para el PMI Cuerpo de Conocimiento (PMBOK) cubre cinco grupos
de procesos [PMI04]:
• iniciación del proyecto,

• planificación de proyectos,
• la ejecución de un proyecto,
• seguimiento y control de un proyecto, y
• el cierre de un proyecto.
www.it-ebooks.info
38 INTRODUCCIÓN
TABLA 1A.5 capítulos en el PMBOK ® Guía

Capítulo 1. Introducción
Capítulo Ciclo de Vida y 2Project Organización
Capítulo Gestión de Procesos para una 3PROJECT Proyecto
Capítulo Integración 4Project administración
Capítulo Ámbito 5proyecto administración
Capítulo Tiempo 6Project administración
Capítulo Costo 7Project administración
Capítulo Gestión de la Calidad 8Project
Capítulo Recursos Humanos 9Project administración
Capítulo Comunicación 10Project administración
Capítulo Riesgo 11Project administración
Capítulo Contratación 12Project administración
Estos cinco grupos de procesos incluyen 44 procesos de gestión. PMBOK

también incluye 34 competencias clave para los administradores de proyectos.
Los títulos de los capítulos de una guía para la Dirección de Proyectos del
Conocimiento, 3ª ed. (Guía PMBOK®) se enumeran en la Tabla 1A.5; que
indican el alcance de los temas abordados por el PMBOK [PMI04]. elementos
Vant vantes de PMBOK se presentan en los apéndices de los capítulos de este
texto.
www.it-ebooks.info
2
Los modelos de proceso de desarrollo de
software
proceso Una serie de operaciones que se realizan en la fabricación o el tratamiento de un

producto.
College Dictionary -American patrimonio, tercera edición
2.1 Introducción al proceso de MODELOS
Gestión de desarrollo de software y la modificación se realiza mediante

descomposición que presentan las actividades de trabajo de alto nivel en las
actividades de trabajo de nivel inferior de una manera jerárquica. Las actividades
de trabajo de nivel más bajo sujeto a la planificación de gestión y rendición de
cuentas se denominan tareas; actividades son, pues, las agregaciones de tareas y
de subordinación actividades.10 realización sistemática de una tarea implica
típicamente siguiendo un conjunto de procedimientos y utilizando un conjunto de
herramientas y técnicas (es decir, la realización de un proceso).
ingeniería de procesos se ocupa de desarrollar y mejorar constantemente el
flujo de trabajo dentro y entre las tareas para hacer que el desarrollo de software
más eficiente y más eficaz; es decir, para realizar las tareas sin perder tiempo,
esfuerzo o recursos (es decir, de manera eficiente) y para lograr los resultados
deseados (es decir, eficacia). La mejora de los procesos de trabajo aumentan la
productividad y la moral de los desarrolladores de software, los atributos de
calidad de los productos de trabajo, y la satisfacción de los usuarios y clientes.
Los principios básicos de la ingeniería de procesos son los siguientes:
1. Mejores procesos de trabajo dan lugar a mejores productos de trabajo,

donde los “mejores productos de trabajo”: características mejoradas, mejor
calidad, menos trabajo, y modificaciones más fáciles.
10
Los términos “actividad” y “tareas” se usan indistintamente en este texto a menos que la diferencia
es importante para el tema en discusión, en cuyo caso, se hará la distinción.

39
www.it-ebooks.info
40 Los modelos de proceso de desarrollo de software
2. Los procesos de trabajo deben ser diseñados con el mismo cuidado utilizado
para diseñar productos de trabajo; los procesos de trabajo deben ser
diseñados para satisfacer los requisitos del proceso y las restricciones del
proceso, adaptarse a las necesidades de cada proyecto, y realizar los
procesos de trabajo eficiente y eficaz.
3. Los procesos de trabajo para cada proyecto deben derivarse de un marco de
proceso. Un marco de proceso es un modelo de proceso genérico que puede
ser adaptada para satisfacer las necesidades de una variedad de situaciones.
La adaptación de un marco consiste en añadir, eliminar y modificar
elementos de adaptar el marco a las necesidades de proyectos específicos.
4. El diseño del proceso y el resultado de la mejora de procesos en los horarios
más cortos, mayor calidad, menores costos, los usuarios más felices y
clientes, y de trabajadores más felices y gerentes.
5. La mejora de procesos rara vez ocurre espontáneamente. La inversión en
ingeniería de procesos ahorra más tiempo, esfuerzo y costo que se invierte.
Un ROI positivo (retorno de la inversión) requiere una inversión continua
de tiempo, esfuerzo y recursos.
Muchas organizaciones han definido marcos de gestión de proyectos, desarrollo

de software, para las líneas de productos de software, para los procesos de
negocio, para la mejora de procesos, y muchas otras situaciones. Algunas
organizaciones han desarrollado modelos de procesos a medida prepara los
diversos tipos de proyectos de software, derivados del marco de proceso de la
organización. En estos casos, como jefe de proyecto, debería seleccionar un
modelo de proceso apropiado de un inventario de modelos y, si es necesario,
además adaptarlo para satisfacer las necesidades específicas de su proyecto.
Un marco de proceso (es decir, un modelo de flujo de trabajo) para proyectos
de software se introducido en el capítulo 1; se ilustra en la figura 1.1 y se repite
aquí como la figura 2.1a. Como todos los modelos el modelo de flujo de trabajo
hace hincapié en los aspectos de relevancia para sus propósitos y suprime otros
aspectos, que pueden ser elaborados en modelos subordinados; La figura 2.1b es
un modelo subordinado para la caja en la esquina superior derecha de la figura
2.1a (es decir, proceso de desarrollo). En este capítulo se presenta modelos
adicionales del proceso de desarrollo de software se muestra en la esquina
superior derecha de la figura 2.1a. Otros capítulos de este texto elaboran otros
elementos del modelo de flujo de trabajo en la Figura 1.1 y examinar su
relevancia para las tareas de gestión y dirección de proyectos de software.
Un modelo de proceso de desarrollo de software hace
hincapié en:
• las actividades de trabajo a realizar en la fabricación de un producto de

software;
• el orden en que las actividades de trabajo y las tareas se llevarán a cabo;
• las formas en que las actividades de trabajo y tareas se pueden superponer y
iterado; y
• los productos de trabajo que resultan de flujo, y entre, las diversas actividades de
trabajo.
El proceso de desarrollo que se utiliza para desarrollar sus productos de trabajo

ejerce una fuerte influencia sobre las técnicas que va a utilizar durante sus
www.it-ebooks.info
proyectos para:
www.it-ebooks.info
2.1 Introducción al proceso de MODELOS 41
Empieza
aqui requisitos
y limitaciones Desarrollo
Proceso
ón y Definició Verificación aquí
n de las ciones validación
Los gestores replanifica de
ción Actividad
es trabajo Entregar
Directivas y Seguro de
restricciones calidad Producto
Re-estimar trabajo
administración
Retenció
n de Otro
datos Secundario
procesos
FIGURA 2.1A Un modelo de flujo de trabajo para la gestión de proyectos de

software.
Sistema Ingenieria Desarrollo de software
Asignar
Requisitos de
hardware
Asignar
Requisitos Desarrollar Asignar &
Personas Arquitectura Refinar
del sistema Requisitos de
software
Desarrollar
Arquitectura
Desarrollar
de software
Requisitos Obtener
del sistema Los
componente
software s de
Definir
Operacional
V&V Integrarsoftware
requisitos Los
sistema componente
comi verificació s de
enzo n software
aquí Las necesidades y Integrar
añadir otra
expectativas del cliente sistema Componente componente
usuario desea Acquirer validación s del s
Condiciones Finsistema
aquí Ingeniería de
sistemas
FIGURA 2.1B Un marco de procesos para el desarrollo de sistemas intensivos en
software
• plan y estimación,
• medir y control,
• comunicar, coordinar y dirigir, y
• gestionar el riesgo.
www.it-ebooks.info
Este capítulo presenta los modelos de procesos de desarrollo de software.

Después de leer este capítulo y completar los ejercicios que usted debe entender:
• elementos del marco de proceso de desarrollo en la figura 2.1b;

• distinciones entre los usuarios, clientes y compradores;
• la adaptación del marco de los sistemas de software de sólo;
• varios modelos de procesos de uso común para el desarrollo de software;
• formas en las que los distintos modelos de procesos de desarrollo influyen en
la gestión de proyectos de software; y
• un ejemplo de diseño del proceso.
2A apéndice de este capítulo comprende los elementos de CMMI-DEV-v1.2, ISO /

IEC 12207 Normas y / EIA IEEE, IEEE / EIA estándar de 1058, y el PMI de cuerpo
de conocimiento que son relevantes para los procesos de desarrollo de software.
Apéndice 2B incluye directrices para elegir entre modelos de desarrollo iterativo.
Los términos utilizados en este capítulo y en todo este texto se definen en el
Apéndice A del texto. diapositivas de la presentación de este capítulo y otro
material de apoyo están disponibles en la URL que aparece en el Prefacio.
2.3 Un marco de desarrollo-PROCESO
La figura 2.1b ilustra un marco para el cuadro de proceso de desarrollo en la

esquina superior derecha de la figura 2.1a. La parte superior izquierda e inferior
derecha de la figura 2.1b ilustrar un marco para la ingeniería de sistemas de
sistemas de software intensivo.
Como se muestra en la figura 2.1b, el desarrollo de un sistema de software
intensivo puede implicar el desarrollo, modificación o adquisición de hardware y
software y la capacitación de las personas para llevar a cabo operaciones
manuales. Los matices de las cajas y las flechas indican las muchas iteraciones
que normalmente se requieren para desarrollar un sistema de software intensivo.
No hay ninguna importancia atribuida a las cajas frente a óvalos en la figura 2.1b,
aparte de hacer hincapié en la puntos inicial y final de las actividades de trabajo.
Las puntas de flecha dobles en el software V & V, verificación del sistema, y
las actividades de validación sistema pretenden indicar que el software V & V
evalúa los componentes de software integrados con respecto a (wrt) los
requisitos de arquitectura de software y de software, requisitos del sistema
sistema de verificación wrt, y el sistema de validación wRT requisitos
operacionales. La verificación se ocupa de determinar el grado en que un
producto de trabajo es correcta, completa y consistente con respecto a otros
productos de trabajo y los procesos de trabajo. La validación se ocupa de
determinismo ING que un producto de trabajo es adecuado para la finalidad
expuesta en el entorno previsto.
Hardware puede incluir hardware de computación y otros dispositivos que se
construirán, modificado o adquiridos. Software puede incluir software existente
para que sirvan como es lógico que se haya desarrollado y / o modificada por el
personal del proyecto, y el software para ser
www.it-ebooks.info
2.3 un marco de desarrollo-PROCESO 43
procurado. La gente a ser entrenados pueden incluir a los usuarios finales,

operadores de sistemas y personal de apoyo funcional.
Algunos sistemas intensivos en software son los sistemas embebidos. Un
sistema integrado es un sistema de contenido dentro de otro sistema. Por ejemplo,
las computadoras y el software están integrados dentro de los productos de
consumo tales como reproductores de DVD, consolas de juegos, hornos de
microondas, teléfonos celulares y automóviles y dentro de sistemas complejos
tales como reactores nucleares, redes de comunicación, y las naves espaciales.
Los usuarios de sistemas ded embed- interactúan con las interfaces del sistema
más grande en lugar de directamente con el hardware y software de ordenador.
Los usuarios directos del software son por lo tanto de hardware y otro software.
Los elementos del marco representado en la figura 2.1b son fases de
desarrollo. Una fase de desarrollo es un conjunto de actividades de trabajo
relacionadas que producen uno o más productos de trabajo. Fases pueden ser
intercalados, se superponen, y iterados como se especifica por el proceso de
desarrollo que se utiliza. Las flechas y matices en la figura 2.1b indicar algunos
de los muchos caminos iterativos y revisiones constantes a y mejoras de,
productos de trabajo que intentan retratar con precisión los procesos no lineales
de la creatividad y la innovación que se producen cuando los equipos de personas
trabajan en colaboración para desarrollar sistemas intensivos en software
complejos.
Elementos del marco de procedimiento representado en la figura 2.1b se
presentan en las siguientes secciones:
• Usuarios, clientes y compradores están cubiertos en la Sección 2.3.1.

• Los requisitos operativos están cubiertos en el Capítulo 3, como es el tema
de la ingeniería de requisitos para los componentes de software de sistemas.
• requisitos del sistema y el diseño del sistema se tratan en la Sección 2.3.2.
• El desarrollo de la arquitectura del software y la obtención de los
componentes de software están cubiertos en la Sección 2.3.3.
• Verificación y validación están cubiertos en la Sección 2.3.4.
Adaptación de la estructura de la figura 2.1b para proyectos de software

solamente y modelos de procesos de uso común para el desarrollo de software se
presentan en las siguientes secciones de este capítulo.
2.3.1 usuarios, clientes, y los adquirentes

Los proyectos se iniciaron debido a las necesidades insatisfechas, deseos,
expectativas y condiciones. El punto de partida (esquina inferior izquierda de la
figura 2.1b) puede implicar a los usuarios, el ERS adaptado para el cliente, una
adquirente, así como otras partes interesadas. En muchos casos el usuario, cliente
y adquirente son la misma persona u organización, pero en otros casos son
entidades distintas. Además puede haber un “promotor” que es distinto de los
usuarios, clientes y adquirente, y quién controla los recursos para el desarrollo
del sistema. Los usuarios son las personas (u otros sistemas, como en el caso de
los sistemas integrados) que utilizarán el software suministrado para llevar a cabo
sus actividades de trabajo o el ejercicio de los pasatiempos recreativos. Los
clientes son los que especifica los requisitos y limitaciones, y aceptar los
productos de trabajo entregables de un proyecto.
www.it-ebooks.info
organización (por ejemplo, una empresa de fabricación, una institución financiera

o una agencia gubernamental).
El cliente se llama la adquirente en situaciones en que el acuerdo contractual
entre el cliente y el desarrollador es un contrato legalmente vinculante; en estos
casos la organización de desarrollo se llama el proveedor. En algunos casos, el
adquirente puede ser un agente de terceros que representa a uno o más clientes o
comunidades de usuarios y que proporciona la interfaz de comunicación entre el
proveedor y los clientes / usuarios.
Usted, como desarrollador de software, puede ser su propio cliente.
Organizaciones algu- veces desarrollan sistemas intensivos en software de una
manera especulativa sin tener un grupo cliente o usuario específico en mente. En
algunos casos, el departamento de marketing desempeña el papel de cliente
sustituto. En otros casos, un equipo de investigación y desarrollo (I + D) puede,
por introspección, construir una versión prototipo o demostración de un producto
que ellos querrían si fueran el cliente / usuario. Cualquiera que sea la situación,
cada proyecto de software tiene un cliente; de lo contrario, no hay necesidades a
satisfacer, nadie para especificar los requisitos y limitaciones, y nadie a aceptar
los productos de trabajo deliv- Ered.
Los clientes, los usuarios, y adquirente pueden ser una y la misma, como se
ilustra en la figura
2.2 (Designado como cliente), o pueden ser entidades distintas, como se ilustra
en la Figura 2.3.
La figura 2.2 ilustra un punto importante: cada proyecto de software es de dos
o más proyectos. Como mínimo, un proyecto de software incluye el proyecto del
cliente para adquirir un sistema y proyecto del desarrollador para desarrollar y
entregar el sistema. Hay actividades que cada parte debe cumplir por separado y
actividades que tienen que hacer juntos. El cliente debe, por ejemplo, determinar,
especificar, y dar prioridad a las necesidades del usuario, las limitaciones del
estado (por ejemplo, cronograma y el presupuesto), y aceptar (o rechazar) el
sistema o producto; el desarrollador debe desarrollar y entregar un producto
aceptable; en conjunto, el cliente y el desarrollador deben negociar los requisitos
y restricciones y los progresos opinión camente periódica- y resolver problemas.
En el caso general, usuarios, clientes, y adquirente son entidades distintas. Los
usuarios son los que van a utilizar el sistema o producto a sus actividades
laborales o para actividades recreativas; Los clientes son los que se especifican
los requisitos y limitaciones y
Clientes Actividades del

Actividade Activi Proyecto del
s del dades desarrollador
proyecto conjuntas
Cada proyecto de software es de dos o más

proyectos
Figura 2.2 Una simple relación cliente-desarrollador
www.it-ebooks.info
2.3 Un marco de desarrollo-PROCESO 45
Contratistas
afiliadas
Comunida
Cliente
d de usuarios
Comunida Cliente Adquirid principal

d de usuarios or Contratist
a
Comunida Cliente subcontratistas
d de usuarios
FIGURA 2.3 Las relaciones entre los interesados en el proyecto
aceptar el producto en nombre de los usuarios; un adquirente es el agente de uno

o más clientes o grupos de usuarios.
Los clientes y usuarios pueden ser diferentes, sin adquirente designado
formalmente. Por ejemplo, un departamento de marketing o un departamento
aeroespacial interna para su empresa podría ser el cliente que representa una
comunidad de usuarios de los jugadores adolescentes en el primer caso y los
astronautas en el último caso.
Como se ilustra en la Figura 2.3, un adquirente es el agente de uno o más
customers.11 Un cliente individual, tal como una institución financiera, podría
emplear un conocimiento adquirente capaz de conseguir un nuevo sistema de
procesamiento de datos para su organización, o varios clientes podrían colaborar
para adquirir un sistema de software intensivo para el uso compartido. En este
último caso una línea aérea, una agencia de alquiler de coches, y una cadena de
hoteles podrían prohibir juntos para adquirir un sistema de reservas y ventas
integral. Una de las tres compañías podría ser el adquirente designado, o pueden
emplear una organización individual o por separado para servir como su
representante del cliente al proveedor del sistema (designado como el primer
contratista en la Figura 2.3). El proveedor podría utilizar uno o más
subcontratistas para desarrollar una o más partes del sistema. Otros contratistas
podrían estar trabajando en proyectos relacionados que requieren la
comunicación con usted, el contratista principal. O bien, puede ser un
subcontratista; en este caso, su cliente es el contratista principal.
Puede haber relaciones adicionales tal como es representado en la Figura 2.3,
por ejemplo, el contacto directo entre el contratista principal y varios clientes y
usuarios Las comunidades, con las interacciones (s) de ser coordinados por el
comprador.
Un aspecto importante de la planificación del proyecto es identificar todas res
del proyecto stakehold- y establecer vías de comunicación bien definidas entre
ellos. Las partes interesadas incluyen a los usuarios, clientes y adquirente,
además de aquellos individuos y organizaciones que afectan a un proyecto o se
verán afectados por los resultados del proyecto. El impacto del sistema nuevo o
modificado en las actividades de trabajo de las partes interesadas debe tenerse en
cuenta, como en el caso de los trabajadores que deben aprender a seguir nuevos
procedimientos de contabilidad y utilizar el software para un nuevo sistema de
transacción financiera.
Tenga en cuenta que el término “cliente” es relativo al contexto: por ejemplo,
los usuarios son los clientes del departamento de marketing, las organizaciones
que colaboran para adquirir un sistema son los clientes de la entidad adquirente,
el adquirente es el cliente de
www.it-ebooks.info
11
Algunas organizaciones adquirente se denominan integradores de sistemas; se procuran e integrar
componentes y entregan los sistemas resultantes a los clientes.
www.it-ebooks.info
el contratista principal y el contratista principal es el cliente de subcontratistas si

se recurre a la subcontratación. El término “proveedor” (como en la relación
adquirente-proveedor) es también dependiente del contexto. Subcontratistas son
proveedores del contratista principal, el contratista principal es el proveedor al
adquirente, y el adquirente es el proveedor a los clientes y clientes son
proveedores a los usuarios. El grupo de desarrollo es un proveedor del grupo de
prueba independiente; el grupo de prueba independiente es un cliente del grupo
de desarrollo.
En este texto el término “cliente” se utiliza para denotar el individuo o la
organización que especifica los requisitos y limitaciones y acepta el sistema o
producto resultante; “Desarrollador” indica el grupo que se encarga de la entrega
de un sistema capaz de aceptación o producto a tiempo y dentro del presupuesto.
Los términos “cliente”, “adquirente”, “proveedor” y “revelador” se aclararán
cuando los significados no son claramente del contexto de uso.
2.3.2 Requisitos del sistema y Diseño de Sistemas

Como se ilustra en la figura 2.1b, la primera fase del desarrollo del sistema
implica que identifique los valores de los interesados en el proyecto y el
establecimiento de líneas de comunicación entre ellos. El siguiente phases12 del
desarrollo del sistema implica el desarrollo de las necesidades de funcionamiento,
los requisitos del sistema y la arquitectura del sistema. Los requisitos operativos
documentan la vista externa del sistema; que especifican las necesidades, deseos,
expectativas y limitaciones de los usuarios, clientes, compradores y otras partes
interesadas. Es importante que se identifique a todos los interesados y sus
intereses se contabilizan en las necesidades de funcionamiento.
Los requisitos del sistema se derivan de las necesidades de funcionamiento;
que especifican las características y atributos de calidad del sistema debe
proporcionar con el fin de satisfacer las necesidades de funcionamiento. Por
ejemplo, los requisitos operacionales pueden indicar que el sistema debe tener un
tiempo de respuesta aceptable. estudios de viabilidad, onstrations demos- de
prototipos, y discusiones podrían dar lugar a un requisito del sistema que
especifica el tiempo de respuesta de menos de 1 segundo para las consultas de
tipo A y menos de 5 segundos para consultas de tipo B, cuando el sistema está
funcionando a capacidad de carga del 70% ( donde también se especifican los
detalles de las consultas de tipo A y tipo B).
Los requisitos operativos son a veces vaga e imprecisa, pero los requisitos del
sistema deben ser cuantificados en la medida posible debido a los requisitos del
sistema son la base para el diseño, implementación y aceptación del sistema. Es,
por supuesto, es necesario verificar que los requisitos del sistema, si está
satisfecho, se traducirá en un sistema que satisfaga las necesidades de
funcionamiento. Trazabilidad, prototipos y revisiones conjuntas entre el cliente
(s) y el revelador son las técnicas que se pueden utilizar para verificar que los
requisitos del sistema son correctos, completos y coherentes con respecto a los
requisitos operacionales. Los detalles de ingeniería de requisitos se presentan en
el Capítulo 3.
La siguiente fase del desarrollo del sistema en la figura 2.1b es el desarrollo de
la arquitectura del sistema. La arquitectura de alto nivel de un sistema de
software intensivo es típicamente representado como un diagrama de bloques que
ilustra el hardware primaria, software y elementos de personas, además de las
interconexiones entre ellos además de su con-
12
Una fase de desarrollo es un conjunto de actividades de trabajo relacionadas que producen uno o
www.it-ebooks.info
más productos de trabajo. Fases pueden ser intercalados, se superponen, y iterados como se determina
por el proceso de desarrollo que se utiliza.
www.it-ebooks.info
INTERFACES DE LOS CONSORCIO FINANCIERO

^ USUARIOS • Registro automático
usuari • Clientes • Validación de cuenta
os • cajeros • Interfaz ATM
• Apoyo operacional
PROCESAMIENTO DE ATM TERMINAL

CUENTA • Interfaz consorcio
• Repositorio de • ATM hardware
cuentas • Software ATM
• Autorización de la
cuenta
FIGURA 2.4 Un• diagrama
Liquidaciónde
debloques a nivel de sistema para un sistema
cuentas
automatizado Teller
conexiones para el medio ambiente del sistema. Requisitos funcionales y

atributos de calidad se asignan a los diferentes hardware, personas y elementos de
software en la figura. Cada requisito funcional se asigna a un elemento individual
del sistema, mientras que los atributos de calidad pueden aplicarse a uno, algunos
o todos los componentes del sistema.
Además de las especificaciones de los componentes de hardware, las
habilidades requeridas para las operaciones manuales a realizar por los elementos
de la gente, y straints con- diseño de los elementos de hardware y software están
especificados. Un diagrama de bloques a nivel de sistema para un sistema de
cajero automático se ilustra en la Figura 2.4. Como se ilustra, un diagrama de
bloques muestra los componentes principales del sistema, los flujos de
información entre los componentes del sistema, el límite entre el sistema y su
entorno (su contexto), y los flujos de información a través de los límites del
sistema.
requisitos de nivel de sistema se asignan al hardware, software y elementos
manuales del sistema. Requisitos adicionales pueden derivarse para soportar los
requisitos de nivel más alto asignados a los componentes.
2.3.3 Requisitos de software, arquitectura e implementación

requerimientos del sistema asignados al software deben ser revisados, revisados y
valorados a elabo- suficiente detalle para que:
1. complejidades ocultos están expuestos (es decir, el trabajo a realizar se

entiende);
2. oportunidades para la reutilización de componentes de software existentes
pueden ser identificados;
3. los recursos de hardware necesarios, tales como la memoria del ordenador y
velocidad de procesador pueden ser estimadas (que pueden dar lugar a la
revisión del hardware los requisitos); y
4. estimaciones de esfuerzo, habilidades requeridas, y el horario necesario
para desarrollar el software se pueden hacer.
la ingeniería de requisitos se trata en el capítulo 3 de este texto.

El diseño arquitectónico de software, tal como se representa en la figura 2.1b,
se ocupa de la especificación de los principales componentes de software, sus
www.it-ebooks.info
interrelaciones y su
www.it-ebooks.info
TABLA 2.1 Algunas formas de obtener los componentes de software

• Implementar en el local
• Licencia de un proveedor
• Procurar a un subcontratista
• Reutilizar de otro sistema
• Reutilizar de una biblioteca
• Obtener de código abierto
conexiones con el entorno del software. Hay varios tipos de laciones

interrelaciones entre los componentes de software; que incluyen,, ioral tamiento
estructural funcional, y las relaciones de datos. Como resultado los diferentes
representaciones (diferentes puntos de vista) se pueden utilizar para especificar
los diferentes tipos de relaciones entre los componentes y las conexiones de los
componentes para el medio ambiente [Bass03].
En otros tiempos, los componentes de software se obtuvieron por escribir el
código para la mayoría, si no todos, de los componentes. Algunas rutinas de
software a partir de una biblioteca de matemáticas o una biblioteca de E / S
podrían haber sido incorporados, pero la mayoría del software para cada producto
fue escrito por los desarrolladores de software. Actualmente los componentes de
software se obtienen usando una variedad de técnicas, que se enumeran en la
Tabla 2.1.
La aplicación de software implica la realización de diseño detallado,
codificación, y a nivel de unidad V & V. El diseño detallado se refiere a la
especificación de los detalles de caras inter, algoritmos, estructuras de datos, y
otros aspectos de los componentes especificados en el nivel arquitectónico.
Codificación implica escribir el software y a nivel de unidad V & V se refiere a
la determinación de que cada unidad de software (es decir, cada módulo de
software) satisface las condiciones impuestas en ella por los requisitos y el diseño
(verificación) y que cada unidad es adecuada para su destinado utilizar en su
entorno previsto (validación).
Diferentes enfoques para la obtención de componentes de software requieren
diferentes enfoques para la gestión del proyecto. Por ejemplo, el desarrollo de
componentes de la casa requiere:
• planificación detallada de los números y las habilidades de los desarrolladores

de software,
• organizar el equipo (s) de desarrollo,
• la asignación de requisitos a los equipos,
• especificando métricas del proyecto a ser recogida,
• seguimiento de los progresos, y
• la aplicación de las medidas correctivas cuando el progreso real no está de
acuerdo con los avances previstos.
Licensing de componentes implica:
• evaluar los componentes candidatos;

• seleccionar los componentes apropiados; y
• negociar términos, condiciones y fechas de entrega de los componentes
seleccionados.
La adquisición de componentes implica la selección de un subcontratista y la

www.it-ebooks.info
negociación de un contrato que incluye elementos tales como:
www.it-ebooks.info
• el alcance del trabajo a realizar por el subcontratista;

• productos de trabajo que se entregarán al subcontratista (por ejemplo,
requisitos, documentación de diseño, el código fuente a ensayar);
• productos de trabajo que se entregarán por el subcontratista (por ejemplo,
código fuente, los casos de prueba, los resultados de pruebas);
• la fecha de entrega y el coste del proyecto del subcontratista;
• métricas para ser informados y frecuencia de los informes por el proyecto
del subcontratista;
• calendario de reuniones conjuntas y comentarios; y
• sanciones y los derechos en los datos (es decir, que es dueño de qué).
Reutilización implica:
• especificando las características y atributos de calidad de los componentes

para ser reutilizados;
• la localización de componentes candidatos;
• la evaluación de sus características, atributos de calidad, e interfaces; y
• modificándolas según sea necesario.
La obtención de componentes de fuentes abiertas implica:
• la localización de componentes;
• la evaluación de sus características, atributos de calidad, e interfaces; y
• la determinación de los derechos de acceso y pasivos.
proyectos de software suelen utilizar más de una de estas técnicas para obtener
los componentes necesarios. Por ejemplo, algunos de los componentes pueden
ser desarrollados en la casa, algunos reutilizados a partir de una biblioteca de
componentes, y algunos pueden obtenerse a partir de un subcontratista, un
vendedor, o una fuente abierta.
Independientemente de cómo se obtienen los componentes de software, las
siguientes actividades deben ser realizadas: verificar que cada componente es
completa, correcta, y consistentes con respecto a los requisitos de diseño y de
software de arquitectura para ese componente; la integración de los componentes;
verificar que los componentes integrados son correctos, completos y coherentes
con respecto al diseño arquitectónico y los requisitos de software; y validar que
los componentes integrados va a satisfacer su propósito cuando se utiliza en su
entorno de funcionamiento previsto. tivos procesos de desarrollo iterativo apoyar
la implementación gradual, verificación y validación de software, ya que se está
construyendo.
La obtención, verificación, y la integración de componentes de software se
logran mejor de una manera iterativa por la que cada componente se añade
sistemáticamente al producto en crecimiento. Los planes del proyecto sobre la
base de un enfoque iterativo debe incorporar planes de desarrollo iterativo, la
verificación incrementales y validación, y revisiones en curso de mejoras y para
trabajar productos ya que estas actividades no se producen en una secuencia
lineal de pasos cuando los equipos de los individuos se involucran en el creativos
e innovadores actividades de trabajo de desarrollo de software iterativo.
Por ejemplo, la creación de prototipos de la interfaz de usuario durante el
análisis de los requisitos de software puede indicar la necesidad de revisar los
requisitos para las tareas que deben
www.it-ebooks.info
realizado por los elementos humanos del sistema (por ejemplo, las operaciones
manuales realizadas por los operadores de los reactores nucleares, los pilotos de
aviones de combate, o usuarios de iPods). Creación de prototipos de
componentes de software durante la actividad de diseño de software puede indi-
car que los requisitos de rendimiento para un componente en particular no
pueden ser alcanzados en el software. En este caso la funcionalidad para ser
proporcionado por ese componente podría ser re-asignado a un componente de
hardware (por ejemplo, el cifrado y descifrado de datos requerirán un chip de
propósito especial). De manera similar algunos de los requisitos de hardware y /
o funciones manuales pueden ser reasignados al software.
2.3.4 Verificación y validación

La verificación se ocupa de determinar el grado en que un Fulbright producto de
trabajo llena los requisitos y condiciones que se le plantean por otros productos
de trabajo y los procesos de trabajo. Un producto de trabajo verificado es
completa, correcta, y consistente con respecto a los requisitos y condiciones para
que el producto de trabajo. Así, la especificación de los requisitos funcionales de
un sistema y atributos de calidad se puede verificar con respecto a las
necesidades de funcionamiento; el diseño se puede verificar con respecto a las
necesidades de funcionamiento, los requisitos funcionales, y los atributos de
calidad; el código puede ser verificada con respecto a otros productos de trabajo,
incluyendo las exigencias y los diseños arquitectónicos y detallados.
Las técnicas de verificación incluyen:
• trazabilidad,
• los comentarios,
• creación de prototipos,
• análisis, demostraciones y
• pruebas funcionales.
Trazabilidad establece conexiones lógicas entre dos productos de trabajo, por

ejemplo, en el establecimiento de que todos los requisitos asignados a un
segmento del diseño están cubiertos en ese segmento. Críticas son un
procedimiento de verificación aceptable para determinar, por ejemplo, que las
especificaciones técnicas son completa, correcta, y consistente con respecto a los
requisitos operacionales. Prototyping se puede utilizar, por ejemplo, para
determinar que la interfaz de usuario será completa, correcta y coherente con
respecto a las necesidades del usuario cuando se implementa en el producto
entregado. Análisis de software implica el establecimiento de determinadas
propiedades lógicas de software utilizando técnicas formales de razonamiento,
por ejemplo, el establecimiento de la ausencia de condiciones de punto muerto o
la raza en software concurrente utilizando técnicas basadas en el estado.
Validación está estrechamente relacionado con la verificación, pero es un
concepto distinto. En general, la validación de un producto de trabajo se refiere a
la determinación del grado en que el producto de trabajo satisface su propósito
cuando se coloca en en su entorno previsto. Validación, al igual que la
verificación, es un proceso general que se puede y se debe aplicar a todos los
productos de trabajo, tanto intermedios como entregables, durante todo el ciclo
de desarrollo del producto. Por lo tanto la validación del diseño se refiere a deter-
www.it-ebooks.info
2.3 Un marco de desarrollo-PROCESO 51
minera que el diseño es una base adecuada para la ejecución (construcción,

revisión, pruebas, y la integración del código) cuando la especificación de diseño
se coloca en el medio ambiente de los desarrolladores de software y probadores.
Del mismo modo la validación de los escenarios de prueba de software / sistema
se refiere a la determinación de que los escenarios de prueba probarán
adecuadamente el software / sistema cuando se opera en el entorno operativo.
La verificación se suele expresar como: “¿Nos construimos el producto

del trabajo correctamente?”
La validación se suele expresar como: “¿Nos construimos el producto del
trabajo correcto?”
Es perfectamente posible que un producto de trabajo a ser verificada, pero no

validado. Por ejemplo, un diseño arquitectónico se especifica en UML puede ser
verificada a ser correcta, completa y coherente con respecto a los requisitos
(construidos correctamente), pero no sería un documento válido para los
ejecutores y evaluadores si no estaban familiarizados con UML ( no es un
producto de trabajo correcta para ellos) porque la descripción del diseño no
cumpliría su finalidad cuando se coloca en el entorno previsto (el entorno de los
ejecutores y los probadores que no están familiarizados con UML).
Verificación de un sistema para ser entregado (verificación-producto final) se
refiere a la determinación de que el sistema es correcta con respecto a sus
especificaciones técnicas; es decir, ¿se desempeñará las funciones descritas, y
tampoco tiene los atributos de calidad especificados (se ha construido
correctamente)? La planificación de la verificación se produce (o debería ocurrir)
durante el desarrollo de los requisitos del sistema y los requisitos de software.
validación del producto final de un sistema se refiere a la determinación de
que el sistema cumple con su finalidad cuando se coloca en el medio ambiente de
sus usuarios previstos; es decir, que no satisface las necesidades del usuario (es
que el producto correcto)? planes y procedimientos para la verificación y
validación de productos de trabajo entregables en desarrollo son actividades
importantes que se producen (o debería ocurrir) durante el desarrollo de los
requisitos de funcionamiento, requisitos del sistema y los requisitos de software.
técnicas de validación de los productos entregables de trabajo incluyen:
• pruebas de funcionamiento, y
• manifestaciones.
Los comentarios son un procedimiento de validación aceptable para ciertos pro-

ductos de trabajo se puede entregar, tales como planes de pruebas, resultados de
pruebas, materiales de entrenamiento e instrucciones de instalación. pruebas y
demostraciones de funcionamiento se pueden utilizar para validar que el software
cumpla con su finalidad cuando son operados por los usuarios previstos en el
medio ambiente (s) previsto.
La planificación para pruebas de funcionamiento implica especificar los datos
de entrada y otras condiciones ambientales más los resultados requeridos de las
pruebas; por ejemplo, una función matemática debería devolver el resultado
matemático correcta en todas las condiciones, excepto para aquellos que violan la
gama de entradas (por ejemplo, los números para los que la cuadratura del valor
de entrada daría lugar a desbordamiento) y entornos operativos no válidos (por
www.it-ebooks.info
ejemplo,
www.it-ebooks.info
fallo en el hardware del coprocesador matemático). Las pruebas adicionales

deben planificarse y llevarse a cabo para determinar que el manejo de
excepciones para los valores de entrada fuera de la gama y entornos
operacionales defectuosos se realiza correctamente.
Una demostración difiere de una prueba en la que la aceptabilidad de los
resultados no se puede predecir con certeza. Por ejemplo, una demostración de la
interfaz de usuario para los usuarios con conocimientos puede revelar
deficiencias desde su punto de vista, a pesar de que la interfaz proporciona las
características y atributos de calidad especificados. Otro ejemplo: puede que no
sea posible predecir la secuencia de movimientos de un programa de ajedrez hará
(pruebas), pero los expertos (maestros de ajedrez) puede determinar el nivel en el
que el programa se reproduce mediante la observación de las manifestaciones de
los movimientos realizados por el programa.
Por desgracia, a veces ocurre que un sistema de entrega se verifica (fue
construido correctamente en que satisface sus especificaciones técnicas) pero no
es válido (no es correcta, ya que no satisface las necesidades del usuario). Esto
puede ocurrir debido a las necesidades de funcionamiento de la cual se generaron
las especificaciones técnicas no son correctos, o debido a las necesidades de
funcionamiento correctas no se tradujeron correctamente en las especificaciones
técnicas, o porque las especificaciones técnicas correctas fueron traducidos
incorrectamente en el diseño y el código. En estos casos, un sistema, tales como
un vehículo de lanzamiento de satélites pueden desviarse de su curso y tienen que
ser destruidos, o un sistema de uso intensivo de usuario puede ser rechazado por
los usuarios, ya que satisface sus necesidades.
La planificación para la verificación y validación de productos de trabajo
entregables (V & V) durante el desarrollo de los requisitos también es útil para
determinar el grado de comprensión de los diversos requisitos de los ingenieros
de sistemas y desarrolladores de software (es decir, los requisitos operacionales,
especificaciones funcionales y los atributos de calidad). Incapacidad para
especificar criterios objetivos de V & V indica que los requisitos ATED aso-
pueden ser vagos, ambiguos o incompletos. La necesidad de elaboración
adicional de los requisitos es así indicada.
2.4 Adaptar el sistema de ingeniería SISTEMA PARA PROYECTOS

sólo de software
La figura 2.1b ilustra un marco de procesos para el desarrollo de sistemas

intensivos en software que incluyen hardware, software y elementos de la gente.
Muchos proyectos de software tienen que ver con el desarrollo de software de
aplicaciones para las que el hardware y el sistema operativo son proporcionados
por un equipo fuera de la plataforma, y no se requiere ningún entrenamiento
especial para los usuarios, operadores o personal de apoyo operativo. La
plataforma de mercancías / software hardware se puede especificar como una
restricción de diseño o puede ser seleccionado como parte del proceso de análisis.
Puede ser, por ejemplo, que su proyecto será desarrollar un software que
deben trabajar en conjunto con el software existente que se implementa en los
equipos existentes que se utilizan en la organización del cliente. De este modo se
especifica la plataforma de hardware / software como una restricción de diseño.
Figura 2.5 ilustra la adaptación del marco de desarrollo en la figura 2.1b para
estos proyectos de software de sólo; los elementos a nivel de sistema se han
eliminado de la figura 2.1b y se ha añadido una actividad Especificar Hardware /
Software plataforma. Para proyectos de software-solamente, los requisitos
www.it-ebooks.info
operativos proporcionan la base para el desarrollo de los requisitos de software.
Los requisitos operativos proporcionan el externo, el usuario
www.it-ebooks.info
2.4 Adaptar el sistema de ingeniería SISTEMA 53
Desarrollar
Requisitos de
Software
Especificar Diseño
Plataforma de Arquitectura
hardware / de software
Obtener
software Los
Verificación componente
Documento de software s de
Requisito software
Integrar
operacional Los
componente
comi s de
enzo Validación software
aquí operativa
Las necesidades y
expectativas del cliente Fin
usuario desea Acquirer aquí
Condiciones
Figura 2.5 Un marco de desarrollo de proyectos de software de sólo
especificación orientada del sistema; los requisitos de software son la

especificación interno, orientado al desarrollador del sistema. Como antes, las
flechas y sombreados en la Figura 2.5 representan algunos de los muchos
caminos iterativos y revisiones de proyectos de software.
En su mayor parte, este texto se centra en la gestión de proyectos de software
sólo para los cuales los principales procesos de desarrollo se representan en la
Figura 2.5. Varias formas de adaptación de la figura 2.5 para los modelos de
procesos de desarrollo de software comúnmente utilizados se presentan en la
sección siguiente.
Un principio fundamental de la ingeniería de
software es:
los procesos utilizados para desarrollar un sistema de software o producto deben

ser diseñados con el mismo cuidado que se utiliza para diseñar el producto.
El diseño del producto se logra mejor a partir de un marco arquitectónico (o

estilo arquitectónico) y adaptar para que se ajuste a las necesidades del producto.
En un diseño de proceso de manera similar se logra mejor a partir de un marco de
proceso y adaptar para que se ajuste a las necesidades del proyecto. La
adaptación de un marco consiste en añadir, eliminar y modificar elementos del
marco para satisfacer las necesidades de las situaciones específicas.
El marco para el desarrollo de software en la Figura 2.5 se puede adaptar para
representar los modelos de proceso más frecuentemente utilizados para
desarrollar software. Estos modelos de desarrollo, a su vez, puede ser adaptado a
las necesidades de sus proyectos. Los siguientes secciones de este capítulo se
refieren a estos modelos.
Como todos los modelos, los modelos de desarrollo de software hacen
hincapié en los aspectos de interés y suprimen detalles que no son importantes
para los aspectos que está siendo modelado. Y, como todos los modelos, los
detalles se pueden elaborar en modelos subordinadas. La Tabla 2.2 muestra los
modelos de desarrollo de software que se describen en este capítulo y los
aspectos de desarrollo de software que se destacan por esos modelos.
www.it-ebooks.info
TABLA 2.2 énfasis principales de algunos modelos de desarrollo de software

Énfasis
Los modelos tradicionales
HackingWriting código sin análisis o la planificación Requisitos-a-
codeWriting código basado en requerimientos operacionales fases de desarrollo y
WaterfallSequential hito opiniones
modelos iterativos
Incremental buildIterative ciclos de codificación, verificación, y demostración
EvolutionaryIterative evolución de requerimientos, diseño y código
AgileIterative la evolución de las necesidades y código
Spirála meta-modelo para el desarrollo iterativo que hace hincapié en la gestión de
riesgos y enfoques alternativos
2.5 El software tradicional MODELOS DE DESARROLLO DE PROCESO
En esta sección se presentan los modelos tradicionales del proceso de desarrollo

de software que han sido, y en algunos casos siguen, que se utilizará.
2.5.1 Seco
En la ingeniería de software, el término “piratería” tiene dos significados:
1. para obtener subrepticiamente acceso a los sistemas y los datos de forma no
autorizada; y
2. escribir código sin ninguna planificación previa.
Es la segunda acepción a la que nos referimos; un “proceso” piratería desarrollo
consiste en escribir código sin antes entender o documentar las necesidades del
usuario y los requisitos técnicos, el desarrollo de una descripción del diseño, o la
preparación de un plan de pruebas. La piratería se caracteriza por la caricatura
que representa a un jefe de proyecto diciendo a los desarrolladores de software,
mientras camina por la puerta “de empezar a programar y voy a ir a buscar lo que
quieren.”
Aparte de estos problemas, la piratería antes de tiempo obliga a los procesos
mentales implicados en el desarrollo de software a un nivel inadecuado de detalle
antes se entienden las preocupaciones de nivel superior. El codificador está
tratando al mismo tiempo de prever los requisitos, el diseño y las consideraciones
de prueba y expresarlos en la sintaxis y la semántica del lenguaje de
programación. Como se mencionó en el Capítulo 1, toda la descripción de un
producto de software suele ser demasiado complejo para toda la descripción que
se escribe directamente en un lenguaje de programación [Jack02], por lo que
debemos preparar diferentes descripciones en diferentes niveles de abstracción, y
para diferentes propósitos.
Para interpretar el modelo de Hacking, la adaptación del marco en la Figura
2.6 ates degenerado a la eliminación de todos los elementos del marco excepto
Obtener componentes de software y reformular como Escribir el código. Sin
embargo, no hay que pasar tiempo adaptar el marco en la figura 2.6 para dar
cabida a la piratería informática (es decir, adaptando el modelo fuera de la
existencia). Un mejor enfoque es: No permita que sus desarrolladores de software
para hackear el código!
www.it-ebooks.info
2.5 modelos de desarrollo SOFTWARE proceso tradicional 55
Especificar
Plataforma de
hardware /
software Obtener
Los
componente
Documento s de
Requisito Integrarsoftware
operacional Los
componente
comi s de
enzo Validar software
aquí Los deseos y Sistem
necesidades de los a Fin
usuarios aquí
Las expectativas de los
clientes Acquirer
Condiciones
Figura 2.6 El modelo de desarrollo Requisitos a código
2.5.2 Requisitos-a-Code
En comparación a la piratería, el desarrollo Requisitos a código tiene la virtud de
desa- oping una comprensión de las necesidades a satisfacer por el software
nuevo o modificado antes de la implementación del software. En un proceso
Requisitos a código, los requisitos operacionales son provocados y pueden o no
pueden ser documentadas, pero caciones speci- técnicos para los requisitos de
software no están desarrolladas y no se genera una especificación de diseño.
Dependiendo del rigor con el que se implementa el modelo, los requisitos
operacionales pueden o no pueden ser colocados bajo el control de versión y un
plan de validación basado en dichos requisitos pueden o no ser desarrollado. Un
proceso Requisitos a código puede ser utilizado para desarrollar código prototipo
de “usar y tirar” para mostrar una maqueta de una interfaz de usuario.
La omisión de los resultados de la fase de diseño en el fracaso para identificar
sistemáticamente los componentes del sistema, las interconexiones entre ellos, y
sus conexiones con el ronment bientes. En consecuencia requisitos no se asignan
de forma sistemática a los componentes y las oportunidades para la reutilización
de los componentes existentes no se identifican de forma sistemática. Al igual
que con el modelo de Hacking, estas consideraciones de nivel superior, si consi-
Ered en absoluto, se contabilizan a un nivel inadecuado de detalle en la sintaxis y
la semántica del lenguaje de programación.
Para un proceso de Requisitos de a-código, adaptando el marco de proceso en
la figura
2.5 implica la eliminación de los requisitos de software desarrollar, y Diseño
arquitectura de software, las fases y la actividad de verificación de software
desde el marco, como se ilustra en la Figura 2.6. Tenga en cuenta también que los
circuitos de retroalimentación iterativos e iteraciones sombreadas en la Figura 2.5
se han eliminado en la Figura 2.6.
2.5.3 El modelo de desarrollo de la cascada

En su artículo seminal “Gestión del desarrollo de sistemas de software de gran
tamaño: conceptos y técnicas”, publicado en 1970, Winston Royce presenta
varios enfoques para el desarrollo de software para ilustrar las deficiencias de los
enfoques
www.it-ebooks.info
tales como los requisitos a código [Royce70]. Uno de los modelos que presentó
fue un modelo de alimentación hacia adelante que hace hincapié en el flujo lineal
de productos de trabajo a través de diversas fases de desarrollo y las revisiones de
hitos asociados cuyo propósito es verificar que los productos de trabajo de las
distintas fases de desarrollo son completos, coherentes y correctos con respecto a
los productos de trabajo anteriores. Ese modelo, que no se citan por él, ha llegado
a ser conocido como el modelo de la cascada; Winston Royce está por lo tanto
conocido como el padre del modelo de cascada. Esto es lamentable porque
Royce, en su papel, no recomendó el modelo; que indica claramente la necesidad
de iteración entre las distintas fases de desarrollo de software.
El objetivo del desarrollo de la cascada es proceder a través de una secuencia
lineal de las fases de desarrollo, que incluye una revisión de los al final de cada
fase de desarrollo. Una versión de la cascada de la figura 2.1b se ilustra en la
figura 2.7, en la que las flechas de retroalimentación e iteraciones sombreadas se
han eliminado de la figura 2.1b.
La representación tradicional del modelo de cascada se ilustra en la figura 2.8;
Figura
2.7 ha sido “desenrollada” para destacar las fases de trabajo lineales y hitos
asociados. El modelo se denomina una cascada debido a los productos de trabajo
se supone que la cascada de fase en fase en una progresión suave, como cascadas
de agua en una cascada.
El propósito de una revisión de los es verificar que los productos de trabajo
bajo estudio son completa, consistente y correcta con respecto al (wrt) otros
productos de trabajo; es decir, para verificar las necesidades de los usuarios
operacionales requisitos wrt, para verificar los requisitos de software WRT los
requisitos del sistema y los requisitos operacionales, y así sucesivamente. Un
éxito revisión de los resultados en los productos de trabajo revisados
Asignar los
requisitos de
hardware
Asignar las
personas
requisitos Desarrollar Asignar y refine
Arquitectur Requisitos de
a del software
Sistema
Desarrollar
Arquitectur
especificar
a de
Sistema Obtener
Software
requisitos software
software componentes
verificación
Definir las
necesidades integrar Software
operacionale componentes
s
comi sistema
enzo verificación
aquí
Las necesidades y integrar
expectativas del cliente añadir otra
Sistema
usuario desea Acquirer validación componentes
componente
Condiciones operaciona s
l
termi
na
aquí
www.it-ebooks.info
Figura 2.7 Cascada adaptación de la figura 2.1b
www.it-ebooks.info
2.5 modelos de desarrollo SOFTWARE proceso tradicional 57
necesidades de
los usuarios SRR
Requerimientos operacionales Validación:
hicimos
SSR construimos
Sistema Rqmts y Diseño
el sistema correcto?
PDR
Requisitos de Software CDR
TRR
Verificación: Diseño de software
estamos STR
construyendo Implementación
el sistema
correctamente?
SRR: requisitos del sistema SSR:

SAR
Pruebas de software
Especificación del software Fijar
Revisión PDR: Diseño Preliminar COCHE
CDR opinión: Revisión Crítica del Prueba del
Diseño sistema
TRR: Prueba STR Revisión de la Examen de ingreso
preparación: Revisión de Pruebas
de Software
SAR: Sistema de Revisión de
Aceptación CAR: revisión de la
aceptación del cliente
Figura 2.8 representación tradicional del modelo de la cascada con hitos
de ser colocado bajo control de versiones para proporcionar una línea de base
(una base) para el trabajo posterior. Una revisión de los éxito al final de la fase de
diseño, por ejemplo, daría lugar a una línea de base de diseño que se ha
verificado que es correcta, completa y coherente con respecto a los requisitos y
necesidades de los usuarios, y que a continuación, proporciona la base para la
implementación de software . Los cambios posteriores en los productos de
trabajo baselined deben ser aprobados por las personas autorizadas para realizar
los cambios (es decir, una tarjeta de control de cambio).
opiniones Milestone se refieren a veces como “puertas de control”, es decir
que no se abrirá la puerta para pasar a la siguiente fase hasta que se corrijan los
problemas identificados durante una revisión de hito. O la puerta puede ser
abierta parcialmente para dejar algo de trabajo continuar mientras se corrigen
problemas en otras áreas.
El objetivo del modelo de cascada es desarrollar un sistema de una sola
pasada, pero, como estados Royce en la descripción del modelo de requisitos-a-
código: “Este tipo de concepto de aplicación muy simple es, de hecho, todo lo
que se requiere si el esfuerzo es sufi - cientemente pequeña y si el producto final
va a ser operada por aquellos que lo construyó ...”13. El mismo podría decirse del
modelo de la cascada.
La planificación de un proyecto de cascada consiste en determinar un
calendario de fases y opiniones e identificando los recursos necesarios para llevar
a cabo cada fase del trabajo. A menudo, una limitación de la duración del
proyecto determina el tiempo disponible para cada fase de desarrollo y
programación de las revisiones de hitos. Un horario determinado de esta manera
(un horario de dictado) puede o no puede ser adecuado. Milestone comentarios
son el principal mecanismo de seguimiento del progreso de un proyecto de
www.it-ebooks.info
cascada. El principal mecanismo de control es el aspecto de la “puerta de
control” de los comentarios.
El modelo de la cascada tiene muchas deficiencias como un modelo para la
naturaleza creativa, intelecto-intensivo de desarrollo de software; por ejemplo,
revisiones iterativos
13
Actas, IEEE Wescon, de agosto de 1970, página 1.
www.it-ebooks.info
TABLA 2.3 Mecanismos de planificación y control de proyectos de software tradicionales

Desarrollo ModelPlanning y Mecanismos de control
HackingNone
Requisitos-a-codeRequirements línea de base, el código validación
WaterfallLinear fases de desarrollo, revisiones de hitos, líneas de base, tablero
de control de cambios, verificación y validación
de trabajo de los productos que no se planea con anticipación y por lo tanto

representan interrupciones en las actividades de trabajo previstas cuando sean
necesarias (como siempre lo hacen). Otros Ings shortcom- incluyen el uso de hito
infrecuentes revisa como indicadores de progreso. Una fase de desarrollo de la
cascada por un gran proyecto puede tardar varios meses. Basándose en mile-
opiniones de piedra como los principales indicadores de progreso (o falta de ella)
no puede detectar problemas que puedan haber ocurrido, y podría haber sido
fijados, mucho antes. Otro defecto se retrasa la validación de los productos
entregables de trabajo hasta que la fase final del proyecto. Esto se traduce en
trabajo costoso y retraso en la entrega si se encuentra que los productos de
trabajo entregables no puede ser validado (es decir, el sistema no va a satisfacer
su propósito cuando se opera por sus usuarios previstos en su entorno previsto).
El problema fundamental del proceso de desarrollo de la cascada es ing
sequenc- lineal de las fases del proyecto (análisis, diseño, implementación,
validación). modelos de desarrollo iterativos superar estos problemas mediante la
intercalación sistemática y Øver- lamiendo las actividades de trabajo de las fases
de desarrollo de diversas maneras.
2.5.4 Directrices para la planificación y control de proyectos de software

tradicionales
La Tabla 2.3 resume los principales mecanismos para la planificación y control
de los proyectos para los modelos tradicionales de desarrollo de software
(piratería informática, Requisitos a código, cascada).
2.6 modelos de procesos-desarrollo iterativo
Desarrollar y modificar software implica procesos creativos que están sujetas a

muchas fuerzas externas y cambiantes. Una larga experiencia ha demostrado que
es imposible “hacerlo bien” la primera vez, y que los procesos de desarrollo
iterativos son preferibles a los procesos de desarrollo lineal, tales como los
requisitos a código y desarrollo en cascada. En el desarrollo iterativo, cada ciclo
de la iteración subsume el software de la iteración anterior y añade nuevas
capacidades para el producto en evolución para producir una próxima versión, la
ampliación del software.
procesos de desarrollo iterativo proporcionan las siguientes ventajas:
• integración continua, la verificación y validación del producto en evolución;

• manifestaciones frecuentes de progreso;
• la detección precoz de defectos;
• detección temprana de problemas en el proceso;
www.it-ebooks.info
2.6 modelos de procesos-desarrollo iterativo 59
• incorporación sistemática de la inevitable reproceso que se produce en el

software de desarrollo; y
• entrega temprana de las capacidades de subconjuntos (si se desea).
El desarrollo iterativo toma muchas formas en la ingeniería de software:
• prototipado iterativo se puede utilizar para desarrollar una interfaz de usuario

o explorar un tema cal técnicamente;
• un proceso incremental-build puede ser utilizado para producir
semanalmente obra de las capacidades del producto ing increas-;
• El desarrollo ágil se puede utilizar para asociar estrechamente a un cliente
prototípico en un proceso iterativo que puede repetir a diario;
• un modelo espiral evolutiva se puede utilizar para enfrentar y mitigar los
factores de riesgo encontrados en el desarrollo de las versiones sucesivas de
un producto en base a los requisitos de ING en evolución.
Cada uno de estos modelos se describe a continuación.
2.6.1 El Modelo Incremental-Build

Retrasar la validación hasta la fase final de desarrollo de software es un
importante corto venida del modelo de cascada. Problemas que podrían haber
sido encontradas anteriormente no se encuentran hasta el momento de la entrega
cerca, y los problemas que se encuentran última son los más caros de solucionar.
Como se ilustra en la Figura 2.9, encontrar y corregir un defecto de requisitos
durante la prueba del sistema puede costar 100 veces más de corregir que se fijan
durante la fase de requisitos; Del mismo modo la búsqueda de un defecto de
diseño durante la prueba del sistema puede costar 50 veces más para fijar como
encontrarlo y fijándolo durante el diseño [BOEHM81].
Así, el coste relativo aumenta de manera exponencial debido a que más
productos de trabajo de aumento de los niveles de detalle y volúmenes de
contenido se han generado en fases sucesivas de desarrollo. La fijación de un
defecto requisitos durante una revisión de los requisitos puede implicar el cambio
algunas palabras, como corregir “el cajero automático no permitirá que múltiples
transacciones por sesión” para “el cajero automático le permitirá múltiples
transacciones por sesión.” La fijación de este defecto durante la validación
prueba de la entrega
Coste
1000 relativo
100
1
Rqmts DesignCode TestUse
Fase del Ciclo de Vida
FIGURA 2.9 costo relativo de encontrar y corregir un defecto de software
www.it-ebooks.info
sistema puede requerir cambios en el código en varios lugares diferentes, además

de volver a escribir y volver a ejecutar las pruebas de validación asociados. Esta
corrección, lo que habría llevado menos de un minuto durante una revisión de los
requisitos, podría tomar mucho más de 100 minutos durante las pruebas de
validación. El esfuerzo requerido para corregir un defecto cuando el sistema está
instalado en varias ubicaciones (es decir, “por campos”) es aún mayor debido a
que el software debe volver a instalarse en cada ubicación (es decir, cada
terminal ATM).
El modelo incremental-build es un modelo de desarrollo-prueba-de demostrar
el desarrollo iterativo en el que se hace hincapié en las manifestaciones
frecuentes de progreso y la verificación y validación de trabajo hasta la fecha.
Figura 2.10 es una adaptación de la figura 2.5 para un proceso incremental-build.
Tenga en cuenta, en particular, que una fase de diseño de partición se ha añadido.
Requisitos se asignan a diversos elementos de la arquitectura de software, y la
arquitectura se divide en una secuencia de prioridades de las construcciones.
Cada generación añade nuevas capacidades para el producto de forma
incremental cada vez mayor. Figura 2.10 se ha adaptado más allá al subsumir la
opción Obtener componentes de software e integración de componentes de
software en un Construir e integrar Características del conjunto I actividad.
También una versión de demostración i Link se ha añadido. El proceso de
desarrollo termina cuando se verifica versión N (la versión final),
Figura 2.11 es una representación “desenrollada” de la figura 2.10 que ilustra
los detalles de la acumulación de verificar-validate-demostrar ciclos en el
proceso Incremental-build. Un “ciclo de acumulación” incluye el diseño
detallado, implementación, integración, revisión y pruebas por los
desarrolladores. En los casos donde el código se va a reutilizar sin modificación,
parte o la totalidad de un Incremental-build puede consistir en revisión,
integración y prueba del código base aumentada con el código reutilizado.
Construye de versiones demostrables, funcionamiento del sistema se producen
con frecuencia, típicamente sobre una base semanal o bisemanal, siendo semanal
la norma.
Desarrollar
requisitos de
software
Diseño de la
configuració
n del
Especificar software Se reparte
plataformas de
hardware / el Diseño
software
Verificación
de software
adquirent
Documento de e
requisitos
operacionales
Validación operativa
Emp
ieza
aqui El usuario
Versiones
de
necesita las
demostració
expectativas del cliente
Condiciones n
www.it-ebooks.info
C ir e integrar uí
Conjunto de F
o
característica i
n
s i; n
s
t Capacidades
de a
r
demostración q
u
FIGURA 2.10 Adaptación de la figura 2.5 para el proceso de Incremental-build
www.it-ebooks.info
diseño de
particionamie
nto demostrar
Verificar y Feature Set 1
Construir
Feature Set 1 Validar
conjunto de
características demostrar
Construir y 1 Verificar y Validar FS 1 + FS 2
Integrar Feature Conjuntos de
Set 2 características 1 +
2
••• Verificar y manifestac
•••••• validar ión
incremental •••••• FS1 +. . .
Rehacer
Construir y Verificar y
Integrar validar
Conjunto de FS1. .FSN
funciones N entregar
FS 1 +. . . + FS N
Hora
FIGURA 2.11 Formación progresiva verificar-validate-demostrar ciclos
Verificación de una acumulación se ocupa de determinar el grado en que la

construcción es completa, correcta y coherente con respecto a los requisitos y el
diseño de la versión actual (que incorpora los requisitos, diseño y código para
construye todo antes). Validación de una acumulación se ocupa de determinar el
grado en que la acumulación demostrado va a satisfacer su propósito previsto en
su entorno previsto. Verificación y validación puede resultar en la reanudación de
los componentes desarrollados anteriormente para acomodar mejor los nuevos
componentes se integran, o para reparar defectos en los componentes
desarrollados anteriormente expuestos mediante la adición de los nuevos
componentes, o para reparar defectos en los nuevos componentes.
Algunos (tal vez todas) de las compilaciones en un proceso incremental y
construcción se suelen demostrarse para validar el progreso al día para
representantes de los usuarios, el cliente (s), y / o el adquirente. Otros construye
puede ser demostrada por usted (el director del proyecto), su equipo de
desarrollo, y tal vez por sus gerentes para proporcionar evidencia con- creto que
el proyecto es (o no es) de proceder según lo previsto. En cualquier caso, las
manifestaciones frecuentes de progreso (o falta de la misma) son un beneficio
importante de un proceso de desarrollo Incremental-build.
Figura 2.12 ilustra el diagrama de hito para un proyecto de seis meses para
construir una piler com- utilizando el modelo de Incremental-build. Los primeros
2 meses se asignan a análisis y diseño seguido de 8 quincenal acumulación
Verificar-validate-demostrar ciclos. El software desarrollado por cada incremento
se añade a la creciente base. El diseño se divide de manera que cada generación
proporciona las interfaces y funcionalidades necesarias para la próxima
generación.
Figura 2.12 ilustra otra ventaja del proceso Incremental-build, a saber, la
capacidad de hacer gracia compensaciones entre las características del producto,
los recursos y el calendario de entrega. Si, por ejemplo, el compilador no está
listo para la entrega en la fecha prevista
www.it-ebooks.info
requisitos Milestone diseño Milestone

Rqmts Diseño Implementación*
1 mes 1 mes 4 meses

V0.1: lector de
entrada
V0.2: además de escritor de salida
V0.3: plus v0.4 analizador
léxico: además de
demo1
símbolo de la tabla
V0.5: además de generador de código
demo2 V0.6: plus tabla enlazador
demo3
V0.7: además de los
Demo4 mensajes de error
Demo5 v0.8: plus
optimizador
Demo6
* Ejecución de cada incremento
incluye el diseño detallado, DEMO7
codificación, revisión, prueba y
demostración
Demo &
Deliver V1.0
FIGURA 2.12 Un ejemplo incremental y

construcción
al final de seis meses, una elección puede hacerse entre la entrega de una primera
versión del compilador sin el optimizador, o extender el horario para permitir la
finalización del proyecto. Debido a los hitos de demostración frecuentes, se
proporciona una alerta temprana de deslizamiento en el calendario de entrega y
ofrece la opción de añadir más o mejores a los desarrolladores del proyecto para
cumplir con la fecha de entrega (siendo consciente de la ley de Brooks, tal como
se describe en el capítulo 1). Debido a la historia detallada de los avances,
debería ser posible estimar con precisión la cantidad de tiempo necesario para
entregar la versión final del compilador en caso de un retraso horario.
Un gran proyecto puede implicar decenas o incluso cientos de ciclos
incrementales, muchas de las cuales pueden ser realizadas por diferentes equipos
que trabajan en paralelo. En estos casos, la planificación también es gradual. La
planificación inicial del proyecto contiene las principales actividades que deben
franquearse y los hitos del cronograma para completarlas; planes detallados se
desarrollan de manera gradual. la planificación incremental se analiza en el
Capítulo 4.
Control de los proyectos de construcción incremental-monitoreo y se basan en
revisiones hito para requisitos y el diseño arquitectónico y en las de-
mostraciones frecuentes de los avances que se producen durante los ciclos de
compilación-Verify-validate-demostrar. En algunos casos el plan del proyecto
puede incorporar entrega temprana de las capacidades de subconjuntos para uso
operacional mientras que las iteraciones restantes se completan. Si, por ejemplo,
el compilador se muestra en la Figura 2.13, es un nuevo lenguaje de
programación, a continuación, v0.7 (mensajes de error) podría implementarse
siguiente v0.4, y el subconjunto se podría entregar a los usuarios del compilador
para que pudieran aprender para escribir programas sintácticamente correctas
mientras se completa el compilador.
verificación Incremental, validación, y la demostración como se ilustra en las
Figuras
www.it-ebooks.info
2,11 y 2,12 superar dos de los principales problemas de un enfoque Cascada: (1)
problemas están expuestos temprano y se pueden corregir a medida que ocurren;
(2) menor en-scope cambios en los requisitos que se producen como resultado de
las manifestaciones incrementales se pueden incorporar en la posterior
Incremental-construye.
www.it-ebooks.info
El proceso incremental-build funciona bien cuando cada equipo se compone

de dos a cinco desarrolladores más un jefe de equipo (que es también un
colaborador técnico). Los miembros del equipo pueden trabajar individualmente
o en parejas. Cada individuo o pareja puede producir no oficial construye sobre
una base diaria usando una copia de la versión oficial actual como un banco de
pruebas. Una acumulación oficial que integra, verifica, valida y demuestra el
progreso realizado por todos los equipos de desarrollo se produce sobre una base
semanal o quincenal.
El modelo incremental-build puede ser ampliado para grandes proyectos
mediante la partición de la arquitectura en subsistemas bien definidos y la
asignación de los requisitos y con interfaces para cada subsistema. Los
subsistemas pueden ser probados de forma independiente y demostrar strated, tal
vez utilizando los trozos y los conductores para las interfaces del subsistema, o
tal vez usando primeras versiones incrementales de otros subsistemas en
evolución. La integración del sistema puede proceder de forma incremental como
versiones intermedias de los diversos subsistemas sean operativos.
Figura 2.11 ilustra que puede ser posible para solapar, en el tiempo, sucesiva
construye del producto. Puede ser posible, por ejemplo, para iniciar un diseño
detallado de la próxima versión, mientras que la versión actual está siendo
validada. Hay tres factores que determinan el grado de solapamiento que se
puede lograr:
1. disponibilidad de personal suficientes para perseguir simultáneamente

múltiples actividades,
2. progreso adecuado en la versión anterior para proporcionar las capacidades
necesarias para la siguiente versión, y
3. el riesgo de retrabajo significativo que debe llevarse a cabo si la verificación y
validación de la generación anterior pone de manifiesto los problemas que
invalidan la labor realizada en la próxima construcción superpuesta.
Cambios significativos en los requisitos, limitaciones de diseño, o factores

ambientales (por ejemplo, cambios de middleware API o características de
hardware) pueden requerir la reanudación significativa del diseño y el código
existente en un proceso incremental y construcción (que es cierto para todos los
modelos de procesos de desarrollo).
Una ventaja significativa de un proceso incremental-construcción es que las
características incorporadas primero se verifican, validado y demostrar con
mayor frecuencia debido a la posterior construye incorporar las características de
construye el anterior. En la construcción del software para controlar un reactor
nuclear, por ejemplo, el software de apagado de emergencia se podría construir
en primer lugar. El funcionamiento de parada de emergencia (scramming) sería
entonces ser verificada y validó en conjunción con las características de cada
generación sucesiva.
La planificación de un proyecto incremental y construcción consiste en la
planificación para el análisis y el diseño de la planificación, más el número y
frecuencia de las versiones iterativas para ser construido y demostrado. El
número de iteraciones se determina por la partición del diseño. La Tabla 2.4
enumera algunos criterios de particionamiento de desarrollo incremental.
iterativo
TABLA 2.4 Algunos criterios de particionamiento de compilaciones incrementales
www.it-ebooks.info
Mas o menos SystemPartitioning criterios
packageEssential aplicación características primero; deseables priorizados
próximo
Seguridad crítica systemsSafety cuenta primero; priorizados los demás siguiente
-Usuario intensivo interfaz systemsUser primero; priorizados los demás siguiente
Sistema softwareKernel primero; utilidades priorizadas siguiente
www.it-ebooks.info
ciones deben ser planificadas para las duraciones de una semana de trabajo para
cada uno. Una semana de incrementos y el número de desarrolladores disponibles
para trabajar en el proyecto determinar el número de funciones que se pueden
incluir en cada incremental y construcción. Esto a su vez determina el calendario
general.
manifestaciones frecuentes del sistema de cultivo proporcionan un mecanismo
objetivo para monitorear el progreso en un proceso incremental y construcción.
Indicadores de problemas incluyen:
1. la falta de aplicación del número previsto de características en un ciclo dado,

2. rendimiento inadecuado o uso excesivo de los recursos informáticos en una
acumulación verifican-validate-demuestran ciclo y
3. excesiva reanudación de las versiones anteriores para dar cabida a la versión
actual.
Las acciones correctivas pueden ser tomadas antes de los problemas resultan en
una situación de crisis. acción correctiva debe ser tomada, por ejemplo, si el
retrabajo para reparar defectos excede 20% del esfuerzo en cada uno de dos
ciclos de construcción sucesivas. Las acciones correctivas pueden incluir la
revisión de los requisitos, volver a trabajar el diseño, la fijación del código, la
adquisición de una nueva herramienta de pruebas, proporcionando cursos de
actualización sobre revisiones por pares, o la revisión de la programación
incremental-construcción para permitir más tiempo para hacer un trabajo
adecuado.
En resumen, el modelo incremental-construcción, al igual que todos los
modelos iterativos, ofrece las ventajas de la integración continua y validación del
producto en evolución, demostraciones frecuentes de progreso, la alerta
temprana de problemas, la entrega temprana de las capacidades de subconjuntos,
y la incorporación sistemática de la retrabajo inevitable que se produce en el
desarrollo de software.
2.6.2 El modelo evolutivo

El término “evolución” en un proceso de desarrollo evolutivo se refiere a la
evolución sistemática de requisitos, diseño y código. El modelo incremental-
build puede tolerar algunos pequeños cambios (cambios en el estudio) en los
requisitos y el diseño sin renegociar calendario y el presupuesto; por el contrario,
un modelo evolutivo es apropiado en los casos en que los requisitos y la
arquitectura de software no puede ser (en su mayoría) se especifica por
adelantado o cuando es probable que sufrir cambios significativos durante el
desarrollo. Un modelo evolutivo puede ser adecuado para las fases iniciales de un
nuevo tipo de proyecto para el que no existe la historia corporativa.
Figura 2.13 ilustra la adaptación de la figura 2.5 para un proceso de desarrollo
evolutivo. Como se ilustra en la figura 2.13, cada iteración de un proceso
evolutivo es un mini-cascada que implica:
• la evolución de las necesidades de funcionamiento y los requisitos de

software,
• el diseño del software para esa iteración,
• la obtención y la integración de los componentes,
www.it-ebooks.info
• verificar y validar el software resultante, y
• evaluación de los resultados.
www.it-ebooks.info
2.6 modelos de procesos-desarrollo iterativo sesenta y cinco
Evolucionar
Requisitos
de Software
Diseño
Software
Obtener
Los
componente
Verificar s de
Evolucionar Software
Requerimient Integrarsoftware
os Los
operacionales componente
comi Validar
s de
enzo Software
software
aquí
necesidades de
los usuarios Demostrar Fin
Las expectativas de los Producto
clientes Acquirer
aquí
Condiciones
FIGURA 2.13 Adaptación de la figura 2.5 para el proceso de desarrollo evolutivo
Cada ciclo en un proceso de desarrollo evolutivo debe limitarse a no más de

un mes para evitar que la mini-cascada se convierta en un maxi-cascada.
Al final de cada ciclo de desarrollo, una evaluación de los resultados, basada
en la verificación, validación y demostración revelará uno de varios posibles
pasos siguientes:
1. el enfoque elegido para esta iteración es satisfactorio y da una idea de la

realización del siguiente ciclo de análisis, diseño, implementación y
evaluación;
2. el resultado del análisis, diseño e implementación de esta iteración no es
satisfactorio, y un enfoque alternativo debe intentarse;
3. suficiente conocimiento se ha ganado en esta iteración (y iteraciones
anteriores) para especificar los requisitos restantes, completar el diseño,
particionarla y terminar el proyecto utilizando un enfoque gradual y
construcción; o
4. el proyecto debe ser cancelada, tal vez porque el estado del conocimiento o
la tecnología no puede apoyar el concepto de sistema.
La figura 2.14 ilustra el proceso de desarrollo evolutivo como se ve por usted,

el director del proyecto. Cada ciclo iterativo implica:
• el análisis de la situación actual y decidir cuál de los 4 posibles pasos a

seguir para perseguir,
• la planificación para el curso de acción elegido,
• el desarrollo del software, siempre y alternativa 4 no se elija, y
• la evaluación de los resultados.
www.it-ebooks.info
ciclo 1 ciclo 2 ciclo 3 ... ciclo n
Los detalles de cada ciclo evolutivo:
Analizar => Plan => Desarrollar => Evaluar
FIGURA 2.14 Vista de gestión del proceso de desarrollo evolutivo
El paso de evaluación debe involucrar al cliente, que participa en la

determinación de cuál de los cuatro resultados que se ha logrado. La evaluación
puede dar lugar a revisiones al concepto de sistema y los requisitos
operacionales.
Un objetivo fundamental de todos los modelos de desarrollo iterativo es
proporcionar demostraciones frecuentes de progreso (o falta de ella) y la alerta
temprana de problemas. En consonancia con ello, la duración de un ciclo
evolutivo nunca debe exceder de un mes. Un mes para una iteración evolutiva
puede ser necesaria cuando la evolución de un sistema grande y complejo; en
muchos casos los ciclos de una semana de duración son las adecuadas. En
cualquier caso, usted no quiere que esperar 3 meses, 6 meses, o 12 meses para
descubrir que el diseño e implementación no satisfacen los requerimientos y
necesidades de los usuarios, o que los requisitos se manifestaron de forma
incorrecta, o que no es factible satisfacer los requisitos dentro del estado actual
de la tecnología. Cada uno de ellos viene OUT- puede suceder cuando se utiliza
un proceso de desarrollo en cascada o un ciclo evolutivo de duración prolongada.
El uso de un proceso de desarrollo evolutivo indica una tarea de alto riesgo;
OTRO TIPO, un proceso incremental y construcción, en base a los requisitos de
estabilidad y la arquitectura, se utilizaría. La planificación debe proceder de una
manera evolutiva debido a que algunos o todos los requisitos son inestables o
desconocido. La etapa de evaluación de cada ciclo lutionary evo- determina qué
hacer a continuación. Una limitación de tiempo se puede colocar a la empresa en
general, como en “vamos a adoptar un enfoque evolutivo por no más de 3 meses;
un importante re-evaluación se llevará a cabo si los requisitos y el diseño no son
estables para entonces “.
2.6.3 Modelos de desarrollo ágiles

modelos de desarrollo ágil también son evolutivos, en el que los requisitos
evolucionan durante la implementación, pero se diferencian del modelo evolutivo
en el que el modelo evolutivo es apropiado cuando el concepto de sistema no es
clara o la viabilidad del proyecto es que se trate. Ágil desarrollar es el más
adecuado para pequeños proyectos de aplicaciones que se llevan a cabo en
presencia de un cliente / usuario con conocimientos que tiene una clara
comprensión de las necesidades a satisfacer por el sistema que se está
construyendo. Hay varias variaciones sobre el tema ágil, pero la mayoría de los
modelos Agile-proceso destacan los siguientes aspectos [ágiles]:
1. que implica de forma continua un cliente / usuario representativa;

2. el desarrollo de casos de prueba y escenarios de prueba antes de
implementar la próxima versión del producto;
3. implementar y probar la versión resultante;
4. demostrando cada versión del producto en evolución para el cliente;
www.it-ebooks.info
oír especificar
com caso de requisito (s)
ienz cliente
o
aquí
ofrece frecuente
escribir
r aquí iteracion
escenario (s)
cliente es prueba
demostrar
capacidade
s añadir nuevas
funciones;
revisión, prueba
y retrabajo
FIGURA 2.15 Un proceso de desarrollo ágil
5. provocar la siguiente requisito (s) desde el cliente; y

6. entrega periódica en el entorno operativo.
papeles del cliente son para proporcionar la “línea de la historia” que

determina las exigencias, para revisar capacidades demostradas, y para
especificar el siguiente capítulo de la línea de la historia para la siguiente
iteración. Un modelo de proceso iterativo para el desarrollo ágil se representa en
la Figura 2.15. “La historia de las tarjetas” se utilizan a veces para grabar
elementos de capítulos de la historia. Ellos pueden ser ordenados por el cliente
para reflejar las prioridades; estimaciones de esfuerzo se pueden escribir en ellos,
y el esfuerzo real se pueden grabar y en comparación con las estimaciones.
Como se indica en la figura 2.15, no hay etapa de diseño explícito y no diseño
docu- mentación en un proceso de desarrollo ágil. Esto se compensa con un
diseño “metáfora” que se comparte entre los desarrolladores. Una metáfora de
diseño podría estar basado en un estilo arquitectónico; por ejemplo, el sistema se
puede basar en un estilo en capas (por ejemplo, una arquitectura de 3 capas) o
una arquitectura de separación de preocupaciones (por ejemplo, una arquitectura
de control de vista modelo-). La falta de diseño explícita requiere que los
desarrolladores sean altamente calificado; de lo contrario, “ágil” se convierte en
un eufemismo para la piratería. Otros procesos de desarrollo en algún momento
se caracterizan como “Plan impulsado,” en contraste con la falta intencional de
énfasis en los requisitos de las especificaciones escritas, diseño docu- mentación,
y los planes de V & V en los modelos ágiles.
En muchas versiones del proceso ágil, los desarrolladores de software
producen una próxima versión de un sistema en funcionamiento en periodos de
tiempo no superior a un día de trabajo. Algunos modelos ágiles utilizan par de
programación, en la que comparten pares de desarrolladores de terminales
putadora una com- y desarrollar el software juntos. La experiencia con los
modelos ágiles indi- Cates que los productos resultantes se clasifican bajo en los
niveles de defectos y alta en la satisfacción del usuario. Sin embargo, la
satisfacción del usuario es críticamente dependiente de que tiene una edgeable
knowl- y usuario prototípico como el cliente en el bucle de desarrollo iterativo.
Algunos críticos han planteado la preocupación de que un proceso ágil puede dar
lugar a un producto estructurado aliado FunciÃ³n- que carece de documentación
de diseño, con lo que el sistema difícil de modificar en el futuro.
www.it-ebooks.info
El desarrollo ágil parece ser el más adecuado para pequeños proyectos que se
desarrollan aplicaciones software.14 En proyectos pequeños que no hay
asignación de requisitos a subsys- TEMS y de partición de un diseño a priori, lo
cual es necesario si los miembros de grandes equipos de proyecto han de trabajar
al mismo tiempo. Los procesos ágiles son apropiadas para proyectos de aplica-
ciones, porque el usuario-historias proporcionados por las metáforas del cliente y
diseño utilizados por los desarrolladores, son los más adecuados para poner fin a-
elemento de software que será utilizado por la gente en la búsqueda de sus
actividades de trabajo o pasatiempos recreativos, en lugar de sistemas de misión
crítica y compleja incrustado.
En común con todos los modelos iterativos, la planificación de un proyecto
ágil implica trabajar con el cliente para desarrollar la visión del producto,
planificar la frecuencia de iteraciones, y planificar la frecuencia de la entrega de
la evolución de las capacidades de los usuarios. A diferencia de otros modelos de
desarrollo iterativo, una metáfora de diseño debe ser establecido por los
desarrolladores, y la versión particular de un proceso ágil para ser utilizado debe
ser revisado y aceptado por los interesados en el proyecto. Durante la ejecución
del proyecto, es especialmente importante revisar con los clientes,
desarrolladores y otras partes interesadas, sobre una base semanal, factores tales
como el estado actual del producto en evolución, publicaciones programadas, la
visión del producto y la metáfora de diseño, factores de calidad y planes para los
próximos dos o tres meses (o hasta el final esperado del proyecto si es menos de
dos o tres meses).
En resumen, los procesos de desarrollo ágiles son adecuados para los
proyectos que se desarrollan aplicaciones de software, requieren menos de 10
desarrolladores, tener un sitio en sitio del cliente bien informado (representante
de los usuarios), tienen los desarrolladores altamente cualificados que comparten
una metáfora de diseño común, tener continuidad del personal de desarrollo; y
para un producto que va a someterse a las liberaciones frecuentes y entregas
periódicas en el entorno operativo.
El texto de equilibrio de la agilidad y la disciplina por Boehm y Turner
contrasta Plan-conducido y ágil se acerca al desarrollo de software y presenta un
groundapproachtoachievingabalancethanincorporatesaspectsofbothapproaches
medianos, en base a la situación particular [BOEHM04].
2.6.4 El modelo Scrum

El modelo Scrum es un marco para proyectos de software de planificación y
realización en base a los principios de desarrollo ágil (el término “scrum” es del
juego del rugby) [Schwab04]. El director del proyecto / líder se denomina
“ScrumMaster.” El cliente (representante de los usuarios) se denomina el “dueño
del producto” y los desarrolladores de software son el “Equipo”. Los equipos
incluyen hasta 10 desarrolladores de software. El propietario del producto,
escribe historias de los usuarios, les da prioridad, y los coloca en la “Pila de
Producto.”
iteraciones de desarrollo se denominan “sprints”, que son típicamente de 30
días duraciones ción. Estos dan lugar a un conjunto de características que pueden
ser entregados a los usuarios, si se desea. Las características que se ejecutarán en
un sprint se determinan durante una reunión de planificación de Sprint; las
características que deben incluirse son derivados de la reserva de pedidos de
productos y se coloca en una “Pila del Sprint.” Breve (a 15 minutos) stand-up
reuniones se llevan a cabo cada día durante una carrera de velocidad para revisar
el trabajo a cabo el día anterior y para planificar el trabajo
www.it-ebooks.info
14
Un pequeño proyecto es considerado como uno que implica 10 o menos los desarrolladores de
software.
www.it-ebooks.info
24 h
30 dias
Valor mínimo de trabajo

Producto BacklogSprint BacklogSprint
del software
FIGURA 2.16 El proceso de desarrollo de Sprint [wiki]
para el presente día. Las reuniones diarias permiten que el ScrumMaster para
determinar la tasa de terminación de la tarea y para anticipar y enfrentar los
problemas potenciales antes de que se conviertan en problemas reales (es decir,
para gestionar los factores de riesgo).
Cada sprint es seguido por una reunión (un “sprint de retrospectiva”) durante
el cual revisa el equipo el sprint y determina cómo pueden mejorar sus procesos
de trabajo en las futuras carreras. El proceso Sprint se ilustra en la Figura 2.16
[Wiki].
2.6.5 El Meta-Modelo Espiral

Originalmente el modelo espiral se presenta como un modelo de desarrollo
[Boehm88]. En los últimos tiempos se ha llegado a ser considerado como un
modelo de meta (es decir, un marco de proceso de desarrollo) de la que varios
modelos iterativos se pueden derivar. Como se ilustra en la figura 2.17, cada
ciclo de un proceso en espiral implica:
1. el análisis de los objetivos, la identificación de enfoques alternativos, y el

establecimiento de con- straints para el siguiente ciclo de proceso;
2. la planificación del próximo ciclo mediante la evaluación de los enfoques
alternativos, la identificación de los factores de riesgo de cada enfoque, y la
selección de un enfoque;
3. la implementación de la alternativa seleccionada; y
4. evaluar los resultados y decidir qué hacer a continuación.
Lo-a-do-a continuación depende de la creación de instancias particular del

modelo de meta-espiral. En un modelo evolutivo en espiral el siguiente ciclo
puede implicar intentar un enfoque diferentes; en un modelo de Incremental-
acumulación de espiral el próximo ciclo consiste en la construcción y la
integración de la siguiente serie de características. Las figuras 2.18 y 2.19 ilustran
evolutiva y Incremental-construir instanciaciones de la espiral meta-modelo. La
duración de un ciclo de espiral puede variar de un día para una espiral ágil a un
mes por una espiral evolutiva.
Aunque la evaluación sistemática de los riesgos es un tema importante de
desarrollo en espiral, no se debe inferir que siempre se debe elegir el enfoque de
riesgo más bajo. esfuerzos de alto riesgo, si tiene éxito, a menudo resultan en
grandes beneficios. Es posible que decida escindir una investigación paralela de
www.it-ebooks.info
un enfoque de alto riesgo, mientras que la implementación de un menor
www.it-ebooks.info
1
ANALIZAR 2
determinar los PLAN
objetivos,
hora evaluar las alternativas;
enfoques identificar y resolver los
alternativos, y factores de riesgo; seleccione
x xxxx
las limitaciones xx una alternativa
x x
x
x x x
Empieza x x x x
x x xx
aqui x
x x x
terminar xxx x
aquí x x x x x x x
xx x x
4 x x xxx x 3
EVALUAR IMPLEMENTAR
evalúa el x x x implementar el
seleccionado
resultado y x x x x x alternativa
decidir qué x
hacer siguiente x
xx x
x x
x x
FIGURA 2.17 El meta-modelo de

espiral
1 2
ANALIZAR PLAN
evaluar los resultados de la hora
evaluar los riesgos
iteración anterior y de la cada
desarrollar enfoques
alternativos para la próxima x xxxx x alternativa y
x xx seleccione una
iteración x
x xx x x
x x
x x xx
x
x x x
xxx x
x x x x x x x
xx x x
4 x x xxx x 3
EVALUAR IMPLEMENTAR
evaluar resultado x x x implementar el
seleccionado
con los clientes y x x x x x alternativa
otras partes x
x
interesadas xx
xx x
x x
FIGURA 2.18 Una representación espiral del proceso de desarrollo evolutivo
alternativa riesgo. La etapa de evaluación sería entonces sopesar tanto los

resultados, y proporcionar información para el siguiente ciclo.
En resumen, los conceptos de la espiral metamodelo se pueden integrar en
todos los modelos de procesos iterativos; el meta-modelo espiral añade las
dimensiones de manera sistemática la generación de enfoques alternativos para la
siguiente iteración, la evaluación del riesgo de
www.it-ebooks.info
1 2
ANALIZAR PLAN
revisar la versión actual; hora revisar el diseño según sea
y revisar las necesario;
características para xxxx evaluar algoritmos
añadir en este próximo
x alternativos, estructuras de
xx
incremento x x x datos y los detalles de la
x x x interfaz; evaluar los riesgos
x x x x y seleccione
x algoritmos, estructuras de
x x x datos, y detalles de la
interfaz
x xxx x x
x x
x x x x x x 3
x
IMPLEMENT
AR
x x x
x x yoinstrumentar el código
4 x x xxx e integrarlo en el
EVALUAR x x presente versión;
evaluar la acumulación con x x revisar y probar la
x x acumulación;
clientes, usuarios y otro x x
x personas independientes
las partes interesadas x
xx determinan acceptability de
x la construcción;
x x
x x
reelaborar como sea
necesario
FIGURA 2.19 Una representación espiral del proceso incremental y

construcción
cada uno, la selección de una alternativa para la implementación y la evaluación

de los resultados. Alternativamente, el meta-proceso en espiral proporciona un
marco para la generación de modelos de desarrollo iterativo.
TABLA 2.5 mecanismos principales para la planificación y control de proyectos iterativos

Desarrollo ModelPlanning y Mecanismos de control Incremental
buildFrequency y el contenido de generaciones, frecuentes construir-verify-
iteraciones validar-demostración, el control de versiones
EvolutionaryWhat-a-do-siguiente decisiones basadas en la evaluación de los resultados;
ciclos de duración limitada, el control de versiones
AgileUser historias, metáforas diseño, la periodicidad de iteraciones, la
frecuencia de las entregas, control de versiones
Evaluación SpiralSystematic de enfoques alternativos y la resolución de los
factores de riesgo en cada ciclo, el control de versiones
La Tabla 2.5 resume los principales mecanismos de planificación y control para

los diferentes modelos de desarrollo iterativo.
2.6.6 Directrices para proyectos de desarrollo iterativo-planificación y control

Las siguientes pautas son útiles en la planificación y la realización de un proyecto
de desarrollo iterativo:
• El plan de proyecto inicial debe especificar el tipo de modelo iterativo para

ser utilizado; debe ser adaptada para satisfacer las necesidades del proyecto.
• La duración de cada iteración se debe especificar en el plan inicial del
proyecto.
www.it-ebooks.info
• Las principales actividades de trabajo y los principales hitos del proyecto

deben ser identificados e incluidos en el plan inicial del proyecto.
• Como el producto evoluciona, los planes son revisados y elaborados dentro
de las limitaciones generales del proyecto.
• actividades de trabajo múltiples y múltiples tipos de actividades de trabajo,
se llevan a cabo simultáneamente.
• control de versión automatizada es esencial para el establecimiento y
mantenimiento de las líneas de base de diversos productos de trabajo en
diferentes etapas de desarrollo.
• Iterativo, verificación y validación independiente son necesarias.
• La alerta temprana de problemas debe ser abordado en cuanto se detecta.
• Las razones para la reanudación excesivo de la creciente línea de base del
producto deben ser identificadas con los y las correcciones hechas tan pronto
como sea posible.
• frecuentes manifestaciones de progreso deben llevarse a cabo para los
desarrolladores, usuarios, clientes, adquirente, y otras partes interesadas
pertinentes.
2.7 Diseñar un proceso-desarrollo iterativo
diseñadores de software utilizan estilos arquitectónicos, patrones de diseño y

modismos para guiar las opciones de diseño que hacen. De la misma manera que,
como diseñador del proceso de desarrollo de su proyecto, puede utilizar el marco
de desarrollo en la figura 2.1b o Figura 2.5, o uno de los modelos de procesos de
desarrollo descritos anteriormente como punto de arranque ing. Los procesos que
se utilizan para desarrollar un producto de software deben ser diseñados con el
mismo cuidado que se utiliza para diseñar el producto. El diseño del proceso, al
igual que el diseño de software, se ve facilitada por la disponibilidad de guías y
plantillas de documentos para la adaptación de los marcos de procesos. Su
organización puede tener consultores internos que pueden ayudar a diseñar el
modelo de su proceso de desarrollo.
En general, el diseño, ya sea de diseño de software, hardware de ordenador,
móviles automatiza, nave espacial, o edificios, siempre se preocupa con la toma
de decisiones entre alternativas para optimizar ciertos criterios de diseño dentro
de los límites de las straints con- diseño. Un producto de software podría estar
diseñado para optimizar el rendimiento, la seguridad, la seguridad, o la facilidad
de futuras modificaciones. Debido a que algunos criterios pueden estar en
conflicto (por ejemplo, maximiza el rendimiento y minimizar el uso de
memoria), a menudo es necesario priorizar criterios de diseño.
En el caso de un proyecto de software, su objetivo podría ser reducir al
mínimo horario, manteniendo la calidad; esto podría requerir un aumento de
personal y la omisión de algunas de las características deseadas del producto.
Alternativamente, el objetivo podría ser maximizar características y calidad, lo
que aumentaría el horario y / o el nivel de personal. Uno de los objetivos del
programa de mini-zando los recursos y al mismo tiempo maximizar las
características y atributos de calidad es excesivamente restringida y
probablemente inalcanzable.
Un ejemplo de un proceso diseñado para un proyecto específico se ilustra en la
figura
2.20. Los atributos del proyecto incluyen:
www.it-ebooks.info
• Criterios para ser optimizados eran manifestaciones frecuentes de progreso y
entrega más temprana posible de una capacidad subconjunto especificado.
• La restricción producto más grave fue el requisito de que el sistema inter
comunicarse con un sistema para el que no existía documentación de la
interfaz.
www.it-ebooks.info
2.7 Diseñar un proceso-desarrollo iterativo 73
3* 2 1 prototipado
4 4 2 1 Análisis y Diseño
3 3 Versión 1
r Entrega
2 2 ede la
Versión 2
Capability
3 4 aubset
La
versión 3r
2 3 3 Ind
iao lidation
nali
ependent
Vin
a
rgi
M0 M1 M2 M3 M4M5M6 M7 principales
nid
hitos
ae
0123456789 l
meses
S
*número de personas asignadas: u
7 miembros del personal, además de líder r
del equipo
FIGURA 2.20 Un proceso de desarrollo adaptados
• La restricción producto fue acompañado por una restricción proceso que los
Ircops desa- no fueron capaces de comunicarse con cualquier persona que
entiende el otro sistema.
• La restricción de programación requiere una fecha de entrega fija 12 meses
después del inicio del proyecto.
• Una restricción adicional del proceso era una limitación en el equipo de
desarrollo de siete desarrolladores además de un administrador líder de
equipo / proyecto.
Como se representa en la figura 2.20, el proceso de desarrollo que fue

diseñado involucrado:
• creación de prototipos (para entender la interfaz con el otro sistema y para

crear prototipos de la interfaz de usuario para el sistema en desarrollo),
• análisis y diseño (para especificar los requisitos y los principales
componentes del sistema),
• desarrollo incremental (por frecuentes manifestaciones de progreso, la alerta
temprana de problemas, y la entrega de la capacidad subconjunto), y
• verificación y validación independiente (por los desarrolladores que no sean
aquellos que implementan cada versión).
El diseño se dividió en tres versiones principales con incremental semanal

construye dentro de cada versión. El desarrollo de las tres versiones se
superponen en el tiempo. Version 2 subsumido y la versión 1 incorporado;
Versión 3 y subsumido incorpora nominal versión 2. La versión 2 proporciona las
capacidades de subconjuntos primeros entregados a los usuarios. Los números de
la figura indican el número de personal asignado a cada tarea en cada punto en el
tiempo.
El proyecto tenía siete hitos principales (ocho incluyendo el hito a partir M0).
Los principales hitos fueron momentos en que estaban las fases de desarrollo
www.it-ebooks.info
completado, se evaluó el progreso, se iniciaron nuevas fases, y se asignó personal

para diferentes tareas. La semana acumulación de verificar a validar-demostrar
ciclos previstos hitos de menor importancia para el proyecto, por el cual se
proporcionaron continuas manifestaciones de progreso y alerta temprana de
problemas sobre una base semanal.
Como se ilustra en la figura 2.20, el proyecto comenzó con tres
desarrolladores asignadas a creación de prototipos y 4 asignado a análisis.
Durante los primeros cuatro meses del proyecto, el papel del esfuerzo de
prototipos era proporcionar respuestas a las preguntas formuladas durante el
análisis y diseño. Milestone M1 baselining involucrados de los requisitos para la
capacidad subconjunto para ser entregado como la versión 2. El intervalo entre
M1 y M2 involucrado continuo de prototipos, el análisis y el comienzo de diseño.
En M2, se determinó que los requisitos y de diseño eran suficientemente estable
para apoyar la implementación de la versión 1. Uno de los miembros del equipo
de creación de prototipos y dos miembros de la análisis y equipo de diseño se
convirtió en el equipo de la versión 1. En M3 se determinó que la versión 2 se
pudo iniciar el uso de las capacidades emergentes de la versión 1 como base para
el desarrollo de la versión 2. Uno de los miembros del equipo de creación de
prototipos y un miembro del equipo de análisis y diseño se convirtió en el equipo
de la versión 2. Versión 1 se completó a M4. Los miembros de prototipos y de
análisis y diseño restantes se convirtieron en el equipo de verificación y
validación independiente (V & V) para la versión 1 más las capacidades
emergentes de la versión 2. Los tres desarrolladores de la versión 1 se convirtió
en el equipo de desarrollo para la versión 3.
Tal como estaba previsto, las capacidades subconjunto de la versión 2 se
entregaron a los usuarios en mile- piedra 5. El semanal construye e incremental V
& V de la semana construye hicieron posible completar la versión 2, realice la
final opiniones de validación, pruebas, y demos- demos-, y entregar la versión 2
en la misma semana. Uno de los miembros del equipo de la versión 2 se asigna
entonces a la versión 3, y el otro miembro fue asignado a V & V. Este proceso de
desarrollo permitió la finalización del proyecto y la entrega del producto en 9
meses, 3 meses antes de la fecha de entrega comprometida de 12 meses.
Los detalles del proceso de desarrollo incremental ilustrado en la figura 2.20
se elaboraron como el proyecto evolucionó. El plan inicial incorpora prototipos,
análisis y diseño, desarrollo incremental de tres versiones, validación
independiente de cada versión, y la entrega de la capacidad subconjunto
temprano. Los principales hitos incluidos en la figura 2.20 se incluyeron en el
plan inicial; el calendario de los hitos y el contenido de la semana construye se
ajustaron como el proyecto evolucionó. Como se ha señalado, el sistema se
completó en 9 meses; 3 meses antes de la fecha de entrega requerida.
Consideraciones para la selección de un modelo de proceso de desarrollo
iterativo basado en las características de los requisitos, el equipo del proyecto, la
comunidad de usuarios, y tipo de proyecto y factores de riesgo se presentan en el
Apéndice 2B de este capítulo.
2.8 LA FUNCIÓN DE PROTOTIPADO en desarrollo de software
En el software de ingeniería de un prototipo es una maqueta de la funcionalidad

deseada de alguna parte del sistema. Esto está en contraste con los sistemas
físicos, cuando el modelo es generalmente una primera versión de la
funcionalidad completa de un sistema. prototipos de software se con- structed
para investigar una situación o para evaluar un enfoque propuesto para la
www.it-ebooks.info
solución de un problema técnico. Un prototipo de una interfaz de usuario, por
ejemplo, podría ser con-
www.it-ebooks.info
2.9 Puntos clave de CAPÍTULO 2 75
structed para promover el diálogo con los usuarios y comprender así mejor sus
necesidades y preocupaciones. Un prototipo de aplicación de un algoritmo puede
llevarse a cabo para estudiar los aspectos de rendimiento o seguridad del
algoritmo.
Los prototipos no se construyen con la misma atención a la estructura
arquitectónica, las interfaces, la documentación y los problemas de calidad que se
dedica a componentes de productos. Los prototipos pueden ser construidos
utilizando diferentes herramientas que se utilizan para construir los sistemas de
pro- ducción. Por ejemplo, un prototipo de una interfaz de usuario podría
desarrollarse rápidamente en Visual Basic, pero la versión de producción de la
interfaz podría ser implementado en C para proporcionar el rendimiento
requerido y compatibilidad con otros componentes del sistema.
Muchos problemas se han creado mediante la incorporación de un prototipo de
software en los sistemas de producción. Prototipos es una técnica útil que se debe
emplear cuando sea apropiado; Sin embargo, la creación de prototipos no es un
modelo de proceso para el desarrollo de software. Algunas organizaciones
utilizan el término “prototipos”, junto con otros términos tales como
“estructurado” o “rápida” para describir su modelo de desarrollo de software. En
muchos casos esto es un eufemismo para la piratería caótica.
Creación de prototipos es una técnica que se puede utilizar en conjunción con
todos los modelos de procesos de desarrollo de software. Prototipado debe ser
planificada, vigilados y controlado; no debe ser utilizado como una excusa para
la piratería incontrolada. Directrices para la creación de prototipos incluyen el
establecimiento de objetivos específicos y limitados para cada una de las
iteraciones de prototipos, lo que limita la duración de iteraciones a 1 semana o
menos, y el uso de los resultados evaluados como base para el siguiente paso.
Aunque esto suena como el enfoque evolutivo, la distinción es que las iteraciones
de Desa- evolutiva ción siguen un proceso sistemático dentro de un contexto más
amplio; creación de prototipos es una técnica para estudiar un problema
específico dentro de un contexto limitado.
Cuando la construcción de un prototipo, mantenemos el conocimiento que
hemos ganado, pero no utilizar el código en la versión del sistema de entrega
si no estamos dispuestos a hacer el trabajo adicional para desarrollar el código de

producción calidad del código de prototipo.
En muchos casos es más eficiente y más eficaz para construir el código de

producción “desde cero” utilizando los conocimientos adquiridos por los
prototipos de rediseñar el código prototipo.
Cuando se utiliza un enfoque evolutivo, mantenemos el conocimiento que
hemos adquirido en cada ciclo de la iteración, y podemos, o no, utilizar el código
que hemos escrito en la versión entregable del sistema, dependiendo de la
evaluación de los resultados. Cuando se utiliza el modelo de Incremental-
construcción, el objetivo es mantener el código que escribimos en cada
construcción como el siguiente elemento del sistema de entrega.
2.9 puntos clave de CAPÍTULO 2
• El proceso de desarrollo de cada proyecto de software debe ser diseñado con

el mismo cuidado utilizado para diseñar el producto.
• Un marco de desarrollo-proceso es un modelo de proceso genérico que
www.it-ebooks.info
puede ser Lored Tai y adaptado para ajustarse a las necesidades de los
diversos proyectos.
www.it-ebooks.info
• El diseño del proceso se logra mejor mediante la adaptación y la adaptación

de los modelos de procesos de desarrollo conocidos y marcos de procesos,
así como el diseño del producto se logra mejor mediante la adaptación y la
adaptación de estilos arquitectónicos conocidos y marcos arquitectónicos.
• Hay varios muy conocido y ampliamente utilizado modelos de procesos de
desarrollo de software, incluida la cascada, incremental y construcción,
evolutiva, ágil, y el desarrollo en espiral.
• Hay varias maneras de obtener los componentes de software necesarios;
diferentes formas de obtención de componentes de software requieren
diferentes mecanismos de planificación, medición y control.
• Las fases de desarrollo de un proyecto de software pueden ser intercalados y
repetir en varias formas.
• procesos de desarrollo iterativo proporcionan las ventajas de ción continua
integración, verificación iterativo y validación del producto en evolución,
manifestaciones frecuentes de progreso, la detección precoz de defectos, la
alerta temprana de problemas en el proceso, la incorporación sistemática de
la inevitable retrabajo que se produce en el desarrollo de software, y entrega
temprana de las capacidades de subconjuntos (si se desea).
• Dependiendo del proceso de desarrollo iterativo utilizado, la duración de
iteraciones van desde un día hasta un mes.
• Creación de prototipos es una técnica para la adquisición de conocimientos;
no es un proceso de desarrollo.
• Los mecanismos de planificación, medición y control utilizados en un
proyecto de software están fuertemente influenciadas por el proceso de
desarrollo utilizado.
• SEI, ISO, IEEE, y PMI, proporcionan marcos, normas y directrices perti-
Vant a modelos de procesos de desarrollo de software (ver Apéndice 2A a
este capítulo).
Referencias
[Bass03] Bajo, L., P. Clements, y R. Kazman. Arquitectura de software en la práctica, 2ª ed.

Addison-Wesley, 2003.
[Boehm04] Boehm, B., y R. Turner. Equilibrar la agilidad y la disciplina. Addison Wesley,
2004.
[Boehm81] Boehm, B. Economía Software Engineering. Prentice Hall, 1981, p. 40.
[Boehm88] Boehm, modelo B. Una espiral de desarrollo de software y mejora. com-
putadora, Mayo de 1988, IEEE.
[CMMI06] SEI. CMMI ® Modelos y Módulos, http://www.sei.cmu.edu/cmmi/models/, 2006.
[IEEE1058] IEEE Std 1058 ™ -1998 Norma IEEE para los planes de gestión de proyectos
de software. Normas Colección de ingeniería. IEEE producto: SE113.
Instituto de Ingenieros Eléctricos y Electrónicos, agosto de 2003.
[IEEE12207] IEEE / EIA 12207.0 / 0.1 / 0.2. Industria Implementación de la Norma
Internacional ISO / IEC 12207: 1995 estándar para la Tecnología de la
Información-Software Procesos del ciclo de vida. Normas Colección de
ingeniería. IEEE producto: SE113. Instituto de Ingenieros Eléctricos y
Electrónicos, agosto de 2003.
www.it-ebooks.info
CEREMONIAS 77
[PMI04] PMI. Una guía para la Dirección de Proyectos del Conocimiento, 3ª ed.
[Royce70] Royce, W. La gestión del desarrollo de grandes sistemas de software: conceptos y
técnicas. IEEE Wescon, 1970; reimpreso en las Actas de la 9ª Conferencia
Internacional sobre Ingeniería de Software, Monterey, CA. ACM Press, 1987.
[Schwab04] Schwaber, Ken. Gestión de proyectos ágil con Scrum. Microsoft Press,
2004.
URL
[Ágil] www.agilealliance.com/intro
[Wiki] en.wikipedia.org/wiki/Scrum_ (desarrollo)
CEREMONIAS
2.1. Brevemente comparar y contrastar las disciplinas de ingeniería de sistemas

e ingeniería de software. ¿Cómo son similares? ¿En qué se diferencian?
2.2. CMMI-DEV-v1.2 enumera cinco áreas de procesos relacionados sobre el
área de proceso Solución Técnica: Desarrollo de requisitos, verificación,
análisis de decisiones, gestión de requisitos, e innovación organizativa y de
implementación.
Acceder al sitio Web en CMMI
http://www.sei.cmu.edu/publications/documentos / 06.reports / 06tr008.html.
Revisar el área de proceso Solución Técnica, y explicar brevemente cómo cada
una de las cinco áreas de procesos relacionados con ellos se relacionan con la
solución técnica.
2.3. Explicar brevemente las diferentes funciones desempeñadas por los
usuarios, clientes y compradores en los proyectos de desarrollo de software.
2.4. Identificar cinco tipos diferentes de partes interesadas en un proyecto para
desarrollar un Auto- acoplado Sistema Teller, tal como el que se ilustra en
la Figura 2.4. Explicar brevemente las funciones desempeñadas por cada
tipo de actor.
2.5. Explicar brevemente las funciones desempeñadas en un proyecto de
sistemas intensivos en software para efectuar las operaciones y los
requisitos de software. ¿Cómo son similares? ¿En qué se diferencian?
2.6. requisitos derivados se incluyen en los requisitos de software para añadir
detalles a un requisito operativo asignado al software, para la elaboración
de un requisito de nivel de sistema, o para proporcionar características que
no son visibles para los usuarios finales, sino que debe estar presente para
apoyar características que son visibles para terminar usuarios.
Proporcionar dos ejemplos de requisitos derivados de un Sistema de
cajero automático. Para cada ejemplo, primer estado el requisito de nivel de
sistema o requisito funcional del que se deriva la exigencia derivada.
2.7. Proporcionar un ejemplo de cada uno de los siguientes:
a. Una relación estructural entre dos componentes de software.
b. Una relación funcional entre dos componentes de software.
c. Una relación de comportamiento entre los dos componentes de software.
d. Una relación de datos entre dos componentes de software.
www.it-ebooks.info
2.8. Para el Sistema de caja automatizada ilustra en la Figura 2.4, dar un

ejemplo de algún tipo de software que pueden obtenerse a partir de cada
una de las seis fuentes de componentes de software enumerados en la Tabla
2.1.
2.9. Brevemente comparar y contrastar los mecanismos de planificación y
control utilizado en un proyecto de desarrollo de la cascada y los que se
utilizan en proyectos de desarrollo iterativo.
2.10. Brevemente explica las diferencias entre el proceso incremental-
construcción y el proceso de desarrollo evolutivo.
2.11. Hay varias versiones diferentes de desarrollo ágil. Investigar y describir
brevemente tres modelos de procesos ágiles diferentes. Explicar en qué se
parecen y en qué se diferencian. Sugerencia: Hacer una búsqueda en
Internet para encontrar sus tres modelos.
2.12. Brevemente comparar y contrastar el proceso evolutivo de desarrollo, el
proceso de desarrollo ágil, y la técnica de prototipado rápido. ¿Cómo son
similares? ¿En qué se diferencian?
2.13. Dibuje un diagrama de flujo de trabajo comparables a las figuras 2.18 y
2.19 para el modelo de desarrollo ágil ilustra en la Figura 2.15. Brevemente
describir los atributos de su figura.
www.it-ebooks.info
ANEXO 2A
Marcos, estándares y directrices para los

modelos de desarrollo software de
proceso
2A.1 LA CMMI-DEV-v1.2 SOLUCIÓN TÉCNICA área de proceso
El propósito de los modelos CMMI es proporcionar marcos que pueden ser

elaborados y adaptados para mejorar la eficiencia y eficacia de los proyectos y
organizaciones que llevan a cabo proyectos de software [CMMI06] software.
actividades de desarrollo de software están cubiertas por el proceso de Solución
técnica en CMMI-DEV-v1.2.
Como se indica en el informe15 CMMI-DEV-v1.2:
El propósito de la Solución Técnica (TS) es diseñar, desarrollar e implementar

soluciones a los requerimientos. Soluciones, diseños, e implementaciones abarcan
productos, componentes de productos, y procesos de ciclo de vida relacionadas con
el producto, ya sea individualmente o en combinación según sea apropiado.
Las metas específicas y prácticas específicas del área de proceso Solución Técnica
en CMMI-DEV-v1.2 son:
SG 1 Seleccione soluciones de componentes de productos

SP 1.1 desarrollar soluciones alternativas y criterios de
selección SP 1.2 Seleccionar soluciones de componentes de
productos
SG 2 Desarrollar el diseño
SP 2.1 Diseño del producto o componente de
producto SP 2.2 Establecer un paquete de datos
técnicos
SP 2.3 interfaces de diseño utilizando criterios
SP 2.4 Realizar marca, comprar, o la reutilización análisis
15
CMU / SEI-2006-TR-008, página 456.
79
www.it-ebooks.info
SG 3 Implementar el producto
diseño SP 3.1 Implementar el
diseño
SP 3.2 Elaboración de la documentación de soporte del
producto
Como indica el informe, los criterios utilizados para seleccionar, diseño, y aplicar
componentes pueden variar significativamente a través de productos,
dependiendo del tipo de producto, el entorno operativo, los requisitos de
rendimiento, los requisitos de soporte, y los horarios de costes o de entrega. La
tarea de seleccionar la solución final hace uso de las prácticas específicas en el
área de análisis de decisiones y proceso de resolución.
Las áreas de proceso y de asuntos relacionados pertinentes a la solución
técnica son:
• requisitos desarrollo
° Asignación de los requisitos del sistema
° Desarrollo del concepto operacional
° Interfaz de definición de requerimientos
• Verificación
° Revisiones hechas por colegas
° La verificación de que los componentes del producto y de producto,
cumplen los requisitos
• El análisis de decisiones y la resolución
° La evaluación formal
• Gestión de requerimientos
° Las prácticas específicas de gestión de requisitos se llevan a cabo de forma
interactiva con los del área de proceso Solución Técnica
• La innovación organizativa y el despliegue
° La mejora de la tecnología de la organización
PROCESOS DE DESARROLLO 2A.2 EN ISO / IEC e IEEE / EIA NORMAS

12207
El proceso de desarrollo especificado en la ISO / IEC e IEEE / EIA 12207 consta de

13 actividades [IEEE12207]:
1. implementación de procesos,
2. análisis de los requisitos del sistema,
3. diseño de la arquitectura del sistema,
4. análisis de los requisitos de software,
5. diseño de la arquitectura de software,
6. diseño detallado del software,
7. codificación y pruebas de software,
8. la integración de software,
9. las pruebas de calificación de software,
10. Integración de sistema,
11. Sistema de pruebas de calificación,
www.it-ebooks.info
12. Instalación de software, y

13. el apoyo de aceptación del software.
Sección 5.3 de 12207.0 establece que el proceso de desarrollo suele incluir

actividades de trabajo para el análisis de requerimientos, diseño, codificación,
integración, pruebas, y la instalación y la aceptación de los productos de
software. El proceso de desarrollo también puede contener actividades
relacionadas con el sistema si es apropiado y si se especifica en el acuerdo
contractual.
2A.3 PROCESO TÉCNICO planes en IEEE / EIA STANDARD 1058
IEEE estándar EIA / 1058 para los planes de gestión de proyectos de software
(SPMPs) establece que los planes de procesos técnicos estarán contenidas en la
cláusula 6 de un PAPS. Los productos que se especifican incluyen:
• el modelo de proceso de desarrollo,

• las técnicas métodos, herramientas y técnicas a utilizar,
• planes para el establecimiento y mantenimiento de la infraestructura del
proyecto; y
• el plan de aceptación del producto [IEEE1058].
el PMBOK® Guía (Una guía para la Dirección de Proyectos del Conocimiento)

presenta una visión general de los procesos de gestión de proyectos que son
generalmente aplicables a la gestión de todo tipo de proyecto [PMI04].
Como se indica en el Apéndice D de la Guía, Extensiones área de aplicación
proporcionan adiciones al material de núcleo que pueden incluir material nuevo o
modificado, ciones elabora- de los procesos existentes, de diferentes maneras
para los procesos para interactuar, elementos de adición o modificaciones de
definiciones de procesos comunes, o entradas especiales, herramientas y técnicas,
y / o salidas para los procesos existentes.
En este momento (2009) de que no aumente el área de aplicación en el PMI
Cuerpo de Conocimientos para la gestión de los distintos modelos de procesos de
desarrollo de la ingeniería de software.
www.it-ebooks.info
APÉNDICE 2B
Consideraciones para seleccionar un

modelo de desarrollo iterativodieciséis
Las siguientes tablas indican las consideraciones para elegir entre la acumulación
Incremental-, modelos de procesos de desarrollo evolutivo, ágiles y espirales
basados en carac- terísticas de los requisitos, el equipo del proyecto, la
comunidad de usuarios, el tipo de proyecto, y los factores de riesgo. Un “sí”
indica que el modelo sería una buena elección basada en la característica en
cuestión. Un “no” indica que el modelo no sería una buena opción para esa
característica. Por ejemplo, un modelo de Incremental-build sería apropiado si los
requisitos son fácilmente definidos o bien conocidos (sí); un modelo evolutivo
sería no ser apropiado en este caso (no) porque mentales y Ancho-build es más
apropiado. Un modelo ágil podría ser apropiado, dependiendo del deseo de
interacciones diarias con el cliente (sí).
dieciséis
Las tablas de este apéndice se basan en material de calidad en gestión de proyectos software de R.
Futrell,
D. Shafer y L. Shafer; Prentice Hall, 2002, pp. 147-152.
82
www.it-ebooks.info
Consideraciones para seleccionar un modelo de desarrollo iterativo 83
Consideraciones TABLA 2B.1 basadas en las características de los requisitos

RequirementsIncremental-buildEvolutionaryAgile
Si los requisitos son bien conocidos o YesNoYes
fácilmente definidos
Si los requisitos se pueden definir YesNoNo
temprano en el ciclo de desarrollo
Si los requisitos son susceptibles de NoYesYes
cambiar con frecuencia durante el
ciclo de desarrollo NoYesYes
Si se necesitan demostraciones para
desarrollar los requisitos NoYesNo
Si es necesaria una prueba de concepto
para determinar la viabilidad YesYesNo
Si los requisitos indican un sistema
grande y complejo Si si si
Si se desea la entrega temprana de
funcionalidad limitada
Consideraciones TABLA 2B.2 basados en las características del equipo del proyecto
Proyecto TeamIncremental-buildEvolutionaryAgile
Si la mayoría de los miembros del NoYesNo
equipo son nuevos en el dominio del
problema para el proyecto NoYesNo
Si la mayoría de los miembros del
equipo son nuevos en el dominio de NoYesNo
la tecnología para el proyecto
Si la mayoría de los miembros del
equipo no están familiarizados con YesYesNo
las herramientas que se utilizarán
en el proyecto
Si algunos miembros del equipo NoNoYes
probablemente serán reasignados
durante el ciclo de desarrollo del
proyecto YesNoYes
Si se pedirá a los miembros del equipo
para interactuar con un representante
de los clientes sobre una base diaria
Si el progreso del equipo estará
estrechamente seguido por los
gerentes y al cliente
www.it-ebooks.info
Consideraciones TABLA 2B.3 basadas en las características de la comunidad de usuarios

Usuario CommunityIncremental-buildEvolutionaryAgile
Si la disponibilidad de los YesYesNo
representantes de los usuarios estará
limitado durante el ciclo de desarrollo
Si son nuevos representantes de los NoYesNo
usuarios a los conceptos de definición
de requerimientos YesNoYes
Si los representantes de los usuarios son
expertos en el dominio del problema YesNoYes
Si los representantes de los usuarios
quieren estar involucrados en todas
las fases del ciclo de desarrollo YesNoYes
Si el cliente desea realizar un
seguimiento de cerca el progreso
Consideraciones 2B.4 tabla en función de las características del tipo de proyecto y factores de
riesgo
Tipo de proyecto y RiskIncremental-buildEvolutionaryAgile
Si el proyecto es un área nueva NoYesNo
para la organización
Si el proyecto incluye sistema de integrationYesNoNo
Si el proyecto incluye la mejora de YesNoYes
un sistema existente
Si se espera que los fondos a ser NoYesYes
inestable durante el ciclo de
desarrollo YesNoNo
Si una alta fiabilidad, la seguridad o la
seguridad del producto es esencial
Si el horario es constrainedYesNoYes
Si las interfaces externas a otros NoYesNo
sistemas son inestables
Si son componentes reutilizables availableYesNoNo
Si los recursos (personas, YesNoYes
herramientas, dinero) son escasos
www.it-ebooks.info
3
ESTABLECIMIENTO DE
BASES DEL PROYECTO
El problema es que empezamos en el medio. Tuvimos que volver atrás y empezar de

nuevo a un costo considerable, esfuerzo y dolor.
-desde un cliente de consultoría
3.1 INTRODUCCIÓN A FUNDAMENTOS DEL PROYECTO
Primeros pasos en un proyecto de software a veces se llama la fase de inicio del

proyecto. Un proyecto para desarrollar o modificar un sistema de software
intensivo se concibe, inició y llevó a cabo en la creencia de que los beneficios del
sistema o producto resultante compensarán el coste del proyecto. A veces, el
beneficio se calcula como una relación costo / beneficio que aporte el valor actual
del dinero, costos de oportunidad, y la tasa esperada de retorno sobre la
inversión, o como el punto de equilibrio para el número de ventas a un precio
establecido. En otros casos los beneficios son menos tangibles; que pueden
implicar consideraciones de seguridad, la seguridad o la comodidad para una
población específica o para la sociedad en general. Las consideraciones
financieras proporcionan la motivación para proyectos llevados a cabo por los
proveedores que desarrollan productos para la venta al público en general.
A veces los proyectos se inician como resultado de un proceso de licitación
por los posibles contratistas y la adjudicación de un contrato por parte de la
entidad adquirente; a veces se basan en un plan de negocios que es consistente
con la misión de la organización. En otras ocasiones, los beneficios pueden ser
especulativa o pueden estar basados en consideraciones políticas. En cualquier
caso, los beneficios percibidos, determinados por algunos criterios, deben superar
el costo estimado de un proyecto.

85
www.it-ebooks.info
86 ESTABLECIMIENTO DE BASES DEL PROYECTO
Tabla 3.1 Elementos de cimentación de proyectos de

software
Preocupado con
fundaciones de productos
Operacional requirementsExternal ver; vista del sistema de los usuarios
requisitos del sistema y la Hardware, software y elementos de la
arquitectura del sistema gente; interconexiones entre elementos;
interfaces para el medio ambiente
Software vista requirementsInternal; vista de los desarrolladores del software a
ser desarrollado o modificado
Diseño diseño constraintsPredetermined decisiones
fundamentos del proceso

Contractual agreementStatement de entendimiento entre un desarrollador y el
cliente
Flujo de Trabajo actividades de trabajo modelManagerial y productos de
trabajo
Desarrollo modelTechnical actividades de trabajo y productos de trabajo
Proyecto proyecto planThe hoja de ruta
El éxito de los proyectos de software, como edificios resistentes a los

terremotos, se construyen sobre bases sólidas y flexibles; establecer los
elementos de cimentación es, pues, una actividad importante durante el inicio del
proyecto. Elementos de cimentación para proyectos de software incluyen bases
tanto para el producto a ser entregado y el proceso por el cual será desarrollado o
modificado. El modelo de flujo de trabajo para proyectos de software,
representado en la Figura 1.1, tiene entradas de requisitos y restricciones de la al
cliente central y directivas y limitaciones de los gerentes. fundamentos del
proyecto se derivan de estas entradas.
Como se indica en la Tabla 3.1, hay cuatro tipos de bases de productos y
cuatro tipos de bases de proceso. fundaciones de productos incluyen las
necesidades operacionales, requisitos del sistema y la arquitectura, requisitos de
software y las restricciones de diseño. Una visión general de las fundaciones de
productos se presenta en el capítulo 2; se elaboran en este capítulo.
fundamentos del proceso incluyen un acuerdo contractual, un modelo de flujo
de trabajo para la gestión del proyecto, un modelo de proceso de desarrollo de
software, y un plan de proyecto. El acuerdo contractual se presenta en este
capítulo. El modelo de flujo de trabajo para proyectos de software se presenta en
el Capítulo 1. Selección y adaptación de los modelos de desarrollo de software se
presenta en el Capítulo 2. Planificación de proyectos y el formato y contenido de
los planes del proyecto se presenta en el Capítulo 4.
• la naturaleza de la ingeniería de requisitos,

• determinar el alcance de un proyecto, y
• el establecimiento de un acuerdo contractual.
www.it-ebooks.info
3.3 ADQUISICIÓN DE SOFTWARE 87
Apéndice 3A a este capítulo se muestran los elementos relevantes de CMMI-DEV-

v1.2, ISO / IEC 12207 Normas y / EIA IEEE, IEEE / EIA estándar de 1058, y el PMI
de cuerpo de conocimientos.
3.3 ADQUISICIÓN DE SOFTWARE
La contratación de software está dirigida por el campo de la adquisición de

software, que es distinta de la gestión de proyectos de software; adquisición se
ocupa de las cuestiones jurídicamente vinculantes que intervienen en la
contratación con un cliente externo (el adquirente). Una visión general de las
cuestiones contractuales se presenta en esta sección, pero estas cuestiones no se
consideran en detalle en este texto.
Un contrato suele especificar el alcance de un proyecto y cláusulas legales
como bilidades LIA- y sanciones por incumplimiento de contrato. Es probable
que incluyen una cláusula de Derechos en los datos o un acuerdo de propiedad
intelectual que especifica exactamente lo que el cliente está pagando y lo que va
a ser entregado a, y es propiedad de, el cliente. Esto puede variar de código
objeto, código fuente, de código además de la documentación de diseño, a la
documentación de diseño de código, escenarios de prueba y casos de prueba, o
para todo lo anterior más una copia de las herramientas de software utilizado para
desarrollar el software y controlar su con- figuración. Derechos de-datos es un
tema particularmente importante para el software de código abierto y software
con licencia de un proveedor.
Hay varios tipos de contratos; por ejemplo:
• Precio fijo,
• tiempo y materiales,
• costo más una cuota fija, o
• costo más gasto de incentivo.
Un contrato de precio fijo es un contrato mediante el cual el cliente pagará una

cantidad específica de dinero para un sistema o producto que contenga
características y atributos de calidad especificados. El dinero se puede pagar en
cantidad a tanto alzado a la entrega final de los productos de trabajo contratados
o puede ser pagado en incrementos sobre el logro satisfactorio de los hitos
especificados. Dado que los proyectos para desarrollar o modificar los sistemas
intensivos en software son altos esfuerzos de riesgo, un contrato de precio fijo
debe incluir una reserva de contingencia sustancial en el precio y el horario. El
contrato también debe contener una cláusula que permite la renegociación del
precio y horario cuando los requisitos son cambiadas por el cliente.
Un contrato de tiempo y materiales es un acuerdo para reembolsar al
proveedor a una tasa fija por el esfuerzo y recursos invertidos en la realización de
un proyecto. Diferentes categorías de habilidades pueden ser reembolsados a un
ritmo diferente, y puede haber un techo colocado en la cantidad total a ser
invertido. Estos contratos se utilizan a veces para los proyectos para mantener un
sistema sobre una base anual.
Un contrato de tarifa fija costo más reembolsa el costo de llevar a cabo el
proyecto, más una cuota para cubrir el costo de los gastos que sean necesarios en
áreas tales como la infraestructura del proveedor, la adquisición de equipos, o la
www.it-ebooks.info
formación. Además la cuota general incluye un margen de ganancia especificada
por el proveedor.
www.it-ebooks.info
Un costo más una cuota de incentivo adjudicaciones de contratos al proveedor

por exceder las exigencias y / o el desarrollo o la modificación de un sistema de
software intensivo a un menor costo y en menos tiempo que el especificado en el
contrato. Muchos contratistas que hacen negocios con las agencias
gubernamentales confían en honorarios de incentivo para proporcionar un
margen de ganancia.
Para más información sobre temas de adquisición, véase el modelo de proceso
CMMI-ACQ a la versión 1.2 que ha sido desarrollado y publicado por el Instituto
de Ingeniería de Software [ACQ07]. CMMI-ACQ a la versión 1.2 “se centra en
los procesos adquirente e integra los cuerpos de conocimiento que son esenciales
para adquisiciones exitosas.” Información adicional sobre el software y los
sistemas de adquisición se puede encontrar en otras referencias, como
[SACMM02] y [CMMIAM05].
3.4 REQUISITOS DE INGENIERÍA
Requisitos proporcionan la base para todo lo que sigue en un proyecto de software.

Por lo tanto, es importante que usted, el director del proyecto, entender la naturaleza
de la ingeniería de requisitos y estar involucrado en el proceso de ingeniería de
requerimientos. Productos fundaciones en CMMI-DEV-v1.2, por ejemplo, incluyen
el desarrollo de requisitos y gestión de requisitos [CMMI06].
Requisitos desarrollo abarca los siguientes tipos de actividades:
• sonsacamiento: la comprensión de las necesidades del usuario, las

expectativas del cliente, y las condiciones del adquirente y documentar en un
Concepto de Operaciones documento
• análisis: traducir las necesidades del usuario, las expectativas del cliente, y
condiciones del adquirente en requisitos técnicos de hardware, software y
elementos de la gente
• asignación: la asignación de requisitos en el hardware, el software y los
elementos del sistema de la gente
• especificación: documentar los requisitos técnicos de notaciones y formatos
estándar; grabada en un documento de Especificaciones Técnicas
• verificación: determinar que las especificaciones técnicas son correcta,
completa y consistente con respecto al concepto de las operaciones
• negociación: dar y tomar las discusiones entre las partes interesadas para
lograr senso vistas del SUS
• aceptación: compromiso con una línea de base requisitos, por todos los
involucrados stakehold- ERS, que da cuenta de las limitaciones de la
programación, presupuesto, recursos, tecnología y factores de riesgo
La gestión de requisitos se ocupa de la gestión de la línea de base los

requisitos en evolución durante el desarrollo del sistema. Un aspecto importante
de la gestión de requisitos es el análisis de impacto, que se ocupa de la
evaluación de la necesidad y hacer los cambios necesarios en los horarios,
presupuestos, los recursos, la tecnología y los factores de riesgo acordes con los
cambios en los requisitos baselined.
Si su proyecto implica especificar los requisitos de hardware y requisitos para
las operaciones manuales (es decir, las realizadas por personas), además de los
requisitos de software, como en un sistema de software intensivo complejo, usted
y su jefe de diseño (arquitectura de software) deben ser miembros de la equipo de
www.it-ebooks.info
ingeniería de sistemas. Si el
www.it-ebooks.info
3.4 Requisitos INGENIERÍA 89
proyecto es de sólo software, es posible que se encargará de desarrollar los

requisitos, o los requisitos puede ser desarrollado por un analista de sistemas (o
un equipo de análisis) y proporcione como el punto de partida para su proyecto.
En general, hay varios tipos de requisitos del producto, como se ilustra en la
Figura 3.1 y discutido en las secciones siguientes. Un diagrama de flujo de
proceso para la ingeniería de requisitos se representa en la figura 3.2; actividades
de trabajo se indican en cursiva y productos de trabajo en negrita.
3.4.1 Desarrollo de Requisitos

Como se ilustra en la Figura 3.2, el desarrollo de los requisitos consiste en la
obtención de requisitos, análisis de requisitos, y los requisitos de aceptación.
necesidades de los usuarios y las expectativas del cliente que incluyen las
características del producto y calidad deseada atribuye suministran las entradas
para la obtención de requisitos. Los requisitos operativos
Requerimient
os
operacionale
s
Operacional Los Diseño

Caracteri atributos restriccione
sticas de s
calidad
Técnico
Presupuesto
Primario Derivado Diseño Diseño

requisitos requisitos Metas restriccione
s
FIGURA 3.1 Una taxonomía de los requisitos del producto
Necesidades de los
usuarios y las
expectativas del cliente, trabajo actividad producto de
trabajo
la obtención de Concepto de
requisitos operaciones
Condiciones y
restricciones de
diseño del adquirente
Negociación Análisis de Técnico

restriccione
requerimientos Especificación
s del
s
proceso
requisitos
Verificación Los requisitos
de aceptación
requisitos de
Impacto Gestión de
referencia
requerimientos
Análisis
Solicitudes de cambio
www.it-ebooks.info
control
de la
línea de
FIGURA 3.2 Proceso de flujo de la ingeniería de requisitos
base
www.it-ebooks.info
que resultan de la obtención de requisitos están documentados en un concepto de

Opera- ciones que, junto con las condiciones de la adquirente y las restricciones
de diseño, proporcionan la entrada para el análisis de requerimientos.
Elicitación y análisis suelen requerir la negociación con los usuarios y clientes.
La actividad de análisis produce las especificaciones técnicas, las cuales, junto
con las restricciones del proceso, proporcionan la entrada a los requisitos de
aceptación. Como se ilustra en la Figura 3.1, las especificaciones técnicas
incluyen requisitos primarios, requisitos derivados, objetivos de diseño, y las
restricciones de diseño. Las distinciones entre las cuatro categorías de
especificaciones técnicas se describen en la Sección 3.4.3.
Requisitos de verificación determina el grado en que las las especificaciones
técnicas son correctos, completos y coherentes con respecto a las exigencias
operacionales y restricciones del proceso; es una actividad necesaria de los
requisitos de aceptación. Integridad de las especificaciones técnicas se determina
al demostrar que cubren todas las necesidades de funcionamiento; Las matrices
de trazabilidad que documentan los spondences ponde de los requisitos
operacionales a las especificaciones técnicas se utilizan a menudo para este
propósito.
Verificación de los productos de trabajo requiere que cada producto de trabajo no
sólo cubre los productos de trabajo completamente de la que se deriva, sino también
los cubre correcta y sistemáticamente. La determinación de la exactitud de las
necesidades operacionales requiere experiencia en el dominio de los usuarios; por
ejemplo, ¿es cierto que los débitos y créditos deben siempre el equilibrio en un
sistema de transacción financiera o hay algunas condiciones en las que pueden estar
en desacuerdo? La determinación de la corrección de la especificación técnica
incluiría responder a preguntas tales como: ¿Es la forma en que los débitos y créditos
que deben ser gestionados correctamente indicado en las especificaciones técnicas?
La consistencia (la tercera condición de verificación) requiere que no haya
inconsistencias externas en las relaciones entre los productos de trabajo y no hay
inconsistencias internas dentro de los productos de trabajo. Una incoherencia
externa sería detectado si, por ejemplo, los requisitos operativos declararon que el
servidor en un sistema de cajero automático debe estar disponible en todo
momento (24 7) y las especificaciones técnicas declaró el servidor ATS deberá
proporcionar una calificación disponibilidad de 0,9, permitiendo así que el
sistema no esté disponible 10% del tiempo. Una incoherencia interna en las
exigencias existiría si un parámetro de interfaz para la base de datos especifica un
parámetro en dólares mientras que el parámetro correspondiente en la operación
de retirar especifica el parámetro en euros. Las taxonomías de los problemas en
los requisitos se pueden utilizar como listas de comprobación para la verificación
de los requisitos. Una lista típica se presenta en la Tabla
3,2 [HAYES03].
Como se ilustra en la figura 3.2, la salida de los requisitos de aceptación es una
línea de base requisitos, que proporciona la entrada para la gestión de requisitos
(es decir, el Concepto de Operaciones y las Especificaciones Técnicas se colocan
bajo el control de línea de base). Las solicitudes de cambio inician cambios en la
línea de base requisitos, que sólo debe ser cambiado como resultado de análisis
de impacto y los ajustes apropiados en algunas o todas las necesidades de
funcionamiento, restricciones de diseño, las especificaciones técnicas y las
restricciones del proceso. Las actividades representadas en la Figura 3.2 pueden
ocurrir varias veces en un proceso de desarrollo iterativo.
Elicitación de requisitos operativos Como se ilustra en la Figura 3.2 (y las Figuras

2.1 y 2.5), los usuarios tienen necesidades, los clientes tienen expectativas, y
www.it-ebooks.info
adquirentes tienen condiciones. Los usuarios de los cajeros automáticos (usted y
yo, los usuarios finales de los cajeros automáticos)
www.it-ebooks.info
TABLA 3.2 Taxonomía de los problemas de los requisitos y ejemplos

Problema CategoryExamples
declaración de un IncorrectIncorrect requisito operativo traducción
incorrecta de una necesidad operativa en una
especificación técnica
valor incorrecta o variable en un requisito
constantes externos incorrectos
Exagerar o subestimar los recursos informáticos asignados a un
requisito
Descripción incorrecta de estado del sistema inicial
IncompleteOmitted requisito
la descomposición incompleta de un requisito
descripción incompleta de un fracaso requisito
para describir completamente la entrada del
sistema o fallo salida para especificar el estado
inicial
Descripción incompleta del sistema inicial
InconsistentRequirements estatales que están por parejas
inconsistente
Requisitos para los procesos concurrentes, cuando se toman por
pares, son incompatibles
AmbiguousMeaning del requisito es poco claro
Requisitos establecidos de una manera que es difícil de entender
InfeasibleRequirement imposible de conseguir dado el estado de tecnología
Requisito imposible de conseguir por los algoritmos de la ciencia
actual
Requisito imposible de conseguir por los conocimientos actuales
de nuestros desarrolladores de software
Requisito imposible de conseguir dado otros factores del
sistema, tales como la velocidad del procesador o de la
memoria disponible
Difícil para achieveRequirement que será difícil de implementar con disponible
recursos, programación, y la tecnología
Requisito de que será difícil de conseguir por los
conocimientos actuales de nuestros desarrolladores de
software
OverspecifiedRequirement supera las necesidades operativas, causando costo
adicional ConstrainedConstraints excesivamente sobre el rendimiento y la fiabilidad de
la excesiva el
necesidad operativa, causando costo adicional
No tracedRequirement no se ha remontado a anterior o subsecuente
fases
Requisito no se puede remontar a fases anteriores o posteriores
no verifiableCompleteness, corrección, y la consistencia de la requisito
no puede ser verificada por cualquier método de
verificación razonable No puede ser validatedRequirement no se indica de una
manera que ofrece validación
criterios para el software implementado
requisito fuera Requisito pertenece en otra sección del requisito de documento
de lugar
requisito especificado en otra parte en la especificación
redundante
información Cronograma, presupuesto, planes de formación, y otros
inapropiada elementos que pertenecen a otros documentos
www.it-ebooks.info
tienen necesidades que van desde la obtención de dinero en efectivo en

momentos y lugares convenientes para hacer depósitos y transferir fondos entre
cuentas. Clientes (las instituciones financieras que adquieran sistemas ATM)
pueden tener expectativas de aumento de la satisfacción del cliente para sus
clientes (usted y yo), un menor número de personal operativo, y menos papeleo
asociado con las cuentas de clientes. Los usuarios finales (usted y yo) puede ser
bien satisfechos con el sistema ATM pero la institución financiera puede
encontrar que necesitan personal más operativos y tienen más papeleo que antes.
Por tanto, es posible satisfacer las necesidades del usuario y no satisfacer las
expectativas del cliente, y viceversa. Una adquirente (que también pueden o no
ser el cliente, que también pueden o no ser un usuario) tiene típicamente
condiciones que especifican las limitaciones de los factores del proceso, tales
como calendario y el presupuesto.
Las necesidades y expectativas de las partes interesadas distintas de los
usuarios finales y los clientes también deben ser tomados en consideración. Otras
partes interesadas incluyen a aquellas que afectan o son afectados por el sistema
propuesto. El personal de operaciones para un sistema de ATM, por ejemplo, son
grupos de interés. Incluyen cajeros de banco, otros miembros del personal que
trabajan en la institución financiera, y los que proporcionan apoyo operativo para
las máquinas, incluyendo el personal que configuran las máquinas, cargar dinero
en ellos, comprobar el funcionamiento de las máquinas, y repararlos cuando el
mal funcionamiento .
Estos personal de operaciones (cajeros y operaciones de apoyo) no se
clasifican como usuarios finales del sistema porque están bajo control del cliente;
que pueden ser reclutados, entrenados, supervisados, y separados por el cliente.
En este sentido, son parte del sistema y no forma parte del entorno operativo del
sistema. Los usuarios de un sistema ATM (usted y yo) no están bajo control del
cliente; estamos por lo tanto elementos del entorno operativo.
El proceso de determinación de las necesidades del usuario y las expectativas
del cliente se conoce como la obtención de requisitos. Hay muchas técnicas para
la obtención de los requisitos operacionales. Algunas de las técnicas más
ampliamente utilizados incluyen los siguientes:
• la introspección: ¿qué me gustaría / necesidad / deseo si fuera un usuario del
sistema propuesto?
• lluvia de ideas: la asociación libre y la generación de ideas para el sistema
propuesto
• Notas Post-It y pizarra blanca: crear, modificar, agrupar y reorganizar las
declaraciones de necesidades y deseos
• prototipos de papel y storyboards: construir interfaces y escenarios
operacionales.
• cuestionarios: ¿cuál de las siguientes características es lo que necesita / deseo?
• observación: ver a las personas que realizan sus tareas de trabajo
• entrevistas abiertas: me dicen como se puede utilizar el sistema propuesto
• grupos de enfoque: por favor, nos dicen lo que usted quiere / necesidad /
deseo en el sistema propuesto
• tutoriales operacionales: el desarrollo de escenarios de interacción con los
usuarios
• demostraciones: cómo te gusta esta interfaz? lo que se debe añadir /
eliminado / cambiado?
• análisis de protocolo: documentar las tareas realizan los usuarios y las
características que necesitarían en el sistema propuesto
www.it-ebooks.info
• análisis de casos de negocios: ¿qué características son necesarias para apoyar

las operaciones de nuestro negocio?
• JAD (desarrollo de la aplicación conjunta): sesiones de reuniones facilitadas
con los usuarios
Más información sobre la obtención de requisitos se puede encontrar en las

siguientes referencias: [LEFF03], [ROBERT06] [WEIGER03].
El Concepto de Operaciones (CONOPS) El documento en el que se registran los

requisitos operacionales que se denomina el Concepto de Operaciones (CONOPS).
Otros nombres para este documento incluyen conceptos operativos de documentos
(TOC) y la Declaración de la Visión. El formato y contenido del concepto de
operaciones documentos son ficado speci- en el estándar IEEE 1362 ™ -1998 Guía
de IEEE para Tecnología de Información del sistema Definición-Concepto de
Operaciones (CONOPS) El documento [IEEE1362].
Contenido de una ConOps incluyen los
siguientes:
• necesidades y expectativas que motivan el desarrollo de un nuevo sistema o

modificación de un sistema existente
• una visión operativa para el sistema propuesto
• modos de operación para el sistema propuesto
• clases de usuario y las características
• tipos de características y de personal de operaciones
• requerimientos operacionales
• escenarios operacionales
• las características del sistema de prioridad y atributos de calidad
• impacto del sistema propuesto en el desarrollo, entornos operativos y de
mantenimiento
necesidades de los usuarios y las expectativas de los clientes proporcionan el

impulso para emprender un proyecto de software. Los ConOps deben incluir
una descripción de las deficiencias en el sistema existente o situación que
proporciona la motivación para la modificación de un sistema existente o el
desarrollo de un sistema automatizado para reemplazar o aumentar las
operaciones manuales.
Una visión operativa del sistema propuesto incluye una descripción por escrito
del sistema en su entorno operativo. Esta información es a veces contenida en
una declaración de misión o una propuesta de comercialización; que puede estar
totalmente contenida en los ConOps o resume en los ConOps y se describen
completamente en un documento de referencia. Diferentes modos de
funcionamiento proporcionan diferentes conjuntos de comportamientos para
diferentes situaciones y diferentes tipos de usuarios. Un cajero automático, por
ejemplo, podría tener un modo de línea normal en sitio, y en línea con ayuda de
modo de, en línea degradado un modo fuera de línea-de diagnóstico modo, un
modo de configuración off-línea-, y.
Diferentes modos de funcionamiento se asocian a menudo con diferentes
clases de usuarios y el personal de operaciones. El modo en línea degradada
podría permitir el uso limitado de un cajero automático cuando el enlace de
comunicación con el servidor no está disponible; por ejemplo, la aceptación de
depósitos para su posterior publicación a una cuenta de efectivo o limitar
www.it-ebooks.info
dispensa- ción a $ 50 USD o menos durante los períodos de interrupción de la
comunicación. El modo en línea- asistida de un cajero automático puede ser
especificado para apoyar a los usuarios que necesitan aumentados
www.it-ebooks.info
apoyar a ver o escuchar al operar las máquinas. El modo de fuera de línea-de

configuración puede especificarse para permitir mantenedores operacionales para
cargar dinero en los contenedores de la ATM y registrar la cantidad de dinero
cargado en cada bin. el modo de diagnóstico sería comprobar el funcionamiento
del sistema, incluyendo el enlace de comunicación y los dispositivos periféricos
tales como la cámara, impresora, lector de tarjetas, y dispensador de dinero.
requisitos operacionales y escenarios operativos son el corazón de un ConOps;
que expresan las características deseadas del sistema y los requisitos de calidad
desde el punto de vista externo de las necesidades de los usuarios y las
expectativas del cliente. Cada escenario operacional es una descripción de una
secuencia paso a paso de las interacciones para una transacción entre una clase de
usuarios o personal operativo y un sistema de software intensivo. Ejemplos de
transacciones incluyen un usuario retirar dinero de un cajero automático o un
establecimiento de una nueva cuenta de usuario de cajero de banco. Depositar el
dinero es un escenario diferente que con- dibujo dinero porque se trata de tareas
de usuarios distintos.
escenarios operacionales describen interacciones paso a paso entre un agente
externo (es decir, un usuario) y elementos internos de un sistema. escenarios
operacionales deben incluir escenarios para el funcionamiento normal del sistema
por parte de sus usuarios previstos, además de escenarios para el manejo de
excepciones, las respuestas degradados, generación de informes, la reconciliación
de los datos y las actividades de mantenimiento, según el caso. Las técnicas para
escenarios operacionales Menting docu- incluyen listas de interacciones
secuenciales, diagramas de secuencia y diagramas de estado [RUMB98]
contados.
Los casos de uso se utilizan a menudo para documentar escenarios
operacionales; una plantilla para, y un ejemplo de un caso de uso se proporcionan
en la Tabla 3.3. Detalles adicionales relativos a los casos de uso se presentan en
el recuadro “Evaluación de Casos de uso” en el Capítulo 7 de este texto. Los
requisitos de calidad que se aplican a un caso de uso se pueden documentar en la
sección de comentarios, por ejemplo, “buen tiempo de respuesta” durante el
inicio de sesión del usuario.
Los requisitos de calidad, según lo expresado por los usuarios y clientes, son a
menudo vaga, imprecisa y ambigua. Los usuarios pueden, por ejemplo, expresar
un deseo de un sistema que es altamente fiable y fácil de usar. Durante estas
declaraciones requisitos de análisis
TABLA 3.3 Uso plantilla del caso y el ejemplo

Caso de uso ID: ATM # 34
Utilice el nombre del caso: Inicio de sesión de usuario
Actor que inicia el caso de uso: cliente de un banco
Otros actores, en su caso: ninguna
Declaración del propósito de este caso de uso:
este caso de uso documenta la forma en clientes del banco inician una sesión en un cajero
automático
Condiciones previas (Debe ser verdad antes de este caso de uso puede ser
“ejecutado”): el cliente tiene una tarjeta de crédito válida y el PIN
(número de identificación personal)
escenario primaria (Para describir la acción principal del caso de uso):
puede documentarse utilizando un diagrama de secuencia, diagrama de estado, o narrativa
Post-condiciones (Lo que debe ser cierto después de este caso de uso
“ejecuta”): El cliente es conectado o cliente ha recibido un mensaje lo
www.it-ebooks.info
siento
escenarios alternativos (manejo de excepciones):
tarjeta bancaria no válida; PIN incorrecto; número de cuenta no válido; ATM es off-line
comentarios: este caso de uso pertenece a Iniciar transacción. El cajero automático debe
tener un buen tiempo de respuesta durante el inicio de sesión del usuario.
www.it-ebooks.info
debe traducirse en las especificaciones técnicas de la que los criterios de

verificación y validación objetiva para el sistema de entrega se pueden derivar;
Sin embargo, los usuarios y clientes deben ser alentados a expresar atributos de
calidad en cualquier términos son significativos para ellos porque sus
declaraciones expresan de calidad, sin embargo, de manera imprecisa
necesidades del usuario y las expectativas del cliente. El incumplimiento de sus
necesidades percibidas y las expectativas puede resultar en el rechazo del sistema
entregado por el cliente o el fracaso de los usuarios a adoptar el producto cuando
se instala en el entorno operativo.
Como un ejemplo de la diferencia entre las necesidades operativas y las
especificaciones técnicas, un requisito operativo puede ser expresada como:
3.6 Los terminales ATM en el Sistema de caja automatizada deberán proporcionar un

buen tiempo de respuesta.
Este requisito operativo, según lo expresado por el cliente puede ser, después de
consideraciones de la satisfacción del usuario, la programación del proyecto, el
esfuerzo, el costo y la tecnología traducido en la siguiente especificación técnica:
3.6 Los terminales ATM en el Sistema de caja automatizada deberán proporcionar:

• un tiempo de respuesta promedio de 2 segundos y un tiempo de respuesta
máximo de 5 segundos para la iniciación de transacción y consultas de saldo
• un tiempo de respuesta promedio de 5 segundos y un tiempo de respuesta
máximo de 10 segundos para las solicitudes de retiro y de depósito.
Tiempos promedio y máximo de respuesta se determinarán para un período de 1
hora de funcionamiento durante el cual se procesan una mezcla aleatoria de
consultas de saldo, 3.000 solicitudes de retiro, y las solicitudes de depósito.
Estos tiempos de respuesta se medirán cuando 50 terminales son simultáneamente
activa y el servidor se ejecuta en un factor de carga promedio de 80%.
Un prototipo de la interfaz de usuario ATM que proporciona los tiempos de

respuesta indicados se podría construir para demostrar los tiempos de respuesta a
representantes de los usuarios y el cliente de modo que un acuerdo se puede
llegar a que los tiempos de respuesta especificados serían aceptables.
El establecimiento de prioridades entre las características del sistema y
atributos de calidad es un paso importante porque los usuarios, clientes y otras
partes interesadas suele tener más necesidades, expectativas y deseos que se
pueden implementar dentro de las limitaciones de tiempo, dinero, recursos y
tecnología. Una forma de dar prioridad a los requisitos operacionales es detallar
primero y luego colocar cada requisito en la categoría de esencial, deseable u
opcional. Cada requisito detallada debe ser una declaración declarativa simple
que no contiene “ands”, “ORS”, “si” o “peros”.
requisitos esenciales son aquellas características y atributos de calidad que
deben ser proporcionados si el sistema es básica para satisfacer las necesidades
del usuario y las expectativas del cliente. Requisitos esenciales de un sistema de
ATM pueden incluir lo siguiente:
E1: permitir que los cajeros de banco para crear

cuentas de usuario
E2: proporcionar un mecanismo seguro para los usuarios acceder
a sus cuentas E3: permite a los usuarios retirar dinero de sus
cuentas
www.it-ebooks.info
se deben implementar todos los requisitos esenciales; priorización de los

requisitos esenciales proporciona una base para el desarrollo iterativo.
requisitos deseables son las que agregan valor al sistema. Son implementado
en orden decreciente con el tiempo, los recursos y la tecnología permiso.
Ejemplos de un Sistema de caja automatizada, en orden de prioridad, podrían
proporcionar a los usuarios la capacidad de:
depositar dinero en una cuenta: D1

D2: acceso al ahorro y cuentas corrientes D3:
cuentas de tarjetas de crédito Acceso
D4: tienen pre-autorizada límites de crédito para los
descubiertos requisitos opcionales pueden incluir la
capacidad de:
O1: sellos de compra a través de la interfaz de la

atmósfera de O2: pagar facturas de servicios públicos a
través de la interfaz ATM
Las técnicas para el desarrollo de las prioridades entre las necesidades

operacionales incluyen el método Delphi [Boehm81], Quality Function
Deployment (QFD) [COHEN95], y el proceso analítico jerárquico (AHP)
[MIND95], [SAATY05].
Su plan de proyecto inicial debe proporcionar suficientes horario, presupuesto
y recursos para implementar los requisitos esenciales y como muchos de los más
deseables que pueden ser acomodados dentro de las limitaciones del proyecto
(sujetos a negociación y el acuerdo con el cliente). Requisitos opcionales son
aquellos que podrían ser implementado si hay suficiente tiempo y recursos y / o
si son fáciles de incorporar. Un papel importante de los requisitos opcionales es
documentar las ideas para las características que podrían incluirse en futuras
versiones del sistema e ideas que son demasiado “lejos” para los usuarios y las
tecnologías de hoy en día. Requisitos triaje es otra técnica para determinar qué
requisitos debe satisfacer un producto dado el tiempo y los recursos disponibles
para desarrollar el producto [DAVIS03].
También es importante documentar en los ConOps el impacto del sistema
propuesto en los entornos de desarrollo, operativos y de mantenimiento. Los
Ircops desa- del sistema nuevo o modificado pueden tener que mantener el viejo
sistema, mientras que el desarrollo de la nueva. Los representantes de los clientes
y usuarios tendrán que asignar tiempo para cumplir con los desarrolladores, para
probar las interfaces de usuario propuestos, para ver demos- onstrations, y para
criticar el sistema en evolución. Las nuevas instalaciones operacionales pueden
tener que ser construida, como en ubicaciones físicas para cajeros automáticos o
salas de control para reactores nucleares o naves espaciales. impactos operativos
podrían incluir la creación de nuevos escritorios y la formación de personal de
apoyo de ayuda para los paquetes de aplicación o, en el caso de los cajeros
automáticos, la contratación y formación de personal de soporte de operaciones y
formación de los cajeros de banco.
Análisis 3.4.2 Requisitos

Es posible que los requisitos operacionales para su proyecto se expresan de una
manera vaga, imprecisa, y / o ambigua. Tales declaraciones se denominan “de
www.it-ebooks.info
diseño
www.it-ebooks.info
metas “. El proceso de análisis de requisitos se ocupa de aclarar los requisitos

operativos y su actualización con en términos que proporcionan criterios
objetivos que pueden utilizarse para verificar y validar que el sistema
especificado, cuando está listo para la entrega, será completa, correcta y
coherente con respecto a los requisitos establecidos objetivamente (verificación)
y que va a satisfacer su finalidad prevista en el entorno previsto (validación).
Usted, el director del proyecto, no se debe aceptar objetivos de diseño como
requisitos obligatorios. Para evitar esto, usted y su cliente podría estar de
acuerdo, por ejemplo, que “fácil de usar” significa que el sistema debe ser fácil
de aprender y fácil de usar para una cierta clase de usuarios. Usted y su cliente
podría estar de acuerdo, además, que “fácil de usar” se establecerá mediante la
realización de experimentos con una población de usuarios típicos para evaluar si
pueden aprender a realizar, y en repetidas ocasiones realizar, especifica las tareas
dentro de períodos específicos de tiempo.
Por ejemplo, un experimento podría implicar la selección de, al, 30 usuarios
típicos aleatorias de un sistema de punto de venta, tales como los utilizados en los
supermercados y tiendas de descuento. Podría ser acordado que el criterio de
“fácil de usar” estaría satisfecho si 27 de 30 usuarios pueden, después de un curso
de entrenamiento de 4 horas, completar con éxito un conjunto de operaciones
especificadas dentro de los 30 minutos y se puede completar con éxito las
operaciones de nuevo una semana más tarde después de una 20 minutos clase de
repaso. El experimento podría llevarse a cabo con un prototipo de la interfaz de
usuario para proporcionar información a los desarrolladores de software y de
nuevo cuando la verificación y validación del sistema entregado. De esta manera,
el objetivo de diseño de “fácil de usar” se ha convertido en un requisito que
puede ser validado por medio objetivo.
Algunos de los requisitos operacionales se describen las funciones que debe
prestarse; por ejemplo:
3.4 Los terminales Cajero deben proporcionar un mecanismo para autorizar el

acceso a las cuentas individuales de los clientes.
3.5 terminales ATM deben proporcionar una opción de dinero rápido.
El procedimiento para autorizar el acceso de los clientes a sus cuentas (por

ejemplo, la huella del pulgar, escaneo de retina, reconocimiento de voz, o de
cajero automático y PIN) sería determinado por la creación de prototipos,
estudios de viabilidad, y las conversaciones con los clientes y usuarios
representantes. requisito operativo 3.4 podría ser reformulada como una
exigencia principal en las especificaciones técnicas:
3.4 tarjetas de cajero automático y números PIN será el mecanismo que se utiliza
para autorizar el acceso a las cuentas individuales de los clientes.
O bien, el requisito podría decirse con mayor precisión como:
3.4 tarjetas de cajero automático que tienen las dimensiones físicas de una tarjeta
de crédito y los PIN que consta de seis símbolos alfanuméricos serán el
mecanismo usado para autorizar el acceso a las cuentas individuales de los
clientes.
www.it-ebooks.info
Los detalles relativos a la información que se ha codificado en una tarjeta de

cajero automático también se manifestaron.
requisito operativo 3.5 podría ser reformulada como:
3.5 terminales ATM deberán presentar una opción de retiro “dinero rápido” que
proporciona $ 100 USD en denominaciones de $ 20 USD. Las transacciones
múltiples no serán permitidos en los retiros de dinero rápido.
Tenga en cuenta que las declaraciones más precisas de las especificaciones

técnicas restringen el espacio de diseño a partir de la cual las soluciones pueden
ser sintetizados, pero, al mismo tiempo, proporcionar expresiones más
específicas de las necesidades de los usuarios y las expectativas del cliente.
También proporcionan una orientación más específica a los desarrolladores de
sistemas y proporcionan criterios de validación objetiva.
Puede que no sea posible repetir cada objetivo de diseño de una manera
objetiva. Por ejemplo, puede no ser práctico o incluso posible establecer de
manera objetiva que el sistema entregado es el “mejor sistema de transacción
financiera del mundo” o el “simulador de vuelo más realista jamás construido.”
En estos casos, los objetivos de diseño, aunque no se dice en una de manera
objetiva, sin embargo, pueden influir en las decisiones de diseño y otros factores
tales como horarios, presupuestos, y las características y atributos de calidad del
producto. Si, por ejemplo, “mejor” se entiende “tiene más características de los
usuarios que los sistemas comparables”, esto indicaría que el número de
características que deba ejecutarse sea de mayor prioridad que el costo o
cronograma; dado diseño alternativo A o B, la alternativa que proporciona el
mayor número de características sería elegido.
3.4.3 Especificaciones técnicas

Como se ilustra en la Figura 3.1, hay tres tipos de requisitos operacionales y
4 tipos de especificaciones técnicas para el software. Los requisitos operativos
incluyen:
• características operativas,
• atributos de calidad, y
• restricciones de diseño.
Las especificaciones técnicas, que se derivan de los requisitos operativos,

incluyen:
• requisitos primarios,
• requisitos derivados,
• objetivos de diseño, y
Cada uno de los cuatro tipos de especificaciones técnicas (requisitos primarios,

requisitos derivados, objetivos de diseño, y las restricciones de diseño) deben
identificarse por separado y figuran dentro de su propia categoría.
www.it-ebooks.info
requisitos principales son características operativas que han sido traducidos a

las especificaciones indicadas de manera objetiva; que incluyen tanto los
requisitos funcionales y requisitos de calidad. Las segundas versiones de
requisitos 3.4 y 3.5 (arriba) son ejemplos de los requisitos primarios. Algunos de
los requisitos operacionales pueden ser expresadas en una manera objetiva,
verificable; esos requisitos operativos se convierten en requisitos primarios o
restricciones de diseño sin traducción posterior.
Como otro ejemplo de la distinción entre las necesidades operativas y las
especificaciones técnicas, los requisitos operacionales de un simulador del
sistema de conducción puede especificar que el simulador debe ser capaz de
simular una variedad de condiciones de conducción, incluyendo condiciones
claras y secas, así como la lluvia, el hielo, la nieve , y las condiciones de niebla.
Las especificaciones técnicas correspondientes podrían afirman que el coeficiente
de fricción en las ecuaciones de estabilidad del vehículo debe ser variable entre
0,0 y 1,0, que la agudeza visual en el campo simulada de visión debe ser variable
entre 3 pies y el infinito, y que ambas variables debe ser controlables desde la
consola de un instructor.
Ambas afirmaciones son necesarias. En este ejemplo, la vista externa
(requisito operativo) establece, para los usuarios, clientes, adquirente,
desarrolladores y otros interesados, las características operacionales del sistema
que se construirán. La vista interno (especificaciones técnicas) proporciona la
base para el diseño, implementación y verificación de que el sistema de entrega
es completa, correcta y coherente con respecto a sus especificaciones técnicas,
documentación de diseño y código. El requisito funcional (capaz de simular una
variedad de condiciones de conducción, incluyendo condiciones claras y secas o
lluvia, hielo, nieve, y las condiciones de niebla) proporciona criterios de
validación para determinar el grado en que el sistema va a satisfacer las
necesidades del usuario y las expectativas del cliente cuando colocado en el
entorno operativo.
En muchos casos los requisitos de los ingenieros intentan utilizar un solo
documento para especificar tanto los requisitos externos (operativos) e internos
(técnicos). Esto a menudo resulta en un documento que es demasiado técnico
para los usuarios y clientes para entender o demasiado vagos para ser de utilidad
para los desarrolladores. La experiencia ha demostrado que es más eficiente y
más eficaz para desarrollar dos documentos distintos para dos propósitos
distintos: el Concepto de Operaciones para documentar las necesidades de
funcionamiento y la especificación de requisitos para documentar los requisitos
técnicos. Por supuesto, las correspondencias entre los dos documentos deben ser
estable- cado y mantenido. matrices de trazabilidad se utilizan a menudo para
este fin (véase la Tabla 3.6).
La figura 3.3 ilustra el seguimiento del proceso de traducción de
características operativas a requisitos primarios. Un requisito operativo puede
traducirse en más de un requisito primordial. En este caso la función operativa se
debe plantear descomposición de modo que cada función operativa se traduce a
una y sólo una exigencia principal. De lo contrario, algunos elementos de algunas
de las características operacionales pueden ser implementado más de una vez por
diferentes desarrolladores o equipos de desarrollo, y algunos elementos pueden
omitirse si el mapeo de una necesidad operativa a múltiples requerimientos
primarios no está completo y uno a uno. El logro de esta condición puede
requerir algún tipo de reorganización y la descomposición de las exigencias
operativas. La figura 3.3 indica que algunos requisitos de explotación no tienen
requisitos principales correspondientes;
www.it-ebooks.info
250
# De
característic
200
as
operativas
150 # De las necesidades
primarias
100
50
0
primero Wk tercero cuarto HORA
segundo Wk Wk Wk
FIGURA 3.3 características de funcionamiento y requisitos primarios
La traducción de características operativas en requisitos primarios requiere un

poco de tiempo y esfuerzo; la investigación, el análisis y la creación de prototipos
pueden ser necesarios para entender el esfuerzo, el horario, la viabilidad técnica,
el costo y los niveles de aceptación por parte de los usuarios de los niveles dife-
rentes de cuantificación de las necesidades. De una manera similar, la traducción
de las restricciones de diseño de los requisitos operacionales a especificaciones
técnicas pueden requerir algún esfuerzo para determinar compensaciones
aceptables entre los niveles de la cuantificación y esfuerzo, horario, viabilidad
técnica, el costo y la aceptación del usuario. Algunos requisitos funcional
pueden permanecer como objetivos de diseño de un período prolongado de
tiempo hasta valores aceptables, cuantificados de las especificaciones técnicas
correspondientes se pueden determinar.
Tenga en cuenta también que el número de características operativas continúa
creciendo con el tiempo en la figura 3.3; esto puede ser causado por:
• descomposición de los requisitos operativos a niveles de detalle más fino, o
• “La corrupción del alcance” en el que los requisitos están aumentando sin
ajustes correspondientes para programar, el presupuesto y / o recursos
(malo), o
• continua redefinición del alcance del proyecto, cronograma, presupuesto y
recursos para satisfacer las cambiantes necesidades de los usuarios o las
condiciones del mercado, lo cual es aceptable, siempre y cuando las partes
interesadas están de acuerdo.
requisitos derivados (el segundo tipo de especificación técnica) son requisitos

para las características del sistema y atributos de calidad que no son visibles para
los usuarios pero que son necesarias para apoyar las necesidades de
funcionamiento. requisitos derivados se incluyen en las especificaciones técnicas
por dos razones:
1. para descomponer los requisitos operativos de alto nivel en especificaciones

técnicas detalladas, y
2. para proporcionar capacidades adicionales necesarias para satisfacer las
necesidades operacionales.
Un ejemplo extremo de la primera situación (descomposición de las

necesidades operacionales de alto nivel) sería derivación de las especificaciones
www.it-ebooks.info
técnicas para un Sistema de caja automatizada basada en un único requisito
operativo:
www.it-ebooks.info
3.0 El sistema de caja automatizada proporcionará a las características, el rendimiento y

los atributos de calidad normalmente proporcionada por tales sistemas.
O, como es sabido, el único requisito operacional declarado por el presidente

estadounidense Kennedy en 1961:
para poner un hombre en la Luna y regresar a salvo a la Tierra a finales de

esta década.
Como un ejemplo de proporcionar una capacidad derivada para satisfacer un

requisito operativo, el requisito operacional podría indicar:
2,9 Cada transacción ATM proporcionará al usuario un recibo impreso que

contiene un registro de la transacción que incluye la fecha y hora de la
transacción.
Un requisito derivado debe ser añadido a las especificaciones técnicas para

especificar una función de reloj al que se accederá al imprimir recibos de los
clientes. El requisito derivado sería especificar una función de reloj que tiene la
resolución necesaria y la deriva permitida (por ejemplo, una resolución de 1
milisegundo y la deriva de no más de 5 milisegundos por día). El requisito de
reloj derivada podría ser asignado como un requisito hardware, como un requisito
de software, o podría resultar en la especificación del hardware y el software
necesarios para obtener la hora exacta de una fuente externa tal como un servidor
central, un estándar de tiempo universal, o la sistema de satélites GPS.
Como se mencionó anteriormente, los requisitos establecidos de una manera
que no es compatible con los criterios de verificación y validación establecidos
objetivamente se clasifican como objetivos de diseño. Los objetivos de diseño
son, pues, los requisitos operacionales que aún no han sido, o no pueden,
traducidos a las especificaciones técnicas establecidas de manera objetiva. Cada
objetivo de diseño debe ser examinado para su posible traducción a una de las
otras tres categorías (requisito principal, requisito derivado o restricción de
diseño). Puede ser posible traducirse algunos objetivos de diseño, como en el
ejemplo anterior de “fácil de usar”, en especificaciones objetivas. Otros
requisitos tales como “sistema de transacción financiera mejor del mundo”
pueden no ser cuantificables y por lo tanto se mantendrá como objetivos de
diseño.
Puede que no sea posible traducir los objetivos de diseño en las
especificaciones técnicas durante las etapas iniciales del desarrollo requisitos
debido a las incertidumbres sobre el costo, horario, y la viabilidad de la
aplicación de diversos niveles de la cuantificación. Por ejemplo, la creación de
prototipos y estudios de viabilidad pueden revelar que la consecución de un
tiempo de respuesta promedio de 2 segundos y un tiempo de respuesta máximo
de 5 segundos para consultas de saldo en el Sistema Cajero cuando 50 terminales
están activos y el servidor se ejecuta en la capacidad de carga 80% se requieren
una tecnología costosa (es decir, las CPU en las terminales, el ancho de banda de
comunicación, la capacidad del servidor, la velocidad de acceso a la base de
datos de cuentas de cliente); sin embargo, un tiempo de respuesta promedio de 4
segundos y un tiempo de respuesta máximo de 8 segundos se podrían lograr por
mucho menos coste. Teniendo en cuenta el equilibrio entre coste y rendimiento,
el cliente puede estar de acuerdo con los parámetros de rendimiento menos
estrictos. La opción de rendimiento más caro podría ser elegido si el sistema
fuera un sistema de misión crítica, tales como el tráfico aéreo
www.it-ebooks.info
sistema de control para la comunicación entre los controladores de tráfico aéreo y

pilotos, en lugar de un sistema de cajero automático.
Como se indicó anteriormente, puede que nunca sea posible traducir algunos
objetivos de diseño en requisitos cuantificados. Supongamos, por ejemplo, que
un requisito operativo establece:
4.1 El sistema de procesamiento de pedidos será el mejor del

mundo.
El problema con este requisito es que no es factible estudiar todos los sistemas de
procesamiento orden en el mundo y cuantificar “mejor del mundo” y, como
resultado, el ingeniero de requisitos no debe aceptar el contrato de unión “se” de
la cuenta . Sin embargo, este objetivo de diseño expresa un resultado deseado y
debe ser aceptado como un requisito vinculante que determinará las prioridades
entre los costos, plazos, características, opciones de diseño y la tecnología que se
utiliza. O bien, este objetivo de diseño se puede eliminar cuando la realidad del
costo y el horario para construir un sistema que se aproxima a “los mejores del
mundo” se presenta al cliente.
Las restricciones de diseño son la cuarta categoría de especificación técnica.
Una restricción de diseño es una decisión de diseño se indica en los requisitos y
para el que no se permite ninguna flexibilidad en el diseño o la implementación,
como por ejemplo:
3.12 El algoritmo de fusión-tipo se utiliza para conciliar los datos de cuenta de cliente
en una base diaria.
restricciones de diseño establecidos imprecisa deben aclararse. Por ejemplo, que

los datos del cliente son a reconciliarse? Reconciliarse con qué? ¿Por qué se debe
utilizar el mergesort algoritmo? ¿Es importante indicar la hora del día en que se
deben reconciliarse los datos?
Las restricciones de diseño también pueden especificar las operaciones que el
sistema no tiene que hacer, por ejemplo:
3.17 Los retiros de cada cuenta de cliente no deberá exceder $ 500 USD en cualquier
período de 24 horas.
No incorporar esta característica en el diseño del sistema podría dar lugar a la

reanudación de forma decisiva al incorporarlo durante la verificación y
validación del sistema entregado. Las restricciones de diseño, como se indica en
las necesidades de funcionamiento, pueden ser vagos, imprecisos, y / o
excesivamente restrictiva, pero en las especificaciones técnicas que deben ser
indicado en una manera que sea factible y que permita la verificación objetiva de
las especificaciones técnicas.
A (cuestionable) restricción de diseño podría enunciarse como sigue:
7.3 La base de datos de clientes transacción se actualizará 12:00-01 a.m. cada día,
utilizando el algoritmo de fusión-tipo.
Esta restricción de diseño es cuestionable por varias razones:
• En primer lugar, el detalle operacional de precisión cuando los datos están

ordenados no tiene cabida en la documentación de los requisitos; debe
tenerse en cuenta en un manual de operaciones. También debe ponerse en
duda en cuanto a la necesidad de la limitación de tiempo
www.it-ebooks.info
de 12:00-01 a.m. cuando el manual de Operaciones es revisado por el

personal de operaciones.
• En segundo lugar, la posibilidad de completar el tipo de datos en un período
de 1 hora cuando el servidor está (presumiblemente) se ejecuta con un
pequeño número de terminales activos y un bajo porcentaje de uso de la
CPU (es decir, tarde por la noche) debe ser determinado.
• En tercer lugar, “pequeño número de terminales activos” y “bajo porcentaje
de uso de la CPU” se debe cuantificar, tal vez después de un análisis, y se
especifica en los requisitos primarios que corresponden a requisito
operacional 7.3 anteriormente.
• En cuarto lugar, la necesidad de utilizar el algoritmo de fusión-tipo debe
aclararse.
Por otro lado, una restricción de diseño de la forma siguiente puede ser necesario
para proporcionar una interfaz requerida de un Sistema de caja automatizada:
4.4 La interfaz banco cajero deberá proporcionar una capacidad de consulta SQL
para acceder a la base de datos-cuentas de clientes.
Cada restricción de diseño restringe el espacio de diseño a disposición de los

diseñadores de los programas y puede dar lugar a un diseño óptimo de las
limitaciones de diseño system.17 debería por tanto:
• ser identificado como tal,

• tiene su necesidad justificada,
• proporcionar flexibilidad, si alguna, y
• reformularse de una manera objetiva.
Durante la fase de diseño, los enfoques alternativos para satisfacer la restricción,

si es que existen, deben ser identificados y analizados. El requisito derivado para
ción un reloj fun- en los cajeros automáticos, por ejemplo, no restringe enfoques
alternativos para proporcionar esa funcionalidad. Si, sin embargo, el requisito se
manifestó como una limitación de diseño que requiere la fecha y hora de las
transacciones que se obtendrán de un estándar de tiempo universal, que excluiría
las opciones de obtención de hora del servidor ATS, el reloj interno de la CPU de
la ATM, de los satélites GPS, o de otra fuente. Una de estas opciones podrían ser
una mejor opción de diseño en el contexto de la arquitectura de software cliente-
servidor ATS.
En algunos casos (por ejemplo, un sistema de uso intensivo de usuario basada
en la web), las necesidades de funcionamiento, cuando se traduce a las exigencias
principales, pueden proporcionar una base adecuada para la construcción de un
sistema de software intensivo. Pero a menudo se encuentra que es necesario
incluir requisitos y limitaciones derivadas cuantificados de diseño para facilitar la
actividad mental en práctica de los requisitos operativos directamente traducidos
y restricciones de diseño y, por ejemplo, garantizar la interoperabilidad de su
sistema con otros sistemas. En otros casos, puede recibir los requisitos operativos
de alto nivel y straints con- diseño de una comercialización, ingeniería de
sistemas, o grupo de hardware. En estos casos se encuentra que es necesaria para
descomponer y cuantificar las necesidades de funcionamiento, añadir requisitos
derivados, y aclarar las restricciones de diseño con el fin de proporcionar una
17
Un diseño óptimo del sistema logra el mejor equilibrio posible entre las características y atributos
de calidad priorizados. Un diseño óptimo es aquel que optimiza las características particulares o
www.it-ebooks.info
atributos de calidad a costa de los demás.
www.it-ebooks.info
base adecuada para desarrollar e implementar planes para llevar a cabo el diseño
de software, implementación y verificación y validación.
La documentación de las especificaciones técnicas Las categorías que se enumeran

en la Tabla 3.4 se pueden utilizar para organizar y documentar las especificaciones
técnicas.
Norma IEEE 830 ™ -1998 es un “Práctica Recomendada para Software
REQUISITOS DE Especificaciones” [IEEE830]. Tabla 3.5 se enumeran los
requisitos específicos que se documenta en la sección 3 de una especificación de
requisitos de software que se ajusta a IEEE 830.
Como se indica en la Tabla 3.5, los requisitos de desempeño sean expresados
en términos cuantitativas. requisitos de rendimiento estáticos incluyen elementos
tales como el número de terminales para ser soportados; por ejemplo, “el sistema
deberá soporte 50 terminales de usuario.” Esto es similar a la categoría
“capacidades” en la Tabla 3.3. requisitos de rendimiento dinámico especifican
factores tales como el número de transacciones para ser procesados en un período
de tiempo dado; por ejemplo, “90% de las transacciones se completan en menos
de 1 segundo cuando 50 terminales de usuario son simultáneamente activa”, que
se clasifica como una restricción de diseño utilizando las categorías en la Tabla
3.3.
Las categorías de especificaciones técnicas en las Tablas 3.4 y 3.5 se pueden
organizar de diversas maneras en un documento de especificación de requisitos.
Especificaciones Técnicas para un sistema de procesamiento de datos científicos
pueden ser organizados por la lista de las funciones de entrada-salida del sistema
debe realizar en el nivel superior con otras categorías, tales como interfaces,
comportamiento, y el rendimiento especifican para cada función de entrada-
salida; un sistema de uso intensivo de usuario podría organizarse mediante la
especificación de ventanas, menús, y
Tabla 3.4 Categorías de las especificaciones técnicas

Descripción de categoría
InterfacesTo el medio ambiente y otros subsistemas
funciones pares de estímulo-respuesta
PerformanceResponse tiempo; rendimiento
BehaviorSequences de estados del sistema a través hora
CapacitiesData; comunicación; memoria
Diseño diseño constraintsPredetermined decisiones
Calidad attributesSafety; seguridad; confiabilidad; otros
Tabla 3.5 Requisitos específicos de la norma IEEE 830-1998

Específico RequirementsDescription
Externo interfacesInputs en y salidas desde el software sistema
FunctionsActions tomadas en la aceptación y entradas de procesamiento y
salidas de generación
Actuación requirementsStatic y dinámico requisitos cuantificados base de datos lógica
requirementsRequirements de información a ser colocados en un
base de datos
Diseño constraintsConstraints impuesta por la conformidad a las normas, las
limitaciones del hardware, etc.
Sistema de software attributesReliability; disponibilidad; seguridad; mantenibilidad;
portabilidad
www.it-ebooks.info
modos de interacción para cada interfaz de usuario con otras categorías de

requisitos subordinadas dentro de la especificación de interfaz; las
especificaciones técnicas de un sistema en tiempo real podrían ser organizados
por comportamientos. Anexo A de la norma IEEE 830 ™ -1998 ofrece varias
formas alternativas de organizar la información en las Tablas 3.4 y 3.5.
3.4.4 requisitos de verificación

En general, la verificación se ocupa de determinar el grado en que un producto de
trabajo satisface las condiciones y limitaciones impuestas sobre ella por otros
productos de trabajo y los procesos de trabajo. Esto significa que el producto de
trabajo debe ser completa, correcta, y consistente con respecto a otros productos
de trabajo y los procesos de trabajo. Hay tres áreas distintas de verificación de
requisitos:
1. la determinación de la integridad interna, la corrección, y la consistencia de
cada uno de requisito operacional y cada especificación técnica;
2. determinar que cada requisito operacional y cada una de las
especificaciones técnicas es externa completa, consistente y correcta con
respecto a los demás requisitos y productos de trabajo relacionados, tales
como planes de pruebas y escenarios de prueba; y
3. la determinación de la interna integridad, exactitud, y la consistencia de los
planes de pruebas relacionadas, escenarios de prueba y otros mecanismos
de verificación del producto final y de validación.
Las técnicas para la verificación de las propiedades internas de requisitos y docu-

mentos relacionados incluyen análisis, opiniones y tutoriales. La trazabilidad es
la téc- nica principal de establecer integridad externa, la corrección y la
coherencia entre estos cuatro documentos: (1) las necesidades operacionales
(objetivos de diseño y las restricciones de diseño operacionales), (2) las
especificaciones técnicas, (3) planes de verificación del producto final, y (4) los
planes de validación del producto final.
Tabla 3.6 es un ejemplo de una matriz de trazabilidad utilizado para establecer
correspondencias entre las características operativas priorizadas y los requisitos
principales en un técnicamente
TABLA 3.6 La trazabilidad de las características operacionales a los requisitos primarios

Requisitos primarias 
Características [P1] [P2] [P3] [P4] [P5] [P6]
operacionales 
[E1] x
[E2] x
[E3] x
[E4]
[D1] x
[D2] x
[D3]
[D4] x
www.it-ebooks.info
especificación de cal. requisitos primarios a menudo se expresan como

especificaciones de entrada-salida funcionales. Por ejemplo, la función de
consulta de saldo acepta un número de cuenta de usuario y devuelve la cantidad
de dinero en la cuenta; una solicitud de retiro acepta un número de cuenta de
usuario y una cantidad solicitada y devuelve un “sí” o la respuesta “no” (después
de activar la función de consulta de saldo, que se implementó por primera vez en
un proceso de desarrollo iterativo).
En la Tabla 3.6 característica operativa [E3], por ejemplo, está cubierto por
exigencia principal [P4]; características operativas [E4] y [D3] todavía no tienen
requisitos primaria correspondiente. Tenga en cuenta que en la Tabla 3.6 cada
función operativa se asigna a uno, y sólo uno, requisito principal; de lo contrario,
una característica operativa podría implementarse varias veces en el sistema.
características operativas E4 y D3 no tienen requisitos primarios
correspondientes; esto puede deberse a que el trabajo está en reso prog-, o puede
ser un descuido que debe ser corregido. atributos de calidad (por ejemplo, seguri-
dad de cuentas de usuario) pueden aplicarse a una, varias o todas las
características del sistema. Otras matrices de trazabilidad pueden utilizarse para
representar la asignación de atributos de calidad a las especificaciones técnicas.
Debido a las especificaciones técnicas proporcionan la base para todo lo que
sigue en un proyecto de software, es importante que sean completa, consistente y
correcta con respecto a las necesidades de funcionamiento, y que las
especificaciones técnicas proporcionan criterios objetivos para la verificación y
validación que cada requisito técnico se satisface con el código del sistema de
entrega. Matrices similares a la Tabla 3.6 se pueden utilizar para ilustrar la
correspondencia entre los requisitos operativos y planes ción validación y entre
las especificaciones técnicas y planes de verificación, así como entre los
requisitos primarios y requisitos derivados. requisitos derivados también deben
tener planes de verificación y validación objetivo para el cual las matrices de
trazabilidad son necesarios.
3.4.5 Gestión de requerimientos

El objetivo del desarrollo es establecer los requisitos de una línea de base inicial de
los requisitos funcional y las especificaciones técnicas, tal como se indica en la
Figura 3.2. la gestión de los requisitos se ocupa de la gestión de los cambios
posteriores en las necesidades de funcionamiento y las especificaciones técnicas y de
mantenimiento de esos cambios en equilibrio con la programación, presupuesto,
recursos, tecnología y otros factores del proyecto.
Dependiendo del alcance de su proyecto que puede o no puede ser responsable
por el desarrollo de la primera serie de requisitos; que pueden ser desarrollados y
se les da a usted como el punto de partida para su proyecto. Pero que sin duda
será responsable de la gestión de cambios en los requisitos de funcionamiento y
las especificaciones técnicas como evoluciona el proyecto. Los requisitos pueden
ser modificados mediante la adición, modificación y eliminación de las
necesidades operacionales, las limitaciones de diseño y las especificaciones
técnicas. Cada cambio de requisitos debe ir acompañada de un análisis de
impacto para determinar el efecto del cambio en la fecha prevista, el presupuesto,
los recursos, los atributos de calidad, la tecnología y otros factores. Análisis de
impacto puede determinar que el cambio propuesto es en su alcance, lo que
significa que puede ser manejado sin cambios a otros factores de proyecto o el
cambio puede estar fuera de alcance,
www.it-ebooks.info
3.4 REQUISITOS DE INGENIERÍA 107
Las líneas de base y las Juntas de Control de Cambio Las líneas de base y las
tarjetas de control de cambio son los principales mecanismos utilizados para la
gestión de requisitos. Una línea de base es un producto de trabajo que se coloca
bajo el control de versión y no puede ser modificado aún más con la aprobación
de un tablero de control de cambio (CCB). Un CCB se compone de uno o más
individuos que tienen la autoridad para realizar cambios en los requisitos y hacer
los ajustes correspondientes para programar, presupuesto, recursos, y / o
tecnología, según sea necesario.
En un proyecto pequeño, usted (como administrador de proyectos y
desarrollador principal) y su al cliente central puede ser los únicos miembros de
la CCB. En un proyecto grande, el CCB puede incluir que un adquirente, que
representa a un grupo de clientes (o tal vez un gerente de mercado ing), y
representantes de su análisis y diseño de equipo, los equipos tación y validación
aplica- thesupport, equipos y mantenimiento , y las partes interesadas
otherconcerned.
En un proyecto a nivel de sistema o programa, el CCB puede ser subordinada
a la CCB sistema. En ese caso, usted y su arquitecto jefe de software debería ser
miembros de esa placa de control. Para ser eficiente y eficaz, la pertenencia CCB
debe incluir aquellos individuos que tienen la autoridad para hacer cambios y que
son directamente responsables de la entrega de un sistema aceptable a tiempo y
dentro del presupuesto.
Un diagrama de flujo de proceso para un CCB desarrollo de software se ilustra
en la figura
3.4. La línea de base inicial de un producto de trabajo (por ejemplo, las
especificaciones técnicas) es creado en virtud del proceso de revisión y aceptación
que determina (por lo menos, algunos de) los requisitos son una base adecuada (una
línea de base) para más actividades de trabajo.
Aprobad Aceptar y negociar CCB

o el proye
cambio Trabajo cto
Producto Negociación
Versión 0. N
Hacer - Negar
cambio - Aplazar Análisis
- Aceptar de
impacto
verific
ar
cambioVersión 0.N + 1
de Producto de CR y RP
Trabajo
- usuar
cambio
ios
comunicada
- Clientes
Línea - Márketing
Las líneas de base se
Base - Desarrolla
establecen mediante un
inicial dores
proceso de revisión y
aceptación
Figura 3.4 flujo de proceso para un BCC desarrollo de software
Una vez establecida, una línea de base se cambia por una de dos razones:
1. debido a un cambio solicitado al producto del trabajo o
www.it-ebooks.info
2. debido a un defecto en el producto de trabajo.
www.it-ebooks.info
Los cambios solicitados se presentan como CRS (solicitudes de cambio). Los

defectos en un producto de trabajo se documentan en RP (Informes de
problemas). Como se indica en la Figura 3.4, un CR o DR pueden ser presentadas
por cualquier de las partes interesadas en cuestión.
La primera actividad durante el análisis de impacto es determinar si la
solicitud presentada ya se ha recibido. En este caso, el remitente es notificado de
la situación del cambio solicitado. Análisis de impacto para un nuevo CR o PR se
lleva a cabo para determinar mina si el cambio propuesto es en alcance o fuera de
alcance; en este último caso se desarrolla una estimación de esfuerzo y recursos
para implementar el cambio. En ambos casos, se facilita una prioridad
recomendado para el cambio.
El CCB (que incluye, el director del proyecto como miembro y tal vez la silla)
debe tener la autoridad para aceptar el cambio propuesto con una designa- ción
prioritaria, aplazar la solicitud (tal vez para la próxima versión del producto), o
para denegar la solicitud. Aplazamiento o denegación de una solicitud de cambio
puede implicar la negociación con el remitente de la solicitud. La aceptación de
la solicitud de cambio puede implicar algún tipo de negociación con los
desarrolladores, que debe incorporar el cambio en sus actividades de trabajo si la
solicitud es en su alcance o modifiquen sus horarios de actividades de trabajo,
con su consentimiento, si el cambio está fuera de alcance. Los grandes cambios
fuera del alcance pueden requerir mayor replanificación del proyecto.
Si la solicitud es aceptada y el cambio negociado, se le asigna el trabajo, el
cambio se realiza y se verificó que ser completa, correcta y consistente, y se
genera una nueva versión de la línea de base del producto de trabajo. El paso
final es asegurar que todas las partes afectadas son notificados de la nueva línea
de base del producto de trabajo y los cambios resultantes de tramitación de la
solicitud de cambio.
El CCB se basa en un proceso de gestión de la configuración (CM), que
implica el uso de una herramienta de control de versiones, para mantener las
versiones actuales de los productos de trabajo, para proteger productos de trabajo
contra cambios no autorizados, para proporcionar auditorías de configuración, y
para proporcionar informes de tendencias. Figura 3.5 ofrece un ejemplo de un
informe de tendencia que pudiera ser proporcionado por el proceso de CM. En el
desarrollo iterativo del proceso de CM también puede implicar la integración
sistemática de los módulos de código en evolución en la base cada vez mayor, el
control de la línea de base de código, y el informe de progreso.
Figura 3.5 proporciona un ejemplo de varias tendencias en el seguimiento de
baselined requisitos:
En primer lugar, tenga en cuenta que el “perfil estable” para el número de
requisitos baselined parece haberse estabilizado en 200; Sin embargo, la
tendencia está etiquetada como “perfil estable?”, ya que, como se puede
observar, el número acumulado de los cambios de requisitos indica que ha habido
unos 65 cambios en los 200 requisitos. La preocupación es si estos cambios han
sido acompañados con los cambios correspondientes en el horario, presupuesto,
recursos y tecnología, según sea necesario para acomodar los cambios. Si es así,
los requisitos, a pesar de tener sufrido muchos cambios, están en equilibrio con
los requisitos de base actual. Si no es así, el proyecto está en serios problemas
debido a la programación, presupuesto, recursos, y la tecnología se basan en un
conjunto de requisitos obsoletos.
En segundo lugar, cabe destacar que el “perfil inestable” también es
cuestionada. Una vez más, la cuestión es si los cambios apropiados en otras
variables del proyecto se han realizado (es decir, el calendario, el presupuesto, los
recursos y la tecnología). Si es así, el proyecto es estable; si no, el proyecto es
www.it-ebooks.info
inestable.
En tercer lugar, cabe destacar que en un principio 150 requisitos se marcaron
como objetivos de diseño, lo que significa que no hay mecanismos de
verificación o validación objetiva se asociaron
www.it-ebooks.info
3.5 FUNDAMENTOS DE PROCESO109
# De # De las nuevas
perfil
requisitos exigencias
baselined inestabl
e?
250 perfil 100
estable
?
200 80
150 60
# De objetivos de
100 diseño 40
50 # De los 20
requerimientos no
identificados
0
primero Qtr2nd 3er 4to HORA

qtr trim trim
FIGURA 3.5 informe de tendencias para los requisitos baselined
con esos requisitos. Como puede verse, a unos 100 objetivos de diseño se han
convertido en requisitos objetivamente estipuladas; sin embargo, 50 permanecen
a convertir. Como se comentó anteriormente, puede que no sea posible convertir
todos estos objetivos de diseño en cuenta los requisitos establecidos
objetivamente, por ejemplo, como el requisito operacional para el “mejor sistema
de inventario del mundo.”
En cuarto lugar, el número de requisitos no identificados se ha reducido de
100 a 25. Las tendencias indican que la conversión de los objetivos de diseño y
trazabilidad son procesos en curso.
En resumen, un BCC:
• identifica los productos de trabajo para ser colocado bajo control de versiones;
• aprueba líneas de base iniciales de estos productos de trabajo;
• evalúa los cambios propuestos a las líneas de base, aprueba, aplaza, o
rechaza las propuestas de cambio;
• ajusta cronograma, presupuesto, recursos y tecnología para adaptarse a los
cambios aprobados;
• horarios y seguimiento de los cambios a la terminación;
• analiza las tendencias de cambio y responde según el caso; y
• tiene la autoridad para llevar a cabo estas tareas.
El control de versiones, tableros de control de cambios, y el análisis de

tendencias se han presentado en el contexto de la gestión de requisitos; Sin
embargo, los mismos procesos se aplican a la gestión de configuración de todos
los productos de trabajo baselined.
3.5 FUNDAMENTOS DE PROCESO
Como se indica en la Tabla 3.1, las fundaciones de proceso para proyectos de

software incluyen el modelo de flujo de trabajo, el modelo de desarrollo, el
acuerdo contractual, y el proyecto
www.it-ebooks.info
plan. El modelo de flujo de trabajo se presentó en el Capítulo 1, la Figura 1.1.

Selección y adaptación de un modelo de desarrollo fue presentado en el capítulo
2. En la siguiente sección se presentan las consideraciones de alcance y el
acuerdo contractual. El formato y contenido de los planes de gestión de proyectos
de software se presentan en el Capítulo 4.
3.5.1 Especificando el alcance de su proyecto

fundaciones de productos (requisitos operacionales, requisitos del sistema straints
con- diseño y requisitos de software) determinan el alcance del trabajo a ser
plished acompa- en un proyecto. El alcance de su proyecto puede implicar el
desarrollo de hardware y software y la formación del personal de operaciones, o
puede ser un proyecto “de sólo software”. En el primer caso, su proyecto de
software puede estar subordinada a un proyecto de Sistemas de nivel que tiene
varios sub-proyectos, incluyendo el suyo (proyectos de desarrollo a nivel de
sistema a veces se llaman programas de desarrollo). En este último caso (sólo
software), su proyecto puede estar afiliado a otros proyectos y por lo tanto
requiere la coordinación de sus actividades de trabajo con los otros proyectos, o
su software único proyecto puede ser un “stand-alone” que tiene un alto grado de
autonomía.
Incluso en el caso de los autónomos sólo de software proyecta las exigencias
del sistema en general deben determinarse. Como mínimo, el software
suministrado funcionará en una plataforma de hardware y, en la mayoría de los
casos, en el entorno del software del sistema (por ejemplo, los conductores de E /
S y un planificador de procesos, o un sistema operativo con todas las
características). El entorno ware y software para el desarrollo de hardware puede
ser diferente del entorno de operación, por ejemplo, si está desarrollando
software embebido utilizando un ordenador anfitrión y descargar el software en
un equipo de destino. El hardware y el software para ser utilizado en el desarrollo
de un sistema puede enunciarse como las restricciones de diseño (lo más
probable) o que pueden tener la libertad de elegir los mejores entornos de
desarrollo y de operación para el sistema (menos probable).
El alcance de algunos proyectos de software de sólo implica trabajar con los
usuarios, clientes, adquirente, y otras partes interesadas para desarrollar los
fundamentos del proyecto, la construcción de una solución de software, entregar
e instalar el sistema resultante, entrenar a los usuarios, y proporcionar apoyo
continuo durante un período determinado de tiempo. Otros proyectos pueden
comenzar una vez que se han establecido los requisitos y terminar con la
validación de la aceptación del producto entregado. Y otros pueden implicar la
modificación de una versión existente de un sistema para producir una próxima
versión.
3.5.2 El acuerdo contractual

El alcance del proyecto puede ser documentada en un acuerdo contractual. En
general, un contrato es una declaración de entendimiento entre las dos partes. El
acuerdo puede ser formal o informal. Un acuerdo formal es un contrato legal
entre su organización y la organización de la entidad adquirente. Un acuerdo
informal es una declaración de entendimiento entre usted, el director del
proyecto, y un cliente interno. acuerdos contractuales informales para proyectos
de software se documentan en memos de entendimiento (MOU). MOU son
apropiadas para proyectos internos cuando el proyecto de software se lleva a
cabo por otras unidades de su organización o tal vez en otros, dentro de su
www.it-ebooks.info
unidad.
contratos formales son documentos que incluyen consecuencias de obligado
cumplimiento para ambas partes legalmente vinculantes si cualquiera de las
partes debe violar los términos del contrato.
www.it-ebooks.info
3.5 FUNDAMENTOS DE PROCESO111
Son apropiados cuando su organización y la organización adquisición son

entidades distintas y dinero debe ser pagado al proveedor (su organización) por la
organización compradora. En este caso los elementos de un acuerdo contractual
se anexan a un contrato formal en la forma de una Declaración de Trabajo
(SOW). El acordados a los requisitos operativos y las especificaciones técnicas se
adjuntan a, y son por lo tanto son parte de un contrato formal; sin embargo, sólo
las características técnicas deben ser legalmente vinculante. En los casos en que
no se han desarrollado las especificaciones técnicas, el contrato debe contener
una advertencia de que los requisitos operacionales no son vinculantes y que las
especificaciones técnicas basadas en las necesidades de funcionamiento serán
negociados y aceptados por adquirente y proveedor.
Los productos que normalmente contenidas en un acuerdo contractual
incluyen:
• ámbito de trabajo
• productos de trabajo entregables
• fechas de entrega)
• cliente / usuario y el desarrollador se unen calendario de revisión
• procedimientos de solicitud de cambio
• limitaciones para el desarrollo
• criterios de aceptación del producto
• elementos adicionales, según corresponda
El ámbito de trabajo incluye todas las principales actividades de trabajo que

deben ser plished acompa- para entregar un producto satisfactorio, por ejemplo,
gestión de proyectos, análisis, diseño, implementación, verificación y validación;
actividades como la formación de los usuarios, proporcionando soporte para la
evolución del sistema después del parto, y las actividades de trabajo similares
serían incluidos en su caso. Los productos de trabajo entregables pueden incluir
sólo el código objeto o código objeto y de referencia y materiales de formación, o
también pueden incluir el código fuente y el conjunto de pruebas, según lo
negociado entre el cliente y el desarrollador (o adquirente y proveedor).
Puede haber más de un acordada a fecha de entrega como, por ejemplo, en el
caso de la entrega inicial de una o más capacidades de subconjuntos para ser
seguido por la entrega del sistema completo. Las fechas de entrega se pueden
especificar como las fechas del calendario o el tiempo transcurrido desde el inicio
del proyecto, el primero es preferible porque suena más definida. Las revisiones
conjuntas entre el cliente / usuario y desarrollador (o adquirente y proveedor)
pueden variar desde las revisiones principales hitos en un proceso de desarrollo
en cascada, a las revisiones frecuentes en un proceso incremental y construcción,
a las interacciones diarias en un proceso ágil.
Dado que el cambio es inevitable en proyectos de software, un mecanismo tal
como el diagrama de flujo de obra para solicitudes de cambio ilustradas en la
Figura 3.4 y un CCB tal como se describe en la Sección 3.4.5 anterior debe ser
aceptado por el cliente y el revelador (o adquirente y proveedor). Las
limitaciones del desarrollo pueden incluir restricciones del proceso impuestas por
el cliente, como el uso de un proceso incremental a la generación que incorpora
demostraciones frecuentes del progreso y la entrega temprana de las
capacidades de subconjunto, o las limitaciones del producto, tales como la
plataforma de hardware, sistema operativo, o la instalación de bases de datos para
ser utilizado. Los criterios de aceptación del producto deben indicarse de manera
www.it-ebooks.info
objetiva para que ambas partes se ponen de acuerdo cuando el producto se ha
completado satisfactoriamente.
www.it-ebooks.info
Los elementos adicionales (por ejemplo, un horario para la formación de

usuario) pueden ser incluidos como appro- piado. En los casos de relaciones
formales entre adquirente y proveedor, elementos tales como el precio, el
calendario de pagos, derechos de datos, y las consecuencias del incumplimiento
de los términos contractuales se harán constar en el contrato formal. Los artículos
enumerados anteriormente se incluirán en la declaración de trabajo, que será un
elemento del contrato.
Cada proyecto de software debe tener un acuerdo contractual en forma de un
memorando de entendimiento (MOU) para los acuerdos contractuales informales
o una Declaración de Trabajo (SOW) para los contratos formales. Algunos
elementos de un acuerdo contractual, pueden ser las limitaciones del proyecto,
por ejemplo, la fecha (s) de entrega y desarrollo limitaciones. Otros artículos
pueden ser completados sólo después de una fase inicial de planificación, por
ejemplo, el alcance del trabajo y los criterios de aceptación del producto. El
MOU o DS se modificarían en ese punto.
Algunas organizaciones utilizan formularios de autorización del proyecto (a
veces llamadas “órdenes de trabajo del proyecto” o “las cartas de proyecto”) para
lanzar oficialmente un proyecto de software. El MOU o DS deben formar parte
del documento de autorización del proyecto, si es que existe.
• proyectos de software tienen cuatro tipos de bases de productos y cuatro

tipos de bases de proceso.
• Requisitos de software incluyen requisitos operativos y las especificaciones
técnicas.
• Los requisitos operativos incluyen características operativas, los atributos de
calidad, las limitaciones de diseño.
• Especificaciones técnicas incluyen requisitos primarios, requisitos derivados,
objetivos de diseño, y las restricciones de diseño cuantificados.
• Los objetivos de diseño son los requisitos operativos que no han sido, o no
pueden, traducidos a las especificaciones técnicas.
• Las principales actividades de desarrollo son requisitos elicitación de
requisitos funcional, el análisis, la traducción a las especificaciones
técnicas y de línea de base la aceptación de las especificaciones técnicas.
• La gestión de requisitos tiene que ver con el control de la línea de base de los
requisitos y con el mantenimiento de la coherencia entre los requisitos, el
esfuerzo, programación, presupuesto, y la tecnología.
• Gestión de la configuración, que incluye el control de versión, una tabla de
control de cambio (CCB), y los informes de estado, es el principal
mecanismo de gestión de requisitos.
• Las especificaciones técnicas se pueden clasificar de varias maneras, y por lo
general incluyen interfaces, funciones, rendimiento, comportamiento,
capacidades, limitaciones de diseño y atributos de calidad
• Un acuerdo contractual incluye elementos tales como el alcance del trabajo a
ser plished acom-, productos de trabajo entregables, las limitaciones de
desarrollo, y los criterios de aceptación del producto
www.it-ebooks.info
Referencias 113
• Cada proyecto debe tener un acuerdo contractual. acuerdos contractuales

informales se denominan memos de entendimiento (MOU). acuerdos
contractuales formales se denominan Declaraciones de trabajo (SOW)
• SEI, ISO, IEEE, y PMI proporcionan marcos, normas y directrices perti-
nente para el establecimiento de bases del proyecto (véase el Apéndice 3A a
este capítulo)
Referencias
[ACQ07] CMMI para Adquisición, Versión 1.2 Modelo. http://www.sei.cmu.edu/

publicaciones / documentos / 07.reports / 07tr017.html.
[Boehm81] Boehm, B. Economía Ingeniería de Software. Prentice Hall, 1981. [CMMI06]
CMMI® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[CMMIAM05] Módulo de Adquisición CMMI (CMMI-AM), versión 1.1. http: //www.sei.cmu.
edu / publicaciones / documentos / 05.reports /
05tr011.html.
[CMMSA02] Software de Adquisición de Modelo de Madurez, versión 1.03,
http://www.sei.cmu.edu/ brazo / SA-CMM.html de 2002.
[COHEN95] Cohen, L. Despliegue de la función de calidad. Prentice Hall, 1995.
[DAVIS03] Davis, A. El arte de los requisitos de triaje. IEEE Computer, marzo de
2003.
[HAYES03] Hayes, J. La construcción de una taxonomía de fallos requisito: Experiencias
de un proyecto de investigación de la verificación y validación de la
NASA. Actas del Simposio IEEE Nacional Interinstitucional sobre
Software Ingeniería de Confiabilidad (ISSRE). Denver, CO, noviembre de
2003 IEEE Computer Society.
[IEEE830] IEEE Std 830 ™ -1998. IEEE Práctica Recomendada para Software
REQUISITOS DE Especificaciones. IEEE Software Engineering
Standards Collection. IEEE SE113 del producto. Instituto de Ingenieros
Eléctricos y Electrónicos, agosto de 2003.
[IEEE1362] IEEE Std 1362 ™ -1998. Guía de IEEE para Tecnología de la Información del
Sistema-Definición-Concepto de Operaciones (CONOPS) del documento.
Ingeniería de software Normas Colección. IEEE SE113 del producto. Instituto
de Ingenieros Eléctricos y Electrónicos, agosto de 2003.
ingeniería. IEEE SE113 del producto. Instituto de Ingenieros Eléctricos y
[LEFF03] Leffingwell, D., y D. Ledwig. Gestión de Requisitos de software: un enfoque de
casos de uso. Addison-Wesley, 2003.
[MIND95] El Método Delphi, Herramientas de la Mente, 1995.
http://www.mindtools.com/pages/ Artículo / newTMC_95.htm.
[ROBERT06] Robertson, S., y J. Robertson. Masteringthe requisitos del proceso. Addison-
Wesley, 2006.
[RUMB98] Rumbaugh, J., I. Jacobson, y G. Booch. El Lenguaje de Modelado Unificado
Manual de Referencia. Addison-Wesley, 1998.
[SAATY05] Saaty, T. Teoría y Aplicaciones del proceso analítico de red: toma de decisiones
con los beneficios, oportunidades, costos y riesgos. RWS Publications, 2005.
[] WEIGER03 Weigers, K. Requisitos de software. Microsoft Press, 2003.
www.it-ebooks.info
CEREMONIAS
3.1. CMMI-DEV-v1.2 enumera las siguientes áreas de procesos relacionados

sobre las áreas de procesos de gestión de requisitos de desarrollo y
requisitos Ment:
Proceso de validación
proceso de solución de
planificación de
proyecto técnico
Producto Integración
Verificación
Seguimiento de Proyectos y
Gestión de Riesgos Gestión de
la Configuración de Control
Acceder al sitio Web en CMMI

http://www.sei.cmu.edu/publications/documentos / 06.reports / 06tr008.html.
Revisar las áreas de proceso Requisitos para el desarrollo y la gestión de los
requisitos, y explicar brevemente cómo cada una de las áreas de procesos
relacionados con ellos se relacionan con el desarrollo y gestión de requisitos
Requisitos.
3.2. Explicar brevemente por qué es importante que cada requisito operacional
ser declarado como asimple statementthatcontains declarativas no “ands”,
“ORS”, “si” o “peros”.
3.3. Dado un conjunto de requisitos operacionales, describir brevemente las
técnicas que usaría para determinar qué requisitos para colocar en cada una
de las categorías: Esenciales, deseable y opcionales.
3.4. Explique brevemente por qué es deseable para categorizar las especificaciones
técnicas que utilizan las categorías en la Tabla 3.4 o 3.5.
3.5. Indique brevemente cómo se organizan las categorías de las
especificaciones técnicas en la Tabla 3.4 para un proyecto de desarrollo
orientado a objetos.
3.6. Brevemente dar algunas razones por las que podría ser preferible utilizar el
tiempo transcurrido en lugar de las fechas del calendario en un acuerdo
contractual.
3.7. Cada característica operativa debe asignar a una y sólo una exigencia
principal. atributos de calidad se pueden aplicar a una, varias o todas las
exigencias principales. Proporcionar un ejemplo de:
a. un atributo de calidad que se asigna a un único requisito principal en un
sistema acoplado Auto Teller. Indicar el atributo de calidad y la
exigencia primaria correspondiente.
b. un atributo de calidad que se asigna a algunas, pero no todas las
exigencias principales en un sistema de caja automatizada. Estado del
atributo de calidad y los requisitos principales correspondientes.
c. un atributo de calidad que se asigna a todas las exigencias principales en
las especificaciones técnicas de un sistema de caja automatizada.
Para cada uno de los siguientes ejercicios, formar un pequeño equipo (tres o
www.it-ebooks.info
cuatro miembros). Realizar estos ejercicios solo, si no es posible formar un
equipo.
www.it-ebooks.info
CEREMONIAS 115
Una unidad de control principal (HCU) consta de un servidor, una interfaz

fácil de usar, y numerosos dispositivos periféricos de diversos tipos. Un
HCU puede incluir diversas instalaciones, tales como la vigilancia,
seguridad y control programable de los dispositivos de entretenimiento y de
comunicación, aparatos de cocina, y sistemas de rociadores.
3.8. Llevar a cabo un ejercicio de reflexión para desarrollar características
operativas 10 y 5 atributos de calidad para una HCU.
3.9. Identificar tres tipos de actores para una unidad de control principal y
describen brevemente cómo interactuarían con, o verse afectadas por,
HCUs individuo y la introducción de HCUs en la comunidad local.
3.10. Estado cinco requisitos operacionales para una HCU que siempre sería
objetivos de diseño; es decir, no es probable que pudieran ser, o sería,
convertida en especificaciones técnicas.
www.it-ebooks.info
ANEXO 3A
Marcos, estándares y directrices

para FUNDAMENTOS DE
PRODUCTOS
3A.1 LA CMMI-DEV-v1.2 áreas de proceso PARA LOS REQUISITOS DE

DESARROLLO Y GESTIÓN DE REQUISITOS
El marco de proceso de CMMI-DEV-v1.2 incluye el desarrollo de los requisitos

como un nivel-3 de proceso y gestión de requisitos por etapas como un nivel-2
proceso por etapas [CMMI06]. El propósito, metas específicas y los procesos
relacionados con el desarrollo de requisitos, como se indica en CMMI-DEV-v1.2,
son los siguientes:
El propósito del desarrollo Requisitos (RD) es producir y analizar al cliente,

producto y requisitos de los componentes del producto.
SG 1 Desarrollar los requisitos del
cliente SP 1.1 Necesidades
provocan
SP 1.2 Desarrollar los requisitos del cliente
del SG 2 Desarrollar Requisitos del producto
SP 2.1 Establecer de productos y componentes de productos
Requerimientos SP 2.2 Asignar Requisitos de los componentes
del producto
SP 2.3 Identificación de los requisitos de
interfaz SG 3 Analizar y Requisitos Validar
SP 3.1 Establecer los conceptos operacionales y
escenarios SP 3.2 establecer una definición de Las
funcionalidades SP 3.3 Analizar los requisitos
SP 3.4 Analizar los requisitos para lograr el
equilibrio SP 3.5 Requisitos Validar
áreas de procesos
relacionados: Requisitos de
la solución de Gestión
Técnica
Producto proceso
de validación del
proceso de
integración de
www.it-ebooks.info
Verificación
116
www.it-ebooks.info
3A.2 FUNDAMENTOS DE PRODUCTOS EN ISO / IEC e IEEE / EIA NORMAS 12207 117
Gestión de la Configuración
de Gestión de Riesgos
El término “cliente” en CMMI incluye tanto los clientes y usuarios como estos
términos se utilizan en este texto.
El propósito, metas específicas y los procesos relacionados con la gestión de
requisitos, como se indica en CMMI-DEV-v1.2, son los siguientes:
El propósito de la gestión de requisitos (REQM) es para gestionar los requisitos de

los productos del proyecto y componentes de productos e identificar inconsistencias
entre los requisitos y los planes del proyecto y productos de trabajo.
SG 1 gestionar los requisitos de
SP 1.1 Obtener una comprensión de los requisitos
SP 1.2 Obtener el compromiso con los Requisitos
SP 1.3 Requisitos gestionar los cambios
SP 1.4 Mantener bidireccional trazabilidad de los requisitos
SP 1.5 Identificar las inconsistencias entre el trabajo y los requisitos del proyecto
áreas de procesos relacionados:
Requisitos de la solución de
desarrollo técnico
Gestión de la Configuración
de Planificación de
Proyectos
Seguimiento de Proyectos y
Gestión de Riesgos de Control
3A.2 FUNDAMENTOS DE PRODUCTOS EN ISO / IEC e IEEE / EIA

NORMAS 12207
Las normas 12207 enfatizan la relación entre comprador y proveedor, así como el
papel de la entidad adquirente y el papel del proveedor en una relación
contractual [IEEE12207]. Como se ilustra en la figura 2 de IEEE estándar EIA /
12.207,2-1997, el adquirente debe desarrollar:
• los requisitos del sistema,

• el plan de adquisición,
• los criterios de aceptación, y
• una solicitud de propuestas (RFP).
Los proveedores potenciales deben tomar una decisión de compra y preparar una
respuesta; si es seleccionado, el proveedor prepara un plan de proyecto.
Como se indica en la Sección 5.3 de 12.207,0, actividades relacionadas con el
establecimiento de las bases técnicas del proyecto del proveedor incluyen:
• análisis de los requisitos del sistema,

• sistema de diseño arquitectónico, y
• análisis de los requisitos de software.
www.it-ebooks.info
En este capítulo se refiere predominantemente a establecer las bases de productos

para un proyecto de software. El formato y contenido de la norma 1058 de planes
de gestión de proyectos de software (una fundación proceso) se presentan en el
Capítulo 4.
Sección 1.3.3, de la Guía de los Fundamentos de la Dirección de Proyectos

(Proyectos y Planificación Estratégica) [] PMI04 estados que los proyectos se
llevan a cabo típicamente para alcanzar los objetivos estratégicos y por lo general
están autorizados como resultado de:
• una demanda de mercado,

• una necesidad de organización,
• una solicitud del cliente,
• un avance tecnológico, o
• un requisito legal.
Otros elementos del PMBOK que se relacionan con la iniciación del proyecto
incluyen el desarrollo de una carta del proyecto y una declaración del alcance del
proyecto. La carta del proyecto es el documento zación autori- para el proyecto.
El alcance del proyecto define, en un nivel alto, las actividades de trabajo del
proyecto y productos de trabajo entregables, los métodos que se utilizan en el
control del proyecto, y los métodos de la aceptación del producto.
www.it-ebooks.info
4
PLANES Y PLANIFICACIÓN
Un plan en la mente de un hombre no es un plan.

-Richard H. Thayer
4.1 Introducción al proceso de planificación
Por definición, todos los proyectos de todo tipo es una tarea de duración limitada
que utiliza los recursos para lograr los objetivos establecidos. Un plan de
proyecto especifica, entre otras cosas, la duración del proyecto, los recursos
necesarios, y cómo se aplicarán los recursos para lograr los objetivos
establecidos. Requisitos de software (que se analizan en el Capítulo 3)
proporcionan los objetivos para el producto a ser desarrollado o modificado. El
proceso de planificación tiene que ver con el desarrollo de los diversos elementos
de un plan de proyecto y documentar el plan en un formato especificado.
Su plan de gestión de proyectos de software debe ser un documento escrito; de
otro modo, las diversas partes interesadas en el proyecto tendrán diferentes
interpretaciones de cómo se llevará a cabo el proyecto, y no habrá ninguna
documentación de los planes de esfuerzo, costos, plazos, recursos y actividades
de apoyo. El plan del proyecto también proporciona un vehículo para los estudios
de comercio y para la negociación de compensaciones entre costo, horario, y
requisitos, tanto inicialmente como cuando se producen cambios. control de la
línea de base del plan de proyecto escrito soporta actualización sistemática del
plan y la comunicación de los cambios.
En el mejor de los casos, el proceso de planificación se iniciará con la
adaptación de los procesos estándar de su organiza- ción para adaptarse a la
gestión, desarrollo de software, y apo- procesos de portabilidad de su proyecto.
En ese caso, la información de este capítulo se puede utilizar como una lista de
control contra el cual se puede comparar los procesos de planificación de su
organización y plantillas de documentos.

119
www.it-ebooks.info
120 PLANES Y PLANIFICACIÓN
Empieza
aqui requisitos
Proceso de
y limitaciones
desarroll
o
ón y Definició Verificación aquí
n de las ciones y Validación
Los gestores replanifica de
ción Actividad
es trabajo entregar
directivas y Seguro de
restricciones calidad producto
Re-estimar trabajo
administración
Retenció
n de Otros
datos procesos
de apoyo
FIGURA 4.1 Un modelo de flujo de trabajo para proyectos de software
En el peor de los casos, tendrá que desarrollar su plan de proyecto sin ningún
tipo de estructuras orga- nizational o directrices. En ausencia de estructuras y
pautas de organización, el modelo de flujo de trabajo para la gestión de proyectos
de software presenta en la figura
1.1 (Se repite aquí como Figura 4.1), el modelo de ingeniería del sistema
presentado en la figura 2.1b, y los modelos de desarrollo y procesos de apoyo que
se describen en el Capítulo 2, más la información de este capítulo pueden
proporcionar un marco tailorable de planificación y ejecución de proyectos de
software.
La planificación del proyecto, al igual que todos los elementos de desarrollo de
software, se logra mejor manera iterativa; se añaden detalles a medida que crece
la comprensión.
• el proceso de planificación para proyectos de software

• el área de proceso de planificación de proyectos de CMMI-DEV-v1.2
• un enfoque para la planificación de proyectos ágiles
• una plantilla para los planes de gestión de proyectos de software (SPMPs)
• la adaptación de la plantilla PAPS
• técnicas para preparar un SPMP
El proceso de planificación presentada en este capítulo es informado por el área de

proceso de Planificación de proyecto del marco de proceso de CMMI-DEV-v1.2, los
elementos de planificación de la ISO y los estándares de IEEE 12207, el estándar
IEEE 1058, y el Cuerpo de PMI El conocimiento. Estos elementos se describen en el
Apéndice 4A a este capítulo. Una versión anotada de la norma IEEE 1058 se presenta
en el Apéndice 4B.
Una copia electrónica de la versión anotada de la norma IEEE 1058,
presentación de diapositivas para este capítulo, y otros materiales de apoyo están
disponibles en la URL que aparece
www.it-ebooks.info
4.3 EL PROCESO DE PLANIFICACIÓN
121
en el prefacio de este texto. Los términos utilizados en este capítulo y en todo

este texto se definen en el glosario al final del texto. Mecanismos y técnicas de
planificación y estimación de proyectos se presentan en los capítulos 5 y 6 de
este texto.
Como se muestra en el modelo de flujo de trabajo de la figura 1.1 en el Capítulo

1 de este texto, que se repite aquí como Figura 4.1, las entradas a la planificación
incluyen requisitos y limitaciones del cliente como las directivas de gestión así y
limitaciones. Los requisitos del sistema, el diseño del sistema, y los requisitos de
software también pueden estar disponibles o son desarrollados durante el inicio
del proyecto. Como se discutió en el Capítulo 3, los requerimientos del cliente
incluyen características operativas, los atributos de calidad, y las limitaciones de
diseño para el producto sioned bientes. Restricciones impuestas por el cliente
pueden incluir tanto el producto como restricciones del proceso.
Una restricción producto podría requerir que el sistema se ha desarrollado
utilizando una versión cado speci- de un sistema operativo o que el sistema nuevo
o modificado proporciona una interfaz SQL para una base de datos existente. Una
restricción proceso podría requerir que el sistema se entrega en una secuencia de
etapas de las capacidades crecientes o que el código fuente del software
entregable más los requisitos y documentación de diseño será entregado a un
agente independiente para la verificación final y validación.
directivas de la administración pueden incluir una declaración de política que
todos los proyectos deben presentar documentación de proyectos y verificar que
esté completa, la exactitud, consistencia y el uso de revisiones por pares. Una
restricción de gestión podría limitar sus recursos del proyecto a una plantilla de
10 desarrolladores de software.
Algunas de sus primeras tareas como jefe de proyecto son establecer un patrón
de comunicación permanente con el representante designado por el cliente (el
principal punto de contacto), y aclarar con él / ella / ellos las necesidades de
funcionamiento, limitaciones desarrollos ción, y criterios de éxito Para el
proyecto.
Como se indicó en el capítulo 3, cada requisito operacional debe ser priorizado
como esencial, deseable u opcional para facilitar el logro de un equilibrio entre
los requisitos, el cronograma y presupuesto. tiempo y recursos suficientes deben
ser proporcionados a implementar todos los requisitos esenciales y, como muchos
de los requisitos deseables según lo deseado por el cliente.
Dependiendo de la naturaleza y el alcance de su proyecto, aclarando los
requisitos operativos y de desarrollo de los requisitos del sistema, la arquitectura
del sistema, y los requisitos de software puede ser su tarea. Como alternativa,
puede delegar a uno o más miembros de su equipo de planificación, o puede
proporcionarse como el punto de partida para el proceso de planificación.
Su comprensión de los requisitos operativos y de desarrollo straints con-
influirá en su elección del modelo de desarrollo que se utilizarán y los
procedimientos a seguir. Las consideraciones incluyen:
• Desarrollo de un sistema de uso intensivo usuario puede requerir la creación

de prototipos para aclarar los requisitos operativos y proporcionar
información para el diseño de la interfaz de usuario.
• El desarrollo del software para un sistema integrado puede requerir la
www.it-ebooks.info
partici- pación de usted y su líder técnico en el equipo de ingeniería de
sistemas.
www.it-ebooks.info
• Desarrollo de la entrega por etapas de las capacidades del sistema en base a

los requisitos estables y una arquitectura estable puede indicar que una
estrategia gradual de construcción es apropiado.
• Desarrollo de una primera de su tipo, el sistema puede requerir una estrategia
de desarrollo evolutivo.
• Un proceso ágil puede ser apropiado para el desarrollo y Realce ción
continua de una aplicación basada en Web o en los casos en que los
requisitos están en evolución ING o cambiando rápidamente.
Los modelos de desarrollo se presentan en el Capítulo 2.

Un cliente externo (el adquirente) por lo general se especificará la cantidad de
dinero y el tiempo disponible para el proyecto, que puede tener que ser
negociados para lograr un equilibrio con los requisitos. Un cliente interno puede
o no puede proporcionar dinero y / o los recursos para el proyecto, pero, sin duda,
especificar una restricción de horario para la finalización del proyecto, que puede
tener que ser negociados. En cualquier caso, un acuerdo contractual en forma de
una declaración de trabajo o un memorando de entendimiento que contiene
elementos tales como los enumerados en el apartado 3.3.2 de este texto debe ser
negociado y aceptado por usted y su cliente. Otras actividades de planificación
incluyen el establecimiento de una línea de base inicial de los requisitos, la
preparación de las estimaciones, y la negociación de las limitaciones para obtener
un equilibrio entre los requisitos, costo y horario.
De acuerdo con el estándar IEEE 12207.1, cada tipo de plan, si se trata de un
plan de proyecto, un plan de gestión de la configuración, un plan de
aseguramiento de la calidad, un plan de formación, u otro tipo de plan debe
contener la siguiente información [12207]:
• tiene que ser satisfecho

• criterios de éxito
• actividades de trabajo que hay que realizar
• cronograma, presupuesto y recursos
• medidas de control de calidad
• procedimientos de cambio y el seguimiento de la historia del proyecto
• interfaces a las partes interesadas
• papeles que desempeñan
• responsabilidades y autoridades
• plan de adquisición de recursos
• plan de adquisición de conocimientos, según sea necesario
Además, cada tipo de plan debe someterse a un examen formal y ser aceptado
por las partes interesadas pertinentes, incluida la versión inicial de y los cambios
subsiguientes al plan.
En conjunción con la preparación de la información genérica que aparece más
arriba, la planificación de los detalles de un proyecto de software debe incluir las
actividades que figuran en las tablas 4.1 y 4.2.
Aunque las actividades en las Tablas 4.1 y 4.2 están en orden secuencial, se
debe entender que, como la mayoría de las actividades de ingeniería de software,
se llevan a cabo mejor de una manera iterativa. También debe entenderse que la
planificación
www.it-ebooks.info
123
TABLA 4.1 actividades de planificación previa para proyectos de software

planificación previa de las actividades
• Establecer una relación de trabajo con su cliente / comprador y otras partes
interesadas del proyecto
• Desarrollar y / o aclarar los requisitos y restricciones operacionales de desarrollo
• Dar prioridad a las necesidades operacionales
• Establecer la línea base inicial de las necesidades operacionales
• Desarrollar requisitos del sistema y la arquitectura del sistema, según el caso
• Desarrollar especificaciones técnicas de los requisitos de software
• Establecer la trazabilidad entre los requisitos operacionales, requisitos del
sistema y los requisitos de software
• Obtener el compromiso de una versión inicial de los requisitos por parte del cliente /
comprador y otras partes interesadas pertinentes
• Establecer una línea de base inicial de las necesidades operacionales y especificaciones
técnicas
• Identificar los recursos necesarios y un calendario para el desarrollo de la versión
inicial del plan del proyecto
TABLA 4.2A alcance general de las actividades de planificación para proyectos de

software (parte 1)
Las actividades de planificación
• Plan para la interacción en curso con el cliente en los comentarios, demostraciones,
aprobaciones, y la aceptación del producto entregado
• Plan para la interacción en curso con la comunidad de usuarios en la obtención de
requisitos, demostraciones de prototipos y evaluaciones operacionales
• Preparar una estimación preliminar de esfuerzo, coste, y programar para determinar
la viabilidad del proyecto dentro de las limitaciones de esos factores
• Refinar las especificaciones técnicas para el sistema o producto
• Especificar un proceso de desarrollo y procesos de apoyo
• Desarrollar un vista de la arquitectura de descomposición (ADV) de la arquitectura
del producto y asignar requisitos para los elementos de la ADV
• Especificar las interfaces entre los módulos de la ADV y las interfaces entre los
módulos y el medio ambiente externo
• Desarrollar una estructura de desglose de trabajo que incluye elementos de trabajo para
los módulos de ADV
• Desarrollar paquetes de trabajo para las tareas de la estructura de desglose del trabajo
(EDT)
• Definir un cronograma de hitos medibles objetivamente
• Preparar una red del cronograma e identificar la ruta crítica (s)
• Preparar un PERT (Programa de Evaluación y Revisión Técnica) estimación de la
duración del proyecto
• Identificar los números y tipos de recursos necesarios, cuándo van a ser necesarias, y
por cuánto tiempo
• Preparar una estimación del óptimas esfuerzo, coste, calendario, y los recursos
• Negociar con el cliente para obtener un equilibrio entre los requisitos, costos,
recursos, y duración del proyecto que satisfaga las restricciones del proyecto
• Finalizar un acuerdo contractual con el cliente que proporciona un equilibrio entre
las necesidades, planificación, los recursos y el costo
www.it-ebooks.info
TABLA 4.2B alcance general de las actividades de planificación para proyectos de

software (parte 2)
Las actividades de planificación
• Definir la estructura organizativa del equipo de proyecto y especificar las funciones, las
responsabilidades y las autoridades
• Establecer el entorno de ingeniería para incluir las normas, procedimientos y
herramientas para el desarrollo de software, verificación y validación
• Especificar un proceso de control de versiones y una herramienta de control de versiones
• Establecer una junta de control de cambios para el proyecto
• Identificar los productos de trabajo para ser colocado bajo control de versiones
• Establecer un proceso de control de cambio que incluye un proceso de análisis de impacto
• Especificar criterios de aceptación objetivos para la colocación de nuevos y
modificados productos de trabajo bajo control de versiones
• Plan para la verificación y validación de productos de trabajo
• Desarrollar un plan de medición para medir e informar la cantidad y la calidad de
los productos del trabajo, el esfuerzo, el costo, el progreso, defectos y otras
medidas de calidad
• Desarrollar un plan de gestión de riesgos para identificar y hacer frente a los factores
de riesgo sobre una base en curso
• Desarrollar planes, en su caso, para los siguientes tipos de actividades:
° gestión de subcontratistas y proveedores
° coordinación con los proyectos y programas asociados
° coordinación con la verificación y validación organización independiente (grande “I”)
° seguridad de la información, incluyendo las autorizaciones de seguridad y el acceso a la
información dentro de varias entidades orgánicas
° aprobaciones según la reglamentación vigente, acuerdos de licencia y derechos-in-datos
° instalación, formación de usuarios, y la transición
° las actividades de mantenimiento en curso
° la gestión de los recursos informáticos, gestión de instalaciones, seguridad física
° protección de copia de seguridad de los datos de productos y procesos
• Preparar un plan para actualizar el plan de proyecto sobre una base periódica y función de
los acontecimientos
• Documentar el plan de proyecto utilizando el formato estándar de la organización, un
formato adaptado basado en el estándar IEEE 1058 [IEEE1058], o el formato de la
Tabla 4.4 de este texto
• Revisar el plan de proyecto con el cliente, los gerentes de nivel superior, y otras partes
interesadas pertinentes; revisar, según sea necesario
• Obtener el compromiso con el plan por los interesados apropiados
• Coloque el plan bajo el control de versiones, estableciendo así la línea de base inicial del
plan
actividades en las Tablas 4.1 y 4.2 pueden ser más amplia de lo necesario para su
proyecto; deben ser adaptado a las necesidades del proyecto.
Los artículos etiquetados “según proceda” en la Tabla 4.2 pueden no ser
aplicables a su proyecto; todos los demás elementos de la lista deberán dirigirse a
un nivel de detalle apropiado para la naturaleza y el alcance de su proyecto y la
criticidad del sistema o producto a desarrollar. Los productos en la Tabla 4.2 que
no están incluidos en sus actividades de planificación deben tenerse en cuenta en
el plan del proyecto, y breves justificaciones deben ser proporcionados para no
incluirlos.
Si tienes la suerte de trabajar en una organización bien administrada la mayor
parte de las actividades Tablas 4.1 y 4.2 tendrán procesos estándares,
procedimientos y herramientas que requieren poca o ninguna, adaptando para su
proyecto. Por ejemplo, la configuración agement hombre- y procesos de pruebas
independientes pueden ser estandarizados; puede haber un conjunto de modelos
www.it-ebooks.info
de procesos de desarrollo para elegir; puede haber organizativa
www.it-ebooks.info
4.4 EL ÁREA DE CMMI-DEV-V1.2 PROCESO para la planificación 125
unidades que cuentan con personal capacitado, procedimientos y herramientas

para la mayor parte o la totalidad de los procesos de portabilidad SUP-; y puede
haber consultores internos para ayudar en la adaptación de una plantilla y la
preparación del plan de proyecto.
Si usted no es tan afortunada, el proceso de planificación puede requerir una
gran cantidad de esfuerzo. En este caso se tiene la tentación de eludir la mayor
parte de las actividades de planificación mencionados anteriormente. El riesgo
para el éxito del proyecto debe ser evaluado para los artículos que no están
planificadas; por ejemplo:
• ¿Qué riesgos incurridos si usted no tiene un proceso para la gestión de

cambios en los requisitos?
• ¿Qué riesgos incurridos si usted no tiene un proceso para evaluar el impacto
de los cambios en los requisitos, costos, plazos, o la tecnología?
• ¿Qué riesgos incurridos si usted no tiene una agenda con metas objetivas?
• ¿Qué riesgos incurridos si usted no tiene un proceso para medir el esfuerzo y
defectos?
• ¿Qué riesgos contraídos, si no practicas de gestión de riesgos?
Estos temas y otros aspectos de riesgo del proyecto se presentan en el Capítulo 9.

Por supuesto, el nivel de detalle en su plan debe ser apropiado para el alcance
y el carácter crítico de su proyecto. El plan puede consistir en unas pocas páginas
para un proyecto pequeño o muchas páginas para un proyecto grande. Una
consideración adicional es que las actividades de planificación mencionados
anteriormente no pueden llevarse a cabo en el orden indicado. Por ejemplo,
algunos elementos del acuerdo contractual pueden especificarse en un contrato
legalmente vinculante antes, el director del proyecto, participar en el proyecto.
Las actividades de planificación deben producirse de una manera que se
adapte a las necesidades de la situación; por ejemplo, algunas actividades de
planificación se pueden producir de una manera evolutiva, como en situaciones
en las necesidades evolucionan y programar hitos indican que una versión de
trabajo del sistema va a ser demostrado al cliente sobre una base semanal. En
estas situaciones la planificación de qué hacer a continuación evolucionará a
medida que evoluciona la situación.
4.4 El área de proceso de CMMI-DEV-V1.2 para la planificación
De acuerdo con CMMI-DEV-v1.2, el propósito del proceso de planificación del

proyecto es establecer y mantener planes que definen las actividades del proyecto.
Otras áreas de proceso CMMI-DEV-v1.2 relacionados con la planificación del
proyecto incluyen:
• desarrollo de requisitos,
• gestión de requerimientos,
• la gestión de riesgos, y
• las áreas técnicas proceso de solución.
Los objetivos específicos de la planificación de proyectos en CMMI-DEV-v1.2

incluyen el establecimiento Las estimaciones, el desarrollo de un plan de proyecto, y
la obtención de compromiso con el plan. Las prácticas específicas relacionadas con
estos objetivos específicos se enumeran en la Tabla 4.3. La naturaleza de los
www.it-ebooks.info
objetivos y prácticas de planificación de proyectos específicos TABLA 4.3 CMMI-DEV-v1.2

capítulos de
Prácticas específicas Este texto
SG 1 establecer
estimaciones
SP 1.1-1 Estimar el alcance del proyecto Capítulo 3
SP 1.2-1 Establecer estimaciones de producto de trabajo y los Capítulo 5
SP 1.3-1 atributos
Definir el de tareas
ciclo de vida del proyecto Capitulo 2
SP 1.4-1 Determinar las estimaciones de esfuerzo y costo Capítulo 6
SG 2 desarrollar un plan de proyecto

SP 2.1-1 Establecer el presupuesto y el calendario Capítulo 6
SP 2.2-1 Identificar los riesgos del proyecto capítulo 9
SP 2.3-1 Plan de gestión de datos Los capítulos 7
SP 2.4-1 Plan de recursos del proyecto y8
Capítulo 5
SP 2.5-1 Planear para el conocimiento y las habilidades Capítulo 5
SP 2.6-1 necesarias
Plan de participación de los interesados Capitulo 2
SP 2.7-1 Establecer el plan del proyecto Capítulo 4
SG 3 obtener compromiso con el plan

SP 3.1-1 Revisar los planes que afectan al proyecto Capítulo 4
SP 3.2-1 Conciliar trabajo y los niveles de recursos Capítulo 6
SP 3.3-1 Obtener el compromiso del plan Capítulo 4
prácticas específicas se discuten aquí. Las técnicas para conseguir estas prácticas se
presentan en los capítulos siguientes, tal como se indica en la tercera columna de la
Tabla 4.3.
Una estimación del esfuerzo, calendario, y los recursos en base a los requisitos
y con- straints es un elemento esencial de un plan de proyecto; se indique otra, no
es posible desarrollar un plan sin estimaciones, y no es posible desarrollar
estimaciones sin requisitos. Las áreas de proceso CMMI-DEV-v1.2 de desa-
rrollo y los requisitos de gestión de requisitos (presentado en el capítulo 3) están
estrechamente relacionados con el área de proceso de planificación del proyecto.
Estimar el alcance de un proyecto tiene que ver con la identificación de todas
las actividades de trabajo a realizar. Una estructura de división del trabajo se
utiliza típicamente para documento del alcance de un proyecto; la estructura del
proyecto se presentan en el capítulo
5. tamaño y la complejidad del producto son los factores principales que
normalmente se utilizan para determinar la cantidad de esfuerzo que se requiere
para desarrollar un producto de software. Otros factores incluyen el rendimiento
requerido, la fiabilidad, la seguridad y la seguridad. Por lo tanto, el
establecimiento de las estimaciones de los atributos del producto, como el
tamaño y la complejidad es una práctica específica de SG objetivo específico 1
(SP 1.2-1). Otros factores que afectarán el esfuerzo y la programación también
deben ser considerados.
Un modelo de desarrollo apropiado para un proyecto de software depende del
alcance del trabajo a realizar, los atributos del producto, y las fases de desarrollo
que deben incluirse. SP 1.3-1 se refiere a la definición de un modelo de
desarrollo de software que incluye un conjunto de fases de desarrollo adecuadas
para los atributos alcance del proyecto y de productos. Con base en los resultados
www.it-ebooks.info
de las prácticas específicas 1.1-1, 1.2-1, y
www.it-ebooks.info
4.4 El área de proceso de CMMI-DEV-V1.2 para la planificación 127
1.3-1, una estimación del esfuerzo y el coste se desarrolla a partir de datos

históricos, ment sentencias con el experto, y otras técnicas presentadas en el
capítulo 6 de este texto.
Lograr la meta SG 1 específica en la Tabla 4.3 proporciona la base para el
logro de SG 2, Desarrollar un plan de proyecto. Un plan de proyecto que
satisfaga SG 2 contendrá un calendario y un presupuesto que satisfaga las
estimaciones de esfuerzo y costo desarrolladas en satisfy- SG ING 1; Dicho de
otra manera, el esfuerzo, calendario, y las estimaciones de costos proporcionan
restricciones que no pueden excederse en el plan del proyecto.
Porque el esfuerzo es el producto de personas y el tiempo, un calendario se
puede derivar de una estimación del esfuerzo; por ejemplo, 54 meses-persona de
esfuerzo pueden ser programadas como 6 personas durante 9 meses. El
calendario se especificará las tareas predecesoras que deben ser completados, y
los productos de trabajo producidos por aquellas tareas que deben estar
disponibles antes de tareas posteriores puedan comenzar; El calendario también
especifica las tareas sucesoras que se pueden realizar después de completar cada
tarea. Se identifican las limitaciones de secuenciación entre las actividades de
trabajo están especificados de esta manera, y oportunidades para las actividades
de trabajo simultáneos. El presupuesto se asigna entonces a cada una de las tareas
que deben realizarse.
Un riesgo es un problema potencial que (si se convierte en un problema)
impactará negativamente a un resultado exitoso de la entrega de un producto
aceptable a tiempo y dentro del presupuesto. Los factores de riesgo deben ser
identificados en el plan del proyecto y las acciones apropiadas gación mitiga
planeado. La gestión de riesgos para proyectos de software se presenta en el
capítulo 9.
SP 2.3-1 en la Tabla 4.3 implica el desarrollo de un plan para la gestión de los
datos de proyecto, que incluye todos los datos en todas las áreas del proyecto
(gestión de proyectos, procesos de desarrollo, y procesos de apoyo). El plan
debe especificar los datos del proyecto que deben recogerse, un horario de
recogida y validación de los datos, los formatos de informes y listas de
distribución, así como los requisitos para la privacidad y seguridad de los datos
del proyecto.
SP y SP 2.4-1 2.5-1 tienen que ver con la identificación y planificación de los
recursos necesarios para llevar a cabo un proyecto. Los recursos incluyen
cantidades de personas y niveles de habilidad requeridos, herramientas de
software, hardware de computación, instalaciones, presupuesto, y todos los
demás recursos necesarios para llevar a cabo un proyecto (SP 2.4-1). Porque la
gente es normalmente el recurso más importante para un proyecto de software, es
importante adoptar la definición de los niveles de conocimiento y habilidades
necesarias para llevar a cabo un proyecto (SP 2.5-1).
Las partes interesadas son las personas cuya participación en un proyecto es
necesario o deseable para asegurar un resultado exitoso. Diferentes tipos de
personas pueden tener diferentes tipos y cantidades de participación durante las
diferentes fases de un proyecto. Por ejemplo, la participación de los
representantes de los usuarios es más importante durante los requisitos defini-
ción y la aceptación del mismo que durante el diseño detallado y la codificación.
SP 2.6-1 se ocupa de la planificación para la participación de los grupos de
interés identificados.
El logro de SG 2 en la Tabla 3.1 culmina en SP 2.7-1 (Establecer el plan de
proyecto). Formato y contenido de un plan de gestión de proyectos de software se
presentan y discuten en la siguiente sección de este capítulo.
Obtener compromiso con el plan (SG 3) incluye tres prácticas específicas. SP
www.it-ebooks.info
3.1-1 implica revisar todos los planes que afectan al proyecto para entender los
compromisos del proyecto. Por ejemplo, la documentación de las necesidades,
los planes para algunos o todos los procesos de apoyo, y los planes para
actividades tales como la instalación del sistema y la formación de los usuarios
entregados son normalmente desarrollado y documentado por separado, y se hace
referencia en el plan del proyecto.
www.it-ebooks.info
SP 3.2-1 (conciliar el trabajo y los niveles de recursos) se refiere a la

conciliación de las diferencias entre las estimaciones y los recursos disponibles.
Una estimación podría, por ejemplo, indicar que serán necesarios 10 personas
que tienen habilidades especificadas para completar un proyecto en los 12 meses
requeridos. Tal vez el presupuesto apoyará sólo 7 personas en el nivel de
habilidad requerido.
opciones aceptables para conciliar las diferencias entre el trabajo a realizar, los
recursos y el tiempo disponibles incluyen:
• la reducción de los requisitos (de-de alcance),

• el aumento de la cantidad de recursos (y el presupuesto correspondiente),
• utilizando los recursos más productivos, y
• extender el horario.
opciones inaceptables para lograr un equilibrio entre el trabajo a realizar, los

recursos y el tiempo disponible (es decir, los requisitos, esfuerzo y horario) en el
plan del proyecto incluyen planes descoping de medición y control, revisiones
por pares, y la verificación y validación; y la planificación de las horas
extraordinarias.
El paso final en el área de proceso CMMI ® Planificación de proyectos es la
obtención de compromiso con el plan por las partes interesadas que se encargan
de la realización de y apoyar la ejecución del plan. Los compromisos con cada
actividad de trabajo identificado en SP 1.1-1 deben obtenerse de las partes
interesadas internas a su proyecto, así como los grupos de interés externos, tales
como la alta dirección, los clientes externos, y proyectos asociados. las interfaces
de organización y técnica ciones de interfaz especificación deben ser
especificados y los compromisos deben ser obtenidos a partir de los grupos de
interés apropiados para participar en el mantenimiento de las interfaces. Como
mínimo, las partes interesadas incluirán usted, su arquitectura de software, el
grupo de aseguramiento de la calidad, su gerente, y un representante del cliente
(por ejemplo, el departamento de marketing, o un cliente externo).
El enfoque de proyecto de planificación se indica en las Tablas 4.1 y 4.2 y por
el área de proceso de Planificación de Proyectos de CMMI-DEV-v1.2 es la base
del enfoque impulsado plan- llamada a la gestión de proyectos de software. Se
debe destacar que el conjunto completo de tareas en las tablas 4.1 y 4.2 y en los
objetivos y prácticas específicas de CMMI-DEV-v1.2 son suficientes para los
más grandes y complejos proyectos de software. Ellos deben ser adaptados y
adaptados a las necesidades de cada proyecto. Desafortunadamente, algunas
personas interpretan mal el enfoque del plan impulsado y lo rechazan por ser
demasiado engorroso y burocrático sin entender que un plan se debe adaptar y
adaptada a las necesidades de cada situación. El enfoque del plan impulsado a la
planificación del proyecto es apropiado en dos situaciones:
1. cuando hay un acuerdo contractual formal entre un adquirente y un pro-

veedor, y / o
2. para proyectos grandes y complejos internos de una organización.
4.4.1 Planificación de proyectos ágiles

Un enfoque ágil puede ser apropiado para proyectos pequeños (por ejemplo, 10 o
menos desarrolladores de software) cuando las condiciones contractuales
formales no se aplican y en los casos
www.it-ebooks.info
4.5 Un plan de proyecto MINIMAL 129
los requisitos están evolucionando o cambiando de forma continua y ery deliv-

frecuente de evolución capacidades han de ser entregados a los usuarios, por
ejemplo, en una aplicación basada en la web. El proceso de desarrollo ágil se
describe en la Sección 2.5.3. A medida relacionada con ellas, la planificación de
un proyecto ágil implica:
• trabajar con el cliente para desarrollar la visión del producto,
• la determinación de la duración del proyecto y el nivel de esfuerzo que deba
aplicarse,
• obtener el compromiso de un representante de atención al cliente bien
informado para la participación en curso en el proyecto,
• establecer el entorno de desarrollo,
• la planificación de la frecuencia de iteraciones, y
• la planificación de la frecuencia de la entrega de la evolución de las
capacidades de los usuarios.
Además una metáfora de diseño debe ser establecido por los desarrolladores y
la versión particular de un proceso ágil para ser utilizado debe ser adoptado y
aceptado por los interesados en el proyecto; la versión de desarrollo ágil Scrum
se discute en la Sección 2.5.3. Se debe establecer un plan para la revisión en
curso con los clientes, desarrolladores y otras partes interesadas, como los planes
deben de revisar periódicamente el estado planificada y real de las cosas y para
reconciliar diferencias. Al igual que con todos los proyectos de software, se
debe establecer la evaluación inicial de los factores de riesgo y planes de
management riesgo permanente. La planificación de este modo un proyecto ágil
implica:
• el desarrollo de la visión del producto;
• la determinación de la duración del proyecto y nivel de esfuerzo;
• obtener el compromiso de un representante del cliente bien informado;
• establecer el entorno de desarrollo;
• la planificación de la frecuencia de iteraciones;
• la planificación de la frecuencia de las entregas;
• el establecimiento de una metáfora de diseño;
• la adopción de una versión de desarrollo ágil;
• la planificación de las revisiones en curso por parte de los grupos de interés;
• la planificación de la revisión periódica de la situación del proyecto;
• la realización de una evaluación inicial de riesgos y mitigación de riesgos; y
• la planificación de las evaluaciones de riesgos en curso y las actividades de
mitigación.
4.4.2 Equilibrar la agilidad y disciplina

Como se relata en el capítulo 2, el texto de equilibrio de la agilidad y la disciplina
por Boehm y Turner contrasta enfoques del plan impulsado y ágil para el
desarrollo de software y presenta una solución híbrida para lograr un equilibrio
que incorpora aspectos de ambos enfoques en función de cada situación
particular [BOEHM04 ].
4.5 Un plan de proyecto MÍNIMO
www.it-ebooks.info
Como mínimo, un plan para un proyecto de software, si el plan impulsado o ágil,
debe incluir la siguiente información:
www.it-ebooks.info
• una declaración del propósito y los objetivos del proyecto

• identificación de los interesados y sus objetivos
• software de modelo de desarrollo que se utilizará
• entorno de desarrollo de software para ser utilizado
• La tecnología de plataforma que se utilizará
• alcance de las actividades de trabajo que se completará
• calendario de actividades de trabajo que incluya el calendario periódicos y
objetivos
• los niveles de habilidad y el número de personal de software necesarios
• cuando serán necesarios varios números y tipos de personal de software
• recursos, además de personal de software
• un plan para informar periódicamente el estado del proyecto
• un plan de gestión de riesgos
Como se ha destacado en repetidas ocasiones, estos elementos de un plan de

proyecto deben basarse en el modelo de desarrollo a utilizar y reducido al tamaño
y complejidad del proyecto. Técnicas para el desarrollo y documentación de estos
elementos de un plan de proyecto se presentan en los capítulos siguientes.
Las siguientes secciones de este capítulo proporcionan una plantilla para y una
descripción de los elementos de un plan impulsado por el plan integral, un
ejemplo de la adaptación de la plantilla, y técnicas para reducir el esfuerzo
necesario para desarrollar un plan de gestión de proyectos de software.
4.6 Un modelo para los planes de administración de proyectos SOFTWARE
En ausencia de un formato estándar para los planes del proyecto en su

organización, la plantilla presentada en las Tablas 4.4a, byc se puede utilizar.
Esta plantilla es similar al formato de los planes del proyecto especificados en la
norma IEEE estándar EIA / 1058. La plantilla es amplia y está destinado a los
proyectos más grandes y complejos. Puede ser, y debe ser, a la medida para
adaptarse a las necesidades de cada proyecto; un ejemplo de la adaptación se
presenta más adelante en este capítulo. La plantilla larga se presenta en tres
mesas para facilitar la presentación. Los temas de las mesas se discuten en
numerosos lugares en todo el texto; el “contenido en el” columna de cada tabla
indica los capítulos y secciones donde se presenta la discusión de cada tema
principal.
Una versión anotada de la plantilla está contenida en el Apéndice 4B de este
capítulo. En el apéndice se plantea una serie de preguntas para ayudarle a
preparar su plan de proyecto. Una versión en línea de la plantilla que ofrece un
esquema fácil de usar para la preparación de los planes del proyecto se puede
obtener en la URL que aparece en el prefacio de este texto.
Una visión general de los diversos elementos de la plantilla se presenta en las
siguientes secciones.
4.6.1 Letra pequeña

Hay nueve secciones principales en la plantilla para los planes de gestión de
proyectos de software basado en el estándar IEEE 1058 más el “front matter”,
que incluye un título
www.it-ebooks.info
4.6 Un modelo para los planes de administración de proyectos SOFTWARE 131
Plantilla 4.4A mesa para un Plan de Gestión de

Proyectos de Software (parte 1)
ContentsDiscussed En
Frente importar sección 4.4.1
Prefacio Título de
la página
Historial de
revisiones
Tabla de
contenidos Lista
de Figuras
Lista de mesas
Proyecto resumen sección 4.4.2

1. Resumen del proyecto
1.1 Propósito, alcance y objetivos
1.2 AssumptionsSection 4.4.2
1.3 restricciones
1.4 proyecto DeliverablesChapter 1
1.5 Cronograma y del Presupuesto Resumen
Evolución, referencias, definiciones sección 4.4.3

2 Evolución del Plan
3 referencias
4 definiciones
Proyecto organización sección 4.4.4

5.Organización del proyecto
5.1 Interfaces de proyectos
5.2 Proyecto StructureChapter 1
5.3 Roles y ResponsibilitiesChapter 8
página, un historial de revisiones, un prefacio, y tal vez una tabla de contenido,

una lista de figuras, y una lista de tablas. La página del título debe contener:
• el nombre del proyecto,

• el número de versión del plan,
• la fecha de emisión,
• el nombre de la persona responsable (usted),
• su organización, y
• su información de contacto (número de teléfono, dirección de correo
electrónico).
Su plan de proyecto debe ser colocado bajo control de versiones tan pronto
como se obtiene compromiso con ella desde el stakeholders.18 apropiada medida
que el plan se desarrolla, la historia sión revi- incluirá una entrada para cada
versión anterior del plan. Cada entrada debe incluir:
18
véase la Sección 3.2.5 para una discusión de control de versiones
www.it-ebooks.info
• el número de versión,
• fecha de lanzamiento,
• secciones cambiaron, y
• la naturaleza de los cambios realizados.
En algunas situaciones puede ser conveniente que cada versión del plan
(incluyendo la versión inicial) incluyen los nombres, firmas y cargos de las
personas que están autorizadas y responsables de la aprobación del plan inicial y
modificaciones al plan. Esta persona puede ser un cliente externo (el adquirente),
o usted, el director del proyecto, en el caso de un proyecto interno.
El Prefacio debe abordar las siguientes
cuestiones:
• el propósito del proyecto,

• el contexto en el que se realizará el proyecto, y
• el público objetivo del plan
Dependiendo del alcance y la formalidad de su plan de proyecto, puede ser

conveniente incluir una tabla de contenido, una lista de figuras, y una lista de
tablas.
4.6.2 Resumen del proyecto

Sección 1 de un plan de gestión de proyectos de software proporciona un
resumen del proyecto (a veces conocido como el “resumen ejecutivo”). El
resumen, como se indica en la Tabla 4.4a, incluye el propósito, el alcance y
objetivos del proyecto.
Propósito, alcance y objetivos de su plan de proyecto debe responder a las
siguientes cuestiones:
• objetivo: la razón por la que su organización está haciendo el proyecto y las

necesidades de la empresa o acuerdos contractuales que deben cumplir los
resultados del proyecto
• Alcance: el alcance del proyecto especifica las principales actividades de
trabajo a ser con- canalizado y la relación de este proyecto a otros proyectos
y otras actividades en curso
• objetivos: los criterios de éxito para el proyecto; los objetivos que deben ser
satis- cado para asegurar un resultado aceptable; los productos de trabajo que
se entregarán; y métodos para ser utilizados en la determinación de que los
objetivos se han cumplido
• exclusiones: el alcance y los objetivos que se excluyen expresamente de este
proyecto y / o de los productos de trabajo resultantes
El propósito debe presentar la motivación para llevar a cabo el proyecto, lo que

podría ser, por ejemplo, para reemplazar a un sistema existente, para actualizar
un sistema existente, para proporcionar un sistema automatizado para reemplazar
un proceso manual, o llevar a cabo un estudio de factibilidad y construir una
prototipo de un producto futuro. El propósito del proyecto de ATM, por ejemplo,
podría ser la de sustituir o actualizar un sistema ATM existente, para
proporcionar un sistema ATM por primera vez para una institución financiera, o
llevar a cabo un estudio de factibilidad y construir un prototipo de una interfaz de
www.it-ebooks.info
usuario avanzada para un sistema de ATM. El PRO-
www.it-ebooks.info
totipo podría implicar el uso de huellas digitales, tarjetas RFID, escáner de retina,
escaneos faciales, o el reconocimiento de voz y comandos de voz para la interfaz
de usuario.
El alcance de las actividades de trabajo para un proyecto (por ejemplo, el
sistema ATM) podría incluir refinamiento de las necesidades de funcionamiento,
el desarrollo de las las especificaciones técnicas, el diseño y la implementación
del software, la validación por un grupo independiente, formación de usuarios,
instalación de el software en múltiples sitios. O bien, podría limitarse a modificar
el diseño de un producto existente y volver a implementar algunas de las
características, lo que resultaría en una nueva versión del producto.
Los objetivos del proyecto deben especificar, lo más claramente posible, los
criterios de éxito para el proyecto. Puede ser que la fecha de entrega es el factor
más crítico para el éxito, aunque menos funciones que se desea se incluyen en el
producto entregado. O bien, puede ser que el desarrollo de una estructura
arquitectónica para una familia de productos (una línea de productos) que va a
maximizar la reutilización de los componentes en los sistemas futuros es de alta
prioridad, incluso si esto significa extender el horario más allá de la fecha de
finalización prevista.
En algunos casos, es importante establecer claramente qué actividades se
excluyen del alcance de su proyecto. Podría ser, por ejemplo, que en base a la
sensibilidad de los datos del cliente, su proyecto no incluye las pruebas del
sistema en el entorno del usuario. O bien, debido a que su proyecto consiste en
mejorar el rendimiento de algunos elementos del sistema operativo de un cliente,
y debido a que los usuarios no deben verse afectados por los cambios, la interfaz
de usuario no debe ser modificado.
Los supuestos son las condiciones en que se basa su plan de proyecto que no
se ha verificado o no pueden verificar en este momento. Usted puede suponer,
por ejemplo, que un número suficiente de personal que tenga los conocimientos
necesarios estarán disponibles cuando sea necesario. O bien, puede asumir que la
complejidad del producto no será un problema, ya que espera tener los
desarrolladores de software que están familiarizados con este tipo de sistema.
Sección 1.2 debe enumerar los factores y condiciones que usted asume será
verdad.
Restricciones (sección 1.3 del plan de gestión) son impuestas externamente
condiciones que su proyecto debe satisfacer. Las restricciones se clasifican
como las restricciones de diseño y limitaciones del proceso. Una restricción de
diseño podría requerir la reutilización de componentes existentes o la
construcción de interfaces especificadas a otro sistema. Una restricción proceso
podría limitar el dinero, los recursos y / o tiempo disponible para llevar a cabo el
proyecto.
Sección 2.3 de este modo debe indicar limitaciones que han sido impuestas a
factores tales como:
• programar,
• presupuesto,
• recursos,
• software para ser incorporado,
• tecnologías a utilizar, y
• interfaces del producto a otros sistemas.
entregables del proyecto deben especificar los siguientes

elementos:
www.it-ebooks.info
• productos de trabajo a ser entregados al cliente (ver sección 1.3)
• cuando y donde se entregarán,
www.it-ebooks.info
• cantidades y medios de entrega,

• todo envasado y manipulación de instrucciones especiales.
entregables del proyecto pueden limitarse a código objeto y de un usuario manual

o que podrían incluir el código fuente, documentación de diseño, y el conjunto de
pruebas, todo ello bajo el control de versiones con una herramienta de control de
versiones especificado, tal vez porque el cliente tiene la intención de mantener y
desarrollar el trabajo entregado productos. Las prestaciones enumeradas en el
plan del proyecto debe reflejar los enumerados en el acuerdo contractual (MOU o
DS) y otros documentos contractuales. Una referencia a esos documentos deben
ser incluidos.
El último punto en el resumen ejecutivo (sección 1.5) se presenta un resumen
del presupuesto sched- ULE y para el proyecto. Los temas que se abordarán en la
sección 1.5 incluyen:
• el marco de tiempo para este proyecto (se indica en el tiempo transcurrido o

por las fechas de inicio y fin),
• los principales hitos y cuando están programados para producirse (por el
tiempo transcurrido desde el principio, o por las fechas de los sucesos),
• el costo total (en dólares o personas-hora), y
• costos y horarios para los procesos y planes adicionales que no están
incluidos en este plan de apoyo, con referencias a la documentación de
dichos planes.
La duración del proyecto se puede afirmar en el tiempo transcurrido (por

ejemplo, seis meses) o por las fechas de inicio y fin (por ejemplo, 3/15 / 20xx a
9/15 / 20xx). Fechas de inicio y final son preferibles porque hacen que el plan
más específico. El costo puede escribir en unidades monetarias o total de
unidades de esfuerzo (por ejemplo, personas-meses). Esta última medida puede
ser preferible a causa de las sensibilidades de organización. hitos importantes,
como comentarios de los clientes y demostraciones que involucran a la
comunidad de usuarios, o las entregas previstas de versiones subconjunto del
sistema final o producto, deben ser incluidos en el resumen del proyecto.
Los costos y horarios para procesos como la gestión subcontratista o
verificación y validación de soporte por una organización independiente, y los
planes adicionales para las actividades “según corresponda” que se enumeran en
la Tabla 4.4a, (formación de usuarios, etc.) que no están contenidas en este plan
de proyecto debe aparecer.
Debido a la naturaleza de la información en el resumen del proyecto, esta
sección se completó típicamente pasado.
4.6.3 Evolución, definiciones y Referencias

Sección 2 de un plan de proyecto (evolución del Plan) describe el plan para
actualizar el plan de proyecto sobre una base periódica y función de los
acontecimientos. Los siguientes temas deben ser abordados:
• el calendario previsto para la actualización periódica del plan,

• condiciones y eventos para los cuales se harán actualizaciones programadas
• método de control de cambios en el plan, y
• métodos utilizados para emitir cambios a las partes interesadas pertinentes
www.it-ebooks.info
Es posible, por ejemplo, va a actualizar el plan de proyecto sobre una base

mensual y, con la participación del cliente, revisar el costo, el cronograma y / o
requisitos a la hora de solicitud de cambio de un cliente está fuera de alcance para
el plan actual. Los cambios en el plan deben ser controlados por un grupo
(pequeño) de individuos autorizados (el CCB proyecto; véase la Sección 3.2.5) y
rastreados utilizando una herramienta de control de versiones. Como se explica
en la Sección 3.2.5, la CCB debe ser escalado para adaptarse a las necesidades
del proyecto; en un proyecto pequeño, el CCB puede consistir en que, el director
del proyecto, y el cliente. Aunque no se puede pensar de esta manera, usted y el
cliente es el (mal infor-) CCB si su proyecto utiliza un modelo de desarrollo ágil.
En un gran programa a nivel de sistema que implica múltiples proyectos
coordinados, puede haber varios BCC; usted puede ser un miembro de la gran
CCB control del programa, además de ser el presidente de la CCB software. En
cualquier caso, los planes de actualización y una breve explicación de los
cambios realizados en el plan del proyecto debe ser comuni- cado de apropiarse
de las partes interesadas; notificaciones de cambios podrían ser distribuidos a una
lista de distribución de correo electrónico.
Sección 3 de la plantilla de la Tabla 4.4a proporciona referencias a documentos
relacionados. Esta sección debe enumerar los documentos que se relacionan con el
plan, tales como el concepto de las operaciones y las Especificaciones Técnicas, e
indicar dónde se pueden encontrar. Como siempre, los documentos relacionados (y el
plan del proyecto) deben ampliarse para adaptarse a las necesidades del proyecto.
Los ConOps, por ejemplo, pueden ser una declaración de la visión de unas pocas
páginas o un pequeño conjunto de casos de uso. Las especificaciones técnicas pueden
ser un documento de tamaño comparable. Por otro lado, los ConOps y ficaciones
Speci- técnica pueden ser cada documentos de gran tamaño si el sistema previsto es
grande y complejo.
Documentos a ser referenciados deben incluir los productos y procesos de
cimentación documentos que figuran en la Tabla 3.1 (requisitos operacionales,
requisitos del sistema y la arquitectura de software, requisitos, restricciones de
diseño, y correspondiente contrato contractual). Las referencias deben ser
proporcionados por otros documentos aplicables, tales como documentos
contractuales adicionales, y también hace referencia a los planes de proyectos
asociados. Las referencias a las políticas de la organización y los procedimientos
y normas aplicables y las pautas a seguir deben ser listados.
Tenga en cuenta, en particular, que la documentación y los requisitos del plan
de proyecto debe tener referencia cruzada y mantener la coherencia entre los
requisitos, calendario, presupuesto, recursos y factores de riesgo; sin embargo,
deben ser documentos separados porque abordan cuestiones diferentes y están
destinados a diferentes audiencias. Los documentos de requisitos no deben
contener ninguna información relacionada con los horarios, presupuestos,
recursos o instalaciones necesarias para llevar a cabo el proyecto. Del mismo
modo el plan del proyecto no debe contener ninguna información de producto
que no sea una breve descripción general del producto a ser desarrollado o
modificado y una referencia a los requisitos de Documen- tación. Las matrices de
trazabilidad pueden utilizarse para la referencia cruzada del plan del proyecto y
documentos relacionados (véase la Sección 3.2.4).
Sección 4, las definiciones, ofrece explicaciones de términos y acrónimos
utilizados en el plan que puede no ser familiar para el público objetivo del plan.
La sección de definiciones debe indicar los significados de los términos y
acrónimos e incluyen referencias a otros documentos que contienen la
terminología necesaria para entender este plan (por ejemplo,
www.it-ebooks.info
El estándar IEEE 610.12 ™ -IEEE estándar Glosario de Terminología de

Ingeniería de Software).
4.6.4 Organización del proyecto

Sección 5 del plan tiene que ver con la manera en que se organiza el proyecto. En
él se describen las interfaces de comunicación del proyecto, la estructura
organizativa para el proyecto, y los roles y responsabilidades para los que
llevarán a cabo las actividades de trabajo del proyecto.
las interfaces del proyecto (Sección 5.1 del PAPS) deben indicar las entidades
de la organización con la que usted y los miembros de su proyecto interactuará y
los individuos que serán los puntos de contacto en las organizaciones.
pueden existir interfaces de proyectos entre su proyecto y el apoyo a las
entidades dentro de su organización como un grupo independiente de pruebas y
la organización matriz, y para entidades externas tales como la organización,
subcontratistas, proveedores y proyectos afiliados adquirentes. Puede utilizar los
organigramas y diagramas para representar las interfaces de organización de su
proyecto. Nombres, cargos, números de teléfono y direcciones de correo
electrónico deben ser listados para aquellos con los que van a interactuar.
Sección 5.2, la estructura del proyecto, aborda los siguientes aspectos:
• cómo se organizará el equipo de desarrollo;

• cómo el equipo de desarrollo va a interactuar con el apoyo de entidades
como la gestión de con- figuración, garantía de calidad, la verificación y la
validación; y
• los puntos de contacto y las líneas de comunicación dentro del proyecto.
En particular, la sección 5.2 de su plan de proyecto debe indicar la forma en

que usted (el director del proyecto), el arquitecto de software (que puede ser
usted), interactuarán los jefes de equipo, y los desarrolladores de software.
dispositivos gráficos tales como gráficos nizational orga- o diagramas pueden ser
utilizados para ilustrar las líneas de autoridad, responsabilidad, y la
comunicación dentro del proyecto. Un ejemplo de una estructura de la
organización para un proyecto de software se representa en la figura 1.3 de este
texto.
Sección 5.3, funciones y responsabilidades,
especifica:
• los roles que deben desempeñar para llevar a cabo las actividades de
desarrollo y procesos de apoyo diferentes,
• las unidades organizativas que desempeñarán los roles, y
• las personas responsables de jugar esos roles dentro de las unidades
organizativas.
En esta sección se debe especificar los títulos de trabajo y las habilidades

necesarias de los individuos y las unidades organizativas que son responsables de
las diferentes actividades de trabajo y procesos SOPORTE- ing. Los individuos
cuyos nombres son conocidos (quizás ahora, quizás más adelante) se pueden
asignar a las responsabilidades. Pero en primer lugar, los papeles que
desempeñan en la realización del proyecto se identifican. Un papel (por ejemplo,
el papel de diseñador) puede ser jugado por uno o más individuos. Un individuo
puede jugar papeles múltiples, simultáneamente y / o secuencialmente. Por
www.it-ebooks.info
ejemplo, un individuo puede ser un diseñador primero y más tarde convertirse en
una
www.it-ebooks.info
programador; un individuo puede ser simultáneamente un probador y el guardián

de la evolución de las versiones del producto en un proyecto pequeño. Una o más
matrices que trazan los roles de desarrollo actividades y procesos de apoyo se
pueden utilizar para describir los roles y responsabilidades del proyecto.
4.6.5 Los procesos de gestión

Sección 6 de un plan de gestión de proyectos de software, los procesos de
gestión, es la esencia de un plan de proyecto. Contiene el plan de puesta en
marcha, el plan de trabajo, el plan de control del proyecto, el plan de gestión de
riesgos, y el plan de liquidación, que se enumeran en la Tabla 4.4b.
El plan de puesta en marcha de su proyecto (sección 6.1) tiene que ver con el
desarrollo de un plan para hacer las estimaciones iniciales, haciendo los cálculos,
y desarrollar un plan de personal, un plan para la adquisición de otros recursos
necesarios, y un plan de entrenamiento para el equipo de proyecto ( si es
necesario). Dependiendo del tamaño y el alcance del proyecto, estos planes
pueden incorporar directamente en el plan de proyecto o el plan de proyecto
pueden contener referencia a otros documentos y archivos electrónicos que
contienen los planes de puesta en marcha.
El plan de estimación de proyectos (sección 6.1.1) debe abordar las siguientes
cuestiones:
• el plan para hacer las estimaciones iniciales y en curso (que va a hacer de

ellos ?, ¿cuándo van a hacer ?, que aprobarlos?);
• las herramientas y técnicas que se utilizan para hacer las estimaciones;
• ¿Cómo se documentarán las estimaciones;
Plantilla 4.4B mesa para un Plan de Gestión de Proyectos de Software (parte 2)

Gerencial procesos sección 4.4.5
6. Los procesos de gestión
6.1 Plan de puesta en marcha
6.1.1 Proyecto EstimationChapter 6
6.1.2 dotación de personal PlanChapter 5
6.1.3 Plan de Adquisición de recursos
6.1.4 Plan del Proyecto de Formación de Personal
6.2 El plan de trabajo
6.2.1 WBS y Trabajo PackagesChapter 5
6.2.2 Programar DependenciesChapter 5
6.2.3 Recurso AllocationChapter 5
6.2.4 Presupuesto AllocationChapter 5
6.3 Plan de Control de Proyectos
6.3.1 RequirementsChapters 3 y 7
6.3.2 ScheduleChapter 8
6.3.3 BudgetChapter 8
6.3.4 QualityChapter 7
6.3.5 Métrica PlanChapter 8
6.3.6 informes PlanChapters 7 y 8
6.4 Gestión de riesgos PlanChapter 9
6.5 plan de liquidación
www.it-ebooks.info
• planes para la reestimación periódica de los costos, plazos, personal y otros

recursos necesarios para completar el proyecto;
• frecuencia de reestimación; y
• el plan para volver a estimar cuando los requerimientos u otras condiciones
del proyecto cambian.
Cuando se prepara una estimación, los siguientes elementos deben estar

documentados:
• persona (s) que hizo la estimación;

• métodos, herramientas y técnicas utilizadas para realizar la estimación;
• datos históricos utilizados como la base de la estimación; y
• el nivel del estimador de confianza en la estimación.
Métodos de estimación, herramientas y técnicas se presentan en el capítulo 6 de

este texto. En algunos casos, una estimación de los costos, duración y recursos
podría ser completada y los compromisos adquiridos antes de desarrollar el plan
del proyecto a nivel de detalle indicado en la Tabla 4.4b. En esos casos aún debe
validar la estimación. Si cree que la estimación no es válida, debe volver a
negociar los requisitos, horario, y
presupuesto; de lo contrario, corre el riesgo de
fracaso antes de empezar. El plan de personal
(sección 6.1.2) debe indicar:
• los tipos de habilidades requeridas;

• el número de personas necesarias que tienen esas habilidades;
• cuándo van a ser necesarios;
• por cuanto tiempo;
• la forma en que se obtendrán; y
• la persona o personas responsables de adquirir el personal necesario.
Herramientas tales como tablas de recursos de Gantt, histogramas de recursos,

hojas de cálculo y las tablas se pueden utilizar para describir el plan de personal
por nivel de habilidad, por fase del proyecto, y por agregaciones de niveles de
habilidad y fases del proyecto. Estas técnicas se discuten en el Capítulo 5.
El plan de adquisición de recursos (sección 6.1.3) debe abordar las siguientes
cuestiones:
• , Además del personal, que serán necesarios recursos;

• cantidades de cada tipo de recurso necesario;
• cuando serán necesarios los recursos;
• la persona, o personas, responsables de la obtención de los recursos; y
• aprobaciones necesarias.
Los recursos pueden incluir elementos tales como hardware y software, contratos
de servicios, el transporte, las instalaciones y los servicios administrativos.
El plan de adquisición de recursos debe especificar los puntos en el
cronograma del proyecto cuando deben producirse las diversas actividades de
adquisición. Las restricciones en la adquisición de la
www.it-ebooks.info
recursos necesarios deben ser especificados. Esta sección se puede ampliar en

adiciones subsecciones cionales (etiquetados como 6.1.3.x, etc.) para dar cabida a
los planes de adquisición para los distintos tipos de recursos a ser adquiridos. Las
referencias a los planes de adquisición de recursos contenidos en documentos
separados deben incluirse aquí.
El plan de formación del personal del proyecto (sección 6.1.4) indica el tipo y el
alcance de la formación necesaria para asegurar que los niveles de habilidad
necesarias, en número suficiente, estarán disponibles para llevar a cabo con éxito el
proyecto de software.
La necesidad de una formación especial puede depender de la naturaleza del
producto a ser desarrollado y las habilidades necesarias para hacer el trabajo. Si
se requiere una formación, un plan de formación debe incluir:
• los tipos de formación que se deben proporcionar,

• número de personal a ser entrenados,
• criterios de entrada y salida para la formación, y
• los métodos de entrenamiento para ser utilizados (por ejemplo, conferencias,
consultas, asesoramiento o formación asistida por ordenador).
Al igual que en todos los planes, el plan de formación del personal debe incluir:
• programar,
• presupuesto,
• hitos, y
• los responsables.
El plan de formación debe incluir la formación necesaria en tanto las habilidades

técnicas y de gestión.
El plan de trabajo (sección 6.2) se describen las actividades de trabajo y los
detalles de horarios, recursos y presupuesto para su proyecto de software. Los
cuatro subsecciones contienen la estructura de desglose del trabajo (EDT) y
paquetes de trabajo, el trabajo activi- lazos a realizar, las dependencias de
programación, asignación de recursos y la asignación del presupuesto.
Sección 6.2.1 (WBS y paquetes de trabajo) documentos:
• el alcance de las actividades de trabajo incluidos en este plan del proyecto,

• compartimentación de las actividades de trabajo,
• el nivel de detalle proporcionado en el plan, y
• documentación de las actividades de trabajo.
El alcance de las actividades de trabajo y la compartimentación de que el trabajo

se especifican en el nivel superior de la EDT. Una EDT es una descomposición
jerárquica de las actividades laborales; es una herramienta fundamental para la
planificación y control de proyectos de software. Durante proyecto de
planificación de una versión inicial de la EDT debe ser desarrollado. Las
actividades de trabajo en la EDT iniciales deben ser descompuestos por lo que:
• estimaciones precisas de las necesidades de recursos y la duración

periodicidad de cada actividad de trabajo principal se pueden hacer,
www.it-ebooks.info
• oportunidades para la reutilización de componentes de software se pueden

identificar y
• factores de riesgo del proyecto están expuestos (tanto a nivel técnico y de
gestión).
El nivel de descomposición de diferentes actividades de trabajo en la estructura

de desglose del trabajo puede ser diferente dependiendo de factores tales como la
calidad de las exigencias, la familiaridad de la obra, la novedad de la tecnología a
utilizar, y los componentes de software para ser reutilizado.
Los paquetes de trabajo se utilizan para especificar, para cada actividad de trabajo,
factores tales como:
• los recursos necesarios,

• duración estimada,
• productos de trabajo a ser producidos,
• criterios de aceptación de los productos de trabajo,
• actividades de trabajo predecesoras y sucesoras y de
• factores de riesgo de la actividad laboral.
Técnicas y directrices para la construcción de la estructura del proyecto y

paquetes de trabajo ING prepa- se presentan en el Capítulo 5.
dependencias horario (sección 6.2.2) indican:
• tareas deben completarse antes de tareas posteriores puedan comenzar;

• tareas que se pueden realizar simultáneamente con otras tareas; y
• restricciones del cronograma impuestas por las dependencias de factores
externos tales como equipos y software suministrado por el proveedor,
software subcontratista-suministrado, y las interfaces con otros componentes
del sistema.
Las tareas son las actividades laborales nivel más bajo en una jerarquía PEP;
también son los elementos de la programación. El cronograma del proyecto debe
incluir hitos frecuentes que se pueden evaluar para lograr utilizando indicadores
objetivos para evaluar el alcance y la calidad de los productos de trabajo
terminados en esos hitos. Las técnicas que se pueden utilizar para especificar las
relaciones de programación incluyen gráficos de hitos, listas de actividades,
redes, redes de horario de la ruta crítica, gráficos PERT, diagramas de Gantt,
actividad y diagramas de Gantt de recursos. Ejemplos e ilustraciones se
proporcionan en el Capítulo 5.
La asignación de recursos (sección 6.2.3) documentos, para cada actividad de
trabajo en la estructura de desglose del trabajo, lo siguiente:
• tipos y cantidades de recursos necesarios (personas y otros recursos),

• cuando son necesarios, y
• por cuanto tiempo.
Recursos que deben asignarse incluyen al personal por nivel de habilidad, y

pueden incluir elementos de hardware, herramientas de software, presupuesto,
instalaciones de ensayo y simulación, y el apoyo administrativo. Una mesa que
los documentos, para cada tarea, los recursos necesarios y cuando la tarea está
previsto que ocurra debe ser proporcionado, además de una tabla inversa que
www.it-ebooks.info
muestra, para cada recurso, las tareas a las que se atribuyen y cuando la tarea es
www.it-ebooks.info
programado para ocurrir. Los datos necesarios para estas tablas se pueden
obtener a partir de los paquetes de trabajo y la red del cronograma.
La asignación del presupuesto (sección 6.2.4) documenta los componentes del
presupuesto asignados a cada actividad de trabajo y la tarea de la EDT. El
presupuesto de tarea por tarea debe incluir el costo estimado para el personal de
nivel de habilidad para llevar a cabo cada tarea (en unidades o personas-hora
monetaria) y puede incluir, según proceda, los costos para artículos tales como
viajes, reuniones con clientes y usuarios, recursos informáticos, herramientas de
desarrollo de software, herramientas de prueba y apoyo administrativo para cada
actividad de trabajo.
Los presupuestos para actividades de más alto nivel en la EDT (la suma de los
presupuestos para actividades de nivel inferior y tareas en la EDT) deben ser
documentados. El presupuesto total para cada tipo de recurso y su suma (el
presupuesto global del proyecto) debe ser proporcionada. La asignación del
presupuesto puede ser desarrollado en forma de tabla usando una hoja de cálculo.
Sección 6.3 del plan de gestión de proyectos (el plan de control del proyecto)
especifica los procedimientos de control que se utilizarán en el cumplimiento de
los requisitos del producto, el calendario, el presupuesto y las normas de calidad
de los procesos de trabajo y productos de trabajo. Además, se debe desarrollar un
plan para la recogida de datos del proyecto y un plan de informes. Cada elemento
del plan de control debe estar en consonancia con las normas de la organización,
políticas y procedimientos para el control de los proyectos de software y debe
satisfacer los acuerdos contractuales para el control del proyecto.
El plan de control de requisitos (apartado 6.3.1) debe abordar las siguientes
cuestiones:
• cómo los requisitos serán aceptadas inicialmente como una línea de base del
producto;
• mecanismos de control que se utilizarán para medir, informar y controlar los
cambios en la línea de base los requisitos; y
• cómo se evaluará el impacto de los cambios en los requisitos de alcance y
calidad del producto, y la programación del proyecto, el presupuesto, los
recursos y factores de riesgo.
mecanismos de gestión de la configuración para el control de los requisitos

debe incluir procedimientos de cambio de control, una herramienta de control de
versiones, y un tablero de control de cambios. Las técnicas que se pueden utilizar
para medir y requisitos de control incluyen la trazabilidad, la creación de
prototipos, análisis de impacto, y las críticas. Estas y otras técnicas se discuten en
el Capítulo 3 de este texto.
El plan de control horario (sección 6.3.2) indica las técnicas que se utilizan
para:
• medir e informar sobre el progreso del trabajo realizado en las mayores y

menores hitos del proyecto,
• comparar el progreso real para el progreso previsto en los hitos y
• aplicar medidas correctivas cuando el progreso real no se ajusta al progreso
previsto.
El logro de los hitos del cronograma debería evaluarse utilizando criterios

objetivos para medir la cantidad y la calidad de los productos de trabajo
www.it-ebooks.info
terminados en cada hito mayor y menor.
El plan de control del presupuesto (sección 6.3.3) se ocupa de:
www.it-ebooks.info
• cómo el costo del trabajo realizado se ha de determinar,

• cómo se tomarán las comparaciones de costos presupuestados a los costes
reales,
• cómo se realizará un seguimiento del coste de las medidas correctivas, y
• herramientas y técnicas que se utilizarán para rastrear y controlar el
presupuesto.
El plan de presupuesto debe incluir hitos frecuentes que se pueden evaluar para
Achievement utilizando indicadores objetivos para evaluar la cantidad y calidad
de los productos de trabajo terminados en esos hitos. Mecanismos como el
seguimiento y presentación de informes binaria del valor ganado se deben utilizar
para medir y reportar el progreso horario y el costo del trabajo realizado frente al
trabajo previsto para su conclusión. Estos mecanismos se describen en el
Capítulo 8.
El plan de control de calidad (sección 6.3.4) documenta los mecanismos que
se utilizarán para medir y controlar la calidad de los procesos de trabajo y los
productos de trabajo en evolución. mecanismos de control de calidad pueden
incluir auditorías de los procesos de trabajo, verificación y validación de los
productos del trabajo, opiniones, análisis de causa raíz, y las evaluaciones de
proceso. la medición del rendimiento técnico se puede utilizar para realizar un
seguimiento de los parámetros técnicos que se asignan a los elementos
individuales del sistema o producto, tales como bytes de memoria real frente
asignados y los ciclos de tiempo de ejecución. Los detalles son RESPETA pro en
los capítulos 7 y 8.
El plan de métricas (sección 6.3.5) se ocupa de las siguientes cuestiones:
• datos de proceso y producto a recoger;

• cómo los datos serán recogidos y validados;
• que recogerá y validar los datos del proyecto;
• métodos, herramientas y técnicas a utilizar;
• frecuencia de la recogida de los diversos tipos de datos métricas;
• mecanismos para la validación de los datos de métricas; y
• cómo se conservaron los datos para su uso futuro.
Procesos y productos métricas para ser recogidos y validados deben ser

coherentes con las necesidades del proyecto y el plan de informes.
El plan de informes (sección 6.3.6) documentos:
• los mecanismos, los formatos de informes y flujos de información que se

utilizarán para comunicar el estado de los requisitos, calendario,
presupuesto, el alcance, la calidad, y otras métricas de estado;
• los tipos de informes que se prepararán;
• que va a preparar y distribuir los informes;
• frecuencia de preparación y distribución de cada tipo de informe;
• formatos que se utilizarán;
• métodos, herramientas y técnicas que serán utilizados; y
• individuos que recibirán copias.
La naturaleza y frecuencia de informes de estado del proyecto deben ser

coherentes con el alcance del proyecto, la criticidad, el riesgo, la visibilidad,
políticas de la organización, y los requisitos contractuales. Métricas e informes se
www.it-ebooks.info
analizan en los capítulos 7 y 8.
www.it-ebooks.info
Sección 6.4 del plan contiene el plan de gestión de riesgos para su proyecto.
Un riesgo es un problema potencial que, si se materializa, tendrá un impacto
negativo en su proyecto. El plan de gestión de riesgos se documentan los
siguientes temas:
• mecanismos que se utilizarán para identificar, analizar y priorizar los

factores de riesgo del proyecto;
• mecanismos para el desarrollo de planes de acción y planes de contingencia;
• los miembros del personal que pondrán en marcha los planes;
• métodos que se utilizan para rastrear los factores de riesgo identificados,
evaluar los cambios en los niveles de los factores de riesgo y responder a
esos cambios;
• los miembros del personal que será responsable del seguimiento de los
factores de riesgo; y
• ¿Cómo se identificarán de forma continua los factores de riesgo, evaluado y
mitigado de manera continua durante el proyecto.
Los tipos de factores de riesgo que deben ser considerados incluyen:
• riesgos en la relación adquirente-proveedor;

• riesgos contractuales;
• riesgos tecnológicos;
• riesgos causados por el tamaño y la complejidad del producto;
• riesgos en los entornos de desarrollo y de destino;
• riesgos en la adquisición de personal, los niveles de habilidad, y la retención;
• riesgos para la programación y el presupuesto;
• riesgos en relación con los proveedores y subcontratistas; y
• riesgos en la consecución de clientes y usuarios la aceptación del producto.
La gestión del riesgo está cubierto en el Capítulo 9.

Los planes de cierre del proyecto (sección 6.5)
documentos:
• condiciones y eventos que indican la finalización del proyecto;

• reuniones y lecciones aprendidas sesiones informativas que se celebrarán post
mortem;
• cómo las lecciones aprendidas y lograron análisis de los objetivos del
proyecto (y no alcanzado) será documentado, distribuido y archivado;
• el plan para materiales de trabajo del proyecto de archivado; y
• ¿Cómo serán reasignados los miembros del proyecto.
El resto de elementos de la plantilla para los planes de gestión de proyectos de

software (procesos técnicos, procesos de apoyo, planes adicionales, apéndices y
el índice) se enumeran en la Tabla 4.4c y discutidos en las siguientes secciones.
4.6.6 Los procesos técnicos

Sección 7 del plan (procesos técnicos) documenta los procesos de desarrollo a
utilizar. Esta es la sección donde se especifica los métodos técnicos, herramientas
www.it-ebooks.info
y
www.it-ebooks.info
Plantilla 4.4C mesa para un Plan de Gestión de Proyectos de

Software (parte 3)
Técnico procesos sección 4.4.6
7. Los procesos técnicos
7.1 Proceso de desarrollo ModelChapter 2
7.2 Métodos, herramientas y técnicas
7.3 plan de Infraestructuras
7.4 Plan de aceptación del producto
Secundario procesos sección 4.4.7

8. Procesos de soporte
8.1 Configuración ManagementChapter 3
8.2 verificación y ValidationChapter 2
8.3 DocumentationChapter 1
8.4 Calidad AssuranceChapter 1
8.5 Los comentarios y AuditsChapter 2
8.6 Problema ResolutionChapter 1
8.7 Subcontratista ManagementChapter 1
8.8 La mejora de procesos
planes adicionales, apéndices índice sección 4.4.8

9. Apéndices
adicionales
Planes
Índice
técnicas a utilizar; planes para establecer y mantener el proyecto de infraestruc-

tura; y el plan de la aceptación del producto.
Sección 7.1 (modelo de proceso de desarrollo) especifica:
• el modelo de proceso de desarrollo que se utilizará para desarrollar el

producto de software, y
• la adaptación del modelo de proceso para este proyecto.
El modelo de proceso de desarrollo debe ser descrito con suficiente detalle para
el documento:
• las relaciones entre las principales actividades de desarrollo y procesos de

apoyo (especificando el flujo de información y de trabajo entre los productos
de las actividades y tareas),
• restricciones de secuenciación entre los productos de trabajo que se generen,
• comentarios que se realicen,
• principales hitos que deben alcanzarse,
• líneas de base que se establezcan,
www.it-ebooks.info
• resultados de los proyectos a ser completado, y

• requiere aprobaciones que abarcan toda la duración del proyecto.
Una combinación de notaciones gráficas y de texto se puede utilizar para describir

el modelo de desarrollo. Cualquier adaptación de modelo de proceso estándar de una
organización debe indicarse en esta sección. modelos de procesos de desarrollo se
describen en el Capítulo 2 de este texto.
Métodos, herramientas y técnicas a utilizar para desarrollar o modificar el
software se especifica en la sección 7.2. Los problemas que deben ser abordados
en esta sección son:
• métodos de desarrollo, técnicas, herramientas de software y lenguajes de

programación y otras notaciones que se utilizan para especificar, diseñar,
construir, probar, integrar documento, entregar y modificar y mantener los
productos de trabajo;
• normas técnicas, políticas, procedimientos y directrices que serán utilizados
para gobernar el desarrollo y / o modificación de productos de trabajo; y
• reglamentos y leyes del gobierno, en su caso, que deben ser observados.
El plan de infraestructura (sección 7.3) se dirige a:
• el plan de establecer y mantener el entorno de desarrollo (Ware hardware,

sistema operativo, red, utilidades de software); y
• instalaciones, políticas, procedimientos y estándares.
los recursos de infraestructura pueden incluir estaciones de trabajo, redes de área

local, escritorios, oficinas, y las disposiciones de seguridad física, personal
administrativo y de servicios de limpieza.
Los planes de la aceptación del producto (sección 7.4)
documentos:
• cómo se obtendrán de usuario y la aceptación del cliente de los productos

entregables de trabajo;
• criterios objetivos que se utilizarán para determinar la aceptabilidad de los
productos de trabajo entregables;
• procesos técnicos, métodos y herramientas que serán utilizadas en la
obtención de la aceptación del producto; y
• en su caso, el acuerdo formal de los criterios de aceptación para ser
preparado y firmado por los representantes de la organización para el
desarrollo y la organización ing acquir- durante la planificación inicial.
Los métodos de validación, tales como las pruebas, la demostración, el análisis, y

la inspección deben especificarse. se debe indicar la relación entre los requisitos,
planes de prueba basada en los requisitos, y la lista de productos de trabajo
entregables requeridos. matrices de trazabilidad pueden utilizarse para este
propósito.
4.6.7 Procesos de soporte

Sección 8 de un plan de gestión de proyecto contiene planes para los procesos de
apoyo que abarcan toda la duración del proyecto de software. Estos planes
pueden incluir, pero no se limitan a los enumerados en la Tabla 4.4c (gestión de
la configuración, verificación y
www.it-ebooks.info
validación, documentación de software, garantía de calidad, revisiones y

auditorías, resolución de problemas y administración de subcontratistas). Los
ocho procesos de apoyo en la Tabla 4.4c son los especificados en la norma IEEE
12207; adaptación de la plantilla para los planes del proyecto puede resultar en la
supresión o modificación de algunos procesos de apoyo. procesos adicionales
pueden añadir según sea apropiado.
Los planes para los procesos de apoyo deben ser desarrolladas a un nivel de
detalle consistente con las otras secciones del plan. En particular, el plan para
cada plan de proceso de apoyo debe incluir:
• roles,
• responsabilidades,
• autoridades,
• programar,
• presupuesto,
• requerimientos de recursos,
• factores de riesgo, y
• productos de trabajo.
La naturaleza de, y tipos de procesos de apoyo necesarias pueden variar de

proyecto en proyecto. Sin embargo, la ausencia de un plan de plan de gestión de
la configuración, verificación y validación, plan de aseguramiento de la calidad,
plan de revisión del cliente-desarrollador conjunta, o un plan de resolución de
problemas debe justificarse expresamente en cualquier plan de gestión de
proyectos de software que no los incluye.
Los planes para algunos procesos de soporte pueden ser desarrollados por
separado por las entidades nizational nizaciones que proporcionen el apoyo. Esos
planes pueden incorporarse directamente en su plan de gestión de proyectos de
software o incorporadas por referencia. planes referenciados son considerados
como parte del plan del proyecto. planes de apoyo pueden estar basados en
procesos de apoyo normales de la organización, que pueden ser incluidos por
referencia.
El plan de gestión de la configuración (sección 8.1 de la PAPS) aborda los
siguientes aspectos:
• productos de trabajo para ser colocado bajo control de versiones;

• cómo se determinará la preparación de productos de trabajo para línea de
base (colocación bajo control de versiones);
• cómo se manejarán las solicitudes de cambio y los informes de problemas
(conectado, analizado y detectado);
• cambiar los procedimientos de control para ser utilizado;
• miembros de la junta de control de cambio;
• ¿Cómo serán notificados los interesados de los cambios en las líneas de base;
• que hará un seguimiento de los cambios en los productos de trabajo y analizar
las tendencias del cambio;
• herramientas automatizadas para ser utilizados para el control de versiones; y
• métodos, herramientas y convenciones que deben ser utilizados para
satisfacer las políticas de la organización, el acuerdo contractual, y los
requerimientos de soporte del producto después de la liberación
www.it-ebooks.info
El (sección 8.2) la verificación y validación del plan se dirige a:
• que va a hacer la verificación y validación (V & V);

• alcance de las actividades que será incluido;
• métodos, herramientas y técnicas que serán utilizados;
• el grado de independencia entre las entidades de desarrollo y las entidades de
V & V del proyecto;
• herramientas automatizadas para ser utilizados para V & V; y
• ¿Cómo se coordinarán las interacciones con un Independiente V & V
organización, en su caso.
la planificación de verificación debería resultar en planes de técnicas tales como

la trazabilidad, mile- opiniones de piedra, revisiones de progreso, revisiones por
pares, creación de prototipos, simulación y modelado. la planificación de
validación debe dar lugar a planes de técnicas tales como pruebas, demostra-
ción, el análisis y la inspección.
El plan de documentación (sección 8.3) debe indicar:
• no entregable y documentos de entrega al que se generarán;

• plantillas o formatos estándar que se utilizarán;
• las personas responsables de proporcionar la información necesaria, la
generación de los diversos documentos, revisión de los mismos, y
aceptarlos;
• documentos que serán puestos bajo control de versiones;
• cuando se requiera que los ejemplares y versiones iniciales de referencia; y
• quién va a obtener copias de las versiones de revisión y líneas de base de los
documentos.
sin entrega documentos pueden incluir:
• especificaciones de requisitos;
• documentación de diseño;
• código fuente;
• matrices de trazabilidad;
• planes de pruebas, actas de las reuniones;
• revisar los informes;
• elementos de acción;
• solicitudes de cambio; y
• informes de defectos.
productos de trabajo entregables pueden incluir:
• código fuente,
• código de objeto,
• manual de usuario,
• en línea sistema de ayuda,
• conjunto de pruebas de regresión,
www.it-ebooks.info
• biblioteca de configuración,
• Principios de Operación,
• guía de mantenimiento y
• cualesquiera otros elementos especificados en la sección 1.4 del plan de
proyecto (entregables del proyecto).
El plan de aseguramiento de la calidad (sección 8.4) se dirige a:
• cómo se proporcionará la seguridad de que el proyecto de software está

cumpliendo con sus compromisos a los procesos de software y productos
de trabajo planificadas como se especifica en los requisitos, plan de gestión
de proyectos de software, planes de apoyo y de las políticas, normas,
procedimientos o directrices a las que el procesar o el producto debe
adherirse;
• quien será responsable del proceso y la garantía de producto; y
• las autoridades, responsabilidades y líneas de comunicación para los que será
responsable del proceso y la garantía del producto.
procedimientos de garantía de calidad pueden incluir análisis, revisión, auditorías

y evaluaciones. El plan de control de calidad debe indicar las relaciones entre los
procesos de evaluación de control de calidad, verificación y validación, revisión,
auditoría, gestión de la configuración, y. El plan de aseguramiento de la calidad
debe ser desarrollado y ejecutado por una entidad de organización (o entidades)
independientes de ustedes, el director del proyecto, y se incorporan por referencia
en su plan de proyecto.
El plan para las revisiones y auditorías (sección 8.5)
documentos:
• los tipos de revisiones y auditorías que se realizarán;

• que llevará a cabo ellos; y
• horarios, recursos, métodos y procedimientos que se utilizarán para llevar a
cabo la revisión de proyectos y auditorías de proyectos.
Este plan debe incluir planes para una revisión conjunta del cliente-desarrollador,
revisiones por la dirección, desarrollador revisiones por pares, auditorías de
garantía de calidad y auditorías de los clientes. elementos de este plan deben ser
coherentes con las políticas institucionales, acuerdos contractuales del proyecto y
otros documentos contractuales.
El plan de resolución de problemas (sección 8.6) indica:
• cómo se informarán los problemas en los procesos de trabajo y productos de

trabajo, Ana-lyzed, priorizados, y resueltos;
• cómo los problemas se realizará un seguimiento de cierre;
• las funciones de las entidades de organización tales como el desarrollo, la
configuración management, la junta de control de cambio, verificación y
validación, y aseguramiento de calidad en la resolución de problemas;
• cómo se manejará la relación entre la resolución de problemas y gestión de
riesgos (apartado 5.4); y
www.it-ebooks.info
• cómo el esfuerzo dedicado a la presentación de informes de problemas,

análisis y resolución será separado informó de manera que retrabajo puede
ser rastreado y procesos necesarios mejoras identificadas.
planes de gestión subcontratista (sección 8.7) Dirección:
• ¿Cómo serán seleccionados los subcontratistas;

• quien será responsable de la preparación de planes de gestión de los
subcontratistas;
• quién será responsable de proporcionar las interfaces técnicas y de gestión a
los subcontratistas; y
• mecanismos de medición, notificación, y el control que se utilizarán.
Los planes para la gestión de los subcontratistas deben incluir los elementos
necesarios para asegurar la terminación exitosa de cada subcontrato. En
particular, los planes para:
• monitoreo del progreso técnico,
• horario y la información presupuestaria,
• criterios de aceptación del producto, y
• procedimientos de gestión de riesgos
deben ser incluidos en cada plan subcontratista. Los temas adicionales deben
añadirse según sea necesario para la finalización con éxito de cada subcontrato.
Una referencia a la subcontratación oficial y el principal contratista /
subcontratista puntos de contacto debe ser proporcionada.
Un plan para la mejora de procesos (sección 8.8)
documentos:
• la frecuencia de evaluación para determinar las áreas de mejora,

• que va a hacer las evaluaciones de los proyectos,
• que van a desarrollar e implementar planes de mejora, y
• que se pondrá en marcha planes de mejora.
El plan de mejora de proceso debe estar estrechamente relacionada con los planes
de gestión de riesgos y de resolución de problemas. Por ejemplo, análisis de la
causa raíz de los problemas recurrentes puede conducir a mejoras en los procesos
simples que pueden reducir significativamente la reanudación durante el resto del
proyecto. Las mejoras propuestas deben ser examinadas cuidadosamente para
identificar aquellos procesos que se pueden mejorar sin interrupciones graves a
su proyecto en curso e identificar aquellos procesos que mejor se pueden mejorar
mediante iniciativas de mejora de procesos a nivel de organización.
4.6.8 Planes adicionales, apéndices, Índice

Sección 9 ofrece planes adicionales que se deben incluir en su plan de gestión de
proyectos de software, según el caso. La siguiente cuestión debe abordarse:
www.it-ebooks.info
• planes adicionales necesarios para satisfacer los requisitos del producto, el

CIES POLI organización, y las condiciones contractuales;
• que los preparará; y
• quien los ejecutará.
planes adicionales para un proyecto en particular puede incluir planes para:
• asegurar que se cumplen los requisitos de seguridad o de seguridad especiales

para el producto,
• instalaciones o equipos especiales,
• la instalación del producto,
• entrenamiento de usuario,
• Integración de sistema,
• conversión de datos,
• transición del sistema,
• mantenimiento del producto, o
• planes de soporte de producto.
Los apéndices se pueden incluir en un plan de proyecto para proporcionar

detalles de apoyo que iría en detrimento del plan si se incluye en el cuerpo del
plan. Un índice de los términos y acrónimos utilizados en el plan del proyecto es
opcional, pero se recomiendan especialmente para mejorar la usabilidad del plan.
Los detalles de los mecanismos utilizados para preparar y ejecutar un plan de
proyecto son RESPETA pro en los capítulos siguientes de este texto.
4.7 TÉCNICAS DE PREPARACIÓN un plan de proyecto
La preparación de un plan de gestión de proyectos de software utilizando la lista

presentada en las Tablas 4.4a, byc, y se describe en la Sección 4.4 será abrumador si,
solo, se enfrenta con el desarrollo de todos los elementos del plan para un gran
proyecto. Hay varios factores que deben reducir el tiempo y el esfuerzo que tendrá
que invertir en la preparación de un plan de proyecto.
4.7.1 Adaptación de la plantilla de plan de proyecto

Sastrería se ocupa de añadir, eliminar y modificar elementos de la plantilla para
su plan de proyecto. Si usted está planeando un proyecto para un cliente interno
en un entorno de desarrollo familiar y bien definido utilizando un pequeño
equipo de desarrolladores de software mentado experimentos y un conjunto
estándar de apoyo a los procesos de su adaptación de las tablas 4.4a, byc puede
dar lugar a la adaptación indica mediante la supresión de los elementos
indicados:
Prefacio Título de
la página
Historial de
revisiones
Tabla de contenido
www.it-ebooks.info
4.7 TÉCNICAS DE PREPARACIÓN un plan de proyecto 151
Lista de figuras
Lista de tabla
1 Resumen del proyecto
1.2 Suposiciones y Restricciones
1.3 Entregables del proyecto
1.4 Cronograma y del Presupuesto
2 Evolución del Plan
3 referencias
4 definiciones
5 Organización del proyecto
5.1 Interfaces de proyectos
5.2 Estructura del proyecto
5.3 Funciones y responsabilidades
6 Los procesos de gestión
6.1 La puesta en marcha del Plan
6.1.1 Estimación de Proyectos
6.1.2 Plan de personal
6.2.1 WBS y Paquetes de Trabajo
6.2.2 dependencias de horario
6.2.3 Asignación de recursos
6.2.4 Asignación de presupuesto
6.3 Plan de Control de Proyectos
6.3.1 requisitos
6.3.2 Programar
6.3.3 Presupuesto
6.3.4 Calidad
6.3.5 plan de métricas
6.3.6 plan de la presentación de informes
6.4 Plan de gestión de Riesgos
7 Los procesos técnicos
7.1 Proceso de Desarrollo de Modelo
8 Procesos de soporte
8.1 Gestión de la configuración
8.2 Verificación y validación
8.3 Documentación
8.4 Seguro de calidad
8.5 Revisiones y auditorías
8.6 Resolución de Problemas
8.7 Gestión subcontratista
8.8 La mejora de procesos
www.it-ebooks.info
9 adicionales Apéndices
Planes
Índice
El plan a la medida tendría el formato resultante:
Página de título
revisión histórica
1 Resumen del proyecto
1.2 Suposiciones y Restricciones
1.3 Entregables del proyecto
1.4 Cronograma y del Presupuesto
3 Referencias
6 procesos de gestión
6.1.1 Plan de estimación de proyectos
6.2.1 WBS y Paquetes de Trabajo
6.2.2 dependencias de horario
6.3.1 Requisitos del Plan de Control
6.4 Plan de Gestión de Riesgos
7.4 Producto Plan de Aceptación
Sastrería no pretende dar a entender que los elementos eliminados sean

importantes, sino que se llevará a cabo de la forma habitual, familiar (por
ejemplo, gestión de la configuración, verificación y validación) y no necesitan ser
documentados en el plan del proyecto, o que son no aplicable a este proyecto (por
ejemplo, no existe un plan subcontratista porque no hay subcontratistas). Los
casos en que no se suprimiría elementos son, por ejemplo, casos en que el
proceso que se utilizará (por ejemplo, para CM o QA) difiere del proceso de
organización estándar.
Para mantener la coherencia entre los planes de proyecto dentro de su
organización, debe conservar el esquema de numeración de la plantilla para los
planes del proyecto.
4.7.2 Incluyendo predefinidas Elementos

Su organización puede tener políticas, procedimientos, listas de verificación,
plantillas de documentos, uno o más modelos de procesos estándares, guías de
adaptación, y los ejemplos que se pueden utilizar para guiar a su preparación de
la versión inicial de su plan de proyecto. Esto puede reducir significativamente el
tiempo y el esfuerzo necesarios.
4.7.3 Usando Apoyo Organizacional

Su organización puede tener consultores internos y expertos que pueden ayudarle
con áreas tales como la definición de los requisitos, la adaptación del proceso
estándar de desarrollo de la organización, el costo y el horario de estimación, la
gestión de riesgos, gestión de la configuración, la adaptación y la preparación de
planes de proyectos, y disciplinas de la especialidad tales como factores
humanos, la seguridad, la seguridad y la fiabilidad.
www.it-ebooks.info
4.7 TÉCNICAS DE PREPARACIÓN un plan de proyecto 153
4.7.4 Al frente de un equipo de planificación

Los proyectos pequeños tienen planes pequeños debido a que el número de
actividades de trabajo que se planificó y coordinó es pequeña y porque los
proyectos a menudo se producen en entornos estables y bien definidas; grandes
proyectos tienen correspondientemente grandes planes. Si usted es el jefe de
proyecto de un gran proyecto de su actividad principal de planificación puede
implicar la coordinación de los esfuerzos de un equipo de planificación y la
integración de su trabajo en un plan integral de gestión de proyectos. Los
miembros del equipo pueden incluir especialistas en áreas tales como los
mencionados anteriormente ingeniería (requisitos, la adaptación del proceso de
elaboración de normas de la organiza- ción, el costo y el horario de estimación, la
gestión de riesgos, gestión de la configuración, la adaptación y la preparación de
planes de proyectos, y disciplinas de la especialidad tales como factores
humanos, la seguridad, la seguridad y fiabilidad).
En los casos de proyectos grandes y complejos es posible que tenga un “plan
para la planificación.” Como todos los planes, un plan para la planificación debe
incluir aspectos tales como:
• roles,
• responsabilidades,
• autoridades,
• programar,
• presupuesto,
• recursos,
• factores de riesgo, y
• productos de trabajo.
4.7.5 Planificación incremental

Su plan inicial del proyecto debe ser suficientemente amplio para incluir todas las
actividades de trabajo en el marco de su proyecto. El nivel de detalle en su plan
inicial debe satisfacer los siguientes criterios:
1. el alcance del plan incluye todas las principales actividades de trabajo, que
deberán realizarse
2. Se identifican oportunidades para la reutilización de los componentes
existentes;
3. Esfuerzo, calendario, y los recursos para cada actividad de trabajo pueden
ser identificados estimación se aparearon con confianza;
4. actividades predecesor y sucesor para cada actividad de trabajo se
especifican y un calendario es determinado; y
5. Se identifican complejidades y factores de riesgo.
Diferentes actividades de trabajo pueden descomponerse a diferentes niveles.

actividades de trabajo familiar y componentes identificados para su reutilización
en el producto puede satisfacer los criterios a un alto nivel; de trabajo, factores de
riesgo desconocidas en base a las incertidumbres, y el uso de las nuevas
tecnologías pueden indicar la necesidad de incorporar los estudios de viabilidad
de creación de prototipos y en el plan.
Durante la ejecución del proyecto del plan se actualiza y se elaboró como se
www.it-ebooks.info
especifica en el apartado 2 de su plan (evolución del plan). Por ejemplo, es
posible que el plan para actualizar
www.it-ebooks.info
su plan de proyecto sobre una base mensual o cuando los factores externos como
los cambios en las necesidades del cliente, dificultades con los subcontratistas, o
retrasos en la entrega de componentes de hardware dictan la necesidad de nueva
planificación.
• Los requisitos operativos, especificaciones técnicas, y las restricciones del

proceso proporcionan la base para la planificación de proyectos.
• Un plan de gestión de proyectos de software es un documento de referencia
controlado por escrito. 4B apéndice de este capítulo proporciona un modelo
para el desarrollo de planes de gestión de proyectos de software basado en el
estándar IEEE 1058; una copia electrónica está disponible en la URL que
aparece en el prefacio de este texto.
• La plantilla completa de los planes de gestión de proyectos de software
presentado en las Tablas 4.4a, byc puede ser, y debe ser, adaptado a las
necesidades de cada proyecto, como en el ejemplo de la adaptación.
• El desarrollo de un plan de gestión de proyectos de software, como todos los
procesos de ingeniería de software, se logra mejor manera iterativa. La
versión inicial del plan debe ser actualizado de manera periódica y como
eventos requieren.
• El nivel de esfuerzo dedicado a la planificación del proyecto, y el nivel de
detalle en un plan de proyecto, tanto inicialmente como en curso, están
determinadas por los factores de riesgo creadas por no hacer más.
• El nivel de detalle en su plan de proyecto inicial debe cumplir los siguientes
criterios: esfuerzo, calendario, y los recursos para cada actividad de trabajo
identificadas se pueden estimar con confianza; actividades predecesor y
sucesor para cada actividad de trabajo pueden ser determinados; Se
identifican oportunidades para la reutilización de los componentes
existentes; y se identifican los factores de riesgo y complejidad.
• opciones aceptables para la obtención de un equilibrio entre el esfuerzo, el
calendario y los requisitos de su plan de proyecto incluyen descoping los
requisitos, lo que aumenta la cantidad de recursos, el uso de los recursos más
productivas, ampliando el horario, y combinaciones de estas opciones.
• opciones inaceptables para lograr un equilibrio entre el esfuerzo, el
calendario y los requisitos incluyen descoping los planes de medición y
control, revisiones por pares, verificación y validación, y la planificación
para el esfuerzo de horas extras.
• SEI, ISO, IEEE, y PMI proporcionan marcos, normas y directrices para la
planificación del proyecto (véase el Apéndice 4A de este capítulo)
Referencias
[BOEHM04] Boehm, B., y R. Turner. Equilibrar la agilidad y la disciplina. Addison Wesley,

2004.
[CMMI06] SEI, CMMI® Modelos y Módulos. http://www.sei.cmu.edu/CMMI/models/, 2006.
[IEEE1058] IEEE Std 1058 ™ -1998. Norma IEEE para los planes de gestión de
proyectos de software. Normas Colección de ingeniería. IEEE producto:
SE113. Instituto de Ingenieros Eléctricos y Electrónicos, agosto de 2003.
www.it-ebooks.info
CEREMONIAS 155

[PMI04] Una guía para la Dirección de Proyectos del Conocimiento, 3ª ed. (PMBOK ®
Guía). Project Management Institute, 2004.
[SACMM02] SEI, Software de Adquisición Capability Maturity Model (CMM-SA), versión
1.03. http://www.sei.cmu.edu/publications/documents/02.reports/02tr010.html
CEREMONIAS
4.1. CMMI-DEV-v1.2 enumera cuatro áreas de procesos relacionados con el área

de proceso de planificación del proyecto:
requisitos de desarrollo,
gestión de requisitos,
gestión de riesgos, y la
solución técnica.
Acceder al sitio Web en CMMI http://www.sei.cmu.edu/publications/docu-
mentos / 06.reports / 06tr008.html, revisar el área de proceso de planificación
del proyecto, y explicar brevemente cómo cada una de las cuatro áreas de
procesos relacionados con ellos se refieren a la planificación del proyecto.
4.2. ¿Qué factores de riesgo se crean si un proyecto no tiene un plan de trabajo
escrito?
4.3. ¿Qué factores de riesgo son creados si un jefe de proyecto no mantiene un
control de línea de base del plan del proyecto?
4.4. Describe brevemente las formas en que cada uno de A continuación se
proporciona una base para la planificación de proyectos:
a. requerimientos operacionales
b. especificaciones de software
c. restricciones del proceso
d. restricciones de productos
4.5. Explique brevemente por qué la identificación de oportunidades para la
reutilización de los componentes existentes es un aspecto importante de la
planificación del proyecto.
4.6. ¿Por qué es la planificación para el esfuerzo de horas extras una opción
inaceptable en un plan de proyecto?
www.it-ebooks.info
ANEXO 4A

para la planificación
4A.1 LA CMMI-DEV-v1.2 PROYECTO área de planificación PROCESO
Planificación de proyectos es un área de proceso de nivel 2 en la representación por

etapas del marco de proceso DEV-v1.2 CMMI- [CMMI06]. De acuerdo con CMMI-
DEV-v1.2:
El propósito de Planificación del Proyecto (PP) es establecer y mantener planes que

definen las actividades del proyecto.
Las metas específicas y prácticas específicas de la planificación del proyecto son:
SG 1 establecer estimaciones
SP 1.1 Estimación del Alcance del Proyecto
SP 1.2 establecer estimaciones de Producto de Trabajo y el Grupo
de Atributos SP 1.3 Definición del ciclo de vida del proyecto
SP 1.4 determinar las estimaciones de esfuerzo
y costo SG 2 Desarrollar un plan de proyecto
SP 2.1 Establecer el presupuesto y
calendario SP 2.2 Identificar los riesgos del
proyecto
SP 2.3 Plan de Gestión de Datos SP
2.4 Plan de Recursos del Proyecto
SP 2.5 Plan de conocimientos necesarios y
Habilidades SP 2.6 Plan de Participación de los
interesados
SP 2.7 Establecer el Plan SG
Proyecto 3 Obtener compromiso con
el plan
SP 3.1 Planes de revisión que afectan a los
niveles de proyecto SP 3.2 conciliar trabajo y
de recursos SP 3.3 Obtener Plan de
Compromiso
156
www.it-ebooks.info
4A.2 ISO / IEC e IEEE / EIA NORMAS 12207 157
áreas de procesos relacionados son:
• Desarrollo requisitos
• Gestión de riesgos
• Solución técnica
Como se discutió en el capítulo 1, IEEE Standard AIE / 12207-1.996 es la

implementación en la industria de la Norma Internacional ISO / IEC 12207:
1995; es la norma general para los procesos del ciclo de vida del software para la
serie de ingeniería de software estándares del IEEE. 12207 consta de tres
documentos: 12207.0, cesos ciclo de vida de software pro; 12207.1: Los datos del
ciclo de vida; y 12207.2, Consideraciones sobre la aplicación [IEEE12207].
Sección 5.2 de 12.207,1, afirma que el objetivo genérico de todos los planes es
especificar las actividades a realizar y el estado de cuándo, cómo y por quién se
llevarán a cabo las actividades.
De acuerdo con 12207.1, cada tipo de plan, si se trata de un plan de proyecto,
un plan de gestión de con- figuración, un plan de aseguramiento de la calidad, un
plan de formación, u otro tipo de plan debe contener la siguiente información
genérica:
• tiene que ser satisfecha;

• criterios de éxito;
• actividades de trabajo que hay que realizar;
• cronograma, presupuesto y recursos;
• medidas de control de calidad;
• modificar los procedimientos y el seguimiento de la historia del proyecto;
• interfaces a las partes interesadas pertinentes;
• papeles para ser jugado;
• responsabilidades y autoridades; y
• plan de adquisición de recursos.
De acuerdo con 12207.1, los contenidos específicos de un plan de gestión de

proyectos incluye elementos tales como
• software de modelo de ciclo de vida;

• proyectar las relaciones estructurales;
• autoridad y responsabilidad de cada unidad organizativa;
• la infraestructura de ingeniería para ser utilizado, incluyendo elementos tales
como ronment la prueba bientes, normas, procedimientos y herramientas;
• una estructura de división del trabajo;
• la programación de actividades y tareas;
• plan de gestión de la calidad;
www.it-ebooks.info
• plan de gestión de la configuración;

• planes de gestión subcontratista, según proceda;
• planes de verificación y validación;
• plan de gestión de Riesgos;
• plan de seguimiento y presentación de informes;
• planes para la participación de la adquirente y los usuarios;
• plan de entrenamiento; y
• politica de seguridad.
IEEE estándar EIA / 1058-1998 es el estándar IEEE para Planes Ment Manage-
proyecto de software. El formato y contenido de los planes del proyecto en base a
1058 se presentan en este capítulo [IEEE1058].
4a.4 el PMI cuerpo de conocimientos
Sección 4.3 de la Guía para la Dirección de Proyectos del Conocimiento

[PMI04], Desarrollar el Plan de Gestión de Proyectos, establece que el plan de
gestión de proyecto integrado rejillas y coordina todos los planes subsidiarios.
planes subsidiarios incluyen, pero no se limitan a:
• plan de gestión del alcance del proyecto,

• plan de gestión de la programación,
• plan de gestión de costes,
• plan de gestión de la calidad,
• plan de mejora de procesos,
• plan de gestión de personal,
• plan de gestión de la comunicación,
• plan de gestión de riesgos, y
• plan de gestión de las adquisiciones.
Cada uno de los planes subsidiarios se detalla en la medida requerida por el

proyecto específico. En la sección 1.1, Objetivo de la guía PMBOK, se insiste en
que el equipo de gestión de proyectos es responsable de determinar lo que es
apropiado para cualquier proyecto dado.
www.it-ebooks.info
ANEXO 4B
Esbozo anotado los planes de gestión de

proyectos de software, BASADO EN
estándar IEEE 1058
OBJETIVO 4B.1
Este esquema describe el formato y contenido de los planes de gestión de

proyectos de software basado en la norma IEEE 1058. La norma no especifica las
técnicas exactas para ser utilizados en el desarrollo de un plan de gestión de
proyectos de software, ni proporciona ejemplos de planes de gestión de proyectos
de software. Cada organización utilizando esta norma debe desarrollar un
conjunto de prácticas y procedimientos para proporcionar Ance guid- detallada
de la preparación y actualización de los planes de gestión de proyectos de
software basados en el estándar. Estas prácticas y procedimientos deben tener en
cuenta los factores mentales, organizacionales y políticos ambientes que influyen
en la aplicación de la norma.
No todos los proyectos de software tienen que ver con el desarrollo del código
fuente de un nuevo producto de software. Algunos proyectos de software
consisten en un estudio de viabilidad y definición de los requisitos del producto.
Otros proyectos de software terminan en ción complemento del diseño del
producto, y algunos proyectos tienen que ver con importantes modificaciones a
los productos de software existentes. La norma es aplicable a todo tipo de
proyectos de software; aplicabilidad no se limita a los proyectos que se
desarrollan código fuente para los nuevos productos. Tamaño del proyecto o el
tipo de producto de software no limita la aplicación de esta norma. Los proyectos
pequeños pueden requerir menos formalización en la planificación de grandes
proyectos, pero todos los componentes de la norma debe ser abordado por todos
los proyectos de software.
proyectos de software a veces son partes componentes de los proyectos más
grandes. En estos casos, el plan de gestión de proyectos de software puede ser un
componente separado de un plan mayor o puede estar fusionado en un nivel de
sistema o plan de gestión de proyectos a nivel de negocio. Varias partes de un
plan de proyecto pueden ser adaptaciones de, o implementaciones directas de las
políticas de la organización de desarrollo, los procedimientos y líneas directrices.
En estos casos, las referencias a esos documentos pueden ser incluidos con la
información appro- piado sastrería. Por ejemplo, los procedimientos de garantía
de calidad para el
159
www.it-ebooks.info
proyecto puede ser “la misma manera que siempre lo hacemos.” En ese caso, la
sección de planificación de control de calidad del plan de proyecto podría
incorporar una referencia a las políticas de la organización de control de calidad,
estándares y procedimientos además de una descripción de los horarios y los
recursos necesarios para el control de calidad en este proyecto.
4B.2 evolución de los planes
El desarrollo de la versión inicial del plan de gestión de proyectos de software

debe ser una de las primeras actividades que esté terminado para un proyecto de
software. A medida que el proyecto evoluciona, la naturaleza del trabajo a
realizar será mejor comprendida y planes será más detallada. En adición de
requisitos cambiarán, el personal van y vienen, y las condiciones del proyecto
van a cambiar. Así, el plan del proyecto debe contener un plan para la revisión
del plan a intervalos periódicos y en la ocurrencia de eventos inusuales. Cada
versión del plan del proyecto debe ser colocado bajo control de versiones, y cada
versión debe contener un programa de actualizaciones posteriores al plan.
4B.3 RESUMEN
El formato y contenido típico de los planes de gestión de proyectos de software

se describen en este documento. Un plan de gestión de proyectos de software es
el documento de control para la gestión de un proyecto de software; que define
los procesos técnicos y administrativos necesarios para desarrollar los productos
de trabajo de software que satisfagan los requisitos del producto.
Algunas organizaciones pueden tener planes de proyectos genéricos basados
en este estándar, por lo que el desarrollo de un plan de proyecto en particular
implicará la adaptación del plan genérico en áreas tales como el modelo de
procesos, procesos de apoyo, y la infraestructura y la adición de elementos únicos
en proyectos tales como el horario, presupuesto, las actividades de trabajo, y el
plan de gestión de riesgos.
4B.4 formato de un PLAN DE GESTIÓN PROYECTO SOFTWARE
El individuo u organización responsable de la realización de un proyecto de

software también deben ser responsables de la preparación del plan de gestión de
proyectos de software (PAPS). El contorno de los elementos de una SPMP se
proporciona en la Tabla 4A1.1.
El orden de los elementos presentados en la Tabla 4A1.1 no pretende dar a
entender que las secciones deben desarrollarse en ese orden. El orden de los
elementos está destinado a facilitar la lectura, presentación, y el uso, y no como
una guía para el orden de preparación de los diversos elementos de un SPMP. Las
diversas secciones y subsecciones de un PAPS pueden incluirse por
incorporación directa o por referencia a otros planos y documentos.
Cada versión de un PAPS en base a este esquema debe contener una portada,
una página de la naturaleza sig-, y un historial de cambios.
www.it-ebooks.info
TABLA 4A1.1 Formato de un Plan de Gestión de Proyectos de Software
Título de la
página Página de
firma historial de
cambios Prefacio
Tabla de
contenidos Lista
de Figuras
Lista de mesas
1 Visión de conjunto
1.1 Resumen del proyecto
1.1.1 Propósito, alcance y objetivos
1.1.2 Suposiciones y Restricciones
1.1.3 Entregables del proyecto
1.1.4 Cronograma y del Presupuesto Resumen
1.2 Evolución del Plan
2 referencias
3 definiciones
4 Organización del proyecto
4.1 Interfaces externas
4.2 Estructura interna
5 Planes proceso de gestión
5.1 Plan de puesta en marcha
5.1.1 plan de estimación
5.1.2 Plan de personal
5.2.1 Actividades de trabajo
5.2.2 Asignación de horario
5.2.3 Asignación de recursos
5.2.4 Asignación de presupuesto
5.3 Plan de control
5.3.1 Plan de requisitos de control
5.3.2 Plan de Control de Horarios
5.3.3 Plan de Control de Presupuesto
5.3.4 plan de control de calidad
5.3.5 plan de la presentación de informes
5.3.6 Plan de recopilación de métricas
6 Planes proceso técnico
6.1 Modelo de proceso
7 Apoyar planes de procesos
7.1 Plan de Gestión de la Configuración
7.2 Verificación y validación del Plan
7.3 plan de documentación
7.4 Plan de garantía de calidad
7.5 Revisiones y auditorías
7.6 Plan de Resolución de Problemas
7.7 Plan de Gestión de subcontratistas
7.8 Plan de Mejora de Procesos
8 Planes
adicionales anexos
Índice
www.it-ebooks.info
Pagina del titulo

La página del título debe contener:
nombre del proyecto

número de versión de la
organización emisora plan
de
Página de firmas
La página de la firma debe contener la firma (s) y título (s) de las personas
responsables de la aprobación del PAPS.
cambia la historia
El historial de cambios debe incluir una lista de todas las versiones anteriores del
plan:
fecha de número
de versión de las
secciones de
liberación
cambió la
naturaleza de los
cambios
Prefacio
El prefacio de la PAPS debe describir:
alcance y el contexto de la audiencia

del plan previsto
Tabla de
contenidos Lista
de figuras
lista de mesas
ESTRUCTURA 4b.5 Y CONTENIDO DEL PLAN
1 DESCRIPCIÓN DEL PROYECTO
Esta sección de la PAPS contiene la siguiente información: el propósito, alcance

y objetivos del proyecto; los principales supuestos y limitaciones, una lista de
entregables del proyecto, un resumen de la programación del proyecto y el
presupuesto y el plan para la evo- lución de la PAPS.
1.1 Resumen del proyecto

1.1.1 Propósito, alcance y objetivos (subcláusula 1.1.1 de la PAPS)
www.it-ebooks.info
Propósito: ¿por qué estamos haciendo este proyecto? ¿En qué negocio o las
necesidades del sistema han de ser satisfechos por los resultados del
proyecto?
www.it-ebooks.info
ESTRUCTURA 4b.5 Y CONTENIDO DEL PLAN 163
Alcance: ¿qué actividades se incluyen en este proyecto? ¿Cuál es la relación

de este proyecto a otros proyectos y procesos de trabajo en curso?
Objetivos: ¿qué es lo que deseamos resultados? ¿Qué productos de trabajo se
van a Ered deliv-? ¿Cómo se determinará la satisfacción de los objetivos?
Exclusiones: ¿qué factores objetivos y alcance se excluyen expresamente de
este proyecto y / o los productos de trabajo resultantes.
1.1.2 Suposiciones y Restricciones
Supuestos: ¿cuáles son las condiciones que hemos asumido será verdad para
este proyecto?
Restricciones: qué limitaciones han sido impuestas a factores tales como el
calendario, el presupuesto, los recursos disponibles, el software para ser
reutilizado, la tecnología a emplear, y / o interfaces del producto a otros
productos?
1.1.3 Entregables del proyecto ¿Qué productos de trabajo vamos a entregar al

cliente? ¿Cuándo y dónde hay que les entregue? En qué cantidades y en lo que
los medios de comunicación? ¿Hay algún envase o instrucciones especiales de
manipulación? ¿Hay otro documento, tales como CDRL (Lista de datos
Requisitos del contratista) o PPL (lista de piezas de programa), que contiene la
lista de entregables? Si es así, dónde se puede encontrar este documento?
1.1.4 Cronograma y del Presupuesto Resumen ¿Cuál es el marco de tiempo

para este proyecto? ¿Cuál es el costo total (en dólares o personas-hora)? Cuando
están programados para producirse los hitos más importantes? ¿Cuáles son los
principales procesos de apoyo y planes adicionales para el proyecto?
1.2 Evolución de la SPMP

¿Cuál es el calendario previsto para la actualización periódica de la PAPS? ¿En
qué condiciones se producirán cambios no programados? ¿Cómo se controlaban
los cambios en el plan? ¿Qué métodos se utilizan para emitir cambios a los
interesados apropiados?
2 Referencias
Donde se pueden encontrar documentos adicionales relacionados con este plan?

(Por ejemplo, el Concepto de Operaciones, especificación de los requisitos del
sistema, software de especificación de requisitos, y / o CDRL). normas y
directrices aplicables, tales como IEEE o normas tasa Corpora- para el plan del
proyecto y los procesos de apoyo, deben ser incluidos. Los nombres de ruta
deben ser proporcionados por el acceso a los archivos electrónicos.
3 DEFINICIONES
¿Cuáles son los significados de los términos y acrónimos utilizados en este

documento? Lo otro documento que contenga la terminología necesaria para
entender este plan (por ejemplo, el estándar IEEE 610-12).
www.it-ebooks.info
4 ORGANIZACIÓN DEL PROYECTO
Esta sección de la SPMP identifica interfaces con entidades de organización

externa al proyecto, describe la estructura interna de la organización del proyecto,
y define las funciones y responsabilidades para el proyecto.
4.1 Interfaces externas

¿Cuáles son las entidades de organización externa al proyecto y dónde están los
puntos de contacto entre el proyecto y las entidades? pueden existir interfaces
externas entre el proyecto y la organización matriz, la adquisición de la
organización, subcontratistas, y proyectos afiliados. organigramas y diagramas
pueden ser utilizados para describir las interfaces de organización del proyecto.
4.2 Estructura interna

¿Cómo se organiza el equipo de desarrollo? ¿Cómo funciona el equipo de
desarrollo de interactuar con el apoyo de entidades como la gestión de
configuración, control de calidad, la verificación y la validación? ¿Dónde están
los puntos de contacto y cuáles son las líneas de comunicación? dispositivos
gráficos tales como organigramas o diagramas pueden ser utilizados para ilustrar
las líneas de autoridad, responsabilidad y comunicación dentro del proyecto.

¿Qué unidades de organización son responsables de las diferentes actividades de
trabajo y procesos SUP- portar? Una matriz que relaciona las actividades de
trabajo y procesos de apoyo a las unidades de organización se puede usar para
representar las funciones y responsabilidades del proyecto.
5 PLANES proceso de gestión
Esta sección de la PAPS especifica el proyecto de plan de puesta en marcha, el

plan de gestión de riesgos, el plan de trabajo del proyecto, el plan de control del
proyecto y el plan de cierre del proyecto.
5.1 Proyecto de puesta en marcha del Plan

Proyecto de puesta en marcha implica el desarrollo de un plan de estimación y
haciendo estimaciones, el desarrollo de un plan de personal, un plan para otros
recursos necesarios, y un plan de entrenamiento para el equipo del proyecto.
Dependiendo del tamaño y el alcance del proyecto, estos planes pueden
incorporar directamente en el PAPS, o el PAPS pueden contener referencias a
otros documentos y archivos electrónicos que contienen los planes de puesta en
marcha.
5.1.1 plan de estimación ¿Cuál es el plan para hacer compañeros estimación

inicial y permanente? ¿Cuáles son los detalles del costo del proyecto, el
cronograma, las necesidades de personal y otros recursos? ¿Qué métodos,
herramientas y técnicas se utilizaron para hacer la estimación
www.it-ebooks.info
compañeros? ¿Qué información histórica se utilizó? ¿Cuál es el nivel de con-

fidence en la estimación del estimador? ¿Cómo van a re-estimaciones periódicas
estar hechos de costos, plazos, personal y otros recursos necesarios para
completar el proyecto? ¿Con qué frecuencia se hará volver a la estimación?
¿Cuál es el plan para volver a estimar cuando los requerimientos u otras
condiciones del proyecto cambian?
5.1.2 Plan de personal ¿Qué habilidades se necesitan? ¿Cuántas personas

tienen lo que los niveles de habilidad son necesarias? ¿Cuándo van a ser
necesarios? ¿Por cuanto tiempo? ¿Cómo se obtienen las personas? ¿Quién es
responsable de adquirir el personal necesario? Las técnicas tales como diagramas
de Gantt, histogramas de recursos, hojas de cálculo y las tablas se pueden utilizar
para describir el plan de personal por nivel de habilidad, por fase del proyecto, y
por agregaciones ciones de los niveles y fases del proyecto.
5.1.3 Plan de Adquisición de recursos ¿Qué recursos, además de las personas,

son necesarias? ¿Cuándo se necesitan? ¿Quién es responsable de su adquisición?
Lo aprobaciones se requieren? El plan de adquisición de recursos puede incluir
planes para artículos tales como el equipo, hardware y software, contratos de
servicios, de transporte, instalaciones y servicios administrativos. El plan de
adquisición de recursos debe especificar los puntos en el cronograma del
proyecto cuando se requiera que las diversas actividades de adquisición. Las
restricciones en la adquisición de los recursos necesarios deben ser especificados.
En esta sección se puede ampliar en subsecciones adicionales de la forma 5.1.3.x
para dar cabida a los planes de adquisición de los distintos tipos de recursos a ser
adquiridos. Las referencias a los planes de adquisición de los recursos contenidos
en los documentos separados deben ser incluidos aquí.
5.1.4 Plan del Proyecto de Formación de Personal ¿Qué formación se necesita

para asegurar que los niveles de habilidad necesarios, en número suficiente
están disponibles para llevar a cabo con éxito el proyecto de software? El
programa de entrenamiento debe incluir los tipos de formación que debe
proporcionarse, número de personal a ser entrenado, los criterios de entrada y
salida de la formación, y los métodos de entrenamiento; Por ejemplo,
conferencias, consultas, tutoría, o la formación asistida por ordenador. El plan
de formación debe incluir la formación necesaria en tanto las habilidades técnicas
y de gestión.

Esta sección de la PAPS se describen las actividades de trabajo, y los detalles de
la planificación, los recursos y el presupuesto para el proyecto de software.
5.2.1 Actividades de trabajo Esta sección contiene tura la ruptura de trabajo del
proyecto estruc-. Las actividades de trabajo en la EDT deben ser descompuestos
a un nivel que expone los factores de riesgo del proyecto y permite una
estimación precisa de los recursos necesarios y la duración periodicidad de cada
actividad de trabajo. Paquetes de trabajo deben utilizarse para especificar, para
cada actividad de trabajo, factores como los recursos necesarios, la duración
estimada, productos de trabajo a ser producidos, los criterios de aceptación de los
productos de trabajo y actividades previas y predece- trabajo sucesor. El nivel de
descomposición de diferentes actividades de trabajo en la estructura de desglose
www.it-ebooks.info
del trabajo puede ser diferente dependiendo de
www.it-ebooks.info
factores tales como la calidad de los requisitos, la familiaridad de la obra, la

novedad de la tecnología a utilizar, y los componentes de software para ser
reutilizados.
5.2.2 Asignación de horario El horario asignado proporciona respuestas a

preguntas tales como: ¿Cuáles son las limitaciones de tiempo de secuenciación
entre las actividades de trabajo? ¿Dónde están las oportunidades para las
actividades de trabajo simultáneos? Lo que las restricciones del cronograma son
causados por las dependencias de factores externos tales como equipo
suministrado por el proveedor y el software, interfaces a los componentes de
hardware y el software suministrado por el subcontratista? El horario asignado
debe incluir hitos frecuentes que pueden evaluarse para el logro utilizando
indicadores objetivos para evaluar el alcance y la calidad de los conductos de
pro- trabajo completado en esos hitos. Las técnicas que se pueden utilizar para
especificar las relaciones de programación incluyen gráficos de hitos, listas de
actividades, cartas de la actividad de Gantt, redes, redes de actividad de la ruta
crítica, y gráficos PERT.
5.2.3 Asignación de recursos ¿Qué recursos se asignan a las diversas

actividades de trabajo en la estructura de división del trabajo y el cronograma del
proyecto? Los recursos especificados puede incluir personal por nivel de
habilidad y factores como los recursos informáticos, herramientas de software,
instalaciones de ensayo y simulación especiales, y apoyo administrativo. Una
línea separada debe proporcionarse para cada tipo de recurso necesario. La
asignación de recursos a las actividades debe ser indicado. Un resumen de las
necesidades de recursos para las diversas actividades de trabajo se pueden
obtener de las edades PACK- trabajo de la estructura de desglose del trabajo y se
presenta en forma de tabla.
5.2.4 Asignación de presupuesto ¿Qué elementos del presupuesto se asignan a

cada una de las principales actividades de trabajo en la estructura de desglose del
trabajo? El presupuesto de actividades debe incluir el costo estimado para el
personal (en dólares o personas-hora por nivel de habilidad) para llevar a cabo
cada actividad y puede incluir, en su caso, los costos de factores tales como
viajes, reuniones, recursos informáticos, herramientas de software, pruebas
especiales y instalaciones de simulación y apoyo administrativo. Una línea
separada debe proporcionarse para cada tipo de recurso para cada actividad. El
presupuesto de la actividad laboral puede ser desarrollado utilizando una hoja de
cálculo y se presenta en forma de tabla.
5.3 Plan de control

Esta sección de la PAPS especifica los parámetros, los mecanismos de
información y procedimientos de control para ser utilizados en la medición,
presentación de informes, y el control de la tos productos requisitos, la
programación del proyecto, el presupuesto y los recursos, y la calidad de los
procesos de trabajo y productos de trabajo. Cada elemento del plan de control
debe ser compatible con las normas de la organización, políticas y
procedimientos para el control de los proyectos de software y con los acuerdos
contractuales para el control del proyecto.
www.it-ebooks.info
5.3.1 Plan de requisitos de control ¿Cómo van a ser aceptadas como requisitos
de las líneas de base de productos? ¿Qué mecanismos de control se utilizarán
para medir, informar y controlar los cambios en la línea de base requisitos?
Cómo se evaluará el impacto de los cambios en los requisitos de alcance y
calidad del producto, y la programación del proyecto, el presupuesto, los recursos
y los factores de riesgo? mecanismos de gestión de configuración deben incluir el
cambio
www.it-ebooks.info
procedimientos de control, control de versiones, y un tablero de control de

cambios. Las técnicas que se pueden utilizar para el control de los requisitos de
trazabilidad incluyen, creación de prototipos y modelos, análisis de impacto, y las
críticas.
5.3.2 Plan de Control de Horarios ¿Qué técnicas se utilizarán para medir el

progreso del trabajo realizado en las mayores y menores hitos del proyecto, para
comparar el progreso real al progreso previsto, y para implementar medidas
correctivas cuando el progreso real no se ajusta al progreso planeado? El logro de
horario mile- piedras debería evaluarse utilizando criterios objetivos para medir
el alcance y la calidad de los productos de trabajo terminados en cada hito.
5.3.3 Plan de Control de Presupuesto ¿De qué manera el costo del trabajo
realizado, las comparaciones de costo planeado a costo presupuestado y el coste
de la acción correctiva (cuando el costo real, el calendario, el alcance, la calidad
o no se ajusta a los planes) pueden lograr? Cómo cuencia se proporcionará
información presupuestaria consiguiente / costo? ¿Qué herramientas y técnicas se
utilizarán? ¿Quién va a obtener copias de la información? El plan de presupuesto
debe incluir hitos frecuentes que pueden ser evaluados por sus logros a través de
indicadores objetivos para evaluar el alcance y la calidad de los productos de
trabajo terminados en esos hitos. Un mecanismo como el seguimiento del valor
ganado se debe utilizar para informar del presupuesto y el plan previsto, el
progreso horario, y el costo del trabajo terminado.
5.3.4 plan de control de calidad ¿Cómo afectará la calidad de los procesos de

trabajo y productos de trabajo en evolución se mide y se controla? mecanismos
de control de calidad pueden incluir auditorías de los procesos de trabajo,
verificación y validación de productos de trabajo, revisiones conjuntas, análisis
de causa raíz, y las evaluaciones de proceso. prestaciones técnicas medi-
surement se debe utilizar.
5.3.5 plan de la presentación de informes ¿Cuáles son los mecanismos de

información, formatos de informes y flujos de información que se utilizará en la
comunicación del estado de requisitos, calendario, presupuesto, el alcance, la
calidad, y otras métricas de estado requeridos se desee o? Los métodos,
herramientas y técnicas de comunicación deben ser incluidos en el plan de
informes. La frecuencia y la naturaleza de la medición y control de proyectos
deben ser coherentes con el alcance del proyecto, la criticidad, el riesgo, la
visibilidad, y los requisitos contractuales.
5.3.6 Plan de recopilación de métricas ¿Cómo se recogen los datos de

medición necesarios, validado, y se retiene? ¿Qué métodos, herramientas y
técnicas se utilizarán? ¿Con qué frecuencia se recopilarán los distintos tipos de
datos de las métricas, analizados y reportados?

¿Qué mecanismos se utilizarán para identificar, analizar y priorizar los factores
de riesgo del proyecto? ¿Cómo se desarrollarán planes de contingencia? ¿Qué
métodos se utilizan para realizar un seguimiento de los factores de riesgo
identificados, evaluar los cambios en los niveles de los factores de riesgo y
www.it-ebooks.info
responder a esos cambios? ¿Cómo se identificarán los factores de riesgo,
evaluados y mitigados de manera continua durante el proyecto? Los factores de
riesgo que deben ser considerados incluyen
www.it-ebooks.info
riesgos en la relación comprador-proveedor, riesgos contractuales, riesgos

tecnológicos, riesgos causados por el tamaño y la complejidad del producto,
riesgos en los entornos de desarrollo y de destino, los riesgos en la adquisición de
personal, niveles de habilidad, y la retención, los riesgos a calendario y el
presupuesto, y los riesgos en la consecución de usuario, cliente y adquirente
acep- tación del producto.
5.5 Plan de Cierre del proyecto

¿Cómo se llegó a la conclusión del proyecto? ¿Cómo serán reasignados
miembros del personal? Lo postmortem reuniones y sesiones de información se
llevará a cabo? ¿Cuál es el plan para el archivo de materiales de trabajo del
proyecto? ¿Cómo va a lecciones aprendidas y documentarse análisis de los
objetivos del proyecto conseguidos?
6 PLANES proceso técnico
Esta sección de la PAPS especifica el modelo de proceso de desarrollo, los

métodos técnicos, herramientas y técnicas que se utilizarán para desarrollar los
diversos productos de trabajo; planes para el establecimiento y mantenimiento de
la infraestructura del proyecto; y el plan de la aceptación del producto.
6.1 Modelo de proceso

¿Qué modelo de proceso se utilizarán para desarrollar el producto de software?
El modelo de proceso debe describir las relaciones entre las principales
actividades de trabajo de proyectos y procesos de apoyo especificando el flujo de
productos de información y de trabajo entre las actividades y funciones, el
momento de los productos de trabajo que se genere, revisa para ser llevado a
cabo, los principales hitos a alcanzar, las líneas de base que se establezcan, las
prestaciones del proyecto a ser completado, y se requiere aprobaciones que
abarcan toda la duración del proyecto. El modelo de proceso para el proyecto
debe incluir la iniciación del proyecto y las actividades de terminación del
proyecto. Para describir el modelo de proceso, una combinación de notaciones
gráficas y de texto puede ser utilizado. Cualquier adaptación de modelo de
proceso estándar de la organización para un proyecto debe indicarse en esta
sección.

Lo que el desarrollo de metodologías, herramientas, técnicas, lenguajes de
programación, y otras anotaciones se pueden utilizar para especificar, diseñar,
construir, probar, integrar documento, entregar y modificar y mantener los
productos de trabajo internos para el proyecto y aquellos que se entregarán a la
¿cliente? Además, ¿qué normas, políticas, procedimientos y directrices técnicas
se utilizarán para gobernar el desarrollo y / o modificación de productos de
trabajo?

¿Cuáles son el plan de establecer y mantener el entorno de desarrollo (hardware,
sistema operativo, red y software), y las políticas, procedimientos, normas, y las
instalaciones necesarias para llevar a cabo el proyecto de software? Estos
www.it-ebooks.info
recursos pueden incluir estaciones de trabajo, redes de área local, herramientas de
software para el análisis, diseño,
www.it-ebooks.info
implementación, prueba y gestión de proyectos, escritorios, oficinas, y las

disposiciones de seguridad física, personal administrativo y de servicios de
limpieza.

¿Cuál es el plan para el usuario, cliente, y la aceptación adquirente de los
productos de trabajo entregables generados por el proyecto de software? ¿Qué
criterio objetivo se utilizará para determinar la aceptabilidad de los productos de
trabajo entregables? Se preparará un acuerdo formal de los criterios de aceptación
y firmado por representantes de la organización desarrollo y la organización
adquirir? Cualquier técnico procesos, métodos o instrumentos necesarios para la
aceptación del producto deben ser especificados en el plan de aceptación del
producto. Los métodos de validación, tales como las pruebas, la demostración, el
análisis, y la inspección deben especificarse en este plan. La relación entre los
requisitos, planes de prueba basada en los requisitos, y la lista de productos de
trabajo entregables requeridos deben indicarse-una matriz de trazabilidad se
pueden utilizar.
7 Apoyar los planes PROCESO
Esta sección de la PAPS contiene planes para los procesos de apoyo que abarcan
toda la duración del proyecto de software. Estos planes pueden incluir, pero no se
limitan a, artículos tales como gestión de la configuración, verificación y
validación, el software de docu- mentación, control de calidad, revisiones y
auditorías, la resolución de problemas y manejo de subcontratista. Los planes
para los procesos de apoyo deben ser desarrolladas a un nivel de detalle
consistente con las otras secciones del PAPS. En particular, las funciones, las
responsabilidades, autoridades, programación, presupuestos, necesidades de
recursos, factores de riesgo y productos de trabajo para cada proceso de apoyo
deben ser especificados. La naturaleza y el tipo de procesos de apoyo requeridos
pueden variar de proyecto en proyecto; Sin embargo, la ausencia de un plan de
plan de gestión de la configuración, verificación y validación, plan de
aseguramiento de la calidad, plan conjunto adquirente-proveedor opinión, plan de
resolución de problemas, o plan de administración de subcontratistas deben
justificarse expresamente en cualquier plan de gestión de proyectos de software
que no los incluye. Los planes para los procesos de soporte pueden ser
incorporados directamente en el plan de gestión de proyectos de software o
incorporadas por referencia a otros planes. planes referenciados son considerados
como parte del plan del proyecto. planes de apoyo pueden estar basados en
procesos de apoyo normales de la organización, que pueden ser incluidos por
referencia. planes referenciados son considerados como parte del plan del
proyecto. planes de apoyo pueden estar basados en procesos de apoyo normales
de la organización, que pueden ser incluidos por referencia. planes referenciados
son considerados como parte del plan del proyecto. planes de apoyo pueden estar
basados en procesos de apoyo normales de la organización, que pueden ser
incluidos por referencia.
7.1 Plan de Gestión de la Configuración

¿Qué productos de trabajo estará bajo la gestión de configuración (control de
www.it-ebooks.info
versiones)? ¿Cómo se determinará la preparación de productos de trabajo para la
línea de base? ¿Cómo se manejarán las solicitudes de cambio (el registro, análisis
y seguimiento)? ¿Cuáles serán los procedimientos de control de cambios?
Quienes serán los miembros de la junta de control de cambios? ¿De qué manera
los interesados serán notificados de los cambios en las líneas de base? ¿Quién va
a realizar un seguimiento de los cambios en curso y analizar las tendencias del
cambio? ¿Qué herramientas automatizadas se utilizarán para la gestión de con-
figuración? ¿Qué métodos, herramientas y convenciones debe ser utilizado para
satisfacer las políticas corporativas y los requerimientos de soporte del producto?
www.it-ebooks.info
7.2 Verificación y validación del Plan

Que va a hacer la verificación y validación (V & V)? ¿Qué alcance de las
actividades se incluirán? ¿Qué métodos, herramientas y técnicas se utilizarán?
¿Cuál será el grado de independencia entre las entidades de desarrollo y las
entidades de V & V del proyecto? ¿Qué herramientas automatizadas se utilizarán
para V & V? la planificación de verificación debería resultar en planes de
técnicas tales como la trazabilidad, las revisiones de hitos, revisiones de
progreso, revisiones por pares, creación de prototipos, simulación y modelado. la
planificación de validación debe dar lugar a planes de técnicas tales como
ensayos, la demostración, el análisis y la inspección. Las herramientas
automatizadas que se utilizarán en la verificación y validación deben ser
especificados.
7.3 plan de documentación

El plan de documentación debe responder a las siguientes preguntas: ¿Qué
documentos se generarán? Lo plantillas o normas se utilizarán? ¿Quién será el
responsable de proporcionar la información necesaria, la generación de los
documentos, revisión de los mismos, y aceptarlos? ¿Qué documentos se
colocarán bajo control de versiones? Cuando va a revisar copias y versiones de
referencia iniciales deberse? ¿Quién va a obtener copias de las versiones de
revisión y líneas de base de los documentos? Sin entrega productos de trabajo
pueden incluir requisitos, especificaciones, documentación de diseño, matrices de
trazabilidad, planes de prueba, actas de reuniones, informes de revisión, los
elementos de acción, solicitudes de cambio, y los informes de defectos. productos
de trabajo entregables pueden incluir código fuente, código objeto, manual, en
línea sistema de ayuda de los usuarios, conjunto de pruebas de regresión, una
biblioteca de configuración, principios de funcionamiento,
1.1.3 del PAPS.
7.4 Plan de garantía de calidad

¿Cómo se obtiene la garantía de que el proyecto de software está cumpliendo con
sus compromisos a los mentos procesos de software planificadas como se
especifica en los requisitos de especificaciones ción, el plan de gestión de
proyectos de software, planes de apoyo, y cualesquiera otros estándares,
procedimientos o directrices a las que el proceso de o el producto debe cumplir?
procedimientos de garantía de calidad pueden incluir análisis, inspecciones,
revisiones, auditorías, y Las valoraciones. El plan de control de calidad debe
indicar las relaciones entre los procesos de evaluación de control de calidad,
verificación y validación, revisión, auditoría, configuración management,
ingeniería de sistemas, y.
7.5 Los comentarios y Plan de Auditorías

¿Qué horarios, recursos, métodos y procedimientos serán utilizados para llevar a
cabo la revisión de proyectos y auditorías? Este plan debe incluir planes para los
exámenes conjuntos adquirente-proveedor, análisis de avances de gestión,
desarrollador revisiones por pares, auditorías de aseguramiento de la calidad, y
www.it-ebooks.info
las revisiones adquirente-conducido y auditorías.
www.it-ebooks.info
7.6 Plan de Resolución de Problemas

¿Cómo se reportaron problemas en los procesos de trabajo y productos de
trabajo, analizado y priorizado, y se resolvieron? ¿Cuáles serán las funciones de
las entidades de organización tales como el desarrollo, la gestión de la
configuración, el tablero de control de cambios, la verificación y la validación en
la resolución de problemas? El esfuerzo dedicado a la presentación de informes
de problemas, análisis y resolución debe notificarse por separado de manera que
retrabajo puede ser rastreado y mejora de procesos logra.
7.7 Planes de Gestión de subcontratistas

¿Cómo serán seleccionados y gestionados subcontratistas? ¿Quién será
responsable de preparar los planes de gestión de los subcontratistas? ¿Quién será
responsable de proporcionar las interfaces técnicas y de gestión a los
subcontratistas? Sobre la base de esta norma deben estar preparados para incluir
los elementos necesarios para asegurar la terminación exitosa de cada
subcontrato. En particular, la gestión de requisitos, ing Monitor con el progreso
técnico, programación y control del presupuesto, los criterios de aceptación del
producto, y los procedimientos de gestión de riesgo debe ser incluido en cada
plan subcontratista. Los temas adicionales deben añadirse según sea necesario
para asegurar la terminación exitosa del subcontrato. Una referencia a la
subcontratación oficial y el principal contratista / subcontratista puntos de
contacto debe ser proporcionada.
7.8 Plan de Mejora de Procesos

¿Cómo y cuándo se evaluará periódicamente el proyecto para determinar las
áreas de mejora? ¿Quién hará las evaluaciones de los proyectos? ¿Quién va a
desarrollar e implementar planes de mejora? El plan de mejora de proceso debe
estar estrechamente relacionado con el plan de resolución de problemas. Por
ejemplo, análisis de la causa raíz de los problemas recurrentes puede conducir a
mejoras en los procesos simples que pueden reducir significativamente la
reanudación durante el resto del proyecto. Las mejoras propuestas deben ser
examinadas cuidadosamente para identificar aquellos procesos que se pueden
mejorar sin interrupciones graves a un proyecto en curso y para identificar
aquellos procesos que mejor se pueden mejorar mediante iniciativas de mejora de
procesos a nivel de organización.
8 Planes adicionales
¿Qué planes adicionales son necesarios para satisfacer los requisitos del producto
y las condiciones contractuales mediante la gestión de forma sistemática el
proyecto de software? ¿Quién va a prepararlos y ejecutarlos? ¿Qué formas
tendrán? se cumplen, planos de las instalaciones o equipos especiales, planes de
instalación de productos, planes de formación de usuarios, los planes de
integración, planes de conversión de datos, de transición sistema de planes
adicionales para un proyecto en particular puede incluir planes para asegurar que,
privacidad, o requisitos de seguridad especiales de seguridad para el producto
planes, planes de mantenimiento de productos y planes de soporte de producto.
www.it-ebooks.info
APÉNDICES
Los apéndices se pueden incluir, ya sea directamente o por referencia a otros

documentos, para proporcionar detalles de apoyo que podrían interferir con la
PAPS si se incluye en el cuerpo del plan.
ÍNDICE
Un índice de los términos y acrónimos utilizados en todo el PAPS es opcional.

Un índice se recomienda, sin embargo, para mejorar la usabilidad del PAPS.
www.it-ebooks.info
5
TÉCNICAS DE PLANIFICACIÓN DEL
PROYECTO
No planificar es planificar el fracaso.

-Alan Lakein
5.1 Introducción al Proyecto técnicas de planificación
capítulos anteriores de este texto se han ocupado de los elementos Requisitos,

restricciones y directivas del modelo de flujo de trabajo en la Figura 1.1 del
Capítulo 1 (se repite aquí como Figura 5.1), las funciones de los clientes y la
gestión, y la naturaleza de los planes y la planificación. En este capítulo se ocupa
de la planificación, definición de actividad, y elementos de acoplamiento
estimación resaltados en la Figura 5.1. técnicas de estimación adicionales se
presentan en el Capítulo 6.
técnicas de planificación, definición de la actividad, y la estimación de
esfuerzo y programación incluye las siguientes actividades, que son un
subconjunto de las actividades contenidas en el cuadro 4.1b en el capítulo 4.
• Desarrollar un vista de la arquitectura de descomposición (ADV) de la

arquitectura del producto y asignar requisitos para los elementos de la ADV
• Desarrollar una estructura de desglose de trabajo que incluye elementos de
trabajo para los módulos de ADV y los requisitos asignados para cada
elemento de trabajo
• Desarrollar paquetes de trabajo para las tareas de la estructura de desglose
del trabajo (EDT)
• Definir un cronograma de hitos medibles objetivamente
• Preparar una red del cronograma e identificar la ruta crítica (s)

173
www.it-ebooks.info
174 TÉCNICAS DE PLANIFICACIÓN DEL PROYECTO
Las solicitudes de cambio y Informes de
requisitos
Proceso
Cliente Planificaci Asigna

ón y actividad Independient
Definitio ciones e
Los replanifica de
norte V&V
gestores ción trabajo
Seguro de entregad
directivas y o
restricciones calidad
Estimación y producto
Re-estimar Controlador Gestión de la s de
configuración trabajo
Retenció
n de ..........
datos . . ... . .

problemas
FIGURA 5.1 flujo de trabajo del proyecto, haciendo hincapié en la planificación,
estimación, y la definición de las actividades
• Preparará una estimación de la duración del proyecto PERT

• Identificar los números y tipos de recursos necesarios, cuándo van a ser
necesarias, y por cuánto tiempo
• Preparar una estimación del óptimas esfuerzo, coste, calendario, y los recursos
• Negociar con el cliente para obtener un equilibrio entre los requisitos, costo
y duración del proyecto que satisfaga las restricciones del proyecto
Es evidente que no se puede preparar un plan para el desarrollo de un producto de

software si usted no sabe qué producto para hacer. Es igualmente evidente que
cuanto más se entiende sobre el producto a fabricar, más confianza tendrá en los
detalles de su plan. La versión inicial de su plan de proyecto será, por necesidad,
de alto nivel e imprecisa; Sin embargo, puede refinar el plan como la estructura
arquitectónica del producto evoluciona y como su comprensión del proyecto
crece basa en la aclaración de las bases de productos cubiertos en el Capítulo 3 de
este texto (requisitos del sistema, la arquitectura del sistema, los requisitos de
software, y restricciones de diseño). La planificación es por lo tanto un proceso
iterativo; cuanto más se entiende sobre el producto del plan mejor que puede
hacer.
• el alcance de la planificación
• planificación ola de rodadura
• escenarios para el desarrollo de un plan de proyecto
• el desarrollo de una vista de la arquitectura de descomposición
www.it-ebooks.info
PLANIFICACIÓN 5.4 Balanceo-WAVE 175
• el desarrollo de una estructura de desglose del trabajo

• el desarrollo de la programación del proyecto
• el desarrollo de perfiles de recursos
• recursos diagramas de Gantt
• la estimación de los costos del proyecto
Las técnicas de planificación que se presentan en este capítulo son informados por el
área de proceso de Planificación de proyecto del marco de proceso de CMMI-DEV-
v1.2, los elementos de planificación de la ISO y los estándares de IEEE 12207, el
estándar IEEE 1058, y el Cuerpo de Conocimiento del PMI. Estos elementos se
describen en el Apéndice 5A a este capítulo.
glosario al final del texto. diapositivas de la presentación de este capítulo y otro
5.3 EL alcance de la planificación
El alcance de su proyecto puede implicar el desarrollo de requisitos, la

negociación sched- ULE y el presupuesto, la adquisición de instalaciones y
recursos, la construcción del producto de software, 19 de instalarlo, la formación
de los usuarios, y mantener el sistema sobre una base continua. O bien, es posible
que se entregó una serie de cambios a realizar, junto con un calendario y un
presupuesto y tener la responsabilidad de gestionar un proyecto para hacer las
modificaciones. O bien, su proyecto puede caer en algún lugar entre estos dos
extremos. En cualquier caso, este capítulo (y este texto entero) considera el
alcance completo de actividades que pueden ser necesarios para gestionar
proyectos de software grandes y complejos. Como se ha subrayado en todo este
texto, las actividades de gestión de proyectos deben ser adaptados y diseñados
para adaptarse a las necesidades de cada proyecto.
5.4 PLANIFICACIÓN OLA DE RODADURA
la planificación de onda rodadura reconoce que es imposible desarrollar planes a

nivel de detalle indicado en este capítulo durante la fase inicial de planificación
de sus proyectos de software. Cuando se está llevando a cabo un proyecto, un
enfoque que se recomienda es aumentar el plan maestro de alto nivel con planes
detallados para el próximo mes, para el mes siguiente, y durante tres meses, por
lo tanto. Cada mes los planes se mueven hacia delante un mes, es decir, se movió
hacia adelante de una manera de onda a la rodadura. Los planes para el próximo
mes deben ser detallados y específicos. Los planes para dos y tres meses, por lo
tanto deben ser lo más específico posible. Rodar el plan de tres meses hacia
adelante cada mes ofrece la oportunidad de:
19
productos de software se construyen por los vendedores para la venta a los numerosos clientes;
sistemas de software son construidos por contratistas para clientes individuales específicos sobre una
base contractual. El “sistema” y “productos” términos se utilizan indistintamente en este texto a
menos que la distinción es importante; la distinción se aclarará en estos casos.
www.it-ebooks.info
n meses de planificación: nn + 1
n+2 mes n + 1 de planificación: n+
1 n+2n+3
mes n + 2 planificación: n + 2 n+3 n+4
FIGURA 5.2 actualización de onda de laminación de planos detallados de cada

mes
• tener recursos disponibles cuando se necesitan,

• obstáculos claros y coordinar las actividades de trabajo, y
• identificar y hacer frente a los factores de riesgo antes de que se conviertan en
problemas.
planificación de onda del balanceo se ilustra en la Figura 5.2.
5.5 ESCENARIOS PARA EL DESARROLLO un plan de proyecto
Como mínimo, debe tener algunos requisitos de explotación para el producto o

sistema para preparar la versión inicial de su plan. Lo ideal sería tener prioridad a
las necesidades operacionales, especificaciones técnicas, un diagrama de bloques
funcional, y una vista de descomposición de la estructura arquitectónica del
producto en la que basar su plan. Sin embargo, esta base ideales rara vez se dio
cuenta al preparar la versión inicial de un plan de proyecto.
La planificación inicial procede típicamente de uno de los siguientes escenarios:
1. Se le da un conjunto de requisitos y restricciones operacionales en uno o más

de los horarios, presupuesto y recursos. Por ejemplo, un sistema que tendrá una
lista cado speci- de características operativas y atributos de calidad debe ser
entregado en 9 meses; 6 desarrolladores de software están disponibles para
implementar el sistema. Su primera tarea es determinar si es factible construir el
producto previsto (o modificar un producto existentes) dentro de esos
parámetros. Esto puede implicar el trabajo con el cliente para aclarar los
requisitos y el uso de los datos y reglas generales históricos para determinar la
viabilidad del proyecto.
Si el proyecto no es viable, con una alta probabilidad de éxito, usted y su
cliente debe dar prioridad a los requerimientos en categorías esenciales,
deseables, y opcionales (que siempre es una buena cosa que hacer). Debe ser
posible implementar todos los requisitos esenciales, con una muy alta
probabilidad de éxito, dentro de las limitaciones de desarrollo en la fecha
prevista, el presupuesto y los recursos. El cliente debe aceptar un producto que
implementa todos los requisitos esenciales y como muchos de los requisitos
deseables que se pueden implementar dentro de las limitaciones en la fecha
prevista, el presupuesto y los recursos. O bien, las limitaciones de desarrollo
deben estar relajados, o alguna combinación de de-la determinación del alcance
de los requisitos y la relajación de los obstáculos para el desarrollo deben ser
perseguidos.
2. Se le puede dar una lista de características y atributos de calidad y se le
www.it-ebooks.info
pedirá a estimar, y luego comprometerse a, el calendario, el presupuesto y los
recursos necesarios para desarrollar un sistema de
www.it-ebooks.info
5.6 DESARROLLO DE LA DESCOMPOSICIÓN vista de la arquitectura 177
o producto que tiene las características y atributos de calidad. En este caso hay
que revisar primero, aclarar y elaborar toda la información que esté disponible.
Usted no debe comprometerse con los requisitos que son factibles debido a la
situación actual de la tecno- logía o la falta de experiencia en su organización;
dichos requisitos deben ser etiquetados como objetivos de diseño que deben
lograrse en la medida posible. En este escenario, se debe preparar una serie de
estimaciones con probabilidades asociadas de éxito y hacer un compromiso para
tener una estimación no menos del 90% de probabilidad de éxito. Los supuestos
en que se basan su estimación y el compromiso deben ser documentadas y
aceptado por el cliente.
3. Se le puede dar una fecha de terminación y un presupuesto y pedirá para
determinar las características de un producto que puede ser construido o
modificado dentro de las limitaciones de tiempo y dinero especificada. Por
ejemplo, ¿qué características y atributos de calidad de funcionamiento puede
usted y 6 de sus desarrolladores de software construir y entregar en 9 meses para
un producto de un tipo especificado?
En cualquier caso, su plan inicial del proyecto debe lograr un equilibrio entre los
requisitos, el calendario, el presupuesto, los recursos y la tecnología. Las
revisiones posteriores de su plan deben mantener este equilibrio como los
requisitos y otros factores cambian. En todos los casos, su primera tarea en el
desarrollo de un plan de proyecto es revisar, aclarar y dar más detalles toda la
información disponible sobre el producto a ser construido o modificado.
Para cada uno de los escenarios anteriores, el siguiente paso es refinar los
requisitos para eliminar áreas de incertidumbre y para preparar una vista de
descomposición de la arquitectura del producto y una estructura de división del
trabajo como base para la preparación de una estimación más precisa.
5.6 DESARROLLO DE LA VISTA ARQUITECTURA descomposición y la

estructura de trabajo DISTRIBUCIÓN
El diseño arquitectónico de software tiene que ver con la especificación de los

módulos de software, sus interrelaciones y sus conexiones con el entorno del
software. Varios tipos diferentes de puntos de vista se utilizan para documentar
los diferentes tipos de barcos PARENTESCO. Las vistas se representan usando
notaciones, tales como los ilustrados en la Figura 5.3, para documentar relaciones
estructurales, funcionales y de comportamiento. Otras vistas arquitectónicas
también son útiles [Bass03].
A ADV parcial para el software de ATM se presenta en la Figura 5.4. Tenga
en cuenta que los requisitos que se enumeran en la Tabla 5.1 se asignan a los
nodos hoja del componente de las transacciones financieras de la ADV.
Tenga en cuenta el uso de los términos “deberá” para los requisitos esenciales,
“debería” para los requisitos deseables, y “podría” para requisitos opcionales.
“Deberá” es un término contractualmente vinculante; “Debería” indica los
requisitos deseados pero no es esencial; “Podría” indica las opciones que podrían
incluirse cuando se disponga de tiempo, presupuesto y recursos.
La figura 5.5a ilustra una representación de estructura de árbol de una
estructura de desglose de trabajo (WBS) para el proyecto ATM. Una
representación alternativa (una lista sangrada) se presenta en la figura 5.5b. Los
nodos hoja del árbol (o la lista) especifican tareas. Una tarea es una unidad más
pequeña de la planificación, medición y control. Los nodos de nivel más alto en
un WBS son actividades; actividades se componen de actividades subordinadas
www.it-ebooks.info
estructura
diagramas de clases OO
ADV (vista descomposición arquitectura)
función
métodos de clase
OO diagramas de
flujo de datos
comportamiento
estado Diagramas
de diagramas de
secuencia
Figura 5.3 Tres puntos de vista de arquitectura de software y ejemplos de notaciones

utilizadas. La vista de la arquitectura de descomposición (ADV) especifica el jerárquica
“es parte de” la relación entre los módulos de software. El ADV es utilizado por los
administradores de proyectos (ti) para desarrollar la estructura de desglose del trabajo
(EDT)
Cajero automático
Software
ATMHD FINAT MANT COMM
. .. . .. ...
validador Procesador Grabadora Terminator

E1, E2 E3, D1, D2, E4, E5 E6, D4
D3 O1, O2, O3
ATMHD: Controladores de
hardware FINAT:
Transacciones financieras
MANT: Mantenimiento y diagnóstico
COMM: Paquete de Comunicaciones
FIGURA 5.4 Una vista descomposición arquitectura parcial (ADV) de software ATM
y tareas. Las relaciones entre las actividades y tareas en una EDT son ción de este
modo contención o “es parte de” relaciones de la misma manera que las
relaciones entre el módulo de software en una vista de descomposición de
arquitectura son “es parte de” las relaciones entre los módulos.
La EDT es una herramienta fundamental para la planificación, estimar, medir
y control- ling un proyecto de software. El papel de una EDT es dividir las
actividades y tareas de un proyecto de software en unidades manejables con
funciones claramente definidas, las responsabilidades y las autoridades de cada
unidad. Además una EDT representa las interfaces y las líneas de comunicación
entre las actividades de trabajo y tareas. Uno de los principales criterios de diseño
www.it-ebooks.info
TABLA 5.1 Algunos requisitos priorizados para el software de ATM

Requerimientos esenciales
E1 Las transacciones financieras serán autorizados por una tarjeta de cajero
automático y una contraseña E2Financial transacciones, se pondrá fin si un cliente no
consigue entrar el
contraseña correcta «ajustable veces»
E3Financial transacción permitirá dinero rápido retiros
E4Financial transacción deberá proporcionar un recibo impreso para cada
transacción
E5The ATM retendrá la información que aparece en el especificación de
requisitos, la sección 3.2.1, para cada transacción de cliente
E6Financial transacción deberá procesar Terminar solicitudes de clientes
requisitos deseables
D1Financial transacción debe adaptarse a la consulta de saldo actas
D2Financial transacción debe acomodar estándar transacciones de retiro
D3Financial transacción debe acomodar depósito actas
D4Customers se debe permitir llevar a cabo múltiples transacciones por sesión
requisitos opcionales
O1Financial transacción podría apoyar débito las
transacciones con tarjetas O2Financial transacción podría apoyar el
pago de los servicios públicos billetes
O3Financial transacción podría permitir a los clientes a comprar los sellos postales que
serán desembolsados por el hardware ATM
Cajero automático
Proyecto
1 Manejo 2 Sistema 3 4 5 Validar 6 Realiza 7 Preparar 8 Entregar

Proyecto de Do Desarroll Compr Sistema r Tech. Pubs. Sistema
Análisis uebe CM
. ar
Sistem
Software
a
3.1. Con 3.2. Con 3.3. Con 3.4. Co

struir struir struir mprar 3.5. Integrar
ATMHD FINAT MANT COMM ATMHD, FINAT,
MANT Y COMM
3.2.1 Con 3.2.2 Cons 3.2.3 Con 3.2.4 cons 3.2.5 Integrar
struir truir struir truir módulos FINAT
Validador Procesad Grabador Terminato
[E1, E2] or a [E4, E5] r
[E3, D1, D2, D3, [E6, D4]
3.2.1.1 O1,- O2, O3]
3.2.2.1 - 3.2.4.1 DEST
- 3.2.3.1
DESV DESP ARED
-
3.2.1.2 - 3.2.2.2 - 3.2.3.2 - 3.2.4.2 CUTT
- CUTV CUTP CUTR
3.2.1.3 - 3.2.2.3 - 3.2.3.3 - 3.2.4.3 ITTM
- ITVM ITPM ITRM
DESX: diseño detallado del módulo de x; CUTx: Codificación y x unidad de pruebas; ITXC: la
integración y prueba de x
www.it-ebooks.info
FIGURA 5.5A forma de árbol estructurado de una EDT
www.it-ebooks.info
1 gestionar proyecto
2 Hacer Análisis de Sistemas
3 desarrollar software
3.1 Construir ATM controladores de hardware (ATMHD)
3.2 Construir las transacciones financieras Handler
3.2.1 Construir Validador [E1, E2]
3.2.1.1 diseño Validador
3.2.1.2 Código y Test Unit Validador
3.2.1.3 Integrar y Validador de prueba
3.2.2 Construir Procesador de transacciones (FINAT) [3, S1, D2, D3, O1, O2,
O3]
3.2.2.1 Diseño Procesador de transacciones
3.2.2.2 Código y Test Unit Procesador de transacciones
3.2.2.3 Integrar y probar los componentes del procesador
3.2.3 Construir grabadora [E4, E5]
3.2.3.1 diseño del registrador
3.2.3.2 Código Unidad de Registro y Prueba
3.2.3.3 Integrar y módulo de prueba del registrador
3.2.4 Construir Terminator [E6, D4]
3.2.4.1 diseño del registrador
3.2.4.2 Código Unidad de Registro y Prueba
3.2.4.3 Integrar y módulo de prueba del registrador
3.2.5 Integrar módulos FINAT
3.3 Construir Mantenimiento y diagnóstico del módulo (MANT)
3.4 Comprar el paquete de comunicaciones (COMM)
3.5 Integrar ATMHD, FINAT, MANT, y COMM
4 verificar Sistema
5 Sistema de validación
6 realizar CM
7 Preparar publicaciones técnicas
8 entregar Sistema
FIGURA 5.5B forma sangría de un WBS
para el desarrollo de la vista descomposición de la arquitectura de software

(ADV) es para descomponer el producto de una manera que permita la
asignación de tareas simultáneas con diferentes equipos y las personas; Por tanto,
existe una estrecha relación entre el diseño de un producto de software y el
diseño de las actividades de trabajo para construir el producto. Este criterio se
puede establecer como sigue:
La vista descomposición de la arquitectura de software (ADV) debe ser estructurado

para proporcionar asignaciones de trabajo simultáneas para los que están disponibles
para desarrollar el software.
Por el contrario, se puede decir que la estructura del equipo que desarrolla el
software influirá en la opinión de descomposición del software entregado
[Conway68].
La distinción entre un ADV y una EDT es a menudo borrosa mediante la
incorporación de la ADV directamente en la EDT sin reformular ella. Esta
confusión se debe evitar. Los elementos de un ADV son módulos de productos;
que se especifican mediante frases nominales que designan cosas, como en la
Figura 5.4. la estructura del proyecto de software
www.it-ebooks.info
proyectos están orientados a procesos, descomposiciones jerárquicos de las

actividades de trabajo y tareas. Los elementos de un WBS se especifican
mediante frases verbales que indican acciones a tomar, como en las figuras 5.4a y
5.4b (por ejemplo, administrar proyecto, desarrollar software, realizar CM). Los
elementos de un ADV están relacionados con los elementos en una EDT
mediante la incorporación dentro de la EDT el trabajo necesario para desarrollar
u obtener los módulos de software.
El nivel superior de sus WBS debe incluir todas las principales actividades de
trabajo en el ámbito de su proyecto; es decir, el nivel superior debe abarcar todas
las actividades de trabajo necesarias para satisfacer los requisitos, restricciones y
compromisos contractuales para su proyecto (por ejemplo, gestión de proyectos,
análisis de sistemas, desarrollo de software, verificación y validación, y la
entrega del producto). Cada nodo de la EDT en su plan inicial del proyecto debe
ser descompuesto en subniveles hasta que cada uno de los siguientes criterios de
descomposición de la EDT se satisfacen:
1. complejidades ocultos están expuestos (es decir, el trabajo a realizar se
entiende);
2. oportunidades para la reutilización de componentes de software existentes
pueden ser identificados;
3. los recursos de hardware necesarios, tales como la memoria del ordenador y
velocidad de procesador, se pueden especificar (que puede dar lugar a la
revisión del hardware los requisitos); y
4. estimaciones del esfuerzo necesario para desarrollar el software se pueden
hacer.
criterio satisfactorio 1 es necesario con el fin de satisfacer el criterio 2; esto no
puede ser posible sin la creación de prototipos, estudios de viabilidad, y la
revisión de los requisitos. También el esfuerzo estimado para encontrar, evaluar y
modificar módulos para ser reutilizados debe equilibrarse con el esfuerzo
necesario para desarrollar nuevos módulos. Es mucho mejor para hacer frente a
estos problemas al principio de su proyecto en lugar de más tarde.
Los WBS representados en las figuras 5.5a y 5.5b se descompone
parcialmente. Elementos 1, 2, 4 a 8, y 3.1, 3.3, y 3.4 deben ampliarse según sea
necesario para satisfacer los criterios de descomposición PEP. Por ejemplo, la
descomposición del elemento 1, Gestionar proyecto, que podría ser de la
siguiente manera:
1 gestionar proyecto
1.1 iniciar proyectos
1.1.1 identificar las partes interesadas
1.1.2 Desarrollar / aclarar los requisitos
1.1.3 Preparar estimaciones iniciales
1.1.4 Preparar el plan inicial del proyecto
1.1.5 Obtener el compromiso con el plan
1.2 proyecto de conducta
1.2.1 proyecto de medida y control
1.2.2 El plomo y el personal directo
1.2.3 Comunicar y coordinar
1.2.4 gestionar el riesgo
1.3 Cierre del proyecto
1.3.1 Obtener la aceptación del producto
1.3.2 Llevar a cabo sesiones postmortem
www.it-ebooks.info
1.3.3 Preparar y distribuir el informe de lecciones aprendidas
1.3.4 Ayudar en la reasignación de personal del proyecto
www.it-ebooks.info
Durante la planificación de las diversas rutas de su WBS se puede

descomponer a diferentes niveles con el fin de satisfacer los criterios de
descomposición de la EDT. el trabajo familiar de baja complejidad requerirá
menos descomposición para permitir estimados confiables de un nuevo tipo de
trabajo de complejidad incierto. Una oportunidad identificada para la
reutilización de un módulo existente requerirá menos se descompone si se tiene
la certeza del módulo candidato será adecuado, y más descomposición para
evaluar su idoneidad si tienen menos confianza en ella. Los elementos de un
WBS típicamente se descomponen en tres o cuatro niveles durante la
planificación; uno o dos niveles adicionales se añaden típicamente durante la
ejecución del proyecto.
5.7 DIRECTRICES PARA estructuras de desglose

de trabajo de diseño
La estructura de desglose del trabajo (WBS) es una herramienta fundamental para

la planificación de un proyecto de software y para medir y controlar el progreso
de un proyecto; que integra las actividades de gestión y técnicas de un proyecto
de software. Un WBS bien diseñado es por lo tanto un elemento esencial de un
plan de gestión de proyectos de software. Quince directrices para el diseño de la
estructura del proyecto se detallan en la Tabla 5.2 y se discuten a continuación.
directrices adicionales para el uso de la EDT para seguir el progreso de su
proyecto se presentan en el Capítulo 11. Como se indica en estas directrices, sus
WBS deben ser diseñados y estructurados con el mismo cuidado utilizado para
diseñar los puntos de vista de arquitectura del sistema de software o producto.
TABLA 5.2 Quince directrices para el diseño de la estructura del proyecto

GuidelineWork Descompostura
1: Utilice la Arquitectura de descomposición View (ADV) de la arquitectura de software
como la base para el desarrollo de la EDT.
2: Estructura de la ADV y la EDT para facilitar las asignaciones de
trabajo. 3: Desarrollar y utilizar las estructuras de desglose de
trabajo orientados al proceso.
4: Insertar las actividades de trabajo a desarrollar y modificar los módulos de producto en
la EDT.
5: Se reparte el alcance del proyecto en no más de 7 u 8 áreas funcionales en el nivel
superior de la EDT.
6: Limitar el fan-out de cada elemento (es decir, el alcance de cada elemento) en la
EDT a siete o menos.
7: Limitar la profundidad máxima de la EDT a seis o menos niveles.
8: Utilice un sistema de numeración decimal a identificar sistemáticamente las
actividades de trabajo y tareas.
9: Asignar requisitos priorizados a las actividades de desarrollo y tareas en la EDT.
10: Diseño de la EDT de arriba hacia abajo, de abajo hacia arriba y la parte media
hacia fuera.
11: Usar paquetes de trabajo para especificar las
tareas del proyecto. 12: Analizar los paquetes de
trabajo para las propiedades deseadas.
13: Deducir la red del cronograma de los paquetes de trabajo.
14: Determinar las necesidades de recursos que utilizan los paquetes de trabajo y la
red del cronograma.
www.it-ebooks.info
15: revisar y elaborar la EDT periódicamente y función de los acontecimientos.
www.it-ebooks.info
5.7 DIRECTRICES PARA estructuras de desglose de trabajo de diseño 183
WBS Diseño Directriz 1: Utilice la vista de la descomposición de la arquitectura

de software (ADV) como base para el desarrollo de la EDT Como se ilustra en la
figura 5.4, los elementos de un ADV se denotan por frases nominales; que son las
cosas. El trabajo para desarrollar los elementos de un ADV está incrustado en la
EDT añadiendo verbos apropiados a las frases nominales en la ADV.
WBS Diseño Directriz 2: Estructura de la ADV para facilitar las asignaciones de

trabajo La vista descomposición de la arquitectura de software embebido en el
WBS debe proporcionar oportunidades para las actividades de trabajo
simultáneos. Por ejemplo, el controlador de hardware, de transacción financiera,
diagnósticos, y módulos de comunicación de la figura
5.4 puede ser desarrollado u obtenido de otra manera por diferentes equipos de
trabajo concurrente tualmente; el paquete COMM también pueden ser adquiridos
simultáneamente. Del mismo modo la validación tor, procesador, módulos de
registrador, y terminador del módulo de transacción financiera puede ser
desarrollada por personas o equipos que trabajan simultáneamente en los
módulos.
WBS Diseño Directriz 3: Desarrollar y turas uso orientado al proceso de desglose de

trabajo estruc- Como se ilustra en las figuras 5.5a y 5.5b, una EDT especifica las
actividades de trabajo, las tareas y las relaciones de contención entre ellos. Cada
actividad y tarea se especifica mediante una frase verbal que indica las acciones que
se deben tomar.
WBS Diseño Directriz 4: Integrar las actividades de trabajo para desarrollar y

modificar los módulos de producto en la EDT Las actividades y tareas para
desarrollar u obtener los módulos en la vista de la descomposición de la
arquitectura de software en la figura 5.4 están incrustados en el WBS de las
figuras 5.5a y 5.5b mediante la conversión de las frases nominales en la figura
5.4 a los correspondientes frases verbales en las Figuras 5.5 a y 5.5b.
WBS Diseño Directriz 5: Se reparte el alcance del proyecto en no más de siete u

ocho áreas funcionales en el nivel superior de la EDT El nivel superior de un WBS
debería particionar todas las actividades de trabajo que se lleva a cabo en siete u ocho
elementos, como se ilustra en las figuras 5.5a y 5.5b. Limitar el número de
actividades a siete u ocho elementos en el nivel superior facilita la gestión de la
complejidad intelectual de un proyecto mediante la partición en un pequeño número
de actividades de trabajo a ser gestionado directamente por el usuario, el director del
proyecto, y por los que informan directamente para ti. actividades subordinadas y las
tareas son asignadas a los jefes de equipo y los miembros del equipo que son
responsables de las actividades y tareas.
WBS Diseño Directriz 6: Limitar el abanico de salida de cada elemento de la EDT a

siete u ocho El abanico de salida de un elemento PEP es el número de ramas que
conectan un elemento a sus elementos subordinados inmediatos. Como se ha descrito
anteriormente, una función de una EDT es designar los roles, responsabilidades y
autoridades en un proyecto de software. Limitar el abanico de salida tiene la ventaja
de controlar la complejidad de cada actividad de trabajo mediante la limitación del
número de actividades subordinadas o tareas que deben ser gestionados de lograr que
la actividad laboral; Se obtiene así la manejabilidad intelectual de un proyecto. Esta
ventaja no es diferente a la ventaja obtenida mediante la limitación del abanico de
salida de los módulos de producto en la vista de la arquitectura descomposición de
arquitectura de software.
www.it-ebooks.info
WBS Diseño Directriz 7: limitar la profundidad de la EDT a seis o menos niveles

La profundidad de una WBS es la longitud de la trayectoria más larga (s) en la
EDT; en las figuras 5.5a y 5.5b la profundidad es de 4, que se indica por el
número de dígitos en los designadores de tareas de nivel más bajo. La limitación
de la profundidad de cada camino en un WBS a seis o menos niveles tiene
ventajas similares a la limitación de fan-out en el control de la manejabilidad
intelectual de un proyecto. Descomposición de una trayectoria de más de seis
niveles para satisfacer los criterios de posición descomposición de la EDT de
exponer la complejidad y los factores de riesgo indica las áreas del producto y / o
arquitectura de procesos que debe ser estudiado con mayor detalle y reconfigurar
según corresponda.
Considere un proyecto de software que cuenta con 10 desarrolladores
trabajando durante 12 meses (480 personas-semanas). Si cada tarea de desarrollo
representa uno personal semanas de esfuerzo que habría 480 nodos hoja en el
desarrollo de software sub-árbol de la EDT. Asumiendo el desarrollo de software
(diseño, código, prueba) es del 50% del esfuerzo total, y partiendo del supuesto
de todas las tareas del proyecto se descomponen a un nivel de un personal
semanas, la EDT tendría 960 nodos hoja. En contraste, un PEP que tiene 6
niveles con un abanico de salida de 7 en cada nodo (a 6 7 WBS) tendría 76
tareas nodo hoja (117,659). Es evidente que un 6 7 EDT es suficiente para que
los más grandes megaproyectos.
Otra consideración de diseño: si un nodo en su WBS tiene, por ejemplo, 3 o 4
sub-niveles con fan-outs de 5 o 6 en cada nodo, esto puede indicar la necesidad
de “escindir” ese segmento de la WBS en un separada subproyecto (a 3 6
WBS tiene 216 tareas nodo hoja).
WBS Diseño Directriz 8: Utilizar un sistema de numeración decimal para

especificar las actividades de trabajo y las tareas de la EDT El sistema de
numeración ilustrada en las figuras 5.5a y 5.5b ofrece una forma sistemática de la
especificación de la contención y las relaciones entre hermanos entre las
actividades y tareas. Tarea 3.2.4.3, en las figuras 5.5a y 5.5b, por ejemplo, es en
el nivel 4 de la EDT porque hay 4 dígitos en su identificador; es el elemento 3a
del cuarto elemento del segundo elemento del elemento tercero en la EDT. Todos
los elementos que tienen un 2 en la segunda posición están entre hermanos
actividades de trabajo de software (por ejemplo, las actividades Build FINAT de
las figuras 5.5a y 5.5b). Algunas organizaciones especifican los números para ser
utilizados en la designación de los elementos principales de la estructura del
proyecto. Por ejemplo, cada elemento de trabajo en cada WBS que comienza con
un 3 designaría trabajo de software, y los elementos de trabajo a partir de un 6
denotaría gestión de configuración.
WBS Diseño Directriz 9: Asignar requisitos priorizados a las actividades de

desarrollo y tareas en la EDT Cada actividad y tarea en un WBS indica el trabajo
que debe ser cumplida y productos de trabajo que deben ser producidos. La
asignación de los requisitos a las actividades y tareas de desarrollo, como se
ilustra en las figuras 5.5a y 5.5b, proporciona especificaciones priorizadas para
los productos de trabajo para ser producidos por esas actividades y tareas.
Además de especificar las características que debe proporcionarse, los requisitos
asignado deben especificar las restricciones de diseño, capacidades,
rendimiento, caras, inter y atributos de calidad, según el caso.
Las características del producto deben asignarse únicamente a las tareas de
manera que las asignaciones de trabajo para la construcción de los módulos están
claramente definidos. Otros requisitos (diseño straints con-, capacidades,
www.it-ebooks.info
atributos de rendimiento, las interfaces y de calidad) pueden aplicarse a múltiples
módulos, incluyendo tal vez todo el sistema o producto, como se explica en
www.it-ebooks.info
Capítulo 3. Estos requisitos deben asignarse a la actividad de más alto nivel para
que se apliquen y sean “fluyó hacia abajo” a los descendientes de esa actividad.
WBS Diseño Directriz 10: Diseño de la parte superior de la EDT abajo, de abajo
hacia arriba y la parte media hacia fuera El diseño de una EDT es mejor hacerlo
de forma iterativa mediante el intercalado de arriba hacia abajo, de abajo hacia
arriba, y las estrategias de medios de salida. En este sentido, los procesos
cognitivos implicados en desarrollos ing una EDT (es decir, el diseño de un
proyecto de software) no son diferentes a los observados en los diseñadores de
software [Walz93].
el desarrollo de arriba hacia abajo de una EDT procede dividiendo el alcance
del proyecto en un conjunto de actividades de alto nivel y, sucesivamente, la
descomposición de las actividades hasta que se especifica un conjunto de tareas
que satisfacen los criterios de descomposición de la EDT mencionados
anteriormente. el desarrollo de abajo hacia arriba de una EDT procede mediante
la identificación de un conjunto de tareas que se deben realizar y agrupar tareas
relacionadas en las actividades. el desarrollo de medianos a cabo de una EDT
procede mediante la identificación de una actividad de nivel medio que debe ser
realizada, posando descomposición en tareas y / o actividades subordinadas,
agrupación con actividades similares, y conectar el conjunto relacionado de
actividades a un nivel más alto de actividad .
WBS Diseño Directriz 11: Usar paquetes de trabajo para especificar las tareas de
desarrollo Los paquetes de trabajo contienen las especificaciones de las actividades y
tareas en una EDT. Tareas son los elementos del nivel más bajo en la EDT. Paquetes
de trabajo para las actividades son agregaciones de paquetes de trabajo para las
actividades y tareas subordinadas.
Un paquete de trabajo debe contener:
• el número WBS correspondiente y el nombre,

• una breve descripción de la tarea,
• duración estimada,
• recursos necesitados,
• tareas predecesoras y sucesoras,
• productos de trabajo a ser producidos,
• productos de trabajo que serán colocados bajo control de versiones (baseline),
• factores de riesgo (es decir, los posibles problemas que puedan interferir con
el complemento ción exitosa del paquete de trabajo), y
• criterios de aceptación objetivos para los productos de trabajo generados por
la tarea.
Una plantilla para paquetes de trabajo se ilustra en la Tabla 5.3a; un ejemplo se

proporciona en la Tabla 5.3b.
WBS Diseño Directriz 12: Analizar los paquetes de trabajo para las propiedades
deseadas Los atributos de los paquetes de trabajo, y las colecciones de paquetes
de trabajo, se pueden analizar para determinar diversos factores del proyecto. Por
ejemplo, el costo estimado de personal para ejecutar un paquete de trabajo se
puede determinar a partir de los números y tipos de personas especificadas y la
duración estimada de la tarea. En la Tabla 5.3b, el coste de personal es los
sueldos cargados (es decir, pagar gastos generales más) por 10 personas-semanas
www.it-ebooks.info
de esfuerzo diseñador senior. El costo de otros recursos se puede determinar de
manera similar: la estación de trabajo y herramientas de software en la Tabla 5.3b
pueden estar disponibles sin costo, o un costo que debe soportar esta tarea, o el
costo puede ser amortizado a través de esta tarea y otras tareas que se utilizar
www.it-ebooks.info
Plantilla TABLA 5.3A para paquetes de trabajo

Tarea identificador: «número WBS y el nombre »
Tarea Descripción: «breve descripción" Estimado
Duración: «días o semanas » Recursos
necesitados:
Personal: «número de personas necesarias para completar esta
tarea" Habilidades: habilidades «personal necesario para completar esta
tarea"
Herramientas: «software y hardware necesario»
Viajes: «a dónde? por cuanto ¿largo?"
Otros: «otros recursos necesarios para completar esta tarea"
Predecesor tareas: «para ser completados antes de esta tarea puede
comenzar » Sucesor tareas: «arranca después de esta tarea es
terminado"
productos de trabajo: «salidas de este tarea"
Las líneas de base: «productos de trabajo a ser puestos bajo control de
versiones" Riesgo factores: «los problemas potenciales de este tarea"
Aceptación criterios: «para los productos de trabajo de este tarea"
TABLA 5.3BA ejemplo paquete de trabajo

Tarea identificador: 3.2.2.1 transacción Diseño procesador
Tarea Descripción: Especificar arquitectura interna del módulo de procesamiento de
transacciones Estimado duración: 2 semanas
Recursos necesitados:
Personal: 2 senior de telecomunicaciones diseñadores
Habilidades: Los diseñadores deben saber UML
Herramientas: Una estación de trabajo con Rapsody
Viajes: Tres días de revisión de diseño en San Diego para 2 personas
predecesor tareas: 3.2.1 Desarrollar la arquitectura del sistema
Sucesor tareas: 3.3.2.2 Implementar transacción procesador
productos de trabajo: especificación de arquitectura para el procesamiento de
transacciones y Las líneas de base del plan de prueba creado: especificación de
arquitectura para el procesamiento de transacciones y Riesgo plan de texto
factores: no Diseñadores identificado
Los criterios de aceptación: El éxito de la inspección del diseño de los compañeros y la
aprobación de la transacción
diseño del procesador por el arquitecto de software
esos recursos; los gastos de viaje se puede determinar e incluido en el coste de

ejecutar el paquete de trabajo (en la Tabla 5.3b, dos de ida y vuelta a San Diego y
3 días apoyo de viaje para 2 personas).
Los costos estimados para una colección de paquetes de trabajo pueden ser
agregados (es decir, enrolladas) para determinar los elementos de costo para
diferentes tipos de actividades y determinar la estimación de los costes totales de
la actividad de los padres. Los costos estimados de las tareas y actividades de
desarrollo pueden ser enrolladas para proporcionar un costo estimado para el
desarrollo de software, que puede ser utilizado como base de cálculo para todo el
proyecto. Por ejemplo, se estima un proyecto a un costo de $ 100.000 USD si el
desarrollo de software se estima que costará $ 50.000 dólares y se estima que el
50% de
www.it-ebooks.info
coste global del proyecto (50% quizá determinada a partir de datos históricos
dentro de la organización).
Si el roll-up de los resultados de costos en una estimación que supera la
restricción en el presupuesto del proyecto, se puede empezar en el nivel superior
y reasignar porciones del presupuesto a las actividades y tareas de una manera de
arriba hacia abajo de manera que las asignaciones al subordi - elementos nate de
cada actividad no exceden la cantidad asignada a esa actividad. Esto puede
implicar la eliminación o la simplificación de algunos requisitos del producto y /
o incurrir en mayores niveles de riesgo.
WBS Diseño Directriz 13: Deducir la red del cronograma de los paquetes de trabajo
Una red de programación para un conjunto de tareas puede ser construido a partir de
las duraciones, predecesores y sucesores de los paquetes de trabajo para esas tareas,
como se explica en la sección siguientes de este capítulo. La construcción de la red
del cronograma puede revelar discontinuidades, circularidad, y otras inconsistencias
entre predecesor y tareas sucesora que se pueden resolver mediante el refinamiento
iterativo de las especificaciones de los paquetes de trabajo.
WBS Diseño Directriz 14: Determinar las necesidades de recursos utilizando los
paquetes de trabajo y la red del cronograma Conociendo el tiempo en el horario
cuando se planifican diversas tareas que se produzca permite la determinación de
las fechas en las que se necesitarán varios tipos de recursos y la duración para la
que se requieren; por ejemplo, la fecha de necesidad de los diseñadores de alto
nivel no identificados en la figura 5.5b se puede determinar a partir del programa
de desarrollo. Si la fecha de necesidad es de tres meses, por lo tanto, no hay
tiempo suficiente para adquirir los diseñadores; si la fecha de necesidad es la
próxima semana, es probable que en un gran problema porque el fracaso para
completar el paquete de trabajo a tiempo demorará tareas posteriores y podría
retrasar la finalización del proyecto. perfiles de recursos para los diferentes tipos
de recursos necesarios se pueden producir mediante la suma de las necesidades
de recursos a través de la programación, como se ilustra más adelante en este
capítulo.
WBS Diseño Directriz 15: Revisar y elaborar la EDT periódicamente y función

de los acontecimientos Los elementos de los WBS iniciales se descomponen a
niveles que satisfagan los criterios de descomposición PEP. A medida que el
proyecto evoluciona, crece la comprensión y cambiar circunstancias; mayor nivel
de detalle puede ser añadido para facilitar las asignaciones de trabajo a las
personas y equipos. elementos de trabajo adicionales pueden ser identificados y
otros revisados. La EDT debe actualizarse cada mes de forma de onda a la
rodadura. También eventos tales como grandes cambios en los requisitos,
calendario, y los recursos deben reflejarse en una EDT revisado. La EDT se debe
colocar bajo control de versiones para identificar claramente la versión actual y
para proporcionar un registro histórico de la evolución de la EDT.
Un enfoque alternativo es para intercambiar el orden de las guías 11, 12, 13 y
14 mediante el desarrollo de primera la red y los recursos estimaciones de
programación para cada tarea en la red del cronograma (directrices 13 y 14) y a
continuación, utilizando la red horario y estimaciones de recursos a especificar y
analizar los paquetes de trabajo (directrices 11 y 12). En cualquier caso, como se
demostrará en el capítulo 8, las especificaciones de los paquetes de trabajo para
los elementos PEP son esenciales para asignar el trabajo a los equipos de
desarrollo y seguimiento del progreso de su trabajo.
www.it-ebooks.info
5.8 DESARROLLO DE LA cronograma del proyecto
Los paquetes de trabajo para sus tareas especifican las duraciones estimadas de
las tareas y las tareas predecesoras y sucesoras. Dada una colección de paquetes
de trabajo, una lista de tareas tales como el de la Tabla 5.4 se pueden desarrollar
utilizando la información predecesor y sucesor contenida en los paquetes de
trabajo. Como alternativa, puede construir primero una lista de tareas como un
paso inicial en la especificación de los paquetes de la EDT y de trabajo. Una lista
de tareas puede ser representado como una red horario tal como el de la figura
5.6; la figura contiene la información de la Tabla 5.4, pero lo transporta en una
representación diferente. Tenga en cuenta que sólo las tareas (elementos de nivel
más bajo) de la Tabla 5.4 se muestran en la Figura 5.6. En adi- ción figura 5.6
ilustra los dos caminos críticos en el horario (ver la siguiente sección).
Una red horario bien formada, tal como la de la Figura 5.6, es un grafo acíclico
dirigido. Las flechas están anotados con los correspondientes (WBS y paquete de
trabajo) los números y las duraciones de las tareas. Los números en los nodos de
la gráfica son los hitos del proyecto. La representación en la figura 5.6 es un
diagrama de tarea-on-flecha. representaciones complementarias que colocan las
tareas de los nodos de la gráfica son utilizados a veces; en este caso, los hitos
están implícitamente representados por las cabezas de puntas de flecha, porque
una tarea posterior no puede comenzar hasta que se hayan completado las tareas
inmediatamente anteriores.
Tenga en cuenta que en la Figura 5.6 evento externo 2.1 debe ocurrir antes de
que el proyecto pueda comenzar. Algunos de sus proyectos pueden tener otros
eventos externos (es decir, eventos que no están bajo su control) que debe ocurrir
en etapas intermedias antes de que el proyecto puede continuar; por ejemplo, la
disponibilidad de una especificación de interfaz o entrega de hardware necesario.
Estos eventos externos están representados por las flechas conectados a la apro-
comieron hitos, como en el caso de evento 2.1.
TABLA 5.4 Una lista de tareas

Actividad Nume
numberDescriptionPredecessorsDuration ro de
persona
l
2.1 Recibir la aprobación para - - -
3.1 procederlos requisitos
analizar 2.1 1 2
3.2 Diseño
3.2.1 Rediseñar los componentes 3.1 6 4
3.2.2 existentes
El diseño de nuevos 3.1 3 1
3.2.3 componentes
las interfaces de diseño 3.2.2 1 2
3.3 implementar código
3.3.1 Implementar nuevo código 3.2.2 6 2
3.3.2 Modificar código existente 3.2.1, 3.2.3 5 1
3.4 aplicación de acabado
3.4.1 Desarrollar un plan de 3.2.2 2 2
3.4.2 integración
prueba de la unidad de acabado 3.3.1, 3.3.2 2 2
3.4.3 actualizar la documentación 3.3.1, 3.3.2 2 3
3.5 Integrar y prueba
3.5.1 Desarrollar pruebas de 3.4.1 1 3
3.5.2 integración
Realizar pruebas de integración 3.4.2, 3.4.3, 3.5.1 1 2
3.6 Realizar pruebas de aceptación 3.5.2 1 1
www.it-ebooks.info
5.8 DESARROLLO la programación del proyecto 189
5
3.4.1 (2)
3.5.1 (1)
2.1 3.2.2 3
(3) 3.3.1
(6)
3.1 3.5.2 3.6
1 2 8 9 10
(1) (1) (1)
3.2.3 (1) 3.4.2 (2)
(0) 16
camino semanas
critico 3.2.1 3.3.23.4.3
4 67
(6) (5) (2)
Mn = tareas; (X) = duración de la

actividad
norte = hitos;
FIGURA 5.6 Una red de actividad-ruta crítica
Tabla 5.5 hitos para la red de horario en la figura 5.6

Descripción del evento
1 Iniciación del proyecto
2 El análisis de requerimientos completado
3 Diseño de nuevos componentes completado
4 Los componentes existentes rediseñaron; interfaces con nuevos
componentes diseñados
5 plan de integración completado
6 Nuevo código implementado; código existente modificado
7 documentación actualizada
8 Prueba de la unidad terminada; documentación actualizada; pruebas de
integración listo
9 completaron las pruebas de integración
10 completaron las pruebas de aceptación
También tenga en cuenta la tarea “ficticia” de cero hitos duración de conexión

7 y 8. Inserción hito 7 y una tarea de duración cero permite la presentación de
informes por separado de terminaciones de tareas para tareas 3.4.2 y 3.4.3.
Debido a que estas tareas están en caminos críticos (ver la siguiente sección), es
importante saber que cada tarea se ha completado y, si no se alcanza hito 8 como
estaba previsto, que la tarea se ha retrasado. hitos adicional y tareas ficticias
pueden ser insertados en una red horario, según se desee, para mejorar la
granularidad de los informes de progreso.
Los números en los círculos son los hitos del proyecto que se utilizan como
indicadores de progreso durante la ejecución del proyecto. La consecución de
un hito se determina por el Ing verify- que todas las tareas a lo largo del camino
que conduce a ese hito se han completado con éxito. Una tarea se ha completado
con éxito mediante el cumplimiento de los criterios de aceptación de los
productos de trabajo producidos por esa tarea, tal como se especifica en el
paquete de trabajo de la tarea. Los hitos para la Figura 5.6 se enumeran en la
Tabla 5.5.
www.it-ebooks.info
Tareas 3.2.1, 3.3.1, 3.3.2 y (3.2.2) y tal vez deben ser descompuestos en sub-
tareas con paquetes de trabajo asociados. Esto se debe a que los excesos en las
largas duraciones de estas tareas no proporcionarían una alerta temprana de
problemas de tiempo (más sobre esto en el capítulo 8).
5.8.1 El método crítico-Path

La duración de cada camino a través de una red de horario puede ser determinado
mediante la suma de las duraciones de las tareas a lo largo de ese camino. Un
camino que tiene la duración más larga es una ruta crítica. Una ruta crítica es
crítica en el sentido de que cualquier retraso en la realización de las tareas a lo
largo de ese camino retrasarán la finalización prevista del proyecto a menos
compensada por la terminación temprana de otras tareas en ese camino. Los
caminos críticos en la figura 5.6 se indican mediante las líneas en negrita. Como
se ilustra, puede haber más de un camino crítico en una red de horario. La ruta
crítica (o trayectorias) determina el calendario general. Las duraciones de los dos
caminos críticos en la Figura 5.6 son 16 semanas. Esta es la duración estimada
del proyecto.
Este enfoque para la determinación de un programa del proyecto se denomina
el método de la ruta crítica (CPM). Cualquier exceso en los horarios para las
tareas en una ruta crítica se extenderán a toda la programación a menos que otras
tareas en que la ruta crítica se acaban en menos tiempo de lo estimado para
compensar los excesos.
Cada camino en una red de CPM que no es crítico ha asociado tiempo de
holgura cero. Por ejemplo, la suma de las duraciones de las tareas a lo largo de la
parte superior más trayectoria en la figura
5,6 (denotado por hitos 1, 2, 3, 5, 8) indica que hito 8 se puede llegar en 7
semanas. Sin embargo, el proyecto no puede continuar hasta que las tareas 3.4.2
y 3.4.3 también llegar a 8 hito en la semana 14. La mayor parte de arriba ruta, por
tanto, tiene 7 semanas de tiempo de holgura entre los hitos 0 y 8. tiempo de
holgura se pueden utilizar para ajustar la programación de las tareas no críticas.
Por ejemplo, la tarea 3.4.1 podría ser programada para las semanas 8 y 9 si los
recursos no están disponibles para ejecutar la tarea en las semanas 5 y 6 (la
primera hora de inicio de la tarea 3.4.1). tiempo de holgura es también conocido
como flotador. Tareas en una ruta crítica tienen cero flotador.
5.8.2 El método PERT

El método de la ruta crítica ofrece un calendario previsto de un proyecto, pero no
proporciona ninguna indicación de la probabilidad de cumplir ese horario. Por
ejemplo, ¿cuál es la probabilidad de que el proyecto representa en la Figura 5.6
se puede completar en los estimado de 16 semanas? Es de 16 semanas demasiado
optimista, sobre la derecha, o demasiado pesimista?
El método PERT proporciona distribuciones de probabilidad para el logro de
hitos del proyecto en la fecha prevista, en función de la probabilidad de
completar cada tarea a lo largo de la ruta a ese hito. Para utilizar el método
PERT, tres números se especifican para cada tarea, como se ilustra en la Figura
5.7: un optimista (la más corta probable) duración estimada, el 50% duración
probablemente estimado, y una (la más larga probable) duración estimada
pesimista. Los tres estimaciones para cada tarea se utilizan para calcular el valor
esperado y la desviación estándar de una función de probabilidad para cada tarea.
Los valores esperados y desviaciones estándar de las funciones de probabilidad
para las tareas a lo largo de una ruta a un hito se utilizan para calcular la
www.it-ebooks.info
distribución de probabilidad de lograr ese hito en varios momentos (ver la barra
lateral PERT para el PERT
www.it-ebooks.info
5.8 DESARROLLO la programación del proyecto 191
CÁLCULO DE CAMINOS Y CRÍTICOS períodos de inactividad
caminos críticos se pueden encontrar sumando las duraciones de las tareas en

cada camino a través de una red de horario y la selección de las trayectorias
más largas (o la más larga en el caso de un único camino crítico). Un enfoque
algorítmico para determinar las rutas críticas y tiempos de holgura para las
tareas no en una ruta crítica implica calcular las siguientes cantidades
asociadas a cada tarea: EST, EFT, LST, y LFT.
EST (Hora de inicio más temprana)

EST es la primera vez que una tarea se puede iniciar. La EST de una tarea es
la EST de la tarea anterior más la duración de esa tarea anterior. Si hay varias
tareas preceden inmediatamente el hito de inicio de la tarea para la cual se está
calculando la EST, se debe utilizar la tarea anterior, que tiene el mayor EST
más la duración de esa tarea. La duración del proyecto es la EST de la tarea
inexistente que seguiría el hito de la finalización del proyecto (es decir, la EST
asociado en el hito final). La EST en hito 10 de la figura 5.6 es de 16 semanas.
EFT (Hora de finalización más temprana)

EFT es la hora más temprana a la que se puede completar una tarea. EFT es
EST más la duración de la tarea.
LST (Última Hora de inicio)

LST es el último tiempo en el que una tarea se puede iniciar sin retrasar la
finalización del proyecto. LST se calcula estableciendo la LST en el hito final
igual a la EST en ese hito. La LST de cada tarea anterior se calcula restando la
duración de la tarea posterior de la LST de la tarea subsiguiente. Por ejemplo, el
LST de tarea 3.6 en la Figura 5.6 es 15 (16 1). Si hay varias tareas emanan del
hito el que termina una tarea, se utiliza la que tiene el más pequeño LST. En la
figura 5.6 el LST asociado con tarea 3.2.2 es 3 porque los LSTs de tareas 3.3.1,
3.2.3, y 3.4.1 son 6, 6, y 11, respectivamente, y 6 (el LST más pequeño) menos 3 (
la duración de la tarea 3.2.2) es igual a 3.
LFT (Última Hora de finalización)

LFT es la última vez que una tarea se puede acabar sin demora la finalización
del proyecto. LFT para cada tarea es LST más la duración de la tarea.
El tiempo de holgura, o flotador, asociado con cada tarea es EST LST (o EFT
LST).
Tareas en una ruta crítica tienen cero tiempo de holgura. free float es el tiempo
de holgura disponible para una tarea cuando todas las tareas anteriores y todas
las tareas posteriores comienzan tan temprano como posible (EST). holgura
total para una tarea es el tiempo de holgura disponible cuando todas las tareas
precedentes en el camino de esa tarea comienzan tan pronto como sea posible
(EST) y todas las tareas posteriores comienzan tan tarde como sea posible
(LST). holgura de tiempo disponible para una tarea se encuentra entre
corchetes por flotación total menos de flotación libre; sin embargo, utilizando
toda la holgura total disponible a una
www.it-ebooks.info
tarea hará que todas las tareas posteriores en que la ruta crítica, porque todas
esas tareas continuación, se iniciará lo más tarde posible.
CPM también se puede utilizar para rastrear el progreso de un proyecto.
Cada hito se puede comprobar fuera a medida que se alcanza; fracaso para
lograr un hito como pro porciona programadas alerta temprana de riesgos para
completar el proyecto a tiempo. caminos críticos pueden ser, y deben ser,
volverse a calcular en el proyecto evoluciona.
Una nota histórica

El método de la ruta crítica se desarrolló a finales de 1950 por MR Walker de
EI DuPont de Nemours y Co. y JE Kelly de Remington Rand como un
mecanismo para la programación de la construcción y renovación de plantas
químicas.
fórmulas). Cálculo de la distribución de probabilidad para el hito final
proporciona una gama de duración de los proyectos estimados en varios niveles
de probabilidad.
Un método directo para el cálculo de la probabilidad de completar un proyecto
en el tiempo Ts o antes, P (t Ts), consiste en calcular el valor medio y
desviación estándar de la función de densidad de probabilidad para el hito final
en base a la prob - aptitud funciona de las tareas en una ruta crítica para el hito
final. El valor medio
es la suma de los valores medios a lo largo de la ruta crítica. La desviación
típica es la raíz cuadrada de la suma de los cuadrados de las desviaciones
estándar a lo largo de la ruta de cal criti- (ver la barra lateral PERT de las
fórmulas PERT). caminos críticos pueden ser computadas utilizando las
estimaciones de 50% probables para cada tarea.
Varios valores de P (t Ts) se puede obtener usando una tabla de Z-
distribución estándar y la fórmula: t sZ metro, donde t Ts.
La probabilidad se obtiene leyendo el valor de P correspondiente al valor de Z
en la tabla Z-distribución.
Si, por ejemplo, el valor medio es = 12 y la desviación estándar es de = 3
para hito 10 en la figura 5.7, la probabilidad P (t Ts) de completar el proyecto
en los tiempos indicados t o en menos tiempo se enumeran en la Tabla 5.6. Otros
valores de P pueden ser
5
3.4.1
(2-3-4) 3.5.1
(1-1-2)
3
3.2.2
3.3.1
(1-2-4)
(4-6-8) 3.5.2
3.1 3.6
1 2 8 9 10
(1-2-3) 3.2.3 3.4.3 (1-2-5) (1-2-2) (1-1-1)
(1-3-5)
(0)
3.2.1 3.3.2 3.4.2
4 6 7
(5-6-8) (4-5-8) (1-2-4)
mn = actividades; n = hitos;
(AMB) = estimaciones de duración
de actividad
Figura 5.7 Una red PERT programación
www.it-ebooks.info
5.9 DESARROLLO DE perfiles de recursos 193
TABLA 5.6 probabilidad de completar un proyecto en el

tiempo t o menos cuando = 12 y = 3
Z PAG (T t
Ts)
0 50% 12
1 84% semanas
15
2 97,7% semanas
18
semanas
obtenido usando la fórmula y una mesa de Z-distribución. Por ejemplo, es 90%

proble- capaz el proyecto se puede completar en aproximadamente 16 semanas o
menos, si = 12 y = 3.
5.8.3 Listas de tareas de Gantt

Hay dos tipos de diagramas de Gantt: Gantts de tareas y recursos Gantts. Un
gráfico de tarea-Gantt (el más comúnmente utilizado de los dos) es un gráfico de
tareas frente a los tiempos en los que está previsto que las tareas que se produzca
(se discuten diagramas de Gantt recursos posteriormente). El gráfico tarea-Gantt
en la Figura 5.8 se deriva de la red de CPM en la Figura 5.6. Tenga en cuenta que
el eje vertical representa la estructura de la EDT. Tenga en cuenta también que
sólo las tareas (elementos de nivel más bajo de la EDT) se muestran en la figura
5.8; los horarios de las actividades de más alto nivel se indican con flechas que
abarcan todo el alcance de las tareas que están subordinadas a las actividades.
Las tareas sombreadas son aquellos en los caminos críticos. Tenga en cuenta que
esas tareas se ordenan de forma consecutiva en la línea de tiempo. Las tareas no
críticas (en el sentido de programación) se muestran con tiempos de inicio más
temprano (EST) y los tiempos de acabado más tempranas (EFT) indicó. La extensión
de la “caja” para cada tarea no crítica indica la última hora de finalización (LFT) para
esa tarea en función de las limitaciones de programación. La diferencia entre el EFT
y LFT es el flotador libre para cada una de las tareas en función de la EST para cada
tarea (ver la barra lateral en el cálculo de rutas críticas y tiempos de holgura).
Figura 5.9 es una versión aumentada de la figura 5.8; que contiene sólo las
tareas. Los números asociados con las tareas en la Figura 5.9 son el número de
personas necesarias para realizar las tareas; que se obtuvieron de la Tabla 5.4.
Los números a lo largo del eje x son las sumas de las personas que se necesitan
para llevar a cabo todas las tareas en los períodos de tiempo indicados. Se
obtienen mediante la suma de los números en cada columna.
La simplicidad de la representación es la principal ventaja de los gráficos de
Gantt de tareas. La principal desventaja es que las dependencias de horario entre
las tareas no críticas no están representados de manera explícita. Para superar este
problema, puede insertar enlaces en un diagrama de Gantt para mostrar las
dependencias, como en la figura 5.10, o puede referirse a la red horario para ver
las dependencias.
5.9 DESARROLLO DE perfiles de recursos
Un diagrama de Gantt de tareas anotado con los requisitos de recursos, como en

las figuras 5.9 y 5.10, es una herramienta conveniente para el desarrollo de los
perfiles de recursos para su proyecto. El perfil personal ing result-, basándose en
los tiempos de inicio más temprana para todas las tareas, se ilustra en la figura
5.11. Los números asociados con las áreas sombreadas indican los recursos
necesarios para las tareas en las rutas críticas. Los otros números indican los
www.it-ebooks.info
recursos necesarios para las tareas programadas no críticos en sus tiempos de
inicio más temprana.
www.it-ebooks.info
PERT (Técnica de revisión y evaluación de programas)
En el enfoque PERT, se proporcionan tres estimaciones para cada tarea:
un: La duración más corta estimado (optimista)

metro: El 50% de la duración probable estimado
segundo: La duración estimada más larga (pesimista)
Si las distribuciones de probabilidad beta se supone para las tareas, los tres
valores se pueden utilizar para calcular la media de la función de densidad de
probabilidad para cada tarea.
La media m se calcula como
un
metro 

.
6
El cuadrado de la desviación estándar se calcula como
segundo
s 2 

x.
El valor de x varía, dependiendo de los niveles de probabilidad usadas para

asignar valores a a y b. Si A y B son asignados al 5% los niveles (optimistas) y
95% (pesimistas) de probabilidad, la fórmula es
segundo  es decir, x 6.

s 2  6
Si un está asignado en el nivel de 20% de probabilidad (optimista) y b se asigna

en el nivel de 80% (pesimista) La fórmula es
segundo  es decir, x 3,2.

s 2  3.2
distribuciones beta son opciones razonables para las funciones de probabilidad

porque están definidos en intervalos finitos y pueden ser asimétricos o
simétricos, dependiendo de los valores de a y b en relación a m.
La media de la densidad de probabilidad acumulativa para las tareas a lo largo
de un camino
a un hito del proyecto es la suma de las medias de las densidades de
probabilidad para las tareas en la ruta a ese hito. La desviación típica de la
función de densidad de probabilidad en el hito es la raíz cuadrada de la suma
de los cuadrados de las desviaciones individuales.
redes de programación no triviales tienen varias rutas. determi- nación
completa de las funciones de probabilidad para el hito de la finalización de un
proyecto implicaría el cálculo y para cada ruta en la red. Un enfoque
simple y eficaz es calcular la función de distribución de probabilidad para la
www.it-ebooks.info
5.9 DESARROLLO DE perfiles de recursos 195
tareas en el (o a) la ruta crítica, donde la ruta crítica se determina usando los

valores más probables (m) de las tareas.
Una Nota histórica

PERT fue desarrollado a finales de 1950 para el programa de misiles Polaris
por el Programa División de Evaluación de la Oficina de Proyectos Especiales
de la Marina de los EE.UU., con la ayuda de la división de sistemas de misiles
de Lockheed y la empresa de consultoría de Booz-Allen y Hamilton. Debido a
que el programa de Polaris era un proyecto de investigación y desarrollo que
involucra numerosos contratistas y numerosas tecno- logías, el gran número
de incertidumbres en la conducción del programa dio como resultado el
enfoque probabilístico para programar estimación.
Aunque la mayoría de los proyectos de software no son tan grande y
complejo como fue el programa de POLARIS, no obstante se caracterizan por
muchas incertidumbres. El método PERT es, pues, aplicable. El mayor
problema en el uso de PERT es la estimación de tres duraciones para cada
tarea. “¿Qué pasaría si” el análisis (probando diferentes valores para ver las
consecuencias de “qué pasaría si”) se puede utilizar en ausencia de datos
sólidos en los que basar las estimaciones.
métodos PERT se discuten en el Capítulo 6 (técnicas de estimación) y el
Capítulo 9 (gestión de riesgos) de este texto.
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.4.3
3.5
3.5.1
3.5.2
3.6
123 4567 8 9 10 11 12 13 14 15 16
Figura 5.8 Task-Gantt diagrama correspondiente a la figura 5.6
www.it-ebooks.info
2
3.1 4 4 4 4
3.2.1
3.2.2
3.2.3 1 2
3.3.1 2
3.4.1 2
3.3.2
1 1 2
3.4.2
1 2
3.4.3
3.5.1
3.5.2 1
2 10 8 7 3 1 4 2
3.6 5
123 4567 8 9 10 11 12 13 14 15 16
SEMANA
FIGURA 5.9 Un gráfico de tarea-Gantt aumentada
3.1
3.2.1
3.2.2
3.2.3
3.3.1
3.4.1
3.3.2
3.4.2
3.4.3
3.5.1
3.5.2 1
3.6 2 5 10 8 7 3 1 4 2
123 4567 8 9 10 11 12 13 14 15 16
SEMANA
FIGURA 5.10 Un gráfico de tarea-Gantt
vinculado
El perfil del personal en la figura 5.11 no es realista para la mayoría de los

proyectos y la mayoría de las organizaciones. No es realista esperar que las
personas se pueden programar para “drop in” y “abandono” de un proyecto sobre
una base semanal. también la alternativa de mantener el pico personal- ing
asignado al proyecto (10 personas en la Figura 5.11) y el uso de los miembros del
personal ya que se necesitan no es realista. ¿Qué hacen el resto del tiempo?
¿Quedarse en casa? Interferir con el trabajo de otros? ¿Ir al cine? ¿Ir a pescar? Ir
a esquiar? ¿Y cuál es el impacto de pagar al personal por el tiempo
improductivo? Podrían trabajar en otros proyectos, pero la programación de
recursos para varios proyectos en este nivel de granularidad no es práctico.
www.it-ebooks.info
5.9 DESARROLLO perfiles de recursos 197
# de la
gente
inicio más temprana
10 PERFIL PERSONAL
123 456 78 9 10 11 12 13 14 15 16
SEMA
NA
FIGURA 5.11 Características del personal para los tiempos de inicio más
temprana para todas las tareas
10 PERFIL DE
ÚLTIMO-
# de 8 START
Gente
1234 56 78 9 10 11 12 13 14 15 16
Semana
FIGURA 5.12 Características del personal para las últimas horas de inicio
para todas las tareas
Los tiempos de holgura ilustran en las figuras 5.8, 5.9, y 5.10 se pueden usar
para ajustar el perfil de la dotación de personal en un intento de obtener un perfil
de la dotación de personal más factible. Si, por ejemplo, se va a programar todas
las tareas no críticas en sus últimas horas de inicio, el perfil del personal en la
figura 5.12 se traduciría. Este perfil no es realista por dos razones:
1. los picos y valles en el perfil y

2. la trama cruzada indica todas las rutas de la red del cronograma son críticos
porque a partir de todas las tareas lo más tarde posible significa un retraso en la
realización de cualquier tarea que retrasará el calendario general.
En la figura 5.12 se muestra el rayado cruzado para la ruta crítica original de

inclinación como en la figura 5.11; el rayado cruzado en la parte superior de la
figura 5.12 representa la criticidad de los otros caminos. Si intenta varias
combinaciones de programación para las tareas no críticas en la figura 5.6, se
dará cuenta de que no es posible obtener un perfil personal plana, como el que se
ilustra en la Figura 5.13. El horario / recurso
www.it-ebooks.info
# del
6 personal
5
4
1 23 4 56 78 9 10 11 12 13 14 15 16
SEMANA
FIGURA 5.13 Un perfil personal deseable, sino imposible de obtener para la Tabla 5.4 y
la Figura 5.6
problema de asignación en este ejemplo es causado por el gran número de opers

desa- software necesarios en las semanas 4, 5 y 6, como se indica en las figuras
5.9 y 5.10.
El problema de asignación de recursos se complica aún más cuando hay varios
tipos de recursos que se asignarán a la programación (por ejemplo, diseñadores,
programadores, probadores, seguridad y especialistas en seguridad, escritores
técnicos). Otros factores que complican la asignación de recursos incluyen:
• la falta de suficientes recursos de diversa índole, cuando sea necesario, y

• el intercambio de recursos entre múltiples proyectos y programas.
A pesar de estas dificultades, se recomienda que su primer paso en el desarrollo

de un programa del proyecto proceder sin tener en cuenta las limitaciones de los
recursos y la asignación de recursos. A continuación, puede iterar sobre el plan
inicial para lograr un equilibrio aceptable entre los horarios, perfiles de recursos,
y los requisitos. opciones aceptables para achiev- ing un equilibrio incluyen:
• la reordenación de las tareas, de modo que se necesitan menos recursos en las

semanas pico,
• extender el horario de modo que se necesitan menos recursos en las semanas
pico,
• la adición de más recursos para mantener el calendario,
• utilizando los recursos más productivos de manera que se necesitan menos
números, y
• descoping los requisitos para que se necesitan menos recursos y menos
tiempo.
Las combinaciones de estas opciones pueden ser utilizadas para lograr un

equilibrio aceptable.
opciones inaceptables incluyen:
• la producción de un plan realista que no tiene ninguna posibilidad de ser

aplicado con éxito;
• la planificación de las horas extraordinarias; y
• las actividades de control de calidad que reducen o eliminan tales como
inspecciones, revisiones y pruebas
www.it-ebooks.info
Por desgracia, las opciones se eligen a menudo inaceptables. La planificación de
las horas extraordinarias es una mala elección en particular porque la gente va a
ser cansado y desmotivado. también
www.it-ebooks.info
5,11 ESTIMACIÓN PROYECTO ESFUERZO, COST y programar 199
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.4.3
3.5
3.5.1
3.5.2
3.6
1 23 4567 8 9 10 11 12 13 14 15 16
SEMANA
FIGURA 5.14 Un gráfico WBS-Gantt para un programa del proyecto
la mayoría de los proyectos de software alcanzaron los períodos en que se

necesitan ráfagas cortas de tiempo extra. tiempo extra planeado no deja ninguna
reserva para esos períodos.
Las representaciones de diagramas de Gantt de las figuras 5.8, 5.9, y 5.10 se
pueden usar para planificar la programación del proyecto y desarrollar los
perfiles de recursos. Cuando se han hecho las decisiones de planificación para
tareas con tiempos de holgura asociados, un diagrama de Gantt WBS- combinado
para que el calendario se puede preparar, como en la figura 5.14. Como antes, las
barras transversales de la eclosión indican las tareas de la ruta crítica, y las barras
abiertas indican las tareas para las que existe tiempo de holgura. También tenga
en cuenta que sólo las tareas se programan; el calendario para cada actividad se
extiende por la extensión de los horarios de trabajo subordinadas.
5.10 CARTAS DE RECURSOS-GANTT
diagramas de Gantt de recursos se pueden utilizar para describir las tareas

asignadas a los distintos recursos. Las tareas de rejilla llenas en la Figura 5.15
son aquellos para los que es necesaria la experiencia de Joe Hotshot y el tiempo
en el que han sido programadas; las tareas programadas como en las figuras 5.8,
5.9, y 5.10 a la que Joe no se asigna se han eliminado de la figura 5.15. La figura
5.16 representa las horas semanales que serán requeridos de Joe para completar
estas tareas. Esto es claramente inviable; cada recurso debe ser asignado dentro
de las limitaciones de disponibilidad.
5.11 Estimar el esfuerzo del proyecto, costo y el horario
esfuerzo total para las tareas que se enumeran en la Tabla 5.4 es de 68 semanas-
personal; esfuerzo total viene determinado multiplicando la duración por el
número de personas para cada tarea y sumando los productos. Si el salario
cargada por el personal semanas es X y las tareas de la tabla
5.4 representan el 50% del coste del proyecto, el costo estimado es 2 X 68.
www.it-ebooks.info
Si, por ejemplo,
www.it-ebooks.info
3.1
3.2.1
3.2.2
3.2.3
3.3.1
3.4.1
3.3.2
3.4.2
3.4.3
3.5.1
3.5.2
3.6
123 4567 8 9 10 11 12 13 14 15 16
SEMANA
FIGURA 5.15 tabla de recursos-Gantt para Joe Hotshot
# De horas de trabajo por semana 3.3.1

3.4.1
3.4.2
120
3.2.1 3.3.1
3.2.2 3.3.2
80
40 3.1 3.3.2
3.3.1
1234 5 678 91011

12
Semana
FIGURA 5.16 perfil de recursos para Joe Hotshot
los salarios son cargados $ 2500 USD por semana, el costo del proyecto se estima
en
$ 340,000 USD. El enfoque del camino crítico indica que el proyecto requerirá de
16 semanas o más (por ejemplo, más para dar cuenta de las limitaciones de la
programación de recursos escasos como Joe Hotshot). El ejemplo PERT indica
que el proyecto puede ser com- pletó en 15 semanas o menos en el 85% de
probabilidad, sujeto a las limitaciones de recursos de disponibilidad.
Otras técnicas para la estimación de esfuerzo, planificación, los recursos y los
costes se presentan en el Capítulo 6.
www.it-ebooks.info
• Los planes de proyectos deben ser compatibles con los requisitos del
producto; no se puede preparar un plan para el desarrollo de un producto de
software si usted no sabe qué producto para hacer.
• Cuanto más sepa sobre el producto a fabricar, más confianza habrá en los
detalles de su plan.
• Un plan de proyecto debe ser actualizado periódicamente y, como
acontecimientos, a través de un enfoque de onda a la rodadura.
• Su plan inicial y subsiguientes planes deben mantener un equilibrio entre los
requisitos, el calendario, el presupuesto y la disponibilidad de recursos.
• Los elementos esenciales de un plan de proyecto incluyen una EDT, una red
de actividad, perfiles de recursos para las diversas clases o recursos y
estrategias para hacer frente a los factores de riesgo identificado.
• La estructura de desglose del trabajo (WBS) es una herramienta fundamental
para la planificación, el seguimiento y control de un proyecto de software.
• La vista de la arquitectura de descomposición (ADV) de la arquitectura de
software pro porciona la base para desarrollar una EDT.
• El ADV es orientado producto; frases nominales se utilizan para especificar
cosas.
• La EDT es orientado al proceso; frases verbales se utilizan para especificar
las actividades y tareas.
• Utilizando las guías para el diseño de un WBS se asegurará de que el PEP está
diseñado con el mismo cuidado que se utiliza para diseñar el producto.
• Sus WBS iniciales deben ser descompuestos para satisfacer los criterios de
descomposición de la EDT.
• Paquetes de trabajo son las especificaciones para las tareas y actividades en la
EDT.
• Paquetes de trabajo para las actividades son agregaciones de paquetes de
trabajo para las tareas y actividades subordinadas.
• La red del cronograma, las necesidades de recursos, las estimaciones de
costos, y los factores de riesgo se pueden derivar de los paquetes de trabajo.
• El método del camino crítico (CPM) se puede utilizar para determinar el
mínimo estimación acoplado duración de un proyecto y los tiempos de
holgura asociados con tareas no críticas.
• La técnica de evaluación y revisión de programas (PERT) se puede utilizar,
para determinar los tiempos, en los distintos niveles de probabilidad,
requerido para alcanzar el proyecto mile- piedras, incluyendo el hito final.
• Un gráfico de tarea-Gantt se puede utilizar para representar el camino
crítico, ilustran tiempos de holgura para las tareas no críticas, y determinar
perfiles de recursos para los diferentes tipos de recursos.
• Un gráfico de recursos-Gantt se puede utilizar para representar la carga de
recursos para varios recursos.
• opciones aceptables para la conciliación de conflictos de programación /
recursos incluyen reconstrucción averiguar la red del cronograma,
extendiendo el horario de modo que se necesitan menos recursos en las
semanas pico, la adición de más recursos para mantener el calendario,
utilizando los recursos más productivos de manera que se necesitan menos
números, descoping
www.it-ebooks.info
los requisitos para que se necesitan menos recursos y menos tiempo, y

combinaciones de los anteriores.
• opciones inaceptables para la conciliación de conflictos de programación /
recursos incluyen Pro- ducing un plan realista que no tiene ninguna
posibilidad de ser implementado con éxito; la planificación de las horas
extraordinarias; y reducir o eliminar las tareas de control de calidad, tales
como inspecciones, revisiones y pruebas.
• perfiles de recursos se pueden utilizar para calcular el esfuerzo y los costos
de los diversos recursos; cronograma del proyecto puede determinarse a
partir de la ruta crítica o a partir de cálculos PERT.
• SEI, ISO, IEEE, y PMI proporcionan marcos, normas y directrices para las
técnicas de planificación de proyectos (véase el Apéndice 5A a este
capítulo).
Referencias

Addison Wesley, 2003.
[CMMI06] SEI, CMMI ® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[Conway68] Conway, ME “¿Cómo Invent Comités haría?” Datamation (abril de 1968).
Vol.
14, No. 4, pp. 28-31.
Información-Software Procesos del ciclo de vida. Colección de Normas de
Ingeniería; IEEE producto: SE113. Instituto de Ingenieros Eléctricos y
[Walz93] Walz, DB, J. Elam, y B. Curtis. Dentro de un equipo de diseño de software: La
adquisición de conocimientos, el intercambio y la integración.
Comunicaciones de la ACM, 36 (octubre de 1993). pp. 63-67.
CEREMONIAS
5.1. Enumerar y explicar brevemente tres factores que pueden impedir, como el
director del proyecto, desde la preparación de una estimación proyecto que
tiene un 90% o mayor probabilidad de éxito.
5.2. Los supuestos en que se basan su estimación y su compromiso deben ser
documentados y aceptados por su gerente y su cliente. Enumerar y explicar
brevemente cinco supuestos (pertinentes y razonables) que puede hacer en
la preparación de una estimación que sería aceptado.
5.3. La vista de la arquitectura representa la descomposición jerárquica “es parte
de” la relación entre con- tainment módulos de software. Enumerar y
explicar brevemente los atributos deseables de módulos de software en un
ADV.
www.it-ebooks.info
CEREMONIAS 203
5.4. Supongamos que un WBS tiene una profundidad de M con un ventilador de

salida de N en cada nivel.
a. Estado, la fórmula para el número de nodos de hoja (es decir, número de
tareas) en el PEP.
b. Cuántas tareas hay en una EDT de la profundidad de 4 con un abanico de
salida de 5 en cada nivel?
5.5. Consulte las Figuras 5.5a y 5.5b, y asumir la siguiente:
• Supongamos que las tareas 3.2.1.1, 3.2.3.1, 3.2.4.1 y cada uno requiere 1
persona por 2 semanas.

• Supongamos que la tarea 3.2.2.1 requerirá 2 personas por 4 semanas.
• Suponga que las tareas 3.2.1.2 y 3.2.1.3, 3.2.3.2 y 3.2.3.3, y 3.2.4.2 y
3.2.4.3 y requerirán cada uno 1 persona durante 1

semana.
• Supongamos que las tareas 3.2.2.2 y 3.2.3.3 requerirá 2 personas por 2
semanas.
• Supongamos que la tarea 3.2.5 requerirá 2 personas por 2 semanas.
a. Preparar una red del cronograma para las 13 tareas, que muestra las
actividades e hitos secuenciales y concurrentes.
b. Prepare una lista de las 13 tareas. La lista de la EST, LST, EFT, y LFT
para cada tarea.
c. Enumerar las tareas de la ruta crítica utilizando las tecnologías
ecológicamente racionales y los LST.
d. El uso de la ruta crítica, enumerar el tiempo necesario para completar las
tareas 13.
e. Preparar un perfil personal para las 13 tareas utilizando la EST para cada
tarea.
5.6. Calcula y lista el tiempo de holgura para cada una de las tareas entre los
hitos 0 y 8 para cada uno de los caminos no críticos en la Figura 5.6.
Muestra tu trabajo.
5.7. Utilizando la plantilla para paquetes de trabajo en 5.3a Tabla, paquetes de
trabajo de diseño para 5 de los 12 tareas en la Tabla 5.4 y la Figura 5.6.
Usted tendrá que “inventar” algo de la información que falta; ser creativo,
pero no ridículo.
5.8. En el texto se afirma que 68 personas-semanas de esfuerzo es necesario para
completar las tareas en la Tabla 5.4. Realizar los cálculos y verificar esta
afirmación. Muestra tu trabajo.
5.9. Asumiendo que tiene acceso a una herramienta de programación tales como
Microsoft Project, utilice la herramienta para lograr lo siguiente:
a. Replicar la lista de tareas en la Tabla 5.4 como un WBS combinado y
diagrama de Gantt.
b. Replicar la red-ruta crítica en la Figura 5.6.
c. Observar e imprimir una lista de los períodos de inactividad asociados a
cada tarea.
d. Replicar la red PERT en la Figura 5.7. Observar e imprimir la
distribución de probabilidad de hito 10.
e. Añadir recursos de personal para cada tarea, utilizando los números de
personal en la Tabla 5.4. Observar e imprimir un perfil personal para el
proyecto.
www.it-ebooks.info
f. Observar e imprimir las listas de recursos de Gantt para cada miembro del
personal.
g. Brevemente describa cómo se intentará resolver los conflictos de
recursos en el gráfico de Gantt de recursos.
5.10. Consultar una tabla Z-distribución y completar los cálculos de los valores
de tiempo t que se muestran en la Tabla 5.6. También encuentre el valor de
Z que corresponde a P (t Ts) = 90% y calcular el tiempo correspondiente
t.
www.it-ebooks.info
APÉNDICE 5A
Marcos, estándares y directrices para las

técnicas de proyecto de planificación
5A.1 prácticas específicas de LA CMMI-DEV-v1.2 PROYECTO área de

planificación PROCESO
El marco de procesos CMMI CMMI-DEV-v1.2, [CMMI06] incluyen ticas ticas

específicas SP 2.1 (Establecer el presupuesto y calendario) y SP 2.4 (Plan de
Recursos del Proyecto) bajo SG objetivo específico 2 (Desarrollar un plan de
proyecto) en el proyecto de Plan-Ning área de proceso. productos de trabajo típicos
de SP 2.1 son:
1. los programas del proyecto

2. dependencias de horario
3. presupuesto del proyecto
Subprácticas de SP 2.1 (Establecer el presupuesto y calendario) incluyen:
1. identificar los principales hitos

2. identificar supuestos de horario
3. identificar las limitaciones
4. identificar las dependencias de tareas
5. definir el presupuesto y el calendario
6. establecer criterios de acción correctiva
Productos de trabajo típicos de SP 2.4 (Plan de Recursos del Proyecto) incluyen:
1. diccionario tarea de la EDT

2. paquetes de trabajo WBS
3. las necesidades de personal en función del tamaño y alcance del proyecto
4. instalaciones críticas / lista de equipo
204
www.it-ebooks.info
5A.3 IEEE / EIA STANDARD 1058 205
5. de proceso / definiciones de flujo de trabajo y diagramas

6. administración programa de lista
requisitos Subprácticas de SP 2.4 incluyen:
1. determinar los requisitos del proceso

2. determinar las necesidades de personal
3. determinar las instalaciones, equipos y requisitos de los componentes
Sección 7.1 de las normas ISO y IEEE 12207.0 cubre el proceso de gestión de
[IEEE12207]. Sección 7.1.2 abarca la planificación; sección 7.1.2.1 establece que los
siguientes elementos deben ser incluidos en los planes de los procesos de gestión:
• horarios
• estimaciones de esfuerzo
• recursos adecuados
• asignación de tareas
• asignación de responsabilidades
Sección 6.11.3 de 12.207,1 indica que una estructura de división del trabajo debe
ser incluido en el plan de gestión de proyectos.
planes de gestión de proyectos basados en el estándar IEEE Std 1058 ™ -1998

Norma IEEE para los planes de gestión de proyectos de software [IEEE1058]
incluirá la cláusula 5.2 (Plan de Trabajo), que contiene los siguientes elementos:
• actividades de trabajo
• asignación de horario
• la asignación de recursos
• asignación de presupuesto
De acuerdo a 1058, una estructura de división del trabajo se utiliza para mostrar
las actividades de trabajo y las relaciones entre ellos. Los paquetes de trabajo se
pueden utilizar para especificar las actividades de trabajo. 1058 establece que las
técnicas tales como hitos gráficos, listas de actividades, cartas de la actividad de
Gantt, redes, redes de actividad de la ruta crítica, y PERT se pueden utilizar para
especificar las relaciones de horario. Los diversos tipos de recursos necesarios
para llevar a cabo el proyecto se deben asignar a los elementos de la PEP y
documentados en los paquetes de trabajo.
www.it-ebooks.info
5a.4 el PMI cuerpo de conocimientos
Una guía para la Dirección de Proyectos del Conocimiento, 3ª ed. (Es decir, el
PMBOK® Guía) [PMI04], incluye secciones que son relevantes para el contenido
de este capítulo:
5.3 Crear EDT

Desarrollo 6.5 Horario
9.1 Planificación de Recursos Humanos
www.it-ebooks.info
6
Las técnicas de estimación
Las predicciones son difíciles; especialmente sobre el futuro.

-paraphrase de una cita atribuida indistintamente a Samuel Goldwyn y Yogi Berra
6.1 INTRODUCCIÓN A técnicas de estimación
El objetivo de la estimación es determinar un conjunto de parámetros que

proporcionan un alto nivel de confianza que usted será capaz de ofrecer un
producto aceptable dentro de los límites de las restricciones del proyecto. Los
parámetros y restricciones a tener en cuenta son:
• Características del producto,

• atributos de calidad,
• esfuerzo,
• otros recursos,
• programar,
• presupuesto, y
• tecnología.
Algunos de estos parámetros se especifican como limitaciones y otros se

estiman. Por ejemplo, se le puede administrar un conjunto de requisitos y una
base de la tecnología (los parámetros constreñidos por lo tanto son:
características y atributos de calidad, la plataforma de hardware y sistema
operativo), y pidió para estimar la cantidad de tiempo, esfuerzo, otros recursos, y
el presupuesto ser necesario (los parámetros estimados); también se debe indicar
su nivel de confianza en la estimación. O bien, se le puede dar un calendario,
presupuesto y

207
www.it-ebooks.info
208 Las técnicas de estimación
recursos y se les pidió estimar el conjunto de características y atributos de calidad

que se pueden desarrollar dentro de esos límites. Otras combinaciones son
posibles.
La experiencia ha demostrado que el desarrollo de estimaciones realistas para
proyectos de software es un proceso propenso a errores. Después del hecho, los
atributos del proyecto, tales como el esfuerzo real, ULE sched-, recursos, costos,
características del producto y los atributos de calidad son a menudo muy
diferentes de los parámetros estimados. Hay varias razones para esta situación
desafortunada:
• la estimación inicial de esfuerzo y el horario podría haberse basado en los

requisitos de vagas y cambiantes,
• la estimación inicial no se actualiza a medida que el conocimiento fue
adquirida y como comprensión aumenta,
• la base de la estimación podría no haber sido apropiado para el proyecto que
se estima,
• el método o herramienta que se utiliza para hacer la estimación podrían no
haber sido apropiado,
• la retirada de los expertos consultados podría haber sido incorrecta o sesgada,
• el producto final podría haber sido más grande o más compleja que asumido
al hacer la estimación,
• el horario y / o recursos podrían haber sido reducidas sin tener que ajustar
los requisitos para las características del producto y los atributos de calidad,
• los requisitos para las características del producto y los atributos de calidad
podrían haber sido incrementado sin ajustar el horario y los recursos,
• el número de desarrolladores de software disponibles y sus niveles de
habilidad podría no haber sido tan asumido al hacer la estimación, y
• factores externos tales como cambios imprevistos en el hardware y software
con interfaces o de la finalización tardía de trabajo por parte de un
subcontratista podrían haber demorado la finalización del proyecto.
El objetivo de este capítulo es proporcionar métodos, herramientas y técnicas que

pueden reducir la probabilidad de cometer malas estimaciones.
• el papel de la estimación en el modelo de flujo de trabajo para proyectos de

software;
• tres principios fundamentales de la estimación;
• medidas de tamaño y la medida del tamaño;
• cómo desarrollar una medida de tamaño;
• algunas técnicas de estimación pragmáticos, basados en la teoría, y basada en
regresión;
• cómo desarrollar, calibrar y evaluar la aceptabilidad de los modelos de
estimación basada en regresión;
• capacidades de las herramientas de estimación;
www.it-ebooks.info
6.3 Principios fundamentales de la estimación 209
• un procedimiento de estimación; y
• un formato para documentar las estimaciones.
Los cuatro conjuntos de normas y directrices para la gestión de proyectos que se

presentan en este texto; es decir, el marco CMMI-DEV-v1.2 proceso, la norma ISO /
IEEE 12207, el estándar IEEE 1058, y el Cuerpo de PMI problemas de estimación de
la dirección del conocimiento en diversos grados. Aspectos de la estimación en estos
documentos se presentan en el Apéndice 6A a este capítulo.
6.3 Principios fundamentales de la estimación
Tres principios fundamentales de la estimación se presentan y discuten en esta

sección. El primer principio fundamental de la estimación de proyectos de
software se establece de la siguiente manera:
Estimación Principio 1 Una estimación del proyecto es una proyección de

experiencias pasadas para el futuro, ajustado para tener en cuenta las diferencias
entre el pasado y el futuro.
Tres cosas son evidentes a partir de este principio:
1. debe tener algunas experiencias pasadas para aprovechar (conocida como la

base de la estimación),
2. usted debe saber algo sobre el futuro (requisitos para el sistema o producto
que va a desarrollar o modificar y
3. hay que hacer ajustes para tener en cuenta las diferencias entre el pasado y
el futuro (conocidos como los factores de ajuste).
Todas las técnicas de estimación de proyectos de software incorporan, de

diversas formas y en diversos grados, experiencias pasadas, el conocimiento del
futuro, y los factores de ajuste. Las experiencias pasadas podrían, por ejemplo,
han dado lugar a una regla de oro (una guía) que indica la productividad del
software en su organización, para su tipo de proyecto, es típicamente de 500
líneas de código entregadas de código por el personal de meses (500 DSLOC /
SM) . Si ha estimado que el producto futuro será de 50.000 líneas de código (en
base a los requisitos y las experiencias pasadas) y si el proyecto de futuro se cree
que es similar a los proyectos anteriores (sin ajustes), se requerirá un estimado de
100 meses personal- de esfuerzo (50.000 / 500).
En ausencia de factores de ajuste, es posible planificar el proyecto durante 10
meses con 10 desarrolladores de software. Si cree que el producto a desarrollar
serán más complejos que los productos anteriores, es posible que aumente el
esfuerzo estimado en 120 meses y entre el personal y planificar el proyecto
durante 12 meses con 10 desarrolladores de software; por el contrario, es posible
reducir la estimación de esfuerzo si cree que el producto esté a menos complejos
que los productos anteriores y / o cree que los desarrolladores de software han
ganado familiaridad con este tipo de productos construcción de productos
similares.
Los datos históricos sobre la base de experiencias pasadas también podrían
indicar que el número de defectos encontrados antes de la liberación del producto
es normalmente de 10 por cada mil líneas de entregado
www.it-ebooks.info
líneas de código fuente (10D / KDSLOC) y el número encontrado por los

usuarios durante los primeros 6 meses de operación son de 1 por KDSLOC. A
continuación, podría estimar que 500 defectos deben ser encontrados antes de la
liberación del producto (50 10) y 50 serán reportados por los usuarios durante
los primeros 6 meses de operación.
Al hacer estas estimaciones, es posible que haya asumido varias cosas (ya sea
explic- tamente o implícitamente). Por ejemplo, es posible que haya asumido que
el producto será similar en complejidad a las típicas construidas en el pasado; por
lo tanto, no se ha aplicado un factor de ajuste de complejidad. Es posible que
haya asumido que el ERS desarrollos del producto futuro serán similares en
capacidad de aquellos en los que la regla de oro de la productividad se basa (500
DSLOC / SM); de lo contrario, debe incluir un factor ción Ajustar- para aumentar
o disminuir la estimación basada en el supuesto de la forma en que la
productividad de los desarrolladores será diferente de la productividad en el
pasado.
Pasado
Experiencias supuestos
Características del
Procedimi
Las
ento de
producto restricciones estimacione
estimació s de
n - esfuerzo
del proyecto - programar
- defectos
- confiabilidad
Factores de ...
ajuste
Figura 6.1 El proceso de estimación
La figura 6.1 ilustra las funciones desempeñadas por los atributos del producto
a ser desarrollado o modificado, las restricciones del proyecto, las experiencias
pasadas, suposiciones y factores de ajuste. Figura 6.1 está relacionada con el
modelo de flujo de trabajo para proyectos de software en la Figura 1.1, repetidos
aquí como Figura 6.2:
requisitos
y limitaciones Proceso de
desarrollo
Cliente Planificació Asigna

ny Definición Independien
de las ciones te
Los replanifica de
Actividade V&V
gestores ción trabajo entregad
s Seguro de
directivas y o
estimación y producto
Reestimación Controlador Gestión de la s de
Retención
de datos ..........
. . ... . .

problemas
www.it-ebooks.info
Figura 6.2 Un modelo de flujo de trabajo para la gestión de proyectos de software,
haciendo hincapié en la estimación y reestimación
www.it-ebooks.info
Una comparación de las Figuras 6.1 y 6.2 muestra que los atributos del
producto se derivan de los requisitos del cliente. restricciones del proyecto
incluyen restricciones de los clientes y las directivas de la administración y
limitaciones. Las experiencias pasadas se resumen por el elemento de retención
de datos Figura 6.2; estas experiencias se pueden resumir en una base de datos de
los proyectos terminados locales, en las cabezas de los expertos, en las reglas
locales del pulgar, en el promedio de la industria, o en el folklore. Los factores de
ajuste se aplican a la cuenta para su comprensión de los requisitos y cómo se
diferencian de las experiencias anteriores, así como las diferencias en los
parámetros del proyecto, tales como niveles de habilidad, disponibilidad de
recursos y las restricciones del cronograma.
Suposiciones se basan en factores que creen que es verdad o que usted cree
que va a ser verdad. Replanificación normalmente implica reestimación, que se
basa en cambios en los requisitos, directrices y limitaciones, y como es requerido
por los informes de problemas. Continuando con el ejemplo (simple) anterior:
• los atributos del producto futuro se resumen en la estimación del tamaño de

50000 DLOC (derivado de los requisitos);
• experiencias pasadas se resumen por la regla de la productividad de pulgar
(500 DSLOC / SM) y las densidades pre-liberación y de defectos post-
liberación; y
• si no se aplican los factores de ajuste, se supone que el proyecto futuro será
similar en todos los sentidos a los proyectos anteriores en los que se basa la
estimación; factores de ajuste se aplican a la cuenta de las diferencias entre
los proyectos anteriores y la futura.
Los factores de ajuste son los atributos que hacen que proyectos
aparentemente similares (es decir, aparentemente productos similares) que
difieren en lo posible, el calendario, los recursos, el costo, características,
atributos de calidad y otros atributos de interés. factores de ajuste típicas
incluyen:
• relativa complejidad del producto,

• habilidades y capacidades de los desarrolladores,
• especificidad y la volatilidad de los requisitos y
• restricciones excesivas, tales como la presión programación.
Cada uno de estos factores (y otros) pueden ser mejores o peores que los
proyectos típicos del pasado.
factores de ajuste son importantes en la estimación de proyectos de software
porque no hay dos proyectos de software son iguales; de lo contrario, se puede
hacer una copia de algún software existente y darle a su cliente. Dicho de otra
manera, todos los proyectos de software incorpora aspectos únicos. La razón por
la que los proyectos de software es producir artefactos de software a diferencia de
cualquier otro que o su organización ha desarrollado.
En este sentido se diferencia del software de entidades físicas. Se requiere una
gran cantidad de esfuerzo para duplicar un edificio, un automóvil o un ordenador.
Cuando haya terminado, la entidad física será similar, pero no idéntica, a la
original. El objetivo de los procesos de manufactura es producir múltiples copias
de artefactos que son lo más parecidos posible, dentro de los límites de la
tecnología y de las consideraciones económicas, pero los resultados nunca son
idénticos. El objetivo principal de su proyecto de software es (o debería ser) para
www.it-ebooks.info
producir una copia aceptable, a tiempo y dentro del presupuesto. A continuación,
usted puede fácilmente
www.it-ebooks.info
producir tantas copias idénticas de su software como se desee, defectos y todos

(testigo Microsoft y otros proveedores de software).
En el ejemplo anterior, se podría pensar que el producto que se construirá será
más complejo que los típicos en el pasado, por lo que puede ajustar la estimación
al alza en un 20% para tener en cuenta el aumento de la complejidad. A
continuación, puede programar el proyecto como un proyecto de 10 meses con
una plantilla media de 12 desarrolladores de software (es decir, equivalentes de
12 a tiempo completo, ETC). Si la duración del programa está limitado a 9
meses, el ajuste lineal de la dotación de personal indicaría que se necesitan
aproximadamente 13 desarrolladores de software FTE:
120 meses-personal
FTE
13.3.
9 meses
Como se mostrará más adelante, la compensación lineal no es suficiente; Se

necesitarán más de 13,3 desarrolladores de software para compensar la
compresión horario porque requiere el mayor nivel de comunicación y
coordinación cuando se añaden más personas.
Todas las estimaciones se basan en suposiciones y limitaciones. Una hipótesis
es una declaración que se toma para ser verdad, sin verificar, o estar en
condiciones de verificar la veracidad de la declaración. En el ejemplo anterior se
asume que el factor de productividad utiliza en su organización (500 DSLOC /
SM) y los niveles de defectos estimados (10 / KDSLOC y 1 / KDSLOC) son
apropiadas para su proyecto. La estimación se ajustó al alza en un 20% porque se
suponía que el aumento de la complejidad del producto requeriría más esfuerzo
que los proyectos típicos pasados; la estimación podría ajustarse a la baja en base
a la suposición de que va a tener un equipo de desarrolladores de software
altamente cualificados que serán más de compensar el aumento de la complejidad
del producto. Supuestos que luego resultan ser falsa invalidará las estimaciones
basadas en dichos supuestos.
Una restricción es una condición impuesta externamente que debe ser
observada. En el ejemplo anterior, el programa podría ser limitado a 6 meses.
Completando 120 persona-meses de esfuerzo en 6 meses requeriría una plantilla
media de más de 20 desarrolladores de software (120/6 = 20); más de 20 años
debido a la intensificación de la comunicación y la coordinación necesaria para
20 FTEs20 en comparación con 10 ETC en un horario de 12 meses disminuirá la
productividad individual de cada desarrollador de software. También el horario
comprimido es probable que aumente el número de defectos pre-liberación y
post-liberación.
Además puede que no sea posible comprimir un calendario de 12 meses a 6
meses debido a que algunos productos de trabajo tienen que ser completado antes
de otro trabajo puede comenzar; No se puede desarrollar el software hasta que los
requisitos son (al menos parcialmente) conocido. No se puede integrar o probar el
código hasta que se escribe. Las limitaciones de factores tales como la
disponibilidad de personal cualificado de software o entrega de hardware o
software necesario también puede evitar la compresión de la programación. Los
datos históricos pueden indicar que hay un proyecto en su organización ha tenido
éxito después de comprimir un horario pre-planificado en un 50% (es decir, a
partir de 12 meses a 6 meses).
20
FTE es un acrónimo para el personal a tiempo completo. Si se requieren 20 ETC para un proyecto, y
www.it-ebooks.info
si cada persona está disponible para trabajar en su proyecto el 50% de su tiempo, tendrá muchos más
de 40 desarrolladores.
www.it-ebooks.info
Estas observaciones se presentan como el segundo principio fundamental de la

estimación de proyectos de software:
Estimación Principio 2 Todas las estimaciones se basan en un conjunto de

supuestos que deben ser realizados y un conjunto de restricciones que debe ser
satisfecha.
Dicho de otra manera, la estimación no será válida si no para satisfacer las

suposiciones hechas en la preparación de la estimación; el proyecto no podrá
cumplir sus objetivos si se violan las restricciones.
Otra forma de ver las suposiciones y las limitaciones en que se basan las
estimaciones es considerar la asunción y limitaciones como factores de riesgo
para su proyecto. Un factor de riesgo es un problema potencial que, si se
convierte en un verdadero problema, creará dificultades para lograr un resultado
satisfactorio para su proyecto (es decir, deliver- ing un producto aceptable a
tiempo y dentro del presupuesto). Por ejemplo, basar una estimación en el
supuesto de desarrolladores altamente cualificados crea un factor de riesgo que
invalida la estimación si los desarrolladores de software no están altamente
cualificados. El intento de completar el proyecto dentro de las limitaciones de 6
meses con más de 20 personas puede crear problemas de comunicación y
coordinación que evite la finalización del proyecto en la fecha prevista y / o
puede dar lugar a un producto no satisfactorio.
Estimación Principio 3 Los proyectos deben ser re-estima periódicamente como

ING comprensión crece y no periódica como cambiar los parámetros del proyecto.
Este principio es un corolario de principio 2. A medida que el proyecto

evoluciona, el ing comprensión del producto en fase de desarrollo, las
suposiciones que se han hecho, y el impacto de las restricciones quedará claro
(más claro). Por ejemplo, el producto puede ser más o menos complejo que usted
asumió; los desarrolladores pueden ser más o menos cualificados y más o menos
motivados que asumiste; la restricción de horario puede ser más o menos grave
de lo que se supone. Una mejor comprensión del producto, la validez (o
invalidez) de sus supuestos, y el impacto de las restricciones de productos y
procesos normalmente dará lugar a la reestimación y el perfeccionamiento de los
planes, como se ilustra en la Figura 6.2.
Por regla general, la reestimación y debe ocurrir sobre una base mensual para
proyectos de menos de 12 meses de duración replanificación, y mensualmente,
trimestralmente o tal vez para el proyecto de una duración superior a 12 meses.
El intervalo de tiempo es determinado por la estabilidad de los requisitos, los
recursos, la tecnología y el proceso de desarrollo.
Los proyectos deben ser re-estima de manera no periódica cuando ocurren
cambios imprevistos en los parámetros del proyecto, tales como:
• un cambio importante de las necesidades,

• fracaso de una nueva tecnología,
• la compresión de la programación,
• reducción del presupuesto previsto, o
• pérdida de personal clave.
www.it-ebooks.info
Mayor replanificación puede ser necesario, dependiendo de la magnitud del

cambio pated unantici-.
Como se dijo anteriormente en este texto, formas aceptables para acomodar
los cambios en los parámetros del proyecto incluyen:
• modificar el ámbito de los requisitos,

• extender el horario,
• la adición de más recursos, y
• utilizando mejor los recursos.
formas inaceptables incluyen:
• exceso de horas extraordinarias,

• reducción de las actividades de verificación y validación previstas, y
• reducción de la documentación prevista.
Si usted está comprometido con un contrato de precios y el calendario fijo con

los requisitos rígidos (siempre una mala idea), debe tener suficiente reserva en el
precio acordado y el horario para dar cabida a cambios a medida que crece la
comprensión (proyectos siempre se hacen más grandes y más complejo que
supone). La reserva puede variar de 10% a 50% del costo estimado, dependiendo
de su confianza en su estimación original. El contrato también debe contener una
cláusula que indica que el contrato será re-negociado ated si hay un
acontecimiento imprevisto, como un cambio importante en los factores
controlados por el cliente; como por ejemplo, cambios en los requisitos, horario,
o la financiación, a saber, los cambios fuera de alcance.
6.4 DISEÑO DEL PROYECTO DE LIMITACIONES
El proceso de estimación se ilustra en la Figura 6.1 es aplicable cuando los

atributos del producto tales como el tamaño y la complejidad se utilizan para
estimar los atributos de proyecto, como el esfuerzo y la duración. En este caso,
los atributos de los productos están en las restricciones de productos hechos. En
algunos casos esfuerzo y / o horario y / o atributos de calidad se especifican como
las limitaciones del proyecto y se utiliza para estimar los atributos de un producto
que puede ser desarrollado o modificado dentro de esos límites. Este enfoque se
denomina “diseñar a limitaciones del proyecto;” se ilustra en la Figura 6.3 (en la
ingeniería de sistemas de este enfoque es conocido como “diseñar a costar”).
Supongamos, por ejemplo, que un proyecto debe ser completado en 6 meses
por 5 desarrolladores de software (30 personas-meses de esfuerzo). Utilizando las
reglas de pulgar desde arriba, se estima que los constreñidos 30 meses-personal
de esfuerzo se traducirá en 15.000 DSLOC (30 500), y que el número de
defectos serán 150 pre-liberación y 15 post-liberación.
Esta estimación diseño-a-limitaciones se basa un factor de productividad que
se supone que es típico de la organización (500 DSLOC / SM). Si el producto
futuro se estima que 20.000 DLOC, el equipo del proyecto de 5 miembros tendrá
que ser un 33% más productivo que el equipo de proyecto típico en el pasado
(20.000 / 15.000) si han de completar el proyecto en 6 meses.
www.it-ebooks.info
6.4 DISEÑO DEL PROYECTO DE LIMITACIONES 215
Experie
ncias supuestos
anteriores
Atributos del producto

Procedimi Las limitaciones
ento de del proyecto
estimació - esfuerzo
n - programar
Ajuste - defectos
factores - confiabilidad
...
FIGURA 6.3 Diseño de las limitaciones
del proyecto
La viabilidad del proyecto depende de la especificación de uno o más realistas

factores Ment ajustes que pueden aumentar la productividad en un 33%; por
ejemplo, el proyecto podría ser factible si se puede utilizar 5 de los mejores
desarrolladores de software en su organiza- ción. Si no se puede asumir que
algunos factores de ajuste realistas serán verdaderas, con un alto nivel de
confianza, hay una correspondientemente alto riesgo de fracaso del proyecto (es
decir, la incapacidad para ofrecer un producto aceptable a tiempo y dentro del
presupuesto). Si el tamaño del producto se estima en 30.000 DLOC, el equipo del
proyecto tendrá que ser doble de productivo que el equipo típico. Esto es poco
probable en cualquier escenario, e indica que el proyecto, tal como limitada, es
inviable.
Usted debe tener cuidado de que las restricciones del proyecto no hacen que
sea imposible encontrar valores factibles para los factores estimados. Hay un
viejo dicho que dice: “Se puede tener el software pronto, bueno, barato; Escoja
dos opciones “Si usted quiere que su software de pronto y bien que no será barato
(es decir, será caro).; si quieres que bueno y barato, no será pronto (es decir, la
duración horario no será corto); si desea que su software de pronto y barato, no
va a ser bueno (es decir, la calidad se verá afectada).
La situación se ilustra en las figuras 6.4a y 6.4b como tres etros fundamentales
tros de estimación-horario, recursos, y los requisitos-que deben equilibrarse.
Como se ha indicado, puede haber cierta flexibilidad en una o más de las
dimensiones: puede (o no puede) ser alguna reserva de contingencia en el horario
(es decir, la diferencia entre el cronograma estimado y el calendario
comprometido). Es probable que haya un límite superior en los recursos que se
pueden aplicar al proyecto. Puede haber un mínimo, en el sentido de que el
proyecto no es viable a menos que el mínimo de recursos están disponibles, y,
habrá un número mínimo de características y atributos de calidad que deben ser
entregados (es decir, los requisitos esenciales). El rectángulo de la solución en las
figuras 6.4a y 6.
El objetivo fundamental de la estimación es desarrollar y mantener las
estimaciones que mantienen sus proyectos “en la caja de solución”, tanto al inicio
como al cambiar las condiciones. Mantener su proyecto en el cuadro significa
que va a entregar un producto aceptable que satisfaga todos los requisitos
esenciales (y algunos de los más deseables y opcionales) dentro de las
limitaciones de un calendario aceptable y los recursos disponibles. Terminar su
proyecto en cualquier punto dentro de la caja de solución limitada indica que
usted entregó un producto aceptable a tiempo y dentro del presupuesto (el
presupuesto se utiliza para obtener los recursos).
Si no hay flexibilidad en los requisitos, la caja en la figura 6.4b se convierte en
www.it-ebooks.info
el plano frontal de la caja; si además no hay flexibilidad en la programación, el
avión
www.it-ebooks.info
recursos
Máximo
mínimo
Estimar
Horario compromiso
Opcional cuadro de
esencial solución
restringida
requisitos
6,4 A FIGURA Tres variables fundamentales de la estimación y la caja solución
resultante
constreñido
recursos constreñido
requisitos
constreñido
programar
FIGURA 6.4b El cuadro de solución constreñido en la figura 6.4a
se convierte en una línea vertical que indica una cierta flexibilidad en los
recursos. Si no hay flexibilidad en cualquiera de los tres parámetros, la caja se
colapsa para un solo punto.
Un proyecto excesivamente restringida es aquella para la que no existe una
solución viable en la caja o el plano o en el punto individual. Esta situación se
produce cuando el programa de con- tensa es menor que la estimación del tiempo
necesario, y / o los recursos son menos de la cantidad mínima requerida y
amable, y / o el número de los requisitos que se pueden implementar dentro de
las limitaciones de horario y recursos es inferior a los de la categoría esencial.
Rígidamente de constricción 1 o 2 de los 3 funda- las variables mentales requiere
flexibilidad en el otro 1 o 2 con el fin de establecer puntos de solución factible.
Rígidamente restringir las 3 variables suele ser una receta para el fracaso.
Las estimaciones son a veces “el mandato”. Estas “estimaciones” son el
resultado de productos y proyectos factores excesivamente limitados que no
tienen flexibilidad en los parámetros de estimación (es decir, su equipo de 5
desarrolladores deben desarrollar 60.000 líneas de código de alta calidad en 6
meses; que debe ser bueno, barato, y pronto). Esto no es una estimación; es un
desastre a punto de ocurrir, para usted, su proyecto, su organización y su cliente.
6.5 ESTIMACIÓN DE TAMAÑO DEL PRODUCTO
Como se indica en la Figura 6.1, las estimaciones de factores como el esfuerzo,

planificación, los recursos, el costo y los atributos de calidad se basan en
atributos del producto, se estima con- straints de proyectos, experiencias pasadas,
y los factores de ajuste. Por otra parte, la figura 6.3 indica que las restricciones
del proyecto pueden dictar los atributos de un producto que puede ser construido
o modificado dentro de esos límites.
La mayoría de los modelos de estimación, herramientas y técnicas utilizan
alguna medida de tamaño que el atributo fundamental producto en el que se basa
la estimación, o en el caso de
www.it-ebooks.info
6.5 ESTIMACIÓN DE TAMAÑO DEL
PRODUCTO 217
el diseño de las restricciones (Figura 6.3) del proyecto, el tamaño es el atributo de

producto que se estima. Dependiendo de la naturaleza del producto, factores
adicionales a medida, tales como la complejidad del producto, grado de
conectividad, respuestas en tiempo real necesarios, o la cantidad de datos a ser
manipulados, pueden influir en las estimaciones de esfuerzo, planificación, los
recursos, los factores de calidad , y el costo; factores de productos adicionales
tales como éstos se incluyen como factores de ajuste en la mayoría de los
modelos de estimación.
La mayoría de los métodos de estimación basados en factores de productos
utilizan una cierta medida del tamaño del producto como el factor principal que
impulsa la estimación debido a que:
1. tamaño tiene una relación causal más fuerte a atributos como el esfuerzo y
el horario que lo hacen otros atributos de producto del proyecto;
2. tamaño se puede medir de manera más objetiva que otros atributos del
producto;
3. algunas medidas de tamaño se estima con mayor precisión a partir de los
requisitos de lo que puede otros atributos del producto; y
4. los datos para el tamaño, el esfuerzo, el horario, y otros atributos del
proyecto se pueden recoger de proyectos terminados y se almacenan en una
base de datos para proporcionar una base histórica de la estimación para
proyectos futuros.
Históricamente, las líneas de código entregadas de código (DSLOC) se ha

utilizado como la medida de tamaño pero hay varios problemas relacionados con
el uso de líneas de código:
• es difícil estimar líneas de código al principio de un proyecto; es difícil

relacionar los cambios en los requisitos a los cambios en las líneas de código
estimada;
• el cálculo de la productividad como líneas de código generado por el
programador meses puede animar a los programadores a escribir un montón
de líneas de baja calidad de código en lugar de un menor número de líneas
de código de alta calidad; y
• métodos modernos de desarrollo tales como el desarrollo dirigido por
modelos, a objetos de programación basado, la reutilización de los
componentes de la biblioteca, y el uso de componentes de código abierto
hacen que la relación entre líneas de código y el proyecto atribuye menos
relevante y menos precisa que en el pasado.
Se han desarrollado medidas de tamaño distinto de líneas de código para

superar los problemas de la utilización de líneas de código. La medida de tamaño
de punto función es el más conocido y históricamente fue la primera alternativa a
líneas de código [Albrecht79]. Los puntos de función (PM) se calculan contando
el número de diferentes tipos de entradas, salidas, archivos internos, consultas e
interfaces en un sistema que deben estimarse.
Estos recuentos se basan en reglas objetivas de conteo, y cada entrada única,
salida de archivos interno, consulta, y la interfaz se pondera tan simple, media o
compleja. El modelo de punto de función se ilustra en la Figura 6.5.
Los valores ponderados se suman para proporcionar un número total de puntos
www.it-ebooks.info
ción fun- sin ajustar (UFP). Los factores de ajuste tales como la complejidad de
procesamiento, velocidad de acción trans, y la facilidad de uso requerido A
continuación se aplican para dar cuenta de las condiciones que se requieren
esfuerzos más o menos que el proyecto típico. Otros detalles y un ejemplo de una
estimación puntual función se proporcionan en la barra lateral adjunta. Como se
indica en la barra lateral, análisis de punto de función ha sido generalizada para
convertirse en la medida del tamaño funcional.
www.it-ebooks.info
SISTEM
yo A
O
norte archivos u
pag
t
u
pag
t
u
s
t
s
INterfaces
consult
as
otro
sistema
s
#FPs = (I, O, F, Q, IN)

FIGURA 6.5 factores de punto de función a ser contados
Un aspecto interesante de la medida de tamaño de punto de función es que las

líneas de código necesario para implementar un número determinado de puntos
de función depende del lenguaje de programa- ming utilizado para implementar
el software necesario para procesar las entradas y utilizar los archivos, interfaces
y consultas para producir las salidas. Podría ser, por una organización
determinada y una especie y tamaño del producto en particular, que el factor de
conversión de puntos de función de líneas entregadas de código es 50 DSLOC /
FP para programas escritos en Java y 300 DSLOC / FP para programas similares
escritos en asamblea idioma. Esto indicaría que Java es 6 veces más expresivo
que el montaje de calibre guaje de este tipo y el tamaño del producto dentro de
esta organización. Si se supone que el esfuerzo requerido para escribir, por
ejemplo,
El calificador en el párrafo anterior “para una organización determinada y una
especie y tamaño del producto en particular” es importante porque la proporción
de líneas de código para funcionar puntos es diferente para diferentes tipos de
software, para diferentes tamaños de software, y por diferentes organizaciones .
Aunque se han publicado directrices para convertir los puntos de función de
líneas de código para varios lenguajes de programación, el factor (s) de
conversión debe ser derivado a nivel local. Dentro de su organización que pueda
tener diferentes factores de conversión para diferentes tipos y tamaños de los
productos de software, y los factores de conversión podría no ser válido en otras
partes de su empresa.
Los factores de conversión entre los puntos de función y líneas de código son
útiles para:
1. utilizar los puntos de función como entradas a la estimación de las

herramientas que están calibrados a las líneas de código y
www.it-ebooks.info
PRODUCTO 219
Medida del tamaño FUNCIONAL
La medida de tamaño de punto función era la primera medida de tamaño

funcional (FSM); que fue desarrollado por Alan Albrecht a mediados de la
década de 1970 para medir el “tamaño externa” de aplicaciones de
procesamiento de datos [Albrecht79]. Llamó al enfoque de “análisis de punto
de función” (FPA).
La función Internacionales Point Grupo de Usuarios (IFPUG, una organiza-
ción sin fines de lucro) es ahora el encargado oficial de FPA. IFPUG mantiene
la función de punto Prácticas conteo manual, lleva a cabo conferencias
anuales, y patrocina seminarios educativos y talleres [IFPUG]. IFPUG
también ofrece un programa de certifi- cación profesional para especialistas
punto de función certificados.
TABLA 6.1 Un ejemplo punto de función

Complejidad: SimpleAverageComplexTotal Entradas
3 3 2 4 0
617
salidas 4  46 5 3  767
archivos 57 2  10 0  1555
consultas 03 95 4  773
Interfaces 05 07 3  1030
Total 242
Tabla 6.1 ilustra la aproximación al punto de función para medi- ción

tamaño funcional. El ejemplo de la tabla muestra el número de puntos de
función para entradas, salidas, archivos, consultas, e interfaces (en negrita) y
los factores de ponderación para las ponderaciones simples, promedio y
complejas en cada caso. Tenga en cuenta que los factores de ponderación para
los archivos y las interfaces son más grandes que los pesos de las entradas,
salidas y consultas. Esto indica que se requiere un mayor esfuerzo para
desarrollar la funcionalidad de los archivos y las interfaces que para los otros
tres factores.
Como se indica en la Tabla 6.1, el número de puntos de función sin ajustar
(UFP) para el ejemplo es 242. Si el factor de ajuste de material compuesto es
1,13, el número de puntos de función ajustados es de aproximadamente 276
(1,13 242). Si los datos del historial de proyectos anteriores indica la
productividad de 6,5 puntos de función por el personal de meses (6,5 FP / SM)
la estimación de esfuerzo es de aproximadamente 42 meses-personal (que se
podría estimar como 6 personas por 7 meses).
Se han desarrollado varias otras medidas de tamaño funcionales. El método
de punto de función cuenta factores externos que son importantes en aplica-
ción de datos intensivos; el método de puntos de función añade un recuento de
algoritmos para sistemas de cálculo intensivo [Jones86]. puntos de función
MK II mejora en el recuento de archivos de puntos función para mejorar la
atención a los detalles internos de aplicaciones ricas en datos [Symons88].
En 1998, cósmico (el consorcio Software Common Measurement
Internacional Con-) estaba formado por un grupo de trabajo de la nización
Normas Internacional Orga- (ISO) para el propósito de desarrollar y normas
de publicación de la ISO para la medición de tamaño funcional, que es una
www.it-ebooks.info
generalización de la función análisis de punto. De acuerdo con el sitio de red
cósmica [COSMIC1]:
www.it-ebooks.info
COSMIC-FFP (ISO 19761) es un método de medición de tamaño funcional que

gene- alizes el proceso de medida para hacer frente a los problemas de sistemas
de información de gestión, así como los proyectos en tiempo real y software
híbrido. Se ajusta a la norma ISO meta- sobre la medición de tamaño funcional
(ISO 12143-1) y utiliza sólo pieles (Requisitos del usuario funcional) del
proyecto de software como entradas al proceso de mediciones.
Las ventajas de COSMIC-FFP, en comparación con los puntos de función son

documentado en [COSMIC2].
2. para convertir los datos históricos para proyectos basados en líneas de

código a los datos históricos sobre la base de los puntos de función.
Tabla 6.2 enumera varios ejemplos de medidas de tamaño en el espíritu de la

FPA. Estas medidas se denominan medidas de tamaño externo (ESM). El término
genérico para las unidades de medida es unidades de tamaño externos (ESUs).
Los puntos de función son, pues, un ESM, y el número de puntos de función en
un sistema de software o producto son ESUs. Este gía terminología se utiliza
porque ESM medida factores externos al software a ser desarrollado o
modificado, incluyendo:
1. insumos que se debe responder,

2. salidas que deben ser entregados, y
3. las interfaces pasivas.
Tabla 6.2 Ejemplos de medidas de tamaño externos

Tipo de Factores SystemESM contados
Datos processingInputs, salidas, interfaces, las consultas,
los archivos de proceso controlSensors, válvulas,
actuadores
Incrustado systemsInterrupts, señales, niveles de
prioridad del usuario interfacesWindows, menús,
elementos por menú -Objeto,
orientedClasses asociaciones, métodos
Estos tres factores determinan el “tamaño externa” del software que, junto con
factores de conversión y factores de ajuste, se puede utilizar para estimar los
factores tales como la cantidad de esfuerzo requerido, el tiempo necesario, las
densidades de defectos pre-liberación y post-liberación, y fiabilidad. Por ejemplo,
si la regla de oro de la productividad, determinado a partir de proyectos
anteriores, es de 7 puntos de función por el personal de meses (7 FP / SM), el
proyecto se muestra en la Tabla 6.1 se requieren aproximadamente 35 meses-
personal de esfuerzo (242/7) .
Sobre la base de estas consideraciones, la siguiente conjetura de medidas de
tamaño externos se ofrece:
El ESM conjetura:
Siempre es posible encontrar una Tamaño de la medida externa que se puede utilizar,
junto con los factores de ajuste de datos históricos y, para desarrollar estimaciones de
atributos de proyectos de interés.
www.it-ebooks.info
PRODUCTO 221
Una conjetura es una afirmación que se cree que es cierto, pero no puede ser
(de manera exhaustiva) ha demostrado ser cierto. Una conjetura que incluye el
calificador “siempre” puede ser refutada por un solo contraejemplo; Sin embargo,
este autor no ha encontrado que contraejemplo.
Que la conjetura ESM debe ser verdad se basa en la observación de que el
propósito del software es para procesar entradas, interactuar con otros sistemas, y
producir salidas. Por consiguiente, el software a ser desarrollado es directamente
proporcional a los números y tipos de entradas, salidas e interfaces para ser
manejado por el software, que se mide por el ESM. La situación se ilustra en la
Figura 6.6.
AMBIENTE
SISTEMA
yo O
norte u
pag t
u pag
t u
s t
s
Interfaces
Figura 6.6 Elementos de medidas de tamaño externos
Por ejemplo, suponga que ha desarrollado un ESM para la construcción de

software integrado que utiliza los siguientes parámetros:
entradas
número de interrupciones, me
número de niveles de prioridad, P
Interfaces
número de entradas de la tabla de control, E
salidas
número de señales, S
También suponga que ha desarrollado la siguiente relación de datos históricos:
ESUs 2 I 4 P E 5 S.
Los factores de ponderación indican el esfuerzo relativo requerido para

implementar el código para procesar una interrupción, manejar los niveles de
prioridad, las tablas de control de acceso, y generar
www.it-ebooks.info
señales de salida. Un sistema que tiene 5 interrupciones diferentes en 3 niveles de

prioridad, interfaces de mesa 15 de control, y 15 señales diferentes tendría 112
ESUs.
Supongamos, además, que ha examinado los proyectos anteriores y desarrolló
el índice de productividad de 2 UDE por personal de tres meses (2 UDE / SM).
Entonces esfuerzo estimado para el desarrollo de software sería
Esfuerzo 112 56 meses-

personal.
2
El proyecto puede ser programado usando 6 desarrolladores de software durante

10 meses.
Si usted está preocupado por las restricciones de memoria (es decir, el número
de bytes de objeto para ser cargados en la memoria), es posible analizar los
productos anteriores para desarrollar una nave PARENTESCO de la forma:
Bytes x ESU,
donde x es el factor de conversión Bytes / ESU. Otros factores de interés podrían

ser explicadas de una manera similar.
Los pasos necesarios para desarrollar un ESM se muestran en la barra
lateral del acompañante.
Las diversas técnicas para estimar atributos de interés para proyectos de
software (por ejemplo, el esfuerzo, horarios, recursos, factores de calidad y coste)
puede ser categorizado como basados en la teoría pragmática, y basada en
regresión. técnicas de estimación pragmáticos incluyen:
• regla de oro
• analogía
• juicio experto
• Delphi
• EDT / CPM / PERT
técnicas de estimación basados en la teoría

incluyen:
• sistemas dinámicos
• DELGADO
modelos de estimación basada en regresión

incluyen:
• COCOMO
• modelos derivados localmente
y los modelos de regresión utilizan tamaño que la entrada de estimación

primario basado en la teoría; técnicas pragmáticos pueden o no pueden utilizar
una medida de tamaño. La naturaleza de estos métodos y ejemplos de sus usos se
presenta en las siguientes secciones.
www.it-ebooks.info
PRODUCTO 223
DESARROLLO DE UN medida de tamaño EXTERNO
medidas de tamaño externos para sistemas o productos similares pueden

desarrollarse de la siguiente manera:
1. Analizar algunos sistemas o productos existentes similares a los sistemas

o productos que se desarrollarán:
a. identificar algunos ESUs candidatos para ser contado en los entornos
de los sistemas o productos y
b. desarrollar reglas de conteo para la UES.
2. Calibrar el ESM de la siguiente manera:
c. contar ESUs para algunos sistemas existentes;
d. desarrollar factores de ponderación para los ESUs;
e. aplicar los factores de ponderación para producir ESUs ajustado (AESUs);
f. desarrollar factores de conversión de unidades de tamaño externos a
factores que deben ser acopladas estimación, tales como esfuerzo,
coste, líneas de código, y la densidad de defectos;
g. aplicar los factores de conversión para calcular factores que deben ser
estimados;
h. comparar las estimaciones a los valores reales para el pasado del proyecto; y
i. ajustar los factores de ponderación para la UES y desarrollar factores
de ajuste para tener en cuenta las variaciones en los factores estimados
para los sistemas históricos tienen ESUs similares.
3. Iterar los pasos 1 y 2 hasta que su modelo de estimación ESM satisface
los criterios siguientes:
a. los ESUs son contables a los requisitos y fases de diseño al principio
de sus proyectos,
b. la ESUs caracterizan el software a implementar, y
c. factores de conversión se pueden derivar para convertir ESUs ajustado
a factores que ser estimado.
3c Criterio debe apoyar estimación de factores tales como
LOC estimado ⎛ AESUs LOC⎞,

ESU ⎠ 
AESUs esfuerzo estimado ⎛ ⎞ Esfuerzo,

ESU ⎠
costo estimado AESUs ⎛ ⎞ Costo,

ESU⎠ 
defectos estimados AESUs

,
ESU ⎠
www.it-ebooks.info
dónde
LOC es líneas de código;

LOC / ESU, Esfuerzo / ESU, costo / EST, y Defectos / ESU se obtienen a
partir de los datos his- tórica de proyectos anteriores; y
AESUs se ajustan ESUs, para el proyecto se estima, ajustada por los factores
de ajuste para el proyecto.
6.6 Las técnicas de estimación PRAGMÁTICOS
técnicas de estimación pragmáticos no se basan en modelos teóricos ni en el

análisis de regresión. Ellos han demostrado ser útiles en la práctica a pesar de
tener ninguna base teórica o regresión subyacente. Varias técnicas pragmáticos
están pre-tantes en esta sección.
6.6.1 Regla de oro

Una regla de oro (ROT) es un guideline.21 generalmente aceptada Debido a la
ingeniería de software, a diferencia de otras disciplinas de ingeniería, no se ocupa
de las relaciones físicas entida-, carecemos de muchos de los modelos
matemáticos en los que se basa la ingeniería tradicional. Por lo tanto utilizamos
muchas reglas de pulgar, algunos que son toda la industria (por ejemplo, en
general, cuesta 50 a 100 veces más para arreglar un defecto posterior a la
liberación de para arreglar un defecto pre-release) y algunos que se derivan
localmente (por ejemplo, en nuestra organización que cuesta 75 veces más que
para arreglar un posterior a la liberación defecto del producto interfaz de fijarlo
pre-lanzamiento).
El factor de productividad utilizado en el ejemplo de la Sección 6.3 (500
DSLOC / SM) podría ser una regla en toda la industria del pulgar para un tipo
particular de software (por ejemplo, aplicaciones cien- Entific, procesamiento de
datos, o de telecomunicaciones) o podría ser una regla local de oro para su
organización y su tipo de software.
Cuando se utiliza métricas como DSLOC 500 / SM o 5 FP / SM, es necesario
comprender los factores incluidos en las métricas. métricas de la productividad,
por ejemplo, se determinan mediante el recuento de líneas de código en los
productos anteriores (o alguna otra medida de tamaño), la determinación de los
meses-personal necesarios para producir esas líneas y formando la relación (por
ejemplo, 500 DSLOC / SM). Es necesario entender cómo se contó tamaño y se
incluyó alcance de lo posible por utilizar la métrica de la productividad. contados
líneas de código pueden haber incluido:
• líneas de código de montaje en el módulo de carga del programa;

• código fuente sin comentarios;
• código fuente con comentarios;
• líneas de código, incluyendo comentarios y rutinas de biblioteca;
• todo el código que se ha escrito (retenidas más descarta);
• todo reutilizado, de código abierto, y el nuevo código en el producto final; o
• todo lo anterior además de todas las normas de prueba-arnés.
21
Una regla de oro es un método o procedimiento que viene de la práctica o experiencia, sin ninguna
base formal.
www.it-ebooks.info
6.6 técnicas de estimación PRAGMÁTICAS 225
El esfuerzo podría haber sido para la codificación única, para la codificación y

prueba, o para todas las actividades de desarrollo de software, además de la
gestión de proyectos, la instalación del sistema, y la formación de usuarios. Se
podría haber incluido toda vez que los desarrolladores de software, incluyendo el
tiempo que pasaron en las reuniones no relacionadas y el mantenimiento de otro
software. Podría haber sido registrado como 40 horas por semana, cuando en
realidad los desarrolladores estaban trabajando 60 horas por semana.
Los proyectos en los que se basa la regla de oro podrían haber sido las
aplicaciones de datos-Processing, sistemas embebidos en tiempo real, o tal vez
las aplicaciones de comercio electrónico basados en web. Estos proyectos
podrían haber exhibido métricas similares para que un promedio de los valores de
ellas es una buena métrica para usar o que puede haber variado ampliamente, con
lo que el valor promedio de una regla del pulgar poco fiable.
Cuando se aplica una regla de oro de la productividad (o cualquier otra ROT)
para hacer una estimación, se está estimando el mismo ámbito de trabajo, para el
mismo tipo de proyectos, que se incluyó en la derivación de la putrefacción. Si,
por ejemplo, un ROT productividad de 500 DLOC / SM se basa en (El) esfuerzo
de escribir las líneas incrustadas de código ensamblador y los desarrolladores
estaban trabajando 60 horas por semana, su estimación será por la cantidad de
esfuerzo necesario para escribir el número estimado de las líneas de montaje
incorporado cuando los desarrolladores están trabajando 60 horas por semana.
Una regla de oro para la productividad de desarrollo de sistemas embebidos de
tiempo real utilizando el lenguaje C no es probablemente aplicable al desarrollo
de aplicaciones de negocio utilizando COBOL.
Si, por el contrario, los puntos de función contados al derivar el ROT se
cuentan utilizando reglas de conteo objetivos y el esfuerzo incluye horas reales
trabajadas en todo el proyecto (análisis, diseño, programación, pruebas, CM,
control de calidad, management), su estimación será para todo el esfuerzo
necesario para desarrollar y entregar software que contiene el número estimado
de puntos de función.
Otra precaución: se debe determinar que el ROT es para el mismo rango de
tamaño del producto como su tamaño estimado. Incluso para tipos similares de
productos y sistemas, el factor de conversión utilizado para relacionar el tamaño
de esfuerzo es por lo general no lineal. Por lo tanto una estimación del esfuerzo
basado en un ROT productividad para los productos que contienen 500 puntos de
función podría tener que ser aumentado por un factor de 1,5 o más para los
productos de 1000 puntos de función (más sobre esto más adelante).
También hay que entender las variaciones en las experiencias pasadas
utilizados para determinar la regla de oro. Si, por ejemplo, su ROT se basa en 5
proyectos anteriores, cuyo tamaño y esfuerzo, al contabilizarse de la misma
manera, producir un ROT promedio de 5 FP / SM pero se pudra la productividad
para los 5 últimos proyectos van desde 3,5 FP / SM 7 FP / SM, usted debe
entender los factores que dieron lugar a estas variaciones (es decir, los factores
Ment ajustes) y el uso de esos proyectos que son más similares a su proyecto.
A pesar de estas advertencias, las estimaciones basadas en reglas generales son
útiles para:
• proporcionar un orden aproximado de estimaciones de magnitud, y

• que pueden ser utilizados al hacer estudios de viabilidad y “qué pasaría si” los
escenarios.
Sin embargo,
www.it-ebooks.info
• se trata de una tarea arriesgada basar una estimación del proyecto de reglas de
oro solo.
www.it-ebooks.info
6.6.2 Analogía
La analogía es una técnica ampliamente utilizada para la estimación de los
atributos del proyecto de ingeniería de software y otras disciplinas de ingeniería.
El objetivo de la estimación basada en la analogía es encontrar uno o más
análogos proyectos para los que se conocen los atributos de interés. Cuanto más
cerca de la analogía, más seguro estará en su estimación. Una regla de oro, por
ejemplo, se puede utilizar con mayor confianza si se basa en proyectos que son
análogas a la que usted está estimando.
estimaciones basadas en analogías pueden ser simples (por ejemplo, un
proyecto similar requiere 5 personas de 6 meses) o sofisticado. En este último
caso, su organización puede tener una base de datos relacional de proyectos
anteriores. Cada fila en el esquema de datos podría contener datos para un
proyecto terminado. Cada columna registraría un atributo de los proyectos
anteriores, tales como:
• el cliente,
• el tipo de producto,
• el alcance de las actividades incluido,
• tamaño del producto y la medida de tamaño utilizado,
• factores de ajuste utilizados (por ejemplo, la complejidad del producto, el
nivel de habilidad de los desarrolladores),
• el modelo de desarrollo utilizado,
• herramientas de desarrollo utilizadas,
• productos entregables producidos,
• duración del proyecto estimado y real,
• estimado y el esfuerzo real,
• el costo estimado y real,
• pre-liberación y densidades de defectos post-liberación,
• los problemas encontrados, y
• lecciones aprendidas.
Para hacer una estimación, se especificaría las características conocidas del

proyecto en el que está estimando. A continuación, escribir una consulta que
recupera una lista de proyectos que responden a su proyecto dentro de un rango
especificado, por ejemplo, todos los proyectos que desa- productos llados de alta
complejidad y que están dentro de 10% de su tamaño estimado construido por
los desarrolladores de la media los niveles de habilidad utilizando C ++ y un
modelo de incremental-build.
La fuerza principal de la estimación basada en la analogía
es que:
• buenas analogías constituían una buena base de la estimación para su

proyecto.
La principal debilidad es que:
• falsas analogías producen estimaciones inexactas.
www.it-ebooks.info
La estimación es ni mejor ni peor que las analogías en los que se basa.
www.it-ebooks.info
6.6.3 Juicio experto

El juicio de expertos consiste en pedir a uno o más expertos por sus estimaciones
del proyecto de atributos tales como el esfuerzo, el tiempo, los niveles de
competencia requeridos, y los factores de riesgo. Refiriéndose a la figura 6.1 de
retención de datos está en las cabezas de uno o más expertos. Los factores de
ajuste que se aplican pueden incluir factores subjetivos tales como saber las
personas que van a hacer el trabajo y gestionar el trabajo, la política de relaciones
con los clientes, y fric- ciones, que pueden existir entre los elementos internos de
la organización. Los atributos del producto incluyen toda la información
disponible para que los expertos examinan.
Los expertos le puede decir que los requisitos son demasiado vagos e
incompletos para que puedan emitir una opinión (que es útil saber). En el otro,
diferentes tipos extremos de los expertos puede ser capaz de proporcionar
estimaciones para los diferentes elementos de la vista de la arquitectura de
descomposición (ADV) del sistema o producto previsto (por ejemplo, la interfaz
de usuario, la base de datos, el paquete de comunicación, los algoritmos).
Los principales puntos fuertes de la opinión de expertos
que son:
• diferentes tipos de expertos pueden proporcionar estimaciones para

diferentes tipos de componentes de productos y
• expertos pueden incluir factores subjetivos y políticos que no están
normalmente registrados en las bases de datos de proyectos anteriores.
Las principales debilidades son que:
• expertos pueden ser demasiado optimistas al estimar el tiempo y los recursos

necesarios para que puedan hacer el trabajo en lugar del tiempo y los
recursos necesarios por los desarrolladores menos expertos y
• su recuerdo de experiencias pasadas puede ser incorrecta o incompleta.
6.6.4 Estimación Delphi

Se puede utilizar la técnica Delphi para obtener estimaciones compuestas de
diferentes experts.22 se dé a cada experto en la misma información relativa al
producto futuro (por ejemplo, requisitos de funcionamiento, especificaciones
técnicas, vistas arquitectónicas, straints con-). Cada pregunta se hace para
proporcionar una estimación de los atributos del proyecto y una breve tificación
justifica- para su estimación. Cada experto puede aplicar reglas de oro, analogías,
su juicio de expertos, o basado en la teoría y los modelos basados en regresión
como deseen en el desarrollo de sus estimaciones.
Usted, el coordinador, cotejar sus estimaciones, proporciona los resultados
compuestos de nuevo a ellos (sin nombres), además de la información adicional
que podrían haber solicitado, y pedirles que aporten una segunda estimación. la
correspondencia de correo electrónico, el uso de plantillas de cálculo para ser
completado y devuelto, es una manera conveniente para llevar a cabo el proceso
de Delphi. Un ejemplo estimación de segunda ronda de un experto se
proporcionan en la Figura 6.7.
El intervalo entre las estimaciones presentadas debe ser de uno a dos días. Esto
le da a cada experto tiempo suficiente para reflexionar sobre el informe resumido
de la ronda previa,
www.it-ebooks.info
22
La técnica Delphi fue desarrollado en los años 1940 en la Rand Corporation como una herramienta
de pronóstico. Se llama así por el oráculo de Delfos cuyas predicciones se buscaron e invocada por
los antiguos griegos.
www.it-ebooks.info
Proyecto: sistema ATM

Estimación redonda:
2 Estimador: Sue
Smith
Ronda 1 4 estimaciones de los
expertos
4 35
miXpert #
3 53
2 44
130
01020304050
60
Estimación de
personas-mes
Resumen de fundamentos para la ronda 1 de 4 estimadores:

1: No veo ningún problema; debe ser un proyecto de rutina.
2: Los requisitos son vagos en algunas áreas; podría causar
problemas. 3: La nueva interfaz de hardware podría causar algunos
problemas.
4: Nuestra gente tiene mucha experiencia con este tipo de sistemas.
Su estimación ronda 2: 35 meses-
personal de su ronda 2 razón de ser:
No creo que los requisitos vagos será un problema porque nuestra gente
tiene mucha experiencia en desarrollo de este tipo de sistemas y tienen
experiencia trabajando con este cliente. Estoy aumentando mi estimación
de 30 a 35 meses-personal, debido a la nueva interfaz de hardware
mencionado en razón de 3. 6.7 Un informe de Delphi
Figura
pero no tanto tiempo que se olvidan los detalles o pierden interés en el proceso.
El anonimato del método Delphi combina las ventajas de múltiples opiniones de
los expertos, evitando el inconveniente de influencia o persuasión indebida por
parte de uno o más de los expertos.
Las estimaciones pueden o no pueden converger después de 3 o 4 rondas (3
rondas es típico en el proceso de Delphi). Si las estimaciones convergen en un
rango estrecho, una reunión entre los expertos es convocado para confirmar sus
estimaciones y para registrar cualquier preocupación que puedan tener sobre el
proyecto propuesto. Si sus estimaciones no convergen, se realiza una reunión
para que puedan justificar sus estimaciones y para resolver sus diferencias entre
ellos. Si los cálculos no convergen durante la reunión, el rango de estimaciones
se puede utilizar para desarrollar una función de densidad de probabilidad para
las estimaciones.
Un enfoque alternativo se denomina el proceso de Delphi de banda ancha
[Boehm81]. Este enfoque implica convocar una reunión de expertos en el
comienzo para discutir el proyecto, lo que permite tiempo para reflexionar y
presentar estimaciones anónimas, y la celebración
www.it-ebooks.info
reuniones después de cada ronda de la estimación para discutir los supuestos y

razones en que se basan sus estimaciones. Existe el peligro de que algunos
estimadores pueden influir indebidamente a otros en virtud de sus personalidades
o posiciones de autoridad, pero se da cada estimador de tiempo para reflexionar
sobre las discusiones y hacer una investigación adicional antes de presentar su
próxima estimación, que se informó de forma anónima.
Un enfoque más radical es uno en el que el proceso se completa en una sola
reunión. Cada ronda de estimación se lleva a cabo mediante votación secreta, la
discusión de las estimaciones entre las rondas. Esto se puede hacer de manera
eficiente, especialmente si ve facilitada por una herramienta de trabajo en grupo
que permite a cada experto para entrar anónimamente una estimación y una breve
justificación de su teclado. La estimación de cada experto y justificación se
muestra de forma anónima en una pantalla grande para el grupo de observar y
proporciona la base para la discusión entre las rondas de estimación. Este
enfoque es más eficiente que el tradicional o de banda ancha Delphi Delphi, pero
no es recomendable, ya que no permite el tiempo suficiente para que los expertos
reflejan en los resultados de rondas anteriores, quizá a hacer una investigación en
la preparación de su siguiente estimación,
Un proceso Delphi puede o no puede producir un resultado consenso. La
imposibilidad de lograr un consenso puede indicar la necesidad de seguir
trabajando para hacerse con el cliente y su gestión en el perfeccionamiento de los
requisitos, el examen de los straints con- diseño y la evaluación de la viabilidad
del proyecto. Otra manera de utilizar los resultados gent nonconver- es
desarrollar una función de probabilidad de la gama de las estimaciones y
utilizarlo para realizar un análisis de riesgo cuantitativo usando un modelo
probabilístico.
Los principales puntos fuertes de un proceso de
estimación de Delphi son:
• la obtención de las opiniones de los expertos combinados sin la influencia

indebida de expertos en una estimación de los demás y
• múltiples rondas de estimación en la que cada experto reflexiona sobre las
razones presentadas de forma anónima de los demás.
Debilidades del proceso Delphi son:
• el tiempo y el esfuerzo necesarios de los expertos,

• la posibilidad de intransigencia por uno o más expertos, y
• la posibilidad de una influencia indebida en las reuniones de banda ancha
Delphi.
6.6.5 EDT / CPM / PERT

El / CPM enfoque EDT / PERT para la estimación se basa en la idea de la
arquitectura posición descomposición incrustado en la EDT y los paquetes de
trabajo de la EDT. Como se discutió en el capítulo 5, los paquetes de trabajo se
pueden utilizar para proporcionar estimaciones de abajo hacia arriba de los
atributos del proyecto enrollando las estimaciones de nivel inferior para las
actividades y tareas. Las estimaciones de los paquetes de trabajo se pueden basar
en otras técnicas pragmáticas (regla general, la analogía, Delphi, el juicio de
expertos) o en modelos esti- mación basadas en la teoría o basadas en regresión.
www.it-ebooks.info
23
Participé en una de esas reuniones en las que un participante comentó: “¿Quién es el idiota que
presentó esa estimación?” El comentario no era propicio para un resultado colegial.
www.it-ebooks.info
En este sentido el / CPM enfoque WBS / PERT es quizás el más exacto de las
técnicas pragmáticos debido a la mayor nivel de detalle con el que se pueden
aplicar diversas técnicas de estimación y porque las variaciones positivas y
negativas en inexactitudes en los niveles inferiores puede “promedio out” cuando
se agregan a niveles más altos. El enfoque PERT se puede utilizar para
proporcionar distribuciones de probabilidad para las duraciones ULE sched- para
alcanzar diversos hitos y para completar el proyecto.
Puede que no tenga suficiente detalle como para desarrollar un ADV, una
EDT, paquetes de trabajo, y una red del cronograma-ruta crítica al principio de su
proyecto, pero el desarrollo de estos elementos debe ser una prioridad en la
planificación y replanificación. Estimaciones revisadas en base a los resultados
iniciales deben hacerse tan pronto como sea posible. La EDT, y la red de
programación serán más detallada como la comprensión crece y como la
ejecución del proyecto avanza. estimaciones actualizadas basadas en la red de la
EDT y el horario que evoluciona deben estar preparados sobre una base continua.
La fuerza principal de la aproximación / CPM WBS es:
• el aumento de la precisión de las estimaciones que resultan de un mayor

nivel de detalle y el nivel de entendimiento de acompañamiento.
La debilidad principal es:
• falta de conocimiento suficiente o el tiempo para preparar el ADV, WBS,

paquetes de trabajo, y la red de camino crítico en la fase inicial de
planificación de un proyecto de software.
6.7 Modelos de estimación TEORÍA BASADA
Un modelo de estimación basado en la teoría se llama así porque hay una teoría
subyacente de los proyectos de software sobre el que se basa el modelo de
estimación. Dos modelos basados en la teoría se describen en este documento: la
dinámica del sistema, que utiliza las ecuaciones de diferencia para modelar el
comportamiento de proyectos, y la formulación original del modelo SLIM, que
utiliza la ecuación de software Putnam y la versión de Putnam de la ecuación
Norden-Rayleigh para modelar proyectos de software.
El objetivo de esta sección no es para explicar plenamente estos modelos
basados en la teoría sino presentar la naturaleza de las teorías subyacentes, cómo
los modelos incorporan las teorías, y advierten que antes de usar un modelo de
estimación basado en la teoría, usted debe entender la la naturaleza de la teoría
subyacente para determinar si el modelo basado en la teoría de que es apropiado
para su situación.
6.7.1 Sistemas dinámicos

la dinámica del sistema fue inventado por Jay Forrester alrededor de 1960
[Forrester61]. Este enfoque ha sido utilizado para modelar los procesos de
desarrollo de software de [Hamid91] y ha sido investigado además por Madachy
y Boehm [Madachy01]. Las teorías de cómo se comportan los proyectos de
software se modelan mediante interactúan las variables continuas que emplean
circuitos de retroalimentación con el tiempo como variable independiente. Los
modelos de simulación se implementan utilizando ecuaciones en diferencias para
www.it-ebooks.info
modelar las variables continuas.
www.it-ebooks.info
6.7 modelos de estimación teoría BASADA 231
Un modelo simple de la producción de software podría modelar la velocidad

de producción como la productividad para cada individuo multiplicado por el
número de personal, donde el número de personal en cualquier punto en el
tiempo depende del número inicial, la tasa de contratación (la velocidad a la que
el personal esté añadido al proyecto) y la tasa de desgaste (la velocidad a la que
el personal de dejar el proyecto). Tanto la tasa de tasa de desgaste y la
contratación se modela como funciones del tiempo. La productividad, como una
función del tiempo, podrían ser modelado como productividad bruta (por
ejemplo, líneas de código por el personal semanas) menos la tasa de retrabajo
(por ejemplo, líneas defectuosas de código por el personal semanas, como una
función del tiempo). Los correspondientes ecuaciones de diferencias son las
siguientes:
INIT (#_ PERSONAL) = 10

INIT (ATTRITION_FACTOR) = 0,02
INIT (GROSS_PROD_RATE) = 500
INIT (REWORK_FACTOR) = 0,8
INIT (HIRING_FACTOR) = 1,2
HIRING_RATE = HIRING_FACTOR * ATTRITION_RATE
ATTRITION_RATE = ATTRITION_ FACTOR * #_STAFF
NET_HIRING_RATE = (HIRING_RATE - ATTRITION_RATE)
#_STAFF = #_STAFF + NET_HIRING_RATE * t
GROSS_PRODUCTION = #_STAFF * * GROSS_PROD _RATE
t NET_PRODUCTION = GROSS_PRODUCTION *
REWORK_FACTOR
Los valores en el lado izquierdo de cada ecuación se actualizan en cada paso

de tiempo (? T) usando los valores calculados en el lado derecho de la ecuación
en el paso de tiempo anterior. El modelo podría, por ejemplo, producir un
informe que enumera (semana a semana o mes a mes) líneas entregables de
código (o puntos de función u otra unidad de tamaño) produjo esa semana o mes
y el total acumulado de líneas de código producido hasta ese punto en el tiempo.
Una estimación de la duración del proyecto se pudo determinar mediante la
observación de la cantidad de tiempo que se necesita para desarrollar las líneas de
código estimada.
Los efectos de diferentes teorías, incluyendo variaciones en factores tales
como la tasa de contratación, tasa de desgaste, y el factor de retrabajo podrían
determinarse mediante la ejecución de diferentes simulaciones con diferentes
valores de los parámetros. Las teorías más sofisticadas incluirían más factores de
proyecto en el modelo, tales como el impacto de la experiencia del proyecto
manag- de ER, la cohesión del equipo de desarrollo, la eficacia de control de
versiones, un proceso incremental y construcción, y los procesos de verificación
y validación, tales como inspecciones de diseño.
representaciones icónicas de modelos de dinámica de sistemas pueden ser
construidos y los modelos pueden ser ejecutados usando herramientas de
simulación tales como STELLA, iThink, y DYNAMO (accesible en Internet).
6.7.2 DELGADO
El modelo de estimación SLIM (Software de gestión de ciclo de vida) fue
desarrollado por Larry Putnam en la década de 1970 y ha evolucionado con el
tiempo para incluir variaciones sobre el modelo original que responde a los
www.it-ebooks.info
cambios prácticas utilizadas para desarrollar sistemas intensivos en software. La
teoría en que se basa el modelo original se describe aquí [Putnam92].
www.it-ebooks.info
El modelo de estimación SLIM original se basa en dos ecuaciones con dos

incógnitas; esfuerzo del proyecto, E, y la duración horario, T. Una de las
ecuaciones es la versión de Putnam de la ecuación de Rayleigh-Norden que los
modelos de la tasa de acumulación y la disminución gradual del personal del
proyecto. La otra ecuación es la ecuación de software de Putnam.
formas simplificadas de las dos ecuaciones son
mi ~ MBI3 
3
mi ~   

SLOC⎞
 Pi 

Los parámetros de las ecuaciones son:
MBI: un índice de acumulación de mano de obra que refleja la tasa estimada

de acumulación de personal para el proyecto;
SLOC: se estima el tamaño del producto (expresado en líneas de código
fuente, SLOC, o en puntos de función, que se convierten por SLIM a
líneas de código utilizando una tabla interna de FP / SLOC); y
PI: el índice de productividad; datos locales se pueden usar para calibrar el eter
param PI, o los valores de la industria de la media se pueden utilizar
para diferentes tipos de productos.
solución simultánea de las dos ecuaciones resultados en pares de valores para

E (esfuerzo) y T (tiempo) que satisfacen las ecuaciones. El esfuerzo máximo, la
solución de tiempo mínimo de las ecuaciones, para valores dados de MBI, PI,
SLOC, y algunas otras constantes se produce en el punto de intersección en la
escala log-log ilustra en la Figura 6.8. Tenga en cuenta que la línea de MBI, a
partir de la ecuación Norden-Rayleigh, tiene una pendiente de 3. Tenga en cuenta
también que la línea (SLOC / PI) 3, a partir de la ecuación de software Putnam,
tiene una pendiente de 4.
Como se indica en la figura 6.8, una restricción de tiempo máximo se puede
especificar, que se traduce en un esfuerzo mínimo y solución de tiempo máximo.
Según Putnam, el punto de intersección en la figura 6.8 para el tiempo mínimo,
ción máximo esfuerzo solu- a las ecuaciones simultáneas se basa en datos
empíricos que indica se ha observado que han terminado con éxito con esfuerzo y
tiempo combinaciones en el no proyectos línea de PI por encima de la línea de
MBI; esta región se denomina la región imposible en SLIM. Las combinaciones
de esfuerzo y tiempo en la línea de PI por debajo de la línea de MBI son
factibles.
Un aspecto interesante del modelo SLIM, como se aplica en la herramienta de
esti- mación SLIM, es el uso de la simulación de Monte Carlo para calcular
varias combinaciones de esfuerzo y el horario en varios niveles de probabilidad.
tamaño estimado (expresado en puntos de función o líneas de código) se
especifica utilizando el método PERT: tamaño más pequeño estimado, 50%
tamaño probable, y el tamaño estimado más grande de la que se determinan la
media y la desviación estándar de una función de probabilidad beta. El tamaño
puede ser especificado para todo el sistema o para los elementos individuales de
la vista de la arquitectura de descomposición. PI y MBI se pueden especificar
como fijo o dentro de los intervalos de probabilidad.
www.it-ebooks.info
6.7 Modelos de estimación TEORÍA BASADA 233
línea de PI:
log E log E ~ (SLOC / PI)3 * Log t-4
región línea de
imposible MBI:
Máximo log e ~ MBI * log t3
Esfuerzo
Simultáneas
tiempo y
esfuerzo
Soluciones
Mínimo
Esfuerzo log t
Tiempo Tiempo
mínim máximo
o
FIGURA 6.8 solución simultánea de las ecuaciones SLIM
La técnica de Monte Carlo es un método de simulación mediante los cuales,

los valores independientes aleatorias se seleccionan de entre cada una de las
distribuciones de probabilidad inversas para el tamaño, PI, y MBI. Los tres
números resultantes (uno para cada tamaño, PI, y MBI) se utilizan para calcular
una combinación de tiempo esfuerzo. Otro, conjunto independiente aleatoria de
valores de entrada a continuación, se selecciona de entre las distribuciones de
probabilidad y se calcula una segunda respuesta. Los cálculos se repiten por lo
general unos pocos cientos o unos pocos miles de veces. Vea la Sección 6.8.2
para una discusión de la simulación Monte Carlo.
Una vista conceptual de los resultados de una simulación SLIM se representa
en la figura 6.9, en donde cada uno de los “favoritos” puntos de datos es una de
las soluciones simultáneas a las ecuaciones Norden-Rayleigh y Putnam; unos
pocos cientos o unos pocos miles de puntos de solución se calculan normalmente.
Las soluciones en la figura 6.9 están delimitadas por las distribuciones de
probabilidad de tamaño, PI, y MBI, por la solución de tiempo mínimo, y por la
restricción (si existe) especificada para la duración máxima del proyecto.
Proyección de la distribución de esas soluciones al eje del tiempo proporciona
la función de densidad de capacidad proble- para la duración del proyecto;
proyectarlas al eje de esfuerzo proporciona la función de densidad de
probabilidad para el esfuerzo, como se ilustra en la Tabla 6.3.
Interpolación de la tabla 6.3, con un horario de 30 meses (99,99% de horario
probable), que es 87% probable que el proyecto puede ser completado con 500
personas-mes de esfuerzo; con 800 SM de esfuerzo (99,99% probable), es 93%
probable que el proyecto se puede completar en 24 meses. La probabilidad conjunta
de completar el proyecto en 24 meses con 500 meses-personal de esfuerzo es
aproximadamente 0,87 0,93 = 0,81 (81%).
Los principales puntos fuertes del modelo SLIM son la solución simultánea de
esfuerzo, E, y la duración, T, y el uso de la simulación de Monte Carlo, que en
conjunto proporcionan combinaciones comerciales-off de esfuerzo y el horario en
varios niveles de probabilidad. Alter- nativa, una de esfuerzo o la duración puede
ser especificado y la gama correspondiente de valores de la otra con sus
probabilidades asociadas se puede calcular.
Algunas personas han criticado la ecuación software de Putnam por ser
www.it-ebooks.info
demasiado sensible en la modelización de la relación esfuerzo-duración como E
T -4; duplicando el horario sería reducir el esfuerzo a 1/16 del valor original.
www.it-ebooks.info
PI: 13 ± 2
log E SLOC: 100 ± 30
E: 297 SM MBI: 2 ± 15%

: 146 SM
* Valores calculados
Monte Carlo
log t
Tiempo mínimo Tiempo máximo de
Solución M: 19.1 MO restricción
: 3,2 MO
Figura 6.9 Una vista conceptual de una estimación SLIM
TABLA 6.3 Probabilidad oscila para una estimación SLIM

50% Probable 84% Probable 97,5% Probable 99,7% Probable
Esfuerzo, E 297 SM 443 SM 589 SM 735 SM
Duración, T 19.1 MO 22.3 MO 25.5 MO 28.7 MO
Para recapitular un punto anterior: hay que entender la teoría en que se basa un
modelo basado en la teoría de saber si se trata de un modelo de estimación
apropiada para su proyecto. Por ejemplo, la acumulación y la disminución
gradual de la dotación de personal del proyecto Incorporated en el modelo SLIM
original no sería apropiado si el perfil del personal para su proyecto refleja un
valor constante, fijo, como 20 personas de principio a fin. SLIM modelos más
nuevos son apropiadas para varios perfiles de personal.
6.8 Modelos de estimación REGRESIÓN BASADOS
modelos de estimación basada en regresión se basan en ecuaciones derivadas de

los datos históricos recogidos de proyectos anteriores. ecuaciones La
construcción de los datos se conoce como análisis de regresión. Las ecuaciones
que incorporan múltiples variables independientes se derivan mediante un
procedimiento conocido como análisis de regresión multivariante. Pero en la
mayoría de los casos de modelos de estimación basada en regresión para los
proyectos de software, la ecuación de estimación primario se basa en el análisis
de la relación entre una sola variable independiente (por ejemplo, tamaño) y una
variable dependiente (por ejemplo, esfuerzo), como en
mi S
segundo
,
donde E es el esfuerzo, S es el tamaño, y a y b son constantes.

Por ejemplo, si S es el tamaño de miles de líneas de código entregadas de código
(KDSLOC) y E es un esfuerzo hecho en meses-personal, la ecuación podría ser
www.it-ebooks.info
6.8 modelos de estimación REGRESIÓN BASADOS 235
ECUACIONES SLIM
Sin entrar en detalles excesivos, es interesante observar algunos aspectos del

modelo SLIM original, que se basa en la versión de Putnam de la ecuación de
Rayleigh Norden- y la ecuación de software de Putnam.
La ecuación de software Putnam fue derivado por Larry Putnam a partir de
datos empíricos recogidos de varios grandes proyectos de software en la
década de 1970. Es de la forma
SLOC⎞3  T 
mi ~ 
 ,
 Pi 
donde E es el esfuerzo, SLOC es líneas de código fuente, PI es el índice de la
productividad, y
T es hora.
La ecuación Norden-Rayleigh se utiliza para modelar la acumulación y la
fase descendente de nivel de personal en el modelo SLIM originales. Es de la
forma “t veces e elevado a menos t al cuadrado”:
y  F 
Te ,
2re 
F t
2
2tr2
e
donde y es la tasa de acumulación de esfuerzo y la fase abajo, K es el área bajo

la curva de la dotación de personal de t = 0 a , y td es la hora a la que y
alcanza su valor máximo, como se ilustra en la Figura 6.10.
La ecuación de Rayleigh es una forma particular de un distri- bución de
probabilidad Weibull. La ecuación adquirió el nombre de “Norden-Rayleigh”
porque Lord Rayleigh utiliza una ecuación similar en la década de 1800 para
modelar la dispersión de la luz solar reflejada por la tierra, lo que explica por
qué percibimos el cielo para ser azul brillante en un día claro y soleado ( una
forma diferente de dispersión de la luz, la dispersión de Mie, explica por qué
el cielo se ve gris en días nublados o contaminados y rojo al amanecer y al
atardecer).
Esfuer
zo y MBP y'= (K / td2) te-pie) f
Rate'
(t) = t2 / 2tre2
K: área bajo la curva
tiempo, t
tre
FIGURA 6.10 Una ecuación Norden-Rayleigh y la curva
www.it-ebooks.info
En la década de 1960 Peter Norden observó patrones regulares de

acumulación de personal y de fase en proyectos de diseño de hardware. Él
modeló proyectos de hardware que consiste en la planificación y
especificación, diseño, prototipos, y la liberación. Se observó que cada
actividad tiene un patrón de acumulación y la fase abajo y se encontró que la
ecuación de Rayleigh encaja en el conjunto compuesto de estas actividades
que se solapan [Norden63]. Putnam utiliza un modelo similar para los
proyectos de software que consiste en la planificación, diseño e
implementación, pruebas y mantenimiento.
El parámetro de la acumulación de mano de obra (MBP) en la Figura 6.10
determina la pendiente de la curva de Norden-Rayleigh (es decir, la derivación
de y ). Se expresa como
K
MBP  .
tre
3
K y td en la Figura 6.10 determinar el tamaño y forma de la curva Norden-

Rayleigh. K más grande y los valores más bajos implican una td una curva
más alta y más agudamente con visera que lo hacen menores valores de K y
mayores valores de TD, es decir, más grande y más pequeño K resultado td en
valores mayores de MBP y viceversa.
Con base en datos empíricos de proyectos de software completas, Putnam
encontró que la MBP tenía una amplia gama de valores, aproximadamente 7 a
233. En la herramienta de estimación SLIM estos valores están codificados
para el índice de acumulación de mano de obra (MBI), que tiene seis valores
discretos ( 1, 2, ..., 6). MBI valores pueden ser seleccionados para reflejar las
tasas de acumulación de personal que van de lento a extremadamente rápido.
El MBI se utiliza, como se ilustra en la Figura 6.8, para determinar la duración
mínima de un proyecto para un valor dado de MBI.
La integral de la versión de Putnam de la ecuación Norden-Rayleigh es de
la forma
y t   K  1 e F

,
donde K es el área total bajo la curva y, como antes, f (t) = t2 / 2TD.2
El valor de y (t), por un tiempo determinado T, es la cantidad acumulada de
esfuerzo que se gasta de la iniciación del proyecto hasta el tiempo T. Putnam
entonces observó que muchos proyectos de liberar el producto en el pico de la
curva, td, y luego entrar en la fase de mantenimiento, de modo que K es el
esfuerzo total del ciclo de vida. En el tiempo td,
ytre
Esto corresponde a la regla de oro ampliamente utilizado que el 40% del esfuerzo
ciclo de vida transcurre al desarrollo de software y el 60% de mantenimiento del
software.
Otra ecuación SLIM calcula el tiempo de desarrollo mínimo, Td para un
proyecto de software,
0.33

T 
re
K ,
www.it-ebooks.info
donde Td es en año, K es en años-personal (el área total bajo la curva Norden-
Rayleigh), y C es una constante en el intervalo de 14 a 15. años conversión a
meses, años-personal para personal-meses, y dejar que C = 14,5 resultados en
www.it-ebooks.info
Tre  mi ,

0.33
donde Tre es en meses y E es el esfuerzo en meses-personal.24

La duración mínima para un proyecto de 120 meses-personal, por ejemplo,
sería
Tre 120 ~ 2.15 
0.33
Esta ecuación tiempo-esfuerzo de desarrollo corresponde a la regla

ampliamente utilizado de
pulgar que el tiempo de desarrollo es proporcional a la raíz cúbica del esfuerzo
(algunas organizaciones utilizan una regla de la raíz cuadrada).
Información adicional sobre la teoría del modelo de estimación SLIM
original se puede encontrar en [Putnam92].
mi
S .
1.2
Por lo tanto, E 40 cuando S = 10 y E 91 cuando S = 20. Nota el aumento no

lineal en el esfuerzo cuando se duplica tamaño.
El tamaño se utiliza como la variable independiente en las ecuaciones de
estimación basados en regresión porque el tamaño se puede determinar más
objetivamente que otros atributos de producto. medidas también el tamaño, tales
como puntos de función se pueden estimar con más precisión que otros atributos
de producto en las primeras fases de un proyecto (y se convierten a líneas de
código, si se desea).
El exponente b en la ecuación refleja la relación típicamente no lineal entre el
tamaño y esfuerzo. Si b es mayor que 1, la relación exhibe diseconomy de escala
(es decir, un producto de dos veces el tamaño requerirá más que el doble de
esfuerzo). Si b es menor que 1, la relación exhibe economía de escala (es decir,
los productos más grandes requieren desproporcionadamente menor esfuerzo). Y,
por supuesto, b = 1 indica una tionship relación lineal entre el tamaño del
producto y el esfuerzo de desarrollo. En la mayoría de los casos b es mayor que
1, pero no siempre.
Haciendo referencia a la Figura 6.1, nótese que se refiere a un modelo de
estimación basada en regresión en que:
• Experiencias anteriores se resumen en la ecuación de regresión derivada de

los datos his- tórica,
• Características del producto se resumen en la estimación del tamaño y
algunos factores de ajuste (por ejemplo, la complejidad), y
• un factor de ajuste del esfuerzo (EAF) se aplica como un multiplicador en la
ecuación de tamaño esfuerzo
miadj S 

segundo
Una ecuación similar se puede derivar de relacionar horario S a esfuerzo E:

re
S
 miadj.
24
[Boehm81], página 470.
www.it-ebooks.info
En esta relación, el exponente d está típicamente en el intervalo de 0,3 a 0,5.

Ecuaciones similares pueden ser desarrollados a partir de datos históricos para
relacionar, por ejemplo, el número de defectos al tamaño del producto.
Las siguientes secciones describen los modelos de estimación basada en
regresión COCOMO y consideraciones implicadas en el desarrollo de un modelo
de estimación basada regresión-derivada localmente.
6.8.1 Los modelos COCOMO

COCOMO es un acrónimo derivado de la frase “modelo de coste constructivo.”
El conjunto original de los modelos COCOMO fue desarrollado por Barry
Boehm y publicado en su texto Software Economía Ingeniería en 1981
[Boehm81]. Los 1981 modelos COCOMO, posteriores modelos COCOMO, y
modelos COCOMO-como derivados de los datos históricos locales (es decir,
basada en regresión) modelos son los modelos de estimación más ampliamente
utilizados.
Para distinguir el primer modelo COCOMO de modelos posteriores
COCOMO, nos referimos a la primera como COCOMO81. Hay 3 conjuntos de
ecuaciones de estimación en COCOMO81 que se derivaron de los datos
recogidos por Boehm de 63 proyectos de software completas. Estos proyectos y
las ecuaciones resultantes se documentan en el texto se hace referencia. Cada
conjunto de ecuaciones incluye una ecuación para estimar el esfuerzo como una
función del tamaño, donde el tamaño se mide en miles de líneas de código fuente
(KSLOC) y esfuerzo es en meses-personal, además de una ecuación de regresión
que relaciona horario en meses a esfuerzo en meses-personal.
Hay 3 conjuntos de ecuaciones para el esfuerzo y el horario en COCOMO81
debido a que los datos de los 63 proyectos agrupados en 3 grupos. En la
investigación, Boehm determinó que un conjunto de proyectos requiere el menor
esfuerzo para un tamaño dado. Que calificó de estos proyectos los “orgánicos”,
que eran proyectos que normalmente se desarrollaron programas de aplicaciones
independientes. El conjunto de proyectos que requiere la mayor cantidad de
esfuerzo para un tamaño dado se denomina “proyectos integrados”. Estos fueron
los proyectos que se desarrollaron software en tiempo real para los ordenadores
integrados dentro de los sistemas más grandes. Los proyectos intermedios se
denominan “adosado”. Los productos desarrollados por estos proyectos eran
típicamente programas de sistemas tales como compiladores y otras herramientas
de desarrollo de software, tales como depuradores, y aplicaciones de bases de
datos; eran pareado de los sistemas operativos.
Para los sistemas pareados, por ejemplo, los valores de a, b, c, y d resultado en
las ecuaciones de estimación
mi KSLOC
1.12
S mi
0.35
.
Aquí es KSLOC miles de líneas de código fuente, E es el esfuerzo en meses-

personal, y
S es horario en meses.
Para explicar las variaciones en el esfuerzo para proyectos del mismo tamaño
dentro de un mismo conjunto de datos (es decir, la dispersión de los datos
históricos), Boehm y algunos otros expertos utilizaron la técnica Delphi para
desarrollar los 15 factores de ajuste y los rangos de valores que figuran en el
www.it-ebooks.info
Tabla 6.4.
www.it-ebooks.info
TABLA 6.4 factores de coste COCOMO81 y multiplicadores de esfuerzo

calificaciones
Muy Muy Extra
bajo Bajo NominalHigh alto alto
factores de coste multiplicadores
de esfuerzo
atributos del producto
RELY (fiabilidad requerido) 0.75 0.88 1.001.15 1.40
DATOS (tamaño de base de datos) 0.94 1.001.08 1.16
CPLX (complejidad de los productos) 0.70 0.85 1.001.15 1.30 1.65
atributos de equipo
TIEMPO (limitación de tiempo de 1.00 1.11 1.30 1.66
ejecución)
STOR (principal limitación de 1.00 1.06 1.21 1.56
memoria)
VIRT (volatilidad máquina virtual) 0.87 1.00 1.15 1.30
TURN (tiempo de respuesta del 0.87 1.00 1.07 1.15
ordenador)
atributos personales
ACAP (capacidad analista) 1.46 1.19 1.00 0.86 0,71
AEXP (experiencia de la aplicación) 1.29 1.13 1.00 0.91 0.82
PCAP (capacidad de programador) 1.42 1.17 1.00 0.86 0.70
Vexp (experiencia de máquina virtual) 1.21 1.10 1.00 0.90
LEXP (lenguaje de programación 1.14 1.07 1.00 0.95
experiencia)
atributos del
proyecto
MODP (el uso de la moderna 1.24 1.10 1.00 0.91 0.82
prácticas de programación)
HERRAMIENTA (uso de 1.24 1.10 1.00 0.91 0.83
herramientas
SCED dede
(horario software)
restricción) 1.23 1.08 1.00 1.04 1.10
Los factores de ajuste se llaman factores de coste; sus valores se llaman

esfuerzo tipliers ples. multiplicadores de esfuerzo se aplican a una estimación
producida por la ecuación ción del esfuerzo estima- para dar cuenta de las
diferencias esperadas entre los proyectos anteriores y el proyecto que se estima.
Un valor multiplicador de esfuerzo (EM) de 1,0 indica un supuesto de que el
causante del costo tendrá el mismo efecto en el proyecto futuro como en
proyectos anteriores típicos del mismo tamaño. Un EM 1 indica una
suposición de que se requiere un mayor esfuerzo para dar cabida a ese conductor
coste que en el proyecto típico pasado; y EM 1 Indica que se requiere menos
esfuerzo. Guía para la elección de valores de multiplicador para la nemotécnica
muy bajo, bajo, nominal, alto, muy alto y extra alto están previstas en el texto.
Los intervalos y valores relativos de los multiplicadores de esfuerzo pueden
ser visualizados mediante la colocación de ellos en un gráfico, como en la figura
6.11, donde algunos de los multiplicadores de esfuerzo se han trazado. El origen
del gráfico representa un mnemónico de “nominal” y un valor de multiplicador
esfuerzo de 1,0. Un valor nominal no influye en el resultado, es decir, que la
elección de un valor nominal de un multiplicador de esfuerzo indica que el
multiplicador tendrá el mismo efecto que en el “proyecto típico” de la historia
www.it-ebooks.info
multiplic
ador de
esfuerzo • TIEMPO, CPLX
1.6
1.5
• ACAP 1.4
• PCAP 1.3
• 1.2 SCED
1.1 • SCED
mnemotécnico
muy bajo 0.9alto muy supletoria
bajo 0.8 alta alta
•CPLX 0.7 • ACAP, PCAP
FIGURA 6.11 Rangos de valores para algunos multiplicadores de esfuerzo

COCOMO81
conjunto de datos. Una gráfica de los rangos de los 15 COCOMO81 factores de

coste se puede encontrar en el text.25 Boehm
En la comparación de la Tabla 6.4 y la Figura 6.11, se puede observar que el
tiplier multi- esfuerzo de tiempo tiene una alta calificación adicional de 1,66 y
CPLX tiene una alta calificación adicional de 1,56. CPLX tiene una calificación
muy baja de 0,7. Tabla 6.4 indica que el tiempo tiene un valor de esfuerzo
multiplicador nominal de 1,0 (no se muestra en la Figura 6.11). No hay valores
de multiplicador de esfuerzo se especifican para las calificaciones de bajo y muy
bajo de tiempo (o STOR). Esto se debe a la ausencia de una restricción de tiempo
de ejecución (o una limitación de memoria) no requerirá menos esfuerzo siempre
y cuando el proyecto típico pasado no era el momento o con- memoria tensas;
Sin embargo, la falta de suficiente tiempo de ejecución o espacio de memoria
hará que un proyecto mucho más difícil y por lo tanto requieren más esfuerzo.
Tenga en cuenta, además, que en la Tabla 6.4 y Figura 6.11 clasificaciones de
alta y muy alta para atributos del producto y atributos de equipo (por ejemplo,
CPLX) tiene multiplicador de esfuerzo de los valores superiores a 1.0 y los
valores inferiores a 1,0 para las calificaciones de baja y, mientras que valores
muy bajos esfuerzo multiplicadores para Personal Los atributos como ACAP y
PCAP tienen valores inferiores a 1,0 para alta y muy alta clasificación y los
valores correspondientes superiores a 1,0 para baja y calificaciones muy bajas.
Ahora la calificación de Muy Baja del multiplicador esfuerzo SCED es de 1.23
y la muy alta calificación es 1.1. SCED tiene un valor de 1,0 para una
calificación nominal, al igual que todos los demás multiplicadores de esfuerzo.
así SCED tiene una forma “perezosa U” (como se ilustra en la figura 6.14; página
254). También hay que señalar que los valores de esfuerzo multiplicadores
distintos a los que correspondiente a la nemotécnica se puede elegir para los
factores de coste. Los mnemónicos son pro-
RESPETA como una ayuda para la selección de
valores de factor de costo.
El producto de un grupo de multiplicadores de esfuerzo se llama el factor de
ajuste del esfuerzo (EEP). Las ecuaciones COCOMO resultantes son de la forma:
miadj tamaño
segu
EAF Ems,

ndo
donde Eadj es el esfuerzo calculado por la ecuación, ajustado por el producto de los
15 multiplicadores de esfuerzo: EAF = EMs. El tamaño se mide en líneas de
www.it-ebooks.info
código. La mayoría de las herramientas de estimación basado en la especificación
COCOMO81 permiso de tamaño en puntos de función que se convierte en líneas de
código por una mesa en la herramienta.
25
Economía Ingeniería de Software, Prentice Hall, 1981, p. 124.
www.it-ebooks.info
Como se describió anteriormente, la ecuación de programación es de la forma

re
S miadj .
Un ejemplo de cálculo de una EAF se proporciona en la Tabla 6.5.
TABLA 6.5 Un ejemplo de la determinación de

la EAF
Factor de Situación RatingEffort Multiplicador
costo
CONFIAR Al igual que en proyectos Nominal 1.00
DATOS anteriores
baja relación de datos a código Bajo 0.94
CPLX Algoritmos complejos Muy alto 1.30
HORA 80% de los ciclos disponibles Alto 1.11
STOR 70% de la memoria disponible Alto 1.06
VIRT sistema estable Nominal 1.00
GIRO Buen tiempo de respuesta Nominal 1.00
ACAP buenas personas mayores Alto 0.86
AEXP Cuatro años Nominal 1.00
PCAP desarrolladores buenos altos Alto 0.86
Vexp Seis meses Bajo 1.10
LEXP Doce meses Nominal 1.00
MODP Más de un año Alto 0.91
HERRAMI BASIC Bajo 1.10
ENTA
SCED según lo estimado Nominal 1.00
EAF ( 15 EMs) 1.17
Si la ecuación es el
esfuerzo
miadj S
1.2
y si S = 20 y EAF = 1,17, entonces
miadj 20~ 128 meses-personal

1.2
S 128 ~ 13,5 meses.

0.35
Si es Eadj en meses-personal y S en meses, el nivel medio de personal es de

aproximadamente
9.5 equivalente a tiempo completo (FTE) los desarrolladores de software (128 /
13,5).
Boehm también desarrolló tablas de distribuciones porcentuales de esfuerzo y
programación a través de las fases del proyecto de Diseño de Producto (PD),
Diseño detallado (DD), Codificación y pruebas unitarias (CUT) y de Integración
y Pruebas (TI). Estas tablas explican el hecho de que los proyectos más pequeños
tienen un mayor porcentaje de esfuerzo total dedicado al diseño detallado,
codificación y las pruebas unitarias de hacer proyectos más grandes, donde se
gastan grandes porcentajes de esfuerzo y tiempo en el análisis, diseño e
integración y las pruebas del sistema de sistemas más grandes.
Además desarrolló tablas para la distribución porcentual de los esfuerzos entre
los ocho tipos de actividades de trabajo dentro de cada fase del desarrollo de
software para diferentes tipos (orgánicos, adosado, empotrado) y tamaños de
productos:
www.it-ebooks.info
1. análisis de requerimientos,
2. diseño de producto,
3. programación (diseño, codificación y pruebas unitarias detallada),
4. planificación de las pruebas,
5. verificación y validación,
6. oficina de proyectos,
7. CM / control de calidad, y
8. manuales.
El procedimiento para hacer una estimación utilizando COCOMO81 es como

sigue:
1. determinar qué conjunto de ecuaciones a utilizar (es decir, ¿Es el proyecto

“pareado” o “incrustado” “orgánico?”??);
2. Tamaño estimado en miles de instrucciones de código entregadas (KSLOC);
3. seleccionar un valor multiplicador para cada uno de los controladores 15 de
costos;
4. calcular el factor de ajuste del esfuerzo;
5. calcular el esfuerzo estimado;
6. utilizar esfuerzo estimado para calcular la duración programación;
7. utilizar las tablas proporcionadas en [Boehm81] para determinar la
distribución de fase de las actividades de trabajo; y
8. utilizar las tablas proporcionadas en [Boehm81] para determinar la
distribución del esfuerzo de cada uno de los ocho tipos de actividades de
trabajo dentro de cada fase.
COCOMO81 se desarrolló en la era de los ordenadores centrales y los

procesos de desarrollo en cascada. En 1987 publicó Boehm el modelo de
estimación Ada-COCOMO para estimar proyectos de sistemas embebidos. Ada-
COCOMO se sonamed porque fue desarrollado en conjunto con el modelo de
proceso ada para estimar proyectos que utilizan otros procesos de desarrollo de
desarrollo incremental y consistentes con el uso del lenguaje de programación
Ada (y lenguajes y métodos similares) para desarrollar programas de sistemas
integrados [Boehm87 ].
Ada COCOMO-añadió algunos nuevos factores de coste y hace ajustes a
algunos de los multiplicadores de esfuerzo COCOMO81. Las dos mejoras más
significativas en la ADA COCOMO fueron:
• incorporación de cuatro factores de escala para ajustar el exponente de la

ecuación ción el esfuerzo estima- para sistemas embebidos, y
• un procedimiento de estimación para el desarrollo incremental de un sistema
de software o producto.
Los cuatro factores de escala introducidas para permitir el ajuste de los

exponentes en las ecuaciones de esfuerzo y de programa son:
• experiencia con el modelo de proceso Ada,

• la minuciosidad de diseño en PDR (revisión del diseño preliminar),
www.it-ebooks.info
• riesgos eliminadas en PDR, y

• requisitos de volatilidad.
Los valores entre 0 y 5 se seleccionan para cada uno de los cuatro factores (0 ser
malo y 5 siendo bueno). Estos valores se utilizan en las fórmulas que resultan en
un exponente esfuerzo que oscila entre 1,04 y 1,24. La ecuación de esfuerzo es de
la forma:
mi S
segundo
,
dónde
segundo  1.04 1 j 4,
0.01  SFj ,
y
 SF , j 1 j 4,
es la suma de los valores de factor de escala de cuatro.

Makinganestimateforanincrementaldevelopmentproject, asin-Ada COCOMO,
requiere que se especifique:
• el tamaño de cada incremento;

• el inicio de cada incremento con respecto al incremento anterior; y
• el “factor de rotura”, que es una estimación del porcentaje de código en
incrementos anteriores que se reelaboró mientras se desarrolla el incremento
actual.
En 1997 Boehm publicó el modelo COCOMO II y posteriormente actualiza en

2000. El modelo descrito aquí es COCOMO II.2000 [Boehm02]. Entre los
muchos cambios en COCOMO81 y Ada COCOMO en COCOMO II, tres más
importantes son:
1. sustitución de los 3 conjuntos de ecuaciones de estimación en COCOMO81

con dos ecuaciones, una para la estimación de esfuerzo y uno para la
estimación de calendario; cada uno ecuaciones tiene un exponente ajustable.
Estas ecuaciones son similares a, pero no idénticos, a los de Ada-
COCOMO,
2. sustitución de algunos factores de coste y la adición de nuevos factores de
coste que resultaron en 17 factores de coste y los valores de multiplicador
asociado en COCOMO II, y
3. un modelo no lineal para estimar el costo de la reutilización de software.
El exponente esfuerzo en COCOMO II es de la forma:
segundo  0.91 1 j 5.
0.01  SF ,
j
Los factores de escala de cinco exponente en COCOMO II

son:
www.it-ebooks.info
• Precedentedness (PREC): lo familiar que es este tipo de trabajo?
• Flexibilidad (FLEX): cuánta flexibilidad existe en los requisitos?
www.it-ebooks.info
• Resolución (RESL): cómo a fondo es el diseño en el PDR? se resuelven en

riesgos PDR?
• La cohesión del equipo (TEAM): hacer todos los interesados tengan una
visión común? son todos los interesados dispuestos a satisfacer los objetivos
de otros grupos de interés?
• Proceso de Madurez (PMAT): ¿cuál es la tasa de madurez CMMI capacidad
al comienzo del proyecto?
Uno de los seis valores se selecciona para cada uno de los cinco factores. Estos
valores dan como resultado un exponente esfuerzo que oscila entre 0,91 y 1,18.
Una fórmula similar se utiliza para calcular el exponente horario. El exponente
horario oscila entre 0,28 y 0,33.
Se remite al lector al libro de texto y la dirección URL para obtener
información adicional sobre COCOMO II [Boehm02], [USC]. Una retrospectiva
histórica sobre la evolución de COCOMO se presenta en [Fairley07].
6.8.2 Estimación de Monte Carlo

modelos de estimación basada en regresión se pueden utilizar para producir
rangos de estimaciones a diferentes niveles de probabilidad [Fairley02]. Las
ecuaciones de regresión y factores de coste se pueden programar en una hoja de
cálculo. Una herramienta de simulación tal como la bola de cristal (una
herramienta que incorpora un conjunto de macros de hojas de cálculo) se puede
utilizar para especificar las funciones de probabilidad para los multiplicadores de
tamaño y esfuerzo estimado en las células de la hoja de cálculo, con lo que se
introducen distribuciones de probabilidad en lugar de valores individuales
[Crystal ]. La herramienta de hoja de cálculo utiliza la simulación Monte Carlo
para muestrear repetidamente la distribuciones de habilidad y soluciones de
cómputo utilizando esos valores proble-. Si el proceso se repite unos pocos
cientos o unos miles de veces, se genera un histograma de esfuerzo probable,
como se ilustra en las Figuras 6.13a y 6.13b.
Obsérvese en la figura 6.13b que la simulación se ha ejecutado 300 veces. Si
12 de 300 estimaciones se calculan para tener el mismo valor de E, la
probabilidad de que requiere esfuerzo será E es 0,04 (12/300). La probabilidad de
que un proyecto se puede completar con una cantidad de esfuerzo inferior o igual
a E se determina mediante la suma de todas las probabilidades para valores de
esfuerzo inferior o igual a E. En la distribución de probabilidad de la figura
6.13b, por ejemplo , que es 80% probable que el proyecto puede ser completado
con 200 personas-mes de esfuerzo o menos ya que el 80% de los valores
calculados de esfuerzo están en o a la izquierda de 200 SM.
De una manera similar el rango de probabilidad para la duración del proyecto
se puede determinar usando la distribución de probabilidad de esfuerzo en una
ecuación de regresión que relaciona horario S a esfuerzo E como en los modelos
COCOMO:
S mi .
re
El histograma resultante de densidad de probabilidad para el horario será similar

en concepto al de la figura 6.13b.
6.8.3 calibración local

En lugar de desarrollar un nuevo modelo de estimación, es posible que pueda
www.it-ebooks.info
volver a calibrar un modelo existente a la situación local dentro de su
organización. Los parámetros utilizados
www.it-ebooks.info
Desarrollo de un modelo ESTIMACIÓN DE REGRESIÓN BASADOS
Los detalles de la construcción de los modelos presentados por COCOMO de

Boehm en la Cesión de Software Ingeniería económica han dado lugar a la
replicación generalizada del proceso. Muchas organizaciones han desarrollado
y utilizado derivada localmente “COCOMO- como” modelos de estimación.
modelos COCOMO-como también se incorporan en herramientas de
estimación de software com- comercialmente disponibles; alguna entrada
apoyo herramientas de datos locales y la derivación de las ecuaciones usando
estos datos [Costar].
Figura 6.12 ilustra la derivación de una ecuación que relaciona el esfuerzo
de desarrollo E al tamaño del producto S, donde cada uno de los puntos de
datos con estrellas representa un proyecto terminado. Si, por ejemplo, la
ecuación lineal en el dominio log-log es de la forma
Iniciar sesión10 registro esfuerzo 10 0,5 1.25 registro10 tamaño,
entonces la ecuación en el dominio real es
esfuerzo 3.3 size1.25.
Si una ecuación similar en relación al horario de esfuerzo es de la forma
horario log10 log10 0.33 0,4 log10 esfuerzo,
entonces
programar 2,8
effort0.33.
Cuando se utilizan las ecuaciones resultantes, un esfuerzo de factor de

ajuste (EEP) se aplica (en el dominio real) para explicar la diferencia en el
esfuerzo que se requiere para los productos del mismo tamaño.
Iniciar sesión10 Esfuerzo (E) *

4 * *
** *
* *
* * <- pendiente b
3 EAF
*
* ** * * *
*
* * *
* * *
2 * *
* *
* Iniciar sesión10 E = log10 a + b *
* * log10 S
* *
1 E = a * S segundo
* miadj = A * S segundo * EEP
Iniciar sesión10 a ->

3 4 5 6
Iniciar sesión10 Tamaño (S)
FIGURA 6.12 Derivación de un modelo de estimación basada en regresión
www.it-ebooks.info
herramientas de software como la herramienta gratuita de calibración calicó

de SoftstarSystems se pueden utilizar para calcular las constantes y
exponentes de las ecuaciones de regresión con datos de proyectos anteriores,
introducidos por usted o algún otro miembro de su organización
[http://softstarsystems.com/].
Varios puntos deben tenerse en cuenta. En primer lugar, los datos históricos
se transforma en el dominio log-log, la ecuación se deriva en el dominio log-
log, y el resultado se transforma de nuevo al dominio real. Esto permite el uso
de técnicas de regresión lineal para derivar y analizar el (típicamente) relación
no lineal entre el esfuerzo y el tamaño.
Un segundo factor que observar en la Figura 6.12 es la dispersión en los
datos. Si el tamaño del producto fueron un predictor perfecto de esfuerzo
requerido, todos los puntos de datos estarían en la línea de la ecuación. Dicho
de otro modo, la dispersión en los datos indican que los factores distintos del
tamaño determinan la cantidad de esfuerzo necesario. La combinación de
estos otros atributos es el factor de ajuste del esfuerzo en los modelos
COCOMO. Estos son también los factores de ajuste de las figuras 6.1 y 6.3.
En relación con esas figuras:
• la experiencia pasada se resume en las ecuaciones de regresión derivadas

de los datos de los proyectos anteriores,
• el producto futuro se resume principalmente en la estimación del tamaño y
• otros atributos del producto y de proceso se explican por los valores de
multiplicador de esfuerzo de los factores de coste (los factores de ajuste).
El objetivo del análisis de regresión es encontrar valores de los parámetros

a, b, c, y d en las ecuaciones E = a (tamaño) B y S = C (tamaño) d que
proporcionan mejores ajustes a los datos, donde E es el esfuerzo y S es la
duración horario. En el dominio log-log, como se ilustra en la figura 6.12, se
lleva a cabo análisis de regresión lineal para encontrar valores de log a (la
intersección) y b (la pendiente) de la ecuación lineal. Un proceso similar se
utiliza para encontrar los valores de c y d para la ecuación de esfuerzo-
duración. El método de mínimos cuadrados se usa típicamente para derivar las
ecuaciones, ya que es relativamente sencillo y produce buenos resultados. Se
trata de valores de log a y b encontrar (y c y d log) que minimizan los
cuadrados de las diferencias entre los valores reales y estimados para cada uno
de los puntos de datos.
Una medida de la bondad de ajuste para una ecuación de regresión es la
suma de los errores relativos (RE) entre cada valor estimado y cada valor real
en la que:
estimar real
cada RE .
real
Por lo tanto ER más pequeños indican menos dispersión en los datos reales de
los proyectos anteriores (un mejor ajuste de la ecuación a los datos) y cosa
más grandes indicar con mayor dispersión en los datos (a menos buen ajuste
de la ecuación a los datos). RE = 0 significa que el valor estimado y el valor
real son los mismos. Si todos los puntos de datos estaban en la línea de la
ecuación, la suma de cosa sería cero. En este caso el tamaño sería un predictor
perfecto de esfuerzo.
www.it-ebooks.info
6.8 Modelos de estimación REGRESIÓN BASADOS 247
La distribución de los errores relativos entre los valores estimados y los

valores reales se puede utilizar para determinar el porcentaje de valores
estimados que se encuentran dentro de un determinado porcentaje de los
puntos de datos reales. Por ejemplo, es posible encontrar que el 80% de los
valores estimados difieren en no más del 20% de los valores reales cuando los
valores reales se normalizan los factores de ajuste para los proyectos. Esto se
expresa por una función PRED (predictor) para los modelos de estimación:
PRED (0,8) = 0,2 en el ejemplo.
La función PRED es ampliamente aceptada como una medida de la eficacia
de un modelo de estimación (todos los modelos de estimación, incluyendo los
modelos de regresión). Un modelo que no lograr PRED (0,8) = 0,2 se suele
juzgarse a ser demasiado inexacta para su uso, lo que significa que hay
demasiado dispersión en los datos históricos subyacentes.
Otra medida de la bondad de ajuste es el coeficiente de correlación r, que es
una medida de la correspondencia entre los valores estimados y los reales. r
varía entre 0 y 1; r = 0 significa que no hay correspondencia, y r = 1 significa
que no es perfecta correspondencia entre los valores estimados y los reales. En
el último caso (r = 1) todos los puntos de datos sería en la línea de la ecuación
de estimación, y como se ha indicado anteriormente, el tamaño serían un
predictor perfecto de esfuerzo.
En principio, el desarrollo de un modelo de estimación basada en la regresión es
simple:
1. recoger algunos datos de proyectos anteriores,

2. utilizar una herramienta de análisis de regresión para derivar algunas
ecuaciones, y
3. desarrollar algunos parámetros de costes y valores multiplicadores
esfuerzo para dar cuenta de las diferencias entre los proyectos anteriores
aparentemente similares.
En la práctica no es tan simple, por supuesto. El primer problema que puede

encontrar es la falta de datos de proyectos anteriores que se registra
constantemente el uso de unidades de medida coherente y formas consistentes
de factores de recuento como el tamaño, el esfuerzo, el programa y los
factores de ajuste. Si usted no tiene datos históricos consistente, usted o
alguien de su organización debe establecer un proceso de recolección de
métricas que dará lugar a la acumulación de datos en los que basar un modelo
de estimación.
El segundo problema que puede encontrar es amplia dispersión en los
datos, lo que significa que los valores de datos para proyectos del mismo
tamaño están tan dispersos que los datos no se agrupan alrededor de las líneas
de las ecuaciones; dicho de otro modo, el error residual, coeficiente de
correlación, y PRED (0,8) todo indica que los proyectos anteriores son tan
diferentes que no es posible estimar proyectos futuros en base a estas
experiencias pasadas. Se trata de un indicador (un síntoma) de un problema
subyacente más profunda: los procesos de desarrollo caótico, a saber, la falta
de prácticas de desarrollo y gestión sistemática de su organización! Es
imposible desarrollar un enfoque sistemático para la estimación de los
proyectos futuros cuando los proyectos anteriores se caracterizan por el caos.
Si usted tiene éxito en la superación de los problemas de mala gestión,
todavía puede ser culto cultad de encontrar un pequeño conjunto de factores
de coste que explican las diferencias en el esfuerzo y la periodicidad de los
www.it-ebooks.info
proyectos del mismo tipo y tamaño. Los factores de coste verdaderos pueden
ser políticas o de carácter social, tales como las malas relaciones de clientes,
management indiferente, y / o desarrolladores de software desmoralizados.
No se debe dudar de incluir dichos factores en un modelo de estimación.
www.it-ebooks.info
No es imposible de superar estos problemas. Muchas organizaciones han

desarrollado y utilizado rutinariamente modelos de estimación basada en
regresión obtenidos localmente. Algunas organizaciones tienen diferentes
modelos de estimación basada en regresión para diferentes tipos de proyectos;
las ecuaciones se basan en los repositorios de datos de la historia robustos.
Cuando un proyecto se completa los datos más antiguos establecidas en el
repositorio para se elimina ese tipo de proyecto, los datos para el proyecto
recién terminado se introduce, y se vuelve a calibrar el modelo (es decir, las
ecuaciones se vuelven a obtuvieron utilizando los nuevos datos). Existe, pues,
una “ventana deslizante” de los datos históricos que refresca constantemente
los repositorios de datos y actualiza los modelos de estimación.
en la mayoría de los modelos de estimación comerciales están calibrados para
promedios de la industria (por ejemplo, PI y MBI en la herramienta SLIM, los
valores de los multiplicadores constantes, exponentes, y los conductores de coste
en la herramienta CoStar para COCOMO II). Calibración local le permite ajustar
los parámetros del modelo.
Puede determinar si la calibración local está garantizado mediante la
comparación de los valores estimados producidos por el modelo de valores
registrados para los proyectos anteriores y tratando de encontrar un conjunto de
parámetros realistas para el modelo que produce aceptablemente pequeñas
variaciones entre los valores estimados y los valores conocidos para los proyectos
terminados. Si esto no es posible, el modelo debe ser recalibrado.
Las herramientas de estimación de SLIM, por ejemplo, pueden volver a
calibrar automáticamente el PI y los parámetros MBI basado en los datos del
historial de proyectos anteriores locales que se introducen en la herramienta. El
multiplicadores constantes A y C en el esfuerzo COCOMO y el horario
Probabilida Densidad
d de
Random 1.0 Distribución probabilid
Number
ad
1
0.75 estimación
Aleatori 0.5 de
o ecuaciones
Número 2 0,25
0 S
810 12
Esfuerzo
Rango de Tamaño
6.13a FIGURA El muestreo utilizando la estimación de Monte Carlo
Frecuencia
PAGrobabilidad 300 ensayos de ENC
occurr E
0.04 12
0.03 9
0.02 6
0.01 3
50 SM 100 SM 150 SM 200 SM250 SM 300 SM Esfuerzo

FIGURA 6.13B Un histograma esfuerzo
www.it-ebooks.info
6.10 ESTIMACIÓN DE RECURSOS DE CICLO DE VIDA, trabajo y costes 249
ecuaciones pueden ser recalibrados utilizando una técnica de aproximación de

mínimos cuadrados que compensa las diferencias entre los valores estimados
utilizando las viejas ecuaciones y los valores reales; Boehm recomienda que los
datos de al menos cinco proyectos anteriores pueden usar para volver a calibrar el
término constante en una ecuación de regresión [Boehm81].
La calibración de ambos los multiplicadores constantes y exponentes en el
esfuerzo y programar ecuaciones de un modelo de estimación basada en
regresión es más problemática porque cálculo de tanto el multiplicador constante
y exponente (es decir, el origen y la pendiente de la línea recta mediante
regresión lineal en el registro de dominio -log) es más sensible a las variaciones
en los datos de los que es el cálculo del multiplicador constante sola. Boehm
recomienda que los datos consistentes de al menos 10 proyectos que están
representativa de los proyectos que se estima en un futuro se utilizará
[Boehm81].
Una nota final de precaución: la luz de la discusión anterior, no se debe utilizar
un modelo de estimación o una herramienta para estimar sus proyectos sin
comprobar la conformidad del modelo con los resultados conocidos de algunos
proyectos realizados en su organización y hacer los ajustes y la recalibración
necesarias ; si la herramienta o modelo sea un modelo COCOMO, un modelo
SLIM, un modelo desarrollado a nivel local, o cualquier otro modelo de
estimación.
6.9 herramientas de estimación
SLIM y COCOMO son representativos de los modelos de estimación para el que

las herramientas de software están disponibles para ayudarle en la realización de
estimaciones. De acuerdo con Capers Jones, había alrededor de 50 herramientas
de estimación disponibles comercialmente comercializados en los Estados
Unidos y 25 más o menos en Europa en 2002 [Jones02]. En el documento citado,
Jones se enumeran las capacidades básicas de la mayoría de las herramientas de
estimación, capacidades adicionales proporcionadas por algunas, pero no todas
las herramientas de estimación, y las capacidades proporcionadas por sólo unos
pocos, en su caso, herramientas de estimación. Algunas de las capacidades en sus
listas, además de algunas otras capacidades que no se mencionan en su artículo,
se presentan en la Tabla 6.6.
Algunas herramientas de estimación se pueden comprar, otros pueden ser
arrendadas, y algunos están disponibles como freeware. La mayoría de los
vendedores de herramientas comerciales vender o arrendar herramientas
adicionales para registrar y métricas del proyecto de informe, herramientas de
repositorio para almacenar los datos históricos para proyectos terminados, y
herramientas de calibración. La mayoría también proporcionar copias
descargables UACIÓN eva- de sus herramientas.
Como se mencionó anteriormente, las herramientas de software disponibles en
el mercado por lo general se calibraron datos de la industria de la media. Usted
debe comprobar y ajustar la calibración antes de utilizar cualquier herramienta de
software para hacer estimaciones para su proyecto. Como veremos más adelante,
siempre se debe usar dos o más técnicas de estimación complementarios (por
ejemplo, la EDT / CPM basado en el juicio de expertos, más una herramienta de
estimación calibrada localmente) y reconciliar las diferencias en las estimaciones
proporcionadas por las diferentes técnicas.
www.it-ebooks.info
6.10 ESTIMACIÓN DE RECURSOS DE CICLO DE VIDA, trabajo y costes
Dependiendo de la naturaleza de su proyecto y su organización, se le puede pedir

a proporcionar una estimación de los recursos del ciclo de vida, el esfuerzo y los
costes para el desarrollo del software, la instalación y la formación de los
usuarios, proporcionando apoyo continuo y el mantenimiento, y retirando la
software. Es posible que tenga los datos históricos en los que basar su
www.it-ebooks.info
TABLA 6.6 Capacidades de herramientas de estimación de software [Jones02]

Capacidades de la mayoría de herramientas de estimación
Soporte para ambos puntos de función y líneas de código
(LOC) la conversión entre los puntos de LOC y función
A nivel de fase, nivel de actividad y a nivel de
tareas de estimación de estimación de desarrollo
incremental
El apoyo a la reutilización del software de varios artefactos
Las capacidades adicionales de algunos, pero no todas las herramientas de

estimación
Soporte para estimaciones basadas en métricas tales como las métricas
orientadas a objetos de riesgos y análisis de valor
plantillas de estimación de defectos derivados de
los datos históricos y la estimación de la
fiabilidad
Del costo para el completo y las estimaciones de tiempo-de-completa
Enlaces a herramientas de gestión como Artemis y Microsoft Project
conversiones de divisas para proyectos de proyectos internacionales
cálculos de inflación para proyectos a largo plazo
Las estimaciones la forma adecuada para los niveles de madurez de SEI
Capacidades proporcionadas por pocas (o ninguna) herramientas de

estimación
los costos de conversión y la nacionalización de las tasas
internacionales para proyectos de búsquedas de marcas y
derechos de autor
Los costos de adquisición de off-the-shelf costos de implementación de
paquetes de software comerciales para recursos empresariales costos
aplicaciones de planificación de litigio por incumplimiento de contrato
si un proyecto se retrasa o por encima del presupuesto
estimación, es posible utilizar algunos promedios de la industria, o el método de

estimación / herramienta que está utilizando puede proporcionar estimaciones de
costes del ciclo de vida en base a promedios de la industria o los datos locales.
promedios de los datos o de toda la industria históricos locales pueden indicar,
por ejemplo, que el costo de desarrollo es típicamente 33% del coste total del
ciclo de vida para su tipo de sistema o producto, lo que indica que los costos
adicionales del ciclo de vida incluirán un factor adicional de dos veces su
estimación para el proyecto de desarrollo de software.
Es posible que tenga una regla local de pulgar que indica la densidad de
defectos reportados por los usuarios es típicamente de 0,1 defectos por punto de
función (0.1 D / FP) durante los primeros seis meses de funcionamiento y 0,05 D
/ FP durante los segundos seis meses. Si su producto contiene 1000 puntos de
función, se debe esperar que los usuarios reportan 100 defectos durante los
primeros seis meses y 50 durante el segundo seis. Si se tarda, en promedio, 1
personal semanas para reparar un usuario informó de defectos y distribuir la
versión actualizada del producto, y si se asume que hay 25 semanas de trabajo en
6 meses, se debe planear para 4 mantenedores de software durante los primeros
seis meses (100/25) y 2 durante el segundo seis (50/25). Si usted debe
proporcionar teléfono y sitio web de soporte para los usuarios, se deben estimar
los costos de personal y las instalaciones.
www.it-ebooks.info
Si se utiliza el perfil de Rayleigh para la tasa de esfuerzo, como en SLIM, el
área bajo la curva de Rayleigh representa el esfuerzo total del ciclo de vida.
Basado en experiencias pasadas u otra información, es posible estimar que se
requerirá el 40% del esfuerzo total para el producto
www.it-ebooks.info
6.11 Un procedimiento de estimación 251
desarrollo y 60% para el mantenimiento (SLIM utiliza 39% y 61%; 0,39 siendo
el punto en el eje de tiempo donde el esfuerzo alcanza su valor máximo en la
ecuación Norden- Rayleigh).
COCOMO II calcula los costes de mantenimiento de una estimación del
tamaño, SizeM, (tamaño a añadir más tamaño que ser modificado durante el
período de mantenimiento) multiplicado por un factor de ajuste de
mantenimiento (MAF) que da cuenta de la falta de familiaridad programador
(UNFM) y la comprensión de software (SU) . SizeM se puede especificar en
puntos de función o líneas de código. Adiciones y cambios se especifican para la
duración del período de mantenimiento TM, lo que puede prolongar durante la
vida útil del software o podría ser necesaria una reestimación sobre una base
anual o semianual. Los factores UNFM y SU representan el efecto de la
condición del software y su documentación sobre el esfuerzo necesario para
entender los cambios que hacer; estos son los mismos factores utilizados en el
modelo COCOMO II para la reutilización del software.
En COCOMO II,
SizeM size añadió tamaño modified
MAF, donde MAF es el factor de ajuste de mantenimiento:
MAF 1 ⎛ ⎛ ⎞ SU UNFM⎞.
 

SizeM se utiliza en la ecuación de estimación de esfuerzo COCOMO II. Como es

habitual en COCOMO II, un factor de ajuste del esfuerzo (EEP) se aplica a la
estimación de esfuerzo determinado por la ecuación de estimación de esfuerzo:
PMMETRO tamañoMETRO 

s
e
g
u
n
donde PMM se estima meses programador de esfuerzo de mantenimiento y MAF
d
o
es el producto de los valores de esfuerzo multiplicadores de los factores de coste
para el mantenimiento del software.
El nivel medio de personal de mantenimiento del software se obtiene calculando:
FSPM PMM,
TMETRO
donde FSPM es el personal a tiempo completo para el mantenimiento del

programa y TM es el período de tiempo del esfuerzo de mantenimiento.
6.11 Un procedimiento de estimación
Estimación, como todos los procesos de ingeniería de software, debe llevarse a

cabo en ajustan baile con un procedimiento bien definido (es decir, un conjunto
de pasos a seguir). Un procedimiento de estimación de múltiples pasos se
enumeran y comentan a continuación:
1. Determinar el propósito de, y se requiere precisión de la estimación.

2. Determinar la información necesaria y las fuentes de la misma.
www.it-ebooks.info
3. Planificar el horario, recursos y responsabilidades para el desarrollo de la

estimación.
4. Desarrollar los requisitos en tanto detalle como sea posible y necesario.
5. Verificar que los requisitos son completa, consistente y correcta, en la
medida posible.
6. Desarrollar una vista de nivel superior de arquitectura de descomposición
(ADV) con el mayor detalle posible y lo justifique.
7. Si se justifica, desarrollar el tamaño, la complejidad y los atributos de
calidad requerida para cada componente de la ADV.
8. Desarrollar una estructura de desglose del trabajo (EDT) con el mayor
detalle posible y lo justifique.
9. Suministrar cualquier factores adicionales requeridos por las técnicas de
estimación para ser utilizados (siempre usar más de una técnica de
estimación, por ejemplo, WBS- basa el juicio de expertos y un modelo
SLIM o COCOMO calibrado localmente)
10. Preparar cálculos utilizando las técnicas de estimación seleccionados.
11. Realizar análisis de sensibilidad de las estimaciones.
12. Conciliar las diferencias en las estimaciones.
13. factores de riesgo documento expuestos por el proceso de estimación.
14. Preparar un plan para la actualización de la estimación a intervalos
periódicos y no periódicos como eventos ocurren.
15. Elaborar e implementar un plan para la retención de la línea de base de
datos de estimación, la estimación documentada, y las actualizaciones en
curso a la estimación.
16. Documentar la estimación utilizando una plantilla estándar para las
estimaciones, para incluir la información en la Sección 6.12 de este
capítulo.
Al igual que con todos los procesos, las etapas del procedimiento mencionadas
anteriormente deben ser adaptado a las necesidades de la situación. Si el paso 1
(determinar el propósito de, y la precisión requerida de la estimación) revela que
la estimación es un “parque de pelota” estimar para determinar la viabilidad de
un proyecto contemplado, una regla de cálculo rápido de pulgar puede tener una
potencia suficiente. Si el paso 1 revela que la estimación es para el próximo
producto principal de la organización, en la que la supervivencia de la empresa
puede depender, la estimación debe ser con- canalizado con gran cuidado y puede
implicar estudios de viabilidad, creación de prototipos, y el análisis de la
competencia.
Varias etapas del procedimiento de estimación utilizan la frase “con el mayor
detalle posible y lo necesario.” Dependiendo de la finalidad y el carácter crítico
de la estimación, el desarrollo de una ADV y un WBS puede o no estar
justificada. Dependiendo de la calidad de los requisitos y el tiempo disponible,
puede que no sea posible desarrollar un ADV o WBS sin trabajo adicional para
desarrollar los requisitos.
Paso 9 indica que siempre se debe utilizar más de una técnica de estimación y
el paso 12 llamadas para la conciliación de la diferencia en las estimaciones
producidas por múltiples técnicas. Una vez más, dependiendo de la finalidad de
la estimación y la información disponible para realizar la estimación, el uso de
múltiples técnicas de estimación puede no estar justificada; Sin embargo, se debe
utilizar varias técnicas de si se está preparando para cometer usted y su equipo de
proyecto para un proyecto basado en las estimaciones. Se recomienda que una de
www.it-ebooks.info
las técnicas basarse en la opinión de expertos o local
www.it-ebooks.info
PROCEDIMIENTO 6,11 una estimación 253
historia de esfuerzo, la duración, las habilidades y los recursos necesarios para

completar las tareas de los paquetes de trabajo en la EDT. Si está disponible, la
segunda opción debe ser una herramienta de estimación calibrada localmente.
Una tercera estimación podría implicar el uso de una estimación téc- nica
pragmática, como regla general, la analogía, o Delphi.
Para conciliar las diferencias producidas por diferentes estimaciones, el paso
11 en el procedimiento de estimación exige la realización de un análisis de
sensibilidad en cada estimación resultante. El análisis de sensibilidad se refiere a
la determinación de la sensibilidad de las variaciones en las salidas estimadas en
base a las variaciones en las entradas de estimación. Grandes variaciones en las
salidas estimadas que resultan de las pequeñas variaciones en las entradas indican
que la técnica de estimación es sensible a los parámetros de entrada. Sabiendo
que la estimación acoplado valores son sensibles a ciertos valores de entrada
puede dar lugar a un examen más detallado de esas entradas y pueden ayudar a
explicar por qué dos estimaciones producidas por dos técnicas diferentes no están
de acuerdo.
Por ejemplo, el tamaño del producto es el parámetro de entrada más sensible
para la mayoría de las herramientas de estimación, ya que es la variable primaria.
En COCOMO II el efecto combinado de los multiplicadores de esfuerzo de
personal es el segundo parámetro más sensible. El efecto combinado de la gama
de valores de personal multiplicadores de esfuerzo, tal como se especifica en el
texto COCOMO II, puede provocar variaciones de aproximadamente 10: 1 en las
estimaciones de esfuerzo, lo que es consistente con las observaciones de otros
[Sack68], [DeMarco99].
Además, el índice de equipo usado para ajustar el exponente en la ecuación de
estimación de esfuerzo COCOMO II ejerce un fuerte efecto, no lineal en el
esfuerzo estimada como una función del tamaño del producto; por ejemplo,
variando el índice de equipo de a Muy Alta Muy baja da como resultado un
cambio del 20% del esfuerzo estimado para proyectos pequeños. Debido al efecto
no lineal de la ecuación exponente esfuerzo, tamaños más grandes darán lugar a
variaciones grandes en el esfuerzo estimado en función del valor EQUIPO.
Otro factor de sensibilidad a considerar cuando se utiliza un modelo
COCOMO-como es la disyuntiva no lineal entre el esfuerzo y el horario. En los
diferentes modelos COCOMO, por ejemplo, la relación entre el esfuerzo y el
horario es de la forma
re
S  miadj,
donde S es horario en meses, Eadj es el esfuerzo en meses-personal (calculada

utilizando la ecuación de esfuerzo y multiplicadores de esfuerzo), c y d son
constantes en COCOMO81, y c es una constante y d se calcula en Ada-
COCOMO y COCOMO II.
Constant c está en el intervalo de 2,5 a 3,0 para los diversos modelos
COCOMO y exponente d es del orden de 0,33 (la raíz cúbica de esfuerzo). Si c =
2,5 y d = 0,33 en la ecuación de programación, un proyecto estimado para
requerir 120 meses-personal de esfuerzo requeriría un horario de
aproximadamente 12,5 meses lo que resulta en un nivel medio de personal de
aproximadamente 10 miembros del personal FTE (120 / 12.5) .
La regla raíz cuadrada de oro es otra manera de estimar horario y nivel de
personal promedio para una cantidad dada de esfuerzo [Jalote02]. Si, por
ejemplo, un proyecto se estima que requerirá 120 persona-meses de esfuerzo,
sería programado como 11 meses, con una plantilla media de 11 desarrolladores
de software (112 = 121). Por lo tanto, utilizando tanto una ecuación de
www.it-ebooks.info
programación COCOMO y el Estado raíz cuadrada del pulgar que indicaría que
un proyecto de 120 meses-personal podría ser programada como 11 a 12,5 meses,
con una plantilla media de 10 o 11. Una opción razonable sería un niño de 12
meses proyecto con una plantilla media de 10 personas.
www.it-ebooks.info
En los diferentes modelos COCOMO la sensibilidad del nivel medio de

personal a variaciones ciones en el esquema se determina por el conductor coste
SCED; que se utiliza para ajustar esfuerzo estimado para los horarios que difieren
de los calculados por la ecuación de programación COCOMO. valores de
multiplicador del conductor coste SCED se enumeran en la Tabla 6.4 y se
ilustran en la Figura 6.14.
1.4 SCED
Esfuerzo
Multiplica
dor
1.3
1.23
1.2
1.1 óptima
Program
ar
Relativo
Horario
1.0 (T / Topt)
0.5 0.751.0 1.25
topt
FIGURA 6.14 SCED multiplicador

de esfuerzo
En la figura 6.14, Topt es la duración calendario calculado por la ecuación horario

COCOMO (que se deriva de los datos históricos de proyectos anteriores). Topt es
óptima en el sentido de que se requiere una cantidad mínima de esfuerzo para un
proyecto de dura- ción topt; duraciones que son tanto más largo y más corto que Topt
requerirán más esfuerzo que la duración óptima. duraciones más largas requieren un
aumento de esfuerzo, e incurrir en costos aumentaron de manera lineal debido a los
costes de personal y las instalaciones sobre una base permonth. Un horario de 1,6
Topt, por ejemplo, requeriría un incremento del 10% del esfuerzo (SCED = 1,1). En
el ejemplo anterior, un proyecto de 12 meses, 10 FTE promedio de dotación de
personal, si se extendió a 19 meses (1,6 12) requeriría 7 FTE dotación de personal
media- (120 1,1) / 19.
Como se ilustra en la figura 6.14, la pena el esfuerzo para comprimir el horario
es más severa que la pena para extender el horario. Si el horario en el ejemplo se
comprime desde 12 meses a 9 meses (0,75 TOPT) el esfuerzo se incrementaría a
147 meses-personal (120 1,23) y la dotación de personal promedio requerida
sería 16,4 (un aumento del 64%). Tenga en cuenta que un aumento lineal de la
dotación de personal promedio resultaría en la dotación de personal media de
13,3 (10 / 0,75). El aumento adicional a 16,4 (1,23 13,3) es necesario para
compensar la disminución de la productividad de cada individuo causado por el
aumento de esfuerzo dedicado a la comunicación y coordinación entre un grupo
mayor de personas.
Tenga en cuenta que el factor de costo SCED en la Figura 6.14 indica que la
programación no puede ser comprimido más de 25% de Topt (es decir, un 75%
de la programación mínima de esfuerzo). El límite de 75% se basa en la
observación de que sólo 4 de 63 proyectos en el conjunto de datos COCOMO81
fueron capaces de comprimir con éxito sus horarios debajo del límite de 75%;
estos 4 proyectos eran pequeños (esfuerzo total de 6, 7, 8, y 15 meses-personal)
www.it-ebooks.info
6.11 Un procedimiento de estimación 255
y había requerido baja fiabilidad, una alta capacidad de personal, y el buen uso de
las prácticas de programación modernos.
La porción superior de SCED en la Figura 6.14 (no incluido en los modelos
COCOMO) indica que un esfuerzo excesivo (añadiendo demasiadas personas a
un proyecto) se extenderá el horario. Esto es consistente con la ley de Brook
[Brooks95]: Adición de Mano de Obra de un proyecto de software finales hace
que sea más tarde.
Volviendo a la etapa 11 en el procedimiento de estimación, las
consideraciones anteriores permiten realizar análisis de sensibilidad de las
estimaciones de esfuerzo y combinaciones esfuerzo-horario; de este modo se
puede determinar los valores de entrada a la que su estimación es particularmente
sensible, y determinar la pena a pagar para apartarse de un programa de “óptima”
que minimiza el esfuerzo total del proyecto.
Como se dijo anteriormente, el modelo SLIM original utiliza la siguiente
ecuación para calcular el tiempo de desarrollo mínimo, Td, para un proyecto de
software:

0.33

T re  ,
K
donde Td es en año, K es en-año de personal (el área total bajo la curva de

Norden-Rayleigh, y C es una constante en el intervalo de 14 a 15. años
conversión a meses, años-personal para personal-meses, y dejar que C = 14,5
resultados en
Tre mi ,
0.33
donde Td es en meses y E es el esfuerzo en meses-personal.

Para el proyecto de ejemplo anterior, la duración mínima programación para
un proyecto de 120 meses personal- sería
Tre  0.33 ~ 2.15 
Este valor es comparable con el horario de tiempo mínimo de 9 meses

estimado en COCOMO. El modelo de estimación SLIM impone severas penas de
esfuerzo de compresión del cronograma y, en contraste con los modelos
COCOMO, calcula un menor esfuerzo por períodos más largos de horario. La
relación esfuerzo-horario en el modelo SLIM indica que el esfuerzo es
proporcional a la duración horario para el poder 4:
mi T ~ .
De acuerdo con esta relación, la disminución de la programación a partir de 12

meses a 9 meses en el proyecto ejemplo aumentaría el esfuerzo de 120 meses-
personal a 370 meses personal- (0,754 = 0,32; 120 / 0,32 = 370) con un nivel
medio de personal de 41 personal (370/9) y extendiéndose el horario a 18 meses
podría disminuir el esfuerzo de 120 meses-personal a aproximadamente 24
meses-personal (1,54 = 5,06; 120 / 5,06 24) con un nivel medio de personal de
1,3 personal (24/18 ).
Puede utilizar la técnica de simulación de Monte Carlo para realizar análisis de
sensibilidad del equilibrio entre el esfuerzo y el horario con la función de
estimación SLIM o el uso de una hoja de cálculo programado con ecuaciones de
regresión utilizando la bola de cristal. Los resultados
www.it-ebooks.info
se obtiene a partir de métodos de estimación y herramientas siempre debe ser

sometido a una verificación de sonableness rea-: herramientas y métodos de
estimación son ayudas; ellos no son la panacea. Recordemos que el objetivo de la
estimación es determinar, a un alto nivel de confianza, un conjunto de parámetros
que le permitirá éxito la entrega de un producto aceptable dentro del calendario
previsto y el presupuesto.
Los pasos 13, 14, y 15 del procedimiento de estimación se ocupan de la
documentación de la estimación. Paso 13 (factores de riesgo de documentos
expuestos por el proceso de estimación) proporciona información que debe
incluirse en la estimación documentado; También puede ser utilizado en la
preparación del plan de gestión de riesgos (véase el capítulo 9). El procedimiento
de estimación puede haber revelado, por ejemplo, que los requisitos son
demasiado vagos para apoyar una estimación precisa, o que los resultados de
horario de restricción en riesgo inaceptable para completar con éxito el proyecto
dentro de la duración limitada, o que los desarrolladores de software no tienen
suficiente conocimiento del nuevo entorno de desarrollo para utilizarlo con éxito
en el proyecto.
Paso 14 (preparar un plan para la actualización de la estimación a intervalos
periódicos y como se producen eventos aperiódicos) se refiere a la preparación de
un plan para mantener la corriente de estimación como comprensión del proyecto
crece, y cambiar las condiciones. Muchas organizaciones actualizan las
estimaciones del proyecto sobre una base mensual. Los cambios en las
exigencias, la reducción del presupuesto, o la pérdida de una persona clave son
ejemplos de eventos aperiódicos que justifiquen la revisión de su estimación.
Paso 15 (preparar e implementar un plan para la retención de la línea de base
de datos de estimación, la estimación documentado, y las actualizaciones en
curso a la estimación) está relacionada con el control de versiones de las
estimaciones documentados, los datos sobre los que se basa cada estimación, y
las versiones actualizadas de la estimación que se crean periódicamente y no
periódica. Al igual que con todas las revisiones a todos los productos de trabajo
baselined, la siguiente información debe ser registrada para cada versión de una
estimación:
• la fecha de la revisión,
• los motivos de la revisión,
• los datos utilizados para realizar la revisión y
• los elementos cambian
control de la línea de base de las estimaciones documentadas elimina la

ambigüedad en cuanto a qué estimación mate es el actual y crea una pista de
auditoría de cómo y por qué el proyecto cambió con el tiempo.
El último paso en el procedimiento de estimación (documento de la estimación
utilizando una plantilla estándar para las estimaciones) debe basarse en una
plantilla estándar para las estimaciones de grabación que se utiliza en toda la
organización. La plantilla debe proporcionar para registrar la información que se
indica y se discute en la siguiente sección.
6.12 Una plantilla para ESTIMACIÓN DE GRABACIÓN
Preguntas a responder al hacer estimaciones son típicamente de la forma:
www.it-ebooks.info
• esfuerzo: la cantidad de trabajo serán necesarios?
• duración cronograma: ¿cuánto tiempo se tarda?
www.it-ebooks.info
6.12 Una plantilla para ESTIMACIÓN DE GRABACIÓN 257
• recursos: ¿qué tipo de niveles de habilidad, herramientas y otros recursos se

necesitan? qué cantidades se necesitan? cuándo van a ser necesarias y por
cuánto tiempo?
• asignaciones: ¿cómo deberían esfuerzo y el horario se asignarán a las
diversas actividades de trabajo?
• hitos: ¿qué indicadores de progreso deben ser observados al realizar el
proyecto? cuándo deben producirse?
• Calidad: ¿cuáles son los atributos de calidad estimado del producto (pre-
parto y post-parto defectos, fiabilidad, seguridad)?
• costo: ¿cuánto será el costo de hacer el proyecto?
• riesgo: ¿cuáles son los problemas potenciales en estos factores estimados?
• nivel de confianza: ¿cuánta confianza tiene en la estimación global?
• los recursos necesarios para mejorar la estimación
Varios niveles de probabilidad para diferentes combinaciones de los parámetros
pueden ser determinados por análisis PERT (capítulo 5), por el análisis de riesgos
(capítulo 9), por la simulación Monte Carlo (este capítulo), y por la evaluación
subjetiva (este capítulo).
Su organización debe tener una plantilla estándar para las estimaciones de
grabación. Debe apoyar registro y comunicación de la información siguiente:
• identificación del proyecto
• número de versión y fecha de estimación
• esfuerzo total estimado
• horario total estimado
• nombre (s) del estimador (s)
• justificación de la estimación (por qué se hizo esta estimación? viabilidad,
estimación inicial, actualización periódica, la actualización no periódico,
etc.)
• Elementos cambiado (por cambios a una estimación)
• cantidad de tiempo y esfuerzo gastado en hacer la estimación
• métodos y herramientas de estimación utilizados
• la base de la estimación para cada método o herramienta utilizada
(promedios de la industria, el juicio de expertos, datos históricos locales,
etc.)
• una lista de suposiciones hechas para cada método o herramienta utilizada
• una lista de restricciones observó al hacer una estimación
• una lista de entradas utilizadas para cada método o herramienta que se utiliza
(por ejemplo, tamaño, PI, MBI, factores de ajuste para SLIM)
• datos de estimación proporcionados por cada método de estimación o de la
herramienta (por ejemplo, el esfuerzo total, horario, los hitos del proyecto, el
esfuerzo para diferentes actividades del proyecto por fase del proyecto,
defectos pre-liberación y post-liberación estimados, fiabilidad estimada en la
entrega del producto, los costes totales del ciclo de vida)
• una serie de estimaciones de esfuerzo, planificación, los recursos, el costo y
la calidad de los atributos asociados con probabilidades para cada método o
herramienta utilizada
• factores de riesgo para el proyecto
• nivel del estimador de confianza en la precisión de la estimación (0 a 10; bajo,
medio, alto)
www.it-ebooks.info
• información, recursos y el tiempo necesario para hacer una estimación
mejorada
www.it-ebooks.info
• Una estimación del proyecto es una proyección del pasado al futuro,

adecuadamente ajustado para tener en cuenta las diferencias entre el pasado
y el futuro.
• Todas las estimaciones se basan en un conjunto de supuestos que deben ser
realizados y un conjunto de restricciones que debe ser satisfecha.
• Los proyectos deben ser re-estima periódicamente a medida que crece la
comprensión y aperi- dicamente a medida que cambian los parámetros del
proyecto.
• El tamaño es la variable principal en la mayoría de los modelos de estimación
de software.
• Las medidas de tamaño más populares son líneas de código de función y
puntos.
• medidas de tamaño externo (ESM) se pueden desarrollar para cada área de
aplicación.
• modelos de estimación pueden ser categorizados como pragmático, basado
en la teoría y basados en regresión.
• modelos de estimación basada en la regresión basada en la teoría y pueden
ser calibrados utilizando datos locales.
• herramientas de estimación de software proporcionan una variedad de
capacidades.
• Las estimaciones deben prepararse usando al menos dos métodos diferentes.
• Las estimaciones deben ser documentados mediante un modelo normalizado.
• SEI, ISO, IEEE, y PMI proporcionan marcos, normas y directrices para las
técnicas de estimación de proyectos (véase el Apéndice 6A a este capítulo).
Referencias
[Albrecht79] Albrecht, AJ Medición de la productividad de desarrollo de aplicaciones.

Actas del Simposio de desarrollo de aplicaciones de IBM, Monterey,
California, octubre de 1979, pp. 83-92.
[BOEHM81] Boehm, B. Software Economía Ingeniería. Prentice Hall, 1981.
[Boehm87] Boehm, B. y W. Royce. TRW COI Ada COCOMO: Definiciones y
refinamientos. Actuaciones del Grupo de Usuarios Tercera Internacional
COCOMO. Soft-Instituto de Ingeniería de mercancías, 1987.
[Boehm02] Boehm, B. et al. Estimación de costes de software con COCOMO II. Prentice
Hall, 2000.
[Brooks95] Brooks, F. El mes laboral mítico. Addison Wesley, 1995.
[CMMI06] SEI. Modelos CMMI® y módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[DeMarco99] DeMarco, T., y T. Lister. Peopleware, 2ª ed. Dorset, 1999.
[Fairley02] Fairley, R. Haciendo estimaciones precisas. IEEE Software. 19 (BER
Noviembre-diciem-): 61-63.
[Fairley07] Fairley, R. La influencia de COCOMO en la educación y la formación de
ingeniería de software. Diario de sistemas y software 80 (agosto de 2007):
pp 1201-1208..
[Forrester61] Forrester, JW Industrial Dynamics. Pegasus Communications, 1961.
[HAMID91] Abdul-Hamid, TK, y Madnick, SE Dynamics Software del proyecto. Aprendiz
www.it-ebooks.info
Hall, 1991.
www.it-ebooks.info
CEREMONIAS 259
Electrónicos, agosto de 2003. [IFPUG] www.ifpug.org.
[Jalote02] Jalote, P. gestión de proyectos software en la práctica. Addison
Wesley, 2002. [Jones86] Jones, método de punto de característica TC El SPR. El software
de productividad Investigación,
Inc., 1986.
[Jones02] Jones, estimación de costos C. Software en 2002. diafonía. Software Technology
Center textuales, junio de 2002.
[Norden63] Norden, P. herramientas útiles para la gestión de proyectos. Operación de
Investigación en Investigación y Desarrollo, editado por BV Dean. Wiley,
1963.
[PMI04] PMI. Una guía para la Dirección de Proyectos del Conocimiento, 3ª ed. (Guía del
PMBOK®) del Project Management Institute, 2004.
[Putnam92] Putnam, L., y W. Myers. Medidas para la Excelencia. Yourdon Press,
1992. [Sack68] Sackman, H., W. Erikson, y E. Grant. exploratoria Experimental
Estudios
Comparando on-line y el rendimiento fuera de línea. Comunicación de la
ACM. 11
(Enero de 1968). pp. 93-105.
[Symons88] Symons, CR punto de función de análisis: Dificultades y mejoras.
Transacciones de IEEE en Ingeniería de Software. 14 (enero de 1988). pp.
2-11.
URL
[COSMIC1] www.cosmicon.org.
[COSMIC2] www.cosmicon.com/advantagecs.asp.
[Coestrella] www.softstarsystems.com.
[Cristal] www.decisioneering.com.
[IFPUG] www.ifpug.org
[Madachy01] www-rcf.usc.edu/ madachy/sd/sd.html.
[PRECIO] www.pricesystems.com/products/true_s_price_s.asp.
[USC] http://sunset.usc.edu/research/COCOMOII/index.html.
CEREMONIAS
6.1. Al hacer una estimación, un factor de ajuste se aplica típicamente a la cuenta de

la complejidad relativa del producto. Explicar el significado de “relativa
complejidad.”
6.2. principio de estimación de 1 indica que los datos históricos de algún tipo es
necesario estimaciones de las marcas. Explica cómo puede ir sobre la
fabricación de una estimación para un nuevo tipo de sistema para el cual no
hay datos históricos.
www.it-ebooks.info
6.3. Explicar la diferencia entre un supuesto y una restricción.
www.it-ebooks.info
6.4. Explique brevemente cómo se podría derivar un factor de conversión de

puntos de función de líneas de código.
6.5. Lista de las formas en que las medidas de tamaño externas son superiores a
las líneas de código para medir el tamaño del producto.
6.6. Enumerar las formas en que los pasos en la barra lateral “Desarrollo de un
Tamaño de la medida externa” podrían haber sido utilizadas para
desarrollar la medida de puntos función del tamaño del producto.
6.7. Brevemente explique la diferencia entre una regla de estimación de pulgar y
una analogía estimación.
6.8. Explica cómo representa el modelo de estimación SLIM para los factores
enumerados en la figura 6.1; Es decir, cómo son los atributos del producto,
restricciones del proyecto, las experiencias pasadas, factores de ajuste, y los
supuestos en cuenta en el modelo SLIM?
6.9. En relación a la Tabla 6.3, el texto establece que la probabilidad conjunta de
completar el proyecto en 24 meses con 500 personas-mes de esfuerzo es más o
menos 81% (0,87 0,93). ¿Qué suposición está involucrado en la fabricación
de este cálculo estadístico?
6.10. La herramienta de estimación SLIM calcula el tiempo mínimo, estimado
máximo esfuerzo. Además, el tiempo máximo y mínimo esfuerzo se pueden
especificar como limitaciones.
a. Explique brevemente por qué es posible que desee a la restricción del
tiempo máximo para un proyecto.
b. Explique brevemente por qué es posible que desee a la restricción del
esfuerzo mínimo para un proyecto.
6.11. Explica cómo representa el modelo de estimación COCOMO81 para los
factores enumerados en la figura 6.1; Es decir, cómo son los atributos del
producto, restricciones del proyecto, experiencias pasadas, factores de
ajuste, y los supuestos en cuenta en COCOMO81?
6.12. El exponente b en la ecuación de tamaño esfuerzo de modelos de
estimación basada en regresión a veces se calcula para que sea mayor que 1
(diseconomy de escala) y a veces calculado a ser inferior a 1 (economía de
escala).
a. ¿Qué factores que explicaría por qué b es mayor que 1 para algunos
conjuntos de datos históricamente Cal?
b. ¿Qué factores que explicaría por qué b es menor que 1 para algunos
conjuntos de datos históricos?
6.13. En muchos modelos de estimación el exponente en la ecuación que
relaciona la duración horario para esfuerzo está en el intervalo de 0,3 a 0,5.
Por ejemplo, la relación raíz cuadrada (es decir, exponente = 0.5) establece
que un proyecto de tamaño 16 requeriría 4 unidades de duración mientras
que un proyecto de tamaño 25 requeriría sólo 5 unidades de duración. ¿Qué
factores que explicaría esta relación; es decir, ¿por qué los proyectos que
requieren más esfuerzo toma proporcionalmente menos tiempo que los
proyectos que requieren proporcionalmente más esfuerzo?
www.it-ebooks.info
CEREMONIAS 261
6.14. ¿Cuál de los factores de coste que figuran en la Tabla 6.4 puede no afectar a
una estimación (es decir, tendrían valores de esfuerzo multiplicador de 1) al
ajustar por las diferencias en el esfuerzo y el horario de duración para
proyectos en una organización estable que desarrolla software cliente-
servidor basado en Web ?
6.15. Lista, y explicar brevemente tres conductores adicionales de costos se puede
agregar a la tabla
6,4 a explicar las diferencias en el esfuerzo y la duración periodicidad de
algunos proyectos de software.
6.16. Usando la Tabla 6.4, se calcula la variación en una estimación esfuerzo que
puede ser causada por el establecimiento de la primera todo el personal de
atributos a muy bajo y luego poner a muy alta.
6.17. En la figura 6.14 el multiplicador esfuerzo SCED para la compresión de la
programación para el 75% de Toptar es 1,23; sin embargo, el aumento requerido
en el personal es 1,64. Demostrar por cálculo, y explicar con palabras, ¿por qué
hay una diferencia entre el incremento en el esfuerzo y el aumento de personal.
6.18. En el texto se usa el término “equivalente a tiempo completo” (FTE). ¿Cuál
es el significado de equivalente a tiempo completo?
6.19. Al calibrar un modelo de estimación, usted debe tratar de encontrar un
conjunto realista de parámetros para el modelo que produce aceptablemente
pequeñas variaciones entre los valores estimados y los valores reales de los
proyectos terminados.
a. ¿Qué es una variación de “aceptablemente pequeño”?
b. ¿Cuál es el significado de “un conjunto de parámetros realistas?”
www.it-ebooks.info
ANEXO 6A
Marcos, estándares y directrices para la

estimación
6A.1 OBJETIVOS y prácticas de la CMMI-DEV-v1.2 PROYECTO área de

planificación proceso de estimación
CMMI-DEV-v1.2 incluye estimación como objetivo específico 1 (CE 1) del área de

proceso de la Planificación del Proyecto. SG 1 tiene 4 prácticas específicas
[CMMI06]:
SG 1 Establecer estimaciones
SP 1.1 Estimar el alcance del proyecto
SP 1.2 Establecer las estimaciones del producto de trabajo y la
tarea atributos SP 1.3 Definición del ciclo de vida del proyecto
SP 1.4 Determinar las estimaciones de
esfuerzo y áreas de proceso de costes relacionados
en los modelos CMMI son:
• desarrollo de requisitos,
• la gestión de riesgos, y
• solución técnica.
En la mayoría de los casos los requisitos (características del producto y los

atributos de calidad) se especifican y un calendario, un conjunto de recursos, y un
presupuesto se estiman, según lo indicado por las prácticas específicas
mencionadas anteriormente. Pero a veces las limitaciones son un calendario, un
conjunto de recursos, y un presupuesto (tiempo, esfuerzo, otros recursos y
dinero), y se estima que las características del producto y los atributos de calidad
que se pueden desarrollar dentro de esos límites.
www.it-ebooks.info
262
www.it-ebooks.info
Sección 7.1.2.1 de 12.207,0 [IEEE12207] establece que los planes de gestión deben
incluir:
• horarios para la realización de las tareas,

• estimaciones de esfuerzo,
• los recursos necesarios para llevar a cabo las tareas, y
• los costos de la ejecución de los planes.
Anexo G.9 de 12207.0 establece que un proceso de gestión debe:
• definir el ámbito de trabajo, y

• identificar, tamaño, estimar y planificar las tareas y los recursos necesarios
para realizar el trabajo.
El numeral 5.5.1 de la norma IEEE 1058-1998 para los planes de gestión de

proyectos de software indica que un plan de estimación debe ser un elemento de
un plan de proyecto [IEEE1058]. De acuerdo con el numeral 1058 deberá
especificar:
• costo y cronograma para el proyecto;

• métodos y herramientas que se utilizan para hacer la estimación;
• la base de la estimación; y
• frecuencia de, y las formas en las cuales se harán re-estimaciones periódicas.
La Guía PMBOK del Project Management Institute incluye estimación como un

elemento de zonas de los bordes de la administración de costos de gestión del
tiempo de Proyectos y knowl- [PMI04]:
Proyecto de gestión del tiempo

• la estimación de recursos de actividad
• estimación de duración de la actividad
• gestión de los costes
del proyecto el desarrollo

del cronograma
• estimación de costos
• presupuesto de costes
www.it-ebooks.info
7
DE MEDIDA productos de trabajo
Cuando se puede medir lo que está hablando, y expresarlo en números, sabes algo al
respecto; pero cuando no se puede medir, cuando no se puede expresar en números,
su conocimiento es de una clase pobre e insatisfactorio; puede ser el principio del
conocimiento, pero apenas tienen en sus pensamientos avanzado hasta el estado de
la ciencia, cualquiera que sea el asunto puede ser.
-Señor Kelvin
7.1 INTRODUCCIÓN A EQUIPOS DE MEDIDA productos de

trabajo
La gestión de un proyecto de software consiste en la planificación y la

estimación, medición permite realizar un control, coordinar y dirigir y gestionar
el riesgo. Una de las razones que usted debe hacer planes y presupuestos para tu
proyecto es proporcionar metas objetivas contra la cual se puede determinar el
progreso del trabajo y la calidad de los productos de trabajo. El progreso se mide
mediante la determinación periódica del estado actual de cada atributo y la
comparación de su estado actual al estado previsto. Estado del proyecto se mide
típicamente e informó semanal, quincenal o mensual.
Determinar el estado del proyecto consiste en determinar las relaciones entre
los atributos del proyecto (invertido esfuerzo, el cronograma y costos, y el estado
actual de los productos de trabajo), además de la situación de cada atributo
individual. Es totalmente posible hacer un buen progreso horario, mientras que
gastar más recursos de lo previsto, o para hacer un buen costo y cronograma de
avance al tiempo que las características del producto equivocado o la producción
de productos de trabajo de baja calidad. el estado del proyecto está documentado
en los informes de progreso.

265
www.it-ebooks.info
266 DE MEDIDA productos de trabajo
El propósito del informe de situación es indicar qué factores son los proyectos
según lo previsto, y que necesitan ser investigados para una posible acción
correctiva. Usted debe, por ejemplo, controlar tanto esfuerzo y de costes de
personal. Si, en un período de referencia dado, el esfuerzo es como estaba
previsto, pero el costo de personal es mayor de lo previsto, está utilizando más
caros (más altamente cualificados) los desarrolladores de software de lo previsto;
tal vez el trabajo es más difícil de lo previsto o tal vez el trabajo a realizar por
personal altamente especializado y caro, los diseñadores está tomando más
tiempo de lo previsto.
Por el contrario, si en un período de referencia dado, el esfuerzo es como
estaba previsto, pero los costes de personal son más bajos de lo previsto, puede
ser que haya podido adquirir los niveles necesarios de habilidad (no es bueno) o
tal vez el trabajo es más fácil de lo previsto y altamente no se necesita personal
especializado (muy bien pagados) (bueno). Si el esfuerzo y el coste están a
menos de lo previsto, esto puede indicar que usted no ha sido capaz de adquirir el
número previsto de los desarrolladores de software y, como consecuencia, el
progreso horario es más lento de lo previsto. O bien, puede ser que el esfuerzo y
el coste son más altos de lo previsto debido a un deseo de acelerar el progreso
horario. Otros costos también deben ser medidos y comparados con el plan. costo
del viaje puede ser mayor (o menor) que planificada; costos de equipo se pueden
desviar de manera similar de plano. En cualquier caso, tendrá que investigar estas
desviaciones del plan.
El control del proyecto se ejerce mediante la aplicación de medidas correctivas
cuando una o más dimensiones del progreso se desvían de plan de más de una
cantidad aceptable o cuando las relaciones entre los atributos del proyecto se
desequilibra; por ejemplo, un retraso de dos días en la consecución de un hito
importante no puede requerir acción correctiva sino siendo dos semanas de
retraso puede constituir un retraso inaceptable para el que se debe tomar una
acción correctiva. Del mismo modo una saturación del 2% de la memoria
asignada para una construcción incremental del software integrado puede ser
aceptable, pero un exceso del 20% no es probable.
Dependiendo de la naturaleza de la desviación del plan de acción correctiva
puede incluir uno o más de
• la adición de más recursos,
• el uso de recursos superiores,
• la mejora de diversos elementos del proceso de desarrollo,
• la mejora de la tecnología, y / o
• de-la determinación del alcance del producto.
Recursos que deben mejorarse, añadido, o reemplazados incluyen personas

(siendo consciente de la ley de Brooks), componentes de software (por ejemplo,
la reingeniería de un componente para mejorar el rendimiento), componentes de
hardware (por ejemplo, más memoria, un procesador más rápido), y herramientas
de software (por ejemplo, un procesador de lenguaje o herramienta de prueba).
Descoping el producto puede ser consumado con gracia si ha priorizado los
requisitos y si está utilizando un proceso de desarrollo iterativo mediante el cual
se han puesto en práctica las características más importantes en primer lugar. Si
la fecha de entrega es con- tensa, es posible que sea aceptable para entregar un
subconjunto de los lazos más altos capabili- prioridad a tiempo con la entrega de
una versión con todas las características posterior prevista para una fecha
www.it-ebooks.info
posterior, negociado.
Por supuesto, hay que tener en cuenta las compensaciones involucradas en las
acciones correctivas; por ejemplo, cambiar el proceso de prueba o la adición de
una nueva herramienta de prueba puede aumentar
www.it-ebooks.info
7.1 INTRODUCCIÓN A EQUIPOS DE MEDIDA productos de trabajo 267
el número de defectos detectados en el largo plazo, pero puede tener un impacto

inaceptable en su horario, que resulta del tiempo necesario para aprender y
asimilar el nuevo proceso o herramienta.
El modelo de flujo de trabajo representada en la figura 1.1 (Capítulo 1), y se
repite aquí como Figura 7.1, ilustra las funciones de medición y control en el
modelo de flujo de trabajo de proyectos de software. Los circuitos de
retroalimentación de la medición, la notificación, la replanificación y el control
están resaltados en la Figura 7.1.
La relación entre la acción correctiva y la gestión del riesgo se examina el
Capítulo 9. En resumen, un riesgo es un problema, un problema potencial que no
ha sucedido todavía, pero tiene una probabilidad no nula de que ocurra; Si eso
sucede, su impacto será negativo en la consecución de un resultado exitoso. En la
gestión de riesgos, se identifican los problemas potenciales, indicadores objetivos
son monitoreados, y se inicia un plan predeterminado de la acción correctiva
cuando un indicador de riesgo cruza un umbral predeterminado (el gatillo
problema).
Al planear, estimar, medir y controlar un proyecto de software, se le prac-
tiquen la gestión del riesgo institucional. La gestión del riesgo está
institucionalizada porque, a través de la experiencia, hemos aprendido que la
planificación sistemática, estimar, medir y controlar un proyecto de software
aumenta la probabilidad de un resultado ful éxito-; dicho de otra manera, es
mejor planear, estimar, medir y control que de no hacerlo. Medición y control del
esfuerzo, horario, costo, características del producto y los atributos de calidad es
por lo tanto una forma de gestión de riesgos; Sin embargo, hay otros aspectos de
la gestión del riesgo, tal como se explica en el capítulo 9, que aumentan la
planificación sistemática, la estimación, medición y control que debe ejercer
sobre sus proyectos de software.
Es posible, aunque no es muy probable, que puede ser capaz de entrega de un
producto aceptable y sin planificación, estimación, medición, o el control. El
coste de la planificación, estimación, medición y control, al igual que el coste de
la gestión de riesgos, es una inversión que realice para aumentar la probabilidad
de éxito. Al igual que el riesgo
requisitos
Proceso
Cliente Planificación Asigna

y Definició Independient
n de las ciones e
Los replanificac de
Actividad V&V
gestores ión trabajo
es Seguro de entregad
directivas y o
la estimación y producto
Re-estimar Configuración s de
Controlador
administración trabajo
Retenció
n de ..........
datos . . ... . .

problemas
Figura 7.1 Un modelo de flujo de trabajo para proyectos de software con énfasis en la
medición, presentación de informes, la nueva planificación y control
www.it-ebooks.info
la gestión, la cantidad que se invierte en la planificación, estimación, medición y

control- ling debe equilibrarse con el costo de no entregar un producto aceptable
a tiempo y dentro del presupuesto.
En este capítulo se presentan los métodos y técnicas para la medición y control

de los productos de trabajo. Medición y control del esfuerzo, el horario, y el costo
se presentan en el Capítulo 8. Después de leer este capítulo y completar los
ejercicios que usted debe entender:
• medidas y escalas de medida;

• medidas de productos para diferentes tipos de productos de trabajo;
• el papel de la gestión de la configuración en la medición y el control de los
• el papel de las inspecciones, tutoriales y pruebas de desarrollador;
• medidas de la complejidad de software;
• medidas de fiabilidad y disponibilidad;
• la detección de defectos y el proceso de reparación;
• maneras de documentar y analizar los defectos y las reparaciones de defectos;
• directrices para la elección de las medidas de productos; y
• fuentes de normas y directrices para la medición y control.
Los cuatro conjuntos de normas y directrices para la gestión de proyecto que se

presenta en este texto, es decir, el marco de proceso de CMMI-DEV-v1.2, la norma
ISO / IEEE 12207, el estándar IEEE 1058, y el cuerpo del PMI del Conocimiento de
medición y control de la dirección del trabajo productos en diversos grados. Aspectos
de la medición y el control de estos documentos se presentan en el Apéndice 7A a
este capítulo. En adi- ción del Software Práctico y enfoque de los sistemas de
medición (PSM) se presenta en el Apéndice; una visión general de PSM se
proporciona en la Sección 7.8 de este capítulo.
7.3 ¿Por qué medir?
Hay varias razones por las que debe medir varios atributos de sus proyectos de
software:
• para proporcionar indicadores frecuentes de progreso (o falta del mismo),

• para proporcionar una alerta temprana de problemas,
• para permitir el análisis de las tendencias para su proyecto,
• para permitir que las estimaciones del coste y la finalización fecha final de su
proyecto, y
• para construir un repositorio de datos de historias de proyectos para su
organización.
www.it-ebooks.info
7.4 Qué se debe medir? 269
La frecuencia de la medición puede variar de día, por ejemplo, en contando el

número de casos de usuario implementado por medio de un proceso de desarrollo
ágil; a la semana, por ejemplo, en contar el número de casos de uso de escenarios
implementados utilizando un proceso de desarrollo incremental y construcción; al
mes, por ejemplo, en conde-ing el número de elementos de diseño implementados
en un proceso de cascada. Los equipos pueden reunirse brevemente cada día para
revisar las áreas de progreso y problemas; jefes de equipo y usted, el director del
proyecto, podrán reunirse semanalmente para revisar el proyecto y cumplir cada
mes para planificar los detalles de la obra del mes que viene. Usted, el director del
proyecto, y algunos de su personal clave puede reunirse con la dirección superior
y con los clientes sobre una base mensual para revisar el progreso e identificar las
áreas problemáticas. la medición frecuente de estado proporciona una alerta
temprana de problemas cuando el estado real no coincide con el estado planeado.
La identificación temprana de problemas es deseable debido a problemas son más
fáciles de solucionar cuando se identifica temprano, es decir, antes de que los
defectos en los productos de trabajo pueden propagarse en los productos de trabajo
posteriores. Recolección de información de estado sobre una base periódica apoya
predicción de tendencias en los atributos del proyecto, tales como defectos, el
costo y horario. Si, por ejemplo, su proyecto se determina que es dos semanas de
retraso, y si se estima que el proyecto sea completado la mitad, y si se sigue
avanzando al ritmo actual, el proyecto será de cuatro semanas de retraso en pletion
com-. Los “si” en el ejemplo anterior son factores que deben ser monitorizados
continuamente La identificación temprana de problemas es deseable debido a
problemas son más fáciles de solucionar cuando se identifica temprano, es decir,
antes de que los defectos en los productos de trabajo pueden propagarse en los
productos de trabajo posteriores. Recolección de información de estado sobre una
base periódica apoya predicción de tendencias en los atributos del proyecto, tales
como defectos, el costo y horario. Si, por ejemplo, su proyecto se determina que es
dos semanas de retraso, y si se estima que el proyecto sea completado la mitad, y
si se sigue avanzando al ritmo actual, el proyecto será de cuatro semanas de
retraso en pletion com-. Los “si” en el ejemplo anterior son factores que deben ser
monitorizados continuamente La identificación temprana de problemas es
deseable debido a problemas son más fáciles de solucionar cuando se identifica
temprano, es decir, antes de que los defectos en los productos de trabajo pueden
propagarse en los productos de trabajo posteriores. Recolección de información de
estado sobre una base periódica apoya predicción de tendencias en los atributos
del proyecto, tales como defectos, el costo y horario. Si, por ejemplo, su proyecto
se determina que es dos semanas de retraso, y si se estima que el proyecto sea
completado la mitad, y si se sigue avanzando al ritmo actual, el proyecto será de
cuatro semanas de retraso en pletion com-. Los “si” en el ejemplo anterior son
factores que deben ser monitorizados continuamente Recolección de información
de estado sobre una base periódica apoya predicción de tendencias en los atributos
factores que deben ser monitorizados continuamente Recolección de información
de estado sobre una base periódica apoya predicción de tendencias en los atributos
factores que deben ser monitorizados continuamente
www.it-ebooks.info
y actualizada.
Como se indica en el Capítulo 6, todas las estimaciones son proyecciones
desde el pasado hasta el futuro, adecuadamente ajustadas para tener en cuenta las
diferencias entre el pasado y el futuro. compañeros de cálculo basado en los datos
locales serán más precisas que las estimaciones basadas en las reglas de las
medias del pulgar o de la industria. Una razón importante para la medición es por
lo tanto la construcción de un repositorio de datos en el que se estima para
proyectos futuros pueden basarse. En el análisis de adición de datos de proyectos
recogidos en toda su organización puede revelar problemas comunes y
recurrentes que deben abordarse a nivel de organización. Por ejemplo, el análisis
podría mostrar que para la mayoría de los proyectos, un gran porcentaje de
defectos totales son en las interfaces entre los módulos de código. La mejora de
la formación y herramientas para el diseño de interfaces podría reducir
significativamente el total de defectos en los productos de software de la
organización.
7.4 Qué se debe medir?
Los atributos que medir y controlar dependen de los criterios de éxito para su
proyecto: la fiabilidad y el rendimiento del software suministrado puede ser el
criterio más importante de éxito, o puede ser que el control de la programación y
el costo del proyecto es el más supremo. Sin embargo, es difícil imaginar un
proyecto para el que un cierto nivel de medición y control sobre cada uno de los
siguientes atributos no es importante para un resultado exitoso:
• esfuerzo: cantidad de trabajo empleado para diversas actividades de trabajo

• horario: logro de los hitos objetivamente medidos
• costo: los gastos para los diversos tipos de recursos, incluyendo el esfuerzo
• el progreso: los productos del trabajo completado, aceptadas y baselined
• Características del producto: requisitos implementados y demostraron que
trabajar
www.it-ebooks.info
• atributos de calidad del producto: defectos, fiabilidad, disponibilidad, tiempo

de respuesta, rendimiento, y otros como se especifica
• riesgo: estado de los factores de riesgo y medidas de mitigación
Típicamente los atributos de proceso (esfuerzo, calendario, coste, y el

progreso) son equilibrado contra los atributos del producto (características y
atributos de calidad). Entre los atributos de proceso, horario puede (o no) sea más
importante que el esfuerzo o coste, y la seguridad puede ser un atributo del
producto más importante que el rendimiento. En función de la importancia
relativa de los diversos atributos de proceso y producto, más esfuerzo se puede
gastar en la medición y el control de algunos de los atributos que en medir y
controlar a los demás.
medidas de producto y proceso son, o deberían ser, subproductos de los
procedimientos, métodos, herramientas y técnicas utilizadas para el desarrollo de
software; si no, los procesos de desarrollo y de gestión deben ser mejorados. El
exceso de tiempo, esfuerzo y costo invertido en obtener, analizar y actuar sobre
las medidas de producto y de proceso es un síntoma de los procesos de desarrollo
y de gestión ineficaces.
7.5 MEDIDAS Y MEDICIÓN
Una medida es el símbolo asignado a algún atributo de un fenómeno en el mundo

real; por ejemplo, usando números enteros o números reales símbolos para medir
la temperatura. surement Measure es el proceso de asignar algún atributo de un
fenómeno en el mundo real a un conjunto de símbolos para los que se especifican
operaciones bien definidas; por ejemplo, la temperatura de asignación a una
escala de medición Celsius, Fahrenheit o Kelvin. diferentes tipos de escalas de
medición permiten diferentes tipos de operaciones; por ejemplo, 40 grados
Celsius o Fahrenheit es más caliente que 20 grados Celsius o Fahrenheit debido a
que la operación de relación “más caliente que” (es decir, mayor que) está
permitido, pero no podemos decir que 40 grados es dos veces más caliente como
20 grados en estas escalas PORQUE Relación de operaciones no son válidos para
estas medidas (más tarde).
Hay cinco escalas de medición comúnmente utilizados: nominal, ordinal,
intervalo, ratio, y absoluta. Estas escalas proporcionan una jerarquía de
operaciones permitidas. La jerarquía, en base a las características de cada escala,
se presenta en la Tabla 7.1.
Una escala nominal asigna artículos a grupos o categorías. Es posible, por
ejemplo, una lista de la cantidad de personal en cada una de varias categorías:
análisis y diseño, implementación, pruebas, formación de usuarios, y así
sucesivamente. O bien, puede enumerar el número de instalaciones de sus
sistemas según la región o el país. El número de elementos en cada categoría se
puede contar para proporcionar distribuciones de frecuencias entre las categorías,
pero sin orden de los elementos dentro de una categoría está implícito. Por
ejemplo, su proyecto podría tener 12 implementadores y 5 probadores; se puede
decir que hay 7 más que los ejecutores de los probadores, pero nada se puede
decir sobre la clasificación de los niveles de habilidad de los ejecutores o los
probadores si está utilizando una escala nominal.
Las medidas basadas en los símbolos que forman una secuencia ordenada, tales
como (bajo, medio, alto) escalas de forma ordinal. Los niveles de habilidad o la
complejidad del programa pueden ser medidos utilizando los símbolos (bajo, medio,
alto) con las operaciones relacionales transitivos permitidos de menor que, mayor
www.it-ebooks.info
que, e igual ( , , =) definida en el conjunto {bajo, medio, alto }. Los intervalos
entre símbolos adyacentes no se especifican para medidas ordinales, y hay no es
determinaron objetivamente elemento cero; por lo tanto nos
www.it-ebooks.info
7.5 MEDIDAS Y MEDICIÓN 271
TABLA 7.1 Jerarquía de las escalas de medición

ScaleCharacteristics
distribuciones NominalFrequency entre medición categorías
OrdinalOrdering dentro de las categorías; intervalos arbitrarios entre las medidas
IntervalEqual intervalos entre las medidas; determinada arbitrariamente elemento
cero RatioEqual intervalos entre las medidas; objetivamente determinado elemento
cero AbsoluteSimilar relación pero con singularidad de medidas
no se puede decir que un programa de alta complejidad es 3 o 5 o 10 veces más

complejo que un programa de baja complejidad, si estamos utilizando una escala
ordinal. Sin embargo, transición tiva operaciones relacionales se pueden aplicar si los
símbolos forman una secuencia ordenada, así que un programa de baja complejidad
es menos complejo que mediana, que es menos compleja que la de alta, y dos
programas de complejidad media son de complejidad comparable. Por la propiedad
de transitividad, el módulo A es menos complejo que el módulo C si el módulo A es
menos complejo que el módulo B y el módulo B es menos complejo que el módulo C
o si el módulo B tiene la misma complejidad que el módulo C (tenga en cuenta la
precedencia entre los “y ”y‘o’operadores en esta frase). El valor Baja, Media o Alta
podría determinarse para un programa o un módulo usando criterios subjetivos.
Cuando se utiliza una escala ordinal, los elementos dentro de una categoría
están clasificadas. Símbolos más altos en el ordenamiento indican valores más
grandes, pero los intervalos entre los símbolos no se puede suponer que ser
iguales. Por ejemplo, un desarrollador de software de alta puntuación en la
capacidad no es necesariamente 3 veces tan capaz como un desarrollador
puntuación baja en la capacidad. El punto cero en una escala ordinal, si existe, se
elige arbitrariamente; por ejemplo, una escala de capacidad de (1, 2, 3)
equiparado a baja, media, alta podría igualmente hacerse a escala como (0, 4, 6);
vea el recuadro “El mal uso de las escalas de medición” en los peligros del uso de
números enteros como las medidas de una escala de medición ordinal.
Las medidas basadas en símbolos que tienen intervalos iguales entre dos
símbolos adyacentes pero que tengan un determinado arbitrariamente elemento
cero escalas de intervalos forma. En una escala de medición de intervalo de una
unidad de medida representa la misma magnitud de un factor de toda la gama de
la escala. Por ejemplo, en la escala de temperatura Celsius o Fahrenheit la
diferencia entre 30 y 40 grados es la misma que la diferencia entre 50 y 60 grados
(10 grados en cada caso). Sin embargo, el punto cero en estas escalas no denota
la ausencia de temperatura (es decir, no está objetivamente determinado) y los
coeficientes no puede formarse. Por lo tanto una temperatura de 60 grados
Celsius o Fahrenheit no es dos veces tan caliente como una temperatura de 30
grados.
Daniel Fahrenheit inventó el termómetro de mercurio en 1714 después de
descubrir que el mercurio tiene un factor de expansión / contracción lineal en un
amplio intervalo de temperatu- ras, lo que es un elemento adecuado para la
construcción de los termómetros de vidrio con marcas lineales en el cristal. Sr.
Fahrenheit estableció tres puntos en su escala de medición: 0 ° F se determinó
como la temperatura de una mezcla de sal, hielo, y agua; 32 ° F se determinó
como la temperatura a la que el agua se congela sin sal; y 96 ° F se determinó que
era la temperatura corporal de una persona adulta saludable. Un cuarto punto de
la escala, 212 ° F, se estableció más adelante como el punto de ebullición del
agua a nivel del mar. Este punto en la escala Fahrenheit recalibrado la
temperatura de un adulto sano de ser 98,6 ° F. señor.
www.it-ebooks.info
Zero grado Fahrenheit es por lo tanto un valor arbitrario, por lo que 0 ° F no

indica la ausencia de la temperatura.
Los números utilizados como puntos de calibración en la escala de
temperatura Celsius son igualmente arbitraria. Sr. Celsius estableció 0 ° C como
el punto de ebullición del agua y 100 ° C como el punto de congelación. La
escala de medición fue posteriormente invierte a la escala ahora- familiarizado
con 0 ° C como el punto de congelación y 100 ° C como el punto de ebullición
del agua a nivel del mar. Las escalas de temperatura Fahrenheit y Celsius son
escalas La medición de intervalo debido a que los intervalos entre medidas son
equidistantes, pero el elemento cero no denota que se mide la ausencia del
fenómeno, es decir, la temperatura.
En teoría de la medición, las medidas que tienen intervalos iguales entre dos
símbolos adyacentes y un elemento cero que indica ausencia de la cantidad que
se mide la forma de una escala de proporción. En las escalas de medición que
utiliza el número entero y medidas de número real, por ejemplo, y que han
determinado objetivamente valores cero, las operaciones relacionales y se
permiten las operaciones aritméticas y las proporciones se pueden formar, como
en la medición del número de estados en un ordenador programa. Debido a que la
medida del tamaño del programa está en unidades de número entero de intervalos
iguales con un elemento objetivamente cero (ausencia de declaraciones), se
puede decir que un programa de 100 declaraciones es dos veces tan grande como
un programa de 50 estados y el tamaño de la programas combinados es de 150
declaraciones.
Tenga en cuenta que la temperatura medida en Kelvin (K) forma una escala
medida de la relación porque el elemento cero es un valor determinado
objetivamente; temperatura en Kelvin es una medida de la energía cinética
asociada con el movimiento de los átomos y cules en moles. El punto de la escala
de temperatura Kelvin cero es la temperatura a la que todos los movimientos a
nivel atómico cesa, lo que significa la ausencia de la temperatura. Por lo tanto 0
K es una medida objetiva y 200 K es dos veces tan caliente como 100 K (es
decir, la energía cinética de los átomos es dos veces más).
Una escala de medición absoluta es uno para el que se permite ratios
(intervalos iguales más una determinaron objetivamente elemento cero que indica
ausencia del fenómeno), además de la singularidad de las medidas. Por ejemplo,
la medición de la densidad de defectos como un número entero de defectos por
línea de código mediante la medición de número total de defectos y dividiendo
por el número de líneas de código forma una escala de medición de relación
porque defectos por línea de código se pueden convertir a los defectos por mil
líneas de código mediante la transformación:
D re
 
KLO 

C
Si, por alguna razón, la transformación monotónica de D / COL se desecharon, la

escala de medición sería un absoluto. Midiendo el tamaño del programa en
puntos de función y desactiva las transformaciones, por ejemplo, en líneas de
código, se formaría una escala de medición absoluta. Dicho de otra manera, la
identidad es la única transformación permitido para una escala de medición
absoluta.
Ordinal, ratio, y las escalas absolutas son las escalas de medición más
comúnmente utilizados en ingeniería de software. la complejidad del programa,
según lo medido por (baja, media, alta), es un ejemplo de una escala de medición
www.it-ebooks.info
ordinal. Medir el tamaño de un programa como un número entero de puntos de
función y transformaciones que realizan
www.it-ebooks.info
de puntos de función a líneas de código forma una escala de medición de relación

porque hay intervalos iguales en ambas medidas, y un programa que no tiene
puntos de función o líneas de código tiene tamaño cero. Midiendo el tamaño del
programa en puntos de función y desactiva las transformaciones forma una escala
de medición absoluta.
Debe tener reglas bien definidas para determinar la asignación del fenómenos
de interés para las medidas que utiliza, como la medición del fenómeno del
tamaño del programa usando las reglas de recuento para contar los puntos de
función o un algoritmo para contar líneas de código. También es importante que
las medidas que utiliza aplicarse de manera uniforme en toda la organización
para que los distintos proyectos se pueden comparar a lo largo de diferentes
dimensiones y para que las tendencias en la organización permita determinar.
Como se suele decir, se desea comparar manzanas con manzanas (es decir,
defectos de defectos) y no manzanas con naranjas por pensando erróneamente las
naranjas son también las manzanas (es decir, por error comparando defectos en
un solo producto a los cambios de requisitos en otro producto).
Si usted está contando líneas de código, por ejemplo, desea que cada proyecto
para el recuento de la misma manera:
• hacer punto y coma delimitan “líneas?”

• terminan de línea símbolos delimitan líneas?
• puedo incluir comentarios?
• Cómo se cuentan una rutina de biblioteca como el 1-línea “incluir” estado de
cuenta o como las líneas equivalentes de código en el cuerpo de la rutina
incluido?
• ¿cómo se cuentan las líneas modificadas de los códigos que se reutilizan de
otros programas de software?
¿Cómo se cuentan los defectos?
• lo que constituye un defecto (por ejemplo, un error de sintaxis durante la

compilación? una caída del sistema durante la validación del sistema)?
• ¿tiene una forma de clasificar los defectos (por ejemplo, los datos, el cálculo,
la interfaz)?
• ¿Cómo caracteriza la gravedad de los defectos (por ejemplo, menor, mayor,
catastrófica)?
A medida directa se obtiene mediante la aplicación de sus reglas de medición

directamente al fenómeno de interés; por ejemplo, contando las líneas de código
en un programa de ordenador utilizando reglas de conteo bien definidos. Una
medida indirecta se obtiene por medidas directas Bining com- utilizando
operaciones apropiadas para que la escala de medición. Por ejemplo, el número
de puntos de función en un programa es una medida indirecta que se determina
mediante la aplicación de las reglas de punto de recuento de función para
determinar el número único (número entero) de entradas, salidas, archivos,
interfaces y consultas en el programa; multiplicando cada por un factor entero
complejidad; y la adición de los resultados juntos. Tablas 7.3 y 7.4 proporcionan
ejemplos de medidas directas e indirectas utilizadas en la ingeniería de software.
Nota en la Tabla 7.3 que “número de defectos fijos” podría ser medido como
una medición “progreso” o como medida de la “calidad”, o ambos, y que
“semana adoptadas para lograr un hito” se podrían utilizar para medir “progreso”
o “tiempo”, o ambas cosas.
www.it-ebooks.info
MAL USO DE escalas de medición
Hay que tener cuidado de que la escalas de medición que utiliza son
apropiados para la situación y se utilizan adecuadamente. Por ejemplo, una
determinación subjetiva de (baja, media, alta) puede ser una caracterización
suficiente de la complejidad del programa para sus propósitos, con base en los
criterios para la determinación de la calificación de la complejidad de un
programa o módulo, pero no se puede sumar, restar, multiplicar, o dividir
estos símbolos. Por desgracia, esto se hace a veces igualando Menor a 1, de
medio a 2, y mayor a 3 o algunos otros valores numéricos ascendente.
Equiparar Menor a 1 y de mayor a 3 y a continuación, aplicar operaciones
aritméticas implica que un módulo de programa de alta complejidad es 3 veces
tan complejo como un módulo de baja complejidad.
Mi ejemplo favorito del mal uso de las escalas de medición es la forma en
que las clases y los profesores son clasificados por evaluaciones de los
estudiantes en muchas escuelas. En estos casos una escala ordinal se utiliza a
menudo y tratado como si fuera una escala de proporción. Por ejemplo, los
estudiantes a menudo se les pidió que calificaran diversos atributos de una
clase o el instructor mediante la comparación de la clase o instructor a otras
clases o profesores que han tenido en una escala de (Mucho peor, peor, Same,
mejor, mucho mejor). Estas clasificaciones son entonces equipararse a (1, 2, 3,
4, 5). Esto implica que un profesor que recibe una calificación de mucho
mejor (equiparado a 5) está clasificado como 1.67 mejor que un profesor que
recibe una calificación de Same (equiparado a 3).
No se proporcionan criterios objetivos para determinar las calificaciones,
por lo que cada estudiante solicita su calificación subjetiva basada en sus
gustos, disgustos, las experiencias pasadas, y la calificación que esperan
recibir en la clase. clasificaciones individuales de los estudiantes son entonces
(incorrectamente) suman y la suma se divide por el número de respuestas para
producir calificación promedio del profesor para cada atributo medido. Peor
aún, todas las respuestas promediadas se promedian para proporcionar una
“calificación” global de la clase o profesor. Utilizando esta escala nominal, es
incorrecto decir, por ejemplo, que la calificación global del profesor Fairley
para todos los catego- rías respuesta es 4.2, ni se puede decir que el profesor
Fairley es 80% tan eficaz como el profesor Willshire, que recibió una
calificación general de 4.7 .
TABLA 7.2 Las respuestas a una encuesta de evaluación del curso

En comparación con otros Much
instructores que haya tenido, era Mucho peor Peor Mism Mejor o
que el instructor: o mejor
¿Experto? 5 10
¿Bien preparado? 4 11
Responde a las preguntas? 3 12
ella eran / sus tareas relevantes? 7 5 3
Eran sus / sus preguntas del 9 6

examen apropiado?
Fueron los materiales devueltos 4 11
de manera oportuna graduada?
www.it-ebooks.info
La forma correcta de presentar los datos nominal es hacer una lista en una
tabla, un histograma, o un gráfico de sectores el número de respuestas en cada
nivel de calificación para cada atributo evaluado como, por ejemplo, en la
Tabla 7.2. El número de respuestas total en cada nivel de clasificación puede
ser contado y la (menor que, igual a, y mayor que) operadores relacionales se
pueden utilizar para comparar categorías; por ejemplo, el profesor Fairley
recibió calificaciones más excelente capacidad de respuesta a las preguntas
que para las asignaciones pertinentes. Además, la escala de razón número
entero se puede usar para comparar el número de respuestas en cada categoría
y para calcular porcentajes; por ejemplo, 67% de las respuestas eran
excelentes para conocedor del material. Pero es incorrecto decir que una
calificación excelente es 5/4 mejor que una buena calificación.
Podemos utilizar las escalas ordinales cuando no tenemos un objetivo, de
acuerdo-a, se utiliza el método de determinación de los intervalos entre los y
las relaciones entre los valores individuales de la medida. Las medidas de
evaluación de un programa de baja complejidad combinarse con un programa
de alta complejidad, por ejemplo, tendrán como resultado una alta
complejidad ityrating, basedonthetransitivepropertiesofthe (baja, media, alta)
medida de complejidad; Alta complejidad es más compleja que la complejidad
media o baja, pero no podemos decir por la cantidad: la calificación de la
TABLA 7.3 Algunas
complejidad medidas
no es 4 (1 +directas
3).
Medidas MeasurementsDirect
Software sizeLines de código
Número de personal por Número de programadores; número de probadores
categoría
ProgressNumber de baselined requisitos; número cambiado; número de módulos
baselined; número de defectos encontrados; número de
defectos fijos; semanas para lograr un hito
Recurso usageCPU ciclos utilizados; bytes de memoria utilizadas
TimeWeeks adoptarse para alcanzar una hito
QualityNumber de defectos fijos; de respuesta del equipo hora
TABLA 7.4 Algunas medidas indirectas

Medidas MeasurementIndirect
SizeFunction puntos
ProductivityLines de código desarrollado por desarrollador meses; puntos de
función implementadas por el programador semanas
Producción rateLines de código por mes; puntos de función por semana
Pruebas rateTests realizado por El personal del día
Defecto densityDefects por cada mil líneas de código; defectos por punto de
función
Defecto efficiencyNumber de defectos fijos por El personal del día
Defecto effectivenessNumber de defectos detectado totales Requisitos / defectos
número / número inicial stabilityCurrent; corriente / número mayor
número
reciente
Costos de rendimiento indexActual costo / presupuestado costo
www.it-ebooks.info
De una medida depende del uso deseado de la medida; y una medida puede
encajar en más de una categoría.
Tenga en cuenta también que el tamaño medido como líneas de código es una
medida directa (tabla 7.3) y que el tamaño medido como puntos de función es una
medida indirecta (Tabla 7.4). Como se indica en la Tabla 7.4, la productividad es la
cantidad de salida producida por unidad de recurso, mientras que la tasa de
producción es la cantidad total de la producción en un período de tiempo dado. Un
proceso eficaz es el que lleva a cabo las tareas con un gasto mínimo de recursos. En
la Tabla 7.4 “número de defectos fijos por día personal” podría ser utilizado como
una medida de la productividad y / o como una medida de la eficiencia de fijación
defecto. La medida de la eficacia en la Tabla 7.4 (número de defectos detectados
durante el examen de diseño / defectos totales) podría contar total de defectos como
los detectados antes de la liberación de un producto o la entrega de un sistema para
un cliente, o tal vez número de defectos encontrados durante el desarrollo y los
primeros 6 meses (o 12 meses) de uso operativo. El índice de desempeño de los
costos en la Tabla 7.4 es un elemento de seguimiento del valor ganado, que se discute
en el Capítulo 8.
7.6 MEDICIÓN atributos del producto
Debe comprobar que cada producto de trabajo, ya que se desarrolla, es completa,

correcta y coherente con respecto a otros productos de trabajo. También debe
validar que cada producto de trabajo es apto para su uso en el entorno previsto.
Además, cada tipo de producto de trabajo (requisitos de funcionamiento,
especificaciones técnicas, el diseño arqui- tectural, diseño detallado, el código
implementado, planes de prueba, resultados de pruebas, etc.) proporciona
oportunidades únicas para medir periódicamente la cantidad y la calidad del
producto de trabajo . Las siguientes secciones indican algunos aspectos de
cantidad y calidad que pueden ser medidos y comparados con los valores
especificados o esperados para los diferentes tipos de productos de trabajo.
Selección y adaptación de las medidas de productos se trata en una sección
posterior de este capítulo.
7.6.1 La medición de las necesidades operacionales y Especificaciones Técnicas

Como se discutió en el capítulo 3, hay tres tipos de requisitos operacionales y
cuatro tipos de especificaciones técnicas:
Los requisitos operativos incluyen:
• característica operativa,
Las especificaciones técnicas, que se derivan de los requisitos operativos,

incluyen:
• requisitos primarios,
• requisitos derivados,
www.it-ebooks.info
7.6 MEDICIÓN atributos del producto 277
Las restricciones de diseño y atributos de calidad, como se indica en las

necesidades de funcionamiento, pueden ser vagos e imprecisos pero deben ser
indicado en las especificaciones técnicas de una manera que permite la
verificación objetiva. Las características de los requisitos de funcionamiento y
especificaciones técnicas se presentan en el Capítulo 3.
Los requisitos operativos a menudo se documentaron utilizando una lista
numerada de tos por el estado como:
5. Los terminales ATM se ofrecerá una opción de “dinero rápido” a los clientes.
En términos contractuales, “deberá” indica un requisito vinculante por contrato;

Términos tales como “deben” o “pueden” se pueden utilizar para indicar los
requisitos de no unión; por ejemplo, propiedades deseadas expresan como
objetivos de diseño pueden establecerse usando “debería” o “may”.
Contando el número de “shalls” es una forma de medir el número de
requisitos; sin embargo, algunos requisitos pueden ser menos precisos o menos
detallada que otros. Para dar cuenta de esto, cada uno de los “shalls” debe
evaluarse en una escala surement medi- (por ejemplo, bajo, medio, alto) para
indicar el grado en que cada requisito satisface los criterios de descomposición
presentados en la Sección 5.3 de este texto a saber:
• el requisito es suficientemente precisa y detallada que se identifican las áreas

de incertidumbre, la complejidad, y el riesgo;
• estimaciones del esfuerzo, el cronograma y los recursos necesarios para
implementar el requisito se pueden hacer con confianza; y
• Se identifican oportunidades para la reutilización de los componentes
existentes que pueden ser utilizados para satisfacer el requisito.
Si a evaluar un requisito esencial o deseable ser baja en la satisfacción de los

criterios de descomposición, se debe descomponer aún más ese requisito. Por
ejemplo, el requisito operacional que establece lo siguiente:
3.0 El sistema de caja automatizada proporcionará a las características, el

rendimiento y los atributos de calidad normalmente proporcionada por tales
sistemas.
sería clasificado bajo los criterios de descomposición.

Algunos requisitos implican medidas de calidad. La precisión de estos
requisitos puede ser evaluada por calificaciones asignadas que indican el nivel de
cuantificación. Una calificación de baja cuantificación indicaría que el requisito
está previsto de una manera vaga, imprecisa, y / o ambigua, y una calificación de
alta indicaría que el requisito está previsto de una manera precisa y sin
ambigüedades. Requisitos baja calificación en la escala de cuantificación se
clasifican como objetivos de diseño, como en:
3.6. Los terminales de cliente en el sistema de caja automatizada deberán

proporcionar un buen tiempo de respuesta.
mientras que un requisito cuantificado sería clasificado de alta en la precisión de

expresión, como en:
www.it-ebooks.info
3.6. Los terminales de cliente en el sistema de caja automatizada deberán

proporcionar un tiempo de respuesta promedio de 2 segundos y un tiempo de
respuesta máximo de 5 segundos para consultas de saldo; y un tiempo de respuesta
promedio de 5 segundos y un tiempo de respuesta máximo de 15 segundos para las
solicitudes de retiro y de depósito. Todos estos tiempos de respuesta se medirán
cuando 50 terminales son simultáneamente activa y el servidor se ejecuta en un
factor de carga promedio de 80%. Promedios deben ser determinados para un
período de 1 hora de funcionamiento.
Una calificación media en la escala de cuantificación indicaría que la

cuantificación es incompleta o poco práctico. Por ejemplo, el requisito 3.6 se
clasificaría Medio si las dos últimas frases no estaban presentes. Un requisito que
indica “el sistema será del 100% fiable” asimismo se considera baja en la
cuantificación, a pesar de que se afirma precisamente, porque es inviable.
Requisitos considera baja o media en la escala de cuantificación requieren trabajo
adicional.
El nivel de cuantificación también se puede utilizar para acceder a la
adecuación de un requisito como base para la planificación de las pruebas.
requisito operacional 4, más arriba, se considera baja, como base para la
planificación de controles, mientras requisito principal 3.6 se clasificaría alta. Un
requisito sería clasificado mediano idoneidad para la planificación del examen si
bien la funcionalidad a ensayar o cuantificación de un atributo de calidad que
deben alcanzarse, como se ha dicho, era débil.
Si la evaluación de los criterios de descomposición, la precisión de expresión,
y la adecuación de la planificación de pruebas se valoran como un triplete
ordenado, requisito 3.6 recibiría una calificación de (medio, alto, alto) o (H, H,
H). Requisitos que reciben una calificación baja en los criterios de
descomposición, la precisión de la expresión, o la base para la planificación de
controles deben descomponerse más allá y / o cuantificarse. Usted puede decidir,
además, que todos los requisitos esenciales deben recibir una alta calificación en
cada una de las tres dimensiones, especialmente si el sistema es crítico para la
seguridad o de misión crítica.
Con respecto a las especificaciones técnicas, requisitos principales se deben
categorizar las autorizadas como esencial, deseable u opcional. requisitos
derivados son, por definición, porque esencial que son necesarios para soportar
los requerimientos primarios. Del mismo modo las limitaciones de diseño se
clasifican, por definición, tan esencial una vez que se determina que las
restricciones de diseño son, de hecho, esencial. Los objetivos de diseño son los
requisitos primarios para los que los criterios de validación objetivo no puede, o
no han sido, afirmaron. Cada objetivo de diseño debe ser categorizado como
deseable u opcional, dependiendo de la importancia de la meta. Requisitos de
este modo se pueden medir de varias maneras diferentes, como se indica en la
Tabla 7.5.
Los requisitos operativos pueden ser evaluadas y medidas determinadas por
las revisiones conjuntas entre el representante de atención al cliente / usuario
(que es un orador idóneo y apropiado) e ingenieros de software que son expertos
en la obtención de requisitos y necesidades de desarrollo. Los requisitos técnicos
pueden ser evaluados y medidos por revisiones internas.
Algunos puntuaciones de evaluación pueden ser etiquetados TBD (a
determinar) en Ings iniciales niones; el estado de todas las ETG se debe
documentar, revisa periódicamente, resuelto de manera oportuna, y rastreado
hasta su cierre.
Otras medidas que se pueden utilizar para determinar el estado del desarrollo
de requisitos se enumeran en la Tabla 7.6.
www.it-ebooks.info
EVALUACIÓN DE CASOS DE USO
Los casos de uso son un mecanismo popular para la especificación de las

características de funcionamiento de un sistema o producto [Kulak03]. Cada
caso de uso especifica una característica de usuario bien definido y
autocontenido. En el ejemplo ATM, la validación, consulta de saldo, la
retirada, y las características de depósito por lo tanto deben ser expresados
como casos de uso separadas. Los casos de uso puede “utilizar” otros casos de
uso; por ejemplo, un caso de solicitud de retiro uso podría hacer uso de un
caso de consulta de saldo uso para determinar que no hay fondos suficientes
en la cuenta antes de dispensar la cantidad solicitada. Una plantilla para la
documentación de casos de uso, con un ejemplo, se presenta en la Figura 7.2.
Los escenarios son elementos clave de casos de uso. Cada escenario
especifica una secuencia de interacciones entre una entidad externa (un caso
de uso “actor”) y el sistema. Cada caso de uso proporciona un escenario
primario (por ejemplo, el escenario de retirada) y uno o más escenarios
secundarios. Cada escenario secundario especifica una acción alternativa al ser
tomada, por ejemplo, el escenario que se promulgó cuando el usuario no
introduzca un PIN correcto durante el proceso de validación de usuarios.
Los diagramas de secuencia y diagramas de estado son los mecanismos más
comúnmente utilizados para la especificación de escenarios. Un diagrama de
secuencia se puede utilizar para especificar un único escenario. Un diagrama
de estado se puede utilizar para documentar múltiples escenarios; cada camino
a través del diagrama de estado especifica un escenario de operación, como se
ilustra en la Figura 7.3.
La notación utilizada en la Figura 7.3 se basa en UML [Rumb05]. Los
nombres de los estados se proporcionan en los nodos del diagrama. La flecha
“puntos” indica el punto de entrada al diagrama de Estado (es decir, el estado
de reposo). Expresiones en las flechas son de la forma xx [aa] / zz, donde xx
es el disparador para tomar ese camino, proporcionado yy es
Caso de uso ID: ATM # 34

Nombre de Usuario caso: autorizar la transacción
Actor que inicia el caso de uso: cliente de un banco
Otros actores, en su caso: ninguna
Finalidad:
este caso de uso documenta los clientes del banco manera inician una
sesión en un cajero automático y se preparan para llevar a cabo una
transacción
Condiciones previas que deben darse antes de este caso de uso pueden ser
“ejecutados”:
cliente tiene una tarjeta bancaria y PIN válidos
escenario principal para describir la acción principal del caso de uso:
diagramas de secuencia, diagramas de estado, o narrativas pueden ser
utilizados; véase el ejemplo de un diagrama de estado en la Figura 7.3
Condiciones posteriores que deben ser verdaderas después de este caso
de uso es “ejecutados”:
al cliente se ha iniciado la sesión o cliente recibe un mensaje lo siento
escenarios alternativos para el manejo de excepciones:
PIN introducido incorrectamente; número de cuenta no válido; no hay
Figura 7.2 dinero
suficiente Una plantilla para documentar,
en la cuenta; y un ejemplo
no hay suficiente dinero endelaunmáquina,
caso de uso
etc. www.it-ebooks.info
mala PIN [PinTry <4] / PinTry ++
buena solicit buena

tarjeta PIN transacción
oci ud
oso procesamien
ALFIL to *
ER
mala tarjeta de la [PINTry = 4]
tarjeta / expulsión
carta llevar la
removida tarjeta
mensaje
[Tiempo de
espera (30)] impre
sión
recibo
FIGURA 7.3 diagrama de estado para el caso de uso en la Figura 7.2
cierto. Si yy está ausente se toma para ser verdad. zz es la acción a tomar,

mientras travers- ing ese camino. Cada uno de xx, yy, y zz es opcional. Una
flecha con una expresión en blanco indica un camino a ser tomada tan pronto
como se hayan completado las actividades en el estado anterior. La estrella (*)
sobre el estado de procesamiento de transacciones en la figura 7.3 indica que
el procesamiento de transacciones se define en un diagrama de estado
subordinado (anidada).
La adecuación de los casos de uso se puede medir utilizando un triplete
ordenado para indicar:
1. el nivel de granularidad especificada en el caso de uso,

2. el nivel de detalle en los escenarios primarias y secundarias, y
3. la suficiencia de la serie de escenarios secundarios en la especificación
de alternativas al escenario primaria.
El caso de uso en las figuras 7.2 y 7.3 podría ser clasificado como (Medio,
Alto, Bajo), que indica que el caso de uso es de granularidad adecuada (M), el
nivel de detalle en el escenario principal es muy bueno (H), pero algunos
escenarios secundarios faltan (L).
Los casos de uso con alta clasificación en la granularidad (detalle excesivo)
deben ser examinados para la fusión en otros casos de uso y casos de uso con
puntuaciones bajas de granularidad (detalles insuficientes) deben ser
examinados para la descomposición en dos o más casos de uso. Los casos de
uso considera baja para el nivel de detalle en el escenario principal o bajo para
la adecuación de escenarios secundarios deberán ser reciclados. escenarios
operacionales evaluados como medio o alto en nivel de detalle, y medio o alto
en suficiencia de escenarios secundarias proporcionan buenas bases para la
generación de escenarios de prueba. Los evaluados como Low no.
Casos de uso especifican características del usuario. atributos de calidad y
restricciones de diseño que se aplican a un caso de uso individual se pueden
especificar en la sección de comentarios del caso de uso. Las que se aplican a
los casos múltiples usuarios pueden especificar por separado.
www.it-ebooks.info
TABLA 7.5 Formas de medir los requisitos

• Por el número de “shalls” en las necesidades de funcionamiento;
• Por el número de especificaciones técnicas en cada una de las categorías
esenciales y deseables;
• Por el número de requisitos derivados de la categoría esencial;
• Por el número de restricciones de diseño en la categoría esencial;
• Por el número de objetivos de diseño en las categorías opcionales y deseables;
• Por el grado en que cada requisito técnico satisface los criterios de descomposición
de los requisitos, se mide en una escala de (baja, media, alta);
• Por el grado de cuantificación de los atributos de calidad, medido en una escala
de (baja, media, alta); y
• Por la medida de la idoneidad de cada requisito como base para la planificación de las
pruebas, se mide en una escala de (baja, media, alta).
TABLA 7.6 Algunas medidas de productos para las actividades de los requisitos
• Número de baselined requisitos frente al número previsto durante este período de
notificación acumulado
• Número de casos de uso desarrollados frente al número previsto durante este período de
• Número de casos de uso revisado y aceptado como adecuado durante este período
de notificación acumulado
• Número de casos de prueba basada en los requisitos de prueba y escenarios
generados frente al número previsto durante este período de notificación acumulado
• Número de prototipos desarrollado y revisado frente al número previsto durante
este período de notificación acumulado
• Número de *CRS y *DR para baselined requisitos presentados, el número aceptado,
rechazado número, y el número diferidos durante este período de notificación
acumulado
• Número de defectos requisitos por categoría de defectos y nivel de gravedad
• Número de CR y DR para baselined requisitos terminadas y cerradas durante este
período de notificación acumulado
• Número de CR y DR para requisitos todavía abierta de este período y de periodos
anteriores
• Cantidad de tiempo requerido para cerrar cada CR y DR para los requisitos baselined
• Situación de las matrices de trazabilidad (ver Tabla 3.6 en la Sección 3.4.4)
° de los requisitos operacionales a las especificaciones
técnicas
° a partir de especificaciones técnicas para probar los casos y
escenarios de prueba
* CR: Solicitud de cambio;
* DR: Defecto Informe.
7.6.2 La medición y el control de cambios para trabajar los productos

Reporting las medidas enumeradas en la Tabla 7.6 requiere un proceso de control
de cambio:
1. Cuando se selecciona los productos de trabajo, incluyendo los requisitos,

satisfacer los criterios de acep- tación objetivas, se colocan bajo control de
versiones, y convertirse así en líneas BASE (es decir, productos de trabajo
baselined). El estado de las líneas de base se informa periódicamente para
indicar tendencias en los cambios.
2. Si más tarde se encontró que un producto de trabajo baselined no es un dato
de partida, se actualiza, y el motivo de su actualización (requisitos de
cambio o defecto), además se informó el tiempo y el esfuerzo necesarios.
www.it-ebooks.info
La aceptación de un producto de trabajo como base de referencia no significa

que el producto de trabajo es perfecto, sino que es una base adecuada para nuevas
actividades que dependen de, o que utilicen el producto del trabajo baselined. Si
posteriormente se encontró que los productos de trabajo baselined de una especie
en particular no son adecuadas líneas de base, los criterios de aceptación para ese
tipo de producto de trabajo deben ser fortalecidas.
La satisfacción de los criterios de aceptación para las especificaciones técnicas se
determina por:
• la inspección y la revisión de las matrices de trazabilidad,
• establecer la suficiencia de los planes de prueba basada en los requisitos,
• examinando el número de objetivos de diseño TBD que aún no se traduce en
especificaciones técnicas,
• el examen de las medidas en la Tabla 7.5, y
• otros criterios discutidos anteriormente.
La satisfacción de los criterios de aceptación para las especificaciones técnicas se

determina por los requerimientos de los ingenieros y otras partes interesadas
pertinentes que están calificados para evaluar la integridad, exactitud y
consistencia de las especificaciones.
En general, se cambia un producto de trabajo baselined, y generó una nueva
versión, por una de dos razones:
1. porque los factores que afectan el producto del trabajo han cambiado; o
2. debido a que el producto de trabajo se encuentra para ser incompleta,
incorrecta o inconsistente.
Las solicitudes de cambio (CR) se utilizan para las peticiones de documentos

de cambios en las líneas de base de tipo 1 y de defectos Informes (DR) se utilizan
para las peticiones de documentos para los cambios de tipo 2. Sin cambios se
pueden hacer para un producto de trabajo baselined sin un CR aprobado o DR
que autoriza el cambio; de lo contrario el control de la línea de base de los
productos de trabajo no será eficaz. Tablas 7.7 y 7.8 proporcionan plantillas para
CRS y los Dres.
gestión de la configuración (CM) es el mecanismo utilizado para implementar
el control de cambio. Elementos de CM incluyen un proceso de control de
cambio, una herramienta de control de versiones, y una Junta de Control de
Cambios (CCB). El CCB se compone de partes interesadas que tienen la
autoridad de aprobar, diferir o negar CR y DR. Los miembros de la CCB
requisitos deben incluir:
• usted (el director del proyecto),

• el arquitecto de software,
• el cliente,
• un representante de los usuarios, y
• un representante de la organización que va a mantener el sistema en
funcionamiento.
En algunos casos, el departamento de marketing puede ser el cliente y el

representante de usuario. Para sistemas embebidos proyecta su proyecto de
software tal vez de subordinación a, y es parte de un programa más grande; CCB
su software puede incluir un ingeniero de sistemas o director del programa como
su cliente. En este caso (el director del proyecto de software) y / o su arquitecto
www.it-ebooks.info
de software debe ser un miembro del sistema-
www.it-ebooks.info
TABLA 7.7 Plantilla para una solicitud de cambio
Cambiar el número de
solicitud: Peticionario:
Fecha de presentación:
Disposición:
Aceptar Aplazar Negar Prioridad
duplicado (si es aceptado):
Alto Medio Bajo
Las líneas de base añadidos (nombres,
números de versión): líneas de base
modificados (nombres, números de versión):
Personal de horas para hacer el cambio:
Fecha nuevos y modificados aprobados
líneas de base: Aceptación de cierre de
sesión:
Fecha de cierre:
Personal notificados del cambio:
CCB nivel. Por regla general, la CCB debe incluir los principales interesados,
pero no debe ser tan grande que se convierte en un grupo de toma de decisiones
difíciles de manejar.
El flujo de trabajo de un proceso de control de cambio se presenta en el
Capítulo 3; Figura 3.5 se repite aquí como Figura 7.4. Se establece la línea de
base inicial de un producto de trabajo
CR o DR Negociación CCB
Aceptado proyect
o
El trabajo del Negociación
producto Dupl Análisis
Versión 0.N Autor
Hacer * de
impacto
Cambio
- Negar
- Aplazar CR y DR
Verificar
y validar - usuarios
* Duplica otra
Trabajo solicitud - Cliente
Versión del - Márketing
producto 0.N - Desarrolladores
+1
Las líneas de base se establecen
Línea
mediante un proceso de revisión y cambio
Base
aceptación comunicada
inicial
CR: Solicitud de
cambio de RD:
Informe de defectos
Figura 7.4 Flujo de trabajo de un proceso de solicitud de cambio
www.it-ebooks.info
TABLA 7.8 Plantilla para un informe de
Número informe de defectos:

Peticionario:
Breve descripción de la falla:
Nivel de gravedad:
Mayor Menor Prioridad
inconveniente para la fijación:
Inmediato ASAP Aplazar
la fase en la que se cometió el error:
Rqmts Diseño Imple. Verif.
Válido. Fase en la que se encontró el error:
Rqmts Diseño Imple. Verif. Válido. Ops
clase de error:
Incompleto Incorrecto Inconsistente
Otra especificar):
¿Cómo se detecta error:
Inspección revisión Prueba Manifestación.
Otra especificar):
Las líneas de base modificados para corregir error (nombres,
números de versión): Personal de hora de fijar:
Fecha nueva línea de base
aprobada: Aceptación de
cierre de sesión:
Fecha de cierre:
defectos
satisfaciendo los criterios de aceptación para el producto de trabajo (esquina

inferior izquierda de la figura 7.4). Las solicitudes de cambio (CRS) y informes
de defectos (DRS) son generados por las diversas partes interesadas (esquina
inferior derecha de la figura 7.4). CRs y los Dres se analizan para urgencia y los
impactos de hacer el cambio o la fijación del defecto de factores tales como el
coste, horario, tecnología, los usuarios, clientes y otras partes interesadas son
evaluados. El autor de la solicitud se le notifica si el cambio solicitado se ha
presentado con anterioridad.
El CCB puede aceptar la CR o DR para la acción en un horario determinado,
tal vez después de hacer ajustes para otros factores de proyecto, o se puede
negociar con el
www.it-ebooks.info
autor de la solicitud, que puede resultar en la denegación de la solicitud o

aplazamiento de acción hasta una fecha posterior. Por ejemplo, una solicitud de
cambio de una función adicional puede ser negado o aplazarse hasta una versión
futura del sistema.
Algunas negociaciones con uno o más jefes de equipo puede ser necesaria para
programar los desarrolladores y otros recursos de hacer los cambios. El producto
de trabajo baseline a modificar (versión 0.N en la Figura 7.4) está desprotegido
desde el sistema de control de versiones. El producto de trabajo modificado se
verifica para integridad, exactitud y consistencia y validado para asegurar que se
va a satisfacer su uso previsto en su entorno previsto.
Después de haber cumplido con sus criterios de aceptación, la nueva línea de
base del producto de trabajo se registró en el sistema de control de versiones y se
convierte en la versión 0.N + 1. Todas las partes interesadas relevantes son
notificados de la nueva línea de base.
Pequeños cambios en una línea de base requisitos (u otras líneas de base de
productos de trabajo), con el tiempo, indican un proyecto estable. Grandes
cambios, especialmente aquellos que dan lugar a grandes cantidades de retrabajo
sin compensar los cambios en las limitaciones del esfuerzo y del horario, son
motivo de preocupación.
El proceso de control de línea de base descrito anteriormente se presenta en el
contexto de la gestión de requisitos; Sin embargo, el control de la línea de base
(es decir, un proceso de cambio de control, una herramienta de control de
versiones y un BCC) es una herramienta fundamental para la medición y control-
ling todos los productos de trabajo de un proyecto de software.
7.6.3 Los atributos de medición Especificaciones de Diseño Arquitectónico

El diseño es el proceso de síntesis de un system26 para optimizar los criterios de
diseño específicos al tiempo que satisface las restricciones especificadas. El
proceso de diseño de software incluye el diseño arqui- tectural y el diseño
detallado. El diseño arquitectónico tiene que ver con sintetiza el tamaño de un
conjunto de componentes, especificando las relaciones estructurales y de
comportamiento entre los componentes, y la especificación de las interfaces con
el entorno del software. El diseño implementado debe dar lugar a un producto
que satisfaga las caciones speci- y limitaciones técnicas y alcanza, dentro de lo
posible, los objetivos de diseño para el sistema o producto.
El diseño detallado se refiere a la especificación de la interfaz, algoritmos,
datos estructuras, comportamiento interno, y los mecanismos de manejo de
excepciones de cada software com- ponent a ser construidos o modificados. El
diseño detallado es parte de la implementación (junto con la codificación de los
módulos, la documentación del código, integración de módulos para formar com-
ponentes, inspecciones y revisiones de código y pruebas por los ejecutores).
Medidas para la aplicación se presentan en la siguiente sección.
arquitecturas de software tienen varios tipos de relaciones entre los elementos
de la arquitectura, que se traducen en diferentes puntos de vista de la arquitectura,
incluyendo el [Bass03]:
• Descomposición,
• Despliegue,
• Usos,
• Clase,
• Capa,
www.it-ebooks.info
26
Un sistema es una colección de interactuar componentes que existe dentro e interactúa con un
entorno.
www.it-ebooks.info
• Mando y control, y
• puntos de vista de implementación.
Otros puntos de vista estructurales también son posibles.
La vista descomposición de la estructura de software, por ejemplo, es la vista
de las relaciones entre los componentes jerárquica, que está integrado en la
estructura de desglose del trabajo, tal como se describe en el capítulo 5 de este
texto. Esta es la vista principal que, según el director del proyecto, debe utilizar
para planificar, organizar y controlar su proyecto.
La vista despliegue ilustra las relaciones entre los componentes
implementados en diferentes elementos del hardware del sistema, como por
ejemplo, en el despliegue de los componentes de software en la arquitectura
cliente-servidor de un sistema de cajero automático. La vista de despliegue es útil
para evaluar el impacto de la colocación de los componentes en el rendimiento y
la seguridad. La vista despliegue indicaría, por ejemplo, si el acceso al cliente es
que ser validado mediante el mantenimiento de una copia de ID de cliente y
contraseñas en cada cajero automático o si los datos de validación se mantiene en
el servidor. Mantener los datos de validación en cada cajero automático mejorará
el rendimiento, reduciendo el número de accesos al servidor, pero podría hacer
que el sistema sea más vulnerable al acceso no autorizado a la información de la
cuenta.
El comportamiento de un sistema se determina por las nes Activa-
secuenciales y simultáneas de los componentes del sistema en tiempo de
ejecución. diagramas de actividad, las redes de Petri, diagramas de secuencia y
diagramas de estado se utilizan comúnmente mecanismos para documentar los
aspectos de comportamiento del software a nivel arquitectónico. Interfaces para
el medio ENTORNO pueden documentarse mediante la adaptación y el uso de
una plantilla estándar, tal como la proporcionada en [Bass03].
Una tarea importante para usted, como director del proyecto, y su arquitecto
(s) de software es para determinar qué puntos de vista, las representaciones de
comportamiento y atributos de la interfaz serán proporcionados en la
documentación de la arquitectura del sistema. Algunos atributos de los productos
de trabajo que pueden ser medidos durante la fase de diseño arquitectónico, o
fases, 27 se enumeran en la Tabla 7.9.
Como se indica en la Tabla 7.9, las actualizaciones de los indicadores de
estado requisitos deben revisarse periódicamente durante el diseño arquitectónico
(y en todo el proceso de desarrollo). Pequeños cambios en la línea de base, los
requisitos de un número creciente de objetivos de diseño convertidos a las
especificaciones técnicas, y un número creciente de casos de prueba basados
REQUISITOS indican un proyecto estable para que el diseño puede proceder con
confianza. Por el contrario, los grandes cambios en la línea de base requisitos
(especialmente sin compensar los cambios en el esfuerzo y las restricciones del
cronograma), un número creciente de objetivos de diseño, y la falta de escenarios
de prueba basados en requerimientos indican un proyecto inestable para el que
procede de diseño en el riesgo de grandes cantidades de reproceso basado en la
inestabilidad de los requisitos.
especificaciones de diseño de arquitectura proporcionan la primera
oportunidad de evaluar el impacto de las decisiones de diseño en los atributos de
calidad del producto a desarrollar. Calidad-atributos escenarios se pueden utilizar
para evaluar el diseño de atributos tales como la facilidad de cambiar el software
para los cambios en los requisitos y postulados de la disponibilidad, el
rendimiento, la seguridad, la capacidad de prueba, y la facilidad de uso de
software [Bass03].
www.it-ebooks.info
La especificación de diseño arquitectónico es la línea base (es decir, colocado
bajo control de versiones) cuando las partes interesadas apropiadas determinan
que la especificación, o una
27
Una fase de trabajo se caracteriza por las actividades de trabajo realizadas y productos de trabajo
producidos. Diversas fases de trabajo, incluyendo el diseño, se pueden repetir varias veces en un
proceso de desarrollo iterativo.
www.it-ebooks.info
TABLA 7.9 Algunas medidas de productos para el diseño arquitectónico

• Cambios a los requisitos *CR, *DR, y otros indicadores de estado requisitos
• Número de elementos de diseño en la línea de base de diseño arquitectónico frente al
número previsto en este período de notificación acumulado
• Número de escenarios en atributos de calidad preparadas frente al número previsto en
• Número de escenario-atributo de calidad tutoriales y críticas frente al número de
previsto en este período de notificación acumulado
• Número de casos de prueba basados en el diseño genera frente al número previsto en
• Número de CR-diseño de la línea de base y los Dres presentado, el número aceptado,
rechazado número, y el número diferido durante este período de notificación acumulado
• Número de defectos de diseño por categoría de defectos y nivel de gravedad
• Número de CR-diseño de la línea de base y los Dres completado y cerrado durante
• Número de CR-diseño de línea de base y los Dres todavía abierta de este período y de
periodos anteriores
• Cantidad de tiempo requerido para cerrar CR-diseño de la línea de base y los Dres
• Situación de las matrices de trazabilidad
° Requisitos para el diseño de componentes
° Componentes para poner a prueba los casos
parte significativa del mismo, satisface los criterios de verificación y validación

objetivas para acep- tación. Criterios de aceptación para una especificación de diseño
típicamente involucran la aplicación de:
• análisis de trazabilidad,
• tutoriales,
• inspecciones y
• realización de revisiones basadas en los escenarios de atributos de calidad.
Un defecto en la especificación de diseño arquitectónico resulta cuando la

especificación baseline se encuentra para ser incompleta, incorrecta, y / o
inconsistente con respecto a las necesidades de funcionamiento y las
especificaciones técnicas:
• Las características operativas,

• atributos de calidad,
• restricciones de diseño,
• las exigencias principales, y
• requisitos derivados.
Además, la especificación de diseño debe ser validado, es decir, determina que es

apto para su uso previsto como base para la implementación y planificación de
las pruebas. Tenga en cuenta que una especificación de diseño puede ser
verificada a ser completa, consistente y correcta con respecto a los requisitos,
pero podría no ser válida si se expresa en una notación
www.it-ebooks.info
(Por ejemplo, UML) que es desconocido para los ejecutores y los probadores, ya
que no sería apto para su uso en el entorno previsto.
Un defecto en la especificación de diseño arquitectónico puede ser causada por
un defecto en los baselined requisitos o por un error en la preparación de las
especificaciones de diseño. Como se discute posteriormente, es importante
identificar las fuentes de defectos.
7.6.4 La medición de atributos de implementación de software

Implementación de software incluye:
• diseño detallado de los módulos;

• codificación de los módulos;
• documentación de código;
• integración de módulos para formar componentes; y
• inspecciones, revisiones de código y pruebas por parte de los ejecutores.
En muchos casos, los módulos y componentes de software existentes se

modifican o se utilizan sin ser codificada en totalidad. La cantidad de aplicación
a llevarse a cabo depende de la cantidad de reutilización del software existente.
El diseño detallado se refiere a la especificación de los algoritmos, estructuras
de datos, el comportamiento interno, interfaces, y mecanismos de manejo de
excepciones de cada módulo de software para ser construido o modificado. La
cantidad de diseño detallado para ser logrado depende de la familiaridad de los
ejecutores con el algoritmo (s) y la complejidad de código para ser
implementado. Usted probablemente no necesitará de las especificaciones
detalladas para guiar la implementación de la décima variación en el algoritmo de
fusión-tipo. Sin embargo, el diseño detallado es probable que ahorrar tiempo y
esfuerzo, y mejorar la calidad de la aplicación si está implementando datos
complejos compresión sion y algoritmos de cifrado por primera vez.
La codificación se refiere a la aplicación de las especificaciones de diseño
(especificaciones de diseño arquitectónico y detallada). El código debe satisfacer
los requisitos y optimizar los criterios de diseño y los objetivos de diseño para el
producto o sistema que está siendo implementado. Como se indica en la sección
5.3, los requisitos para las características y atributos de calidad se deben asignar a
cada elemento de la estructura de desglose de trabajo para orientar a los
ejecutores y los probadores. Las técnicas de implementación elegido puede ser
determinada por la necesidad de mejorar la fiabilidad a expensas de rendimiento,
por ejemplo, mediante la incorporación de las afirmaciones en tiempo de
ejecución en el código, o la técnica de aplicación escogida pueden maximizar el
rendimiento a expensas de un aumento de la memoria el uso de, por ejemplo,
mediante la creación de tablas de valores se utilizan con frecuencia para evitar el
cálculo de los valores en cada uso.
Como se indica en la Tabla 7.10, la finalización de diseño detallado,
codificación, y la unidad de pruebas de módulos puede ser pronosticado mediante
el seguimiento de la tasa de progreso y comparándolo con el número estimado de
módulos a ser escrito o modificado. Si, por ejemplo, el ritmo de progreso actual
es de 5 módulos por semana, y 50 módulos aún no se han completado, la
ejecución se completará en 10 semanas, a la tasa actual de progreso. Por
supuesto, las estimaciones de finalización debe ser actualizadas semanalmente
debido a que el ritmo de avance puede variar de una semana a otra.
www.it-ebooks.info
TABLA 7.10 Algunas medidas de productos para la implementación de software

• Cambios a los requisitos *CRS y *DR, CR arquitectura y diseño de los proyectos de
resolución y otros requisitos de diseño e indicadores de estado
• Número de módulos baselined frente al número previsto en este período de
• medidas de la complejidad de los módulos, componentes, subsistemas y sistemas
• Número de inspecciones de código llevados a cabo frente al número previsto
durante este período de notificación acumulado
• Número de código CR-línea de base y los Dres presentado, el número aceptado,
rechazado número, y el número diferido durante este período de notificación
acumulado
• Número de código CR-línea de base y los Dres completado y cerrado durante este
• Número de código CR-basales y los Dres todavía abierta de este período y de
periodos anteriores
• Cantidad de tiempo requerido para cerrar CR y DR-código de la línea de base
• densidad acumulativa de defectos descubiertos por categoría de defectos y nivel de
gravedad, sobre la base de defectos totales y el total de líneas de código baseline
• Pronóstico para la realización del diseño detallado, codificación y pruebas desarrollador
• Situación de las matrices de trazabilidad:
° a partir de módulos baselined y componentes a la arquitectura
° de casos de prueba especificados a los módulos y componentes
° de casos de prueba completado con éxito a los módulos y componentes
Las inspecciones de código El número de inspecciones de código llevó a cabo

en comparación con el número previsto durante un período de notificación, y la
acumulada, son medidas citadas en la Tabla 7.10. Una inspección de código es
una forma de revisión por pares llevada a cabo por los compañeros de la persona
que desarrolló el código. En general, un compañero es aquel que tiene el mismo
estatus o de pie con otras personas que realizan tareas similares. Una inspección
de código se acompa- plished por un pequeño equipo de desarrolladores de
software (normalmente de 3 a 5). Los gerentes (incluida usted, el director del
proyecto ing), clientes, representantes de los usuarios, y otros están excluidos de
participar. Las evaluaciones inter pares son por lo tanto libre de las presiones
sociales y políticas que resultan cuando los participantes de diferentes rangos o
posiciones están presentes.
Con respecto a las inspecciones de código, su trabajo como director del
proyecto es:
• proporcionar capacitación en el proceso de inspección, si es necesario;

• permitir un tiempo adecuado en el calendario para preparar y llevar a cabo
las inspecciones;
• revisar los resultados; y
• hacer mejoras en sus procesos de inspección y desarrollo como indican las
tendencias reportadas encontradas durante las inspecciones.
En particular, el proceso de inspección requiere que usted, como director del

proyecto, programar el tiempo suficiente para la preparación, reuniones,
retrabajo, y el seguimiento de las actividades de las inspecciones.
El líder del equipo de cada equipo de software pequeña es responsable de los
productos de trabajo generados por el equipo, y él / ella debe participar en las
www.it-ebooks.info
inspecciones de código
www.it-ebooks.info
desarrollado por sus equipos. Los jefes de equipo son colaboradores técnicos y
son, o deberían ser, considerados como los miembros del equipo y no como tener
un rango superior. Si su proyecto es pequeño (es decir, 5 o menos los
desarrolladores de software) y usted es el director del proyecto, arquitecto de
software, y el líder del equipo, usted debe participar en las inspecciones. Usted
(el director del proyecto) están excluidas de la participación en proyectos más
grandes; OTRO TIPO, no se producen discusiones francas y acciones de auto-
corrección.
Como se muestra en la barra lateral, las inspecciones son el mecanismo más
eficiente y más eficaz conocido para encontrar y corregir defectos temprano en el
proceso de desarrollo. En la mayoría de los casos las inspecciones requieren
menos esfuerzo y encontrar más defectos que las pruebas. Sin embargo, el
proceso de inspección es un trabajo intensivo y puede parecer ser un uso
ineficiente de los recursos de personal (pero no como mucha mano de obra como
las pruebas por defecto encontrado y CORREGIDOS). Usted y su organización
pueden contrarrestar la aparición de la ineficiencia de las inspecciones mediante
el análisis de los datos de inspección y comparándolo con datos similares de las
pruebas (por ejemplo, el esfuerzo por defecto encontrado y corregido). Hay algo
mal con su proceso de inspección si sus datos no muestran las inspecciones para
ser eficiente y eficaz ya que las inspecciones se han encontrado para ser eficiente
y eficaz en muchas situaciones por muchas organizaciones.
Algunas organizaciones han encontrado que las pruebas unitarias tras la
inspección de los módulos de código no es rentable, porque muy pocos defectos
son encontrados por la unidad de pruebas después de la inspección y reparación.
En estas organizaciones, módulos de software están integrados en el producto de
la evolución después de un desarrollador corrige los defectos encontrados durante
una inspección. Sin embargo, las inspecciones no eliminan la necesidad de
pruebas de integración y verificación independiente y validación de un sistema
en evolución, ya que la dinámica de las interacciones entre los componentes del
sistema en virtud de diversos escenarios operacionales pueden exponer los
defectos que no pueden ser encontrados por las inspecciones. Los defectos que se
han encontrado y fijados por las inspecciones hacen las pruebas de integración,
verificación y validación más eficiente. El proceso de inspección se ilustra y se
discute en la barra lateral adjunta.
Tutoriales Tutoriales y las inspecciones son dos tipos de comentario de trabajo.

El propósito de la inspección es encontrar defectos y para recopilar datos para su
posterior análisis en el tipo y número de defectos y el esfuerzo requerido para
fijarlos. La participación en las inspecciones se limita a un pequeño número de
personas; típicamente de 2 a 4. El propósito de un tutorial es comunicar y revisar
cuestiones técnicas a un grupo (tal vez grande) de las personas. Los defectos
pueden ser descubiertos durante un recorrido, pero la detección de defectos no es
(no debería ser) el propósito principal de un recorrido; comunicación es (o
debería ser) el propósito principal de un tutorial. Algunas de las diferencias entre
las inspecciones y recorridos se enumeran en la Tabla 7.11.
Debe utilizar ambas inspecciones y recorridos según proceda: inspecciones
para encontrar defectos y tutoriales para comunicar problemas técnicos. Tabla
7.12 listas diferentes tipos de comentarios y los fines para los que se llevan a
cabo.
Prueba desarrollador Las “pruebas de desarrollador” citadas en la Tabla 7.10

(pronóstico para ción complemento de diseño detallado, codificación, y las
pruebas de desarrollador) están diseñados para validar las características y
www.it-ebooks.info
atributos de calidad de cada módulo. pruebas Desarrollador se preparan por los
desarrolladores de software en conjunción con la preparación del diseño
detallado y el código. prueba desarrollador puede requerir el desarrollo de
arneses de prueba para simular el entorno en el que operará el módulo. Si está
utilizando un proceso iterativo
www.it-ebooks.info
INSPECCIONES
Hay cuatro funciones que se jugará en una inspección:
1. el papel moderador de convocar y conducir la reunión,

2. el papel desarrollador para el desarrollador que generó el producto del trabajo,
3. el rol de lector para presentar el material al grupo parafraseando, y
4. el papel grabador para registrar los defectos y otras áreas de interés.
El papel grabador es esencial, ya que los defectos encontrados durante una

inspección que no se fijan en ese momento y preocupaciones para ser
investigados no son perseguidos durante la inspección; que se registran para
las acciones de seguimiento. Una sola persona puede desempeñar más de una
función. La única excepción es que el desarrollador no debe jugar el rol de
lector. Dos es por lo tanto el número mínimo de personas que pueden realizar
una inspección: una persona puede jugar el papel de moderador y lector, y el
desarrollador puede jugar el papel de promotor y grabador. Más típicamente,
cada una de cuatro personas se le asigna un papel y participar en la inspección;
cada miembro de un equipo de inspección es un inspector.
Las seis fases de flujo de trabajo para el proceso de inspección software se
ilustran en la Figura 7.5. La planificación implica el moderador y el
desarrollador. Ellos revisan el material y determinar si está listo para su
inspección, identifican los materiales conexos necesarios, solicitar a los
participantes, y programar la reunión. Esto requiere típicamente de 2 a 4
horas. La sesión de introducción es opcional; que se lleva a cabo si los
participantes necesitan una orientación al material a ser inspeccionado. La
sesión de información general, si se mantiene, por lo general requiere de ½ a 1
½ horas.
Cada participante debe pasar de 2 a 3 horas preparando: revisar el material
y, mediante un formulario estándar, la grabación de defectos, los posibles
defectos y áreas de interés para la discusión durante la reunión de la
inspección.
310
Planifica Visión de Preparan Reunión Rehace Seguir
ción conjun do r
to
2-3 Hrs. 2 horas.
0,5-1,5 6 Max.
12-4 Hrs. 2 4 5 Aprox. 92-3 Horas.11
Hor .por 5 Hrs.
as. Inspector
7
tiempos de transición
1 Entrada
2 1-3 días (si se Tercera
incluye) Hora 8
3 Inmediato (Opcional)
4 Inmediato
5 3-5 días
6 Inmediato
7 Día 1 (si se incluye)
8 Inmediata
9/10 1
semana
11 Exit
www.it-ebooks.info
Figura 7.5 El proceso de inspección
www.it-ebooks.info
Al comienzo de la reunión de la inspección, el moderador registra el tiempo

dedicado por cada participante en la preparación para la reunión; estos datos
son la fuente de los tiempos indicados en la Figura 7.5 [Bush88]. Si uno o más
de los participantes no ha preparado, esa persona o personas que están
exceptuados de la reunión, y de la TOR moderación determina si la reunión
debe posponerse o si se debe proceder sin esa persona o personas.
Durante la reunión de la inspección, el lector parafrasea pequeños bloques
de material (es decir, código de una inspección de código, diseño para una
inspección de diseño, requisitos para una inspección de requisitos, escenario
de prueba para una inspección de plan de pruebas) y le pide a cada
participante, a su vez, e incluyendo a sí misma oa sí mismo, si ven algún
problema o tiene alguna preocupación. Las grabaciones de los registradores,
en una forma estándar, los defectos, problemas y preocupaciones expresadas
durante la reunión.
Es importante que la reunión se limita a no más de 2 horas, porque los
participantes se cansa después de 2 horas de actividad concentrada y porque
los participantes pueden programar el resto de su jornada de trabajo, y por lo
tanto son más propensos a ser participantes voluntarios si conocen el tiene una
reunión de partida definido y hora de finalización. Con un poco de
experiencia, usted y su organización aprenderá la cantidad óptima de material
que puede ser inspeccionado en una reunión de 2 horas: demasiado material
hace que el proceso ineficaz debido a defectos e inquietudes serán analizadas
exceso; demasiado poco material hace que el proceso ineficiente, porque se
pierde tiempo.
La tercera hora no es una extensión de la reunión de 2 horas. Es una opción
que se puede utilizar para las discusiones informales entre algunos o todos los
participantes, después de una pausa o tal vez a la mañana siguiente con un
café.
Retrabajo se lleva a cabo por el desarrollador del material en consulta con
otros como sea apropiado; esta actividad requiere típicamente
aproximadamente 5 horas. El promotor, o el equipo de inspección, puede
solicitar otra inspección después de la reanudación se completa si el retrabajo
es sustancial. Sin embargo, esto rara vez ocurre En la práctica, porque el
moderador y el desarrollador no deben programar una inspección hasta que
coinciden en que el material está listo para ser inspeccionado.
El moderador y desarrollador llevan a cabo la reunión de seguimiento de
acuerdo en que todos los defectos y las preocupaciones han sido abordadas y
que todos los formularios de información se han completado. Una inspección
requiere alrededor de 2 semanas de tiempo transcurrido y de 30 a 40 horas de
esfuerzo total entre 4 participantes.
En un análisis de muchas inspecciones de código en un sistema grande, una
organización informó de que la eficacia de las inspecciones era de
aproximadamente 1 por equipo defecto horas; la inspección típicas que se
encuentran alrededor de 37 defectos por mil líneas de código inspeccionados a
una tasa de inspección de 150 líneas de código por equipo-hora (300 líneas
por inspección). Este resultado se encontró que era de 2 a 4 veces más
eficiente que la prueba. Por ejemplo, si se tarda 5 horas en promedio para
encontrar y corregir un defecto importante por inspección que podría tomar de
10 a 20 horas para encontrar y reparar el mismo defecto mediante ensayos. las
tasas más rápidas de inspección detectaron menos defectos; por ejemplo sólo
se detectaron 10 defectos por mil líneas de código a una tasa de inspección de
500 líneas de código por equipo-hora [Russell91].
Los beneficios adicionales de las inspecciones incluyen el trabajo en equipo
www.it-ebooks.info
y el aprendizaje mutuo que se produce, y la detección de patrones de defectos
que surgen mediante el análisis de los registros de los tipos de defectos
encontrados durante la inspección. En el último caso, por ejemplo, podría ser
evidente que un gran porcentaje de los defectos encontrados se encuentran en
la
www.it-ebooks.info
interfaces entre módulos. Esto podría indicar que el diseño detallado de inter-
enfrenta antes de la codificación reducirá sustancialmente defectos.
Procedimientos para la realización de las inspecciones y los formularios de
registro asociados están contenidos en el apéndice 7B de este capítulo.
proceso de desarrollo (recomendado) la versión actual del software en evolución

puede ser utilizado como el instrumento de prueba para las pruebas unitarias de
módulos en fase de desarrollo (que se integrarán en el producto en evolución y
proporcionará el instrumento de prueba para la siguiente iteración de la aplicación).
Si está utilizando un proceso de desarrollo ágil, los casos de prueba se escriben
antes de que se escribe el código (siempre es una buena idea). Otra de las medidas
de aplicación de la Tabla 7.10 es la complejidad de los módulos, componentes,
subsistemas y sistemas. La siguiente sección presenta alguna complejidad
medidas dad de código de software.
7.6.5 Medidas de complejidad para el código de software

Como se discutió en el capítulo 1, la complejidad es una de las características
inherentes de software de ordenador. software complejo es difícil de entender,
difícil de documentar, difícil de probar, difíciles de modificar, y como
consecuencia, difíciles de reutilizar. A la inversa, se puede concluir que el
software que es difícil de entender, difícil de documentar, difícil de probar,
difíciles de modificar y / o difíciles de reutilizar es, por definición, complejo.
Tres medidas de uso común de la complejidad del software son
TABLA 7.11 Distinción entre inspecciones y recorridos

InspectionsWalkthroughs
Objetivo: encontrar defectsPurpose: a comunicar
Formación de la formación de participantsNo Participantes
roles asignados: moderador, No hay roles asignados
lector, grabadora, desarrollador
Los nombres de los participantes recordedNames de participantes (normalmente) no
registrado Desarrollador no lo hace presentDeveloper
normalmente regalos
Grabar registro keepingNo acuerdo
Análisis de la inspección análisis resultsNo del tutorial resultados
TABLA 7.12 Hay varios tipos de comentarios y sus propósitos

Mas o menos ReviewPurpose
InspectionTo encontrar defectos y documento de descubrimiento y la procesos de
reparación WalkthroughTo revisar los productos de trabajo y comunicar cuestiones
TeamTO revisión del progreso y plan de trabajo ocupaciones
ProjectTo revisión del progreso, proceso y producto limitaciones y factores
de riesgo Confront
CustomerTo opinión avances, limitaciones y riesgos factores
DepartmentTo revisión carteras de proyectos, identificar y enfrentar común
factores de riesgo, evaluar el estado de los presupuestos y
clientes, y confirman la declaración de misión / Revisar
www.it-ebooks.info
ciclomática complejidad, el generador de costos COCOMO complejidad, y el

acoplamiento y la cohesión.
Complejidad ciclomática ciclomática complejidad es una medida de la teoría

de grafos. Cuando se aplica a código fuente, es una medida del número de
caminos independientes linealmente a través del código. Se aplica a software
mediante el cálculo de la complejidad estructural del gráfico de flujo de control
de un módulo y también se puede utilizar para calcular la complejidad de
colecciones de módulos. Figura 7.6 representa un gráfico de flujo de control en el
que los nodos representan grupos de secuencialmente ejecutan las instrucciones y
los bordes representan flujo de control entre los nodos declaración. Los nodos
oscuros contienen declaraciones que invocan otros módulos (más sobre esto más
adelante). Como se indica en la figura 7.6, la fórmula para el cálculo de
complejidad ciclomática de un gráfico de flujo de control es
do 
donde E es el número de aristas y N es el número de nodos en el gráfico de flujo

de control; los bordes de entrada y salida no se cuentan.
Como regla general, los módulos que tienen complejidad mayor que mide 10 o
12 se consideran generalmente ser demasiado complejo; que son difíciles de
entender, difícil de documentar, difícil de probar, y difícil de modificar. Medidas
de complejidad ciclomática tomadas antes y después de software es modificado
puede ser utilizado para controlar la entropía de software, que es la tendencia de
software a ser más complejo, ya que se somete a modificación [Belady76]. En
algunos casos, los sistemas de software se han retirado porque se han vuelto tan
complejos, a través de una serie de modificaciones, que ya no pueden ser
modificados sin crear números inaceptables de nuevos defectos. Módulos para
los que la medida de complejidad se vuelve demasiado grande se pueden
modificar adicionalmente para reducir la complejidad y por lo tanto evitar la
entropía excesiva. Esta es una forma de mantenimiento preventivo para el
software.
la complejidad del diseño ciclomática de una colección de módulos se calcula
mediante la retención de sólo los nodos de cada módulo (y los bordes asociados) que
contienen declaraciones que invocan, o son invocados por otros módulos. la
complejidad del diseño se calcula mediante el cálculo de la complejidad ciclomática
de cada módulo resultante y la combinación de esas complejidades utilizando la
fórmula
Un
módulo
C (M) = 13 - 10 + 2 = 5
Figura 7.6 Un gráfico de flujo de control y cálculo de complejidad ciclomática
www.it-ebooks.info
corriente continua
Scorriente continua
METROj 
donde DC (Mj) es la complejidad de diseño de módulo j y N es el número de
módulos.
Un módulo'
7-6+2=3
2-2 + 2 =
3-3 + 2 2
=2
0-1 + 2 = DC (S) = 8 - 4 + 1 = 5
1
FIGURA 7.7 Ciclomática la complejidad del diseño
En la figura 7.7, A módulo es la versión podado del módulo A en la Figura

7.6. Los otros módulos de la Figura 7.7 son los invocados por el módulo A.
Colecciones de módulos que tienen complejidades de diseño mayor que 40 o 50
se considera que es demasiado complejo. En tales casos el sistema debe ser
separada en dos o más subsistemas, cada uno de complejidad aceptable, que se
comunican a través de una sola interfaz, bien definido. Un sistema complejo
podría ser descompuesto, por ejemplo, en la interfaz de usuario, la base de datos,
de cómputo, y subsistemas de comunicación con las caras inter bien definidas
entre los subsistemas.
El hecho de que la complejidad ciclomática de una sección de código fuente es
el recuento del número de caminos linealmente independientes a través de un
módulo (o cualquier sección de código) se puede utilizar como una guía para la
planificación de las pruebas debido a que la medida de complejidad ciclomática
es una cota superior en los casos de prueba de números necesarios para lograr
cobertura de sucursales y un límite inferior en el número de casos de prueba
necesarios para lograr la cobertura total de la ruta. Por ejemplo, el número de
casos de prueba para lograr una cobertura rama de dos secuencial declaraciones
IF-THEN-ELSE, como se representa en la figura 7.8 es 2. El número de casos de
prueba para lograr la cobertura de camino es 4. El número complejidad
ciclomática es 3.
La métrica de complejidad ciclomática de software fue desarrollado por Tom
McCabe en 1976 [McCabe76]. El McCabe compañía comercializa herramientas para
calcular la complejidad matic ciclo- de módulos y sistemas escritos en varios
www.it-ebooks.info
lenguajes de programación [www.mccabe.com]. Algunos juegos de herramientas de
desarrollo también incorporan calculadoras complejidad ciclomática.
www.it-ebooks.info
FIGURA 7.8 gráfico de flujo de control para dos secuencial declaraciones IF-
THEN-ELSE
Conductor Costo COCOMO Complejidad Como se discutió en el capítulo 6,

los modelos COCOMO se cuestan modelos de estimación que proporcionan
estimaciones de esfuerzo y horario. En contraste con la complejidad ciclomática,
que es una medida de la complejidad estructural, el conductor coste COCOMO
CPLX se utiliza para medir la complejidad de las operaciones a realizar por un
módulo o una colección de módulos. En COCOMO, el valor de CPLX se utiliza
para aumentar o disminuir una estimación esfuerzo.
Determinar el valor de CPLX se basa en la evaluación de la complejidad de los
cinco tipos de operaciones de un programa suele llevar a cabo:
• operaciones de control,
• operaciones de cálculo,
• operaciones dependientes de dispositivos,
• operaciones de gestión de datos, y
• operaciones de gestión de interfaz de usuario.
Se proporciona una tabla para seleccionar un valor para cada uno de los cinco
elementos; por ejemplo, un programa estima que las operaciones de control que
implican la mayoría de código de línea recta con unos pocos operadores de
programación estructurada no anidados como DOS, casos y IF-THEN-vigilara y
tendría una capacidad nominal de llamadas a procedimientos simples o
secuencias de comandos simples Muy baja en la complejidad (0,73). Un
programa estima que tiene múltiples recursos para ser planificado con
dinámicamente cambiantes prioridades y con control distribuido en tiempo real
sería clasificado de muy alta complejidad (1,74) [Boehm2000]. El rango de
valores multiplicadores de esfuerzo para CPLX es, pues,
0,73 CPLX 1,74.
El valor de CPLX para cada uno de los cinco factores de complejidad se

estimó a partir de los requisitos y del diseño, si está disponible; o bien, se puede
determinar a partir del código fuente para fines de mantenimiento del software.
El valor numérico de la
www.it-ebooks.info
factor de complejidad dominante, o de factores, entre los cinco factores se utiliza

como el multiplicador de esfuerzo para CPLX en la ecuación de estimación de
esfuerzo. Un valor CPLX superior a 1 indica que el código es, o se estima, más
complejo que el producto típico y por lo tanto el proyecto requerirá más esfuerzo
que el proyecto típico; un valor inferior a 1 indica que el código es, o se estima
que es menos complejo que el producto típico y el proyecto requerirá menos
esfuerzo que el típico. CPLX, como la complejidad ciclomática y el acoplamiento
y la cohesión, se puede aplicar al código existente para determinar la dificultad
de comprensión, la documentación, pruebas y Modificar- ing el código.
Acoplamiento y Cohesión Acoplamiento y la cohesión son medidas de las

relaciones entre los módulos (acoplamiento) y las relaciones entre los elementos
dentro de los módulos (cohesión) [Myers74]. El acoplamiento se mide en una
escala de débil a fuerte; acoplamiento débil es menos complejo que el
acoplamiento fuerte. acoplamiento débil es deseable, ya que promueve la
facilidad de comprensión, facilidad de documentación, la facilidad de las
pruebas, la facilidad de modificación, y la facilidad de reutilización; es decir, que
se traduce en complejidad deseable de acoplamiento entre un grupo de módulos.
Algunos niveles de acoplamiento se enumeran en la Tabla 7.13. acoplamiento del
mensaje, como en software orientado a objetos, y la comunicación mediante el
paso de parámetros, tanto en software orientado a objetos y funcionalmente
estructurado, son los métodos preferidos de acoplamiento.
Las medidas más fuertes, y menos deseables, de acoplamiento (sello, control,
común, y el contenido) no son deseables debido a que el efecto de hacer que un
cambio puede rizarse más allá del módulo que se está cambiado. Por ejemplo, si
una estructura de datos se cambia en un sistema que exhibe sello o acoplamiento
común, todos los módulos que acceden directamente la estructura de datos
tendrán que ser cambiado.
La cohesión es una medida de las relaciones entre los estados dentro de un
módulo, en una escala de fuerte a débil. de cohesión fuerte es deseable, ya que
indica que todas las declaraciones de un módulo están contribuyendo a la misma
finalidad. cohesión fuerte reduce la complejidad, ya que cada módulo se le puede
dar un nombre corto y sencillo que indica su propósito. Esto permite a los seres
humanos para construir modelos mentales de colecciones de módulos por, como
dicen los psicólogos, “fragmentación” de la información. Por ejemplo, si un
módulo llamado “ordenación rápida” sólo hace rápida clasificación de los datos
comunicados por entrada y salida de parámetros (acoplamiento de datos), los
detalles internos del módulo no tienen que ser recordado cuando se razona sobre
el programa en el que el módulo de clasificación rápida está incrustado. Además
módulos altamente cohesivos no tienen efectos secundarios inesperados o
sorprendentes.
TABLA 7.13 Algunas medidas de complejidad de acoplamiento

Tipo de acoplamiento
(Débil para Fuerte) Explicación
Mensaje couplingRequest de Servicio
Datos couplingPassing de parámetros
Sello módulos couplingTwo acceder directamente a la misma estructura de datos (s)
Control couplingModules pasan banderas para controlar las rutas de ejecución de
otros módulos Común módulos couplingAll acceder directamente a los mismos datos
estructura (s)
Contenido couplingModules acceder directamente a los datos internos de otro módulos
www.it-ebooks.info
TABLA 7.14 Algunas medidas para la cohesión de software

Tipo de Cohesión
(Strong a Débil) Explicación
método cohesionEach objeto en un objeto tiene la cohesión funcional y
apoya el solo propósito, bien definida del objeto funcional
elementos cohesionAll en un soporte función una sola, por poco definido
concepto
Secuencial cohesionOutput de algunos elementos proporcionan entradas a los
elementos siguientes en un módulo
Comunicación cohesionAll elementos de un módulo de uso de los mismos datos de entrada
pero para
fines diferentes
Temporal cohesionThe única relación entre los elementos es que Se ejecuta
como un grupo
Coincidente cohesionNo relaciones significativas entre los elementos de una módulo
que pueda encontrar un comando para lanzar un misil guiado. No hace falta decir
que el módulo no sería altamente cohesivo.
Algunos niveles de cohesión se enumeran en la Tabla 7.14. Objeto de
cohesión, como en software orientada a objetos y la cohesión funcional, tanto en
software orientado a objetos y funcionalmente estructurado, son los niveles
preferidos de la cohesión.
Cuanto más débil y menos deseable, medidas de cohesión (ción secuencial,
nicación, temporal y casual) da lugar a una mayor complejidad porque hacen un
módulo difícil de entender, documentar, probar, modificar y reutilización.
acoplamiento débil (mensaje y datos) y de cohesión fuerte (objeto y funcional),
en conjunto, resultan en software que contiene módulos reutilizables, y es fácil de
entender, documento, prueba, y modificar debido a que el efecto de onda de los
cambios se reduce, en comparación a las colecciones de módulos que tienen un
fuerte acoplamiento y cohesión débil.
7.6.6 Medición de Integración y Verificación de unidades de software

En el modelo de desarrollo en cascada, la unidad de software que se integra y se
verificado es el conjunto de componentes para todo el sistema. La integración
de los componentes del sistema por lo tanto se produce al final del proceso de
desarrollo, como se indica en la Figura 2.8. En un proceso iterativo, la
integración y la verificación (además de validación) de unidades de software se
produce sobre una base cíclica, tal como se indica en la figura 2.10; en un
proceso iterativo las unidades de software están creciendo subconjuntos de todo
el sistema. En cualquier caso, la integración y verificación de software se ocupa
de:
• la integración de los componentes del sistema en unidades más grandes;

• verificar que las unidades más grandes se implementan como diseñado; y
• verificar que las unidades son completa, correcta, y consistente con respecto
a sus requisitos funcionales y de calidad.
Algunas medidas de productos que se pueden obtener durante la integración de

software y veri ficación se enumeran en la Tabla 7.15.
www.it-ebooks.info
TABLA 7.15 Algunas medidas para la integración de software y verificación

• Cambios a los requisitos, el diseño y el código *CRS y *DR, y otros indicadores de estado
• Número de módulos integrado con éxito y verificada frente al número previsto
durante este período de notificación acumulado
• densidad de defectos para cada componente, cada subsistema, y todo el sistema
• Número y porcentaje de pruebas basadas en el diseño aprobadas durante este período
• Número y porcentaje de pruebas basadas en el diseño fracasaron; durante este
• Número de integración CR-línea de base y los Dres presentado, el número
aceptado, rechazado número, y el número diferido durante este período de
• Número de CR-integración de línea de base y los Dres cerrado durante este período
• Número de CR-integración de línea de base y los Dres todavía abierta de este período
y de periodos anteriores
• Cantidad de tiempo requerido para cerrar CR y DR-basal de integración
• Situación de las matrices de trazabilidad:
° a partir de unidades de software para casos de prueba basados en el diseño y escenarios
de prueba realizado con éxito
° a partir de unidades de software para completar con éxito los requisitos basados en
casos de prueba y escenarios de prueba
• Pronóstico para la culminación de la integración y verificación
Debe supervisar cambios a CR y DR para requisito, el diseño y las líneas de

base de código, además de otros indicadores de estado del producto para
determinar si esos cambios son en alcance o fuera del alcance de los parámetros
del proceso (esfuerzo, otros recursos, presupuesto, programación, tecnología) y
ajustar los parámetros según sea necesario. Otras medidas de la Tabla 7.15 le
permiten determinar si se está haciendo un progreso adecuado como se mide
comparando el progreso previsto para el progreso real.
7.6.7 La medición de Verificación y validación del sistema

verificación del sistema tiene que ver con la determinación de que el sistema que
se entregarán es correcta, completa y consistente con respecto a sus
especificaciones técnicas y requisitos de funcionamiento cuando se opera en el
entorno de desarrollo. La validación del sistema se refiere a la determinación del
grado en que el sistema entregado satisface su propósito cuando se opera por sus
usuarios previstos en su entorno operativo previsto. Los procesos, métodos y
técnicas son similares en cada caso. Sin embargo, la verificación del sistema se
produce normalmente en el entorno de desarrollo, mientras que la validación del
sistema se produce normalmente en el ambiente operacional y consiste en
usuarios reales. Usted (el director del proyecto), el desarrollo de su personal
designado, representantes de los usuarios, y el cliente debe presenciar las pruebas
y demostraciones en ambos casos.
Algunas medidas de productos para la verificación y validación del sistema se
enumeran en la tabla
7.16. Puede utilizar estas medidas para prever la terminación de la verificación y
validación del sistema del sistema. técnicas utilizadas comúnmente para el
sistema V & V están probando, demostraciones, opiniones, y el análisis de
www.it-ebooks.info
trazabilidad.
www.it-ebooks.info
TABLA 7.16 Algunas medidas para la verificación y validación del sistema

• Cambios a los requisitos, diseño, código, y la integración *CRS y *DR, y otros
indicadores de estado
• Número y porcentaje de pruebas y demostraciones funcionales basados en escenarios
ejecutados con éxito durante el presente período de notificación y la acumulada
• Número y porcentaje de pruebas y demostraciones funcionales basados en
escenarios fallaron durante el presente período de notificación y la acumulada
• Número y porcentaje de pruebas cuantitativas pasaron durante el presente período de
notificación y la acumulada
• Número y porcentaje de pruebas cuantitativas fallaron durante el actual período de
• Las estimaciones de fiabilidad y disponibilidad del sistema
• densidad DR acumulativa (DRs por unidad de tamaño)
• Número de CR y DR-sistema de línea de base presentado, el número aceptado,
rechazado número, y el número diferido durante este período de notificación acumulado
• Número de CR y DR-sistema de línea de base cerrada durante este período de
• Número de CR-sistema de línea de base y los Dres todavía abierta de este período y de
periodos anteriores
• Cantidad de tiempo requerido para cerrar CR y DR-sistema de línea de base
• Pronóstico para la realización de la verificación del sistema
• Pronóstico para la finalización de la validación del sistema
pruebas y demostraciones basados en escenarios están destinados a evaluar el

grado en que el sistema proporciona las características necesarias, la
funcionalidad y Butes atri- calidad, incluyendo el manejo de excepciones y
funcionamiento degradado. Las pruebas y demostra- ción de características y
funcionalidad en un sistema especificado por casos de uso, por ejemplo, podrían
ejercer todos los escenarios primarios y secundarios en los casos de uso. Los
escenarios secundario deben cubrir las excepciones y manejo de excepciones,
por ejemplo, mediante pruebas de la respuesta cuando un cliente deja de
introducir el PIN correcto en un sistema de caja automatizada. Funcionamiento
degradado podría incluir pruebas y demostración de capacidades operativas
especificadas de terminales ATM, tales como la respuesta de los cajeros
automáticos cuando el servidor o el canal de comunicación está abajo.
La diferencia entre una prueba y una demostración es como sigue: a prueba
está diseñada especificando el entorno de prueba, los estímulos de entrada, y el
resultado esperado de la prueba. Por ejemplo, una prueba de funcionamiento de
una función de raíz cuadrada debe devolver 3 cuando la entrada es 9, 3,1622 ... (a
un grado específico de resolución) cuando la entrada es 10, y así sucesivamente.
El valor de la raíz cuadrada para ser devuelto para números negativos también
serían probados para la conformidad con la especificación, a condición de que la
especificación incluye los resultados para los números negativos.
Una demostración se lleva a cabo mediante la especificación de los estímulos
del medio ambiente y de entrada, pero el resultado no puede predecirse con
antelación. Aceptabilidad del resultado se determina mediante juicio humano. La
aceptabilidad de una interfaz de usuario, por ejemplo, está determinada por los
usuarios representativos; el nivel en el que lleva a cabo un programa de juego de
ajedrez está determinado por los maestros de ajedrez. demostraciones a nivel de
sistema deben ser confirmaciones de las manifestaciones anteriores de prototipos
y demostraciones de incremento
www.it-ebooks.info
7.7 medición y análisis de defectos de software 301
progreso durante el desarrollo de software; no debe haber sorpresas en las

manifestaciones a nivel de sistema.
pruebas del sistema cuantitativos se derivan de los atributos cuantitativos
contemplados en los requisitos primarios, requisitos derivados, y las restricciones
de diseño. Estas pruebas se ocupan principalmente de verificación y validación
de los atributos de calidad del sistema, tales como el rendimiento en diversas
condiciones especificadas, tiempo medio entre fallos, tiempo medio de
reparación, y la disponibilidad.
Atributos tales como facilidad de aprendizaje y facilidad de uso, tal como se
mide por específico, pre- experimentos determinados también pueden ser
evaluados. atributos cuantitativos basados en pruebas de estrés también pueden
llevarse a cabo; como por ejemplo el ensayo de tiempo de respuesta de los
terminales de ATM cuando 100 terminales son simultáneamente activa y el
servidor se ejecuta en uso de la CPU 90%.
7.7 Medición y análisis de defectos de software
defectos de software, cuando se encuentran durante el funcionamiento de un

sistema o producto, dan lugar a fallos. Un fallo se produce cuando el software no
satisface sus necesidades del usuario, las expectativas del cliente, o las
especificaciones técnicas (requisitos primarios, los requisitos derivados, las
limitaciones de diseño) cuando es operado por sus usuarios, según lo previsto en
su entorno operativo previsto. Algunos fallos son más graves que otros; un fallo
del sistema es más grave que un mensaje de error incorrecto e incorrectamente
resultados computados puede constituir una falta más grave que un fallo del
sistema.
saldos de clientes incorrectamente calculados en un sistema de caja
automatizada, por ejemplo, pueden dar lugar a graves problemas para los
usuarios o para la institución financiera, dependiendo de la naturaleza del defecto
que causa el fallo. Un fallo del sistema a partir del cual la recuperación es posible
el uso de un registro de transacciones (después el defecto de que la causa del
accidente es fijo) puede causar molestias durante el corte, pero causa daño no a
largo plazo. Una coincidencia de tipos en una interfaz de software que hace que
un error no detectado en los cálculos de navegación (como en un orbitador Mars
que chocó contra la superficie de Marte) es más grave que un fallo de software en
vuelo desde la cual el sistema puede reinicie por sí mismo, o para los cuales un
parche de software se puede cargar.
defectos de software son causados por errores humanos. A diferencia de los
artefactos físicos, software no se desgasta o romper con el uso repetido. errores
humanos son de dos tipos:
• error de omisión (no hacer algo que debería haber hecho) y

• de error de comisión (hacer algo de forma incompleta, incorrecta o
inconsistente tently).
Tabla 7.17 enumera algunas razones seres humanos cometen errores. La

mayor parte de los errores cometidos durante el desarrollo de software y la
modificación son causados por problemas en comu- nicación y coordinación, y
por la falta de conocimiento, habilidad o las herramientas adecuadas, pero
algunos son causados por la falibilidad humana. Los errores en la comunicación y
coordinación se pueden reducir mediante mejores procesos de trabajo. Los
www.it-ebooks.info
errores de la falibilidad se pueden reducir, por ejemplo, al no requerir exceso de
horas extraordinarias, lo que resulta en fatiga mental, que a su vez da lugar a
errores.
www.it-ebooks.info
Fiabilidad, disponibilidad, tiempo medio entre fallos, y tiempo medio de

reparación
Tabla 7.16 indica que las estimaciones de fiabilidad y disponibilidad del

sistema se pueden realizar durante la verificación y validación del sistema. La
fiabilidad del sistema se define por tres atributos:
1. El sistema llevará a cabo operaciones específicas

2. Bajo las condiciones establecidas
3. Durante un período de tiempo especificado
Un índice de fiabilidad R es la probabilidad de que un sistema será fiable (es

decir, llevará a cabo las operaciones especificadas bajo las condiciones
establecidas por un período determinado de tiempo). Si el índice de fiabilidad para
un sistema indica que el sistema funcionará durante 5 minutos (tiempo de reloj de
pared) entre fallos, donde el fracaso refiere a una caída del sistema, con% de
probabilidad 80 (R = 0,8), y si satisface sistema Este (absurdo ) requisito ment (es
decir, que opera sin una caída del sistema durante 5 minutos o más, el 80% de las
veces), se dirá que el sistema sea fiable. sistemas de misión crítica a menudo
tienen calificaciones de confiabilidad del orden de 0,999995 durante períodos de
tiempo que se extienden hasta varios años. hardware y software redundante se
requiere para satisfacer dichos requisitos de fiabilidad gent strin-.
Tiempo hasta el fallo (MTTF) La media es la cantidad media de tiempo que
un sistema está en funcionamiento entre fallos. Tiempo medio de reparación
(MTTR) es la cantidad promedio de tiempo que se necesita para devolver un
sistema con errores en estado operativo. La disponibilidad es la probabilidad
estará disponible un sistema cuando sea necesario.
La disponibilidad se puede expresar como
UN 
MTTF
.
MTTF
MTTR
Si MTTF = 80 horas y MTTR es de 20 horas entonces a = 0,8, fracasos

suponiendo que se distribuyen de manera uniforme en el tiempo. Puede ser que un
sistema ATM tiene un requisito de disponibilidad de 0,9 desde las 6:00 AM hasta
las 11:59 pm todos los días sin ningún requisito de disponibilidad de 12:00 AM
hasta las 5:59 PM. Actualizaciones, conciliaciones de cuentas, y otros tipos de
actividades de mantenimiento por lo tanto podrían ser programadas durante horas
de la noche.
Los sistemas que tienen requisitos de disponibilidad extremadamente altos
suelen emplear múltiples procesadores de hardware con el funcionamiento
simultáneo y la votación por mayoría de los procesadores (como en el caso del
transbordador espacial de la NASA ordenadores de a bordo) o con
procesadores de reserva en caliente (como en el caso de la Nueva York bolsa).
Como es el caso habitual cuando se trata de estadísticas, las desviaciones, así
como los valores medios deben establecerse y validados. Los usuarios de un
sistema con MTTF = 80 horas que tienen una desviación estándar de 2 horas
probablemente daría más altos en la disponibilidad de un sistema que tiene MTTF
= 80 horas y una desviación estándar de 40 horas incluso si MTTF fue la misma
para ambos sistemas (80 horas ) y MTTR fue la misma para ambos sistemas (por
ejemplo, 4 horas).
www.it-ebooks.info
defectos totales, k
defectos
residuales # Acumulada de defectos
descubrió:
(-a)
fallas por ~ K * [1 - e ]
intervalo
re t
Decrecimiento exponencial
*
* *
*
el tiempo de prueba de la CPU,
t
Figura 7.9 Un modelo de crecimiento de la fiabilidad
crecimiento de la fiabilidad durante la prueba del sistema se puede

aproximar como se ilustra en la Figura 7.9. Durante sistema de prueba el
número de defectos encontrados por unidad de intervalo de prueba típicamente
disminuye de manera exponencial; defectos que son fáciles de encontrar son
rápidamente expuestos mientras que menos de los más difíciles se encuentran
por intervalo de prueba. Si los resultados de cada defecto en un fallo (es decir,
una desviación de comportamiento especificado o deseado), la curva de caída
exponencial en la figura 7.9 es una medida inversa de MTTF. Por ejemplo, si
16 defectos se encuentran durante un día de 8 horas de la prueba, el número
promedio de defectos por hora de prueba es 2 en ese día y el MTTF es de 30
minutos para ese día. El recíproco de la curva de defectos es por lo tanto una
curva de crecimiento de la fiabilidad.
Los modelos exponenciales y logarítmicas de Poisson de crecimiento de la
confiabilidad se presentan en [Mala97]. Otros modelos se pueden encontrar en
Internet.
Como jefe de proyecto debe analizar defectos y, en la medida de lo posible,

esforzarse por reducir los errores. Por supuesto, los seres humanos cometen
errores (no somos autómatas), por lo que la probabilidad de que la producción de
software libre de defectos para sistemas grandes y complejos es cercano a cero.
Los defectos se cuentan como errores descubiertos durante el proceso de
aceptación de los productos de trabajo a ser la línea base o errores descubiertos
después de un producto de trabajo se baseline. Los errores encontrados y
corregidos antes de la línea de base de un producto de trabajo inicial no se
cuentan como defectos:
Los defectos son los errores encontrados durante la aceptación inicial de productos
de trabajo, y los errores que se encuentran en productos de trabajo baselined.
Cuando se descubre un defecto, un informe de defectos se prepara y utiliza para

rastrear ing condiciones- del defecto (es decir, corrigiendo el error que creó el
defecto). Figura 7.10 ilustra el proceso de detección y reparación de defectos. La
plantilla DR en la Tabla 7.8, que se repite aquí como la Tabla 7.18, se puede
utilizar para grabar información de defectos a lo largo
www.it-ebooks.info
TABLA 7.17 Razones seres humanos cometen errores en los proyectos de software
Las fallas de comunicación y coordinación
• “No he recibido la información necesaria”
• “La información que ha cambiado y no se le dijo”
• “Me malinterpretado la información correcta”
• “Yo no sabía que tenía que hacer esa parte”
• “Pensé que tenía que hacer esa parte”
La falta de habilidad y herramientas

• “No sabía cómo hacer ese trabajo”
• “Nunca he hecho ese trabajo antes”
• “Yo no tenía la herramienta correcta para el trabajo”
falibilidad humana
• “Estaba cansado, enfermo, perturbado, ...”
• “Mi hijo, marido, esposa, estaba enfermo”
• “Estaba pensando en mis próximas vacaciones”
• “Yo estaba distraído por una llamada telefónica”
• ...
t0 td1 td2
product producto
procedimient de ...
o del
o de trabajo
trabajo
aceptación baselined
privado
aplazar negar
aceptar CCB preparar y

decisión presentar DR
correcta y t0: Momento de la creación

completa de defectos tdj: Tiempo de
error DR detección de defectos vida
defecto = t0 - tdj
FIGURA 7.10 La detección de defectos y el proceso de reparación
las fases de desarrollo de su proyecto y para registrar los defectos a lo largo del
ciclo de vida mantenimiento de un producto de software o sistema. Información
DRs completado puede ser analizada, como se discute a continuación.
Como se indica en la Tabla 7.18, defecto Informes (DR) se utilizan para
registrar:
• fechas de apertura y cierre del defecto informe,

• una breve descripción de la falla causada por el defecto,
• la forma en que se detectó el defecto,
• -personal horas pasadas en la fijación del defecto,
• fase en la que se cometió el error que creó el defecto,
www.it-ebooks.info
TABLA 7.18 Plantilla para un informe de defectos
Número informe de defectos:

Peticionario:
Breve descripción de la falla:
Nivel de gravedad:
Mayor Menor Prioridad inconveniente para la fijación:
Inmediato ASAP Aplazar
la fase en la que se cometió el error:
Rqmts Diseño Imple. Verif.
Válido. Fase en la que se encontró el error:
Rqmts Diseño Imple. Verif. Válido. Ops tipo de error
Incompleto Incorrecto Inconsistente
Otra especificar):
¿Cómo se detecta error:
Inspección revisión Prueba Manifestación.
Otra especificar):
Las líneas de base modificados para corregir error (nombres,
números de versión): Personal y la hora de fijar:
Fecha nueva línea de base
aprobada: Aceptación de
cierre de sesión:
Fecha de cierre:
• fase en la que se descubrió y se corrige el defecto,
• productos de trabajo baselined modificados para corregir el error,
• cierre de sesión por una parte responsable de certificar el producto del
trabajo modificado ha pasado con éxito sus criterios de aceptación,
• fecha de la nueva línea de base se introduce en el sistema de control de
versiones, y
• el personal notificados del cambio.
Los datos para Defecto Los informes pueden ser capturados durante el proceso
de revisión de pruebas de inspección de aceptación inicial basal y durante la
administración de configuración check- y procedimientos de facturación para la
modificación de los productos de trabajo baselined. La entrada de datos se facilita
mediante la visualización de plantillas electrónicas que se realizan por Ircops
desa- software y mantenedores durante la comprobación y registro de entrada.
www.it-ebooks.info
Su organización debe tener criterios para categorizar el nivel de gravedad de

un defecto, por ejemplo:
• Uno de los principales defectos debe fijarse inmediatamente porque el

defecto puede causar un efecto dominó en otros productos de trabajo que
dependen de este producto de trabajo (por ejemplo, uno de los principales
defectos sería declaración incorrecta de un requisito que crearía defectos en
la documentación de diseño, código, y planes de prueba);
• un defecto menor debe fijarse en un futuro próximo, pero no se propagará a
otros productos de trabajo (por ejemplo, un error en un escenario de prueba
que debe ser corregido antes de ser usado sería clasificado como un defecto
menor);
• un defecto incómoda no afectará el comportamiento operativo del sistema,
pero podría crear un inconveniente para los usuarios (por ejemplo, una
característica de interfaz de usuario que requiere que el usuario introduzca
una secuencia de caracteres de control en lugar de seleccionar una opción de
hacer clic).
Son posibles otras categorizaciones de nivel de gravedad. Por ejemplo un defecto

catastrófico en un sistema de misión crítica podría resultar en la pérdida de varias
vidas y / o la pérdida catastrófica de la propiedad, un defecto significativo podría
resultar en la pérdida de una sola vida o pérdida significativa de la propiedad; un
defecto grave puede provocar lesiones graves o la pérdida grave de la propiedad,
y un defecto menor podría provocar lesiones leves o menor pérdida de propiedad.
La plantilla presentada en la Tabla 7.19 se puede utilizar para reportar el
envejecimiento de informes de defectos abiertos por nivel de gravedad. Usted y
su organización debe tener metas para el cierre de informes de defectos dentro
del período de tiempo determinado; por ejemplo, los principales defectos deben
ser fijados dentro de las 24 horas, los defectos menores plazo de 3 días, y el
defecto inconveniente dentro de los 5 días.
Un informe también puede ser generado para indicar el número total de
defectos abiertos, el número de defectos comunicados recientemente, y el número
llevado adelante desde el período de notificación ous previ-, como en la Tabla
7.20.
El formato de los informes de defectos en la Tabla 7.18 incluye entradas para
el registro de la fase de desarrollo en la que se cometió el error y la fase de
desarrollo en que se encuentra el defecto. Estos datos pueden ser utilizados para
preparar un informe usando la plantilla ilustrada en la Tabla 7.21. Tabla 7.22
proporciona una leyenda parcial para las entradas de la Tabla 7.21, que debería
ser suficiente para explicar las entradas restantes. En mesa
7.21 de verificación y validación defectos, por ejemplo, son defectos encontrados
en productos de trabajo V & V tales como matrices de trazabilidad, informes de
reuniones de inspección, y en casos de prueba, escenarios de prueba, entornos de
prueba, y planes de prueba.
TABLA 7.19 Plantilla para la presentación de informes envejecimiento defecto por nivel de
gravedad
Tipo de defecto Abrir 1 día 3 días 5 días 5 días

abiertos abiertos abiertos
# defectos mayores
www.it-ebooks.info
# defectos menores
# defectos
inconvenientes
www.it-ebooks.info
7.7 Medición y análisis de defectos de software 307
TABLA 7.20 Plantilla para la presentación de informes defectos por periodo de informe
Tipo de defecto Numero total recientemente Arrastrado

denunciados
defectos mayores
Los defectos menores
defectos inconvenientes
TABLA 7.21 Plantilla para matrices de defectos

Ocupacion
es: Diseño Imple. Verif. Válido. Ops. Los
Rqmts. totales
defectos: RDR RD RDi RDve RDVA RDO 
Rqmts.
Diseño D DDi DDve DDva DD 
Imple. IDi IDve IDV O 
Verif. ddd VEV A IDo 
Válido. E Veva VE 
Vavá O 
totales:       TOTAL

VA
O
TABLA 7.22 Una leyenda parcial para la Tabla 7.21
DefectWhen Encontró
RDrRequirements defectos encontrados durante requisitos la aceptación de
línea de base
RDdRequirements defectos encontrados durante un diseño actividad
RDiRequirements defectos encontrados durante una actividad de
implementación RDveRequirements defectos encontrados durante una actividad
de verificación RDvaRequirements defectos encontrados durante una validación
actividad
requisitos RqDAll defecto encontrado durante todo el desarrollo de software
ocupaciones
ImTDefects de todo tipo encuentran durante una implementación actividad
TOTALDefects de todo tipo encuentran durante todo el desarrollo de software
actividades y operaciones
datos de defectos que se presentan en el formato de la Tabla 7.21 se pueden usar

para determinar, por ejemplo, el porcentaje de defectos requisitos que se
encuentran durante el diseño:
 
 
RqD⎦ 

o, por ejemplo, el porcentaje de defectos de diseño que “escapar” del proceso de

diseño y se descubrió posteriormente:

 ddd 
  
 .
  DeD⎠ 
Tabla 7.23 proporciona un ejemplo de una matriz de defectos para un proyecto
terminado. Los defectos 20 operaciones totales (PO) son los defectos que se han
encontrado los usuarios
www.it-ebooks.info
TABLA 7.23 Un ejemplo de una matriz de defectos para un proyecto terminado

Fases Cuando defectos encontrados:
Rqmts. Diseño Imple. Verif. Válid Ops. Los
o. totales
defectos: 50 25 13 6 3 3 100
Rqmts.
Diseño 60 30 15 8 7 120
Imple. 80 40 20 10 150
Verif. 6 3 0 9
Válido. 7 0 7
totales: 50 85 123 67 41 20 386
durante los primeros 6 meses de operación. Si, como en la Tabla 7.23, el número
de defectos requisitos encontrados durante las actividades requisitos era 50, el
número encontrado durante el diseño fue de 25, el número encontrado durante la
ejecución fue de 13, el número encontrado durante la verificación era 6, el
número encontró durante la validación fue de 3, y el número encontrado por los
usuarios durante los primeros 6 meses de la operación fue 3, sería evidente que:
1. los criterios de aceptación para la aceptación de línea de base de los

requisitos deben mejorarse para otros proyectos presentes y futuras (50% de
los requisitos de defecto encontrado durante el desarrollo escapado el
proceso de verificación requisitos);
2. detección de defectos requisitos deben mejorarse en fases de desarrollo
posteriores (más o menos 50% de los restantes defectos requisitos se
detectaron en cada etapa subsiguiente de desarrollo; más debería haber sido
detectado durante la fase de diseño);
3. defecto de la eficacia de detección en cada etapa de desarrollo fue de
aproximadamente 50%; y
4. más o menos 5% de defectos totales escapó el proceso de desarrollo y no se
encontraron por los usuarios durante los primeros 6 meses de operación
(20/386; un resultado de la eficacia del 50% en cada etapa).
Otros análisis son posibles. En la Tabla 7.23, 3% de los defectos requisitos

escapó el proceso de desarrollo y no se encontraron por los usuarios (3 de 100).
También tenga en cuenta que los criterios de aceptación de código implementado
son sólo el 53% de efectividad (80 de 150 defectos de ejecución que encontramos
durante la actividad de implementación; 70 escaparon). En general,
aproximadamente el 7% de los defectos de ejecución escapó el proceso de
desarrollo (10 de 150).
Análisis de la Tabla 7.23 también podría revelar que de los 60 defectos de
diseño encontrados durante las actividades de diseño, 40 fueron el resultado de
los 25 defectos requisitos que escaparon en el proceso de diseño y otros 20
defectos de diseño se crearon durante la actividad de diseño. Del mismo modo el
análisis podría mostrar que de los 80 defectos de ejecución que se encuentran
durante la implementación, 50 fueron causadas por los 43 requisitos y defectos de
diseño en que se basa la ejecución y los otros 30 fueron creados durante la
ejecución. Estos y similares análisis pueden identificar áreas de mejora de los
procesos de desarrollo, procedimientos, métodos, herramientas y técnicas a
través de thedevelopment proceso.
www.it-ebooks.info
7.8 ELECCIÓN Medidas del Producto 309
Como se señaló anteriormente, la eficacia de la detección de defectos en la

Tabla 7.23 es de aproximadamente 50% en cada fase de desarrollo (defectos 25
de 50 requisitos escapan en el diseño; 12 requisitos defectos se encuentran
durante el diseño y 13 de escape en mentación imple-; y así sucesivamente). No
es razonable que los criterios de aceptación para un producto de trabajo deben
encontrar el 70% y el 80% de los defectos en el producto de trabajo antes de la
línea de base es (no es razonable esperar que el 100% de los defectos en un
producto de trabajo se encontrará antes baselining a ella).
Si el 70% de los defectos requisitos se encuentran en cada una de las cinco
fases de desarrollo (requisitos, diseño, implementación, verificación y
validación), entonces sólo 0,073% del 100% de los defectos requisitos
permanecerá para ser encontrado por los usuarios ([1 0.35 ] 100). La
eficacia global de encontrar defectos requisitos durante el desarrollo de software
es, pues, 99,927%. Por un razonamiento similar, 0.24% de los defectos de diseño
debe escapar del proceso de desarrollo, y el 0,81% de los defectos de ejecución
debe ser liberado a los usuarios. Este análisis (simple) se basa en el supuesto de
una lineal, proceso de desarrollo de la cascada. Un proceso de desarrollo iterativo
debe hacer mucho mejor de lo indicado debido a las repetidas oportunidades para
actualizar los productos de trabajo base-alineados en sucesivas iteraciones.
El ejemplo de la Tabla 7.23 es para un proyecto completo y un sistema que ha
estado en funcionamiento durante seis meses. Usted puede preparar matrices de
defectos similares durante el desarrollo de software que se actualizan en cada
intervalo de informe. La matriz se puede analizar la evolución del desarrollo de
tendencias y en comparación con las expectativas, con base en los resultados de
proyectos anteriores similares en etapas similares de desarrollo.
7.8 ELECCIÓN Medidas del Producto
secciones anteriores de este capítulo se han presentado muchas posibilidades para

la medición de los atributos de los productos de trabajo. El capítulo 8 presenta los
métodos y técnicas para ING mensurables y controlar sus procesos de trabajo. Es
posible, aunque no es muy probable, que puede ser capaz de entrega de un
producto aceptable a tiempo y dentro del presupuesto sin ningún tipo de
planificación, estimación, medición, o el control de los procesos de trabajo y
productos de trabajo. Como se dijo anteriormente, el costo de la planificación,
estimación, medición y control, al igual que el coste de la gestión de riesgos, es
una inversión que realice para aumentar la probabilidad de éxito. La cantidad que
se invierte en la planificación, estimación, medición y control depende de la
criticidad de la entrega de un producto aceptable dentro de las limitaciones del
proyecto y el coste de no hacerlo.
Dadas las múltiples restricciones que se van a encontrar en la gestión de un
proyecto de software, que nunca tendrá tiempo suficiente para hacer un trabajo
minucioso y completo de medición y control de los productos de trabajo o
procesos de trabajo (o cualquier otra cosa, es decir, la ingeniería de sistemas,
ingeniería de requisitos, diseño, desarrollo, revisión, pruebas, planificación de
proyectos, estimación, y otras actividades del proyecto). En el caso de la
medición y el control de los requisitos, por ejemplo, puede decidir que los
requisitos esenciales deben recibir la mayor atención, y tal vez sólo un
subconjunto de los requisitos esenciales, consideradas fundamentales para el
éxito del producto se con- controlada a nivel de detalle indicado anteriormente.
Como pauta general, sin embargo,
www.it-ebooks.info
Algunos aspectos de medición y control pueden ser prescritos por su organiza-

ción; por ejemplo, pueden ser necesarios todos los proyectos que informar, a
intervalos prescritos, proyecto de atributos tales como:
• tamaño del producto,
• defectos,
• esfuerzo gastado en diversas actividades del proyecto
• retrabajo correctivo de las líneas de base de productos de trabajo, y
• progreso horario en el logro de hitos prescritos.
Ambos valores y las tendencias actuales en el tiempo deben ser reportados y

analizados.
Objetivos-pregunta-Metrics (GQM) es un enfoque que puede ser utilizado para
determinar las medidas que se deben hacer en un proyecto de software [Basili94].
GQM llega a un conjunto de métricas de contestar las siguientes preguntas:
Objetivos: ¿Qué desea lograr?

Preguntas: ¿qué preguntas deben ser contestadas para asegurar que a lograr sus
objetivos?
Métricas: qué datos deben ser recogidos y analizados para responder a las
preguntas?
Supongamos, por ejemplo, que uno de sus objetivos es reducir los

defectos: Objetivo: reducir defectos durante el desarrollo de
software
preguntas:
cuántos defectos se introducen durante el desarrollo de software?
¿Qué porcentaje de defectos totales encontrados durante el desarrollo de
software es introducido en cada fase de desarrollo de software?
¿Qué porcentaje de defectos totales encontrados durante el desarrollo de
software se encuentra en cada fase de desarrollo de software?
¿Qué tipos de defectos se encuentran en cada fase de desarrollo de
software?
¿En qué porcentaje deben defectos encontrados durante el desarrollo de
software se reducirá en los próximos 12 meses?
Métrica:
número total de defectos encontrados durante el desarrollo de software
porcentaje de defectos totales introducidos en cada fase del software Desa-
ment
porcentaje del total de defectos encontrados en cada fase de desarrollo
de software tipos de defectos encontrados en cada fase de desarrollo de
software
Estas métricas se pueden determinar utilizando las técnicas y formatos

presentados en esta sección. Los tipos de defectos encontrados pueden ser
categorizados como incorrecta, incompleta, de la interfaz, la lógica, y así
sucesivamente; véase la lista en el Apéndice 7B un ejemplo de tipos de defectos.
El siguiente paso en la reducción de defectos sería encontrar las respuestas a
los siguientes tipos de preguntas y para tomar las acciones apropiadas:
¿qué tipo de errores se están haciendo que dan lugar a los tipos predominantes
de defectos?
www.it-ebooks.info
7.10 DIRECTRICES para medir y controlar los productos de trabajo 311
¿qué tipo de acciones se deben tomar primero para reducir los tipos
predominantes de errores?
¿qué tipo de acciones se deben tomar para reducir posteriormente las clases
menos prominentes de errores?
Si tienes la suerte de trabajar en una organización bien administrada, habrá

plantillas, guías de adaptación, y personal para ayudarle a diseñar un plan de
medición y control para sus productos de trabajo y procesos de trabajo.
7.9 La medición del software PRÁCTICA
Orientaciones adicionales para la selección y aplicación de medidas de software

se proporciona en el sitio Web de y en las publicaciones de Practical Software y
Sistemas Measure surement [PSM]. Medición técnica Proyecto de colaboración
del PSM, INCOSE, e Industria ofrece una introducción a la medición Practical
Software [Roed05]. El informe es un esfuerzo de colaboración entre el PSM
(Practical Software y Sistemas de Medición) y INCOSE (Consejo Internacional
sobre Sistemas Engineer- ing) organizaciones. Como se indica en el informe, las
medidas técnicas incluyen medidas de efectividad (MOE), los parámetros clave
de rendimiento (KPPS), medidas de rendimiento (MOPS), y las medidas de
rendimiento técnico (TPMS).
• MOE son medidas de éxito que son independientes de la solución particular

utilizado para lograr los objetivos operativos. Una medida objetiva utilizada
para determinar que un sistema es fácil de aprender y fácil de usar (o no),
para un grupo determinado de usuarios, es un ejemplo de un MOE.
• MOSes proporcionan información sobre el rendimiento de un sistema
específico. Ejemplos de MOSes son medición del tiempo de respuesta y el
rendimiento para un sistema particular.
• TPM atributos medida de un sistema para determinar la eficacia de un
sistema, o algunos elementos de un sistema, satisfacer los requisitos
especificados. La medición de la cantidad de memoria utilizada frente a la
cantidad de memoria asignada, como en la figura 7.11, es un ejemplo de
TPM.
• KPPS son un subconjunto crítico de los parámetros de rendimiento que
representan las capacidades más críticos o características. Medidas de
rendimiento que están relacionados con los requisitos esenciales son
ejemplos de KPPS.
Las relaciones entre los márgenes de exposición, MOP, las MTP, y KPPS como
se ilustra en el informe, y se reproducen aquí en la Figura 7.12.
Información adicional relativa a Practical Software y Sistemas ción
Measurement se incluye en la Sección 5 del apéndice 7A a este capítulo.
7.10 DIRECTRICES para medir y controlar los productos de

trabajo
Las siguientes pautas se ofrecen a ayudarle en el desarrollo y ejecución de un

plan de medición y control de sus productos de trabajo:
www.it-ebooks.info
Memori
256K
a
reserva de 10%
225K
Real
B=
Incremental-
B1B2B3B4 B5 construye
FIGURA 7.11 Funcionamiento de la medida técnica de uso de la memoria
Creciente
medidas de Técnico
Eficacia Resolucio
(MOE) nes y
periódica
Llave Insight
Parámetros
Necesidades de de medidas Insight
la misión o rendimiento de técnica
problemas de Actuación (Progreso
funcionamiento y Riesgo)
críticas Técnico Las
medidas de
Creciente rendimiento
Ámbito (TPMS)
de
aplicació
n de
Solución
Las medidas
técnica técnicas son interdependientes
FIGURA 7.12 Relación de las medidas técnicas [Roed05]
G1: Gestión de la configuración de las líneas de base del producto del trabajo,
sobre la base de criterios de aceptación objetivas para productos de
trabajo, es esencial.
G2: El tiempo y el esfuerzo invertido en ingeniería de sistemas, ingeniería de
requisitos, y el diseño es el tiempo y el esfuerzo bien invertido.
G3: El tiempo y el esfuerzo invertido en la creación de prototipos, desarrollo
de escenarios, inspecciones y revisión de requisitos y el diseño es el
tiempo y el esfuerzo bien invertido.
G4: El tiempo y el esfuerzo dedicado a la trazabilidad entre los productos de
trabajo es el tiempo y el esfuerzo bien invertido.
G5: El tiempo y el esfuerzo empleados en el desarrollo y ejecución de planes de
verificación a nivel de sistema y validación, en base a las necesidades de
funcionamiento y las especificaciones técnicas, es tiempo y esfuerzo bien
invertido.
www.it-ebooks.info
7.12 puntos clave de CAPÍTULO 7 313
G6: El tiempo y el esfuerzo invertido en encontrar y corregir defectos tan pronto

como sea posible es el tiempo y el esfuerzo bien invertido.
G-7: El tiempo y el esfuerzo empleados en la recogida y análisis de datos de
defectos, y tomando acciones correctivas basadas en el análisis es el
tiempo y el esfuerzo bien invertido.
Directrices para el desarrollo de medidas de proceso se discuten en el capítulo

siguiente.
7.11 AJUSTES Balanceo-WAVE basados en medidas y medición

del producto
Como se discutió en el capítulo 5, la evolución de los planes detallados, en base al

estado actual, que se conoce como el enfoque de onda de laminación para la
planificación. la planificación de onda rodar bordes RECONOCE que es imposible
desarrollar planes a nivel de detalle indicado en este capítulo durante la fase inicial
de planificación de un proyecto.
Ejemplos de actividades de trabajo que pueden ser ajustados en base a las
medidas y surements Measure de productos de software incluyen:
• número restante de los casos de uso que se desarrolló,

• número restante de escenarios que se genere,
• número restante de prototipos para ser construido,
• número restante de escenarios de prueba que se genere,
• número restante de inspecciones y pruebas de unidad que se llevó a cabo, y
• número restante de pruebas de integración y del sistema para llevar a cabo.
Los ajustes que se puedan hacer para mantener un equilibrio entre los requisitos,
el esfuerzo, el horario, el costo y la tecnología se discuten en el Capítulo 8.
• La medición periódica de los atributos del producto permite la comparación

del estado actual al estado planeado.
• Control (acción correctiva) se ejerce cuando el estado real difiere del estado
planeado por más de una cantidad aceptable predeterminado.
• medidas de producto y proceso son, o deberían ser, un subproducto de los
procedimientos, herramientas y técnicas utilizadas para desarrollar software,
si no el proceso de desarrollo debe ser modificado.
• Una medida es un mapeo de un fenómeno de interés a un símbolo.
• Diferentes escalas de medición permiten diferentes tipos de operaciones
sobre las medidas.
• Cada producto de trabajo debe ser verificada y validada; Además buye atri-
específicas de cada tipo de producto de trabajo se pueden medir.
• El control de versiones de líneas de base de productos de trabajo es necesaria
para la medición y control de los productos de trabajo.
• Las inspecciones son la técnica más rentable sabido encontrar defectos en los
productos de trabajo, especialmente en los requisitos y el diseño cuando se
corrigen fácilmente.
www.it-ebooks.info
• Las inspecciones se utilizan para encontrar defectos; tutoriales se utilizan

para comunicar problemas técnicos.
• El software que es difícil de entender, difícil de documentar, difíciles de
verificar la fecha y validada, y difícil de modificar es demasiado complejo.
• ciclomática complejidad, el generador de costos COCOMO CPLX, y el
acoplamiento y la cohesión son tres medidas de la complejidad del software.
• Un índice de fiabilidad es la probabilidad de que un sistema no dejará de
realizar las funciones previstas dentro de su entorno de trabajo por un
período determinado de tiempo.
• Una calificación de disponibilidad es la probabilidad estará disponible un
sistema para su uso cuando sea necesario.
• Los defectos son el resultado de errores humanos; defectos en un operativas
salidas causar que el sistema de comportamiento o los resultados
especificado o esperado.
• Los fallos de software se producen cuando se detectan defectos en el
funcionamiento de un sistema por sus usuarios previstos dentro de su
entorno de trabajo.
• El registro sistemático del proceso de detección y reparación de defectos
permite el análisis de la contención de defectos y escape durante las distintas
fases de desarrollo de software.
• El tiempo, esfuerzo y costo de medición y control de los productos del
trabajo, como el tiempo, el esfuerzo y el coste de la gestión de riesgos, es
una inversión que realice para proporcionar una alerta temprana de
problemas y aumentar la probabilidad de éxito.
• Al igual que la gestión de riesgos, la cantidad que se invierte en la medición
y control de los productos de trabajo depende de la criticidad de la entrega
de un producto aceptable dentro de las limitaciones del proyecto, y el costo
de no hacerlo.
• SEI, ISO, IEEE, PMI, y PSM-INCOSE proporcionan marcos, normas y
directrices para medir y controlar los atributos del producto (véase el
Apéndice 7A a este capítulo).
• Procedimientos y formas para la realización de inspecciones de software
están contenidos en el apéndice 7B a este capítulo.
Referencias
[Basili94] Basili, V., G. Caldiera, y HD Rombach. La pregunta meta enfoque

métrica.
Enciclopedia de la Ingeniería de Software. Wiley, 1994, pp. 528-532.
Addison Wesley, 2003.
[Belady76] Belady, L., y M. Lehman. Un modelo de desarrollo a gran programa.
IBM Systems Journal 15 (3): 225-252, 1976.
[Boehm00] Boehm, B., C. Abts, A. Brown, S. Chulani, B. Clark, E. Horowitz, R.
Madachy,
D. Reifer, y B. Steece. Estimación de costes de software con COCOMO II.
www.it-ebooks.info
Prentice Hall, 2000.
www.it-ebooks.info
CEREMONIAS 315
[Bush88] Bush, M. resultados de la inspección en el JPL. Actas del décimo Internacional

Conferen- cia de Ingeniería del Software. IEEE Computer Society Press, 1998.
proyectos de software. Ingeniería de las normas de recopilación, IEEE
producto: SE113. Instituto de Ingenieros Eléctricos y Electrónicos, agosto
de 2003.
[Kulak03] Kulak, D., y E. Guiney. Casos de uso: Requisitos en Contexto, 2ª ed. Addison
Wesley, 2003.
[McCabe76] McCabe, T. A medida de complejidad. IEEE Transactions on ingeniería de
software 2 (Diciembre 1976): 308-320.
[Mala97] Mala, YK, y J. Denton. ¿Qué representan los parámetros de software de modelo de
crecimiento fiabilidad? Actas del 8º Simposio Internacional sobre Ingeniería de
Software Fiabilidad. IEEE Press, noviembre de 1997.
[Myers74] Myers, G., y L. Constantine. diseño estructurado. IBM Systems Journal 13
(febrero de 1974): 115-139.
[Roed05] Roedler, GJ, y C. Jones. Medición técnico: Un conjunto de informes del PSM,
INCOSE, e Industria. INCOSE-TP-2003-020-01, versión 1.1 (27 de
diciembre de 2005). Disponible
enhttp://www.psmsc.com/Downloads/Technology Papeles /
TechnicalMeasurementGuide_v1.0.pdf.
[Rumb05] Rumbaugh, J., I. Jacobron, y G. Booch. El Manual de Lenguaje de Modelado
Unificado de referencia, 2ª ed. Addison Wesley, 2005.
[Russell91] Russell, G. La experiencia con la inspección en los desarrollos del ultralarge
escala. IEEE Software vol. 8, No. 1. (enero de 1991). pp. 25-31.
URL
[PSM] www.psmsc.com/Prod_TechPapers.asp
[SEI06] www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
CEREMONIAS
7.1. CMMI-DEV-v1.2 enumera dos áreas de proceso relacionadas en el área de

proceso de arrastre Con- Seguimiento y:
Planificación de proyectos, y
la medición y análisis.
Acceder al sitio Web en CMMI http://www.sei.cmu.edu/publications/
documentos / 06.reports / 06tr008.html, revisan el Seguimiento y Control
www.it-ebooks.info
área de proceso, y explicar brevemente cómo cada una de las dos áreas de
procesos relacionados con ellos se relacionan con Seguimiento y Control.
7.2. Las personas que juegan diferentes papeles en un proyecto de software
necesitan diferentes tipos de informes sobre la situación en relación con los
atributos del producto. Para cada uno de los siguientes, lista y explicar
brevemente los tipos de informes sobre el estado del producto que podrían
ser útiles para ellos (asumir un proceso de desarrollo iterativo):
a. cliente
b. gerente de proyecto
c. diseñadores
d. programadores
e. probadores
7.3. Sección 7.2 enumera cinco atributos de los proyectos de software a ser
medidos y Controlled: esfuerzo, horario, costo, características del producto
y los atributos de calidad del producto. Lista de otros tres atributos de un
proyecto de software que podría ser importante para medir y controlar.
Explicar brevemente por qué podrían ser importantes y cómo pueden ser
utilizados.
7.4. En la Sección 7.5 medición de la temperatura se utiliza para ilustrar la
diferencia entre las escalas de intervalo y de razón.
a. escalas Celsius y Fahrenheit tienen valores cero. Por qué no son escalas
de razón?
b. Proporcionar un ejemplo de una escala de intervalo no se menciona en el
texto que no es una escala de proporción. Si la escala tiene un elemento
cero, explicar brevemente por qué el elemento cero no significa que sea
una escala de razón.
c. Proporcionar un ejemplo de una escala de razón no se menciona en el
texto. Explique brevemente por qué el elemento cero de la escala hace
que sea una escala de razón.
7.5. Utilizar la Internet para encontrar un conjunto de reglas para contar líneas
de código. Brevemente explique las reglas.
7.6. Tablas 7.3 y 7.4 lista algunos directos y algunas medidas indirectas para
a. Enumerar las medidas directas e indirectas de los atributos del producto
en las tablas.
b. Enumerar las medidas directas e indirectas para el proceso de atributos en
las tablas.
c. Enumerar y explicar brevemente las medidas de productos de adición
directa de tres que podrían ser utilizados en un proyecto de software.
d. Lista 3 y explicar brevemente las medidas de productos indirecta
adicionales que podrían ser utilizados en un proyecto de software.
7.7. Explique brevemente por qué líneas de código es una medida directa del
tamaño del producto. Explique brevemente por qué los puntos de función es
una medida indirecta del tamaño del producto.
7.8. Figura 7.3 ilustra el diagrama de estado para el caso de uso en la Figura 7.2.
a. Enumerar los estados del diagrama de estados que proporcionan el
escenario principal para el caso de uso.
www.it-ebooks.info
b. Proporcionar nombres para y la lista de los estados de 3 escenarios
secundarios en el diagrama de estado.
www.it-ebooks.info
CEREMONIAS 317
c. Nombrar y explicar brevemente un escenario secundario que falta que

debe ser agregado al diagrama de estado.
7.9. En la Sección 7.6.2 se indica que la CCB debe tener la autoridad para
aceptar, aplazar o denegar una solicitud de cambio o un informe de
defectos.
a. Brevemente indique una circunstancia bajo la cual un BCC podría
aplazar una solicitud de cambio
b. Brevemente indique una circunstancia bajo la cual un BCC puede negar
una solicitud de cambio
c. Brevemente indique una circunstancia bajo la cual un BCC podría
aplazar un informe de defectos
d. Brevemente indique una circunstancia bajo la cual un BCC puede negar
a un informe de defectos
7.10. Tablas 7.6, 7.9, y 7.10 incluyen “número de defectos por categoría y nivel
de gravedad” para las necesidades, el diseño arquitectónico, y la aplicación,
respectivamente.
a. Enumerar tres categorías diferentes de defectos para los requisitos.
b. Lista tres categorías diferentes de defectos de diseño arquitectónico.
c. Enumerar tres categorías diferentes de defectos para su implementación.
7.11. En la barra lateral inspecciones se afirma que el desarrollador del material
que está siendo inspeccionado (es decir, el autor) nunca debería ser el
lector. Explicar brevemente por qué esto es una buena regla.
7.12. Refiérase a la Figura 7.6.
a. ¿Cuántos casos de prueba será necesario obtener cobertura de sucursales?
b. ¿Cuántos casos de prueba será necesario obtener cobertura de caminos?
(Pista: Sea n el número de recorridos de bucle.)
c. ¿Cuál es el número complejidad ciclomática de la gráfica? ¿Cuál es la
relación tionship de las respuestas a A y B a la complejidad ciclomática de
la gráfica?
7.13. Seleccione un programa de su elección (o un programa elegido por el
instructor).
a. Construir un gráfico de flujo de control para uno de los módulos del
programa.
b. Calcular el número complejidad ciclomática para uno de los módulos del
programa.
c. Construir la gráfica de flujo de diseño para el programa.
d. Calcular la complejidad del diseño del programa.
e. Evaluar y asignar un valor de muy baja, baja, nominal, alta o muy alta a
cada uno de los cinco factores utilizados para determinar la complejidad
CPLX en un modelo COCOMO II para el programa. Explicar
brevemente por qué eligió los valores que ha asignado a cada uno de los
cinco factores. (Pista: Véase la Tabla II-15, página 31, en ftp:. // ftp
usc.edu/pub/soft_engineering/COCOMOII/cocomo99.0/modelman.pdf.)
f. Evaluar y asignar un valor de baja, media o alta a la cohesión de cada
módulo en el programa. Explicar brevemente por qué eligió sus valores
asignados.
www.it-ebooks.info
g. Evaluar y asignar un valor de Baja, Media o Alta para el acoplamiento

de cada módulo en el programa. Explicar brevemente por qué eligió sus
valores asignados.
7.14. Un sistema que tiene un MTTF de 80 horas con una desviación estándar de
2 horas probablemente sería clasificado más alto en fiabilidad de un sistema
que tiene un MTTF de 80 horas y una desviación estándar de 40 horas.
Explicar brevemente por qué esto sería cierto.
7.15. El modelo de flujo de trabajo en la Figura 7.11 indica que cada defecto
encontrado durante la aceptación de un producto de trabajo o que se
encuentran en un producto de trabajo baseline debería notificarse mediante
un informe de defectos. Brevemente explicar una circunstancia en la que un
RD no puede ser presentada por un defecto detectado. Brevemente explica
los problemas que podrían ser creados por no presentar una DR.
7.16. Consulte la Tabla 7.23.
a. ¿Qué porcentaje de defectos totales fueron de defectos de diseño?
b. ¿Qué porcentaje de los defectos encontrados por usuarios (OPS) eran
defectos requisitos?
www.it-ebooks.info
ANEXO 7A
Marcos, estándares y directrices para medir

y controlar los productos de trabajo
7A.1 LA CMMI-DEV-v1.2 SEGUIMIENTO Y CONTROL DE PROCESO DE

LA ZONA
El propósito del Proyecto de Monitoreo y Control es proporcionar una comprensión

de los avances del proyecto para que las acciones correctivas apropiadas puedan ser
tomadas cuando el rendimiento del proyecto se desvía significativamente del plan.
Las metas específicas y prácticas específicas de control y mando en CMMI-DEV- v1.2

son [SEI06]:
SG 1 monitor contra el plan del proyecto

SP 1.1 monitorizar los parámetros de
planificación del proyecto SP 1.2
compromisos del monitor
SP riesgos del proyecto 1.3 monitor
SP gestión de datos 1.4 monitor
SP 1.5 Monitor de participación de los
interesados SP 1.6 Llevar a cabo
revisiones de progreso
SP 1.7 Realizar exámenes de hitos
SG 2 Administrar la acción correctiva para
el cierre SP 2.1 Analizar las cuestiones
SP 2.2 tomar medidas correctivas
SP 2.3 Manejo de acción
correctiva
Hay dos áreas de procesos relacionados con el CMMI-DEV-v1.2:
1. Planificación del proyecto y

2. Medición y Análisis.
319
www.it-ebooks.info
El área de proceso de Planificación de proyecto está cubierto de anexos a los

capítulos 5 y 6 de este texto.
Las metas específicas y prácticas específicas de Medición y Análisis son:
actividades SG 1 de medición y análisis Align

SP 1.1 Establecer objetivos de medición
SP 1.2 Especificar las medidas
SP 1.3 se indican los procedimientos de recogida y
almacenamiento de datos SP 1.4 se indican los
procedimientos de análisis
SG 2 proporcionan resultados de las
mediciones SP 2,1 medición
recoger datos SP 2.2 Analizar los
datos de medición
SP 2.3 Tienda datos y
resultados SP 2.4
Comunicar los resultados
ISO / EIC y Normas / EIA IEEE 12207 incluyen el monitoreo Proveedor como un
elemento de proceso de adquisición de la adquirente y Ejecución y Control como
proveedor actividad [IEEE12207]. actividad de supervisión de la entidad adquirente
se especifica en la sección 5.1.4 de 12.207,0, la supervisión del proveedor. Sección
5.1.4.1 indica que el adquirente control de los proveedores mediante el Proceso de
Revisión Conjunta y el proceso de auditoría, además del proceso de verifica- ción y
el proceso de validación, según sea necesario.
las actividades de ejecución y control del Proveedor (sección 5.2.5) incluyen
seguimiento e progreso el control y la calidad de los productos de trabajo durante
todo el ciclo de vida del proyecto. Esta actividad iterativa debe incluir el
monitoreo de rendimiento técnico, costos y horarios y el informe de estado del
proyecto. En problemas de suma deben ser identificados, grabado, analizado y
resuelto.
Iniciar
Acció Acción
n correctiva
Cerca
de
Informes Acció
de estado n
Evaluación
y análisis de
tendencias
FIGURA 7A.1 la resolución de problemas de bucle cerrado
Sección 6.8 de 12.207,0, Resolución de Problemas establece que el sistema de

resolución de problemas debe:
• ser de bucle cerrado,
• contener un esquema para categorizar y priorizar los problemas,
www.it-ebooks.info
7A.5 práctico software y sistemas de medición (PSM) 321
• incluir un procedimiento de análisis de tendencias, y

• proporcionar para la evaluación de la resolución de problemas y
disposiciones.
La naturaleza de bucle cerrado de la resolución del problema se ilustra en la

Figura 7A.1 del presente apéndice.
Cláusula 5.3 de la norma IEEE 1058-1998 para los planes de gestión de

proyectos de software (SPMPs) indica que los planes para el control de los
siguientes atributos de un proyecto deben ser incluidos en su plan de proyecto
[IEEE1058]:
• requisitos
• programar
• presupuesto
• calidad
En adición SPMPs que cumplen con IEEE 1058 contendrá un plan de recolección
de métricas y un plan de informes. El plan de gestión de riesgos está contenida en
la cláusula 5.4.
El PMI Cuerpo de Conocimiento (PMBOK) incluye los siguientes capítulos

relacionados con la medición y el control de un proyecto [PMI04]:
• Capítulo 5 Gestión del Alcance del Proyecto

• Capítulo 6 Gestión del Tiempo del Proyecto
• Capítulo 7 Gestión de los costos del proyecto
• Capítulo 8 Gestión de la Calidad del Proyecto
• Capítulo 9 Proyecto de Gestión de Recursos Humanos
• Capítulo 10 Gestión de la Comunicación del Proyecto
• Capítulo 11 del PMBOK® cubre Proyecto de Gestión de Riesgos.
7A.5 práctico software y sistemas de medición (PSM)
El informe de medición técnica: Un conjunto de informes del PSM, INCOSE, e

Industria es el resultado de un esfuerzo de colaboración entre el PSM (Practical
Software y Sistemas de Medición) y INCOSE (Consejo Internacional sobre
Sistemas de Inge- niería) organizaciones [Roed05]. El informe proporciona una
guía para la selección y aplicación de medidas técnicas para proyectos de
software y sistemas. Una introducción a Practical Software y sistemas de
medición se presenta en la Sección 7.8 de este capítulo.
www.it-ebooks.info
APÉNDICE 7B
PROCEDIMIENTOS Y FORMAS DE
INSPECCIONES DE SOFTWARE
7B.1 realización de una inspección SOFTWARE
Hay cinco (o seis) pasos para una inspección:
1. Llevar a cabo una reunión de planificación de corto para asignar las

funciones del equipo y programar un tiempo y lugar para la reunión de
Inspección. (Paso opcional: Tener un recorrido del documento para ser
revisado, dirigido por el autor, si es necesario familiarizar a los
participantes.)
2. Preparativos de la Reunión de Inspección mediante el uso de una lista de
verificación y completar una
personal Preparación individual Log.
3. Los miembros del equipo asisten a la Reunión de inspección, limitado a 2
horas.
4. Los miembros del equipo ayudan al autor, como se pide en las actividades de
seguimiento.
5. Tras la reanudación, el moderador y el autor se reúnen para preparar el
informe resumido de inspección.
Un diagrama de flujo para el proceso de inspección se ilustra en la Figura 7B.1.

Los detalles de cada paso:
Paso 1
El moderador y el autor se reúnen para planear la inspección: ¿quién debe
participar; qué materiales debe ser distribuido a los participantes y está disponible
para su referencia; es el material del autor listo para la inspección?
Paso 2
Tener una reunión de planificación para su equipo para distribuir materiales de
inspección y asignar funciones a los miembros del equipo. El autor debe
proporcionar una visión general de material a ser revisado, y si es necesario
para familiarizar a los participantes. También está programado un tiempo y lugar
para la reunión de Inspección. La reunión de revisión debe mantenerse
www.it-ebooks.info
322
www.it-ebooks.info
7B.1 realización de una inspección SOFTWARE 323
pocos días después de la reunión de planificación para dar tiempo a la

preparación individual, pero no tan largo que todo el mundo se olvida de su
preparación. La Reunión de inspección deberá ser planificada durante 2 horas.
Hay cuatro funciones del equipo para los cuatro miembros del equipo. Una
persona será el moderador, que se encarga de que sea el presidente de la Junta de
Inspección y preparar el paquete de revisión final con la ayuda del Autor. Otra
persona será el lector, cuyo trabajo consiste en parafrasear el documento que está
siendo revisado en la Reunión de Inspección. Una persona será grabadora. El
papel del registrador es para grabar en una inspección lista de defectos defectos
descubiertos durante la Reunión de Inspección. El autor del documento para ser
revisado asiste a la reunión para escuchar y responder a las preguntas. Todos los
miembros del equipo son inspectores de documentos.
3 1
Planificación Visión de Preparació Inspección Rehace Seguir
r
conjunt n 2-3 Hrs.
Aprox. Aprox. 2-
5 Hrs. 3 Hrs.
o 0,5-
1,5
1 2-4 Hrs. 2
Hor 4 .por 5 2 horas. 691
Inspector Max.
as.
7
tiempos de transición
1 Entrada Terc
2 1-3 días (si se incluye) era
3 Inmediato hora
4 Inmediato 8
5 3-5 días
6 Inmediato
(Opcional)
7 Inmediata (si se incluye)
8 Inmediato
9/10 1 semana Min. Después de
la inspección de salida 11
Dos Wk Max. proceso
Figura 7B.1 Diagrama de flujo para el proceso de inspección
Paso 3
Preparación individual: Cada persona debe planear para pasar de 2 a 3 horas
preparando para la reunión de Inspección mediante el estudio del documento a
ser inspeccionados y grabación descubierto defectos en una preparación de
registro individuales. Una lista de control de defectos se debe utilizar durante la
preparación individual.
Etapa 4
La Reunión de Inspección: Durante la Reunión de inspección, el lector podrá
presentar el documento parafraseando (resumiendo) de ella. Todos los miembros
del equipo, incluyendo el moderador, lector, grabadora, y el autor, contribuirán
los defectos que encontraron durante la preparación individual e (tal vez)
descubrir nuevos defectos. Vea las instrucciones para la realización de una
reunión en la inspección 7B.3. Defectos serán registradas por el registrador de la
lista de defectos Inspección y cada defecto se CAT- egorized de cuatro maneras:
www.it-ebooks.info
(1) por las iniciales de los buscadores; (2) como mayor, menor, o de la emisión;
www.it-ebooks.info
(3) como Falta, es incorrecto o extra; y (4) por Tipo de defecto. Ver la lista de
defectos Inspección incluida para más información.
Paso 5
Seguimiento: Después de la reunión, el autor va a corregir los defectos
encontrados durante la inspección, con la ayuda si así lo solicita. Esto debería
estar terminado en dos o tres días.
Paso 6
Preparación del informe de inspección: Después de que los defectos se corrigen,
el autor y moderador preparar el paquete de revisión. El paquete de revisión
incluye una portada, la lista de defectos de inspección, preparación individual de
registros, y el breve informe de inspección.
7B.2 el defecto LISTA
Durante la preparación individual y la Reunión de inspección, los defectos serán

clasificadas en cuatro formas: (1) por las iniciales de los buscadores; (2) como
mayor, menor, o de la emisión; (3) como Falta, es incorrecto, o adicional; y (4)
por Tipo de defecto.
Iniciales los buscadores son para la trazabilidad en caso de que el autor tiene
que hablar con el Finder (s) de un defecto en un momento posterior. Iniciales los
buscadores no son para contar que encontró el mayor número de defectos.
Una mayor defecto es uno que va a causar problemas serios en el futuro si no
se corrige ahora; un defecto menor es uno que debe ser corregido, pero se puede
corregir más adelante. Una cuestión abierta es algo que necesita más
investigación, por ejemplo, la posibilidad de un error en otro documento o si
clasificar algo tan Falta, es incorrecto o extra. Missing significa alguna
información necesaria no se proporciona; Wrong indica que la información es
incorrecta, y Extra significa que la información es innecesaria. requisitos
adicionales podrían ser características de los usuarios no necesitan, o información
que pertenece en otro documento, como el calendario y el presupuesto
información o asignaciones de personal.
La lista de verificación de defectos es diferente para diferentes tipos de
documentos. Una lista de control de ejemplo para las inspecciones de código es:
C1. La funcionalidad de la aplicación del diseño en el código

C2. Lógica entradas, salidas, pruebas de bucle, pruebas de rama, de
anidación, llamadas y devuelve entre módulos
C3. Los datos de uso-declaraciones, inicializaciones, misiones y usos
C4. Interfaces de coincidencia de listas de argumentos y otras interfaces,
códigos de retorno C5. bloques claridad de comentarios, comentarios,
nombres de variables, la sangría, blanco
espacio
C6. Mantenibilidad-facilitar la comprensión, la trazabilidad de diseño
detallado, pling y la cohesión aco-, cambiar la historia en el bloque de
comentarios de cabecera
C7. La sintaxis de uso de símbolos y puntuacion (nota: una compilación
limpia debe ser inspeccionado)
www.it-ebooks.info
7B.3 llevar a cabo una REUNIÓN DE INSPECCIÓN 325
C8. Archivos-declaraciones, de apertura, de cierre

C9. Estilo-uso de cabeceras de comentarios y comentarios en línea,
directrices para el estilo de programación
C10. Otros-defectos que no son de los tipos enumerados
tipos de defectos de los temas pendientes incluyen:
O1: cambios cuestionables para el diseño en el O2

código: Embalaje de los módulos de código
O3: Otras cuestiones abiertas
Listas de control deben adaptarse a las necesidades del proyecto y

organización en particular.
7B.3 llevar a cabo una REUNIÓN DE INSPECCIÓN
1. El Moderador primera establece el propósito de la reunión y describe el

documento que ser revisado. El moderador le pregunta a cada persona la
cantidad de tiempo que pasaron la preparación para la reunión de revisión y
se asegura de que todos estén preparados. Si alguien no está preparado, esa
persona es justificada o la reunión se reprograma.
2. El moderador pide al lector a comenzar. El lector presenta una breve visión
general del documento y parafrasea la primera sección. El moderador
pregunta si hay algún comentario sobre esa sección. Cada miembro del
equipo utiliza su tratamiento previo registro individual para contribuir
comentarios. (Si hay varios comentarios, el moderador le pide a cada
persona, a su vez, contribuir a uno de los comentarios.) El moderador dirige
la discusión equipo para determinar si el comentario es para ser aceptado
como un defecto. Si es así, las iniciales del Finder (s) se registra, y la
categoría de defecto es decidido por el equipo: (Falta, es incorrecto, Extra);
(Mayor, menor, de la emisión); y Tipo de defecto. La grabadora entre la
información en una Lista de Defectos de Inspección y hacer notas
adicionales según sea necesario. Antes de continuar, el moderador pregunta
si hay algún comentario adicional. Esto continúa hasta que se discuten todos
los comentarios. El moderador luego le pide a la siguiente persona si tienen
un defecto de contribuir; esto continúa hasta que todos los defectos son
registrados para esa sección del documento.
3. El moderador luego pide al lector que presentar la siguiente sección y el
proceso descrito en la etapa 2 se repite hasta que se terminó la revisión del
documento.
4. Después de la revisión de documentos está terminado, el moderador recoge
la lista de defectos de Inspección de la grabadora y la revisa con el equipo
para asegurarse de que el equipo está de acuerdo en los defectos
descubiertos y para asegurarse de que los defectos se describen de una
manera que todo el mundo (especialmente el autor, que corregirlos) puede
entenderlos.
5. El equipo de ayuda al moderador a preparar el informe de inspección.
www.it-ebooks.info
6. El moderador luego coteja el paquete de revisión, que incluye la portada, la

preparación individual de registros, las listas de inspección de defectos, y el
breve informe de inspección.
Todo el mundo debe recordar que el propósito de la reunión es encontrar

defectos, no de solucionarlos. Es el trabajo del moderador para mantener una
reunión productiva y para terminar la reunión de dos horas. El moderador debe
mantener en marcha el encuentro, pero no tan rápido que los principales defectos
se pierden.
El autor del documento recibe una copia de la lista de defectos en la
inspección final de la reunión. El autor y otros miembros del equipo son los
puntos de acción para ser completado dentro de una semana asignados. El autor
podría pedir a algunos miembros del equipo para pasar una “tercera hora”
informal después de la reunión de revisión para ayudar al autor, pero sólo si el
autor pide ayuda.
Después de que el autor ha fijado los defectos mayores (y tal vez los menores
también), se reúne con el moderador para verificar que los principales defectos
han sido corregidos y para completar el informe de síntesis. El moderador
también comprueba el estado de cualquier Cuestiones abiertas y genera puntos de
acción oficiales para cualquier trabajo que queda por hacer antes de enviar copias
del informe de síntesis al Arquitecto de Software y el Jefe Moderador. Esta
reunión debe ocurrir dentro de 5 a 10 días después de la reunión de inspección.
www.it-ebooks.info
LOG preparación individual
Nombre
Proyecto Fecha de recibido el paquete
Tipo de inspección: por ejemplo, el código de software
Fecha de Terminación
PREPARACIÓN HORA Fecha Tiempo usado
TOTAL DE HORAS Y MINUTOS:
Defectos / problemas abiertos

# Ubicación Tipo y Descripción
(número de línea)
1
NOTA: Añadir más páginas según sea necesario
www.it-ebooks.info
PORTADA INFORME DE INSPECCIÓN
Inspección ID # Fecha de inspección:

Proyecto:
Moderador: Telefono no:
correo electrónico:
Componente:
¿Es esta una nueva inspección? sí no
InspectorPhone No.RoleInspection Tipo

Requisitos del sistema: __
Requisitos de Software:
Diseño arquitectonico:
Diseño detallado: __
Código fuente: __
Plan de prueba: __
Resultados de la prueba:
Otro: __
Tamaño del Producto de Trabajo de inspección:
Referencia
Documentos:
comentario
s
Se recomienda una nueva inspección después de la reanudación? sí no
www.it-ebooks.info
INSPECCIÓN DE DEFECTOS LISTA

(Para el uso de grabador y autor)
Proyecto: Moderador:
Componente: Grabadora:
Tipo de inspección: Inspección ID #
Tipo Iniciale Fecha

Defecto Ubicació de Clasificación s del Corregido **
# n defect Mayor Menor Abrir Finder
o# /
#1 Desaparecido incorrecto extra
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
# 10 Desaparecido incorrecto extra
Descripción:
www.it-ebooks.info
Inspección ID #
Página de páginas
Tipo Iniciale Fecha

Defecto Ubicació de Clasificación s del Corregido **
# n defect Mayor Menor Abrir Finder
o# /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
#dieciséis Desaparecido
incorrecto extra
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Mayor Menor Abrir /
Descripción:
Nota: Re-inspección se recomienda después de la reanudación si

se encuentran más de 20 defectos.
Para ser completado después de re-trabajo:

fecha de terminación especificada para la
reanudación:
fecha de finalización real de la reanudación:
El tiempo dedicado por autor en Re-trabajo: (horas)
www.it-ebooks.info
RESUMEN INSPECCIÓN
Inspección ID # Fecha de inspección:

Proyecto: Moderador:
Componente: Telefono no:
¿Es esta una nueva inspección? sí sin correo electrónico:
Tipo de inspección:
Requisitos del sistema: Requisitos de Software: Diseño arquitectonico:
Diseño detallado: Código fuente Plan de prueba: Resultados

de la prueba: Otro:
Tamaño del Producto de Trabajo:
Total de horas-hombre Gastadas (mn):

Planifica Visión de Preparación Reunión Rehacer Seguir Tercer Total
ción conjunto individual a hora
Los
inspectores
Moderador
Autor (s)
defectos mayores
Número de defectos de tipo ha detectado que falten:
Número Corregido:
Número de defectos de tipo incorrecto Detectado: Número Corregido:
Número de defectos de tipo extra Detectado: Número Corregido:
DEFECTOS Gran Total:
Los defectos menores

Número de defectos de tipo ha detectado que falten:
Número Corregido:
Número de defectos de tipo incorrecto Detectado: Número Corregido:
Número de defectos de tipo extra Detectado: Número Corregido:
Los defectos menores TOTALES:
Problemas abiertos:
Problema: Cesionario:
www.it-ebooks.info
8
DE MEDIDA procesos de trabajo
Se puede ver mucho con sólo mirar.

-Yogi Berra
8.1 INTRODUCCIÓN A EQUIPOS DE MEDIDA procesos de

trabajo
Una introducción a las medidas, medición y control se presenta en el capítulo 7,

las secciones 7.1 y 7.2. Las secciones deben leerse como material de referencia
para este capítulo.
Hay varias razones para medir diversos atributos de los procesos de trabajo:
• para proporcionar indicadores frecuentes de progreso,

• para proporcionar una alerta temprana de problemas,
• para permitir el análisis de las tendencias para su proyecto,
• para permitir que las estimaciones del coste y la finalización fecha final de su
proyecto, y
• para construir un repositorio de datos de historias de proyectos para su
organización.
El modelo de flujo de trabajo para proyectos de software representados en la

figura 1.1 (Capítulo 1) y repetidas como en la Figura 7.1 ilustra las funciones de
medición y control en proyectos de software. La medición, notificación, la
replanificación y el control se destacan en la Figura 7.1. La medición del estado
del proyecto consiste en determinar los valores actuales y los valores acumulados
de varios atributos del proyecto. Como se relata en el capítulo 7, es

333
www.it-ebooks.info
334 DE MEDIDA procesos de trabajo
difícil imaginar un proyecto para el que un cierto nivel de medición y control

sobre cada uno de los siguientes atributos no es importante para asegurar un
resultado exitoso:
• esfuerzo: cantidad de trabajo empleado para diversas actividades de trabajo

• horario: logro de los hitos objetivamente medidos
• costo: los gastos para los diversos tipos de recursos, incluyendo el esfuerzo
• el progreso: los productos del trabajo completado, aceptadas y baselined
• Características del producto: requisitos implementados y demostraron que
trabajar
• atributos de calidad del producto: defectos, fiabilidad, disponibilidad, tiempo
de respuesta, rendimiento, y otros como se especifica
• riesgo: estado de los factores de riesgo y las actividades de mitigación
Los valores medidos de estos atributos del proyecto se comparan con los
valores planificados o especificado para cada intervalo de medida especificado en
el plan del proyecto. El control se ejerce cuando los valores reales se desvían de
los valores previstos o especificados por más de una cantidad aceptable; siendo
dos días de retraso en la consecución de un hito importante puede ser aceptable,
siendo dos semanas de retraso probablemente no es aceptable, pero siendo dos
meses de retraso desde luego no es aceptable.
En función de la importancia relativa de los diversos atributos de proceso y
producto de su proyecto, más esfuerzo se puede gastar en la medición y el control
de algunos de los atributos que en medir y controlar a los demás. El rendimiento
y la fiabilidad del software entregado pueden ser los criterios más importantes de
productos o puede ser que el control horario y costo del proyecto es necesario
para entregar un producto mínimamente aceptable es el más supremo. Sin
embargo, es difícil imaginar un proyecto en el que un cierto nivel de control
sobre el esfuerzo, horario, costo, características del producto y los atributos de
calidad especificados del producto no todos lo hacen contribuyen a un resultado
exitoso, aunque algunos atributos pueden ser más o menos importantes que otros.
Típicamente, el proceso de atributos (esfuerzo, horario, y el coste) son
equilibrado contra los atributos del producto (características y atributos de
calidad). Entre los atributos de proceso, el horario puede ser más importante que
el esfuerzo y el coste, y la seguridad puede ser un atributo del producto más
importante que la fiabilidad. Medición y control del esfuerzo, horario, costo, y el
progreso se tratan en este capítulo. La gestión de los factores de riesgo
relacionados con los atributos del producto y de proceso se trata en el capítulo 9.
Esfuerzo, costo y cronograma tienen atributos comunes, y cada uno tiene
atributos únicos. Los atributos comunes de esfuerzo, horario, y el costo para ser
medidos y Controlled incluir la cantidad y el porcentaje de cada uno que está
gastando en diferentes actividades del proyecto, incluyendo la gestión de
proyectos, análisis y diseño y aplica- ción, así como la verificación , validación, y
otras actividades de apoyo. Usted debe comparar los valores medidos con los
valores previstos y los valores esperados, siendo esta última derivada de los datos
históricos y las reglas locales de pulgar.
Por ejemplo, los proyectos de la organización podrían pasar típicamente 5% a
10% del esfuerzo total en la medición y control de los atributos del proyecto. Si
usted está gastando más, o menos, debe determinar qué este es el caso y aplicar
las medidas correctivas apropiadas. Puede ser, por ejemplo, que usted está
pasando del 15% al 20% del esfuerzo de medición y control, ya que su
organización es la conversión de un proceso de desarrollo caída Agua para el
www.it-ebooks.info
desarrollo iterativo y su proyecto es el primero
www.it-ebooks.info
8.1 INTRODUCCIÓN A LA MEDICIÓN 335
para poner en práctica el nuevo enfoque; la cantidad de esfuerzo que están

gastando en ción y control de medición es por lo tanto apropiado.
Por otro lado, si usted está gastando menos del 5% del esfuerzo de medición y
control, puede ser que usted no está pasando suficiente tiempo en la medición y
el control o que su (grande) del proyecto no tiene suficiente personal asignado a
su proyecto grupo de gestión para hacer un trabajo eficaz de medición y control.
Las relaciones entre el esfuerzo, el cronograma y el costo también deben ser
medidos y controlados. Por ejemplo, puede ser que usted espera gastar el 30% de
esfuerzo y el 40% de su horario de los requisitos y de diseño. Si se gasta
significativamente más o menos de cualquiera, debe determinar las razones y
tomar medidas correctivas, como se indica. La relación entre el esfuerzo y de
costes de personal también debe ser ured medi- y controlada. Si, en un período de
referencia dado, el esfuerzo es como estaba previsto, pero el costo de personal es
mayor de lo previsto, está utilizando más caros (más altamente cualificados) los
desarrolladores de software de lo previsto. El sobrecosto puede, por supuesto, ser
porque el trabajo es más difícil de lo previsto o porque el trabajo a realizar por
los analistas altamente cualificados y diseñadores está tomando más tiempo de lo
previsto.
Por el contrario, si en un período de referencia dado, el esfuerzo es como
estaba previsto, pero los costes de personal son más bajos de lo previsto, puede
ser que haya podido adquirir los niveles de habilidad necesarios o que el trabajo
es más fácil de lo previsto y las personas altamente cualificadas (altamente no
son necesarios pagados personal). Si el esfuerzo y el coste están a menos de lo
previsto, esto puede indicar que usted no ha sido capaz de adquirir el número
previsto de los desarrolladores de software, por lo que programar el progreso es
más lento de lo previsto. O bien, puede ser que el esfuerzo y el coste son más
altos de lo previsto debido a un deseo de acelerar el progreso horario.
Otros costos también deben ser medidos y comparados con los planes. costo
del viaje puede ser mayor (o menor) que planificada; costos de equipo se pueden
desviar de manera similar de plano. En cualquier caso, tendrá que investigar estas
desviaciones del plan.
Posibilidades de acción correctiva, cuando los valores reales de los atributos
del proyecto no están según lo previsto o esperado, incluyen:
• la adición de más recursos,
• el uso de recursos superiores,
• la mejora de diversos elementos del proceso de desarrollo, y / o
• de-la determinación del alcance de los requisitos del producto.
Recursos que podrían ser mejorados, añadidos o reemplazados incluyen:
• las personas (sean conscientes de la ley de Brooks al agregar personas),

• componentes de software (por ejemplo, la reingeniería de un componente de
software para mejorar el rendimiento),
• componentes de hardware (por ejemplo, más memoria, un procesador más
rápido), y
• herramientas de software (por ejemplo, un procesador de lenguaje o
herramienta de prueba).
Nunca se debe utilizar las siguientes técnicas para “conseguir un proyecto

nuevo en marcha:”
www.it-ebooks.info
• niveles y duración de las horas extraordinarias excesivas;

• reducción o eliminación de las actividades de verificación y validación
previstas;
• reducción o eliminación de la documentación prevista usuario, ayudas de
formación, y así sucesivamente; o
• reducción o eliminación de cualquier actividad planificada que reduciría las
características o atributos de calidad del sistema para ser entregados sin el
consentimiento del cliente.
Este capítulo presenta métodos y técnicas para medir y controlar los procesos de
trabajo (medida y control de los productos de trabajo fueron presentados en el
capítulo 7). Después de leer este capítulo y completar los ejercicios usted debe
entender cómo:
• medir y analizar el esfuerzo original, la reanudación de la evolución, y la

reanudación evitable;
• utilizar paquetes de trabajo para rastrear el esfuerzo, el programa y los
• utilizar el seguimiento binario para evitar el síndrome completado 90%, y
por lo tanto a acu- rado determinar el estado de esfuerzo, el programa y los
productos de trabajo, y para estimar el esfuerzo mate y horario para
completar un proyecto;
• utilizar los informes del valor ganado, basado en el seguimiento binario, para
proporcionar informes concisos y precisos de lo posible, el calendario y el
progreso del trabajo; y
• utilizar técnicas de valor ganado para pronosticar el costo real estimada y la
fecha estimada de finalización de los proyectos de software.
Como se relata en el capítulo 7, CMMI-DEV-v1.2, ISO / IEEE 12207, el estándar

IEEE 1058, y la Guía PMBOK del PMI toda proporcionar orientación para la
medición y control de los proyectos de software. Véase el Apéndice 7A en el
Capítulo 7.
8.3 La medición y análisis ESFUERZO
Como se ilustra en la Figura 8.1, hay tres categorías de esfuerzo [Fairley05]:
• Trabajo original,
• retrabajo evolutiva, y
• retrabajo evitable (retrospectiva y correctivo).
El trabajo original es el esfuerzo realizado en el establecimiento de líneas de

base iniciales de productos de trabajo (por ejemplo, requerimientos, diseño,
código, planes de prueba). retrabajo evolutiva es el esfuerzo que gasta para
www.it-ebooks.info
cambiar productos de trabajo baselined de manera que añaden valor a una
www.it-ebooks.info
8.3 La medición y análisis ESFUERZO 337
esfuerzo
taxonomía
Trabajo
rehacer
original
evolutivo evitable
retrospectivo correctivo
FIGURA 8.1 Una taxonomía del esfuerzo

del proyecto
la evolución de producto o sistema. Por ejemplo, el diseño y la parte del código

pueden tener que ser modificados debido a un cambio en los requisitos que
resulta de análisis del nuevo producto de un competidor o de un cambio de
misión para el sistema de misión crítica de un cliente.
retrabajo evitables se retrabajo necesario realizar cambios en productos de
trabajo baselined desarrolladas durante el trabajo original o la reanudación de la
evolución. En principio, la reanudación evitables (como su nombre indica) es un
trabajo que no debería tener que hacer. Debido a que los seres humanos no son
infalibles, alguna pequeña cantidad de trabajo es evitable e inevitable. Como se
indica en la Figura 8.1, hay dos tipos de retrabajo evitable: retrospectivos y
correctivas. retrabajo retrospectiva se produce en el desarrollo de la cascada, por
ejemplo, cuando el código tiene que ser modificados debido a defectos
encontrados durante el programa La verificación de los que sea una base
inadecuada para la validación del sistema. retrabajo retrospectivo ocurre en el
desarrollo iterativo cuando un producto de trabajo baseline tiene que ser vuelto a
trabajar para adaptarse a las necesidades de una iteración posterior. En el
desarrollo iterativo, por ejemplo, una interfaz de código baselined podría tener
que ser rediseñado y recodificada para proporcionar una base para el código de la
siguiente iteración que se va a integrarse en el creciente línea de base del
producto. Las cantidades excesivas de retrabajo retrospectiva pueden indicar la
necesidad de una mayor atención al diseño de interfaces, por ejemplo.
retrabajo correctiva se produce cuando un defecto descubierto en un producto
de trabajo baseline se corrige. Debido a la reanudación correctiva es el resultado
de defectos hechas por errores humanos, y porque los seres humanos son
humanos, una cierta cantidad de retrabajo evitable es de esperar. Un gran
porcentaje de esfuerzo total dedicado a la reanudación evitables, como una fiebre
alta en una persona enferma, es un problema en sí mismo; más
significativamente, es una indicación tor de otros problemas graves. En el caso de
proyectos de software, los altos niveles inaceptables de retrabajo evitables son un
síntoma de los procesos de trabajo ineficientes e ineficaces.
Refactorización de software durante el desarrollo iterativo es un ejemplo de las
diferencias entre la reanudación de la evolución, retrabajo retrospectiva, y
retrabajo correctiva. retrabajo evolutiva se produce cuando refactorización del
software existente se realiza para dar cabida a los nuevos requisitos que no
hubieran podido preverse en un proceso iterativo de desarrollo. retrabajo
retrospectiva se produce cuando una característica previsto necesaria como base
para la iteración actual no está incluido en la iteración anterior y por lo tanto hay
que añadir ahora. retrabajo retrospectiva por lo general requiere más esfuerzo que
habría sido necesaria para incluir la característica necesaria durante la iteración
anterior. retrabajo correctiva se produce en un proceso de desarrollo iterativo
www.it-ebooks.info
cuando los errores son descubiertos en los productos de trabajo que han sido
revisados, probados y aceptados.
www.it-ebooks.info
Por desgracia, muchas organizaciones no miden por separado y se informan

trabajo original, la reanudación de la evolución, retrabajo retrospectiva, y la
reanudación de corrección, por lo que son conscientes de cómo se gastan los
recursos del proyecto. En muchas organizaciones, retrabajo evitable es de 50% y
más del esfuerzo total del proyecto; en estas organizaciones, la mitad o más de
esfuerzo es por lo tanto pasó en errores de fijación realizados por los desarrollos
de software ERS [Basili94], [Boehm01].
retrabajo evitable es la pesadilla de la mayoría de las organizaciones de
desarrollo de software. retrabajo evitable de 5% o menos del esfuerzo total se
alcanza en las mejores organizaciones de software; 20% o menos retrabajo
evitable es alcanzable y debe ser un objetivo para todas las organizaciones de
software, incluyendo el suyo [Fairley05].
Debido a que el desarrollo de software es-intensivo esfuerzo, la reelaboración
evitables mejora la productividad y la moral de los trabajadores y la calidad de
los productos de trabajo. Debido a la reanudación evitables consume recursos
del proyecto que podrían destinarse a la obra original o la reanudación de la
evolución, la reelaboración evitables mejora la productividad. Debido a que los
desarrolladores de software pueden pasar su tiempo haciendo el trabajo de alta
calidad original y la reanudación de la evolución en lugar de la corrección de
errores, mejora su estado de ánimo. Debido a que un cierto porcentaje de defectos
escapará el proceso de desarrollo y ser encontrado por los usuarios, la
reelaboración evitables también mejora la calidad del software entregado. Si, por
ejemplo, la reanudación evitables durante el desarrollo corrige defectos 200 y un
5% adicional de defectos de desarrollo se encuentran los usuarios durante el
primer año de funcionamiento, los usuarios encontrarán aproximadamente 10
defectos durante el primer año. Por otro lado, si la reanudación evitables fija 20
defectos durante el desarrollo de software, los usuarios encontrarán 1 defecto.
Las cantidades de, y relaciones entre, los cuatro tipos de trabajo (trabajo
original, de retrabajo cionario evolu-, trabajo de repaso retrospectivo, retrabajo
correctivo) deben ser ured separado medi-, analizado y reportado periódicamente.
Medición puede revelar que grandes cantidades de retrabajo evolutiva se están
realizando sin cambios apropiados en el plan baseline para esfuerzo y horario, o
que retrabajo correctiva es una fracción no puede signifi- del esfuerzo total.
Debido a la reanudación de la evolución es de valor añadido, no debería ser un
problema para usted, el director del proyecto, previstos ajustes correspondientes
se han realizado a los planes de esfuerzo, horario, y otros recursos necesarios
para dar cabida a los cambios. retrabajo evolutiva puede ser un gran problema
cuando los cambios de valor añadido al producto o sistema son obligatorias y sin
ajustes en otros atributos del proyecto correspondiente.
Se puede medir la cantidad de esfuerzo para cada tipo de trabajo de
seguimiento:
• Los paquetes de trabajo para el trabajo original de la EDT,

• esfuerzo resultante de las solicitudes de cambio para la reanudación de la
evolución, y
• esfuerzo resultante de informes de defectos para retrabajo retrospectivo y
retrabajo correctiva.
Su sistema de gestión de la configuración puede proporcionar los datos

necesarios para producir los informes de estado (ver los capítulos 3 y 7).
(paquetes de trabajo presentados en el capítulo 5) son un mecanismo para
documentar las tareas en una estructura de división del trabajo. El trabajo original
www.it-ebooks.info
se puede seguir mediante el aumento de las plantillas de los paquetes de trabajo,
tal como se indica en la Tabla 8.1, para incluir campos para el registro de las
cantidades reales de esfuerzo, el cronograma y los recursos gastados, y el trabajo
real
www.it-ebooks.info
8.4 MEDICIÓN Y ANÁLISIS DE ESFUERZO REWORK 339
TABLA 8.1 Una plantilla paquete de trabajo aumentada reportar

programada versus resultados reales
Tarea CARNÉ DE IDENTIDAD: «Número WBS»
Tarea identificador: «Nombre de la EDT»
Tarea descripción: "breve descripción"
Estimado duración: «Días o
semanas» Recursos necesarios:
Personal: «Número de personas necesarias para completar
esta tarea»
Habilidades: «Habilidades personal necesario para completar
esta tarea»
Herramientas: «Software y hardware necesario»
Viajar: "¿A donde? ¿por cuanto tiempo?"
Otro: «Otros recursos necesarios para completar esta
tarea»
Predecesor Tareas: «Para ser completado antes de que esta tarea
puede empezar»
Sucesor Tareas: «Se puede iniciar después de esta tarea se ha
completado»
productos de trabajo: «Resultados de esta tarea»
Las líneas de base: «Productos de trabajo para ser colocado bajo
control de versiones»
Riesgo factores: «Problemas potenciales para esta tarea»
Criterios de aceptación: «Para los productos de trabajo de esta tarea»
Comenzando Fecha: planeado real
Finalizando Fecha: planeado real
Personal: planeadas real
Otro recursos previstos: real
Trabajo los productos previstos real
productos producidos. Debido a que cada paquete de trabajo produce una o más
productos de trabajo que se colocan bajo el control de la línea de base después
de que satisfacen sus ria terios de aceptación, plantillas para el registro de valores
reales se pueden proporcionar como parte del proceso de registro de entrada al
sistema de gestión de la configuración. Un paquete de trabajo que utiliza el
seguimiento binario no está cerrada (es decir, una tarea no se completa) hasta que
los productos de trabajo satisfacen sus criterios de aceptación y se proporcionan
los valores aumentados. A continuación, los resultados reales pueden compararse
con los resultados previstos para cada tarea completada y colecciones completas
de tareas.
8,4 medición y análisis ESFUERZO REWORK
Las matrices de reproceso, similar en formato a la matriz defecto presentado en el

capítulo 7, se pueden utilizar para registrar y analizar el esfuerzo de retrabajo.
Una plantilla para matrices de reproceso se presenta en la Tabla 8.2 y un ejemplo
de una matriz de retrabajo correctiva se presenta en la Tabla 8.4; la matriz es para
un sistema que ha estado en funcionamiento durante 12 meses. Tenga en cuenta
que las copias de la plantilla de la Tabla 8.2 se pueden utilizar para informar por
separado lutionary evo-, retrospectivo, y retrabajo correctiva.
www.it-ebooks.info
Tabla 8.3 proporciona una leyenda parcial para las entradas en la Tabla 8.2, y
estas descripciones debe ser suficiente para explicar las entradas restantes. La
fase de “un tipo particular de reanudación” en la Tabla 8.3 significa una de
retrabajo evolutiva, retrabajo retrospectiva, o retrabajo correctiva.
www.it-ebooks.info
TABLA 8.2 Una plantilla para matrices de retrabajo

Tipo de retrabajo: evolutivo retrospectivo correctivo
Cuando se produce la fase de retrabajo:
Producto de Rqmts. Diseño Imple. Verif. Válido. Ops. Los
trabajo: totales
Rqmts. RRR RRD RRi RRve RRva RRO 
Diseño DRd DRi drve DRVA DRO 
Imple. IRi IRve IRva IRO 
Verif. VEve VEva VE 
Válid Vavá O 
o. VA
Los totales       TOTAL
O
TABLA 8.3 Una leyenda parcial para la Tabla 8.2

ReworkKind de Rehacer
Rrra tipo particular de retrabajo de los requisitos durante los requisitos de
aceptación de línea de base
RRDA tipo particular de la reanudación de las necesidades durante una
actividad de diseño RRIA tipo particular de la reanudación de las necesidades durante
una implementación
actividad
RRveA tipo particular de la reanudación de las necesidades durante una actividad
de verificación RRvaA tipo particular de la reanudación de las necesidades durante una
validación actividad
requisitos RqRAll retrabajo de un tipo particular durante todas las
actividades de desarrollo de software
ImTAll retrabajo de un tipo particular durante una actividad de implementación
TOTALAll retrabajo de un tipo particular durante todo el desarrollo de software
ocupaciones
TABLA 8.4 retrabajo esfuerzo personal en horas para un producto hipotético, pero realista,
software
Retrabajo del informe: evolutivo retrospectivo  correctivo total
Cuando se produce la fase de retrabajo:
Tipo de retrabajo: Rqmts. Diseño Imple. Verif. Válido. Ops. Los totales
Rqmts. 200 150 130 120 138 300 1038
Diseño 360 299 300 365 701 2025
Imple. 800 800 920 1000 3520
Verif. 60 150 0 210
Válido. 70 0 70
totales: 200 510 1229 1280 1643 2001 6863
Tabla 8.4 proporciona un ejemplo de una matriz de retrabajo-esfuerzo para un

producto de software hipotética pero realista durante el desarrollo y los primeros
12 meses de operación.
Nota, por ejemplo, la gran cantidad de esfuerzo de la reanudación en la Tabla
8.4 necesario para corregir los requisitos de defectos que no fueron encontrados
durante los requisitos de trabajo actividades (1038-200: 80%). Tenga en
cuenta también que los 3 requisitos defectos encontrados por los usuarios (Tabla
8.5) requiere más esfuerzo que el 50 encontrado durante el examen de los
www.it-ebooks.info
requisitos
www.it-ebooks.info
8.4 MEDICIÓN Y ANÁLISIS DE ESFUERZO REWORK 341
(300 personas-horas frente a 200). Por otro lado, los mayores porcentajes de
esfuerzo fue retrabajo de los defectos encontrados por los usuarios; 29% de todo
el retrabajo correctiva se produjo durante los primeros 12 meses de
funcionamiento del sistema (2001/6863). Suponiendo un mes de trabajo es de
152 personas-hora y que un año de trabajo se compone de 11 personas-mes por
persona, man- tenance correcciones durante el primer año se requiere personal de
aproximadamente 1.2 FTE (2001 / [11 * 152]).
Un enfoque alternativo para la determinación de esfuerzo retrabajo puede
basarse en una matriz de defecto tal como el que se ilustra en la Tabla 8.5 y un
modelo de retrabajo exponencial tal como el representado en la figura 8.2.
Figura 8.2 se normaliza a 1 personal-hora para arreglar un defecto que se
encuentra durante las actividades laborales los requisitos, 1,5 personal-hora para
fijar el defecto durante el diseño, 2,5 personal horas solucionarlo durante la
implementación, 5 personal-hora durante software verificación, 10 personal-hora
durante la validación del sistema, y 25 personas-hora si se encuentra por los
usuarios (es decir, durante el funcionamiento del sistema). La Figura 8.2 es
realista, pero debe ser verificada o corregida utilizando los datos históricos
locales. Muchas organizaciones han informado aún mayor crecimiento
exponencial en el esfuerzo necesarios para corregir defectos.
Si se tarda más (o menos) que el personal 1 hora para arreglar un defecto que
se encuentra en una fase de requisitos, el esfuerzo para solucionar el defecto se
debe multiplicar por ese factor. Por ejemplo, si se lleva a 4 personas-hora para
arreglar un defecto requisitos durante los requisitos de aceptación, será 100
personas-hora para fijarlo si se encuentra por los usuarios (4 25).
TABLA 8.5 Un ejemplo de una matriz de defectos para un proyecto terminado

Fases Cuando defectos encontrados:
Tipos de defectos: Rqmts. Diseño Imple. Verif. Válid Ops. Los totales
o.
Rqmts. 50 25 13 6 3 3 100
Diseño 60 30 15 8 7 120
Imple. 80 40 20 10 150
Verif. 6 3 0 9
Válido. 7 0 7
totales: 50 85 123 67 41 20 386
esfuerzo 25.0
25
relativo
20
15
11.5
10
5.0
5 2.5
1.0 1.5
1
RqmtsDesignImple.Verif. Válid ops
o.
Fase
FIGURA 8.2 esfuerzo relativo para corregir un defecto
www.it-ebooks.info
TABLA 8.6 Crecimiento exponencial del multiplicador esfuerzo para arreglar un defecto
para una hipotética, pero realista, la organización
Esfuerzo Multiplica Esfuerzo Esfuerzo Esfuerzo
Multiplica dor Multiplic Multiplic Multiplic
dor para esfuerzo ador para ador para ador para
Fase de trabajo Rqmts. por Imple. Verif. XHTML.
defectos defectos defectos defectos defectos
requisitos 1
de diseño
Diseño 1.5 1
Implementación 2.5 1.66 1
Verificación 5 3.33 2 1
Validación 11.5 7.6 4.6 2.3 1
operaciones 25 16.7 10 5 2.17
Factores de multiplicación para fijar otros tipos de defectos en las fases

posteriores se enumeran en la Tabla 8.6, que se basa en la Figura 8.2.
Los resultados basados en las Tablas 8.5 y 8.6 están en la Tabla 8.4,
suponiendo que se necesita, en promedio, 4-persona de horas para arreglar un
defecto requisitos durante la fase de requisitos, 6-persona de horas para corregir
un defecto de diseño durante el diseño, y 10 personal- horas para corregir un
defecto de aplicación durante la ejecución, un defecto de verificación durante la
verificación y validación de un defecto durante la validación. Usted puede
desarrollar fácilmente un programa de hoja de cálculo para registrar datos de
defectos y realizar los cálculos de reproceso deseados.
Los valores relativos de la Tabla 8.6 y el ejemplo en la Tabla 8.4 hacen que
sea evidente que el esfuerzo gastado en encontrar y corregir defectos tan pronto
como sea posible es esfuerzo bien invertido. Los patrones de valores de la Tabla
8.4 indican dónde deben concentrarse los esfuerzos de mejora de procesos para
reducir la reanudación.
8.5 SEGUIMIENTO DE ESFUERZO, calendario, y COST;

ESTIMACIÓN DE FUTURO ESTADO
Como se ilustra más arriba, los mecanismos básicos para el seguimiento de

esfuerzo, horario, y el costo de los proyectos de software son paquetes de trabajo
para el trabajo original, y las solicitudes de cambio y los informes de defectos
para la reanudación; Las solicitudes de cambio documento se da cuenta de
reproceso y defectos evolutivos documentan retrabajo evitable (retrospectiva y
correctivo). Recordemos que cada paquete de trabajo, solicitud de cambio, o
informe de defectos deben producir uno o más tangibles productos de trabajo que
pueden ser verificados usando criterios de aceptación objetivas. Los datos pueden
ser recogidos por el trabajo realizado y el análisis detallado de diversos tipos de
actividades de trabajo, tales como la reanudación correctivo, se pueden realizar.
Estos mecanismos también pueden ser usados para informar sobre el progreso en
los niveles más gruesas de granularidad proporcionando informes resumidos de
esfuerzo total, coste (de costes de personal más otros costos) y calendario de los
productos de trabajo desarrollados o modificados.
8.5.1 Seguimiento binario

seguimiento binaria es la técnica fundamental para el seguimiento con precisión
el estado del proyecto; el concepto se denomina “resultados binarios” por Tom
www.it-ebooks.info
DeMarco [DeMarco82]. Cada
www.it-ebooks.info
8.5 SEGUIMIENTO ESFUERZO, horario y costo 343
paquete de trabajo, solicitud de cambio, y el informe de defectos produce uno o

más productos de trabajo que deben satisfacer los criterios de aceptación
objetivas antes de la nueva versión (s) se convierten en líneas de base. Una tarea
(un paquete de trabajo para el trabajo original, una solicitud de cambio, o un
informe de defectos) se cuenta como 0% completo hasta que el producto de
trabajo asociado satisface sus criterios de aceptación. El producto de trabajo es
entonces considerado como 100% completa; seguimiento es, pues binario.
seguimiento binaria ayuda a evitar el síndrome completa el 95% de los
proyectos de software. Seguimiento de los progresos en una base “cálculo
aproximado” a menudo se traduce en proyectos que son reportados a ser un 95%
durante largos períodos de tiempo. seguimiento binario, tal como se representa en
la figura 8.3, donde cada “X” representa un progreso basado en el seguimiento
binaria de paquetes de trabajo, proporciona un seguimiento preciso del progreso
real. También tenga en cuenta en la figura 8.3 que el progreso real se desvía de
los avances previstos al principio del proyecto. La acción correctiva debería
haber sido tomada a más tardar el segundo mes del proyecto.
Figura 8.3 ilustra la máxima de seguimiento binario:
Es mejor ser 100% completo con un 90% de la obra, y sé que es verdad (rastreo
binaria en el mes 10), que pensar que está completo al 90% con el 100% de la obra,
y espero que sea cierto (el guesstimate al mes 5).
Ya que el seguimiento binaria no da crédito por el trabajo en curso, la exactitud

de seguimiento binario puede ser mejorada mediante el seguimiento en los
niveles más sutiles de la granularidad. Figura 8.4 ilustra seguimiento binaria de
paquetes de trabajo en una estructura de división del trabajo. Como se ilustra, las
tareas (los nodos hoja de la EDT) se cuentan como 0% completo o 100%
completo. terminaciones porcentuales para las actividades de nivel superior se
calculan en función de los porcentajes de finalización de las tareas y actividades
subordinadas. Por simplicidad de presen- tación, cada paquete de trabajo en la
Figura 8.4 se supone que requiere cantidades iguales de esfuerzo. La precisión
puede ser mejorada mediante la ponderación de cada tarea por cantidad relativa
de esfuerzo, tal vez en una escala de 1 a 5.
Paquetes de trabajo 3.1.2, 3.2.2, y 3.2.3 en la figura 8.4 puede ser 70% o 80%
completo (o 95%), sino por el seguimiento binario no se da crédito hasta que los
productos de trabajo asociados satisfacen sus criterios de aceptación.
Progreso informó en un 95%

100% planifica x
x
do x
80% Progres x xx
o x
xx
60% x reportad
x o
x
40% x Progres
x
x o
x
20% x real
xx
x Progres
0% x x xx o
24 6 810 12 Meses
fecha de entrega prevista
FIGURA 8.3 Ilustrando el síndrome completa 95%

www.it-ebooks.info
3.
Codifica 41,5% completa
ción
3.1 3.2
Módul Módulo
50% 33%
o de de
entrada proceso
3.2.1 3.2.2 3.2.3

3.1.1 3.1.2
format Edit Procesa
Obt compr o de ar r
ener obar datos dato datos
el la 100 0%
s0%
aport
100% 0%
entra
e da
Figura 8.4 seguimiento binaria de paquetes de trabajo
3.
Codifica 71% completa
ción
3.1 3.2
Módulo 75% Proceso 67%
de Módulo
entrada
3.1.1 3.1.2 50% 3.2.1 100% 3.2.2 50% 3.2.3 50%

100%
Obt Comprob format Edit Proceso
ener ar o de ar Datos
el Entrada datos dato
apor s
te
3.1.2.1 3.2.2.1 3.2.2.2 3.2.3.1 3.2.3.2
3.1.2.2
Manejo Edit Edit Proc. Proc.
Esca
de errores ar ar Incr1 Incr2
near
Incr1 Incr2 100%
Entr 100% 0% 0%
100%
ada 0%
FIGURA 8.5 Mayor nivel de detalle en el rastreo binaria de paquetes de
trabajo
La precisión de seguimiento puede ser mejorada por la descomposición de la

obra en pequeñas tareas, como se ilustra en la Figura 8.5, donde se puede
observar que las actividades 3.1.2, 3.2.2, y
3.2.3 son cada uno un 50% el uso de seguimiento completo binario. Una vez más,
asumiendo todas las tareas requieren el mismo esfuerzo, el mismo proyecto es de
71% de avance.
Aumentar el nivel de descomposición de la Figura 8.4 hasta 8.5 aumentó La
exactitud de orientación de informes de estado de 41,5% completa a 71%
completa. En general, las tareas más pequeñas (es decir, las unidades más
pequeñas de esfuerzo) aumentan la exactitud de la información, pero a los riesgos
de la micro y de los recursos del proyecto excesivos dedicados a la medición y
control. Para evitar estos problemas potenciales, las tareas deben ser no menor
que un miembro del personal semanas de esfuerzo. los desarrolladores de
software individuales (o programadores de pares, como en el desarrollo ágil) se
pueden descomponer su trabajo en unidades más pequeñas, por ejemplo,
www.it-ebooks.info
8.5 SEGUIMIENTO ESFUERZO, horario y costo 345
completar varias iteraciones en un producto de trabajo durante un ciclo semanal,

pero para fines de medición y control, las tareas no debe ser inferior a un
personal semanas.
Después de que el producto de trabajo asociado satisface sus criterios de
aceptación, un paquete de trabajo, solicitudes de cambio, o informe de defectos
está cerrada y nunca volvió a abrir. ciones modificaciones posteriores de los
productos de trabajo se documentan en las nuevas solicitudes de cambio y los
informes de defectos. El límite superior de tamaño de la tarea se determina por
consideraciones de riesgo. Recordemos que los objetivos fundamentales de la
medición y el control son proporcionar onstrations demos- frecuentes de progreso
y alerta temprana de problemas cuando el progreso no es como estaba previsto o
esperado. Si una tarea tiene como alcance a requerir una gran cantidad de
esfuerzo y la finalización de la tarea no está como estaba previsto, la alerta
temprana de problemas no será
adquirido. Una regla de oro es:
cada tarea en su proyecto de software debería requerir entre 1 semana y el

personal-1 personal- mes de esfuerzo.
Porque el esfuerzo es el producto de personas y el tiempo, una tarea personal de 2

semanas podría lograrse por 2 personas en una semana, lo que proporciona una
medida semanal del progreso, que es altamente deseable.
Supongamos que su proyecto está en el ámbito de requerir 5 personas durante 12
meses (5 años-persona de esfuerzo). Si cada tarea en el proyecto requiere de 2
personas-semanas de esfuerzo, el proyecto consta de 120 tareas (o 240 si las tareas de
cada tarea es de 1 personal semanas de esfuerzo); 120 tareas serían, en promedio, 10
tareas a realizar cada mes (miembro 2 tareas por el personal por mes). Como se
discutió en la sección 5.2, la planificación a este nivel de detalle se realiza mejor en
una, de manera incremental olas de rodadura.
Los proyectos más grandes (por ejemplo, 10 personas para 12 meses, 20
personas de 24 meses, o 200 personas durante 30 meses) deben ser organizados
en equipos de 5 o menos personas-miembros por equipo, como se ha discutido en
el capítulo 1 e ilustrado en la Figura 1.3. Es deber de cada jefe de equipo, trabajar
con ella o con miembros de su equipo, para negociar las tareas semanales,
asegurar que los criterios de aceptación de los productos de trabajo están
satisfechos, y el uso de ING pista- binaria para reportar el progreso (o falta de
ella) para el director del proyecto y otra Apropiada interesados.
8.5.2 Estado estimar las futuras

Tabla 8.7 ofrece un ejemplo del uso de rastreo binaria para determinar el estado
del proyecto. La tabla indica que 270 de 300 baselined requisitos están
suficientemente cubiertos por la arquitectura del producto. especificaciones de
diseño detallado para 750 módulos de la arquitectura se han baseline, 500
módulos de código se han codificado, verificado, y aceptada como líneas de base,
a 200 módulos se han integrado y baseline con éxito, y el código para 43
requisitos ha sido validado y baseline (es decir, el código se ha demostrado para
satisfacer los fines previstos en su entorno previsto).
Claramente, el producto está siendo desarrollado de una manera iterativa
porque el código para el 20% de los requisitos ha sido validado y el diseño de 30
requisitos aún no se han completado. La columna “porcentaje completado” es
preciso porque se está informando de rastreo binaria de productos de trabajo.
Trabajo basado en los 30 restantes requisitos podrá ser del 80% o el 90%
www.it-ebooks.info
completado pero no contar con ellos como medidas de progreso hasta que se
completa al 100%.
www.it-ebooks.info
TABLA 8.7 Ejemplo del estado del proyecto mediante el

seguimiento de binario
Estado porcentaje completa
270 de 300 requisitos remontar a diseñar 90%
750 de 1000 módulos diseñados y aceptadas 75%
500 de 1000 módulos codificada y aceptadas 50%
200 de 1000 módulos integrados 20%
43 de 300 requisitos validados 14%
TABLA 8.8 Porcentaje de esfuerzo para diversas actividades de

trabajo
Actividad de trabajo Porcentaje de esfuerzo de
desarrollo
Diseño arquitectonico 17%
Diseño detallado 26%
La codificación y la unidad de prueba 35%
La integración y verificación 10%
Validación 12%
Tabla 8.8 se utiliza para determinar el porcentaje global completado para el

proyecto. La tabla contiene porcentajes típicos de esfuerzo de varios tipos de
actividades de trabajo en la organización donde se realiza el proyecto.
De las Tablas 8.7 y 8.8 se puede determinar que el 17% de la obra es de 90%
(diseño arquitectónico), 26% del trabajo es 75% completo (detallado diseño), y
así sucesivamente. La combinación de las dos tablas proporciona el porcentaje
global completado para el proyecto:


El proyecto es 56% completo, y por lo tanto 44% del trabajo permanece para ser
completado. Supongamos que el proyecto se encuentra al final de su séptimo mes
y 75 meses-personal de esfuerzo se ha gastado hasta el momento. Si 75 meses-
personal es del 56% del esfuerzo total del proyecto, el 44% restante se requieren
60 meses-personal de esfuerzo ([44/56] 75). plantilla media ha sido de
aproximadamente 11 desarrolladores de software (75/7); 60 meses-personal de
esfuerzo restante utilizando 11 desarrolladores de software requerirán
aproximadamente 5,5 meses adicionales (60/11). Por lo tanto, se estima que el
proyecto requerirá una programación total de 12,5 meses (7 + 5,5). El proyecto
podría completarse en 11 meses si 4 más desarrolladores de software podrían
añadirse de manera que no viola la ley de Brooks.
Es muy poco probable que el proyecto podría completarse en 9 meses tiempo
total (otros 2 meses) mediante la adición de 19 desarrolladores de software (60/2
= 30; 30 = 11 + 19).
Una precaución: Los cálculos anteriores asumen que el trabajo restante que se
realiza para cada tarea es en el mismo nivel de granularidad y dificultad como
trabajo completado, y que una tasa constante de progreso prevalecerá para las
actividades de trabajo restantes. Puede ser que las partes más difíciles se han
completado, que significa que los 30 restantes requisitos son sencillas y el
proyecto es más de un 56% de avance. Por el contrario, los 30 requisitos restantes
pueden ser los más complejos y el proyecto es inferior a 56% completa.
www.it-ebooks.info
8.6 VALOR DEL TRABAJO DE
INFORMACIÓN 347
La precisión de la estimación hasta la conclusión puede ser mejorado. En

primer lugar, asegúrese de que los criterios de descomposición de prueba
bastante. Recordemos que cada requisito debe ser descompuesto hasta que:
• complejidades y factores de riesgo están expuestos;

• Se identifican las oportunidades de reutilización; y
• esfuerzo para cumplir el requisito puede ser estimado.
Entonces factores de ponderación (por ejemplo, en una escala de 1 a 5) en base a

esfuerzo estimado se puede aplicar a cada requisito restante. Puede ser, por
ejemplo, que se estiman algunos requisitos para requerir 3 veces o 5 veces la
cantidad de esfuerzo en comparación con algunos de los otros requisitos. Si un
requisito se estima que es un “20” en esfuerzo relativo en comparación con otros
requisitos en una escala de 1 a 5, que requisito claramente necesita ser
descompuesto en un conjunto de requisitos más pequeños, derivados. ING
esfuerzo restante para completar el proyecto se puede calcular con mayor
precisión utilizando los factores de ponderación.
8.6 GANADO DE INFORMACIÓN VALOR
rastreo binaria de paquetes de trabajo para el trabajo original, solicitudes de

cambio para Evolución- retrabajo ary, y defectos de informes para la reanudación
evitable (retrospectiva y correctivo) se pueden utilizar para producir valor ganado
(EV) informa. El enfoque EV para informar terminaciones paquete de trabajo es
la siguiente (las solicitudes de cambio y informes de defectos pueden ser
rastreados de un modo similar):
1. Utilizando un enfoque de onda de rodadura, especificar el coste previsto y

la duración en el paquete de trabajo para cada tarea que se completará
durante el próximo mes.
2. Cuando una tarea se ha completado, el costo de crédito prevista (esfuerzo
más otros costos) para la tarea como su “valor ganado” (es decir, el valor
obtenido es el coste previsto que se “ganó la espalda” cuando se completa
una tarea).
3. Para todas las tareas realizadas hasta la fecha, comparar la suma de los
valores obtenidos (es decir, el coste previsto para todas las tareas) a la suma
de los costes reales de las tareas.
4. Para todas las tareas realizadas hasta la fecha, comparar el número de tareas
que deberían haber sido completados a los que se ha completado.
Si el costo acumulado real para completar todas las tareas hasta la fecha es
mayor que el coste previsto para esas tareas (paso 4), el proyecto está por encima
del presupuesto; Por el contrario, si el costo real es menor que el coste previsto,
el proyecto está bajo presupuesto. Del mismo modo, si un menor número de
tareas se han completado hasta la fecha de lo previsto para la finalización del
proyecto está retrasado; si hay más tareas se han completado de lo previsto del
proyecto es antes de lo previsto (paso 5). seguimiento binario asegura que el
trabajo como lo informa a ser completa es en realidad completa debido a que los
productos de trabajo han pasado sus criterios de aceptación. La terminología del
valor ganado se resume en la Tabla 8.9.
www.it-ebooks.info
A partir de las fórmulas de la Tabla 8.9, se puede observar que un IPC 1
significa que el costo real es mayor que el costo presupuestado y un SPI 1
significa que el proyecto está retrasado
www.it-ebooks.info
TABLA 8.9 Obtenido terminología valor

TermDefinitionExplanation
El costo de BCWPBudgeted importe acumulado del presupuesto para
Trabajo todas las tareas realizadas hasta la fecha
realizado (es decir, el valor ganado)
El costo real de todas las tareas realizadas
Costo de ACWPActual Trabajo hasta la fecha
realizado
El costo de BCWSBudgeted coste previsto de todas las tareas
Trabajo programadas para la terminación hasta la
programado fecha
BACBudget Real costo CostPlanned del total proyecto
SCDScheduled Terminación DatePlanned fecha de
finalización de el proyecto EACEstimated Real
CostEstimated costo real del proyecto basado
sobre los progresos hasta la fecha
ECDEstimated Terminación DateEstimated fecha de
finalización basada en
progreso hasta la fecha
CVCost VarianceCV = ACWP - BCWP
SVSchedule VarianceSV = CPTP - BCWP
CPICost Actuación IndexCPI = ACWP / BCWP SPISchedule
Rendimiento IndexSPI = CPTP / CPTR
CVCCost Varianza en CompletionCVC = EAC - BAC
SVCSchedule Variación en SVC = ECD - SCD
finalización
whereEAC = BAC * IPC y ECD = SCD * SPI
programar; por el contrario, un IPC 1 y un SPI 1 significaría que el proyecto

está en el presupuesto y en virtud de lo previsto. Otras combinaciones de CPI y
SPI supuesto, son posibles.
Una precaución: las fórmulas para CPI, SPI, EAC y ECD de la Tabla 8.9 a
veces se invierte, como en
IPC BCWP,
ACWP
SPI BCWP,
CPTP
que hace
EAC BAC
IPC
ECD SCD.
SPI
www.it-ebooks.info
8.6 VALOR DEL TRABAJO DE
INFORMACIÓN 349
En este caso IPC 1 1 y SPI significarían un proyecto está por encima del
presupuesto y tarde. Ambos conjuntos de fórmulas producen los mismos valores
de EAC y ECD si se aplican de forma coherente.
Un ejemplo de un informe de valor ganado se proporciona en la Figura 8.6. En
este ejemplo, el proyecto es por encima del presupuesto, ya que, por las fórmulas
de la Tabla 8.9, el IPC es mayor que 1 (es decir, A C) y tarde debido a que el
SPI es mayor que 1 (es decir, B C). Todos los 8 combinaciones de A, B, y C
son posibles, como se ilustra en la Tabla 8.10. La relación entre A, B, y C en la
columna 1 de la Tabla 8.10 se ilustra en la Figura 8.6.
desempeño de los costos y el calendario índices de rendimiento se pueden
utilizar para calcular el costo real estimado y Fecha estimada de terminación
utilizando las fórmulas de la tabla
8.9. Un ejemplo se proporciona en la Figura 8.7. Debido a que el IPC y el SPI
pueden variar de un período de información a la siguiente, la CAO y ECD
también pueden variar de un periodo a otro. Por ejemplo, un proyecto puede ser
más económico, pero antes de lo previsto en un período de información, de vuelta
en el presupuesto y el horario previstos en el siguiente, o el presupuesto, pero
tarde en el próximo período.
Los ejemplos en las figuras 8.6 y 8.7 son exageradas para los fines de ilus-
tración. En un proyecto bien dirigido, las líneas CRTR y CPTR hará un
seguimiento de cerca los CPTP
Esfuerz
oo
Dólares ACWP
UN
CPTP
segundo IPC = UN / do
SPI = segundo / do
BCWP
do
Hora
fecha de reporte
FIGURA 8.6 Un ejemplo de la información del valor ganado
TABLA 8.10 Ganado relaciones de valor

Orientación: A A B T B C
B C A A C B
Condición: C B C X A A
I
Sobrecosto x x x
Ahorro de costes x x x
retraso de horario x x x
horario de antemano x x x
UN: ACWP; B: CPTP; C: CPTR
www.it-ebooks.info
dólares EAC = BAC * IPC
CVC
BAC
ACWP
UN
IPC = do / UN
CPTP SPI = do /
B
segundo
BCWP
SVC
C
SCD ECD = SCD * SPI
Hora
fecha de reporte
FIGURA 8.7 proyecciones de valor acumulado de costo real estimado y Fecha estimada
de terminación
línea, es decir, el proyecto seguirá siendo más o menos el cronograma y el

presupuesto a lo largo del proyecto. Dicho de otra manera, el calendario y las
variaciones del presupuesto (SV y CV) estarán cerca de 0 y los índices de
rendimiento de costes y programar (CPI y SPI) estarán cerca de 1 en cada
intervalo de informe; las variaciones del coste y del horario de finalización (CVC
y SVC) estarán cerca de cero y su proyecto entregará un sistema aceptable a
tiempo y dentro del presupuesto. Usted puede desarrollar informes similares a los
de las Figuras
8.6 y 8,7 usando hojas de cálculo para hacer los cálculos y preparar los gráficos
(véase también el panel de control en la Sección 8.4.1).
El estado de los paquetes de trabajo para solicitudes de cambio y los informes
de defectos (evolutivos y retrabajo evitable) puede ser rastreado por separado
utilizando el seguimiento binario y pre- tantes como los informes sobre el valor
ganado de una manera similar a la de seguimiento y presentación de informes
progreso de la obra original. Alternativamente, un compuesto de todo el trabajo
se puede informar juntos (trabajo original, retrabajo evolutiva, retrabajo evitable).
Un ejemplo de seguimiento del valor ganado la siguiente manera:
Supongamos que un determinado proyecto acaba de finalizar el tercer mes de un
calendario de 12 meses. El presupuesto previsto para el proyecto es de $ 500.000.
De acuerdo con el plan del proyecto, $ 40.000 de presupuesto debería haber
finalizado en los primeros tres meses; $ 50,000 se ha completado. Tiene costo
$ 60.000 a completar el trabajo hasta la fecha. Así:
SCD = 12 meses =
$ 500.000 EAC
CPTR = $ 50.000
= $ 40.000 CPTP
ACWP = $ 60.000
Usando las fórmulas de la Tabla 8.9, el estado del proyecto al final de los 3
meses se encontró que:
www.it-ebooks.info
8.6 GANADO DE INFORMACIÓN VALOR
351
IPC $ 60.000 1,2,

$ 50,000
SPI $ 40.000 0,8,

$ 50,000
y la EAC y ECD son
EAC $ 500.000 1,2 $ 600.000,

ECD 12 0,8 9,6 meses.
A pesar de seguimiento y presentación de informes binaria del valor ganado se

presentan aquí por un conjunto integrado de actividades de trabajo, como ocurre
en un proyecto de software, las técnicas se pueden utilizar para realizar un
seguimiento de las actividades que no están bien integradas. Por ejemplo, puede
utilizar este método en una gran ventaja durante la fase de mantenimiento del
ciclo de vida del software, cuando varias solicitudes de cambio y los informes de
defectos se procesan de forma individual. Los valores acumulados de coste y el
tiempo real se pueden comparar con los valores presupuestados para, por
ejemplo, todo el mes las actividades de mantenimiento por mes sobre una base
anual.
En resumen, los informes EV son una forma concisa de
presentación:
1. el estado actual de costo (esfuerzo más otros costos), el programa y los

avances en los productos de trabajo;
2. tendencias en el tiempo; y
3. en curso (por ejemplo, mensuales) estimaciones del costo final de un
proyecto (CAO) y la fecha de entrega del sistema (ECD) en base a la
situación actual en curso de su proyecto.
El valor ganado informes de seguimiento basado en binario proporciona

medidas precisas de productos de trabajo terminados debido a los productos de
trabajo no se cuentan como completa hasta que cumplan los criterios de
aceptación objetivas y se convierten en líneas de base que se colocan bajo control
de versiones. Los cambios posteriores en los productos de trabajo baselined son
iniciados por las solicitudes de cambio y los informes de defectos, que también
son aceptadas, la línea base, y seguidos a partir de datos que se realiza un
seguimiento de manera binaria basada en criterios objetivos acep- tación.
Condiciones necesarias para la presentación de informes precisa del valor
ganado son los siguientes:
1. Especificación de los paquetes de trabajo para el trabajo original,

solicitudes de cambio, y los informes de defectos que se completará durante
el próximo mes, actualizada mensualmente de forma de onda rolling-.
2. El desarrollo iterativo y la aceptación de los productos de base de trabajo a
intervalos frecuentes para proporcionar demostraciones de progreso y alerta
temprana de problemas.
3. El control de versiones de los productos de trabajo de referencia.
4. seguimiento binaria basada en criterios de aceptación objetivas para
productos de trabajo.
www.it-ebooks.info
5. Los informes precisos de esfuerzo y tiempo requerido para completar los
paquetes de trabajo, solicitudes de cambio, y los informes de defectos.
www.it-ebooks.info
6. Los métodos estándar, herramientas y formatos de toda la organización para

la obtención e informar sobre el estado del valor ganado.
7. El uso de la condición de valor ganado para pronosticar calcula el costo real
y la fecha estimada de finalización.
Para la presentación de informes del valor ganado para ser eficaz, debe ser Accu-
rado informaron esfuerzo y tiempo (punto 5). tarjetas de tiempo preparados sobre
una base semanal (por ejemplo, cada viernes por la tarde) no son aceptables
debido a la cantidad de tiempo que pasa en diversas actividades de trabajo
durante la semana no será recordado con precisión. tareas agradables se recordará
por ser mucho más corto que en realidad era necesario; tareas desagradables o
difíciles se recordará como tomar mucho más tiempo que realmente necesarios, o
tal vez no van a ser reportados.
Alternativas a las tarjetas de tiempo semanales
incluyen:
1. plantillas electrónicas, completado al final de cada día o a intervalos durante

el día;
2. plantillas para el registro de las actividades de trabajo que se generan para
cada paquete de trabajo, solicitud de cambio, o el informe de defecto
asignado a cada desarrollador de software; y
3. los modelos adjuntos al sistema de control de versiones que requieren la
entrada de datos en el registro de productos de trabajo aceptados.
Una alternativa a la captura automática de datos es tener una persona no

amenazante, (por ejemplo, un trabajador de oficina) reunir los datos
manualmente desde cada desarrollador de software sobre una base diaria, lo
inserta en una hoja de cálculo, y generar informes sobre el valor ganado sobre la
base de datos compuestos en una semanalmente.
Es responsabilidad de cada miembro del equipo para reportar los datos de
tiempo y esfuerzo para cada tarea de manera oportuna; es responsabilidad de
cada jefe de equipo para asegurarse de que los datos de tiempo y esfuerzo
precisos están siendo introducidos por los miembros del equipo. Es
responsabilidad del personal de garantía de calidad para auditar periódicamente
el sistema de información para asegurar que los datos de tiempo y esfuerzo son
precisos y oportunos.
El nivel más pequeño de granularidad en el esfuerzo para ser informado debe
estar en el intervalo de 2 a 4 horas de trabajo. Dicho de otra manera, la cantidad
de tiempo dedicado a cada una de las 2 a 4 tareas más importantes que ocupan
una jornada laboral de 8 horas debe ser informado. Si, por ejemplo, se cierra 6
informes de defectos en un día, usted debe reportar el tiempo dedicado a cada
uno. Sin embargo, en general, su proyecto no está bien organizado si los
miembros del personal trabajan en más de 4 tareas distintas por día, en promedio.
Abogados y contadores, cuando se trabaja para los clientes, a menudo
informan de su tiempo en incrementos de 15 minutos. Este nivel de granularidad
no es necesaria para los proyectos de software. Hay que recordar que las razones
para la medición de diversos atributos de los proyectos de software son
proporcionar indicaciones frecuentes de progreso y alerta temprana de
problemas, para permitir el análisis de las tendencias, para permitir que las
estimaciones del coste final y fecha de finalización de su proyecto y la
construcción de un repositorio de datos de completado proyecto. Estos objetivos
pueden ser alcanzados por la presentación de informes esfuerzo en unidades de 2
www.it-ebooks.info
a 4 horas al final de cada día, o peri dicamente durante todo el día. Este nivel de
detalle es suficiente para satisfacer los propósitos de la medición mientras se
evita el tedio y la interrupción de trabajar actividades inherentes en la
información más detallada.
www.it-ebooks.info
8.7 PANEL DE CONTROL DEL
PROYECTO© 353
Una última bandera amarilla en la recopilación y notificación de datos de

proyectos (tanto de productos y procesos): notificación de los datos del proyecto
debe estar en el nivel de los equipos (de 3 a 5 personas) y proyectos
(agregaciones de equipos). Los datos nunca debe estar relacionado con las
personas, excepto en reuniones privadas donde el énfasis debe ser “¿qué puedo
hacer yo, como su jefe de proyecto (o jefe de equipo) para ayudarle a hacer un
mejor trabajo?” Y no “¿cómo puedes ser tan estúpida que han cometido tantos
errores?”Nada va a matar a un programa de medi- ción más rápido o más eficaz
que la revelación pública de datos relacionados con la productividad individual y
la calidad individual de trabajo.
Debido a la multitud de factores que influyen en la productividad y la calidad
del software, los individuos pueden ser acreditados o culpados por exceder o no
cumplir las expectativas de forma incorrecta. Por ejemplo, Joe programador
puede tener la productividad más bajo, según se mide en líneas de puntos de
código o de función producidos por semana, o informes de defectos cerradas por
semana. Esto puede deberse a Joe, siendo el mejor programador en su grupo, se
le dio las partes más difíciles o puede ser que Joe piensa cuidadosamente y
escribe concisa, pero legible y correcta, el código que requiere un menor número
de líneas que el más detallado y el defecto propensa código escrito por otros. O
es posible que Joe, mientras excelente en algunos tipos de tareas, fue asignado
por error una tarea para la que no tenía experiencia o aptitud.
8.7 PROYECTO DE PANEL DE CONTROL ©
El Proyecto de Control Panel © (PCP) es una herramienta de hoja de cálculo MS

Excel para introducir datos de estado de proyecto y la preparación de las
representaciones visuales de los datos; una copia de la herramienta se puede
descargar haciendo clic en el enlace de referencia [PROJCP]. La versión original
de la PCP se desarrolló bajo los auspicios del Proyecto Red de Gestores de
software (SPMN); ahora es administrado por la Ingeniería Informática Integrada
(ICE) Dirección de la Corporación American Systems.
Figura 8.8 muestra la ventana del PCP. Cinco categorías de datos del proyecto
se dis- jugados: Progreso (que incluye el Valor Ganado, Productividad y
finalización), el riesgo, el cambio, el personal y la calidad. Cada elemento en la
figura 8.8 tiene una hoja de obra correspondiente para la introducción de datos y
la visualización de pantallas expandido. Las hojas de trabajo correspondientes
pueden haciendo clic en la pantalla o haciendo clic en la barra de hoja de cálculo
en la parte inferior del libro PCP. Las pantallas de la figura 8.8 se generan por el
código de Visual Basic que utiliza los datos de las hojas de cálculo para generar
las pantallas. Todos los elementos de la pantalla del panel de control por lo tanto
pueden ser modificados y adaptados para satisfacer las necesidades de cada
proyecto y / o cada organización mediante la modificación del código de Visual
Basic.
La esquina superior izquierda de la pantalla contiene las fechas del período de
presentación de informes y la presentación del valor ganado. El periodo de
informe se puede seleccionar para ser “semanal” o la línea de CPTR ilustra los
CPTP y el BAC “mensual.”; el proyecto se ha retrasado debido a que el CPTR es
menor que el CPTP. La línea ACWP indica que el proyecto es más de
presupuesto porque el CPTR es menor que el ACWP. La EAC se proyecta sobre
la línea ACWP, y como se puede ver, el EAC es mayor que el BAC, basado en el
www.it-ebooks.info
valor CPI de 0,8 muestra a la derecha de las pantallas EV (el IPC se calcula como
ACWP / CPTR y EAC es calculado como BAC / IPC, por lo que un IPC menor
que 1 indica que el proyecto se encuentra por encima del presupuesto).
www.it-ebooks.info
PROGRESO
De A PRODUCTIVIDAD
11/5/2008 12/5/2008 0.8
0,9 1,0 1,1
1.2 0.8
0,9 1,0 1,1
1.2
90 100110
80120
Período de información 0.7 1.3 0.7 1.3 70 130
ARCOS
BAC
Valor agregado Índice de A-Completa Horario de
(BCVP) Rendimiento Índice de compresión
del costo Rendimiento (%)
1 millones 036912 (CPI) (IPAC)
TERMINACIÓN
EAC
Puerta de la Puerta de la
calidad
Las tareas
completadas
Costo real calidad
17
(ACVP) Debido total
3
1 Millones 03 6912 completó en los
3
Tiempo últimos termine a
11 Hora
transcurrido tiempo
0 36912 Estado de la tarea este Las tareas
Meses período
Debido Total Más completadas
RIESGO CAMBIO PERSO CALIDAD
1.5 2.0 2.53.0 NAL Fase descubierto en:
1.0 1.5 2.0 2.53.0
5 0 0 1 1 0 1.0 Prueba Código Des Req oper
Impacto
0.5 3.5 0.5 3.5

4 0 2 1 1 0 Cerrad
o
3 1 0 0 1 0
defectos
defectos
2 0 1 0 0 0
1 0 0 0 0 1 CM La rotación
Volatilidad por voluntaria por
1-20 21-40 41-60 61-80 81-99 mes (%) mes
30(%)
40 50
1,5 2,0 2,5
Probabilidad 1.0 3.0 20 60
0.5 3.5 10 70
Req Des Código TestReq Código Des

Advertencia Canal requisitos VolatilityOvertime Horas por mes Prueba
Anónimo Top 10 de (%)Por mes (%)
Riesgos por defectos ActivityDefects por
Estado ©
FIGURA 8.8 Display desde el Panel de Control de Proyectos [PROJCP]
La pantalla muestra el tiempo transcurrido fecha de finalización del período

actual. Los datos para los cálculos del valor ganado se pueden importar desde
Microsoft Project.
El A-completas medidas de calibre Índice de Rendimiento (IPAC) la misma
relación para el resto del proyecto que las medidas del IPC hasta el final del
período de ING informe- actual. TCPI se calcula como
BCWP BAC
EAC
.
ACWP
Se utiliza en conjunción con el medidor de CPI. De acuerdo con el manual de los usuarios
del panel de control, que se puede descargar desde el sitio Web de referencia:
Si TCPI es mucho mayor que el IPC, a continuación, el equipo del proyecto está
anticipando una mejora de la eficiencia para que sea más eficaz en el cumplimiento de
las estimaciones de costos en el futuro que ha sido el caso hasta la fecha. El costo total
estimado del proyecto (EAC), por lo tanto se puede está calibrada mediante la
comparación de TCPI con CPI. Siempre cuestionar afirmaciones de futuro mejora de la
productividad que se traduce en un aumento del 20 por ciento o mayor en TCPI sobre
IPC para asegurar que se basan en el razonamiento lógico. Esto es especialmente cierto
de las “balas de plata” como nuevas herramientas, lenguajes o metodologías que
realmente pueden disminuir la productividad debido a la formación y los costes de
puesta en marcha. La línea roja en este calibre [TCPI] debe ser de aproximadamente
20 por ciento por encima del valor actual del indicador de CPI para mostrar la relación
y el nivel de alerta entre los dos medidores.
El medidor de la Lista de compresión en la figura 8.8 muestra la relación de la

fecha de terminación estimado (ECD) para este proyecto en comparación con el
programa de “nominal”, que se calcula como
www.it-ebooks.info
8.7 PANEL DE CONTROL DEL
PROYECTO© 355
meses naturales nominales 2,5 person-months 1 3.
Recuerde del capítulo 6 que la relación entre horario y esfuerzo es típicamente

implica un exponente en el intervalo de 0,33 a 0,5. el manual del usuario para el
panel de control señala que una relación de compresión Horario menos de 80%
de la programación nominal indica una programación de alto riesgo; esto se
indica por la porción sombreada de la galga Horario compresión. El valor de 80%
es consistente con los valores com- presión de horario en las herramientas de
estimación de SLIM y COCOMO.
Las pantallas Gate Calidad en la figura 8.8 se basan en el seguimiento binaria
de terminaciones de tareas. Debido total es el número total de tareas que deberían
haber sido realizadas durante el período del informe actual más cualquier tarea
atrasada en comparación con años anteriores. Completado a tiempo muestra el
número de tareas que se completaron según lo programado. Completado incluye
Late tareas programadas para la realización durante el periodo de reporte que se
completaron a finales más cualesquiera tareas atrasadas de ejercicios anteriores
que se completaron en el período actual. Atrasado total es el número total de
tareas para todos los periodos anteriores, más el período actual que estaban en
mora al final del periodo de reporte:
Atrasado total Late Debido total Completed de Tiempo Completo 


Atrasado total indica el número de tareas que deben completarse para que el
proyecto de vuelta a tiempo.
El gráfico Tareas Gate Calidad Completado muestra el número acumulado de
las tareas previstas para concluir a finales del período actual (la línea continua) y
el número real completado (la línea discontinua). La distancia horizontal entre las
dos líneas indica el deslizamiento actual en horario hasta la fecha, que es similar
a la distancia horizontal entre CPTP y CPTR en las figuras 8.6 y 8.7.
La zona de riesgo en la figura 8.8 muestra, en la tabla, el número de factores
de riesgo que se han identificado en cada una de las células Consecuencia /
probabilidad. La exposición al riesgo es el producto de la probabilidad de
impacto (véase el capítulo 9); por lo tanto los factores de riesgo en la esquina
inferior izquierda de la tabla tienen las exposiciones de riesgo más bajas y las de
la esquina superior derecha tienen la mayor exposición. Al hacer clic en el botón
“Top 10 de Riesgos” dis- juega una hoja de cálculo que muestra el nombre del
factor de riesgo, su probabilidad, el impacto y la exposición al riesgo.
El botón de advertencia Canal Anónimo muestra una luz roja cuando se ha
recibido un aviso anónimo de un problema potencial (un factor de riesgo) o un
aviso anónimo de un problema real. La luz roja se apaga cuando todos los
factores de riesgo y problemas de forma anónima reportados han sido tratadas.
Por desgracia, la cultura en algunas organizaciones no proporciona una atmósfera
en la que las personas sienten que está bien reportar los factores de riesgo y
problemas. El canal de denuncia anónima que les permite plantear cuestiones sin
temor a represalias.
El área CAMBIO en la figura 8.8 indica el porcentaje de Gestión de la
Configuración La volatilidad y Requisitos La volatilidad por mes. Volatilidad
CM se calcula como la relación de los productos de trabajo baselined (es decir,
los elementos de configuración) que han sido modificados (o sustituido) y volvió
a comprobar en el manage- sistema ment configuración durante el último periodo
de informe, dividido por el número total de elementos de configuración baselined
. Como se indica en la Figura 8.8, un valor umbral de 2% es un indicador de
www.it-ebooks.info
cambio excesivo.
www.it-ebooks.info
Requisitos Volatilidad por Mes se calcula dividiendo la suma de nuevas,

cambiado, y eliminados requisitos especificados durante el período de informe
actual por el número total de los requisitos al final del período de referencia.
Las áreas sombreadas indican que el umbral para ambos medidores en cambio
se fijó en 2%. Cabe señalar que las áreas sombreadas para todos los medidores en
la Figura 8.8 se pueden reajustar según se desee.
La zona de personal en la figura 8.8 indica los porcentajes de rotación
voluntaria por mes y las horas extraordinarias horas por mes. La rotación
voluntaria por mes es el número de miembros del proyecto de abandonar el
proyecto durante el período actual (es decir, el mes en curso) cuando todavía son
necesarios en el proyecto, dividido por el número de personal al inicio del
período de información. El porcentaje de horas de tiempo extra por mes se
calcula dividiendo el número total de horas extraordinarias trabajadas por todos
los miembros del proyecto por el número total de horas trabajado en un horario
de 40 horas por semana. De acuerdo con el manual de los usuarios del panel de
control del rango objetivo debe ser menor de 10% (es decir, menos de 4 horas
extraordinarias por semana por miembro del personal, en promedio); cuando la
tasa de horas extra se acerca al 20% (8 horas extraordinarias por semana por
persona,
El área de calidad de la figura 8.8 se refiere a defectos por actividad y el
estado abierto / cerrado de los defectos conocidos. Los defectos mediante gráfico
de actividad muestra el número de defectos detectados para las fases de
desarrollo de los requisitos, el diseño, el código y prueba. El eje horizontal de
defectos por actividad indica las fases en las que se descubrieron defectos. El
código de color de cada gráfico de barras que indica el número de defectos de
cada tipo que se encuentra en cada fase de desarrollo; Por ejemplo, el gráfico de
barras más a la izquierda indica que se han encontrado la mayoría de los defectos
de requisitos durante las actividades de trabajo requisitos, algunos fueron
encontrados durante el diseño, algunos durante la codificación, y algunos durante
la prueba. Los defectos mediante informes gráfico de actividad de datos similares
como en la Tabla 8.4 en este capítulo, pero con los ejes intercambiado.
El gráfico de defectos de estado indica el número de informes de defectos que
están abiertos (es decir, el defecto debe todavía ser fijo) y el número que se han
cerrado (es decir, el defecto ha sido fijo y el trabajo modificado ha sido aceptada
como una nueva versión del producto de trabajo baseline).
La penúltima hoja de trabajo en el panel de control del proyecto proporciona
un ejemplo de la adaptación de la pantalla de hoja de cálculo. el manual del
usuario C21B (descargable desde el sitio Web de referencia) proporciona
instrucciones sobre cómo modificar el código de Visual Basic para modificar y
crear nuevas pantallas. Por ejemplo, es posible que desee tener nuevas hojas de
cálculo y medidores (o un panel de control diferente) para registrar datos sobre
las inspecciones de software. Es posible visualizar la tasa media de inspecciones
de software y la eficiencia media de inspección.
El primero de visualización puede mostrar la tasa de comprobación de
inspección dividiendo el número medio de páginas lógicas de documentos (o
puntos de función o líneas de código) inspeccionados por reunión inspección por
el número promedio de horas de trabajo invertidas por los miembros del equipo
de inspección durante el último período de informe ; la pantalla mostraría páginas
(o alguna otra medida) inspeccionados por personal de horas. La última pantalla
(eficiencia media de inspección) mostraría el número de defectos encontrados por
todas las inspecciones durante el período anterior dividido por el número total de
horas de trabajo invertidos en las inspecciones.
Las pantallas de inspección podrían ser monitorizados con el tiempo para
www.it-ebooks.info
determinar aumentos o disminuciones en las tasas de inspección y la eficiencia de
inspección. pantallas similares podrían ser
www.it-ebooks.info
desarrollado para el esfuerzo de prueba y los defectos encontrados durante las

pruebas. Las comparaciones de las tasas y la eficiencia de las inspecciones de
código frente a las pruebas podrían ser fácilmente hacerse dentro de los períodos
de presentación de informes y la acumulada durante períodos de información.
• Los efectos de los procesos de medición son proporcionar indicaciones

frecuentes de progreso, para proporcionar una alerta temprana de problemas,
para permitir el análisis de las tendencias en su proyecto, para permitir que
las estimaciones del coste final y fecha de finalización de su proyecto y la
construcción de un repositorio de datos de el proyecto de historias para su
organización.
• Las dimensiones principales de trabajo a ser medidos y controlados son
esfuerzo, horario, y el coste para cada uno de los distintos procesos de
trabajo.
• La medición de esfuerzo, horario, y el costo debe estar relacionada con el
seguimiento de los productos de trabajo producidos mediante el seguimiento
de binario.
• La cantidad de esfuerzo, tiempo y dinero que usted invierte en la medición y
control se determina por consideraciones de riesgo: ¿cuál es el impacto
potencial de no hacer lo suficiente? ¿cuál es el impacto potencial de hacer
demasiado?
• Posibilidades de acción correctiva, cuando los valores reales de los atributos
del proyecto no están según lo previsto o esperado, incluir la extensión del
horario, la adición de más recursos, el uso de recursos superiores, mejorando
diversos elementos del proceso de desarrollo, y / o cierre definitivo de la
determinación del alcance de los requisitos del producto .
• Posibilidades para la acción correctiva que nunca deben ser usados incluyen
cantidades y duraciones de las horas extraordinarias excesivas; reducción o
eliminación de actividades ficación y validación veri- previstas; reducción de
la documentación prevista usuario, ayudas de formación, y así
sucesivamente; y la reducción, sin el consentimiento del cliente, de cualquier
actividad planificada que reduciría las características especificadas o
atributos de calidad del sistema o producto a entregar.
• la planificación de onda de laminación por jefes de equipo y jefes de
proyecto, con planes detallados para el próximo mes en el rango de una a dos
semanas del personal por tarea, proporciona suficiente granularidad para un
seguimiento preciso del progreso.
• informes binaria de paquetes de trabajo es la única técnica conocida para
nosotros que evita el síndrome completa el 95% de los proyectos de
software.
• informes del valor ganado basado en el seguimiento de los paquetes binarios
de trabajo terminados proporciona informes concisos de costo real en
comparación planificada, el cronograma y el trabajo terminado.
• Informes de tiempo dedicado a las tareas a intervalos de 2 a 4 horas cada día
de cada uno es lo suficientemente precisa para la mayoría de los proyectos
de software.
• los datos de productividad y de calidad deben ser reportados a nivel de
equipos y proyectos, pero nunca a la altura de los contribuyentes
www.it-ebooks.info
individuales.
• Las siguientes técnicas, cuando se usan juntos, pueden proporcionar
información sobre el estado exacto y pronósticos exactos para proyectos de
software: onda rodando elabo- ración de planes de trabajo documentados en
paquetes de trabajo, solicitudes de cambio, y los informes de defectos;
desarrollo iterativo con frecuentes manifestaciones de progreso; control de
línea de base de los productos de trabajo; seguimiento y análisis de la
reanudación por la clase
www.it-ebooks.info
(Evolutivo, retrospectivo, correctivo); seguimiento binaria de paquetes de

trabajo, solicitudes de cambio, y los informes de defectos; y se ha ganado la
presentación de informes de valor.
• Resumen muestra, tal como la proporcionada por un panel de control,
pueden proporcionar informes de estado sucintas para los proyectos de
software.
Referencias
[Basili94] Basili, V., y S. Green. la evolución de procesos de software en el SEL.

IEEE Software
(Julio de 1994): 58-66.
[Boehm01] Boehm, B., y V. Basili. la reducción de defectos de software lista de los 10.
Computadora
(Enero de 2001): 135-137.
[DeMarco82] DeMarco, T. Control de los proyectos de software. Yourdon Press, 1982.
[Fairley05] Fairley, RE, y MJ Willshire. retrabajo iterativo en el desarrollo de software: El
bueno, el malo y el feo. IEEE Computer (septiembre de 2005). Vol. 38, No.
9. pp 34-41.
proyectos de software. Normas Colección de ingeniería. IEEE producto.
URL
[PROJCP] http://www.iceincusa.com/16CSP/content/software/tools/cntrlpnl/cpnlrgt.htm
CEREMONIAS
8.1. ¿Por qué es importante incluir medidas objetivas de los productos de

trabajo terminados cuando el seguimiento de esfuerzo, el cronograma y
costo?
8.2. CMMI-DEV-v1.2 enumera dos áreas de procesos relacionados sobre
Proyecto de Monitoreo y Control: Planificación de proyectos, y la medición
y análisis.
Acceder al sitio Web de acceder al sitio web en CMMI
http://www.sei.cmu.edu/ publicaciones / documentos / 06.reports /
06tr008.html, revisar el Proyecto de Monitoreo y Control de área de
proceso, y explicar brevemente cómo cada una de las dos áreas de procesos
relacionados con ellos se relacionan con proyecto de monitoreo y control.
8.3. Las personas que juegan diferentes papeles en un proyecto de software
www.it-ebooks.info
necesitan diferentes tipos de informes sobre la situación en relación con los
atributos de proceso. Para cada uno de los siguientes, lista y explicar
brevemente los tipos de informes de estado de proceso que podrían ser
útiles para ellos (asumir un proceso de desarrollo iterativo):
www.it-ebooks.info
CEREMONIAS 359
a. Cliente
b. Gerente de proyecto
c. diseñadores
d. Los programadores
e. probadores
8.4. Norma IEEE 1058 especifica, en la cláusula 5.3, que como mínimo, los
requisitos, el horario, el presupuesto y la calidad deben ser medidos y
controlados en un proyecto de software. Enumerar tres atributos adicionales
de un proyecto de software que podrían ser medido y controlado. Explicar
brevemente por qué podría ser importante para medir y controlar cada uno
de ellos.
8.5. Brevemente explica las diferencias entre el presupuesto, el costo y el precio
de un proyecto de software.
8.6. trabajo de software consiste en un trabajo original, la reanudación de la
evolución, retrabajo retrospectiva, y retrabajo correctiva. Dar un breve
ejemplo, específico de cada tipo de trabajo.
8.7. Consulte la Tabla 8.4.
a. ¿Qué porcentaje de esfuerzo total se gastaron en la fijación de los defectos
de diseño?
b. ¿Qué porcentaje de esfuerzo para corregir los defectos encontrados por
los usuarios (OPS) se gastaron en la fijación de los defectos requisitos?
8.8. Supongamos que el esfuerzo restante para completar el trabajo en la Tabla
8.7 es el siguiente:
Ponderación de 4 para cada uno de los 30 requisitos restantes
Ponderación de 3 para cada uno de los 250 módulos restantes a ser
diseñado y aceptado
Ponderación de 1 para cada uno de los módulos 500 a codificar y
aceptado para medir peso de 2 para cada uno de los 800 módulos
restantes para ser integrado Ponderación de 1 para cada uno de los 257
restantes requisitos para ser
validado
a. ¿Cuál es el porcentaje de finalización del proyecto?
b. ¿Cuántos meses quedan para completar el proyecto, asumiendo el
proyecto acaba de terminar su séptimo mes y 77 meses-personal de
esfuerzo se han gastado?
8.9. Usando las fórmulas en la Tabla 8.9, desarrollar un programa de hoja de
cálculo para calcular los siguientes factores para un proyecto de software:
variación del costo (CV)
variación del cronograma
(SV)
índice de desempeño del costo (CPI)
índice de desempeño del cronograma
(SPI) estimó el costo real (EAC) Fecha
estimada de terminación (ECD)
Variación de los gastos hasta la
conclusión (CVC) varianza horario
www.it-ebooks.info
hasta la conclusión (SVC)
www.it-ebooks.info
8.10. Aplicar el programa de hoja de cálculo desarrollado en el Ejercicio 8.9 para

calcular los valores listados en el ejercicio.
a. Utilice el siguiente conjunto de datos: CPTR = $ 40K, 50K ACWP = $,
y CPTP = $ 60K. Supongamos que BAC = $ 200K, SCD = 12 meses, y
que el proyecto se encuentra al final del tercer mes de un calendario de
12 meses.
b. Verificar la exactitud de la hoja de cálculo mediante la realización de los
cálculos de la mano; muestra tu trabajo.
8.11. Repetir el ejercicio 8.10 con los siguientes datos:
Después de 6 meses un proyecto ha completado $ 60K de su presupuesto

planificado. El plan era completar $ 50K del presupuesto previsto. El costo
por el trabajo realizado es de $ 45K. El proyecto está prevista para 10 meses y
el presupuesto total es de $ 100K.
8.12. En pocas palabras explican cómo los paquetes de trabajo, seguimiento

binaria, y el Ing informe- valor ganado se pueden utilizar en una gran
ventaja durante la fase de mantenimiento del ciclo de vida software
cuando varias solicitudes de cambio y los informes de defectos se asignan a
los individuos y se procesan de forma individual. Supongamos que tenemos
un presupuesto anual para actividades de mantenimiento.
8.13. explicar brevemente por qué se deben hacer los datos relacionados con la
productividad y la calidad del público dentro de las organizaciones de
software a nivel de equipo y de proyecto. explicar brevemente por qué los
datos relacionados con la productividad y la calidad nunca deben ser
reportados a nivel de los miembros individuales del proyecto.
8.14. Descargar una copia del Panel de Control de Proyectos © desde el sitio Web
de referencia [PROJCP].
a. Introduzca los datos de valor acumulado del Ejercicio 8.10, y comparar
los resultados con los cálculos de la mano.
b. Siga las instrucciones en el manual del usuario cp21b para modificar la
pantalla del panel de control en algunos aspectos interesantes.
www.it-ebooks.info
ANEXO 8A
Marcos, estándares y directrices para medir

y controlar los procesos de trabajo
Véase el Apéndice 7A (Capítulo 7) para una descripción de los elementos de medida

y control de CMMI-DEV-v1.2, ISO / IEEE 12207, IEEE 1058, y el Cuerpo de
Conocimiento del PMI.
361
www.it-ebooks.info
9
GESTIÓN DE RIESGO DEL PROYECTO
Cuando un proyecto de software es exitosa, no es porque no había problemas, pero

debido a los problemas fueron superados.
-Paul Torre
9.1 INTRODUCCIÓN A LA GESTIÓN DE RIESGO DEL PROYECTO
El objetivo de la gestión de riesgos es identificar y mitigar los posibles problemas

con la suficiente antelación para evitar impactos adversos en los factores del
proyecto, tales como el presupuesto, planificación, los recursos y el coste, y las
características del producto y los atributos de calidad. Si desatendido, problemas
potenciales pueden convertirse en verdaderos problemas que pueden conducir a
ciones de crisis situa-. Para proyectos de software, una crisis es un “show-tapón”
que detiene o impide el progreso serio. Usted no quiere ser el gerente de, o un
miembro de un proyecto que está en una situación de crisis; la gestión de riesgos
puede ayudar a mitigar los posibles problemas y evitar las crisis.
De manera informal, se puede decir que el riesgo es la posibilidad de una mala
cosa podría suceder y las consecuencias asociadas debería ocurrir lo malo. Más
formalmente, la posibilidad de que algo malo ocurra es expresada como la
probabilidad de ocurrencia. La mala cosa que podría suceder es un problema
potencial que no ha sucedido todavía, pero, si se produce, tendrá un impacto
negativo en uno, algunos o la totalidad del presupuesto, cronograma, recursos,
costos, características del producto y los atributos de calidad. Las consecuencias
del impacto negativo podría ser la pérdida de vidas humanas, bienes,
información, dinero, reputación, demora en la entrega de un producto
inaceptable, el costo inaceptable, o su trabajo.
El riesgo se caracteriza, pues, por la probabilidad p, donde 0 p 1, y la
pérdida potencial de L.
Para proyectos de software, la pérdida potencial se expresa por lo general en una
escala ordinal de

www.it-ebooks.info
363
www.it-ebooks.info
364 GESTIÓN DE RIESGO DEL PROYECTO
TABLA 9.1a La determinación cuantitativa de los niveles de

exposición de riesgo
Impacto potencial L = 25 L = 50 L = 75 L = 100
Probabilidad
pag = 0,25 6.25 12.5 18.75 25
pag = 0,5 12.5 25 37.5 50
pag = 0,75 18.75 37.5 56.25 75
pag = 0.90 22.5 45 67.5 90
TABLA 9.1B determinación cualitativa de los niveles de

exposición de riesgo
Impacto potencial Bajo Medio Alto Muy alto
Probabilidad
Bajo Bajo Medio Alto Medio
Medio Bajo Alto Alto Alto
Alto Medio Alto Muy alto Muy alto
Muy alto Medio Alto Muy alto Extremadamente
alto
(Baja, media, alta), o en unidades monetarias, o en unidades adimensionales de

utility.28 En situaciones de misión crítica, el riesgo se puede expresar como el
potencial de pérdida de vidas humanas o el potencial de pérdida significativa de
información o propiedad. Tanto la caracterización (probabilidad y la pérdida de
potencial) son importantes. Si p = 0, significa que la pérdida potencial nunca se
convertirá en una pérdida real; si p = 1, significa que la pérdida ya ha ocurrido o
va a ocurrir con certeza. Si la pérdida potencial es insignificante no hay motivo
de preocupación. Si la pérdida potencial es grande, el esfuerzo se puede ejercer
para reducir el impacto o la probabilidad, incluso si la probabilidad de ocurrencia
es ya muy bajo.
La exposición al riesgo (RE) es el producto de la probabilidad y la pérdida de
potencial:
RE p L.
Un factor de riesgo tiene una probabilidad p = 0,25 de ocurrencia y la pérdida

potencial de
L = $ 100.000 tiene una exposición al riesgo de $
25.000.
valores cuantitativos de la probabilidad y la pérdida potencial se pueden usar
para determinar los niveles de exposición al riesgo, como en 9.1a Tabla. No
siempre es posible cuantificar las probabilidades y posibles efectos de los
factores de riesgo. En esos casos la exposición al riesgo se caracteriza de una
manera cualitativa utilizando una escala de medición ordinal. La exposición al
riesgo se determina entonces por combinaciones de probabilidad y el impacto
potencial, como en 9.1b Tabla.
28
La utilidad es una unidad adimensional de medida, por lo general en una escala de 0 a 100, de valor
www.it-ebooks.info
relativo dentro de un contexto dado. Un vaso de agua, por ejemplo, tiene mucha mayor utilidad a una
persona perdida en el desierto que a una persona en la comodidad de su hogar o de su.
www.it-ebooks.info
9.2 OBJETIVOS DE ESTE CAPÍTULO 365
El riesgo es la probabilidad de que algo malo va a pasar y la pérdida asociada

si el malo sucede. Por el contrario, se puede decir que la oportunidad es la
probabilidad de que algo bueno va a pasar, con una ganancia asociada si se
produce. Visualización de oportunidad como el inverso del riesgo se refleja en las
palabras: “el riesgo de una persona es la oportunidad de anoth- er” y “ve el vaso
medio vacío, pero lo veo medio lleno.”
Una organización de aversión al riesgo, o individuo, se suelen elegir las
alternativas de menor riesgo, mientras que una organización de la toma de
riesgos, o individuo, se suelen elegir las alternativas de mayor riesgo debido a
situaciones de alto riesgo suelen tener altas ganancias, si tiene éxito, pero las altas
pérdidas si fracasado. Algunas organizaciones persiguen la gestión de
oportunidades, que consiste en evaluar las ganancias potenciales a realizar y los
riesgos involucrados, y estar preparado para aprovechar las situaciones, deben
ganancias potenciales superar el potencial de pérdidas en el juicio de los
participantes del proyecto.
En este capítulo se presentan los métodos y técnicas para la gestión de los

factores de riesgo en sus proyectos de software. Después de leer este capítulo y
completar los ejercicios que usted debe entender:
• la terminología de la gestión de riesgos para proyectos de software

• el papel de las técnicas convencionales de gestión de proyectos en el manejo
de los factores de riesgo genéricos para proyectos de software
• métodos y técnicas utilizadas para identificar, analizar, priorizar y mitigar
los factores de riesgo específicos del proyecto
• estrategias de mitigación de riesgo de evasión, el traslado, la aceptación, la
acción inmediata, y los planes de contingencia y acciones
• contenidos de los planes de gestión de riesgos
• top-N de seguimiento de riesgos y elaboración de informes
• formato, contenido y uso de los registros de riesgos
• gestión de crisis para los proyectos de software
• la gestión de riesgos a nivel de organización
• la gestión de riesgos conjunta con los clientes y subcontratistas
Dado que los proyectos, en general, y los proyectos de software, en particular, se

caracteriza por muchas incertidumbres (es decir, son inherentemente esfuerzos de
alto riesgo), cada uno de los marcos, normas y directrices que se presentan en este
texto (CMMI-DEV- v1.2, ISO / IEEE 12207, el estándar IEEE 1058, y PMBOK)
incluyen procesos y prácticas de gestión del riesgo recomendado. Los aspectos
relevantes de estas normas y directrices están contenidas en el Apéndice 9A de este
capítulo. Además una visión general IEEE estándar EIA / 1540-2001 de Procesos del
Ciclo de Vida-Riesgo Hombre- agement se presenta en el Apéndice 9A. Condiciones
específicas para la gestión de riesgos se definen en el Apéndice 9B a este capítulo y
en [Fairley05].
Los términos adicionales utilizados en este capítulo y en todo este texto se
definen en el glosario al final del texto. diapositivas de la presentación de este
capítulo y otro material de portabilidad SUP- están disponibles en la URL que
aparece en el Prefacio.
www.it-ebooks.info
9.3 RESUMEN DE LA GESTIÓN DE RIESGO Para

proyectos de software
proyectos de software son esfuerzos inherentemente riesgosas porque lograr un

resultado exitoso (es decir, la entrega de un producto aceptable a tiempo y dentro
del presupuesto) implica establecer y mantener un equilibrio entre muchas
limitaciones técnicas, organizativas, sociales y políticos, cualquiera o todos los
cuales pueden cambiar a medida un proyecto evoluciona. Cada problema
potencial para un proyecto de software se llama factor de riesgo, ya que
representa una amenaza para un resultado exitoso. La Tabla 9.2 enumera algunos
tipos que ocurren comúnmente de factores de riesgo para proyectos de software.
El riesgo de tiempo de calendario inadecuada puede resultar de:
• comprometerse a una mala estimación,

• cliente o la gestión de compresión de un horario sin un ajuste
correspondiente a los recursos y / o requisitos,
• Además de los requisitos sin los ajustes correspondientes para programar y
recursos, o
• reducción de los recursos planificados sin ajustes correspondientes.
El riesgo de insuficiencia de fondos para llevar a cabo un proyecto puede

implicar la falta de suficiente dinero en el presupuesto para llevar a cabo todas las
actividades de trabajo necesarios (tal vez causados por una mala estimación o
comprometiéndose a un presupuesto “mandato”), o puede que no implicará que
recibe el dinero de una manera oportuna. En este último caso, por ejemplo, el
cliente que está pagando por un proyecto puede retrasar el pago de los fondos
incrementales o su agement hombre- podrá aplazar la asignación de los fondos
necesarios hasta el próximo trimestre fiscal o año fiscal.
La falta de gestión de requisitos adecuados puede crear Mayo tipos diferentes
de problemas potenciales y reales. Como se indica en la Tabla 9.2, los requisitos
pueden infea- sible porque:
TABLA 9.2 Algunos factores de riesgo que ocurren comúnmente para proyectos de software
Riesgo FactorsExamples
calendario ScheduleInadequate hora
los fondos cuando BudgetInsufficient necesario
RequirementsInfeasible, inestable, incorrecta, incompleta, inconsistente
PersonnelRecruitment, la capacidad, retencion
ProcessInefficient y / o ineficaz procedimientos
ResourcesHost y de destino máquinas; secundario organizaciones
TechnologyPlatform y dominio
desarrollo GeographyMultiple sitios
Externo factorsVendors y subcontratistas
Operacional características risksMissing, inadecuada actuación
QualityUser y el cliente insatisfacción
MaintenanceCorrections, falta caracteristicas
www.it-ebooks.info
9.3 RESUMEN DE LA GESTIÓN DE RIESGO Para proyectos de software 367
• su organización carece de habilidad y / o experiencia en el dominio de

aplicación;
• los requisitos pueden estar cambiando constantemente y no logran
estabilizarse después de una cantidad de tiempo razonable;
• pueden ser incorrectamente indicar las necesidades del usuario y las
expectativas del cliente;
• que pueden ser incompletos, por lo que requiere que los ingenieros de
software para “llenar los espacios en blanco”, como bien les parezca (y que
puede ser malo); o
• que pueden ser incompatibles, lo que puede resultar en una falla de diversas
características del producto para interactuar correctamente.
surgen Otros factores de riesgo basados en los requisitos de los requisitos de la

fluencia y “chapado en oro”, como llamado por Boehm [Boehm91]. Requisitos
arrastran, como su nombre indica, se produce cuando los requisitos aumentan con
el tiempo sin ajustes compensatorios para programar, los recursos, el presupuesto
y la tecnología. Requisitos fluencia es el resultado de la gestión de requisitos
ineficaz.
chapado en oro se produce cuando se incluyen las características y atributos de
calidad que no son rentables (como se determina por los usuarios y clientes). El
enchapado en oro a menudo se produce cuando los desarrolladores de software
añadir características que no están especificados en los requisitos y no son
necesarios para soportar los requerimientos primarios (características es decir,
que no se derivan).
riesgos de personal incluyen:
• riesgo de reclutamiento: la incapacidad potencial para reclutar el número

necesario de personal;
• riesgo capacidad: posible falta de las habilidades y capacidades necesarias
entre el personal del proyecto; y
• el riesgo de retención: el potencial para la pérdida del personal del proyecto.
Los procesos de trabajo tienen el potencial de ser ineficiente y / o ineficaces.

Un proceso de trabajo ineficiente requiere más esfuerzo, tiempo, recursos y
dinero que un uno eficiente. Un proceso de trabajo ineficaces no logra los
resultados deseados. Un proceso de trabajo puede ser eficaz pero ineficiente; es
decir, se puede producir el resultado deseado, pero a un costo excesivo o una
cantidad excesiva de tiempo. Un (absurdamente) proceso eficiente que es
efectivo es uno que hace poco trabajo y no produce resultados. Claramente,
procesos de trabajo deben ser eficientes y eficaces para reducir el riesgo de
fracaso del proyecto.
Hay dos tipos de factores de riesgo de recursos:
1. factores de riesgo en activos físicos tales como la velocidad del procesador

y capacidad de memoria, que puede ocurrir en la máquina huésped usada
para desarrollar software y en la máquina de destino en el que se operará el
software; y
2. factores de riesgo en el apoyo a organizaciones tales como gestión de la
configuración y las pruebas independientes sobre los que hay que confiar,
pero sobre los cuales no tiene ningún control directo.
Los factores de riesgo incluyen en la tecnología de los riesgos en la tecnología

www.it-ebooks.info
de la plataforma utilizados para desarrollar software, tales como redes, estaciones
de trabajo, sistemas operativos, compiladores, depuradores, herramientas de
bases de datos y herramientas de prueba, además de los riesgos en la tecnología
del dominio de usuario / cliente.
www.it-ebooks.info
Los factores de riesgo en el dominio del cliente pueden surgir debido a su

organización y su personal del proyecto no están suficientemente familiarizados
con los factores en el dominio del cliente, tales como las prácticas de
contabilidad, leyes fiscales, la física de la navega- ción interplanetaria, o cuidado
del paciente crítico. O bien, la tecnología del dominio / cliente usuario puede ser
inmaduro y por lo tanto más allá de las capacidades conocidas de la informática y
la ingeniería de software. Ejemplos de la última situación incluyen diagnóstico
integral de enfermedades humanas mediante el análisis de ADN automático o la
discriminación automática de amigos y enemigos en la defensa antimisiles.
La globalización y la tecnología de Internet han dado como resultado el
aumento del uso de múltiples sitios de desarrollo de proyectos de software. Los
factores de riesgo creadas por el desarrollo de software en múltiples sitios
incluyen dificultades de comunicación incrementan cuando reuniones cara a cara
no son posibles, además de las dificultades creadas por las diferentes zonas
horarias diferentes y culturas de los miembros del equipo.
factores de riesgo externos se crean cuando su proyecto depende del
desempeño de los proveedores y subcontratistas. Los factores de riesgo en la
adquisición de componentes de los proveedores y subcontratistas pueden resultar
en una falla de un proveedor o subcontratista para entregar un componente
satisfactorio, o componentes, a tiempo y dentro del presupuesto.
Un vendedor puede:
• dejar de hacer las modificaciones solicitadas a un paquete de software tiene

licencia,
• dejar de lanzar una nueva versión que contiene funciones que necesita en el
momento oportuno,
• lanzar una versión próxima que no es compatible con la versión actual, o
• interrumpir el soporte del paquete.
Los factores de riesgo incluyen en subcontratación posibles problemas en la

comunicación entre usted y su subcontratista, y posibles problemas internos al
subcontratista (es decir, los factores de riesgo de la Tabla 9.2).
Los riesgos operacionales son factores de riesgo que pueden convertirse en
problemas si no incluir todas las características requeridas o atributos de calidad
en el sistema o producto entregado, haciendo así que el sistema o producto
inservible o menos útiles que previsto. factores de riesgo son la calidad de los
posibles problemas que se convertirán en verdaderos problemas si los usuarios y /
o clientes están satisfechos con el rendimiento o los resultados producidos por el
sistema entregado.
insatisfacción de los usuarios puede surgir de factores tales
como:
• falta de disponibilidad del sistema (es decir, accidentes frecuentes),

• producción de resultados erróneos, o
• dificultad de aprendizaje y uso.
Es posible que el usuario necesita ser satisfecha pero no las expectativas del
cliente, y viceversa. Por ejemplo, los usuarios de un sistema de caja automatizada
(usted y yo) pueden ser satisfechos con el sistema, pero el cliente (la entidad
financiera) pueden no satisfechos porque los informes producidos por el sistema
son difíciles para financieros a utilizar y a veces errónea.
www.it-ebooks.info
9.4 TÉCNICAS DE GESTIÓN DEL PROYECTO CONVENCIONALES 369
Los factores de riesgo para el mantenimiento del software incluyen la posible

necesidad de un número excesivo de mantenedores de encontrar y corregir
defectos en el software entregado, y la necesidad de agregar características que
deberían haber sido incluidos en el software entregado, pero no lo eran. Los 12
factores detallados en la Tabla 9.2 son algunos factores de riesgo que ocurren
comúnmente para proyectos de software, pero la lista no es exhaustiva; hay
muchos tipos de cosas que tienen el potencial de ir mal en un proyecto de
software.
El riesgo general de su proyecto de software es el conjunto total de los factores
de riesgo que han sido identificados como posibles problemas para ese proyecto.
La gestión de riesgos del proyecto consiste en la mitigación de cada factor de
riesgo identificados individualmente y hacer frente a las interacciones entre los
factores de riesgo. Puede ser, por ejemplo, que evita el problema de un horario
invadida por la reducción de las actividades de verificación previstas crea el
riesgo de que la calidad del producto inaceptable, o que la violación de los
principios de acoplamiento y cohesión para evitar el problema de exceder la
memoria disponible crea un riesgo para el mantenimiento del código.
En general, los factores de riesgo en las siguientes áreas, y las compensaciones
entre ellos, deben ser identificados y enfrentados:
• costo
• programar
• recursos
• los objetivos del producto
° Características del producto
° atributos de calidad
• supuestos
• restricciones
Además los factores de riesgo en áreas tales como la tecnología de la plataforma,

la tecnología de dominio, y la comunicación y coordinación con los clientes,
usuarios y adquirentes deben ser gestionados.
9.4 TÉCNICAS DE GESTIÓN DEL PROYECTO CONVENCIONALES
Las técnicas convencionales de gestión de proyectos presentados en este texto

pueden ser considerados como la gestión del riesgo institucional. Con el tiempo
se ha hecho evidente que la aplicación de técnicas convencionales tales como:
• la planificación y la estimación
• la gestión de requisitos,
• la preparación de estructuras de desglose de trabajo,
• el establecimiento de redes de horario, y
y medir el progreso usando técnicas tales como:
• el desarrollo iterativo,
• seguimiento binario, y
• informes del valor ganado,
www.it-ebooks.info
mejorar las posibilidades de éxito al reducir la exposición al riesgo. En otras

palabras, es mejor hacer la gestión de proyectos convencional que no hacerlo.
La gestión del riesgo aumenta las técnicas de gestión de proyectos
convencionales. explícita de la administración de los supuestos y limitaciones,
por ejemplo, es un elemento clave de la gestión de riesgos. Como se ha descrito
anteriormente en este texto (capítulo 4) supuestos son condiciones que usted
asume que será cierto, pero no se puede verificar durante la planificación. Usted
puede suponer, por ejemplo, que un número suficiente de personal que tenga los
conocimientos necesarios estará disponible cuando sea necesario. O bien, puede
asumir que complejidad del producto no será un problema, ya que espera tener
los desarrolladores de software que están familiarizados con este tipo de sistema.
Los supuestos son posibles problemas (factores de riesgo); suposiciones
resultaron ser falsas crean problemas reales.
Las restricciones son impuestas desde el exterior las condiciones que debe
satisfacer su proyecto (es decir, los factores que están fuera de su control como
director del proyecto). Son limitaciones que se han impuesto en el proyecto de
atributos tales como:
• el horario,
• presupuesto,
• recursos disponibles,
• software para ser reutilizado,
• tecnologías a utilizar, y
• interfaces con otros sistemas.
Las restricciones pueden ser categorizados como restricciones de diseño y

limitaciones del proceso. Una restricción de diseño podría requerir la
reutilización de componentes existentes o la construcción de interfaces
especificadas a otro sistema. Una restricción proceso podría limitar el dinero, los
recursos y / o tiempo disponible para llevar a cabo el proyecto. limitaciones más
restrictivas crean factores de riesgo que tienen mayor probabilidad de presentar
problemas se conviertan en que impedirán deliver- ing un producto aceptable
dentro de cronograma y presupuesto.
Los factores de riesgo creadas por las restricciones del proyecto a veces se
pueden evitar las limitaciones Modificar- ing. restricciones del proceso
(programación, presupuesto, recursos y limitaciones) de productos
(características y atributos de calidad) deben ser examinados. Algunas
restricciones pueden ser esenciales para un resultado exitoso. Otros, en un
examen más, pueden ser relajado o eliminado. Un requisito operacional para
“cerca de tiempo de respuesta instantánea” puede ser aceptablemente satisfecho
con una 5-segundo tiempo de respuesta en lugar de la statedrequirementfora 2-
segundos ResponseTime, porejemplo. tiempo de respuesta Theincreased puede
disminuir significativamente la probabilidad de que un factor de riesgo se
convierta en un problema.
La gestión del riesgo aumenta gestión de proyectos convencional en (al
menos) tres maneras. En primer lugar, se puede administrar de forma activa
supuestos y limitaciones por:
• detallar explícitamente,
• la identificación de los factores de riesgo asociados,
• priorizar los factores de riesgo,
www.it-ebooks.info
• el seguimiento de las métricas de indicadores de riesgo;
• la revisión periódica de los factores de riesgo, y
• perseguir acciones de mitigación según sea necesario.
www.it-ebooks.info
9.4 TÉCNICAS DE GESTIÓN DEL PROYECTO CONVENCIONALES 371
En segundo lugar, se puede:
• establecer valores de umbral para las métricas de indicadores de riesgo y

otros parámetros del proyecto (por ejemplo, índice de rendimiento horario, el
índice de funcionamiento de coste, los requisitos de volatilidad) y
• preparar las respuestas (es decir, desarrollar planes de mitigación) que deben
iniciarse si se violan esos umbrales.
Usted, su cliente, y sus gerentes puede tolerar un retraso de 2 días en la

consecución de un hito importante proyecto, pero usted y que puede estar de
acuerdo, de antemano, que un retraso de más de 2 semanas en la consecución de
un hito importante desencadenará acciones de mitigación. O bien, puede convenir
que una memoria excedido en más de un 10% en cualquier ciclo de demostración
acumulación semanal dará lugar a una acción atenuante.
Como se indica en este texto, hay formas aceptables e inaceptables para
compensar los problemas en un proyecto de software. Los métodos aceptables
incluyen:
• el aumento de la programación,
• aumentar el presupuesto,
• La aplicación de más recursos,
• la aplicación de mejores recursos,
• la reducción de los requisitos; y
• la mejora de los procesos de trabajo.
métodos inaceptables incluyen:
• que requiere exceso de horas extraordinarias;

• la reducción de las actividades de verificación y validación; y
• la reducción de usuario, cliente, soporte, y el SIDA mantenimiento y la
documentación.
La tercera forma en que la gestión del riesgo aumenta gestión de proyectos

convencional es mediante el uso de un enfoque sistemático para identificar,
analizar, priorizar y mitigar los factores de riesgo específicos para su proyecto,
durante la planificación inicial y de forma continua. Es posible que el uso de los
convencionales métodos, herramientas y técnicas presentadas en este texto para
planificar y estimar, medir y controlar y dirigir y orientar su proyecto, pero si
usted no está haciendo la gestión del riesgo sistemático, es posible que no logran
identificar y responder a factores de riesgo específicos con suficiente antelación
para evitar las situaciones de crisis.
factores de riesgo identificados deben ser priorizados debido a que algunos
factores de riesgo, y algunas interacciones entre los factores de riesgo, pueden
tener mayores probabilidades y / o un mayor impacto potencial que otros y por
lo tanto deben recibir más atención y recursos. las estrategias de mitigación de
riesgos deben concebirse. En algunos casos, la mitigación de riesgos consiste en
tomar medidas inmediatas para reducir la probabilidad y / o impacto potencial de
un factor de riesgo identificado. En otros casos, la mitigación de riesgos implica
el seguimiento de un indicador de riesgo y tomar medidas si (cuando) un
problema potencial se convierte en un problema real (es decir, cuando un valor
de activación cruza un umbral, el gatillo problema predeterminada). En algunos
www.it-ebooks.info
casos, las decisiones sobre cómo hacer frente a los factores de riesgo
identificados pueden diferirse hasta que la situación se entiende mejor.
www.it-ebooks.info
TABLA 9.3 Factores de riesgo y técnicas de gestión de riesgos

Riesgo Gestión FactorsRisk técnicas
Personal shortfallStaff con los mejores talentos; empleos partido a las habilidades; realizar
acuerdos de personal número-; proporcionar
entrenamiento cruzado; personal clave horario pre-
horario y / o presupuesto Múltiples técnicas de estimación; diseño de costo y el
realista horario; desarrollo incremental; la reutilización del
software; requisitos de lavado
El desarrollo de las funciones análisis Organización; análisis de la misión;
del software equivocadas desarrollada Concepto de Operaciones; realizar
encuestas a los usuarios; prototipos; desarrollo
El desarrollo de la interfaz de temprano de manuales de usuario
usuario incorrecto creación de prototipos; escenarios; análisis fácil
de tarea; las características del usuario (clases
de usuarios, las cargas de trabajo, estilos de
trabajo)
Oro platingRequirements fregar, prototipos; análisis coste-beneficio; el diseño con el
costo y horario; trazabilidad
Continuando corriente de los Cambiar las tarjetas de control; el establecimiento de
cambios de requisitos un umbral alto para los cambios; ocultación de
información (para facilitar los cambios); desarrollo
incremental (para diferir los cambios en incrementos
Las deficiencias en los posteriores)
componentes suministrados Evaluación comparativa de los componentes
externamente potenciales; inspecciones; comprobación de
Déficits en tareas llevadas a referencia; análisis de compatibilidad
cabo externamente La comprobación de referencias de los subcontratistas
potenciales; auditorías pre premio; contratos de
déficit de rendimiento adjudicación de honorarios; diseño o prototipos
en tiempo real competitiva; la formación de equipos
El filtrar capacidades Simulación; la evaluación comparativa; modelado;
informáticas prototipos; instrumentación; sintonización
Análisis técnico; análisis coste-beneficio; prototipos;
verificación de referencias
En los casos en que el curso correcto de la gestión del riesgo es incierto, 29 y

en los casos en que una acción atenuante no es evidente, debe colocar los factores
de riesgo identificados en una lista de vigilancia que se revisa a intervalos
frecuentes; las acciones de mitigación de riesgos se inicia entonces según el caso.
Las técnicas para la priorización de los factores de riesgo y estrategias para
mitigar el riesgo del proyecto se discuten más adelante en este capítulo.
proyectos de software a menudo tienen factores de riesgo que son
desconocidos durante la planificación inicial pero que se manifiestan más tarde
en un proyecto. No es raro para asignar una reserva de contingencia que se
utilizará cuando los factores de riesgo desconocidos aparecen más adelante en un
proyecto. La cantidad de dinero en la reserva para contingencias puede variar de
10% a 50% o más del presupuesto del proyecto, en función del nivel de
incertidumbre durante la planificación inicial.
Muchas de las técnicas convencionales de gestión de proyectos se puede
utilizar para controlar los factores de riesgo. La Tabla 9.3 enumera algunas de las
técnicas que se pueden utilizar para administrar los factores de riesgo
enumerados por Boehm en su lista de 10 de los factores de riesgo para proyectos
de software [Boehm91]. Las siguientes secciones presentan técnicas para las
www.it-ebooks.info
estrategias de reducción del riesgo riesgo identificación ción, el análisis y la
priorización de los factores de riesgo, y.
29
La incertidumbre resulta de la falta de conocimiento o de la información; a menudo es la causa de un
factor de riesgo.
www.it-ebooks.info
9.5 Técnicas de identificación RIESGO 373
9.5 Técnicas de identificación RIESGO
Como se indica en las diversas normas y directrices para la gestión de riesgos, los
factores de riesgo del proyecto deben ser identificados a medida que desarrollan.
Los factores de riesgo deben ser identificados, analizados, priorizados, y
desarrollaron planes de mitigación, en la medida en que sea posible, durante la
planificación inicial del proyecto, sino también factores de riesgo deben ser
identificados, analizados, priorizados y mitigados de manera continua y
permanente. Algunos problemas potenciales no se materialicen; Por ejemplo, el
hardware que necesita es entregado a tiempo, por lo que el riesgo de retraso en la
entrega no se convierta en un problema. Otros factores de riesgo imprevistas
surgirán como evoluciona el proyecto; por ejemplo, su arquitectura de software le
dice que puede moverse a otra ciudad por motivos personales, pero no es seguro
que lo hará y que no está segura cuando ella se moverá, si lo hace.
Algunos factores de riesgo que se cree que se resolverá pueden volver a surgir.
Por ejemplo, un antiguo riesgo de fracaso para lograr un consenso sobre el diseño
de la interfaz de usuario que se logró anteriormente pueden ahora volver a surgir
debido a que algunos nuevos usuarios que se han incorporado recientemente a la
organización de usuarios están diciendo que quieren cambios importantes. Esta
re-institutos el riesgo de retraso en la entrega del producto en base a la falta de
consenso entre los usuarios.
Algunas técnicas para la identificación de factores de riesgo se enumeran en la
Tabla 9.4. En general, cualquier técnica que se utiliza para identificar los
problemas potenciales para su proyecto puede ser utilizado para la identificación
de riesgos.
9.5.1 Las listas de verificación

Las listas de verificación se utilizan a menudo para identificar los factores de
riesgo. Pueden ser utilizados por los individuos, en las reuniones de grupo, o
como ayuda para los que participan en un proceso Delphi (ver Capítulo 6). La
taxonomía de riesgo desarrollado en SEI es una de las listas de control más
conocidos para la identificación de riesgos [Carr93]. La taxonomía es una
jerarquía de tres niveles de factores de riesgo que ocurren comúnmente para
proyectos de software. 9.5a tabla se enumeran los dos niveles superiores de la
jerarquía. 9.5b tabla enumera algunos de los elementos del segundo nivel y el
tercer nivel en la jerarquía. El informe que contiene la taxonomía y otros aspectos
de la identificación y gestión de riesgos se puede acceder en el URL citado en
[Carr93].
TABLA 9.4 Algunas técnicas para la identificación de factores de riesgo

• Las listas de verificación
• Reunión creativa
• Juicio experto
• análisis FODA
• análisis de supuestos
• El análisis de dificultades
• Lecciones aprendidas archivos
• el modelo de costos
• análisis horario
• requisitos de triaje
www.it-ebooks.info
• inventario de activos
• análisis de compensaciones
www.it-ebooks.info
TABLA 9.5A mejores niveles de la taxonomía de riesgos SEI [Carr93]

De nivel superior ElementsSecond-Nivel Elementos
A. Ingeniería de producto (aspectos técnicos de el trabajo) A.1. requisitos
A.2. Diseño
A.3. Código y unidad
de prueba
A.4. Integración y
pruebas
A.5. especialidades de la
ingeniería
B. entorno de desarrollo (métodos, procedimientos y B.1. Proceso de desarrollo
herramientas que se utilizarán) B.2. sistema de desarrollo
B.3. Proceso de gestión
B.4. métodos de gestión
B.5. ambiente de trabajo
C. las limitaciones del programa (factores contractuales, C.1. recursos
organizacionales y operacionales que están fuera del C.2. Contrato
control de la administración local) C.3. interfaces de programas
TABLA 9.5B Algunos elementos de segundo y de tercer nivel de la taxonomía riesgo

SEI [Carr93]
Segundo nivel ElementsThird-Nivel Elementos
A.1. RequirementsA.1a. Estabilidad
A. 1b. A.1c
integridad. Claridad
A. 1d. A.1e
validez.
Viabilidad A.1f.
A.1g precedente.
Escala
B.1. DesarrolloprocessB.1a. B.1b
formalidad.
Idoneidad
B. 1c. El control
del proceso B.1d.
Familiaridad
B.1e. control del producto
B.3. administraciónprocessB.3a. Planificación
B. 3b. La organización del
proyecto B.3c. B.3d
experiencia de gestión.
interfaces de programas
B.5. TrabajoenvironmentB.5a. actitud B.5b calidad.
Cooperación B.5c.
B.5d comunicación.
Moral
C.1. ResourcesC.1a. Programar
C. 1b. El
personal C.1c.
Presupuesto
C.1d.
Instalaciones
www.it-ebooks.info
Técnicas de identificación 9.5 RIESGO 375
9.5.2 Reunión creativa

Lluvia de ideas es una técnica ampliamente utilizada para la generación de listas
de factores de riesgo. Las reglas de intercambio de ideas son “todo vale” (con
exclusión de mal gusto,, giosos fiabilidad étnica racial o comentarios sexuales) y
“ninguna crítica permitidos.” La crítica y crítica se producen en una sesión
posterior análisis.
Es bastante fácil para un grupo de individuos para generar una larga lista de
factores de riesgo en una sesión de reflexión de uno o de dos horas. El grupo está
generalmente limitado a 10 o menos personas para que todos tengan la
oportunidad de participar. Una ronda de todos contra todos, una idea en cada
turno, el proceso ofrece a todos la oportunidad de participar. Una segunda sesión,
que tuvo lugar después de una pausa, se puede utilizar para analizar y priorizar
los factores de riesgo utilizando un método de clasificación tales como la
votación abierta a mano alzada, la asignación de un número total de puntos a los
factores de riesgo, o un proceso Delphi (véase el capítulo 6).
9.5.3 Juicio experto

El juicio de expertos se basa en la experiencia y los recuerdos de experiencias
pasadas entre un grupo selecto de expertos. Los sesgos (tanto optimista y
pesimista) de los expertos consultados con- deben tenerse en cuenta cuando se
habla de factores de riesgo y problemas en proyectos anteriores. El proceso
Delphi puede ser utilizado en conjunción con el juicio de expertos para reducir
los sesgos entre los expertos (véase el Capítulo 6).
9.5.4 EMPOLLÓN
FODA significa fortalezas, debilidades, oportunidades y amenazas. Cuatro listas
se preparan, uno para cada uno de S, W, O, y T. listas de control, la reunión de
reflexión, y ment experto sentencias con el se pueden utilizar para facilitar una
sesión de FODA. Al igual que en el caso de la lluvia de ideas, debe fomentar la
libre asociación de ideas. Después de una pausa en la reunión, los resultados del
ejercicio de FODA pueden ser examinados para identificar los factores de riesgo
en cada una de las cuatro categorías. Un análisis FODA puede identificar
oportunidades, así como los factores de riesgo.
9.5.5 Análisis de suposiciones y restricciones

Una suposición es una situación o un evento que se cree que es verdadera, o se
cree será verdad, pero que no se puede verificar en la actualidad o que no están
dispuestos a verificar en este momento. Por ejemplo, se podría suponer que los
requisitos no serán modificadas sin ajustes correspondientes se realizan para
programar, los recursos, el presupuesto y la tecnología como sea necesario para
mantener una probabilidad aceptable de la entrega de un producto satisfactorio,
a tiempo y dentro del presupuesto. O bien, se podría suponer que el hardware
será entregado en la fecha prevista y estará disponible cuando sea necesario.
Las restricciones son condiciones externas impuestas en el proceso de
desarrollo y / o el producto entregable. Como se mencionó anteriormente, las
limitaciones deben ser examinados por la necesidad y las posibilidades de
flexibilidad. Podría ser, por ejemplo, que la fecha de entrega programada no
puede extenderse pero algunas de las exigencias de menor prioridad podría
aplazarse para su inclusión en una segunda versión del producto.
www.it-ebooks.info
Supuestos y limitaciones, tanto para el proceso y el producto deben ser
enumeradas de manera explícita y se examinan los factores de riesgo. Un
supuesto que demuestra más adelante
www.it-ebooks.info
que es falso es un problema potencial (un factor de riesgo) que se convierte en un

verdadero problema cuando demostrado que es falsa. Una restricción que podrían
no estar satisfecho es un factor de riesgo que se convierte en un problema si la
restricción no está satisfecho.
Los resultados del análisis de lista de verificación, de intercambio de ideas, el
juicio de expertos, análisis DAFO, y otras técnicas de identificación de riesgos se
deben examinar para suposiciones implícitas ciones y limitaciones implícitas.
Esas suposiciones y restricciones deben ser explícitos y analizadas como factores
de riesgo.
9.5.6 Lecciones aprendidas Archivos

Lecciones aprendidas archivos son (o deberían ser) preparadas como actividad de
la terminación del proyecto para cada proyecto. Un archivo de lecciones
aprendidas debe indicar:
• lo que salió bien en el proyecto,

• lo que salió mal en el proyecto,
• lo que podría haberse hecho mejor,
• raíz de las causas de los éxitos y los fracasos, y
• recomendaciones para futuros proyectos.
Los factores de riesgo identificados y se enfrentó a lo largo del ciclo de vida

del proyecto deben ser incluidos en las lecciones aprendidas. Debe consultar los
archivos de las lecciones aprendidas dentro de su organización en la planificación
de un proyecto. También debe hablar con los directores de proyectos, arquitectos
de software, jefes de equipo, los miembros del proyecto, y los clientes (en lo
posible) para entender los factores de riesgo sociales y políticas que no se
pudieran reflejar en los archivos de las lecciones aprendidas.
9.5.7 El costo y horario de Modelado

Costo y modelado de programación se pueden utilizar de varias maneras para
identificar y evaluar los factores de riesgo para su proyecto. Recordemos, del
Capítulo 6, que una estimación es una proyección del pasado al futuro,
adecuadamente ajustado para tener en cuenta las diferencias entre el pasado y el
futuro. El pasado se resume en la calibración del modelo de costos utilizando
datos históricos de proyectos anteriores. El futuro se resume en una estimación
del tamaño de la base de los requisitos. Los factores de ajuste en cuenta las
diferencias entre el proyecto pasado “típica” y el futuro causado por diferencias
en factores tales como los atributos del producto, los atributos del proyecto, los
atributos personales, y los factores tecnológicos.
La primera manera de un modelo de estimación de costos y el horario se puede
utilizar para identificar los factores de riesgo es el de examinar el modelo (s) de
costes utilizado:
• Es (son) apropiado y debidamente calibrados para su tipo de proyecto?

• ¿El alcance de las actividades estima coincide con el alcance de su proyecto?
• ¿Los datos de calibración basan en promedios de la industria o proyectos
locales?
• Es la calibración reciente o antiguo?
www.it-ebooks.info
Una segunda manera de identificar los factores de riesgo utilizando modelos de
costos y el calendario es examinar los supuestos y limitaciones en que se basa la
estimación, y para hacer
www.it-ebooks.info
explícita de la administración de los supuestos y limitaciones, como se describió

anteriormente. Algunos de los parámetros de estimación puede ser constreñido
(por ejemplo, duración del proyecto y / o el coste total); otros parámetros de
estimación son supuestos que no pueden verificarse durante la planificación
inicial (por ejemplo, factores de ajuste que reflejan la suposición de
disponibilidad de un número adecuado de personal calificado).
Una tercera manera de usar modelos de costos y programar para identificar los
factores de riesgo es hacer “qué pasaría si” análisis y análisis de sensibilidad de
la estimación (s) producido por el modelo (s). Qué-si el análisis implica la
variación de los parámetros de entrada a un modelo y la observación de las
salidas en un “qué pasaría si este fuera el caso” manera:
• ¿y si el tamaño estimado es mayor (o menor) que supone?

• ¿y si los niveles de habilidad y experiencia de los desarrolladores de
software fue mayor (o menor)?
• ¿y si no se asumen como otros parámetros de estimación?
El análisis de sensibilidad se refiere a la determinación de qué parámetros de

entrada producen grandes variaciones en los valores estimados para
correspondientemente pequeños cambios en los parámetros de entrada. Por
ejemplo, el efecto combinado del personal costó conductores en los modelos
COCOMO ejercen la influencia más fuerte en segundos valores estimados,
tamaño después estimado. El esfuerzo-horario comercial-off en el modelo SLIM
es muy sensible a la duración horario (esfuerzo varía con la cuarta potencia
inversa de lo previsto en SLIM).
El análisis de la actividad de la red del proyecto se puede utilizar para
identificar los factores de riesgo asociados a la programación del proyecto. Una
red de actividad, tal como el que se ilustra en la Figura 9.1, puede ser analizado
para determinar:
• precisión de la duración de las tareas estimado de la ruta crítica,

• caminos que son “casi crítico”, y
• fan-in y fan-out a los hitos del proyecto.
5
3.4.1 (2)
3.5.1 (1)
2.1 3.2.2 3
(3) 3.3.1
(6) 3.5.2
3.1 3.6
1 2 8 9 10
(1) (1) (1)
3.2.3 (1) 3.4.2 (2)
(0) 16
camino critico semanas
3.2.1 3.3.2 3.4.3
4 67
(6) (5) (2)
Mn = tareas; (X) = duración de la actividad

nort = hitos;
e
FIGURA 9.1 Una red de actividad-ruta crítica
www.it-ebooks.info
Debido a que la ruta crítica (o caminos) determinan el calendario general del

proyecto, es esencial que las estimaciones de las duraciones de las tareas de la
ruta crítica sea lo más preciso posible. múltiples caminos críticos, como en la
Figura 9.1, presentan un factor de riesgo debido a deslizamiento en el calendario,
ya sea para tareas 3.4.2 o 3.4.3 retrasará la terminación del proyecto.
Dado que los proyectos de software son entidades dinámicas, un camino que
es “casi crítico” puede llegar a ser el factor determinante de la finalización del
proyecto, si ese camino lleva más tiempo de lo estimado. En la figura 9.1, por
ejemplo, la duración estimada para llegar hito 6 en el camino crítico es de 12
semanas. Las duraciones de las tareas 3.1, 3.2.2, 3.3.1 y indican la duración de
alcanzar hito 6 es de 10 semanas. Estas tareas deben ser monitorizados
estrechamente determinan que no utilizan más de 2 semanas de tiempo de
holgura; de lo contrario, un plan de contingencia debe ser invocado.
El abanico de entrada a una etapa del proyecto se determina por el número de
flechas entrantes que son incidentes en el hito. Milestone 6 de la figura 9.1 tiene
un abanico de entrada de 2 y 8 hito tiene un abanico de entrada de 3. Debido a las
tareas sucesoras no pueden comenzar hasta que se hayan completado todas las
tareas predecesoras, la demora en la realización de las tareas predecesoras que
excedan el tiempo programado para llegar el hito va a retrasar el inicio de las
tareas predecesoras. tareas ruta crítica 3.4.2 y 3.4.3 se retrasará si el camino para
las tareas 3.1, 3.2.2, y
3.3.1 lleva más de 12 semanas.
Fan de salida se determina por el número de flechas que salen de un nodo de
hito. El abanico de salida es 3 en hito 3 en la Figura 9.1. Debido a que ninguna de
las tareas sucesoras puede comenzar hasta que se completen las tareas
predecesoras, retraso en cualquiera de las tareas predecesoras retrasará el
comienzo de todas las tareas sucesoras. En la Figura 9.1, por ejemplo, el retraso
ción complemento de las tareas 3.1 y 3.2.2 retrasará el inicio de las tareas 3.2.3,
3.3.1, 3.4.1 y.
Los hitos que tienen fan-in de alta y / o alta fan-out de este modo representan
áreas de problemas potenciales en la red de horario, especialmente si están en el
camino crítico o una ruta de “cerca-crítica”. Puede ser posible rediseñar la red del
cronograma para reducir el abanico de entrada y de abanico a cabo en momentos
de alto riesgo, a condición de que los productos de trabajo producidos por las
tareas predecesoras están disponibles cuando sea necesario. Otras opciones
incluyen la preparación de planes de contingencia y seguir de cerca las tareas
predecesoras y sucesoras, y el rediseño de la red del cronograma al extender el
horario para reducir el abanico de entrada y de salida del ventilador.
La cuarta forma de una red de horario puede ser utilizado para administrar
factores de riesgo es utilizar el método de Monte Carlo de la estimación, como se
describe en el Capítulo 6, para producir gamas de estimaciones con
probabilidades asociadas. técnicas de Monte Carlo se pueden utilizar
estimaciones producto de las probabilidades de alcanzar diversos hitos del
proyecto, incluyendo el hito terminación, como se ilustra en la Figura 9.2
[Fairley94]. Paquetes de trabajo para las tareas de la red del cronograma pueden
ser examinados para determinar los factores de riesgo asociados con la
disponibilidad de los recursos necesarios en las fechas necesarias, los factores de
riesgo asociados con las tareas predecesoras y productos de trabajo, y los factores
de riesgo documentados explícitamente en los paquetes de trabajo.
Todavía otra manera de utilizar estimaciones para identificar los factores de
riesgo es el de examinar los elementos documentados usando la plantilla de
estimación en la Sección 6.10 del Capítulo 6:
www.it-ebooks.info
• cuando se hizo la estimación?
• que hizo la estimación?
• la cantidad de tiempo y esfuerzo se gastó en hacer la estimación?
www.it-ebooks.info
Frecuencia
PAGrobabilidad 300 ensayos de urrence
OCC
0.04 12
0.03 9
0.02 6
0.01 3
9.1 Mo 13,1 Mo 14,4 Mo 15,5 Mo Horario (meses)

11,4 Mo 16,4 Mo
FIGURA 9.2 Una estimación de Monte Carlo del proyecto fecha de

finalización
• qué métodos y herramientas de estimación se utilizaron?

• lo que fue la base de la estimación para cada método y herramienta utilizada
(los promedios de la industria, el juicio de expertos, datos históricos locales,
etc.)?
• cómo fueron las diferencias en las estimaciones reconciliados?
• qué supuestos se hicieron para cada método o herramienta que se utiliza?
• qué limitaciones se observaron para hacer las estimaciones?
• lo que las entradas se utilizaron para cada método o herramienta que se
utiliza (por ejemplo, tamaño, PI, MBI, factores Ment ajustes)?
• ¿cuáles son los niveles de probabilidad de esfuerzo, planificación, los
recursos utilizados, el costo y los atributos de calidad para cada método o
herramienta?
• ¿Qué otras estimación de datos fue proporcionada por los métodos y
herramientas de estimación (por ejemplo, hitos del proyecto, el esfuerzo para
diferentes actividades del proyecto, defectos estimados de liberación pre y
post-liberación, fiabilidad estimada en la entrega del producto, los costes
totales del ciclo de vida)
• qué factores de riesgo fueron identificados para el proyecto?
• lo que es del estimador (estimadores) nivel de confianza en la exactitud de la
estimación (de 0 a 10; baja, media, alta)?
• qué información, recursos, y el tiempo hacen los estimadores necesitan para
hacer una mejor estimación?
9.5.8 requisitos Triage

Requisitos triaje es el proceso de determinar qué requisitos debe satisfacer un
producto dado el tiempo y los recursos disponibles [Davis03]. En el capítulo 3,
esto se describe como el proceso de priorización de requerimientos en categorías
esenciales, deseables, y opcionales. La gestión del riesgo se puede aplicar a los
requisitos de clasificación para determinar que el tiempo y los recursos son
suficientes para proporcionar un alto nivel de probabilidad de que los requisitos
esenciales pueden ser implementados.
requisitos deseables deben ser priorizados y el tiempo y los recursos
necesarios para ponerlas en práctica deben ser negociados con las partes
interesadas del proyecto, tal vez en la disminución de la probabilidad de éxito
www.it-ebooks.info
para los requisitos de prioridad más baja. En ambos casos
www.it-ebooks.info
factores de riesgo (esencial y los requisitos deseables) deben ser identificados y

mitigados a alcanzar el nivel necesario de éxito probable.
Requisitos opcionales especifican características que “sería bueno tener” si
hay suficiente tiempo y recursos. La lista opcional es también un lugar para
registrar ideas para futuras versiones del producto y para los futuros productos.
Requisitos de la lista de opcionales son, por definición, opcional y no
contribuyen al riesgo del proyecto.
La ingeniería de valor es un enfoque similar que utiliza un valor añadido para
el cliente frente a los costos como criterio para priorizar requisitos [VALUE].
9.5.9 Inventario de activos

Los activos son recursos de la organización que se pueden aplicar los proyectos
de software. Otra manera de identificar los factores de riesgo es hacer un
inventario de los activos dentro de su organización y determinar las cantidades y
calidades de los activos que están disponibles para su proyecto de software.
Ejemplos de activos de la organización se enumeran en la Tabla 9.6.
Tabla 9.6 Ejemplos de activos de la organización

• Los gerentes de proyecto
• requisitos ingenieros
• arquitectos de software
• Los líderes del equipo de desarrollo
• Desarrolladores de software
• probadores de software
• los procesos de desarrollo de software
• CM de personal, procedimientos y herramientas
• de personal de control de calidad, procedimientos y herramientas
• herramientas de análisis y diseño
• herramientas de prueba
• entornos de desarrollo integrado
• Estaciones de Trabajo
• Redes de área local
• impresoras
• tranquilos espacios de trabajo
• salas de reuniones privadas
Cada tipo de activo puede ser analizada para fortalezas y debilidades en

cantidad y calidad. Las estrategias de mitigación pueden ser desarrolladas para
mitigar los factores de riesgo asociados a los activos. Por ejemplo, podría
determinar que, para su proyecto, hay insuficiente desarrolladores de software
que tienen experiencia adecuada utilizando el lenguaje Java programa-ming. Su
proceso de mitigación podría implicar la capacitación para sus desarrolladores, la
contratación de desarrolladores cualificados, o subcontratar el trabajo a una
organización que tiene las capacidades necesarias.
9.5.10 Análisis de compensaciones

análisis de compensaciones tiene que ver con la identificación admisibles las
compensaciones y los factores de riesgo asociados a las compensaciones. Puede
ser permisible para aumentar los recursos para mantener el progreso horario, pero
no es admisible para de-ámbito de aplicación todas las exigencias básicas. En
este caso, los factores de riesgo que pueden identificar son los relacionados con
www.it-ebooks.info
la disponibilidad
www.it-ebooks.info
ANÁLISIS DE RIESGO 9.6 y priorización 381
de los recursos adicionales cuando (si) necesarios y los problemas potenciales de

la ing implement- todos los requisitos esenciales dentro de la restricción de
horario usando una cantidad razonable de recursos.
9.6 ANÁLISIS DE RIESGO y priorización
El análisis de riesgos se refiere a la evaluación de las probabilidades, los

impactos potenciales, y los marcos de tiempo de probable aparición de factores
de riesgo identificados. Priorización clasifica los factores de riesgo de
probabilidad, impacto y / o marco de tiempo cuando un problema potencial
podría convertirse en un problema real. Idealmente usted será capaz de realizar
análisis de riesgo cuantitativo mediante la asignación de valores numéricos a las
probabilidades y los impactos potenciales para cada factor de riesgo fied identi-,
usando una escala de proporción, de modo que la exposición al riesgo numérico
(es decir, el producto de la probabilidad y el impacto potencial) puede ser
calculado para cada factor de riesgo.
En algunos casos, es posible que pueda cuantificar las probabilidades e
impactos por examin- ing proyectos anteriores, mediante la consulta de expertos
individuales dentro de su organización, o utilizando el método Delphi para
obtener el consenso del grupo. Los expertos pueden diferir en sus evaluaciones.
Si es así, puede utilizar sus rangos de valores para evaluar los intervalos de
exposición de riesgo de diversos factores de riesgo. En otros casos, puede tratar
de “qué pasaría si” análisis que implica especificar varios valores de probabilidad
y el impacto de diferentes factores de riesgo y el cálculo de las exposiciones a
riesgos resultantes.
En otros casos, puede que no sea capaz de cuantificar las probabilidades e
impactos, lo que puede tener para llevar a cabo análisis de riesgos utilizando una
escala ordinal cualitativa y la asignación de valores tales como baja, media, alta y
muy alta a la probabilidad y el impacto potencial de cada factor de riesgo
identificado. La exposición al riesgo se determina entonces utilizando la Tabla
9.1. Los valores ordinales se pueden obtener mediante el análisis de los datos
históricos, mediante la consulta de expertos, por un proceso Delphi, o por análisis
what-if.
Algunas organizaciones convierten escalas ordinales a escalas de razón
mediante la asignación de valores numéricos a las probabilidades y los impactos
potenciales, como se indica en la Tabla 9.7. En este caso todas las partes
implicadas deben tener en cuenta las dificultades de la conversión de una escala
ordinal a una escala de proporción y colocando de ese modo demasiado énfasis
en los valores resultantes. Por ejemplo, las partes implicadas pueden no estar de
acuerdo sobre lo que constituye una probabilidad media o impacto en
comparación con una alta probabilidad o el impacto y los valores numéricos
correspondientes pueden ser engañosos.
TABLA 9.7 Relación equivalentes escala de símbolos

ordinales
El valor
aproximado de
Valor ordinal relación de escala
Probabilidad Muy bajo 0.10
Bajo 0.25
Medio 0.50
Alto 0.75
www.it-ebooks.info
Muy alto 0.90
Impacto Muy bajo 10
Bajo 25
Medio 50
Alto 75
Muy alto 90
www.it-ebooks.info
Además de la evaluación de la probabilidad y el impacto, el período de tiempo

en el que el factor de riesgo podría convertirse en un problema debe ser evaluado.
El riesgo de tener personal insuficiente para actividades de trabajo programadas
tres meses, por lo tanto, por ejemplo, proporciona tiempo suficiente para hacer
los arreglos. A medida que el tiempo para el trabajo a com- Mence se acerca, la
probabilidad de que un riesgo personal se convertirá en un problema de personal
se hace más alta. De acuerdo con la Tabla 9.1, la exposición al riesgo de tener
personal insuficiente para las tareas programadas en la semana que viene será
muy alta, si se asume que la probabilidad es muy alta y el impacto es alto. Como
se mencionó anteriormente, el objetivo de la gestión de riesgos es identificar y
mitigar los problemas potenciales con tiempo suficiente plomo para evitar
situaciones de crisis.
Los factores de riesgo pueden ser priorizadas usando exposiciones de riesgo
(probabilidad potencial
impacto) y los plazos de probable. Supongamos, sin embargo, que dos factores de
riesgo tienen exposiciones de riesgo iguales y plazos similares de ocurrencia. Por
ejemplo, el factor de riesgo supongamos que A tiene probabilidad de 0.25 y el
impacto potencial de 75 en una escala utilidad de 100, y ese factor de riesgo B
tiene probabilidad de 0.75 y el impacto potencial de 25. Ambos tienen
exposiciones al riesgo de 18,75. Suponiendo que no hay recursos suficientes para
mitigar eficazmente tanto A como B, que deben recibir los recursos de
mitigación?
Supongamos, por ejemplo, que si los factores de riesgo A se convierte en un
problema que tendrá un impacto negativo tiempo de respuesta para los usuarios
principales del sistema (es decir, los clientes de un sistema de caja automatizada)
y el factor de riesgo B tendrá un impacto negativo tiempo de respuesta para los
usuarios secundarios del sistema (es decir, el personal de operaciones que
mantienen el ATS). En este caso, probablemente, los recursos serían asignados a
la mitigación de los factores de riesgo
UN. factor de riesgo B sería colocado en una lista de vigilancia. Los recursos
adicionales pueden tener que ser encontrado, o los recursos existentes reasignado
para mitigar factor de riesgo B, si posteriormente se pone de manifiesto que la
exposición al riesgo de B ha aumentado a un nivel inaceptable.
Este ejemplo ilustra un punto importante acerca de la gestión de riesgos: las
decisiones de gestión de riesgos se basan en factores objetivos, tales como la
exposición al riesgo, y también de factores subjetivos que implican
consideraciones sociales y políticas.
9.7 Las estrategias de mitigación RIESGO
La mitigación del riesgo tiene que ver con el desarrollo e implementación de

estrategias para manejar los factores de riesgo. La mitigación es por lo general
preocupados por la reducción o bien la probabilidad de ocurrencia de un
problema potencial o reducir el impacto del problema potencial, en caso de que
se convierta en un verdadero problema. Las estrategias de mitigación deben ser
desarrollados para los factores de riesgo que han sido identificados, analizados y
priorizados. Como se indica en la Tabla 9.8, las estrategias de mitigación
incluyen la evitación, el traslado, la aceptación, la acción inmediata, y la acción
contingente.
9.7.1 Evitación de riesgo
www.it-ebooks.info
Evitar el riesgo se refiere a cambiar la situación para reducir la probabilidad de
un problema potencial a un nivel aceptable. Si una restricción de tiempo en un
sistema de tiempo real es motivo de preocupación, tal vez la restricción de
tiempo puede ser relajado o tal vez una
www.it-ebooks.info
Las estrategias de mitigación 9.7 RIESGO 383
Estrategias de mitigación de riesgo TABLA 9.8

StrategyApproach
AvoidanceChange el proyecto o la producto
TransferReallocate la requisito (s)
AcceptanceWatch lista
Inmediato actionReduce probabilidad y / o impacto
Contingente actionDelayed acción, si garantizado
procesador de hardware más rápido se puede utilizar; Si no hay tiempo suficiente

para completar el proyecto, tal vez el horario puede ser extendido, evitando así el
riesgo de retraso en la entrega.
Como se mencionó anteriormente, los factores de riesgo son a menudo creadas
por las restricciones del proyecto y, a veces se pueden evitar mediante la
modificación de las restricciones. (restricciones del proceso de programación,
presupuesto, recursos), las limitaciones de productos (características y atributos
de calidad), y las limitaciones logía gías (velocidad del procesador, la memoria
disponible) deben ser examinados. Algunas restricciones pueden ser esenciales
para un resultado exitoso. Otros, en un examen más, pueden ser relajado o
eliminado.
9.7.2 La transferencia del riesgo

La transferencia del riesgo implica la reasignación de los requisitos que crearon
el factor de riesgo a otro componente del sistema u otra unidad organizativa que
puede manejar mejor el factor de riesgo. La compresión de datos, por ejemplo,
puede tener que ser implementado en un chip de propósito especial si el
algoritmo de compresión de datos no puede ser ejecutada con suficiente rapidez
en el software. O bien, puede decidir utilizar un subcontratista de ciertas partes de
su proyecto si su equipo de proyecto no tiene la experiencia necesaria para las
aplicará esas partes.
Se debe tener cuidado de que la transferencia de un factor de riesgo no crea
otros riesgos inadmisibles. El tiempo y los gastos necesarios para diseñar y
desarrollar un chip de propósito especial puede crear riesgos inaceptables para el
costo y horario. La gestión de un subcontratista puede representar un riesgo
mayor para el éxito de la curva de aprendizaje necesaria para su equipo y su
proyecto fracasará si el subcontratista no puede entregar componentes
aceptables dentro de un marco de tiempo aceptable.
9.7.3 La aceptación del riesgo

de aceptación de riesgo es la tercera estrategia para mitigar un factor de riesgo. La
aceptación implica reconocer el factor de riesgo, pero no tomar ninguna acción en el
momento presente que no sea colocando el factor de riesgo en una lista de vigilancia.
A pesar de la aceptación del riesgo no da lugar a una actividad específica de
mitigación, cada factor de riesgo en una lista de vigilancia es con frecuencia volver a
exami- ined de forma periódica para determinar si el nivel de probabilidad, de
impacto o marco de tiempo se ha convertido en lo suficientemente importante como
para justificar adicional actividades de mitigación (por ejemplo, la evitación, la
transferencia, la acción inmediata, o acción contingente).
Una lista de vigilancia tanto, sirve como un recordatorio constante de volver a
examinar los factores de riesgo que pueden volverse más graves como el
www.it-ebooks.info
proyecto avanza. personal del proyecto, por ejemplo, podría ser suficiente para
los próximos 3 meses, pero la preocupación por la futura dotación de personal
podría
www.it-ebooks.info
dar lugar a la colocación de los problemas de personal en la lista de vigilancia. Si

los problemas de personal no se han resuelto como el tiempo de los enfoques de
necesidad, un plan de acción inmediata podría ser desarrollados y puesto en
práctica para adquirir los miembros del personal necesarios.
9.7.4 Acción inmediata

Las acciones inmediatas son las actividades de mitigación que se realizan ahora
para reducir la probabilidad de que un problema potencial (es decir, un factor de
riesgo) se convertirá en un problema real, y / o acciones para reducir el impacto
de un posible problema si se convierte en un verdadero problema a ser. Las
acciones inmediatas se especifican en los planes de acción inmediata.
Supongamos, por ejemplo, que su equipo de proyecto tiene la habilidad suficiente
en el uso del lenguaje de programación Java. Es posible implementar un plan de
formación-acción inmediata para mejorar sus habilidades y reducir así el riesgo
de dar a un producto inaceptable y / o invadiendo el calendario de entrega.
Documentación de un plan de acción inmediata incluye:
• un identificador,
• la persona que es responsable de ver que se ejecuta el plan,
• responsabilidades de otras personas involucradas en la ejecución del plan,
• una descripción del factor de riesgo para ser mitigado,
• las acciones a realizar,
• los recursos necesarios,
• la duración prevista de las acciones indicadas,
• los hitos de progreso a alcanzar, y
• los criterios de éxito que van a indicar la finalización exitosa de las
actividades previstas.
Un ejemplo se proporciona en la Tabla 9.9.

Usted nunca tendrá suficiente tiempo, dinero o recursos para llevar a cabo las
acciones adecuadas de compuerta mitiga para todos los factores de riesgo
identificados. Los factores de riesgo que tienen los más altos lazos prioridades,
según lo determinado por la exposición al riesgo y los factores subjetivos, deben
recibir la mayor parte de sus recursos limitados.
Una forma de determinar estrategias de inversión es calcular y comparar los
factores de riesgo de apalancamiento (RLF) para diversas estrategias de inversión
para sus factores de riesgo más altas prioridades. RLF se calcula mediante el
cálculo de la exposición al riesgo antes de la mitigación, la exposición al riesgo
después de la mitigación, y dividiendo la diferencia por el costo de la mitigación:
después
RE RLF antes de
. costo de la
mitigación
Supongamos, por ejemplo, que usted está considerando una inversión de $ 25.000 a
reducir la probabilidad a partir de 0,4 a 0,1 de los factores de riesgo con impacto
potencial de $ 500.000. La exposición al riesgo antes de la mitigación es $ 200.000
(0,4 $ 500.000), la exposición al riesgo tras la cobertura sería de $ 50.000 (0,1 $
500.000), y el costo de la mitigación se estima en $ 25.000. El RLF es, pues,
www.it-ebooks.info
Las estrategias de mitigación 9.7 RIESGO 385
TABLA 9.9 Ejemplo de un plan de acción inmediata

• número de plan de acción y nombre: AP # 3, Formación de Java
• Fiesta responsable: Sue Smith
• Otras partes responsables: Joe Williams establecerá las estaciones de trabajo; que
aún no identificada instructor entregará el curso.
• factor de riesgo para el ser mitigado: falta de suficiente habilidad de Java
• Las acciones para ser completados: clase de entrenamiento y ejercicios de laboratorio
durante 20 programadores
• Fiesta responsable: Sue Smith
• Recursos necesitados: instructor, el aula con estaciones de trabajo, tiempo de liberación
para los asistentes
• Duración de esta acción: 4 semanas
• Hitos para esta acción:
Semana 1: encontrar el instructor, clase de reserva, identificar a los asistentes
Semana 2: cargar el software en los ordenadores, obtener / reproducir
los materiales de clase Semana 3: realizar la clase 5 días
Semana 4: proyecto de laboratorio completo (medio tiempo, 4 días)
• Los criterios de éxito para esta acción: 19 de 20 asistentes completar con éxito el proyecto de
laboratorio
200.000 50.000
RLF 
25, 000
Mayores factores de riesgo de apalancamiento indican mejores estrategias de

inversión.
No hay garantía, por supuesto, que la inversión se reducirá la probabilidad a
partir de 0,4 a 0,1, ni hay certeza de que el factor de riesgo se convertirá en un
problema si no se mitiga. La probabilidad es “sólo el 40%.” Sin embargo, $
500.000 habría una pérdida financiera grave como para su organización y una
grave pérdida de reputación para usted. Si usted no gasta $ 25.000 a mitigar el
factor de riesgo y se produce el problema, se le criticado. Si lo hace pasar $
25,000 y el problema no se produce, usted (y otros) nunca sabrá si se hubiera
producido sin tener que gastar $ 25.000.
En este sentido invertir en la mitigación de riesgos es similar a la inversión en
el seguro. Usted puede ser uno de los afortunados que nunca ha tenido un
accidente automovilístico grave. Se podría decir que usted ha perdido un montón
de dinero para pagar el seguro de automóviles (especialmente si son de mi
edad). Sin embargo, el potencial impacto financiero creado por no comprar el
seguro es tan grande que la mayoría de la gente racional continuarán a comprar
un seguro, a pesar de que la probabilidad de un accidente sobre la base de la
evidencia histórica es baja, e incluso si no fuera requerido por la ley.
9.7.5 Acción contingente

acciones contingentes se especifican en los planes de contingencia que se
preparan para los problemas potenciales para los que se justifiquen no hay
acciones inmediatas. Si, por ejemplo, se están llevando a cabo una estrategia de
desarrollo incremental, la falta de suficiente memoria o tiempo de respuesta
inadecuada puede convertirse en un problema más adelante, pero por ahora, no
hay suficiente memoria y el tiempo de respuesta es aceptable. Estos tipos de
factores de riesgo se conviertan en problemas cuando los indicadores de riesgo
objetivos (medidas objetivas) transversal predeterminada umbrales (el problema
disparadores).
www.it-ebooks.info
Figura 9.3 (repetido del Capítulo 7) proporciona un ejemplo de la memoria de
seguimiento asignado frente a la memoria utilizada en un proyecto de sistema
embebido. El factor de riesgo es la falta
www.it-ebooks.info
Memori
256K
a
reserva de 10%
225K
Real
B=
compilaciones
B1B2B3B4 B5 incrementales
FIGURA 9.3 Que ilustra un umbral de memoria 10% para la gestión de riesgos
de la memoria suficiente para ejecutar el software necesario. El sistema está

siendo implementado en una serie de compilaciones incrementales semanal. La
memoria se asigna a cada generación sucesiva del sistema y la cantidad
acumulada de memoria utilizada para cada compilación demostrado se compara
con la cantidad asignada. Como se indica en la Figura 9.3, 10% de la memoria se
mantiene en reserva. El software le caben en la memoria disponible si no se
excede este margen.
En la figura 9.3, la memoria real utilizado en incrementales construye B1 y B2
exceda la cantidad asignada previsto, pero no en más de un 10%. Construir B3, la
memoria actual, sin embargo ha causado utilizado para superar el umbral del
10%. Este es el detonante de la invocación de un plan de contingencia (ver Tabla
9.11). Uno de los fallos comunes de gestión de riesgos es la de “esperar y ver” si
la situación va a mejorar sin necesidad de invocar el plan de contingencia.
La mejoría espontánea en una mala situación casi nunca sucede. Recordemos
que el propósito de la gestión de riesgos es identificar problemas potenciales con
la suficiente antelación para evitar las situaciones de crisis. Aunque hay un
montón de memoria todavía disponible después de la acumulación B3, todavía
hay una gran cantidad de funcionalidad a implementar. La tendencia, basado en
construye B1, B2 y B3, indica que, sucesivamente, más memoria se utiliza lo que
se había planeado en cada generación. Ahora es el momento de invocar el plan de
contingencia para evitar la crisis de desbordamiento de memoria.
Una plantilla para los planes de contingencia se presenta en la Tabla 9.10. Como
se ha indicado, un plan de contingencia especifica:
• el indicador de riesgo que se desea medir;

• la frecuencia de medición;
• el valor de umbral para la acción contingente (es decir, el gatillo problema),
el plan contingente de acción; y
• la duración especificada por las acciones contingentes para resolver el
problema.
www.it-ebooks.info
9.7 Las estrategias de mitigación RIESGO 387
TABLA 9.10 Plantilla para un plan de contingencia

Número plan de contingencia y nombre: CP # 1 [nombre]
• Fiesta responsable: [tu nombre]
• factor de riesgo para el ser mitigado: [breve descripción]
• Indicador (s) de riesgos a ser seguido: [breve descripción]
• Frecuencia de medición: [Incluir unidades de tiempo]
• Valor (s) de umbral para la acción (s) contingente: [Incluir unidades de medida]
plan de acción de contingencia

• Las acciones para ser completados: [breve descripción]
• Responsabilidades: [Lista de quién va a hacer qué]
• Recursos necesitados: [ponlos en una lista]
• Hito para esta acción: [Frecuencia de medición del avance]
• Los criterios de éxito para esta acción: [¿Cómo vamos a saber cuando el problema se
resuelve?]
• La duración máxima de esta acción: [¿Cuándo vamos a declarar una crisis?]
TABLA 9.11 Ejemplo de un plan de contingencia

Número plan de contingencia y un nombre: la memoria CP # 5
• Fiesta responsable: John Smith
• factor de riesgo para el ser mitigado: falta de memoria suficiente en el microprocesador
• Indicador de riesgo a medir: programada versus la memoria real utilizado en
incrementales sucesivas construye
• Frecuencia de medición: medición semanal de uso de memoria para
incrementales sucesivas construye
• Valor umbral: 10% sobre el plan en cualquier construcción incremental
plan de acción de contingencia

• Las acciones para ser completados: reingeniería del software para encajar dentro de la
memoria asignada
• Responsabilidades: Joe Williams y Sue Smith tratará de rectificar la memoria invadido; que
serán liberados de todos los demás derechos y reciben pago por horas extras
• Recursos necesitados: una máquina objetivo adicional será trasladado durante la noche de
San José
• Hitos para esta acción: no hay hitos objetivo; breves reuniones de estado de stand-up se
llevará a cabo a las 11:00 am y 6:00 pm de cada día
• Los criterios de éxito para esta acción: el uso de memoria reducida a no más de
5% en cantidad asignada
• La duración máxima de esta acción: 7 días
Un proyecto entra en modo de crisis si las acciones contingentes no alcanzan

los criterios de éxito especificados en el plan dentro de la duración especificada.
El plan de contingencia para el factor de riesgo en la Figura 9.3 se presenta en
la Tabla 9.11. Exceder el margen de 10% proporciona el gatillo para activar el
plan de contingencia. La figura 9.3 indica que el plan de contingencia debe ser
activado debido a la acumulación incrementales B3 ha superado la asignación
de memoria acumulativa para la construcción.
Como se discutió en el Capítulo 7, los atributos de medida de un sistema para
determinar lo bien que el sistema o algunos elementos del sistema de satisfacer
los requisitos especificados se conoce como medición del rendimiento técnico
(TPM). Medir la cantidad de
www.it-ebooks.info
memoria utilizada frente a la cantidad de memoria asignada, como en la figura

9.3, es un ejemplo de TPM.
9.8 TOP-N SEGUIMIENTO DE RIESGO Y los registros de riesgo
Los factores de riesgo, las prioridades entre ellos, y su estado se pueden mostrar
en las listas de la parte superior-N, donde N es aproximadamente 10. Los
diferentes niveles de su proyecto y de su organización deben tener diferentes
listas. La lista-N máxima está limitada a aproximadamente 10 factores de riesgo,
ya que, los miembros de su proyecto, y su organización no tiene los recursos o el
tiempo para hacer frente eficazmente a más de 10 factores de riesgo
significativos en cualquier nivel dado del proyecto (equipo, subsistema ,
proyecto). Usted, su organización y su cliente debería considerar seriamente la
re-definición del alcance, o tal vez la cancelación de su proyecto si usted ha
identificado más de 10 factores de riesgo significativo (es decir, los factores de
riesgo que tienen las exposiciones alto o muy alto riesgo, como se indica en las
Tablas 9.1a y 9.1b ).
Como se ilustra en la Tabla 9.12, cada factor de riesgo está clasificado, su
clasificación en el período anterior se indica, y el estado de la mitigación de
riesgos se indica. Clasificación se determina por consenso entre los que se verán
afectados si el factor de riesgo se convierte en un problema. Un factor de riesgo
puede moverse hacia arriba o hacia abajo en el ranking basado en la reevaluación
periódica del factor de riesgo y la criticidad de otros factores de riesgo. Ambas
consideraciones objetivas y subjetivas deben tenerse en cuenta en la clasificación
de los factores de riesgo.
Como se indica en la Tabla 9.12, número de entrada 7 es un nuevo factor de riesgo
en la lista de top-N. Las dos últimas entradas son factores de riesgo que se cerraron
durante la semana pasada. Si usted fuera el director del proyecto del proyecto en la
Tabla 9.12, que sería (debería ser) de pensar en un plan de acciones contingentes, si
las acciones actuales no resuelven satisfactoriamente los factores de riesgo indicados
en los marcos de tiempo indicados.
Las organizaciones que utilizan top-N listas a menudo tienen diferentes listas
de factores de riesgo en los diferentes niveles de la organización. Cada equipo
dentro de un proyecto tiene su lista, cada proyecto tiene su lista, cada
organización de apoyo tiene su lista, y los departamentos en los que soft- Ware
proyectos se llevan a cabo tienen sus listas. Los equipos de proyecto a identificar
los factores de riesgo y emprender acciones de mitigación que están dentro del
ámbito de su responsabilidad y autoridad. Los factores de riesgo que no se
pueden mitigar dentro del equipo se mueven hacia arriba a nivel de proyecto. Los
factores de riesgo que pueden ser mitigados dentro de un proyecto o una
organización ing SOPORTE- se mitigan en ese nivel. Los factores de riesgo que
no se pueden mitigar dentro de un proyecto o una organización de apoyo se
presentan hacia arriba y proporcionan entradas a la lista-N superior del
departamento.
Muchas organizaciones que utilizan listas-N de la actualización de las listas
sobre una base semanal y publicar las listas en los espacios de trabajo accesibles
públicamente. Esto facilita la comunicación sobre problemas potenciales y, en
palabras de un colega, “despenaliza” riesgo, es decir, que se convierte en
aceptable para discutir los problemas potenciales, sus probabilidades, sus
impactos y los plazos, y las estrategias de mitigación. actualización semanal de
las listas de la parte superior-N asegura que ocurrirá, la gestión de riesgos
continua en curso. El uso de listas de N-superior puede tener un efecto
www.it-ebooks.info
revolucionario, positivo en los proyectos de software y la cultura del lugar de
trabajo dentro de una organización.
Top-N de seguimiento del riesgo puede ser incorporada en un registro de
riesgos, que es una tabla que puede ser implementado como una hoja de cálculo
utilizado para controlar los factores de riesgo. Como se indica en la Tabla 9.13,
cada fila de una tabla de registro de riesgos incluye los siguientes elementos:
www.it-ebooks.info
TABLA 9.12 Ejemplo de un informe de riesgo-N superior (N = 8)
Proyecto www
:
Fecha: xx / yy /
zz
Ranking Rang
Esta o Seman Marco de
Semana sema as en Factor de Impacto potencial Acción atenuante tiempo para
9.8 TOP-N RIESGO RASTREO Y RIESGO REGISTROS 389

na la riesgo la resolución
1 4 2 Reemplazo para el Retraso en la Reunión con el jefe de Inmediato
www.it-ebooks.info
pasad Lista
líder del equipo de terminación de la servicio el lunes
a
control de sensor codificación; código
de menor calidad
2 6 2 Los cambios fecha de entrega 2 personas adicionales Debe completar
solicitados en la retardada asignados los cambios por
interfaz de usuario el próximo
3 2 5 errores del Retraso en la Las pruebas de viernes
Nueva versión debe
compilador realización de la validación en ser validado por
codificación de los curso este viernes
4 3 6 Disponibilidad de controladores dey
retardo de costo Reunión con el cliente y Deben haber
estaciones de trabajo hardware
cronograma el jefe de servicio el instalado
para la prueba del miércoles estaciones de
5 5 3 sistema
Definición de Retraso de la reunión de revisión trabajo dentro
Definición de
debe
un mes
hardware de integración de prevista para el próximo estar disponible a
banco de pruebas sistemas martes finales de este mes
390
GERENTE PROYECTO RIESGO
TABLA 9.12 (continuación)
Proyecto www
:
Fecha: xx / yy /
zz
Ranking Rang
Esta o Seman Marco de
Semana sema as en Factor de Impacto potencial Acción atenuante tiempo para
na la riesgo la resolución
6 1 3 Impacto de los Podría requerir un demostración del Tan pronto como sea
pasad Lista
requisitos de cambio importante prototipo programado posible
www.it-ebooks.info
a
tolerancia a a la arquitectura durante una semana a
fallos en el HW / SW partir del jueves
rendimiento
7 - 1 La especificación adquisición tardía de Reunión para considerar Debe completar la
de interfaz de subsistema de alternativas programadas especificación a
telecomunicaciones hardware para el miércoles finales de este mes
no completó
8 8 4 La no manuales de mala Recursos Humanos ha Se necesita tan
disponibilidad de calidad colocado anuncio con pronto como sea
escritor técnico / la agencia de empleo posible
- 7 4 editor
CM persona apoyo inadecuado Experimentado persona Resuelto
necesita para aumentar la CM ha unido al
carga de trabajo proyecto
- 9 5 Interface a la base de Tiempo y Resuelto en la última Resuelto
datos esfuerzo para demostración
poner en práctica
una nueva interfaz
9.8 TOP-N SEGUIMIENTO DE RIESGO Y los registros de riesgo
391
TABLA 9.13 Elementos de un registro de riesgos

factor de identificador de Riesgo
número de revisión y fecha de
revisión Responsable
Categoría de riesgo (horario, recursos, costos, técnicos, otros)
Descripción
Estado (cerradas, acción, supervisado)
Si se cierra: fecha de cierre y la disposición (disposición: evitado, transferido, retirado de la
lista de vigilancia, la acción inmediata o acción contingente completado, la crisis logró)
Si activo: número de acción plan o número de plan contingente de acción y el estado de la
acción (estado: en el plan, o desviarse de plan de más factores de riesgo para completar el
plan)
Si monitorizado: Se aplican los siguientes elementos:
• rango Top-N
• rango anterior
• Semanas en la lista
• Impacto potencial
• acción actual
• marco de tiempo para la resolución
• Relación con otros factores de riesgo
• plan de contingencia relacionada
Como se indica en la Tabla 9.13, la responsabilidad de la gestión de cada

factor de riesgo se debe asignar a una persona apropiada. Incluye
responsabilidades:
• asegurando que un plan de mitigación se desarrolla para el factor de riesgo,

• el seguimiento de la métrica indicador de riesgo (o métricas),
• la implementación y el seguimiento del progreso de los planes de acción y
planes de contingencia, y
• informar sobre el estado de las partes designadas.
El estado de un factor de riesgo se puede cerrar, acción, o de verificación:
• Un factor de riesgo Closed es uno que no sucedió (por ejemplo, el hardware

fue entregado a tiempo) o uno para el que una actividad de mitigación ha
reducido con éxito la probabilidad de ocurrencia y / o el impacto potencial a
niveles aceptables;
• estado activo de un factor de riesgo indica que un plan de acción inmediata o
de un plan de acción con- tingent se ha invocado y se encuentra actualmente
en curso; y
• Un factor de riesgo es monitoreada uno que está siendo rastreado en una lista
de vigilancia o está siendo monitoreado por una o más métricas de
indicadores de riesgo. Si un indicador de riesgo cruza un valor umbral
predeterminado, se iniciará un plan de acción contingente y el estado se
cambiará de monitorizada a activo.
Hay varios tipos de informes pueden ser generados a partir de un registro de

riesgos. Por ejemplo, una lista de todos los factores de riesgo cerrado activo, o
www.it-ebooks.info
supervisadas se pueden generar. O bien, todo el riesgo
www.it-ebooks.info
factores de los que son responsables los individuos particulares. O bien, sólo el
Top-M en la lista de factores de riesgo.
Diferentes registros de riesgos se deben utilizar en los diferentes niveles de su
organización. Cada equipo debe mantener un registro de riesgos que se actualiza
semanalmente. Los miembros del equipo de proyecto deben cumplir con usted, el
director del proyecto, una vez por semana para actualizar el registro, o con sus
jefes de equipo que se reúnen con usted a su vez. Puntos que deben incluirse en el
registro del proyecto son aquellos factores de riesgo que los equipos individuales
no pueden manejar y los que tendrán un impacto más allá del equipo individual,
deben esos riesgos se conviertan en problemas.
El departamento en el que se produce su proyecto debe tener un registro de
riesgos que se actualiza en forma semanal, quincenal o mensual. Los ítems de
registro de riesgos del departamento incluyen aquellos factores de riesgo que no
se pueden manejar a nivel de proyecto o que se manejan mejor a nivel de
departamento. Del mismo modo que usted y su cliente, y usted y sus
subcontratistas (si lo hay), deben mantener registros de riesgos que se actualizan
de forma periódica, ya sea mensual o trimestral en función de la duración y la
criticidad del proyecto gestionada de forma conjunta.
Cada versión de cada registro de riesgos debe ser identificado por su número,
fecha, tipo (equipo, proyecto, departamento, cliente, o subcontratista). Cada
versión debe estar bajo el control de versiones para proporcionar trazabilidad y
un registro histórico. Como se ha indicado anteriormente, utilizando
públicamente mostrado top-N listas de riesgo y registros de riesgos puede tener
un efecto positivo lutionary, revo- en el proyecto y la comunicación de la
organización.
Radar de riesgos es una herramienta de software que basa en Microsoft Access
que puede ser usado para implementar un registro de riesgos. Muchos de los
elementos de radar de riesgo son similares a los que se enumeran en la Tabla
9.13, a pesar del riesgo de radar utiliza un formato algo diferente. capturas de
pantalla de muestra de radar de riesgos pueden verse
enhttp://www.iceincusa.com/Content/RRFlyer.pdf. Una copia de demostración
gratuita de radar de riesgos se puede descargar desde http: //www.iceincusa. com
/ Products.aspx? p = Products_RiskRadar.
9.9 CONTROL DEL PROCESO DE GESTIÓN DE RIESGO
Al igual que todos los procesos de ingeniería de software, el proceso de gestión

del riesgo debe ser adaptado a las necesidades de cada uno de sus proyectos. En
un pequeño proyecto que consiste en un único equipo de desarrollo (5 o menos
desarrolladores), un registro de riesgos actualizada semanalmente en forma de
una sola hoja de cálculo es suficiente. Usted, como director del proyecto,
arquitecto de software, y el líder del equipo, sería el encargado del registro de
riesgos y controlar el proceso de gestión de riesgos.
Como todos los procesos del proceso de gestión del riesgo se vuelve más
compleja en los proyectos grandes que involucran a múltiples equipos de
desarrollo y que puede implicar varios departamentos, múltiples clientes y
múltiples subcontratistas. En estos casos cada factor de riesgo se debe
documentar el uso de un formulario de informe de riesgo, como la que se ilustró
en la Tabla 9.14.
Cada factor de riesgo conocido es analizada y controlada por un Consejo de
Gestión de Riesgos (RMB), que es similar en funcionamiento a una Junta de
Control de Cambios (véase la Sección 3.4.5). Su RMB proyecto debe ser dirigido
www.it-ebooks.info
por usted, el director del proyecto, y debe incluir su arquitectura de software, los
jefes de equipo y representantes de la CM, control de calidad, soporte y funciones
de mantenimiento. Debe tener RMBS separadas para gestionar conjuntamente los
factores de riesgo adquirente-proveedor que tienen el potencial de afectar las
relaciones con
www.it-ebooks.info
9.9 CONTROL DEL PROCESO DE GESTIÓN DE RIESGO 393
TABLA 9.14 Formato de un formulario de notificación de riesgos

número de informe de riesgos:
Remitente: [nombre e información de contacto]
Categoría de riesgo: [horario, recursos, costo, otra técnica]
Nivel de gravedad:
Descripción:
Potencial
impacto: Período
de tiempo:
disposición recomendada: [evitar, transferir, aceptar, la acción inmediata, la acción
contingente]
Plan de Aplazar RMB

contingen proyec
cia to
• Evitar nue
seguimi • Transfer vo
ento de Análisi Conocido
ir
las • Acepta s de
métricas r riesgo
Actualización • Act
y el informe del Cerrar y
informe o
Estado • Recha
zar
Invocar Manejo
contingente de Crisis
acciones Formulario de
Cerrar y informe Informe de Riesgos
• Cliente
• Márketing
• Los
gestores
• Lideres de
equipo
• Desarrollad
ores
• subcontratistas
FIGURA 9.4 El flujo del proceso para controlar el proceso de gestión de riesgos
su cliente y gestionar conjuntamente los factores de riesgo con su subcontratista

(s), en su caso (véase la Sección 9.11 y 9.12).
Como se indica en la figura 9.4, los interesados se informan mediante los
formularios de notificación de riesgos artículos de interés para proyectar. Los
productos son analizados por un analista de riesgo (que, en un proyecto pequeño,
tal vez por un asistente personal en proyectos más grandes). El remitente es
notificado si el factor de riesgo que ya se conoce y está siendo manejado. De lo
contrario, el analista revisa el informe de riesgo, ella o su concurrencia u otras
recomendaciones añade, y envía el informe a la RMB.
El RMB toma acción (o dirija a otros a tomar medidas) a:
• evitar,
• transferir,
• aceptar el factor de riesgo y colocarlo en una lista de vigilancia,
• desarrollar y ejecutar un plan de acción inmediata ( “Ley” en la Figura 9.4), o
• desarrollar un plan de contingencia y controlar el factor de riesgo ( “Defer”
www.it-ebooks.info
en la figura 9.4);
o el RMB podrá decidir rechazar el informe de riesgos.
www.it-ebooks.info
En todos los casos distintos de rechazo del informe de riesgo, un nuevo

elemento se introduce en el registro de riesgos adecuada (equipo, proyecto,
departamento, cliente, subcontratista). Como todos los productos de trabajo
importantes, el registro de riesgos se coloca bajo el control de versiones para
evitar cambios no autorizados y proporcionar un registro histórico de las
actividades de gestión de riesgos.
Si la decisión es controlar el factor de riesgo, se desarrolla un plan de
contingencia (véanse las Tablas 9.10 y 9.11), una o más métricas de indicadores
de riesgo se realiza un seguimiento, y el estado se informa sobre una base
periódica. En algún momento de la entrada en el registro de riesgos se puede
cerrar, porque el riesgo no se materializó, o una métrica indicador de riesgo
puede desencadenar acciones contingentes porque la métrica cruzó un valor
umbral predeterminado.
acciones contingentes pueden manejar con éxito un factor de riesgo que se ha
convertido en un problema. En ese caso, el factor de riesgo está cerrado en el
registro de riesgos. O bien, las acciones contingentes pueden fallar para superar
el problema en el marco de tiempo especificado y el proyecto entra en modo de
crisis.
9.10 GESTIÓN DE CRISIS
Un proyecto entra en modo de crisis, cuando un evento o una situación detiene el

progreso. La gestión de crisis es el proceso de limpiar el puesto de control para
que el progreso puede reanudar. Recordemos que el objetivo de la gestión de
riesgos es identificar los factores de riesgo con la suficiente antelación para evitar
las situaciones de crisis. Así, un proyecto nunca entraría en estado de crisis, si la
gestión del riesgo fue del 100% efectivo. Sin embargo, ningún proceso es 100%
efectivo, por lo que la posibilidad de situaciones de crisis hay que reconocer. Hay
varias maneras de que un proyecto puede entrar en modo de crisis:
• no identificar sistemáticamente, priorizar y mitigar los problemas potenciales;

• la identificación de problemas potenciales, pero sin tomar medidas de
mitigación;
• situaciones y acontecimientos imprevistos e imprevisibles; y
• fracaso de un plan contingente de acción para resolver el problema en el
marco de tiempo asignado.
Podría ser, por ejemplo, que nadie previó la falta de suficiente memoria sería
un problema, o tal vez la posibilidad de que la memoria es insuficiente se
discutió, pero no se tomaron medidas de mitigación (incluyendo la falta de poner
el factor de riesgo en una lista de vigilancia), o tal vez el plan de acción
contingente, como ejecutado por Joe y Sue, no pudo resolver el problema dentro
de los 7 días asignados a solucionar el problema.
Directrices para la gestión de situaciones de crisis
incluyen:
• reconociendo la situación,
• la asignación de recursos suficientes,
• la búsqueda de soluciones creativas,
• la revisión del estado con frecuencia, y
www.it-ebooks.info
• fijar una fecha “drop-dead”.
www.it-ebooks.info
9.11 Gestión del riesgo a nivel de la organización 395
Un proyecto en estado de crisis está en peligro de fracaso. interesados

apropiados, incluyendo los gestores de clientes y de nivel superior, deben ser
notificadas; doloroso como que sea. A fecha de abandono muertos para el
proyecto debe establecida por las partes interesadas. Debido a que el proyecto
está en peligro, todos los recursos disponibles que se pueden utilizar de manera
productiva deben ser asignados para superar la crisis, aunque otras actividades
laborales deben detenerse temporalmente. soluciones creativas deben ser
exploradas, pero no en la medida en que el progreso es superada por “parálisis de
análisis.” Estado debe revisarse a diario, o incluso dos veces al día, en las
reuniones de estado cortos con los participantes se limitan a los que participan
directamente en el intento de superar la crisis (por ejemplo, de 15 a 30 minutos
reuniones de stand-up).
Si la crisis se supera en el tiempo asignado para la gestión de crisis, EGLAS
sched-, presupuestos y planes de trabajo debe ser revisado para tener en cuenta el
tiempo y los recursos dedicados a la gestión de crisis.
La última guía, el establecimiento de una fecha “drop-dead”, es
particularmente importante para forzar una acción decisiva cuando una crisis no
puede ser superada dentro de un plazo determinado; de lo contrario, un proyecto
puede languidecer en estado de crisis mucho más allá de un punto de decisión
razonable. La decisión resultante en la fecha de abandono muertos será:
1. cancelar el proyecto o
2. re-alcance significativamente ella.
Si el proyecto se cancela un plan de terminación debe ser preparado y

ejecutado. El plan debe incluir un plan de redistribución de los miembros del
proyecto y puede requerir difíciles negociaciones con el cliente, que puede ser
interno o externo a la organización. Si se vuelve a con ámbito del proyecto, los
requisitos y un plan de proyecto deben ser desarrollados para el proyecto (nuevo).
En cualquier caso (superar con éxito la crisis, la cancelación del proyecto, o
significativamente modificar el ámbito de ella), los miembros del personal que
han hecho contribuciones extraordinarias en el intento de superar la crisis deben
ser recompensados por sus esfuerzos. La recompensa puede tomar la forma de un
par de días de descanso para recuperar el sueño y ver a los miembros de la
familia, además de una carta o correo electrónico de apreciación (la recompensa
recomendado), o una cena para la familia, o los viajes de conferencia, o alguna
combinación de éstos.
9.11 Gestión del riesgo a nivel de la organización
La mayoría de los procesos, métodos y técnicas que se presentan en este capítulo

se con- cerned con el manejo de los factores de riesgo a nivel de proyectos
individuales. La gestión de los factores de riesgo en sus proyectos de software
será más fácil, y más probabilidades de tener éxito, si la gestión del riesgo se
apoya en el nivel organizativo de la organización en la que se lleva a cabo su
proyecto. Las comunicaciones con los altos directivos y tomers cliente central
que se basan en la gestión de riesgos que puedan comprender las opciones
competitivas, financieros y estratégicos para los sistemas, productos y familias de
productos.
Los factores que dan lugar a la gestión de riesgos exitosa a nivel de
organización incluyen [Fairley96]:
www.it-ebooks.info
• definición explícita de desarrollo y gestión de las prácticas,

• comunicación basada en la gestión de riesgos,
• riesgo de información a altos directivos y
• una política corporativa de gestión de riesgos de proyectos de software.
A riesgo a nivel corporativo las políticas de gestión deben exigir, para todos los
proyectos:
• planes de gestión de riesgos desarrollados en la etapa de planificación de un
proyecto y incorporado en el plan general del proyecto;
• la adaptación específica para el proyecto del proceso de desarrollo y los
métodos de gestión de riesgos, herramientas y técnicas a utilizar; y
• opinión explícita de los factores de riesgo sobre una base regular y continua.
Como se ha indicado anteriormente en este capítulo, los procesos de gestión de
riesgos uniformes en toda la unidad de organización es un área de proceso de
nivel 3 en la representación por etapas de CMMI-DEV-v1.2.
9.12 GESTIÓN CONJUNTA DE RIESGO
Algunos factores de riesgo pueden requerir estrategias de mitigación que

implican una al cliente central externa, su organización (el proveedor), y (el
director del proyecto). Por ejemplo, la reducción de los factores de riesgo creadas
por las necesidades operacionales ambiguas pueden requerir una mayor
participación de los usuarios representativos; mitigación de los factores de riesgo
técnico puede requerir una mayor asignación de recursos (es decir, dinero) por
parte del cliente, una mayor participación con un grupo de hardware, o de-
determinación del alcance de los requisitos. la gestión de riesgos efectiva a este
nivel requiere una gran cantidad de confianza y cooperación entre el cliente y el
proveedor (su organización). Por otro lado, si no hay confianza o cooperación
entre adquirente y proveedor del proyecto probablemente fallará en cualquier
caso.
Del mismo modo los factores de riesgo que se presentan en el uso de
subcontratistas deben ser administrados conjuntamente por usted (el cliente del
subcontratista) y el subcontratista (el proveedor). Cada subcontrato debe exigir al
subcontratista a la práctica la gestión interna de los riesgos y las articulaciones.
• Un factor de riesgo es un problema potencial que se convierte en un

verdadero problema cuando un indicador de riesgo medido objetivamente
cruza un umbral predeterminado.
• Los factores de riesgo se caracterizan por la probabilidad de ocurrencia y la
pérdida de potencial.
• El riesgo del proyecto es el conjunto de factores de riesgo que tienen el
potencial de afectar negativamente a un proyecto de software.
• La mayoría de las normas y directrices para la gestión de proyectos de
software incluyen la gestión de riesgos como un proceso clave.
• técnicas convencionales de gestión de proyectos para la planificación y
estimación, medición y control, y liderar y dirigir proyectos de software son
institucionalizados técnicas utilizadas para gestionar los factores de riesgo
www.it-ebooks.info
genéricos.
www.it-ebooks.info
CEREMONIAS 397
• técnicas de gestión de riesgos se utilizan para identificar, analizar, priorizar y

factores de riesgo específicos del proyecto mitiga puerta.
• las estrategias de mitigación de riesgo incluyen la evitación, el traslado, la
aceptación, la acción inmediata, y la acción contingente.
• mitigación de riesgos exitosa reduce la probabilidad y / o la pérdida de un
problema potencial a niveles aceptables.
• La gestión de los factores de riesgo en sus proyectos de software será más
fácil, y más probabilidades de tener éxito, si la gestión del riesgo se apoya en
el nivel organizativo de la organización en la que se lleva a cabo su proyecto.
• Usted y su cliente, y usted y sus subcontratistas (si lo hay), debe participar
en la gestión conjunta de los riesgos.
Referencias
[Boehm91] Boehm, BW gestión de riesgos del software: Principios y prácticas. software
IEEE (enero de 1991). vol. 8, No. 1. pp 32-41.
[Carr93] Carr, MJ, et al. Taxonomía-Basado identificación de riesgos.www.sei.cmu.edu/pub/
documentos / 93.reports / pdf / tr06.93.pdf, 1993.
[CMMI06] SEI. CMMI ® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[Davis03] Davis, A. El arte de los requisitos de triaje. IEEE Computer (marzo de
2003). Vol.
32, No. 3. pp 42-49.
[Fairley94] Fairley, RE gestión de riesgos para proyectos de software. IEEE Software
(mayo de 1994). vol. 11, No. 3, pp 57-67.
[Fairley96] Fairley, R., y P. Rook. La gestión del riesgo para el desarrollo de software.
IEEE Tutorial sobre Ingeniería de Software. IEEE Computer Society, 1996.
pp 387-400.
[Fairley05] Fairley, RE glosario de software de gestión de riesgos. IEEE Software (mayo /
junio de 2005). Vol. 22, No. 3, pp 101.
[IEEE1540] IEEE Std 1540 ™ -2001. IEEE estándar para el software del Ciclo de Vida
procesos- Gestión de Riesgos, Ingeniería normas de recopilación. IEEE
producto: SE113. Instituto de Ingenieros Eléctricos y Electrónicos, agosto
de 2003.
[VALOR] http://www.value-eng.org/.
CEREMONIAS
9.1. CMMI-DEV-v1.2 enumera tres áreas relacionadas con los procesos en el

área de proceso de gestión de riesgos: la planificación de proyectos,
monitoreo y control de proyectos, y la decisión
www.it-ebooks.info
análisis y resolución. Acceder al sitio Web en

CMMIhttp://www.sei.cmu.edu/publicaciones / documentos / 06.reports /
06tr008.html. Revisar el área de procesos de gestión de riesgos, y explicar
brevemente cómo cada una de las tres áreas de procesos relacionados con
ellos se relacionan con la gestión de riesgos.
9.2. La Tabla 9.1 enumera algunos factores de riesgo que ocurren comúnmente
para proyectos de software. Lista de tres factores de riesgo adicionales que
pueden ocurrir en los proyectos de software y proporcionar un ejemplo de
cada uno.
9.3. Uno de los factores de riesgo enumerados por Boehm en [Boehm91] ejerce gran
presión en las capacidades de la informática; es decir, tratar de implementar
software para el cual no se conocen los algoritmos. Da tres ejemplos que no se
mencionan en este texto de áreas en las que un cliente puede solicitar
características que pondría a prueba las capacidades de la informática. Explicar
brevemente cada uno.
9.4. En la Sección 9.1 se afirma que se podría crear un riesgo para la capacidad
de mantenimiento por violar los principios de acoplamiento y cohesión con
el fin de evitar el problema de exceder la memoria disponible.
a. Explique brevemente cómo el uso de memoria podría reducirse al violar
los principios de acoplamiento y cohesión.
b. Explique brevemente cómo violar esos principios podría crear un riesgo
de mantenimiento.
9.5. exceso de horas extraordinarias es un método inaceptable para superar los
problemas en un proyecto de software.
a. Brevemente explique la cantidad de horas extras es excesiva, en su opinión.
b. Explica brevemente tres factores de riesgo para el éxito del proyecto que
son creados por exceso de horas extraordinarias.
9.6. proyectos de software a menudo tienen factores de riesgo que no son
evidentes durante la planificación inicial de un proyecto de software. Da tres
ejemplos de factores de riesgo no citadas en este texto que podría no ser
evidente durante la planificación inicial de un proyecto de software.
Explicar brevemente cada uno.
9.7. Seleccione una técnica de gestión de riesgos (evitar, transferencia, aceptar,
acto, aplazar, rechazar) para cada uno de los factores de riesgo enumerados
en la Tabla 9.2 (10 total). Brevemente explica cómo cada una de las técnicas
de gestión de riesgos que ha seleccionado se puede utilizar para controlar los
factores de riesgo para proyectos de software. Seleccione cada una de las
seis técnicas al menos una vez.
9.8. En la Sección 9.2 se da un ejemplo de un factor de riesgo que se convertirá
en un problema si su arquitectura de software sale de su empresa.
Brevemente explique 3 técnicas que podría utilizar para mitigar los
problemas que se crearían si ella se va. Tenga en cuenta que todavía no ha
dejado y que no puede salir.
9.9. Prepare una hoja de cálculo para implementar un registro de riesgos utilizando
el formato en la tabla
9.13. Rellenar la hoja de cálculo con algunos factores de riesgo de los
ejercicios de 9,7 y 9,8, y / o algunos factores de riesgo hipotéticos. La mano
en su programa de hoja de cálculo y una lista impresa de la salida de la
www.it-ebooks.info
misma.
www.it-ebooks.info
ANEXO 9A

para
GESTIÓN DE RIESGOS
9A.1 LA CMMI-DEV-v1.2 área de gestión de riesgos de los procesos
El marco de proceso de CMMI-DEV-v1.2 incluye la gestión de riesgos como un

área de proceso en el nivel 3 en la representación por etapas y, como un área de
proceso de gestión de proyectos en la representación continua. Como se indica en
CMMI-DEV-v1.230:
El propósito de Gestión de Riesgos (RSKM) es identificar problemas potenciales antes

de que ocurran para que las actividades de manejo de riesgo se pueden planificar e
invocados como sea necesario a través de la vida del producto o proyecto para mitigar
los impactos adversos sobre el logro de objetivos.
Las metas específicas y prácticas específicas de gestión del riesgo en los

modelos de procesos CMMI son:
SG 1 Prepárese para la gestión de riesgos

SP 1.1 Determinar las fuentes de riesgo y
categorías de SP 1.2 Definir los parámetros
de riesgo
SP 1.3 Establecer una estrategia de gestión
de riesgos SG 2 Identificar y analizar los riesgos
SP 2.1 Identificar los riesgos
SP 2.2 Evaluar, clasificar y priorizar los riesgos
SG 3 riesgos Mitigar
SP 3.1 Desarrollar planes de mitigación de riesgos
SP 3.2 Implementar planes de mitigación de riesgos
áreas de procesos relacionados con la gestión del riesgo en los modelos CMMI
son:
30
CMU / SEI-2006-TR-008, página 432.
399
www.it-ebooks.info
• Planificación de proyectos,
• Seguimiento y control de proyectos, y
• Análisis de Decisiones y Resolución.
9A.2 ISO / EIC y IEEE / EIA NORMAS 12207
Apéndice G, Sección G.10, de IEEE / EIA Estándar 12207.0 (proceso de gestión)

incluye los siguientes objetivos:
• determinar el alcance de la gestión de riesgos a ser realizado para el proyecto;

• identificar los riesgos para el proyecto a medida que desarrollan;
• analizar los riesgos y determinar la prioridad en la que aplicar los recursos
para mitigar esos riesgos;
• definir, implementar y evaluar las estrategias de reducción del riesgo
adecuadas; y
• definir, aplicar y evaluar las medidas de riesgo para medir el cambio en el
estado del riesgo y el progreso de las actividades de mitigación.
El ámbito de la gestión de riesgos incluye las actividades a realizar, que se

enumeran en el anexo L de IEEE / EIA 12.207,2:
• planificación de los riesgos

• identificación de riesgo
• análisis de riesgo
• mitigación de riesgos
• seguimiento y control de riesgos
IEEE Standard AIE / 12207.2, Sección L.2 (planificación de riesgos),

establece que un plan de gestión de riesgos debe desarrollarse y que el plan debe
incluir métodos para realizar la gestión de riesgos, las formas en que serán
documentadas e informadas las actividades de gestión de riesgos, los
responsables de las actividades de gestión de riesgos, y las formas en las cuales el
riesgo factores y su estado se comunicará a otras organizaciones, como el
adquiriente y subcontratistas. También se observa que el plan de gestión de
riesgos puede ser parte del plan de gestión de proyectos.
Sección L.1 del Anexo L en 12.207,2 hace hincapié en que la gestión de
riesgos es parte del proceso de gestión general y no es un sustituto para otras
actividades de gestión de proyectos (es decir, la gestión de riesgos propugne
gestión de proyectos convencional).
El numeral 5.4 de la norma IEEE 1058-1998 para los planes de gestión de

proyectos de software (plan de gestión de riesgos) establece que los planes de
gestión de riesgos identifique:
• procesos y procedimientos que se utilizarán para identificar, analizar,

priorizar y mitigar los factores de riesgo del proyecto, tanto inicialmente
como durante todo el ciclo de vida del proyecto;
www.it-ebooks.info
• métodos que se utilizan para realizar un seguimiento de los diversos factores

de riesgo;
• métodos de evaluación de los cambios en los niveles de factores de riesgo; y
• planes para responder a los cambios.
Además de un plan de gestión de riesgos debe especificar quién será el

responsable de los diversos aspectos de la gestión del riesgo, con qué frecuencia
se examinarán los factores de riesgo, el proceso de revisión, y que estarán
involucrados. Asimismo, el plan debe especificar cómo se informa del estado de
riesgo ya quién.
Los factores de riesgo que deben ser considerados incluyen posibles
problemas en:
• relación adquirente-proveedor;
• factores contractuales;
• factores tecnológicos;
• tamaño y la complejidad del producto;
• de desarrollo y de destino entornos;
• el personal de adquisición, niveles de habilidad, y de retención;
• calendario y el presupuesto; y
• adquirente la aceptación del producto.
Sección 5.4 del Apéndice B en el Capítulo 4 de este texto plantea una serie de
cuestiones que deben abordarse en la preparación de un plan de gestión de
riesgos.
Capítulo 11 de la Guía para la Gestión de Proyectos PMI Cuerpo de

Conocimiento (PMBOK) se ocupa de la gestión de riesgos. La introducción del
capítulo 11 establece que los objetivos de la gestión de riesgos del proyecto son
aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la
probabilidad y el impacto de los eventos adversos al proyecto.
Los temas abordados en el capítulo 11 del PMBOK
incluyen:
• Planificación de la gestión de riesgos,

• Identificación de riesgo,
• Análisis Cualitativo de Riesgos,
• Análisis Cuantitativo de Riesgos,
• Correr el riesgo de Planificación de la respuesta, y
• Seguimiento de Riesgos y Control.
De acuerdo con PMBOK, la distinción entre la gestión de riesgos cuantitativa y

cualitativa se determina por el grado en que los números objetivamente derivados
se pueden asignar a las probabilidades y los impactos de los problemas
potenciales, como se ilustra en las Tablas 9.1a y 9.1b de este capítulo.
www.it-ebooks.info
9A.5 estándar IEEE 1540
Aunque la gestión de riesgos se menciona a lo largo de la norma ISO / IEC e IEEE /

EIA Normaliza- ción 12207, que no contienen un proceso de gestión del riesgo
explícito. Norma IEEE 1540-2001 es el estándar IEEE para el Ciclo de Gestión de
Procesos de vida-riesgo [IEEE1540].
De acuerdo con la norma IEEE 1540, los procedimientos que implementan el
proceso de gestión de riesgos identifique:
• frecuencia a la que los riesgos han de ser volvieron a analizar y monitoreadas,

• tipo de análisis de riesgos requerida (cuantitativa y / o cualitativa),
• escalas de medición que se utiliza para estimar la probabilidad de riesgos y
consecuencias,
• tipos de umbrales de riesgo que se utilizarán,
• tipos de medidas utilizadas para seguir y controlar el estado de los riesgos,
• cómo los riesgos están a ser priorizados para el tratamiento,
• el cual las partes interesadas (s) Perspectivas del proceso de gestión de
riesgos apoya, y
• categorías de riesgo a tener en cuenta.
La norma contiene 5 anexos (es decir, anexos):
• Anexo A: plan de gestión de riesgos

• Anexo B: solicitud de acción de riesgo
• Anexo C: Plan de tratamiento del riesgo
• Anexo D: aplicación de la gestión de riesgos en la serie IEEE / EIA 12207
• Anexo E: bibliografía anotada
El contorno de los planes de gestión del riesgo en el Anexo A de la norma

IEEE 1540 contiene los siguientes temas que se incluirán en el plan de gestión de
riesgos para cada proyecto:
• políticas y directrices que deben seguirse

• responsabilidades para la gestión de riesgos
• orientación de la gestión de riesgos y la formación
• costos y horarios para la gestión de riesgos
• una descripción del proceso de gestión de riesgos
° análisis de riesgo
° seguimiento del riesgo
° tratamiento del riesgo
• evaluación del proceso de gestión de riesgos
° la captura de información de riesgo
° evaluar el proceso de gestión de riesgos
° lecciones aprendidas de generación
www.it-ebooks.info
9A.5 estándar IEEE 1540 403
• la comunicación de riesgos
° documentación y presentación de informes
° coordinación de la gestión de riesgos con las partes
interesadas
° coordinación de la gestión de riesgos con las partes interesadas
• procedimientos de cambio y la historia
www.it-ebooks.info
ANEXO 9B
SOFTWARE DE GESTIÓN
DE RIESGO GLOSARIO
Plan de contingencia Un plan para hacer frente a un factor de riesgo, en caso de

ser un problema.
la gestión del riesgo continuo El proceso de analizar el progreso de una
planificada actividad, proyecto, programa o sobre una base periódica,
permanente y gastos de los factores de riesgo identificados; Incluye opciones
en desarrollo y posiciones de retirada para permitir soluciones alternativas
para reducir el impacto si un factor de riesgo se convierte en un problema.
Crisis Un crítico estado de cosas en el que una decisiva, resultado indeseable es
inminente.
Gestión de crisis Pasos a seguir cuando un plan de contingencia no resuelve el
problema aso- ado.
Problema Una situación negativa a superar. Un factor de riesgo se convierte en
un problema cuando una medida de riesgo (una medida objetiva) cruza un
umbral predeterminado (el gatillo problema).
Riesgo La probabilidad de incurrir en una pérdida o soportar un impacto
negativo.
aceptación del riesgo El reconocimiento de la existencia de un factor de riesgo,
junto con la decisión de aceptar las consecuencias si se produce el problema
correspondiente; también llamado asunción de riesgos.
Análisis de riesgo El proceso de examinar los factores de riesgo identificados para la
probabilidad de ocurrencia, la pérdida potencial y posibles estrategias de riesgo de
manipulación.
Evitación de riesgo Un curso de acción que elimina un factor de riesgo de una
mayor con- sideración (por ejemplo, cambiando los requisitos, que se extiende
el horario, o anillo Transfer- la causa del factor de riesgo a otro dominio).
Riesgo de exposición El producto de veces de probabilidad potencial de pérdida
para un factor de riesgo; por lo general en una escala ordinal (por ejemplo,
bajo, medio, alto) o se expresa en una escala de proporción en unidades
monetarias o utilidad.
Factor de riesgo Un problema potencial que sería perjudicial para una actividad
planificada, proyecto, o programa, caracterizado por la probabilidad de
ocurrencia problema
www.it-ebooks.info
404
www.it-ebooks.info
SOFTWARE DE GESTIÓN DE RIESGO GLOSARIO 405
(0 p 1) y una pérdida potencial (de la vida, el dinero, la propiedad, la

reputación, etc) debe producirse el problema. Tanto la probabilidad y la pérdida
potencial podrían cambiar con el tiempo.
manejo de riesgos Un curso de las medidas adoptadas en respuesta a un factor
de riesgo; incluye la aceptación de riesgos, evitar riesgos, la transferencia del
riesgo, y la mitigación de riesgos.
Identificación de riesgo Un método sistemático y organizado para la
determinación de los factores de riesgo asociados con una planificada la
actividad, del proyecto o programa.
factor de apalancamiento de riesgo (RLF) RLF (REA Reb ) / rmc, donde Reb es
la exposición al riesgo ante el riesgo
mitigación, rea es la exposición al riesgo después de la mitigación de riesgos, y
RMC es el costo de la actividad de mitigación de riesgos. Un rlf mayor indica
una mejor estrategia de mitigación.
Gestión de riesgos Un proceso organizado para identificar y manejar los factores
de riesgo; incluye la identificación inicial y la manipulación de factores de
riesgo, así como la gestión del riesgo continuo.
medida de riesgo Una medida objetiva asociado con un factor de riesgo para ser
mitigado.
Mitigación de riesgos Un curso de las medidas tomadas para reducir la
probabilidad de y / o potencial pérdida de un factor de riesgo; incluye la
ejecución de los planes de emergencia cuando una medida de riesgo cruza un
umbral predeterminado (cuando un factor de riesgo se convierte en un
problema).
La reducción de riesgos La reducción de la probabilidad y / o impacto potencial
de un factor de riesgo; podría implicar la investigación, la creación de
prototipos, y otros medios de exploración.
La transferencia del riesgo Transferir la responsabilidad de la gestión de un
factor de riesgo a otra organización o entidad funcional en mejores
condiciones para mitigar el factor de riesgo.
disparador de riesgo El valor umbral predeterminado de una medida de riesgo
que desencadena la invocación de un plan de contingencia cuando la medida
de riesgo cruza el umbral.
análisis de causa raíz Determinación de la causa o causas subyacentes (un factor
de riesgo de) de un problema potencial.
Incertidumbre El resultado de no tener un conocimiento preciso o suficiente de
un ción situa-; a menudo la causa raíz de un factor de riesgo.
Utilidad Una medida de valor dentro de un contexto dado, a menudo se mide en
una escala de 0 a 100.
www.it-ebooks.info
10
EQUIPOS, trabajo en equipo, motivación,
liderazgo y comunicación
Si sus acciones inspiran a otros a soñar más, aprender más, hacer más y ser más, usted
es un líder.
-John Quincy Adams
10.1 INTRODUCCIÓN
Los tres activos clave para proyectos de software son las personas, procesos y
tecnología. Para tener éxito, debe tener el número correcto de personas que tienen
habilidades adecuadas y están motivados para hacer su mejor trabajo. Los
procesos incluyen procedimientos para llevar a cabo el trabajo y la coordinación
de las actividades de trabajo. La tecnología incluye la infraestructura, métodos,
hardware, herramientas de software, y otros equipos necesarios para desarrollar
el producto. Las personas son el activo más importante; la gente de su gran
capacidad y motivación a menudo puede superar los procesos y la tecnología
inadecuados, pero excelentes procesos y la tecnología no pueden compensar la
falta de capacidad y la motivación. También los salarios de los miembros del
proyecto son típicamente el mayor componente de los costos del proyecto.
Además de la capacidad individual y la motivación, los proyectos de software
requieren el trabajo en equipo estrechamente coordinada. Los equipos son
esenciales porque se necesita la variedad de habilidades que poseen los diferentes
miembros del equipo y porque nadie está interesado en esperar 10 años para 1
persona para completar un proyecto de 10 años persona que podría completarse
en 1 año por 10 personas. Además, la sinergia que se produce cuando los
miembros del equipo trabajan juntos en un espíritu de colaboración a menudo
resulta en un producto superior a la que habría resultado de los esfuerzos de
varias personas que trabajan de forma aislada. Los desarrolladores de software
deben ser contribuyentes individuales, así como los miembros del equipo
dispuestos y entusiastas.

407
www.it-ebooks.info
408 EQUIPOS, trabajo en equipo, motivación, liderazgo y comunicación
Debido a que el desarrollo de software y la modificación son los esfuerzos

intelectuales, estrecha coordinación de las de su equipo (o equipos) esfuerzos es
esencial. Por desgracia, algunos ingenieros de software con habilidades técnicas
pendientes no están interesados en ser, ni están psicológicamente aptos para ser
miembros de un equipo cohesionado.
Con demasiada frecuencia, las organizaciones de software son culpables de
suboptimización la productividad de un equipo por atender a la idiosincrasia de
las personas con habilidades técnicas pero socialmente ineptos. En algunos casos,
puede ser necesario quitar un miembro del equipo perjudicial para el mayor bien
del equipo, el proyecto y la organización.
Este capítulo se ocupa de los aspectos del trabajo en equipo, motivación y
estilos de dirección de proyectos de software. Estos factores ejercen una fuerte
influencia en la moral de las personas y equipos, y como resultado, la
productividad, la tasa de producción, la calidad del producto y la satisfacción del
cliente.
• la gestión de frente que conduce,

• la naturaleza de los equipos y el trabajo en equipo,
• técnicas para mantener la moral y la motivación,
• estilos de personalidad, y
• el modelo de comportamiento de 5 capas de desarrollo de software.
Las normas y directrices que se presentan en cada uno de los capítulos anteriores, a
saber, CMMI-DEV-v1.2, ISO / IEEE 12207, el estándar IEEE 1058, y el Cuerpo de
Conocimiento del PMI, problemas de las personas de dirección en un grado limitado.
Otras directrices para liderar y dirigir los esfuerzos individuales y de equipo incluyen
las personas CMMI, el proceso de software del equipo (TSP) que se basa en el
proceso de software personal (PSP), y los pros y en el texto Peopleware. Un resumen
de estas directrices se proporciona en el Apéndice 10A a este capítulo.
10.3 GESTIÓN DE FRENTE A LÍDER
Sus funciones, como director del proyecto, incluyen la gestión del proyecto y
dirigir al personal del proyecto. La gestión se ocupa de hacer planes y
estimaciones, ING collect- y el análisis de los datos del proyecto y del producto,
informes de progreso, que controla el proceso de desarrollo y los productos de
trabajo, e identificar y mitigar los factores de riesgo. Líder se refiere a la
comunicación con el personal del proyecto y otras partes interesadas, la
coordinación de las actividades de trabajo y mantener la moral.
Los buenos gerentes no son necesariamente buenos líderes, y los buenos
líderes no son necesariamente buenos gestores. Gerente es una actividad
analítica, mientras que conduce implica relaciones humanas. Se requieren
diferentes rasgos de personalidad y diferentes conjuntos de habilidades para
www.it-ebooks.info
10.3 GESTIÓN DE FRENTE A LÍDER 409
TABLA 10.1 Algunos atributos de los líderes efectivos

• escucha con atención
• autoridad delegados
• facilita el trabajo en equipo
• Coordina las actividades de trabajo
• facilita la comunicación
• Habla con las personas sobre una base diaria
• Dice “gracias” cuando sea necesario
• Los entrenadores y los trenes
• mantiene el entusiasmo
• reconcilia diferencias
• resuelve los conflictos
• Adoctrina al personal recién asignados
• Ayuda a los empleados a desarrollar planes de carrera y lograr sus objetivos profesionales
• Reasigna, las transferencias, y termina personal como sea necesario
la gestión y de dirigir. Algunos excelentes gerentes son líderes pobres y algunos

excelentes líderes son malos gestores.
Un líder eficaz es un buen oyente que escucha, oye y responde al subtexto, así
como el texto principal de una conversación; es un facilitador que proporciona el
catalizador para el trabajo en equipo; es un entrenador que proporciona
orientación y fomentados ción; y es un entusiasta que cree en el equipo del
proyecto y los objetivos del proyecto. Los atributos de los líderes efectivos se
enumeran en la Tabla 10.1.
Para ser un gestor de proyectos eficaz, debe identificar aquellas actividades de
gestión y líder para el que tenga una aptitud y la que le gusta hacer. A
continuación, debe encontrar maneras de compensar las otras actividades de
trabajo que no disfrutas y para los que no tienen la aptitud. Como Tom DeMarco
ha dicho, “averiguar lo que no es bueno y no lo hace.” 31
Usted puede encontrar, por ejemplo, que son una excelente líder que establece
fácilmente buenas relaciones de trabajo con los demás y que los demás disfrutan
de trabajar con usted, pero que no disfruta de la preparación de informes sobre el
valor ganado o el análisis de datos de defectos. En este caso, usted y su
organización puede resultar rentable para delegar las tareas cal analíticamente a
una persona designada que trabajará con usted en aquellas tareas que, para ti, son
poco atractivos. Esa persona podría ser un asistente personal que trabaja con
usted en un tiempo parcial o tiempo completo, dependiendo del alcance del
proyecto o, la persona podría ser alguien a quien se le tutoría y preparación para
convertirse en un director de proyecto.
O puede ser, a fuerza de su personalidad y el conjunto de habilidades, usted es
un excelente gestor pero menos capaces como un líder. Usted puede encontrar
que su líder técnico (es decir, arquitecto de software) es el líder de facto de los
desarrolladores de software para los que buscan las decisiones técnicas y
orientaciones. Esto puede ser un arreglo muy eficaz, siempre y cuando usted y su
líder técnico tiene una estrecha relación de trabajo, una clara comprensión de sus
ámbitos de responsabilidad, y la capacidad de resolver sus diferencias en privado,
presentando así un frente unido.
La división de responsabilidades entre usted, como director del proyecto, y su
líder de cal técnicamente son los siguientes:
31
Conversación privada.
www.it-ebooks.info
• Usted es responsable de la entrega de un producto aceptable a tiempo y

dentro del presupuesto.
• Su líder técnico es responsable de dirigir el equipo del proyecto para
alcanzar la parte “producto aceptable” de la ecuación, dentro de las
limitaciones de horario y presupuesto.
Como se observa Fred Brooks, usted, el director del proyecto, es similar a la

película pro-ductor que es responsable de la totalidad del proyecto. El líder de su
técnica es similar a la del director de cine que es responsable del contenido del
producto [Brooks95]. Las películas más exitosas (y los proyectos de software)
son aquellos en los que el productor y el director tienen una relación de trabajo
armoniosa. Los fracasos son a menudo el resultado de incompatibilidades en los
puntos de vista y conflictos de personalidad entre el productor (director del
proyecto) y director (jefe técnico). Sus desarrolladores de software y personal de
apoyo son los actores y tramoyistas que trabajan para desarrollar un producto
capaz aceptable dentro de las limitaciones de programación, presupuesto, y la
tecnología.
En el mejor de los casos se dará cuenta de que son eficaces tanto como un
gerente y un líder. En proyectos pequeños puede funcionar como gerente y líder
técnico o, en pequeños proyectos, usted (el productor) y su líder técnico (el
director) puede trabajar simultáneamente juntos en dos o más proyectos
pequeños, aplicando así su conjunto de habilidades por separado en el forma más
beneficiosa.
Usted puede encontrar algunas tareas de administración son desagradables, ya
que no tiene la formación, herramientas, o infraestructura de la organización para
hacer sus tareas de una manera eficiente y eficaz. Una de las ironías de las
organizaciones de software (y del ing Engineer- organizaciones en general) es
que los mejores técnicos a menudo son seleccionados para ser gestores de
proyectos sin el beneficio de la formación, el aprendizaje o la tutoría en la gestión
y el liderazgo. Si tienen la suerte de recibir un apoyo adecuado de su
organización, puede convertirse en efectivo en áreas que anteriormente
considerados como sus debilidades.
10.4 EQUIPOS Y TRABAJO EN EQUIPO
Una de sus principales tareas como un líder es fomentar un ambiente de trabajo

en equipo dentro de su proyecto. Un equipo es un grupo de individuos que
trabajan de manera cooperativa y NATed coordinación para lograr los objetivos y
metas compartidas. Un grupo de personas que trabajan juntas no es un equipo si
no tienen una actitud de cooperación y comparten objetivos y metas comunes.
Los miembros del equipo son individuos que tienen objetivos individuales,
agendas, motivaciones, deseos, aptitudes y actitudes; pero para ser un equipo, los
miembros individual y específico también debe tener una visión compartida y
productos de trabajo compartido. Cada miembro debe estar dispuesto a
subordinar algunos de sus objetivos individuales a los objetivos compartidos del
equipo; mejor aún, los objetivos individuales deben estar alineados con los
objetivos del equipo. A cambio, las recompensas (y sanciones) deberían ser para
el equipo del proyecto en su conjunto, y para los equipos secundarios según sea
apropiado,
Coalescencia de los individuos en equipos cohesionados rara vez ocurre
espontáneamente. Los factores que contribuyen a la formación del equipo
incluyen las personalidades de los individuos y las condiciones sociales y
www.it-ebooks.info
culturales en la organización [Katzen93]. Algunos factores que contribuyen a los
equipos de software eficiente y eficaz se enumeran en la Tabla 10.2.
www.it-ebooks.info
411
TABLA 10.2 Factores que contribuyen a los equipos

de ingeniería de software eficientes y eficaces
• número adecuado de personas
• mezcla de habilidad correcta
• Las buenas herramientas
• una formación adecuada
• Respeto por el otro
• El respeto a los gerentes y líderes
• Voluntad de ser miembros del equipo
• La propiedad compartida de los productos de trabajo
• Buena capacidad de comunicación
• canales de comunicación buenas
• Buen ambiente de trabajo
• Tener un buen rato juntos
Una de sus principales responsabilidades, como director del proyecto, es el de

facilitar las condiciones que figuran en la Tabla 10.2 para que los miembros de
su proyecto se unirán en un equipo o equipos. Su equipo (s) proyecto debe tener
un número suficiente de personas que tienen las habilidades necesarias,
herramientas y capacitación para lograr los objetivos del proyecto dentro de los
con- straints de programación, presupuesto, requisitos, y la tecnología.
En muchas organizaciones los miembros del equipo son seleccionados
mediante la aplicación de, y siendo entrevistados para, la pertenencia al equipo
del proyecto. El solicitante puede ser un empleado de la organización o un
potencial nuevo empleado fuera de la organización. En el primer caso (un
empleado de la presente), se les permite solicitar puestos de trabajo que
constituyen las transferencias laterales al mismo nivel de habilidad o que
constituyen promociones a cargos como jefe de diseño, líder de un equipo de
desarrollo, líder del personal de toda la organización el equipo de pruebas, o un
probador de desarrollador. Los solicitantes no son aceptadas sin la aprobación de
las personas apropiadas, incluido usted (el director del proyecto), su jefe de
diseño, y los actuales miembros del equipo que trabajarían con el solicitante, y el
actual gerente del solicitante.
El respeto, como se dice a menudo, se debe ganar. Usted, el director del proyecto,
debe trabajar para ganarse el respeto de los miembros del equipo del proyecto
mediante la exhibición:
• competencia,
• capacidad,
• integridad y
• preocupación por su bienestar.
Cada miembro del proyecto debe presentar asimismo estas características para
ganar y mantener el respeto de los otros miembros del equipo.
Es posible que algunos individuos tienen ningún interés en ser miembros de un
equipo. Estos llamados lobos solitarios deben ser retirados de su equipo de
proyecto. Si esto no es posible, se debe encontrar tareas que pueden realizar de
forma relativamente aislada del resto del equipo; que no deben recibir
gratificaciones especiales y recompensas que resultan de los esfuerzos del
equipo. Como dice el refrán, “una manzana podrida puede estropear el barril;” un
individuo que no cooperan puede destruir un equipo de proyecto.
Un indicador clave de un equipo efectivo se comparte la propiedad de los
www.it-ebooks.info
productos de trabajo. Mientras que cada individuo es responsable de su o sus
asignaciones de trabajo y el trabajo
www.it-ebooks.info
productos, la propiedad compartida de los productos de trabajo es evidente

cuando los miembros del proyecto están dispuestos a ayudarse mutuamente. Por
el contrario, los grupos disfuncionales se caracterizan por una falta de voluntad
de los individuos para ayudar a los demás, tal vez debido a la presión excesiva
horario, exceso de horas extraordinarias, y / o la competencia entre los miembros
del equipo que no recompensa la cooperación.
Las buenas habilidades de comunicación, buenas vías de comunicación, y un
ambiente agradable físi- cas son conducentes al equipo coalescencia. Por último,
teniendo un buen rato juntos es el pegamento que se puede unir un equipo; Sin
embargo, las actividades “divertidas” deben ser cuidadosamente seleccionados.
No todo el mundo disfruta de los bolos o paintball.
Otras técnicas que contribuyen al equipo coalescencia incluyen:
• la realización de reuniones de planificación y revisión fuera de las instalaciones,

que incluyen el tiempo suficiente para la socialización informal,
• la organización de los miembros del equipo participan juntos en los cursos
de formación fuera de las instalaciones,
• proporcionando pizza o cookies para celebrar el logro de los hitos del
proyecto, y
• eventos sociales organizados como asistir a los partidos de béisbol o “día de
la familia” en los parques de atracciones.
En su texto Peopleware, Tom DeMarco y Tim Lister describen un “equipo

cuajado” como “un grupo de personas de punto con tanta fuerza que el todo es mayor
que la suma de las partes” [DeMarco99]. por lo tanto los equipos cuajados exhiben
sinergia en sus actividades de trabajo. En su texto, DeMarco y Lister describen los
atributos de los equipos cuajados, que incluyen:
• baja rotación de los miembros del equipo,

• un fuerte sentido de identidad con el equipo,
• una sensación de elitismo,
• propiedad conjunta del producto,
• voluntad de ayudar a otros, y
• evidente placer de la obra y el uno del otro.
“maneras seguras del fuego para inhibir la formación de equipos e interrumpir

la sociología proyecto” DeMarco y Lister entonces introducen el concepto de
“teamicide”, que es Teamicide técnicas incluyen:
• gestión defensiva,
• burocracia sin sentido,
• separación física de los miembros del equipo,
• fragmentación del tiempo,
• horarios poco realistas,
• falta de tiempo suficiente para producir productos de trabajo de calidad,
• control de camarilla, y
• exceso de horas extraordinarias.
www.it-ebooks.info
413
TABLA 10.3 Algunos antídotos para teamicide

Teamicide PracticeAntidote
Defensivo managementTrust miembros de su equipo hasta que se demuestre lo contrario;
fijar personal
problemas a medida que ocurren
Imbécil bureaucracyUse procedimientos rentables y papeleo; demostrar el
beneficio de ellos a todas las partes implicadas
Poco realista plazos deadlinesSet que tienen una probabilidad razonable de se
cumplan física separationProvide espacios de trabajo en grupo y las oportunidades de
casual
interacciones
La fragmentación de timeAssign personas a una tarea a la vez, ya un equipo de un
momento; evitar las tareas de extinción de incendios “”
Camarilla los miembros del equipo controlAllow a trabajar juntos durante períodos
prolongados de
hora
Calidad reductionDon't comprimir horarios sin de-la determinación del alcance de los
requisitos;
no añada requisitos sin extender el horario
Excesivo overtimeAvoid ¡eso!
Evitar teamicide es una condición necesaria para la construcción y el

mantenimiento de los equipos de cuajado. Tabla 10.3 lista algunos antídotos para
teamicide.
Para muchas organizaciones, la separación física de los diferentes equipos es
una realidad en la era de la globalización. En estos casos, el trabajo debe ser
dividido cuidadosamente de modo que los equipos geográficamente separados
pueden realizar sus actividades de trabajo relativamente aislados de otros
equipos.
Usted, como director del proyecto, debe desarrollar la confianza entre usted y
los miembros de su equipo y fomentar la confianza entre los miembros de su
equipo. La confianza, como el respeto, se debe ganar mediante la exhibición:
• honestidad,
• candor,
• sinceridad y
• seguir adelante
en acuerdos y compromisos en sus interacciones con los miembros de su equipo.

Un área común de la desconfianza por los miembros del equipo es la
preocupación por cómo se utilizarán los datos de productividad y de calidad
recogidos de los miembros individuales del equipo. Datos COL- cionado de
individuos siempre deben ser consolidados, analizados a nivel de equipos
pequeños, y se agregan entre los equipos pequeños como sea necesario para fines
de análisis y generación de informes. Usted debe hacer todo en su poder para
evitar asociación de individuos con los datos recogidos. Nada va a matar la
confianza más rápido que la divulgación o el uso de los datos prometidos que
tendrá lugar en la confianza.
Usted, como director del proyecto, debe evitar la tentación de “ser uno de los
chicos (o chicas)” al unirse en la programación, pruebas y actividades de revisión
a menos que usted es el gerente / técnico-líder de un pequeño proyecto (5 o
www.it-ebooks.info
menos personas) en la que son un contribuyente técnica.
Cuando los datos indican que el rendimiento de un individuo no es de las
expectativas, usted debe sostener una reunión privada con el individuo. El
objetivo y el tono de la
www.it-ebooks.info
reunión debe ser para determinar las condiciones que están causando inadecuada
Mance perfor- y para ayudar al individuo a desarrollar un plan de acción que va a
remediar esas condiciones. Remedios pueden incluir uno o más de:
• formación,
• tutoría,
• mejores herramientas,
• aclaración de las responsabilidades,
• reasignación de tareas dentro del proyecto, o
• reasignación a otro proyecto o departamento.
El bajo rendimiento puede requerir que usted y el trabajo individual con el

departamento de recursos humanos para resolver el problema (tal vez las
diferencias de personalidad hacen que, a juicio de la persona, el problema a
resolver).
Los líderes de los equipos pequeños (de 3 a 5 miembros) son responsables de
la vigilancia de la productividad y la calidad de la producción de sus miembros
del equipo, y para trabajar con sus miembros para aplicar acciones correctivas
para las deficiencias en el rendimiento. En proyectos grandes, puede ser
necesario que el líder del equipo y que, el director del proyecto, para trabajar en
privado con los miembros del equipo que no están funcionando, o no pueden
llevar a cabo con las expectativas. Los miembros del equipo, jefes de equipo y
otros que demuestran ser poco fiable y que no mejoran deben ser removidos de
su proyecto.
Otras técnicas teamicide enumerados en la Tabla 10.1 incluyen la burocracia
sin sentido y plazos poco realistas. burocracia sin sentido es a veces sin sentido,
pero a menudo se percibe como sin sentido basado en la falta de comprensión,
debido a que:
Lo que es productivo para el equipo o el proyecto no siempre es visto como productiva por
los individuos.
Completar informes de defectos y el tiempo y el esfuerzo dedicado a cada

tarea de grabación, por ejemplo, puede restar tiempo disponible para escribir
código o ejecutar casos de prueba; Sin embargo, estos datos son esenciales para
la medición y control de un proyecto eficaz. Cada individuo debe ver resultados
tangibles de la “documentación” que son beneficiosas para ellos, al proyecto, a la
organización ya los clientes. Por ejemplo, el análisis de datos de defectos puede
dar lugar a mejores procesos, métodos, y / o herramientas que reducen la
reanudación y las horas extraordinarias.
Debe asegurarse de que cada miembro del equipo entiende el propósito y los
beneficios de cada elemento de “papeleo”, debe proporcionar información a los
miembros del equipo sobre la base de los datos que proporcionan, y hay que
incorporar en sus horarios suficiente tiempo para completar la necesaria
papeleo. Si el tiempo no está bien gastado, debe eliminar ese aspecto de trámites
o que sea un mecanismo efectivo para el proyecto. Si no se puede justificar y
demostrar a sus miembros del proyecto, el propósito, beneficios, y el valor del
tiempo dedicado a la preparación de los datos solicitados, no se debe pedir a los
miembros de su proyecto para informar de ello. Por ejemplo, explicar a los
miembros del equipo que la información exacta de las horas extraordinarias de
horas de trabajo puede ser de beneficio que le proporciona los datos que necesita
para convencer a sus gerentes y al cliente que el calendario tiene que ampliarse.
www.it-ebooks.info
415
Los gestores y los clientes suelen fijar plazos poco realistas en la creencia de
que los plazos poco realistas animarán a los trabajadores para lograr una mayor
productividad en un esfuerzo por cumplir con los plazos. Se trata de un
maquiavélico, la teoría X enfoque equivocado de cabeza a la gestión de personas
[Mach13], [McGreg85]. Está mal orientada por varias razones:
1. engendra cinismo entre los miembros del proyecto,

2. que se traduce en productos de trabajo de baja calidad,
3. que se traduce en insatisfacción en el trabajo, porque los miembros del
equipo no están autorizados para producir productos de trabajo de calidad, y
4. que se traduce en exceso de horas extraordinarias en el intento de cumplir
con los plazos poco realistas
Resultados exceso de horas extraordinarias en la fatiga y el agotamiento

mental, que desmoraliza a los trabajadores y los resultados de los errores que
aparecen como defectos en los productos de trabajo. exceso de horas
extraordinarias también conduce a la rotación voluntaria del personal, que es tiva
disrupción de progresar, ya que es caro y requiere mucho tiempo para reemplazar
al personal. Usted debe resistir la presión de sus gerentes y clientes para
establecer plazos poco realistas.
Como se indica en la Tabla 10.3, la separación física es otra técnica de
teamicide a ser evitado. Los miembros del equipo deben ser co-localizados
debido a la ingeniería de software es una actividad de trabajo en equipo-intelecto
intensiva. Los miembros del equipo de desarrollo de productos comunes de
trabajo deben estar dentro de la proximidad física entre sí de manera que continua
comunicación ad hoc es posible. E-mail y llamadas de conferencia son útiles pero
no son sustitutos de las discusiones y las reuniones cara a cara. La separación
física de los miembros del equipo es un problema importante para los proyectos
dispersos geográficamente. Estos proyectos son más exitosos cuando las
actividades de trabajo se dividen de una manera que requiere poca comunicación
entre los equipos con particiones. Aprender sobre otras culturas puede ser útil,
como se puede intercambio de personal entre y entre los equipos de proyecto
geográficamente dispersos.
Oportunidades para las interacciones casuales deben ser creados.
Organizaciones han observado descensos en la cohesión del equipo, la
productividad y calidad de los productos de trabajo cuando se interrumpieron
oportunidades para las interacciones casuales, tales como la cafetera comunal o
la pausa para el té de la tarde.
Fragmentación del tiempo entre las múltiples tareas o proyectos de trabajo es
otra técnica teamicide que debe evitarse. La asignación a múltiples proyectos
impide que los miembros del equipo de trabajo conjunto durante largos períodos
de tiempo para aprender una idiosincrasia de los otros, a considerar a los
productos de trabajo como artefactos compartidos, y fomentar la confianza entre
sí.
Un tema relacionado es la interrupción del flujo concentrado de un individuo de
procesos de pensamiento. Flujo (o “estar en la zona”) es un estado mental en el que
una persona se sumerge por completo en lo que él o ella está haciendo; se caracteriza
por falta de esfuerzo de la actividad y una pérdida de sentido del tiempo. El concepto
de flujo fue propuesto por el psicólogo Mihály Csíkszentmihályi en 1975 y ha sido
ampliamente referenciada a través de una variedad de campos. Muchas de las
actividades de trabajo basada en el intelecto de desarrollo de software son mejores
www.it-ebooks.info
acompa- plished por esfuerzo mental concentrado que se produce cuando uno está
“en el flujo” o “en la zona”. En su texto Peopleware, DeMarco y Lister indican que
se necesita
www.it-ebooks.info
aproximadamente 15 minutos para entrar en el estado de flujo; 32 si está

interrumpido por llamadas telefónicas y otras personas cada 15 o 20 minutos no
entrarán en el estado de flujo mental necesaria para la concentración total en la
tarea en cuestión.
DeMarco y Lister observan que las pequeñas oficinas con puertas que se pueden
cerrar, quizás compartidas por dos o tres personas, ofrecen mejores oportunidades
para llevar a cabo el trabajo concentrado que hacer los espacios Carrel ubicuos de
edificios de oficinas modernas. Este autor observó una vez una organización que
tenía una política de “horas de silencio” 01:30-tres y media cada día de trabajo.
Durante este tiempo se desvían las llamadas telefónicas y no se programaron
reuniones. La atmósfera tranquila resultante permitió que las personas entren en el
flujo y realizan el trabajo mental concentrada. Otras técnicas incluyen erigir una
pequeña bandera o una señal que indica “Estoy ocupado ahora” y / o el uso de
auriculares con cancelación de ruido.
Control camarilla sin embargo, es otra técnica teamicide veces utilizado por
los administradores inseguros y desconfiados que temen rebeliones de los
miembros del equipo unidos. En otras ocasiones el control camarilla perjudicial
es la consecuencia no deseada de la rotación de los miembros del personal entre
las asignaciones de trabajo en la creencia de que la rotación de puestos constante
amplía las habilidades de los trabajadores e inyecta nueva forma de pensar en
proyectos. Usted y su organización debe trabajar con cada ingeniero de software
para desarrollar e implementar planes de carrera que proporcionarán la
profundidad y amplitud de las habilidades que son beneficiosas para la
organización y están en línea con los objetivos de la carrera del individuo. Sin
embargo, estos planes de crecimiento deben aplicarse a intervalos que no
interrumpen la continuidad de los actuales miembros asignación de trabajo o
equipo.
reducción de la calidad es una técnica teamicide importante que debe evitarse.
No se le permite a uno de los principales frustraciones de los desarrolladores de
software de tiempo suficiente para producir productos de trabajo que tienen las
características y atributos de calidad de sus credos personales y sentidos de la
demanda de responsabilidad. reducción de la calidad se produce cuando un
programa se comprime sin medidas compensatorias, tales como descoping los
requisitos o el aumento de los recursos. reducción de la calidad también puede
ocurrir debido a la compresión sched- ULE virtual. Esto sucede cuando se añaden
nuevos requisitos y no se toman medidas compen- saciar; como resultado más
trabajo debe hacerse en el tiempo disponible. reducción de la calidad debe ser
evitado si la cohesión del equipo y la moral individuales se van a mantener. Por
otra parte, usted (el director del proyecto o líder gestor / equipo) debe protegerse
de “chapado en oro,
exceso de horas extraordinarias es el último punto en la Tabla 10.3. Las horas
extraordinarias es el tiempo trabajado más allá del compromiso de tiempo
obligado, que suele ser de 8 horas de trabajo por día. Debido a que el desarrollo
de software y la modificación son actividades intensivas-intelecto, no es
razonable esperar que los ingenieros de software pueden ser intelectualmente
productivo de manera continua cuando trabajan más de 8 horas por día, 5 días a
la semana. Cada ingeniero de software y gestor de software sabe que habrá
momentos en los que se requieren explosiones cortas de tiempo extra. Sin
embargo, más del 10% de horas extras a la semana (4 horas) o 10% por mes (dos
días de 8 horas) deben ser considerados como excesivos. ráfagas cortas de exceso
de horas extraordinarias (es decir, 1 a 2 semanas de duración) deben ser
compensadas con tiempo libre para que los individuos puedan recargar física,
mental y emocionalmente.
www.it-ebooks.info
32
[DeMarco99], página 63.
www.it-ebooks.info
10.5 MANTENER moral y la motivación 417
En una simple frase, la única manera de tratar con exceso de horas

extraordinarias es evitarlo. Para resumir el peligro de teamicide, citamos
DeMarco y Lister: “La mayoría de las organizaciones no se dispuso a matar
conscientemente equipos. Ellos solo actúan de esa manera.”33
10.5 MANTENER moral y la motivación
Es su responsabilidad, como director del proyecto y líder, para mantener la moral

de su equipo de proyecto. La moral es evidente cuando un equipo de proyecto
exhibe la confianza, la alegría, la disciplina y la voluntad de llevar a cabo las
tareas asignadas. La moral es la manifestación externa de la motivación.
Mantener la moral es, pues, en gran medida una cuestión de proporcionar el
medio ambiente y las condiciones en las que están motivadas personal del
proyecto para llevar a cabo sus tareas asignadas de buen grado con confianza,
alegría y disciplina.
Para motivar es proporcionar un incentivo para realizar una acción. Las
personas pueden estar motivados por el miedo y la intimidación, que puede tomar
la forma de miedo a la reprimenda, miedo a la humillación, o el miedo a perder el
trabajo. Este enfoque no es probable que produzca el resultado deseado de la
alegría y la voluntad de llevar a cabo las tareas asignadas con confianza con la
disciplina. Un enfoque más positivo es crear las condiciones en las que las
personas pueden satisfacer sus necesidades psicológicas mientras persigue sus
actividades de trabajo. Los individuos de este modo obtener satisfacción de su
trabajo y estar motivados para hacer un trabajo de alta calidad de manera
oportuna.
TABLA 10.4 Elementos psicológicos de satisfacción en el trabajo

Para las necesidades psicológicas sean personas satisfechas necesitan:
• A creer que su trabajo es importante

• Para tener un sentido permanente de los logros
• Para recibir el reconocimiento por sus contribuciones
• Para utilizar una variedad de habilidades
• Para llevar a cabo tareas bien definidas
• Tener oportunidades de crecimiento profesional
• Para tener una cierta autonomía
• Para tener interacciones sociales agradables
Algunas de las formas en que se encuentran satisfacción psicológica en el trabajo se

enumeran en la tabla
10.4. Probablemente es cierto que la mayoría de la gente, a fin de obtener
satisfac- ción psicológica del trabajo, tienen que creer que su trabajo es
importante, tener una sensación continua de rendimiento (por ejemplo, el “cierre”
en términos psicológicos), y para recibir el reconocimiento de sus contribuciones.
Otros elementos que se enumeran en la Tabla 10.4 varían en orden de
importancia para los diferentes individuos.
La opinión predominante es que los que trabajan en marketing, ventas, o las
relaciones humanas obtienen satisfacción en el trabajo de las interacciones
sociales, mientras que los ingenieros de software prefieren autonomía sobre las
interacciones sociales (es decir, que los dejen solos para hacer su trabajo a su
manera). Sin embargo, la gente no se caracterizan o caricaturized tan fácilmente.
Algunos Pollas mar- pueden autonomía premio a tratar con los clientes en su
propio camino a través de las interacciones sociales agradables con compañeros
www.it-ebooks.info
de oficina, y algunos ingenieros de software pueden derivar más
33
Ibídem, Página 139.
www.it-ebooks.info
la satisfacción de la realización de tareas bien definidas que contribuyen a los

resultados de su equipo de tener una gran cantidad de autonomía individual en la
realización de esas tareas.
Con el fin de proporcionar un ambiente de trabajo positivo, hay que entender
que los factores de motivación son importantes para cada individuo y tratar, en la
medida en que sea posible, para crear las condiciones para los individuos. Joe
Tester puede disfrutar de per- formando las tareas bien definidas de depuración
más de la interacción con los usuarios, y Sue analista puede disfrutar de la
interacción con los usuarios más de depuración de código. Si las circunstancias lo
permiten, cada uno debe ser asignado a las tareas que les permitan satisfacer sus
necesidades psicológicas.
TABLA 10.5 Factores que hacen los ingenieros de software feliz en el trabajo
• Un lugar tranquilo para trabajar
• problemas técnicos desafiantes
• La autonomía en la resolución de problemas
• Capacidad de controlar propio horario
• Una oportunidad de aprender cosas nuevas y probar nuevas ideas
• Adecuada las instalaciones de computación y herramientas de software
• líderes técnicos competentes
• La comunicación con sus compañeros a través de correo electrónico, tablones de
anuncios, grupos de noticias, blogs y conferencias técnicas
Tabla 10.5 proporciona una lista anecdótica de satisfactores de trabajo para los
ingenieros de software. Las listas de las Tablas 10.4 y 10.5 no están destinados a
ser definitiva, sino más bien ilustrativa de los factores que se deben tener en
cuenta al crear un ENTORNO ción de trabajo en la que los trabajadores pueden
obtener satisfacción psicológica y por lo tanto presentan una moral positiva.
10.6 NO PUEDE CONTRA NO SERÁ
Como se observa por Andy Grove, fundador y ex CEO de Intel Corporation, los
trabajadores que no se están realizando con las expectativas no pueden o no
[Grove95]. Si un desarrollador de software quiere hacer un buen trabajo, pero no
puede, puede deberse a que él o ella carece de formación, habilidad, experiencia,
herramientas, tiempo o habilidad básica para hacer el trabajo. Cuando una
persona tiene los requisitos previos necesarios para hacer un buen trabajo, pero
no lo hará, es porque carecen de la motivación (o tal vez son perversamente
motivado para hacer fracasar un proyecto). Los que no pueden no pueden y los
que no están dispuestos. Tabla 10.6 lista las cuatro combinaciones posibles y la
situación resultante.
Como se ha indicado, no pueden y no es una situación realista, ya que la
persona que no está calificado para hacer un trabajo no está dispuesto a hacerlo y
no debe ser asignado a ese
TABLA 10.6 Cuatro combinaciones de no puede y no lo hará

incapaces y unwillingA realista situación
No es posible, pero Willinga peligroso situación
capaz pero unwillingLack de motivación
y capaces willingThe mejor situación
www.it-ebooks.info
10.6 NO PUEDE CONTRA NO SERÁ
419
trabajo. Incapaces y dispuestos es una situación peligrosa porque la persona que

lo más probable cometer errores graves en el intento de hacer un trabajo para el
cual él o ella no está calificado. Capaz y dispuesto es la situación en la que una
persona está calificada para realizar una tarea, pero se niega a hacerlo, o lo hará
de mala gana y con falta de entusiasmo. Capaz y dispuesto es la situación más
deseable; la persona tiene la capacidad y está dispuesto a realizar las tareas
asignadas.
Para ser un líder eficaz, hay que entender las personalidades, habilidades y
motivaciones (o falta de ella) de cada individuo y responde según requiera la
situación. Este enfoque se conoce como liderazgo situacional [Hershey99]. Cada
uno de la lata no será frente a situaciones que no figuran en la Tabla 10.6 pueden
ser tratadas con el uso de las técnicas de liderazgo situacional que se indican en la
Tabla 10.7.
TABLA 10.7 Cuatro situaciones y estilos de liderazgo

no puede frente Won'tLeadership Estilo
incapaces y además unwillingTeaching de venta
No es posible, pero además willingTeaching de refuerzo
capaz pero unwillingSelling además de refuerzo
y capaces además willingReinforcing delegación
Para aquellos que son incapaces y sin voluntad, un estilo de enseñanza es

adecuada para que puedan y un estilo de venta es apropiada para motivarlos.
técnicas de enseñanza incluyen asistir a las clases, lectura de documentos, siendo
tutelado, y el trabajo con consultores. técnicas de venta incluyen anécdotas,
testimonios de personas respetadas, oradores invitados, los papeles que se deben
leer y clases. La enseñanza más gastos de ventas serían piado consignados para
las personas que no tienen la formación o la experiencia para participar en las
inspecciones de software, por ejemplo, y son escépticos sobre el valor de las
inspecciones.
Para aquellos que son incapaces pero dispuesto, además de un estilo de
enseñanza de refuerzo es Apropiada; enseñanza para impartir las habilidades y de
refuerzo para canalizar sus esfuerzos en las formas deseadas. técnicas de refuerzo
incluyen una combinación de enseñanza, venta, y otras técnicas, tales como la
asistencia a talleres, siendo entrenado, y el aprendizaje para aumentar la
capacidad de hacer el trabajo. La enseñanza de más de refuerzo sería apropiado
para aquellos individuos que están dispuestos a darle una oportunidad software
de inspecciones, pero carecen de la habilidad necesaria.
Aquellos que son capaces pero sin querer debe estar motivado por la creación
de las condiciones en las que están dispuestos a hacer el trabajo con entusiasmo.
técnicas de motivación incluyen la venta y de refuerzo, además de otras técnicas
tales como la eliminación de los obstáculos que el DE-motivan el individuo. La
venta y el refuerzo sería un enfoque adecuado para aquellas personas que han
tenido malas experiencias participar en las inspecciones de software mal
administradas debido a que los participantes no fueron entrenados para hacer
inspecciones. La barrera de la motivación puede ser eliminado mediante la
capacitación y entrenamiento.
La mejor situación es cuando los individuos son capaces y están dispuestos a
hacer el trabajo asignado. El estilo de liderazgo adecuado es el refuerzo y la
delegación. ción reforzamiento reforzará su capacidad y la delegación reforzará
su motivación. técnicas egation gados incluir el trabajo con las personas a
www.it-ebooks.info
establecer metas, dándoles la autoridad y autonomía para hacer el trabajo de la
manera que mejor piensan, y el establecimiento de procedimientos para informar
sobre el progreso y los problemas. Los individuos que son capaces y están
www.it-ebooks.info
dispuestos para llevar a cabo inspecciones de software, por ejemplo, son

candidatos para convertirse en moderadores de inspección.
10.7 estilos de personalidad
La personalidad está determinada por los comportamientos, rasgos mentales y

emociones que distinguir una persona de otra; personalidad es lo que hace que
una persona una persona. Los individuos se responden mejor cuando el estilo de
liderazgo que muestra es compatible con su personalidad. Si usted está
interactuando con alguien que es metódico y orientado detalle-, él o ella va a
responder positivamente a cuidadosamente estudiada, planes detallados. Por el
contrario, si se trata de una persona creativa “cuadro grande”, él o ella va a querer
comprender el alcance de la obra y el impacto de sus tareas en el resultado
global; estas personas estarán impacientes con explicaciones detalladas.
Muchos modelos diferentes de personalidad se han desarrollado. Algunos de
estos modelos son útiles para dar una idea de nosotros mismos y una visión de la
mejor manera de interactuar con otras personas que tienen rasgos de personalidad
que difieren de las nuestras. Las siguientes secciones resumen brevemente tres
modelos de la personalidad:
• rasgos de personalidad de Jung,

• Myers-Briggs Type indicadores y
• Dimensiones de Wilson de Estilos Sociales.
Se debe enfatizar que estos modelos representan algunos aspectos de la

personalidad y ninguno son representaciones completas o integrales de la
personalidad humana.
10.7.1 Rasgos de la personalidad de Jung

Un rasgo de la personalidad es una forma característica en que una persona
percibe, siente, piensa o actúa. Uno de los modelos más completos de los rasgos
de personalidad fue desarrollado por Carl Jung en la década de 1920 [Jung23]. La
primera vez que distinguía entre introversión y la extroversión, que está
determinada por la forma en que se percibe su entorno, toma decisiones, y
“recarga” ella o su nivel de energía. Los introvertidos prefieren el mundo nal
inter de pensamientos y sentimientos; un buen momento para una persona
introvertida es la lectura de un libro, trabajando en un rompecabezas, o escuchar
música. Los extrovertidos prefieren el mundo exterior de las cosas, personas y
acciones; disfrutan de fiestas y reuniones sociales. El estereotipo de un ingeniero
de software es el nerd introvertido; extroversion es el estereotipo de un vendedor.
Jung define entonces cuatro formas en las que nos ocupamos de nuestro
entorno, independientemente de si somos introvertidos o extrovertidos. Estas
cuatro formas están sintiendo, pensando, intuir, y el sentimiento. Una persona
detección obtiene conocimiento del mundo a través de sus cinco sentidos y
reacciona a la información que se recibe de fuentes externas.
Una persona que es predominantemente un pensador recoge la información y
lo evalúa de una manera lógica antes de actuar (o no actuar) en la información.
Las decisiones se toman sobre una base racional en lugar de reaccionar a los
estímulos al igual que aquel que está pre- dominately una persona de detección.
Pensadores son por lo tanto menos espontáneo que sensers.
Intuir es una percepción del mundo que se produce fuera de los procesos
www.it-ebooks.info
conscientes. La intuición se basa en la integración de grandes cantidades de
información en un subconsciente
www.it-ebooks.info
10.7 estilos de personalidad 421
forma en lugar de simplemente ver, oír y reaccionar como es el caso de la

persona de detección, o por procesos de razonamiento lógico, como es el caso
para la persona de pensamiento.
El sentimiento es la cuarta forma en que Jung observó que las personas a lidiar
con el mundo. Sentimiento implica la evaluación de la información basada en las
respuestas emocionales de uno a esa información.
Jung observó que la mayoría de las personas tienden a ser introvertidos o
extrovertidos, y aunque todos los individuos utilizan los cuatro modos de tratar
con el mundo (sensores, promueva su, intuición, la sensibilidad), la mayoría de la
gente usa predominantemente una forma mayor parte del tiempo, utilizar
secundariamente otra, y débilmente utilizar los otros dos. rasgos predominantes
son com- compensada para, en el caso de los introvertidos que hacen excelentes
presentaciones públicas y extrovertidos cuyos trabajos requieren largos períodos
de esfuerzo individual. Sin embargo, el introvertido es más cómodo (es decir, en
su “zona de confort”) cuando no está haciendo presentaciones públicas y el
extrovertido es más cómodo al interactuar con la gente en lugar de en el
desarrollo de software en un entorno aislado.
Jung hizo hincapié en que no todos tienen un rasgo predominante. Sin
embargo, la mayoría de los investigadores de acuerdo en que la introversión y la
extroversión y los cuatro rasgos de personalidad identificados por Jung son
universales en todas las culturas, aunque la proporción de individuos que exhiben
diferentes rasgos predominantes varía en las diferentes culturas. Wurster pro
porciona una revisión exhaustiva de la obra de Jung y los tipos de personalidad
MBTI asociados [Wurster93].
10.7.2 Tipos de personalidad MBTI

En la década de 1940, Katharine Briggs y su hija Isabel Briggs Myers
desarrollaron el Indicador Myers-Briggs (MBTI) basado en los rasgos de
personalidad de Jung. Es una de las pruebas más utilizadas para evaluar los
estilos de personalidad.
La prueba consiste en responder a unas 100 preguntas. Varios sitios web
proporcionan en línea, versión auto-puntuación del cuestionario MBTI; que se
pueden encontrar mediante el uso de su motor de búsqueda favorito para buscar
enlaces “MBTI”. Los resultados se evaluaron en cuatro escalas:
• extraversión-introversión,
• detección-intuir,
• pensar-sentir, y
• juzgar-percibir.
Con base en los resultados de miles de pruebas de MBTI, se ha determinado

que alrededor del 75% de los examinados en los Estados Unidos puntuación
como extrovertidos (25% introvertidos), y alrededor del 75% de examinados
anotar en el lado de detección del sensor-intuir escala. Aunque los porcentajes de
pensamiento-sentimiento son casi iguales por género, aproximadamente 2/3 de
los hombres puntuación en el lado de la escala pensamiento pensamiento-
sentimiento y aproximadamente 2/3 de la puntuación de las mujeres en el lado
sensible. Por el contrario, se puede decir que un tercio de los hombres puntuación
en el lado sensible y 1/3 de la puntuación de las mujeres en el lado pensamiento
[Boeree06].
www.it-ebooks.info
La cuarta escala (a juzgar-percepción) no es una de las dimensiones de Jung.
Myers y Briggs lo incluyeron para indicar cuál de estilos de Jung predomina y que es
sec- secunda- en los resultados de la prueba. “A juzgar” no implica que uno es
crítico; aquellos
www.it-ebooks.info
que tengan una calificación en el lado de la escala juzgar a juzgar-percibir

tienden a ser ordenada y metódica. Aquellos que tengan una calificación más
hacia el final de la escala de percepción son más flexibles y espontáneos. Si su
puntuación en el lado extrovertido de la escala Sion-introversión extrover- y en el
lado de la escala juzgar-percibir juzgar, su estilo predominante es el pensador o
espesores, dependiendo de qué lado de la sensación de escalar pensando- su
puntuación está encendido y su estilo secundario es el otro. Si la puntuación
como un introvertido con una puntuación más alta de jueces, su estilo
predominante está detectando o intuir, dependiendo de qué lado de la detección-
intuir la escala de su puntaje se encuentra en, y su estilo secundario es el otro.
El uso de las 16 combinaciones de extraversión-introversión, percibiendo-
intuir, think-ing sensación, ya juzgar-percepción, Myers y Briggs identificado 16
estilos de personalidad. La mayoría de las personas que toman la prueba MBTI
caen en algún lugar dentro de las 16 categorías. Sin embargo, algunas personas
colocan en algún lugar entre dos o tres estilos diferentes.
Los 16 estilos de personalidad MBTI se enumeran en la Tabla 10.8, y se
abrevian como
TABLA 10.8 estilos MBTI y opciones de carrera

Estilo predominante y
Personalidad Secundario StylesTypical Carrera elecciones
MBTI
sensación ENFJExtroverted con
intuitingTherapist
s,
maestros,
vendedores
ENFPExtroverted intuir con feelingMarketeers,
anunciantes,
los políticos, los actores
ENTJExtroverted pensando con intuición Los ejecutivos y
ENTPExtroverted intuitiva con pensando
administradores analistas,
empresarios
sensación ESFJExtroverted con detección ocupaciones

de servicios que implican
contacto personal
ESFPExtroverted detectar con artes,
feelingPerformance público
relaciones
pensamiento ESTJExtroverted con sensingPublic de
servicios,
organizaciones de
voluntarios
detección ESTPExtroverted con thinkingPromoters,
empresarios INFJIntroverted intuitiva con feelingTherapists, ministros, general
los médicos
practicantes INFPIntroverted sentir con intuición Psicología, arquitectura,
religión
INTJIntroverted intuitiva con INTPIntroverted
pensamiento pensan
www.it-ebooks.info
do con intuición La ciencia aplicada, ingeniería
La filosofía, las matemáticas, la

ciencia teórica
detección ISFJIntroverted con feelingNurses,
bibliotecarios, maestros
sensación ISFPIntroverted con sensingArts y naturaleza
detección ISTJIntroverted con
thinkingAccountant
s, auditores,
ingenieros
pensamiento ISTPIntroverted con detección Los
soldados, los técnicos
www.it-ebooks.info
• E: extroversión; I: La introversión;
• S: Detección; N: Intuyendo;
• T: Pensamiento; F: Feeling;
• J: A juzgar; y P: Percibiendo.
Si la puntuación como un ENFJ, por ejemplo, indica que su estilo de

personalidad es extrovertida con la sensación de que su estilo predominante y
Intuyendo como su estilo secundaria (debido a la puntuación J). Si la puntuación
como un ENFP, indica que su estilo personalidad es extrovertido con intuición
como su estilo predominante y sentir como su estilo secundaria (debido a la
puntuación P). La distribución de los estilos de personalidad entre la población de
América del Norte es la siguiente [Wideman98]:
• Extrovert: 75%; Introvert: 25%;

• Detección: 75%; Intuitivo: 25%;
• Pensando: 50%; Feeling: 50%;
• Percibiendo: 50%; A juzgar: 50%.
Con el tiempo Myers-Briggs, y otros han emparejado los tipos de personalidad

MBTI con opciones de carrera, la compatibilidad con los tipos de personalidad de
los demás, y muchas características de comportamiento de los individuos
adicionales. estilos de personalidad se han adaptado a las ocupaciones en que
las personas que tienen esos tipos de personalidad tienen carreras exitosas y
satisfactorias. Algunas de estas ocupaciones se indican en la columna derecha de
la Tabla 10.8. La prueba MBTI es ampliamente utilizado en la orientación
profesional, pero su uso no está exento de controversia.
MBTI resultados indican que más del 50% de los ingenieros de software son
introvertidos, en comparación con alrededor del 25% en la población general.
resultados MBTI también indican que los ingenieros de software son pensadores
predominantemente (80% a 90%) [McConnell99]. Los ingenieros de software
son, pues, más en sintonía con la lógica y el razonamiento analítico y menos que
ver con las relaciones humanas que la población general.
Los tipos de personalidad más comunes para los ingenieros de software son
INTJ y ISTJ con una división equitativa entre N (intuición) y S (detección)
[McConnell99]. Un INTJ podría ser su diseñador más creativo, y un ISTJ podría
ser su mejor programador. Cuando es posible, los proyectos podrían beneficiarse
mediante la inclusión de diferentes tipos de personalidad en la mezcla de
personalidades; N personalidades están preocupados con amplia comprensión de
una situación y S personalidades se ocupan de exploración profunda de temas
estrechos. Mezclarlos puede traer más puntos de vista para la resolución de
problemas. Sin embargo, se debe tener cuidado para evitar conflictos entre los
diferentes tipos claramente personalidad; interacciones entre los INTJ y ISTJ,
por ejemplo, pueden conducir a un conflicto.
Otros observadores creen que los ingenieros de software competentes tienden
a caer en las clasificaciones NT y SJ, por ejemplo: “tipos NT tienden a visualizar
la solución completa a un problema, mientras que los tipos SJ tienden a visualizar
los pasos necesarios para las aplicará la solución.” [Hardiman97].
Algunos investigadores creen que su estilo como director del proyecto está más
estrechamente relacionado con su posición en la escala-A juzgar Percibiendo del
perfil MBTI [Hammer01]. Si se encuentra en el lado A juzgar de la escala es
probable que prefiera:
www.it-ebooks.info
• establecer objetivos claros y medibles,

• dividir las tareas en subtareas grandes abajo y proceder con método,
• desarrollar una línea de tiempo con hitos para monitorear el progreso con
cuidado,
• lleguen a un cierre rápido y ser reacios a cambiar las decisiones,
• Quieres trabajar en un ambiente estructurado,
• creen que una receta para el éxito es “planificar el trabajo, entonces el plan de
trabajo,”
• estar motivado por el logro,
• quieren lograr resultados en un proyecto y luego seguir adelante,
• establecer reglas para que tome decisiones cuando, y
• confiar en su capacidad para organizar el proyecto para lograr el objetivo
deseado.
Muchos elementos de esta lista (de [Hammer01]) reflejan técnicas presentadas en

este texto (por ejemplo, la estructura del proyecto, caminos críticos, el valor
ganado), pero esto no debe interpretarse en el sentido de que no se puede tener
éxito como gerente de proyectos si está en el lado de Percepción de la escala
(véase más abajo).
Precauciones para los directores de proyectos que están juzgando
predominantemente incluyen:
• confundiendo el plan con el proyecto,

• perdiendo oportunidades por no adaptarse a la nueva información,
• por error suponiendo que todo el mundo está motivado por plazos como eres,
• molestando a los demás recordando continuamente a los plazos,
• la toma de decisiones sin toda la información que necesita,
• apareciendo rígida a los demás,
• limitando la creatividad o la espontaneidad, lo que podría resultar valiosa, y
• el establecimiento de líneas de tiempo poco realistas que no tienen en cuenta
el comportamiento humano.
Si usted es predominantemente un perceptor, es probable

que:
• darse cuenta de que un plan claro no asegura que todo va a ir bien;

• mantenerse abierto a cambiar el plan a medida que más información esté
disponible;
• averiguar lo que motiva a los demás, además de la consecución de los plazos
(por ejemplo, la autonomía, la oportunidad de aprender nuevas habilidades);
• desarrollar formas de escanear regularmente el medio ambiente para la
nueva información o consultar con alguien que hace esto de forma natural
(por ejemplo, la comercialización o el personal de ventas);
• permiten a las personas a trabajar en sus propios caminos al mismo tiempo
hacerlos responsables para el producto final;
• plan para la espontaneidad, por ejemplo, establecer un período de tiempo
para la lluvia de ideas y luego dejar que el proceso de emerger; y
• al inicio del proceso, obtener retroalimentación sobre la viabilidad de las
líneas de tiempo.
www.it-ebooks.info
La mayoría de los atributos en la lista perceptor también se enfatizan lo largo de
este texto (por ejemplo, la planificación de onda laminados, el desarrollo iterativo,
y la gestión de riesgos en curso). Claramente, todos los atributos de juzgar y
percibir los rasgos de personalidad son valiosos para un jefe de proyecto. La
comprensión de su tipo de personalidad puede ayudar a
www.it-ebooks.info
compensar los rasgos que pueden no ser natural para usted y también le ayudan a
protegerse contra el exceso de celo en los rasgos que son naturales para ti.
10.7.3 Dimensiones de Estilos Sociales

En la década de 1960 Larry Wilson presentó su modelo de estilos sociales. De
acuerdo con el sitio web del Centro de aprendizaje Wilson (ver [Wilson04]), las
dimensiones de estilos sociales son útiles para:
• gerentes de primera línea que han experimentado dificultades interpersonales

en la tran- sición de empleado a gerente;
• directivos de todos los niveles que desean mejorar sus relaciones de trabajo
con los gerentes, compañeros, subordinados y clientes internos o externos;
• los empleados que desean establecer relaciones eficaces del equipo de trabajo;
• gerentes o líderes de equipos que facilitan el trabajo en equipo;
• vendedores o gerentes de ventas que trabajan como un equipo;
• las personas que colaboran con otros para alcanzar soluciones innovadoras; y
• todas las personas en las organizaciones que deseen desarrollar una mejor
comprensión de los demás y para adaptar su comportamiento a tener
interacciones más efectivas.
estilos sociales podrían ser mejor llamarlas “estilos de comunicación;” que se

basa en las dimensiones de la asertividad y capacidad de respuesta en la
comunicación, como se ilustra en la figura 10.1. La asertividad es en una escala
continua de pedir orientado para contar orientado a. Aquellos que están
orientados-ask son oyentes; aquellos que están orientados a contar son
conversadores. La capacidad de respuesta es en una escala de tarea orientada a
las personas orientadas. Los que están tienen poco tiempo para las interacciones
personales orientado a la tarea; la tarea es lo primero, la gente segundos. Los que
están orientado a las personas creen que la tarea se logra mejor cuando se
abordan problemas de las personas en primer lugar.
Tarea orientada
Sensibilidad
Analítico: Conductor:
• busca pruebas • Se centra en los
• Se aplica el razonamiento resultados
lógico • se hace cargo
• No compromete • Toma decisiones
Ask- rápidas Tell-orientado
demasiado pronto
orientado • le gustan los retos Asertividad
• Hechos cuando
Asertividad recompensa es clara
Expresivo:
Amable: • Ideas comparte
• Buscan acuerdo • crea el entusiasmo
• proporciona soporte
• Se comunica la • genera entusiasmo
sinceridad • Motiva e inspira
• genera confianza
Orientado a las
personas de
www.it-ebooks.info
respuesta
FIGURA 10.1 Las dimensiones de estilos sociales [Wilson04]
www.it-ebooks.info
Los cuatro cuadrantes resultantes se etiquetan Conductor, expresivo, amable, y

Analytical Ana-. Como se indica en la Figura 10.1, Drivers exhiben sin sentido
comportamiento. Son y decirle orientado orientado a la tarea; conseguir la tarea
realizada es de mayor prioridad que las relaciones personales y un conductor le
dirá cómo se va a hacer en lugar de pedir su opinión. Los conductores reciben
rápidamente al punto cuando se trata de los demás, y que pueden ser
considerados como brusco. Son orientado a los resultados y con frecuencia son
adictos al trabajo. La dura, pero justa, sargento primero es el controlador
estereotipada, como es el director del proyecto sin sentido.
Expresivos son también decir-dirigidos, pero las relaciones personales vienen
antes de tareas. Son entusiastas, hablador, competitiva y creativa. Expresivos
como para ver every- uno que tenga un buen momento; ellos son el “alma de la
fiesta.” Ellos prefieren iniciar interacciones con una conversación en un nivel
personal antes de abordar la tarea a realizar; sin embargo, ellos están más
interesados en que le dice acerca de su fin de semana que preguntar sobre la suya,
por ejemplo. Willy Lohman (el protagonista en “Muerte de un viajante”) es un
expresivo estereotipada [Miller98], al igual que el jefe de proyecto que se
desarrolla una relación cordial con el cliente (que pueden ser externos a su
organización o en el departamento de marketing de la organización).
Amigables compartir con los expresivos el énfasis en las relaciones
personales. Amigables son más silenciosos que los expresivos y su asertividad
toma la forma de preguntar en lugar de decirle. Un expresivo le informará sobre
su fin de semana, y amable le preguntará sobre la suya. Amigables son fáciles
van y tratan de minimizar los conflictos siempre que sea posible. Ellos creen que
la tarea se vaya más suave si las personas se sienten cómodos unos con otros. El
tendero amablemente que pregunte acerca, y es realmente interesados en su
familia, es un Afable estereotipada como es el jefe de proyecto que es
genuinamente preocupado por el bienestar de sus miembros del proyecto y toma
un interés en su vida personal.
Analyticals, como amigables, están orientados a preguntar, pero como con
controladores de la tarea se presenta ante la gente. Son tranquilos y sin
pretensiones y no buscan las interacciones sociales. Analyticals competencia de
exposiciones y la iniciativa para trabajar a través de problemas de una manera
lógica. La imagen popular de un contador proporciona un estereotipo de un estilo
social analítica. Un jefe de proyecto que se ocupa principalmente de cronograma
y el presupuesto de datos, informes de defectos y seguimiento del valor ganado
sería clasificado como una analítica.
Para hacer que los cuatro estereotipos más realista, Wilson incrustado la
cuadrícula en la figura
10.1 en cada uno de los cuatro cuadrantes de manera que un individuo puede ser
un Afable pero más hacia el estilo Analytical que el expresivo, o un controlador
puede ser principalmente un conductor con un estilo controlador secundario (la
parte superior derecha extrema en la Figura 10.1). Los individuos que comparten
atributos comunes de estilos sociales son más compatibles que los que comparten
algunos atributos. Un fuerte Afable y un fuerte conductor no tienen muchos
rasgos de personalidad comunes, ni tampoco una fuerte analítico y un fuerte
expresivo.
Estereotipos de conflicto de la figura 10.1 incluyen una fuerte interacción del
conductor con un fuerte Afable, como en el caso de la “ceja-golpeado” marido
(Amable) y la mujer frente-golpeo (Driver), o el “slap-em-situ la-back”vendedor
(expresivo) que interactúa con un estadístico sin sentido (analítica). En los
proyectos de software homólogos podrían ser un jefe de proyecto que es
predominantemente un controlador de interactuar con un relajado pero el líder del
www.it-ebooks.info
equipo productivo o desarrollador de software (un Afable) o un miembro del
equipo analítico interactuar con un jefe de proyecto expresivo. En
www.it-ebooks.info
10.8 LOS CINCO-capa del modelo COMPORTAMIENTO 427
Estos casos interacciones van mejor cuando cada individuo entiende el estilo de
comu- nicación de la otra y ajusta su comportamiento para adaptarse a las
características de la personalidad de su contraparte.
10.8 LOS CINCO-capa del modelo COMPORTAMIENTO
En su artículo, “Un estudio en el campo del diseño de procesos de software para

sistemas grandes,” Curtis, Krasner, y Iscoe presenta un modelo de
comportamiento de cinco capas de los procesos de desarrollo de software
[Curtis88]. El modelo se representa en la Figura 1 de su papel y reproduce aquí
como en la Figura 10.2; que ilustra los problemas de comportamiento a nivel de
individuo, equipo, proyecto, empresa y entorno empresarial. El modelo hace
hincapié en los procesos psicológicos, sociales y de organización en cada nivel.
Su objetivo era entender cómo estos procesos afectan la productividad y calidad
del software.
El nivel individual se ocupa de los procesos cognitivos y motivacionales de los
desarrolladores de software individuales. A nivel de equipo, los procesos
cognitivos y motivacionales interactúan con los procesos sociales del equipo;
problemas de comunicación y coordinación surgen dentro y entre los equipos. A
nivel organizativo, proyectos llevados a cabo por la organización están
determinados por, y son afectados por la política, la empresa y la cultura
corporativa. A nivel empresarial, la organización en la que proyec- ECTS se
llevaron a cabo interactúa con otros elementos de la organización matriz, con
organizaciones de clientes, y pueden interactuar con las organizaciones
subcontratistas, proveedores, contratistas y afiliados. Curtis et al. hacen hincapié
en que los problemas en una capa del modelo pueden promulgar en, afectar, y
verse afectados por otros niveles.
El tamaño y la estructura de un proyecto determina el grado de influencia de
cada capa tiene sobre el proceso de desarrollo de software. Las capas superiores
del modelo pueden ejercer poca o ninguna influencia si se está haciendo un
pequeño proyecto para un cliente interno dentro de la organización local. Si usted
está haciendo un gran proyecto para un comprador que representa múltiples
clientes (o múltiples clientes sin un solo punto de contacto) y el proyecto
participan los proveedores y subcontratistas, los niveles más altos del modelo
pueden ejercer una fuerte influencia en la forma de organizar y llevar a cabo su
proyecto.
-Milieu negocio
Empresa
Equipo
del
Proyecto
Individual&Grupo Organizativo
Cognición
Análisis de
contenido Motivación DynamicsBehavior
www.it-ebooks.info
}
}
}
FIGURA 10.2 Cinco capas del modelo de comportamiento de desarrollo de software
[Curtis88]
www.it-ebooks.info
NEGOCIO
MEDIO princi
Adquisitivo
administra pal
Federal dores contratist Sub-
regulador EMPRESA a contratist
es sistemas Mayor a
normas Ingenieria administració Negocio
grupos n perspecti
Calidad PROYEC Otro vas
garantía TO proyect
Cuentas Contiguration Vended
Hardware os
administració ores
Márketing Ingenieria Personal
Fin n
usuar Proyecto DOD
Prueba EQUI
ios PO gerente
Legal s Equip colegas Financi
Otro o Factor ar
equip líder es
os INDIVIDUAL human
os
FIGURA 10.3 Las capas de la comunicación en el modelo de comportamiento
[Curtis88]
Curtis et al. informar sobre los resultados del estudio de 17 proyectos grandes
a través de los 5 niveles tamiento ioral. Se analizan tres problemas:
1. la delgada propagación del conocimiento del dominio de aplicación,

2. fluctuante y conflictivos requisitos, y
3. comunicación y coordinación averías.
Investigaron cómo estos problemas “afectó la productividad y calidad del software

a través de su impacto en los procesos cognitivos, sociales y de organización.” 34
La Figura 6 en el Curtis et al. papel, reproducida aquí como la figura 10.3,
ilustra los niveles de comunicación del ingeniero de software individual a medio
empresarial. En la figura DOD es el Departamento de Defensa. El alejamiento de
la comunicación está determinado por el número de nodos de la información
tiene que pasar a través con el fin de unir dos nodos. A medida que estos autores
observan, cuanta más información tiene que atravesar nodos, menos probable es
que se produzca una comunicación precisa y adecuada.
El modelo de cinco capas ilustra que un desarrollador de software se comunica
con más frecuencia con los miembros del equipo, un poco menos frecuentemente
con otros equipos de proyecto, y mucho menos a menudo con grupos
empresariales, y muy rara vez con grupos externos. Curtis et al. también se
considera dificultades de comunicación causadas por diferencias culturales y por
la separación geográfica (y las diferencias que se acompañan en las zonas de
tiempo).
Algunos de sus hallazgos, en cada una de las tres áreas estudiadas son como
se indican a continuación. propagación delgada de conocimiento del
dominio de la aplicación:
• a nivel individual, los diseñadores excepcionales ejercieron influencia

extraordinaria, ya que fueron capaces de cartografiar el conocimiento
profunda de aplicaciones en una arquitectura computacional;
34
Del resumen de [Curtis88].
www.it-ebooks.info
10.8 LOS CINCO-capa del modelo COMPORTAMIENTO
429
• a nivel de equipo, se gastó un esfuerzo sustancial coordinar una comprensión

común de tanto el dominio de aplicación y cómo el sistema debe realizar
dentro de ella;
• a nivel de proyecto, se pasó el tiempo para asegurarse de que los equipos de
desarrollo comparten un modelo común del sistema;
• a nivel de empresa, el costo de aprendizaje de un área de aplicación era un
gasto significativo corporativa, y el tiempo requerido para un nuevo
miembro del proyecto para ser productivos en un dominio de aplicación
desconocida osciló entre seis meses a un año; y
• dentro del entorno empresarial, la comprensión común del dominio de
aplicación y la arquitectura del sistema para sistemas grandes y complejos
desarrollados por varias compañías se vio obstaculizada por los límites de la
organización entre y dentro de las empresas.
Fluctuante y requisitos en conflicto:
• en el nivel medio de negocios, las fluctuaciones y los conflictos entre los

requisitos por lo general el resultado de los factores del mercado, tales como
las diferentes necesidades entre los clientes, las necesidades cambiantes de
un solo cliente, los cambios en las tecnologías subyacentes o en productos de
la competencia, y los malentendidos del dominio de aplicación;
• a nivel de empresa, los problemas requisitos también surgieron a partir de
fuentes internas como el marketing, la política corporativa, y la gestión de
las líneas de productos;
• a nivel de proyecto, el equipo de diseño a menudo negociado para reducir los
conflictos y los requisitos de límites a los que podrían ser implementadas
dentro de las restricciones del cronograma, presupuesto y tecnología;
• a nivel de equipo, que era difícil hacer cumplir los acuerdos entre los
equipos; y
• a nivel individual, los programadores crean a menudo una fuente oculta de
los requisitos de fluctuación cuando agregaron mejoras que no eran
necesarios.
Comunicación y coordinación:
• a nivel individual, la necesidad de una amplia comunicación no se redujo por

la documentación;
• a nivel de equipo, los equipos pasan un tiempo considerable la definición de
términos, la coordinación de las convenciones de representación, y la
creación de canales para el flujo de información;
• a nivel de proyecto, a menudo artificiales (políticos) barreras a la
comunicación entre los equipos de proyecto creado una necesidad para las
personas que cruzan las fronteras del equipo y para crear redes de
comunicación informales;
• a nivel de empresa, los límites de la organización obstaculizados
comprensión de los requisitos, mientras que los límites temporales
enterrados los fundamentos de diseño; y
• en el nivel medio de negocios, no solo grupo sirvió como la única fuente de
los requisitos; comunicaciones de la organización se convirtió en crucial
para la gestión de proyectos.
www.it-ebooks.info
En resumen, la agregación de los problemas causados por la delgada

propagación del conocimiento del dominio de aplicaciones en puntos niveles de
comportamiento a la importancia del aprendizaje (por ejemplo, cursos de
formación y tutoría) gestionados como un factor importante en la productividad,
calidad y costes. Los procesos de comunicación y coordinación dentro de un
proyecto a menudo se convirtió en crucial para hacer frente a la fluctuación de y
conflicto entre los requisitos. La comunicación efectiva en todos los niveles es
crucial para todos los aspectos de la gestión de un proyecto. Como Curtis et al.
Ponlo:
[E] stos problemas han sobrevivido durante varias décadas a pesar serio esfuerzo a
mejorar la productividad y calidad del software. No estamos afirmando haber
descubierto nuevas perspectivas para la gestión de ingeniería. Por el contrario,
estamos tratando de organizar observaciones sobre los procesos de comportamiento
de diseño de grandes sistemas para ayudar a identificar los factores que deben ser
atacados para mejorar el rendimiento global del proyecto. 35
• La gestión y líder son actividades distintas; un jefe de proyecto competente

es bueno en ambos, o encuentra formas de compensar sus debilidades.
• Un equipo es un grupo de individuos que trabajan de manera conjunta para
lograr objetivos comunes y compartidos.
• Muchas organizaciones no matan intencionadamente equipos, que sólo
actúan de esa manera; antídotos se pueden aplicar para superar comúnmente
ocurre técnicas teamicide.
• Cuando la gente no se están realizando con las expectativas, es porque no
pueden y / o porque no lo harán.
• Su trabajo como líder es crear las condiciones en las que sus seguidores
pueden satisfacer sus necesidades psicológicas en sus entornos de trabajo.
• Usted y su personal puede comunicarse con mayor eficacia cuando cada
persona entiende y compensa los estilos de personalidad de los otros.
• El modelo de comportamiento de cinco capas ilustra problemas de
comunicación y coordinación a nivel individual, de equipo, de proyectos, de
la compañía, y el medio empresarial.
Referencias
[Boeree06] Boeree, Evaluación GC. Las teorías de la personalidad.

http://www.ship.edu/
7Ecgboeree% / jung.html de 2006.
[Brooks87] Brooks, FW Sin balas de plata: Esencia y accidentes de Ingeniería de
software. IEEE Computer (abril de 1987) Vol. 20, No. 4. pp 10-19.
[Brooks95] Brooks, FW El mes laboral mítico. Addison Wesley, 1995. [CMMI06] SEI.
CMMI® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/,
2006.
35
Ibid, p. 1282.
www.it-ebooks.info
Referencias 431
[Curtis88] Curtis, B., H. Krasner, y N. Iscoe. Un estudio de campo del

proceso de diseño de software para sistemas grandes. MCCA. Vol. 31, No.
11, de noviembre de 1988. pp 1259-1267.
[Curtis01] Curtis, B., W. Hefley, y S. Miller. Las personas Capability Maturity
Model líneas directrices para mejorar la fuerza de trabajo. Addison Wesley,
2001.
[DeMarco82] DeMarco, T. El control de proyectos de software. Yourdon Press, 1982.
[DeMarco99] Demarco, T., y T. Lister. Peopleware, proyectos productivos y Equipos,
segundo
ed. Dorset Publishing, 1999.
[Grove95] Grove, AS Alta de gestión de resultados. Vintage Books, 1995.
[Hammer01] Hammer, AL Myers-Briggs Type Indicador Trabajo estilos de informe.
Consulting Psychologists Press.
2001.http://www.cpp.com/images/reports/smp261182. pdf.
[Hardiman97] Tipos de personalidad Hardiman, LT e ingenieros de software. IEEE
Computer
(Octubre, 1997) Vol. 30, No. 10. pp 10.
[Hershey99] Hershey, P., y KH Blanchard. Liderazgo y el ejecutivo al minuto.
William Morrow, 1999.
[Hump97] Humphrey, WS Introducción al Proceso de Software Personal. Addison
Wesley, 1997.
[Hump00] Humphrey, Proceso WS Introductiontothe equipo de software. Addison
Wesley, 2000.
[IEEE12207] IEEE / EIA 12207.0 / 0,1 / 0,2, Implementación de la Industria de la norma
internacional ISO / IEC 12207: 1995 estándar para procesos de Tecnología de
la Información Software del ciclo de vida, Colección de Normas de
Ingeniería; IEEE producto: SE113, el Instituto de Ingenieros Eléctricos y
Electrónicos, Inc. de agosto de 2003.
[Jung23] Jung, CW Tipos psicológicos. Pantheon Books, 1923 (traducción Inglés
H. Godwyn Baynes).
[Katzen93] Katzenbach, J., y D. Smith. La sabiduría de los equipos. Harvard Business
School Press, 1993.
[Mach13] Maquiavelo, N. El príncipe. clásicos Bantam, 1984.[McConnell99]
McConnell, S. Después de la fiebre del oro. Microsoft Press, 1999.
[McGreg85] McGregor, D. El lado humano de la empresa. McGraw-Hill.
1985. [Miller98] Miller, A. Muerte de un vendedor. Pingüino, [1949] 1998.
[Wideman98] Wideman, el trabajo en equipo de proyecto RM, perfiles de personalidad y la
población en general: ¿Tenemos suficiente del tipo adecuado de personas?
Actas de la Gestión de Proyectos 29 Anual Instituto Seminario / Simposio,
Long Beach, CA, Instituto de Gestión de Proyectos de 1998. También está
disponible enhttp: // www. maxwideman.com/papers/profiles/profiles.pdf.
[Wilson04] Wilson, Estilos L. El Manual Sociales: Encuentra su zona de confort y la gente
se sienta cómodo con usted, Wilson Learning Library, 2004. También
dispo- capaces de http://portalcenter.wilsonlearning.com.
[Wurster93] Wurster, indicador de tipos de Myers-Briggs CW: Una evalua- ción cultural y
ético. Universidad de Defensa Nacional, Washington, DC, 1993. También
disponible enhttp://www.ndu.edu/library/ic6/93S86.pdf.
www.it-ebooks.info
CEREMONIAS
10.1. Enumerar y explicar brevemente tres de los atributos de un líder eficaz que
figuran en la Tabla 10.1 que se ha observado en un maestro favorito,
director, u otro líder. Enumerar y explicar brevemente tres atributos en la
tabla 10.1 que ha observado que no estaban presentes en un maestro
ineficaz, director, u otro líder.
10.2. Enumerar y explicar brevemente tres de las técnicas que se enumeran en la
Tabla 10.2 que ha observado o que se puede imaginar que podría ser
realista importante para un equipo de desarrollo de software.
10.3. Lista teamicide tres técnicas adicionales, además de los de la Tabla 10.3,
que ha observado o que se puede imaginar que podría suceder de manera
realista. Explique brevemente algunos antídotos para cada uno de los tres
elementos.
10.4. Enumerar y explicar brevemente las tres técnicas más importantes de la Tabla
10.4 que contribuyen o podrían contribuir a satisfacer sus necesidades
psicológicas en el trabajo. Puede incluir factores que son importantes para
usted que no figuran en la tabla.
10.5. Enumerar y explicar brevemente tres factores en la tabla 10.5 que le hacen,
o le haría, feliz en el trabajo. Puede incluir factores que son importantes
para usted que no figuran en la tabla.
10.6. Enumerar y explicar brevemente una situación de su vida sional personal,
académico o profesión para cada una de las cuales se indican Tabla 10.6.
Para cada uno, explicar brevemente cuál de los estilos de liderazgo de la
Tabla 10.7 era, o sería, más eficaz para ayudar.
10.7. Localizar y utilizar un (libre) de prueba y la puntuación servicio en línea
para una evaluación MBTI. Explicar brevemente por qué los resultados
hacen, o no lo hacen, reflejan su imagen de sí mismo. Pedir a algunos
amigos si creen que los resultados reflejan su personalidad.
10.8. La estilos modelo social representado en la figura 10.1 menudo se puede
observar en los arquetipos de personalidad (caricaturas) interpretados por
personajes de películas, programas de tele- y obras de teatro. Dé un ejemplo
de cada uno de los cuatro estilos (Conductor, expresivos, amable, Analítica)
en personajes de películas, programas de televisión, u obras de teatro con la
que está familiarizado. Explicar brevemente los aspectos de la personalidad
observados en cada uno de sus personajes ejemplo, que los colocan en la
categoría seleccionada.
10.9. El modelo de comportamiento de cinco capas en la figura 10.2 se utilizó
para estudiar tres problemas a menudo se observan en el diseño de sistemas
intensivos en software grandes: la delgada difusión del conocimiento del
dominio de aplicación, fluctuante y requisitos en conflicto, y problemas en
las comunicaciones y la coordinación . Elige un nuevo problema, además
de los tres en el modelo (por ejemplo, cambiar rápidamente gía tec- o
cambios competitivos en el producto de la competencia) que usted ha
observado, o que se puede imaginar que podría suceder de manera realista.
Explica brevemente el impacto de este problema en cada uno de los cinco
niveles (individual, equipo, proyecto, empresa, el entorno de negocios).
www.it-ebooks.info
APÉNDICE 10A
Marcos, estándares y directrices para

equipo y liderazgo
10A.1 LA CMMI-DEV-v1.2 procesos del Marco
Los procesos marco CMMI, incluyendo CMMI-DEV-v1.2 [CMMI06], siguen

teniendo un importante impacto positivo en la disciplina de la ingeniería de software,
pero los modelos no son la panacea. En particular, no abordan tema de la experiencia
en los dominios de aplicación, métodos de desarrollo de software específicos y
tecnologías, o asuntos de personal (por ejemplo, selección, formación, motivación y
retención). Este apéndice tiene que ver con otros modelos y directrices que se han
desarrollado para mejorar la capacidad y la motivación de los individuos y de la
eficacia de los equipos y el trabajo en equipo.
Las normas 12207 para los procesos del ciclo de vida del software abarca cinco
áreas de la vida primaria del proceso del ciclo, ocho soporte a las zonas de
proceso, y cuatro áreas de procesos de la organización [IEEE12207]. procesos de
organización incluyen los procesos de gestión, infraestructura, mejoramiento y
capacitación. El proceso de formación se ocupa de ING fin de • asegurar que los
números correctos y los tipos de personal que tienen las habilidades necesarias
están disponibles cuando sea necesario. El proceso de formación es la única área
de proceso en 12207 que se ocupa de problemas de las personas.
10a.3 IEEE / EIA STANDARD 1058
Norma IEEE 1058 para los planes de gestión de proyectos de software incluye un
Plan Personal ing tren- en el subapartado 5.1.4, lo cual es consistente con los
estándares IEEE estándar EIA / 12207. Esta es la única sección en 1058 que
aborda cuestiones de trabajo en equipo, motivación y ERSHIP plomo
[IEEE1058].
433
www.it-ebooks.info
La Guía de PMI para la Dirección de Proyectos del Conocimiento (PMBOK)

incluye Gestión de Recursos Humanos (capítulo 9) y Gestión de las
Comunicaciones (Capítulo 10) [PMI04]. Los temas tratados en el capítulo 9 del
PMBOK son:
• Planeamiento de Recursos Humanos

• Adquirir el Equipo del Proyecto
• Desarrollar el Equipo del Proyecto
• Gestionar el Equipo del Proyecto
Los temas tratados en el capítulo 10 son:
• Planificación de las comunicaciones

• Distribución de la información
• Informar el rendimiento
• gestionar a los Interesados
En la sección 2.3.2 Además de toda la Organización culturas y estilos discute

aspectos de las culturas organizacionales y factores que dan forma a estos cultivos,
tales como:
• valores compartidos, normas, creencias y expectativas;

• Policias y procedimientos;
• vista de las relaciones de autoridad; y
• trabajar horas éticos y de trabajo.
10A.5 OTRAS FUENTES DE INFORMACIÓN
Cuatro fuentes adicionales de información relativos a los individuos, los equipos

y el liderazgo en proyectos de software son:
• People CMM [www.sei.cmu.edu/cmm-p/]

• Introducción al Proceso de Software Personal [Hump97]
• Introducción al proceso de software del equipo [Hump00]
• Peopleware: Proyectos Productivos y Equipos, 2ª ed. [DeMarco99]
10A.5.1 El People CMM

El Modelo de Madurez de Capacidad Personas (People CMM) está patrocinado
por el Instituto de Ingeniería de Software. De acuerdo con el sitio web, el People
CMM es:
[A] marco que ayuda a las organizaciones a abordar con éxito sus problemas de las
personas críticas. Sobre la base de las mejores prácticas actuales en campos tales
como recursos humanos, gestión del conocimiento y desarrollo de la organización,
el People CMM guía a las organizaciones en la mejora de sus procesos de gestión y
el desarrollo de sus fuerzas de trabajo. los
www.it-ebooks.info
10A.5 OTRAS FUENTES DE INFORMACIÓN 435
People CMM ayuda a las organizaciones caracterizan la madurez de sus ticas ticas
fuerza de trabajo, establecer un programa de desarrollo de la fuerza continua, a
establecer prioridades para las acciones de mejora, integrar el desarrollo de fuerza de
trabajo con la mejora de procesos, y establecer una cultura de excelencia. Desde su
lanzamiento en 1995, miles de copias del People CMM se han distribuido, y se
utiliza en todo el mundo por las organizaciones, grandes y pequeñas.
nivel 5 mejora de la capacidad continua alineación de

(optimizar) rendimiento de la organización innovación
continua plantilla
la integración de
competencias facultado
nivel 4 grupos de trabajo activos
(predecible) basados en la
competencia
la gestión del rendimiento cuantitativo
capacidad de organización de gestión
de la tutoría
análisis de las competencias

del personal de
planificación de
nivel 3 competencia desarrollo de la
(definido carrera de desarrollo
) prácticas basadas en la
competencia de desarrollo
laboral cultura participativa
dotación de personal
comunicación y coordinación
nivel 2 ambiente de trabajo
(Administr gestión del rendimiento
ado) formación y desarrollo
compensación
Figura 10A.1 Los niveles de madurez del People CMM
El People CMM está estructurado como un modelo de 5 niveles, similar en

estructura a las representaciones por etapas de los modelos CMMI. Los
elementos del modelo se CATed indicación en la Figura 10A.1.
El libro Lo que los madurez de la capacidad Modelo de directrices para la
mejora de la fuerza de trabajo describe el People CMM y las prácticas clave que
componen cada uno de sus niveles de madurez. Se muestra cómo aplicar el
modelo en la orientación de las mejoras organizativas e incluye estudios de casos
[Curtis01].
Proceso 10A.5.2 El Personal Software

El Personal Software Process (PSP) tiene que ver con el mantenimiento de
registros y el aprendizaje activo de las propias experiencias personales. Formas
se proporcionan para permitir la grabación de la actuación personal en
proyectos de software. Al analizar periódicamente la información, uno aprende
cómo estimar mejor productividad personal y para evitar errores (es decir, la
creación de defectos).
Las direcciones de PSP, a nivel de los desarrolladores de software individuales,
muchas de las áreas de proceso de CMMI-DEV-v1.2 y prácticas recomendadas,
incluyendo:
www.it-ebooks.info
• el desarrollo de los requisitos

• planificación de proyectos
• Revisiones hechas por colegas
• medición y análisis
• solución técnica
• la integración del producto
• verificación
• validación
• gestión de riesgos
• Análisis de decisiones y resolución
Proceso 10A.5.3 El software del equipo

El Team Software Process (TSP) se basa en PSP. De acuerdo con Humphrey, un
equipo que practica TSP, donde cada miembro utiliza los procesos de PSP,
funcionará en el nivel 5 de CMMI en escena la representación [Hump00]. áreas
de proceso incorporados en TSP además de los incluidos en PSP incluyen:
• gestión de requerimientos
• procesos y aseguramiento de la calidad del producto
• gestión de configuración de software
• la gestión cuantitativa del proyecto
PSP, TSP, y CMMI-DEV-v1.2 de este modo forman una jerarquía:
• PSP se ocupa de los procesos individuales,

• TSP se ocupa de los procesos de equipo, y
• CMMI-DEV-v1.2 se ocupa de los procesos en el proyecto y los niveles de
organización.
10A.5.4 Peopleware
El texto Peopleware [DeMarco99] avanza la premisa de que las causas
fundamentales de la mayoría de los problemas que enfrentan los directores de
proyectos y desarrolladores de software son or- nizational y de gestión, no
técnico. El texto está en seis partes:
Parte I: Gestión de la Parte II de Recursos

Humanos: El ambiente de la oficina
Parte III: Las personas adecuadas
Parte IV: Crecimiento Equipos Productivos
Parte V: Se supone que es divertido trabajar aquí
Parte VI: Hijo de Peopleware
www.it-ebooks.info
10A.5 OTRAS FUENTES DE INFORMACIÓN 437
TABLA 10A.1 técnicas Teamicide y ejemplos

Teamicide TechniquesExamples
Defensivo managementLack de confiar en su equipo miembros
procedimientos y BureaucracyMindless papeleo excesivo
Físico separationNo espacio de trabajo de grupo; no hay posibilidades para las
interacciones casuales
La fragmentación del trabajo timeAssigning personas a múltiples proyectos y
equipos
Falso plazos deadlinesUnrealistic todo el mundo sabe que no se pueden cumplir
Calidad reductionCompressing horarios sin descoping los requisitos
Camarilla permitiendo que los miembros del equipo a controlNot permanecer
juntos durante periodos de tiempo
prolongados
Excesivo overtimeNo tiempo para ayudarnos unos a otros; la fatiga y el desgaste
aspectos degradantes de los La sustitución de las frases sin sentido en lugar
carteles de motivación y placas de ofrecer oportunidades concretas para la
motivación individual
Un aspecto inesperado de overtimeDiffering habilidades de los miembros del equipo y
voluntad de trabajar horas extras
La sexta parte de la segunda edición incluye 8 capítulos adicionales más allá

de los de la primera edición del texto. Por ejemplo, entre los temas abordados en
estos additionalchaptersareofteamicideand “teamiciderevisited.” Teamicideis
describe como una forma de “inhibir la formación de equipos e interrumpir
sociología proyecto.” Tabla 10A.1 listas teamicide técnicas y ejemplos. Tabla
10.3 en este capítulo se describen algunos antídotos para teamicide.
Al final del capítulo 20, DeMarco y Lister concluir: “La mayoría de las
organizaciones no establecen para matar conscientemente equipos. Ellos solo
actúan de esa manera “.
www.it-ebooks.info
11
CUESTIONES DE ORGANIZACIÓN
Los logros de una organización son los resultados del esfuerzo combinado de cada
individuo.
Vince Lombardi
11.1 INTRODUCCIÓN A cuestiones de organización
Dado que el software se construye y se mantiene por los seres humanos, y porque
las organizaciones están compuestas por seres humanos, proyectos de software y
las organizaciones que llevan a cabo proyectos de software son complejas redes
sociales. La organización término se utiliza para denotar “una estructura
administrativa en la que las personas a administrar colectivamente uno o más
proyectos en su conjunto, y cuyos proyectos comparten un alto directivo y operar
bajo las mismas políticas.” [CMMI06].
A nivel organizativo:
• la cultura de la empresa debe ser establecido y mantenido;

• objetivos estratégicos deben ser determinados y perseguidos;
• activos intelectuales deben ser nutridos;
• Se deben establecer procesos de desarrollo de software; y
• infraestructura, medios técnicos, herramientas y técnicas deben ser
proporcionados.
Estas preocupaciones de organización se tratan en este capítulo.

Como jefe de proyecto dentro de una unidad organizativa, debe establecer
canales de comuni- cación entre las entidades de organización, por ejemplo, entre
el grupo de desarrollo de software y el grupo de prueba independiente, y entre

439
www.it-ebooks.info
440 CUESTIONES DE ORGANIZACIÓN
requisitos
Proceso
Cliente Planificació Asigna
ny Definición Independient
de las ciones e
Los replanifica de
Actividad V&V
gestores ción trabajo
es Seguro de entregad
directivas y o
la estimación y producto
Re-estimar Gestión de la s de
Controlador
Retenció
n de ..........
datos . . ... . .

problemas
FIGURA 11.1 Un modelo de flujo de trabajo para la gestión de proyectos de
software
su proyecto y el grupo de gestión de configuración independiente (si lo hay).

canales de comunicación informales que son beneficiosas para el proyecto deben
Anime a los canales de comunicación de edad e informales perjudiciales para el
proyecto debe ser desalentado.
Es posible que, por un lado, quiere fomentar la comunicación informal entre
los desarrolladores de software e ingenieros de sistemas con el fin de aclarar y
refinar los requisitos de software. Por otro lado, es posible que desee para
desalentar comu- nicación informal entre los implementadores de software
individuales y los usuarios finales debido a que estas comunicaciones pueden
dar lugar a requisitos no autorizado a la fluencia y pueden crear falsas
expectativas entre los usuarios. La comunicación entre los usuarios y los
desarrolladores se debe limitar a las sesiones de la obtención de requisitos que
implican los usuarios representativos y los ingenieros de software que son
expertos en la obtención de requisitos, y para reuniones de intercambio técnico
entre los desarrolladores de software, sus jefes de equipo o jefe de proyecto y
usuarios. La intención no es para desalentar interacciones, sino más bien para
asegurar que las interacciones se producen de una manera ordenada.
Para facilitar la comunicación interna a su proyecto, un modelo de flujo de
trabajo similar a la figura 1.1, que se repite aquí como la figura 11.1, y una
estructura de proyecto similar a la figura 1.3, que se repite aquí como la figura
11.2, se deben establecer para su proyecto de software. La intención de una
estructura jerárquica, como en la figura 11.2, no es para desalentar la
comunicación informal entre los desarrolladores en diferentes equipos, pero para
asignar las exigencias y descomponer la arquitectura de software para que cada
equipo pueda realizar sus actividades de trabajo con alta cohesión interna entre
los miembros del equipo y acoplamientos sueltos a otros equipos (véase el
capítulo 4).
www.it-ebooks.info
www.it-ebooks.info
11.3 La influencia de la cultura corporativa 441
Cliente
Gerente de
proyecto
Arquitecto de
software
Equipo Líder Líder V&V CM XX

Líder # 1 del del
equipo # Equipo #
... 2 ... 3
Miembro Miembro
Miembro Miembro
Cada equipo tiene de 2 a 5

miembros más un jefe de
equipo
V & V: Verificación y validación
CM: Configuration Management
XX: otros procesos de apoyo
FIGURA 11.2 Un modelo de organización para proyectos de software
• los elementos de culturas corporativas,

• la importancia de la misión y visión,
• evaluar y nutrir el capital intelectual,
• funciones del personal clave,
• responsabilidad frente a la autoridad, y
• 15 directrices para organizar y dirigir equipos de ingeniería de software
Los marcos, normas y directrices que se presentan en cada uno de los capí- tulos
anteriores, a saber, CMMI-DEV-v1.2, ISO / IEC e IEEE estándar EIA / 12207,
IEEE / EIA estándar de 1058, y el Cuerpo de PMI dirección de conocimiento de
la organización problemas en diversos grados. Los elementos pertinentes de estas
normas y directrices se resumen en el Apéndice 11A de este capítulo.
11.3 La influencia de la cultura corporativa
La cultura corporativa se compone de los patrones de creencias, valores y

conductas que existen dentro de una organización. Las normas culturales fluyen
de arriba hacia abajo. Las personas
www.it-ebooks.info
TABLA 11.1 Elementos de cultura organizacional

• Código de vestimenta
• Grado de formalidad
• Horas laborales
• Cooperación contra la competencia
• estructura de recompensas
• La resolución de conflictos
• las normas disciplinarias
• Desarrollo de la carrera
• Las actitudes acerca de la calidad
• Relaciones con los clientes
• Comportamiento ético
• Una declaración de visión
• Una declaración de misión
mirar a sus colegas de alto nivel y supervisores para los indicadores de

comportamientos aceptables e inaceptables y para aprender los caminos de “salir
adelante” en la organización. Los supervisores miran a sus directivos, que a su
vez se parecen a sus gerentes para recibir orientación. Desde la perspectiva del
individuo, la cultura corporativa proporciona la respuesta a la pregunta “¿Qué se
siente al trabajo en esta organización?” Algunos de los factores que determinan
los patrones culturales se enumeran en la Tabla 11.1.
Diferentes organizaciones tienen diferentes códigos de vestimenta, que van
desde el traje formal en todo momento (por ejemplo, corbatas, chaquetas,
vestidos), a lo formal cuando se reunió con los clientes y no estructurado de otra
manera, a “business casual” a viernes “vestido hacia abajo”, a los pantalones
vaqueros -y-- tee-camisas en todo momento. De una manera similar el grado de
formalidad varía de nombres en toda la organización a formas más respetuosas de
dirección para Sors supervisiones y gestores.
Algunas organizaciones son bastante flexibles en horas de trabajo, y otros han
aplicado estrictamente las veces estar en el trabajo. En el caso de un horario
flexible, algunas organizaciones requieren que todos estén presentes 10 a.m.-3:00
pm así que las reuniones se pueden programar en momentos en que las personas
están disponibles para asistir. Aplican estrictamente las horas de trabajo pueden
estar basadas en los deseos de gestión de nivel superior o tal vez obligados por
consideraciones de seguridad que dictan la instalación debe ser bloqueado desde
las 6:00 pm hasta las 7:00 am de lunes a viernes y los fines de semana.
Algunas organizaciones fomentan la competencia entre los contribuyentes
individuales en la creencia de que el estrés de la competencia mejora la
productividad y calidad del trabajo. Otras organizaciones que animan a la
cooperación y el trabajo en equipo en la creencia de que la sinergia que resulta de
trabajo en equipo cooperativo mejora la productividad y calidad del trabajo. La
estructura de recompensas en algunas organizaciones reconoce y premia los
logros individuales, mientras que otras organizaciones que animan a los esfuerzos
del equipo y recompensa. Los enfoques para la resolución de conflictos y las
medidas disciplinarias varían de dejar hacer a la intervención y mejora. Las
acciones disciplinarias varían de manos libres con procedimientos bien definidos
que incluyen la documentación de comportamientos inaceptables,
sesiones de asesoramiento, períodos de prueba, y las políticas de despido.
Algunas organizaciones han definido bien las escalas profesionales, planes de
carrera de desarrollo para cada empleado, calificaciones y procedimientos para el
avance de una escala de la carrera, y un departamento de relaciones humanas que
trabaja con los empleados para avanzar en la carrera de cada empleado. la
www.it-ebooks.info
promoción profesional en otras organizaciones es sobre una base ad hoc.
www.it-ebooks.info
11.4 EVALUACIÓN Y NUTRIR capital intelectual 443
relaciones con los clientes, las actitudes acerca de la calidad, las declaraciones
de visión, las declaraciones de misión, y el comportamiento ético son elementos
interrelacionados de la cultura de la organización. En contraste con la sabiduría
convencional, el cliente no siempre tiene la razón y no todos los clientes son los
clientes adecuados para una organización. Algunas organizaciones promulgan a
través de las actitudes positivas hacia la organización a los clientes, la calidad y
la ética, mientras que otros no dicen nada sobre estos temas. Respecto a los
clientes, las actitudes hacia la calidad y el comportamiento ético a menudo se
instila por la declaración de la misión y la declaración de la visión de una
organización. Las declaraciones de misión y visión sirven a propósitos distintos y
deben estar claramente diferenciados.
Una declaración de misión define el propósito y los objetivos de una
organización. Por ejemplo,
Proporcionamos sistemas de información de alta calidad a los clientes que valoran la

calidad
es una declaración de la misión.

Los valores organizacionales y el comportamiento ético deben estar alineados
con la declaración de la misión. Si el suministro de sistemas de información de
alta calidad es la misión, preocupaciones conde calidad deben ser reforzados y
apoyados en toda la organización y las consideraciones éticas deben impedir la
entrega de software con deficiencias conocidas. La frase “a los clientes que
valoran la calidad” indica que la organización valora de estos clientes y debe ser
selectiva en los clientes de los que se ocupa, si la declaración de la misión se va a
cumplir; es decir, los clientes que exigen horarios cortos que los productos de
calidad sacrificio no debe llevarse a cabo.
Por el contrario, una declaración de visión tiene objetivos específicos y un
calendario para achiev- ing ellos. Un ejemplo de una declaración de visión es
Vamos a ser uno de los tres principales proveedores de sistemas de información para
cuidados intensivos de pacientes en los Estados Unidos para el año 2010.
Una declaración de misión y una declaración de la visión, en conjunto,

proporcionan la base para la planificación y las normas de comportamiento de la
organización estratégica.
Algunas organizaciones viven de su misión y visión; otros no los tienen o
tienen ellos, pero no prestan atención a ellos.
11.4 EVALUACIÓN Y NUTRIR capital intelectual
Los activos principales de una organización de software son las habilidades y

capacidades de los gestores de proyectos, los desarrolladores de software, y otro
personal de software. Los activos humanos se denominan capital intelectual
[Stewart97]. Porque las personas son activos de la empresa, deben ser manejados
para maximizar el retorno de la inversión y no a minimizar costos. Las
organizaciones que consideran a los trabajadores como los costos para ser
minimizadas incluyen restaurantes de comida rápida y muchas organizaciones de
ventas al por menor. En estos casos, los trabajadores son considerados como
unidades intercambiables y reemplazables; se les paga la cantidad mínima
posible y, a menudo son reemplazadas cuando son elegibles para aumentos de
www.it-ebooks.info
salarios y beneficios.
Las organizaciones que consideran a las personas como activos determinar
sistemáticamente los niveles de habilidad necesarios, contratar a los mejores
candidatos disponibles, garantizar que los trabajadores tienen
www.it-ebooks.info
los procesos, procedimientos, métodos y herramientas que necesitan, e invierten

en actividades de formación y desarrollo profesional de los trabajadores. Una
prueba de fuego del compromiso de la organización para su capital intelectual es
observar lo que sucede cuando los tiempos son difíciles. Por desgracia, muchas
organizaciones dejan de invertir en la formación y las herramientas y reducir o
cancelar los fondos de viaje para los trabajadores para asistir a conferencias y
seminarios de desarrollo profesional. Estas prácticas indican que los directivos de
la organización consideran que su gente de software como los costos que deben
controlarse en lugar de activos a ser alimentado.
Tabla 11.2 se enumeran algunas de las medidas (directos e indirectos) que las
organizaciones pueden utilizar para evaluar su capital intelectual [Stewart97].
Al igual que todos los elementos de una organización bien administrada, el
capital intelectual debe evaluarse, debilidades determinadas, y medidas adoptadas
para mejorar el capital intelectual de la organización.
11.5 El personal clave FUNCIONES
Su personal clave son aquellos miembros del proyecto que se asignan

responsabilidades y se les da la autoridad para llevar a cabo estas tareas por
usted, el director del proyecto. Si usted es el director del proyecto, el líder del
equipo, y la arquitectura de software en un proyecto de 5 o 6 miembros, cada
miembro del proyecto es una persona clave en su proyecto. Si usted es jefe de
proyecto de un proyecto que consiste en múltiples equipos pequeños (es decir, 5
o 6 miembros por equipo) su personal clave incluyen los jefes de equipo y la
arquitectura de software (que puede ser usted). Es la responsabilidad de los jefes
de equipo para coordinar nate las actividades laborales de los miembros de su
equipo, que son a su vez a su personal clave. Los jefes de equipo deben tener la
autoridad para hacer las asignaciones de trabajo dentro de sus equipos, y aceptar
la responsabilidad de producir productos de trabajo de alta calidad en la fecha
prevista.
Ellos, los jefes de equipo, son responsables de la cantidad, calidad y
oportunidad de los productos de trabajo producidos por sus equipos. Tabla 11.3
se enumeran algunas funciones del personal clave de los proyectos de software.
Tenga en cuenta que el proceso y la garantía de calidad del producto, verificación
y validación no se enumeran en la Tabla 11.3. El personal de garantía de calidad
no son miembros del proyecto, ni son miembros de grupos independientes de
verificación y validación, ya que, el director del proyecto, no tienen (no debería
tener) autoridad para dirigir sus actividades de trabajo. El administrador de
configuración para su proyecto debe ser un miembro de su equipo, ya sea o no
que la persona o personas que se reporta directamente a usted o a otro
administrador; ya sea disposición es aceptable siempre que los objetivos y
procedimientos de gestión de la configuración están satisfechos. El papel
probador de software no es una función de verificación o validación; es la
función que lleva a cabo pruebas independientes dentro de su proyecto; este
papel podría ser compartida entre los miembros del equipo que ponen a prueba
un código de otra persona.
Una de sus primeras tareas como director del proyecto es determinar el alcance
de sus responsabilidades y autoridad. Es posible, por ejemplo, tienen un alto
grado de autonomía en la contratación y el despido de su personal de proyectos, o
puede ser obligado a utilizar el personal asignado a su proyecto. Es posible
trabajar directamente con un cliente externo y negociar cronograma, presupuesto
y entregables con el cliente organización de la consulta, o su cliente puede ser un
www.it-ebooks.info
grupo de ingeniería del sistema o un departamento de marketing dentro de la cual
se encuentra en una posición subordinada.
www.it-ebooks.info
11.5 Personal clave FUNCIONES 445
TABLA 11.2 Las medidas directas e indirectas de capital intelectual

Medidas de Intelectual
CapitalExamples
• Las • Nuevos productos o servicios efectuados en los últimos 12
medidas de meses
la • Número de patentes y derechos de autor presentadas y
innovación obtenidos en los últimos 12 meses

• Porcentaje de las ventas atribuibles a nuevos productos o
servicios
• Medidas de las • En una escala de (infeliz, bien, muy feliz), lo feliz que está
actitudes de los con su trabajo?

empleados • En comparación con hace un año, ¿estás más feliz, sobre el
mismo, o menos feliz en el trabajo?

• ¿Usted entiende cómo su trabajo es de beneficio para los
clientes (no en todos, un poco, algo, etc.)

• Personal esencial: porcentaje de empleados cuya experiencia
• Medidas de es esencial para el negocio de la empresa

experiencia, la • número promedio de años de experiencia entre el
facturación y la personal esencial

tenencia • Novato relación: porcentaje de personal esencial con menos
de dos años de experiencia

• Rotación entre el personal esencial
• número promedio de años de experiencia de todos los
empleados
• Causas para dejar a aceptar puestos de trabajo en otros lugares
• Grados, por nivel, de personal esencial
• • Grados siendo buscados por personal esencial con el

Medidas de
educación y patrocinio empresarial
• cursos no requieren título siendo tomadas por el personal
formación
esencial con el patrocinio empresarial
• Promedio de horas de formación al año por personal esencial
• Otro medidas • Los ingresos generados por empleado
• Los ingresos generados por empleado esencial
• Porcentaje de clientes que nos desafían
• ¿Qué habilidades son las más importantes en la satisfacción de
las necesidades del cliente?
• ¿Qué habilidades son los más admirados por otros empleados?
• ¿Cuáles son las tareas más deseados por los gerentes y
trabajadores de alto potencial? ¿Dónde lo menos quieren

trabajar? Lo que explica las diferencias?
• ¿Qué explica las diferencias entre lo que los clientes
valoran y qué valor empleados?

• ¿Qué tecnologías o habilidades emergentes podrían
socavar el valor del conocimiento y las habilidades

especiales de su organización?
• ¿Qué porcentaje de tiempo que el personal esencial se
gasta en actividades de bajo valor a su base de

clientes?
• ¿Qué porcentaje de tiempo de todos los empleados se gasta en
actividades de bajo valor a su base de clientes?

• ¿Cuál es la reputación de su empresa entre expertos en su
campo?
www.it-ebooks.info
TABLA 11.3 Algunas funciones del personal clave de los proyectos de

software
• Gerente de proyecto
• ingeniero de requisitos
• Arquitecto de software
• Capitan del equipo
• implementador de software
• Probador de software
• gestor de configuración
AUTORIDAD Y RESPONSABILIDAD
La responsabilidad es la obligación de llevar a cabo las tareas asignadas y los

deberes de su puesto de trabajo. En una sociedad bien organizada, cada
función organizativa tiene una descripción del trabajo que detalla las
funciones principales de ese papel. Las funciones principales de un jefe de
proyecto, por ejemplo, son los siguientes:
• preparar y actualizar las estimaciones y planes;

• medir y controlar el proceso de trabajo y los productos de trabajo;
• comunicar, coordinar y conducir; y
• gestionar el riesgo.
Las funciones principales de un arquitecto de software (es decir, el diseñador

jefe) se detallan en la Tabla 11.4.
TABLA 11.4 Responsabilidades de la función de la arquitectura de software

• Interactúa con el personal de los requisitos de ingeniería
• Desarrolla opciones de diseño y presenta las ventajas y desventajas entre ellos a los
tomadores de decisiones
• Lidera el equipo de diseño
• Dirige y coordina los líderes del equipo de implementación
• Mantiene la visión del producto
• Coordina las actividades técnicas con otros equipos de diseño, otras disciplinas y
otras organizaciones
Las responsabilidades de los jefes de equipo se detallan en la Tabla 11.5.

listas similares de deberes deben ser incluidos en las descripciones de trabajo
para todas las funciones que deben desempeñar en sus proyectos. En una
organización bien administrada, existirán descripciones de trabajo para cada
uno de los roles que deben desempeñar. En una organización caótica que
podría tener que desarrollar las descripciones de trabajo usted mismo.
La autoridad es el poder de tomar las decisiones que se deben hacer en el
cumplimiento de las responsabilidades de uno, y el poder para aplicar estas
decisiones, o para ver su aplicación. Un CCB, por ejemplo, debe tener la
autoridad para establecer líneas de base del producto del trabajo y para
aceptar, rechazar o diferir las solicitudes de cambio y defectos
www.it-ebooks.info
11.5 El personal clave FUNCIONES 447
informes. Cada descripción del trabajo debe incluir la autoridad conferida en

el trabajo, así como las responsabilidades asignadas. Un desarrollador de
software correspondiente, por ejemplo, tiene (o debería tener) la autoridad,
dentro de las limitaciones (o de organización) guía de estilo del proyecto, para
implementar el código en la forma en que él o ella piensa que va a satisfacer
mejor las necesidades, pero él o ella no tiene la autoridad para cambiar la línea
de base los requisitos para el producto.
TABLA 11.5 Responsabilidades del papel de líder del equipo

• Supervisa los procesos personales y de equipo
• Asegura la calidad del producto personal y de equipo
• Mentores y entrenadores de los miembros del equipo
• Mantiene la moral del equipo, la energía y la unidad
• Mantiene la gestión sobre los avances y problemas
• Coordina las actividades de trabajo con otros equipos y grupos
• Resuelve los problemas y las cuestiones dentro de su control
• Eleva los problemas y las cuestiones más allá de su control
La autoridad se puede delegar la responsabilidad, pero no puede. Puede, por

ejemplo, delegar la autoridad a su arquitecto jefe para negociar los requisitos
con el cliente. Sin embargo, usted sigue siendo responsable, como jefe de
proyecto, para la entrega de un producto aceptable dentro de las limitaciones
de horario y presupuesto. Si el arquitecto no puede negociar con éxito los
requisitos y no logra su proyecto, usted será responsable del fracaso. Y, por
supuesto, tienes derecho a compartir el crédito por los resultados exitosos.
Una queja común entre las personas que trabajan en las organizaciones es que
ellos no tienen la autoridad para llevar a cabo sus responsabilidades. A veces esto
es el resultado de la ineptitud de un gerente que delega autoridad insuficiente, a
veces se basa en el deseo de un administrador de ejercer el control sobre todos los
aspectos de la obra para la cual él o ella es responsable (tal vez debido a la
inseguridad del gerente o tal vez porque él o ella no confía en los miembros del
equipo para llevar a cabo sus responsabilidades asignadas), y, a veces los que se
quejan de la falta de autoridad piensan erróneamente sus responsabilidades son
más grandes de lo que son en realidad.
asignaciones de personal se hacen primero identificando las funciones que

deben desempeñar. Las funciones que deben desempeñar incluyen el director del
proyecto, arquitecto de software, software de Menter imple-, administrador de
configuración, y otros, que se enumeran en la Tabla 11.6. Una persona puede
desempeñar múltiples funciones como, por ejemplo, una persona (usted) que
juega el director del proyecto, arquitecto de software y las funciones de jefe de
equipo en un proyecto pequeño. Una de las funciones puede requerir varias
personas como, por ejemplo, el papel o rol ejecutor probador. Una indicación
vidual puede desempeñar diferentes funciones en diferentes momentos, por
ejemplo, como diseñador de software y más tarde como probador de software.
Algunas funciones, como el administrador de configuración, pueden ser una
función de tiempo parcial para uno de los ejecutores de software en un proyecto
pequeño, un papel a tiempo completo en un proyecto más amplio, o una función
realizada por una entidad orgánica separada. Algunos papeles, la calidad
www.it-ebooks.info
TABLA 11.6 Algunos papeles de proyectos de

software
• Gerente de proyecto
• ingeniero de requisitos
• Arquitecto de software
• Capitan del equipo
• implementador
• Ensayador
• gestor de configuración
• Proceso y calidad del producto assurer
• verificador independiente
• validador independiente
• Escritor técnico
• Entrenador
• instalador
• mantenimiento del sistema
aseguramiento y verificación y validación independiente, por ejemplo, debe ser

jugado por personas de entidades orgánicas se separan del proyecto.
Una vez identificadas las funciones que deben desempeñar y el número de
personas necesarias para llenar esos papeles, el siguiente paso es establecer la
calificación de las personas que van a jugar los papeles, cuando serán necesarios
esos individuos, y por cuánto tiempo. Puede ser, por ejemplo, que sus ejecutores
de software deben ser competentes en el uso del lenguaje de programación Java o
que su administrador de configuración deben ser competentes en el uso de una
herramienta específica de control de versiones.
Si, durante la planificación inicial, los nombres de los que van a jugar se conocen
los papeles, que se pueden introducir en la matriz de asignación de personal, como en
la Tabla 11.7. Si no se conocen sus nombres, un plan de adquisición de personal debe
ser desarrollado. El plan debe indicar las funciones que deben desempeñar, el número
de personal necesario para llenar los papeles, las calificaciones de trabajo para los
roles y las fechas en que los papeles deben ser llenados.
TABLA 11.7 Asignación de los individuos a los roles

Persona papel PM RE SA E CM CCB
S
Joe S. PAG PAG
O METRO
Sue W. PAG PAG
Bill P. segundo segundo PAG
Mai L. PAG segundo METRO
PM: Gerente de Proyecto; RE: Requisitos del ingeniero; SA: Arquitecto de Software; TI: probador
independiente; CM: Administrador de configuración; CCB: Cambiar la tarjeta de control; P: primaria;
B: Copia de seguridad; M: miembros.
El departamento de recursos humanos o alguna otra entidad de organización

pueden ser de ayuda para llenar los papeles, o puede estar en su propia para dotar
de personal a su proyecto, en función de la infraestructura de su organización y,
posiblemente, en las condiciones establecidas en el contrato entre la organización
del cliente y su organización. El plan de adquisición de personal debe ser
revisada cuando se desarrolla el plan de gestión de riesgos para determinar
posibles problemas en la adquisición del personal necesario.
www.it-ebooks.info
11.6 QUINCE directrices para organizar 449
En la Tabla 11.7 nota que cada función, a excepción de arquitecto de software

y gestor de configuración, tiene una persona primaria y una persona de refuerzo.
Cada función debe tener una persona de reemplazo para llenar cuando la persona
principal no está disponible (por cualquier motivo). Tenga en cuenta que Bill P.
es copia de seguridad para ambas funciones ingeniero gerente y los requisitos del
proyecto; tal vez él está sirviendo como aprendiz en estos papeles en preparación
para convertirse en un director de proyecto y / o ingeniero de requisitos. Joe S. es
primaria, tanto para los requisitos de la ingeniería y de pruebas independiente que
son funciones compatibles; Joe puede desarrollar pruebas basadas en los
requisitos durante el análisis de requisitos y aplicarlos como los ejecutores de
desarrollar el código. Mai tiene ninguna copia de seguridad para la función de la
arquitectura y Bill no tiene copia de seguridad para la gestión de la
configuración. se deben hacer estas asignaciones. La cabeza del CCB es Sue, el
director del proyecto. CCB miembros son Joe, el ingeniero de requisitos y Mai, la
Si el proyecto se muestra en la Tabla 11.7 es una pequeña todos los miembros
del proyecto, excepto Joe, puede ser ejecutores de software, además de sus otras
funciones. Si el proyecto es un grande con múltiples equipos de desarrollo, cada
jefe de equipo y su copia de seguridad debe ser incluido en la tabla.
11.6 QUINCE directrices para organizar y dirigir equipos de software

INGENIERÍA
Esta sección final del texto es una versión actualizada de un documento

previamente publicado por el autor [Fairley93]. En él se resumen muchos temas
que se tratan en el texto y presenta algunos nuevos.
11.6.1 Introducción a las Directrices

Software, a diferencia de otros artefactos de ingeniería, es exclusivamente un
producto de la inteligencia humana; nuestras materias primas son la materia gris
en el interior del cráneo humano. A medida que el tamaño y la complejidad del
software crece y como la demanda de software de mayor calidad y menor
aumento de los ciclos de desarrollo, la capacidad de los ingenieros de software
individuales para trabajar como miembros de los equipos, y la capacidad de los
jefes de equipo para dirigir los esfuerzos de los miembros del equipo se
convierten más crítico para el éxito. Esta sección presenta 15 líneas directrices
para organizar y dirigir equipos de ingeniería de software.
Hay varias razones por las que los equipos son más eficaces que un conjunto
de individuos que trabajan solos. Programación y conjuntos de habilidades son
razones principales. Los clientes no van a esperar 5 años para una persona para
desarrollar o modificar un producto de software que requiere de 60 meses-
personal de esfuerzo. En el otro extremo, no es razonable asignar 60 personas
durante 1 mes. Podríamos alcance de un proyecto personal de 60 meses como un
trabajo para 5 personas de más de 12 meses o 6 personas más de 10 meses, o
usando la regla de la raíz cuadrada 8 personas durante 8 meses.
También se necesitan equipos para proporcionar la variedad de habilidades y
aptitudes necesarias para desarrollar o modificar un sistema de software.
Además, la sinergia que se produce cuando los miembros del equipo trabajan
juntos en un espíritu de colaboración a menudo resulta en un producto superior
a la que habría resultado de los esfuerzos de varias personas que trabajan de
forma aislada.
Organización y coordinación de las actividades de las personas que participan
www.it-ebooks.info
en el trabajo en equipo intensivo intelecto es un tipo relativamente nuevo de la
actividad humana. Con el tiempo hemos aprendido a organizar las actividades
agrícolas y de fabricación para utilizar las habilidades
www.it-ebooks.info
de varias personas, pero todavía no hemos dominado las técnicas

correspondientes cionales y de liderazgo Organization for equipos de trabajo-
intensiva intelecto.
Para ilustrar los problemas del trabajo en equipo-intelecto intensiva, tenga en
cuenta las dificultades que surgirían si un grupo de individuos fuera a escribir un
libro como un esfuerzo de equipo, y en un horario predeterminado y dentro de un
presupuesto determinado de personas-hora que podría ser dedicado al proyecto.
Los problemas encontrados serían similares a los encontrados por un grupo de
ingenieros de software que trabajan en equipo (esta analogía se repite desde el
capítulo 1).
La determinación del tipo de libro para escribir y documentar los requisitos
para el libro de una manera clara, completa y sin ambigüedades son
procedimientos análogos a especificar los requisitos para un sistema de software.
La decisión sobre la estructura de las relaciones entre los capítulos y, secciones y
volúmenes (quizás) del libro es el análogo del diseño arquitectónico en el
software. Especificación de estilo, voz, tensa, y el diseño de página para cada
capítulo es similar al diseño detallado del software.
Escribir los capítulos y comprobar la ortografía, la sintaxis y la gramática es
análoga a la unidad de codificación y prueba de módulos de software. La fusión
de los capítulos corresponde a la integración de software. Cuando se ha
completado el libro, el texto integrado debe fluir suavemente, como si estuviera
escrita por un solo individuo en una sola sesión. Un editor realiza una
verificación independiente y hace sugerencias para mejorar el producto, tanto
durante el desarrollo y sobre la terminación de la obra. El valor percibido del
producto final está determinada en gran parte por los comentarios de los críticos
y el trabajo de la boca entre los clientes. Si el libro es muy popular, puede ser
actualizado y puesto en libertad por varias ediciones después de la liberación
inicial.
Debido a que no hay leyes físicas que rigen la escritura del libro y no hay
teorías matemáticas de cómo escribir un libro, un resultado exitoso para el
esfuerzo del equipo dependerá de los objetivos claramente definidos, el
entendimiento común y la aceptación de dichos objetivos, un enfoque común,
recursos adecuados y tiempo de calendario, las habilidades de los colaboradores
individuales, y su capacidad para trabajar como un equipo cohesionado.
Con el tiempo hemos observado una serie de factores y desarrollado una serie
de técnicas que diferencian a los equipos de software capaces de la menor
capacidad. Llamamos a estos equipos de ingeniería de software Equipos (juegos).
Las siguientes pautas resumir la nuestras observaciones y explicar nuestras
técnicas para organizar y SET líder. Estas técnicas son igualmente aplicables al
desarrollo de nuevos sistemas intensivos en software y modificaciones
(mantenimiento) de los sistemas existentes.
11.6.2 Las directrices

1. Contratar a los mejores que puedes encontrar.
En el contexto de los equipos de ingeniería de software, “mejor” significa que
las personas que tienen conocimientos técnicos adecuados y suficientes
habilidades interpersonales para interactuar con otros miembros del equipo.
Algunos ingenieros de software tienen habilidades técnicas pendientes, pero no
son ni interesado en ser, ni psicológicamente adecuado para ser miembros de
equipos cohesionados. Con demasiada frecuencia, las organizaciones son
culpables de suboptimización la productividad de un equipo por atender a la
idiosincrasia de las personas con habilidades técnicas pero socialmente ineptos.
www.it-ebooks.info
En algunos casos, puede ser necesario quitar un miembro del equipo perjudicial
para el mayor bien del equipo, el proyecto y la organización.
Contratar a los mejores se pueden encontrar significa que probablemente tendrá
que pagar más que el precio actual de los individuos dentro de una misma categoría
de calificación. Ha sido
www.it-ebooks.info
repetidamente demostrado que la productividad del programador varía por

factores de 10: 1 o más entre los programadores individuales que tienen
antecedentes y experiencias similares. simple economía indicarían que el pago
del 10% al 20% más a cambio de una ganancia de 500% o 1.000% es una ganga.
2. Tratar a las personas como activos en lugar de los costos.
La primera regla de negocio es la gestión de activos de la empresa para
maximizar el retorno de la inversión en estos activos; La segunda regla es para
controlar los costos. Por desgracia, muchas organizaciones de software
confunden la segunda regla con el primero y tratan a sus ingenieros de software
como los costos en lugar de activos. Las empresas que consideran a sus
ingenieros de software como activos invierten en los ingenieros, proporcionando
una compensación adecuada, un ambiente de trabajo que mejora la productividad
y la calidad del trabajo y un entorno ción manage- que es de apoyo de
trabajadores del sector y las actividades de trabajo. El ambiente de trabajo para
los ingenieros de software incluye el ambiente de trabajo tual sociales, culturales,
y intelec-; el entorno de desarrollo automatizado; y el espacio de trabajo físico.
De acuerdo con DeMarco y Lister [DeMarco99] la capacidad de desviar las
llamadas telefónicas y otras interrupciones, evitando así interrupciones en los
patrones de pensamiento, es uno de los mecanismos más eficaces para mejorar la
productividad individual. los miembros del equipo Co-fijo que participan en una
actividad de trabajo conjunta en las áreas de trabajo adyacentes es esencial.
Proporcionar zonas de descanso privado en el que dos o tres personas pueden
conversar sin molestar a los demás es otro ejemplo de un factor de espacio de
trabajo que puede mejorar la eficiencia y eficacia de las personas y equipos. Una
política de horas de silencio durante parte de cada día de trabajo puede mejorar el
ambiente de trabajo intelectual de los equipos de ingeniería de software. Durante
las horas de silencio no se aceptan llamadas telefónicas, no se celebran reuniones,
y cada miembro del equipo trabaja en tareas individuales, como en un entorno de
biblioteca.
3. Proporcionar un equilibrio entre la especialización laboral y la variedad de
empleos.
Muchos ingenieros de software están motivados por necesidades
aparentemente conflictivos: la necesidad de ser reconocido por su experiencia
dentro de una sub-disciplina, y la necesidad de aprender y aplicar nuevas
habilidades.
En el campo del software, tareas que son un reto inicialmente pueden
convertirse rápidamente en repetitivo y aburrido. Por otra parte, la organización a
menudo necesita especialistas altamente calificados en diversas tecnologías
arcanas. Es razonable asignar tareas a los que son los más cualificados para llevar
a cabo esas tareas; Sin embargo, nuevas y desafiantes asignaciones de trabajo
también deben proporcionarse de manera que los contribuyentes individuales no
se convierten técnicamente estancada. la productividad a corto plazo puede
beneficiarse de la especialización centrated prolongada y con- por individuos,
pero en el largo plazo, el individuo y la organización se beneficiarán de una
variedad juiciosamente elegido de asignaciones de trabajo para los miembros del
equipo.
4. Mantener a los miembros del equipo juntos.
Toma tiempo para que los miembros del equipo para aprender los unos de los
hábitos de trabajo, aptitudes, habilidades, gustos, y disgustos, y los miembros del
equipo se sientan cómodos con su entorno de equipo. Uno de los problemas
potenciales de las organizaciones de la matriz es la falta de cohesión del equipo;
los miembros del proyecto provenientes de hogares funcionales para períodos
www.it-ebooks.info
cortos de tiempo a menudo tienen más lealtad a sus gerentes funcionales y sus
colegas funcionales que a sus compañeros de proyecto y gerente de proyectos.
Mantener un equipo juntos durante largos periodos de tiempo y el uso de técnicas
de formación de equipos explícitas
www.it-ebooks.info
tales como la planificación fuera del sitio y reuniones de revisión, la participación

del equipo en los cursos de formación y actividades recreativas patrocinados por
las empresas son técnicas efectivas para la construcción de un equipo
cohesionado. reuniones de estado semanales pueden ser experiencias de trabajo
en equipo, si PROP- erly llevado a cabo (véase la directriz 10).
5. Limitar el tamaño del equipo.
Estrecha coordinación, trabajo en equipo-intelecto intensiva se logra mejor por
equipos pequeños. Hemos observado dos tipos de equipos de ingeniería de
software cohesivos, siendo el primero el más común. Esta estructura del equipo
se compone de tres a seis miembros del equipo además de un jefe de equipo, lo
que resulta en un tamaño máximo de siete equipo. Si un equipo crece hasta ocho
o más, se divide en dos equipos de tres a seis miembros cada uno de los líderes
del equipo más. Cuando un equipo se hace más grande de seis o siete, es difícil
para los miembros del equipo para coordinar sus actividades de trabajo con cada
uno de los otros miembros del equipo. También es imposible que el líder del
equipo para proporcionar el nivel necesario de la planificación, coordinación
ción, y el liderazgo.
Los equipos más grandes de siete pueden ser un síntoma de
compartimentación inadecuada de los requisitos e insuficiente descomposición de
la arquitectura de software. El producto debe ser estructurada como una
colección de elementos de acoplamiento flexible, altamente cohesivas, donde
cada elemento puede ser implementado por un equipo pequeño. Los equipos son
entonces altamente cohesivo y débilmente acoplado.
La segunda estructura de equipo se compone de 7 a 12 personas, además de un
jefe de equipo. Dentro de estos equipos más grandes, los miembros individuales
del equipo son más autónomas y tienden a acoplarse de manera más flexible a
otros miembros del equipo que en los 3 a 6 equipos de la persona. Para ser
eficaces, estos equipos más grandes deben satisfacer algunas condiciones
especiales; a saber:
• cada miembro del equipo debe ser un altamente cualificado y experimentado

profesional;
• cada miembro del equipo debe tener un papel funcional bien definido; y
• cada uno debe tener una clara comprensión de su papel y las funciones de los
otros miembros del equipo.
Además, cada miembro del equipo debe tener suficiente iniciativa y disciplina
para planificar y organizar sus actividades de trabajo individuales y para
comunicarse con los otros miembros del equipo y el líder del equipo (véase la
directriz 8).
Estos equipos cohesivos más grandes se han observado en dominios tales
como las telecomunicaciones, control de procesos, y la ingeniería de sistemas.
Los miembros de estos equipos son a menudo altamente cualificado y
experimentado en sus especialidades funcionales, papeles funcionales están
claramente diferenciadas, y el papel de cada persona es claramente entendidos
por otros. Se debe destacar que los equipos y proyectos se colocan en riesgo
cuando los equipos más grandes de siete (seis miembros, más líder) se utilizan
sin los requisitos previos de la habilidad individual, la experiencia, la
especialización del trabajo, y la iniciativa.
6. Diferenciar el papel de líder del equipo.
En ambos tipos de equipos, los jefes de equipo desempeña las funciones
esenciales de:
www.it-ebooks.info
• planificación, negociación y coordinación de las actividades de trabajo de los
miembros del equipo;
• el establecimiento de objetivos de rendimiento para cada miembro del equipo;
• el seguimiento del progreso de los individuos y el equipo;
• actualización de los planes;
www.it-ebooks.info
• la validación de los productos de trabajo producidos por los miembros del

equipo; y
• comunicarse con el director del proyecto, el arquitecto de software, otros ele-
mentos del proyecto, la organización matriz, y la organización del cliente.
A pesar de que las responsabilidades son las mismas, las actividades del líder
del equipo son algo diferentes para los equipos de 3 a 6 que para los equipos de 7
a 12 (véase la directriz 8).
En todos los casos, un líder de equipo puede ayudar a un miembro del equipo,
pero nunca toma la iniciativa en la generación de productos para el trabajo de
trabajo de un equipo líder es planificar y coordinar las actividades de trabajo,
establecer objetivos de rendimiento, validar productos de trabajo, controlar el
progreso, asesorar y ayudar al equipo miembros, anticiparse a los problemas, y
ser portavoz para el equipo. Debido a estas funciones de planificador,
coordinador, monitor de progreso, comunicador, y el agente de control de calidad
(véase la directriz 7), el líder de un equipo de ingenieros de software no es “la
sobrecarga de administración”, sino más bien es el catalizador que hace que un
grupo de individuos a unirse en un equipo cohesionado productiva.
El jefe de programación del equipo es otro tipo de equipo de software de
cohesión [Baker72]. La distinción principal entre nuestro enfoque (juegos) y la
del equipo de gramática Jefe Pro- es que el líder SET no genera los productos de
trabajo, ni es él o ella le pide ser el gurú técnico (pero un líder SET deben estar
familiarizados con el dominio de aplicación y debe ser competente en las
tecnologías de software que se utiliza).
En un conjunto coherente, los miembros del equipo, individual y
colectivamente, tienen la autoridad para tomar decisiones técnicas y son
responsables de los contenidos técnicos de su trabajo. En el enfoque programador
jefe, el jefe de programación hace que toda decisión téc- nico y genera la
mayoría, si no todos, del software. También es difícil para el jefe de
programación para llevar a cabo todas las tareas técnicas y de gestión necesarias
debido a la gran carga de trabajo involucrado, y debido a la variedad de
habilidades necesarias para hacer bien los dos trabajos. Además, es difícil de
ampliar la técnica de jefe de programación de proyectos múltiples del equipo; las
técnicas descritas en este capítulo pueden ser escalados a proyectos de tamaño
arbitrario (véase la directriz 14).
7. Hacer que cada jefe de equipo agente de control de la calidad del equipo.
Una tarea importante para un líder de equipo es la especificación o la
adaptación de los criterios de validación para los productos de trabajo y
determinar que los productos de trabajo satisfacen los criterios. En equipos de
tres a seis, el líder del equipo es el moderador de revisiones por pares (es decir,
inspecciones) y determina que otras actividades de ingeniería de calidad se llevan
a cabo de una manera eficaz; por ejemplo, la determinación de que los criterios
de terminación-prueba de la unidad están satisfechos.
En equipos más grandes (de 7 a 12 miembros), el líder del equipo por lo
general no validan todos los productos de trabajo generados por todos los
miembros del equipo, sino que asigna tareas de validación, como los derechos de
moderador para equipos de revisión, a los miembros del equipo en un “round-
robin” forma para que todos toma su turno. Esto es posible porque cada miembro
de los equipos más grandes tiene suficientes conocimientos y experiencia para
conducir revisiones por pares y aplicar criterios de validación de objetivos para
los productos de trabajo generados por otros miembros del equipo. Cada
miembro del equipo está capacitado para servir como moderador, lector y
www.it-ebooks.info
grabador de revisiones formales de pares.
Así pues, el líder hace el “trabajo real”, se mantiene en estrecho contacto con
los esfuerzos de cada miembro del equipo, y asume la responsabilidad por la
calidad de los productos de trabajo generados
www.it-ebooks.info
por el equipo. En los proyectos de software organizados en torno a un juego o

conjunto, los jefes de equipo son, pues, los agentes de control de calidad primaria
para esos proyectos. El papel del grupo Ance assur- calidad es entonces para
asesorar a los jefes de equipo, analizar datos de métricas de calidad, mejoras en
los procesos MEND ciones, y para asegurar que los jefes de equipo y sus equipos
están cumpliendo con sus responsabilidades.
Tenga en cuenta que en un proyecto pequeño (es decir, 6 o menos miembros
del equipo) el líder del equipo también puede desempeñar el papel de jefe de
proyecto y arquitecto de software.
8. Descomponer las tareas en unidades manejables de trabajo.
tareas de nivel más bajo están dimensionadas para lograr un equilibrio entre la
microgestión de los miembros individuales del equipo y la gestión macro de todo
un equipo. A nivel de las asignaciones de trabajo para las personas, se
recomienda la regla de “uno-a-dos”: una o dos personas, una a dos semanas, pero
sin exceder de 80 horas por persona-tarea. por lo tanto la regla de uno a dos
soportes de las tareas de trabajo en un 40 horas el personal a 80 horas personal de
rango. Una tarea asignada a una persona durante dos semanas o dos personas
durante una semana satisfagan la regla de uno a dos. Cuarenta personas-horas de
esfuerzo en el extremo inferior evita agement microman- de individuos que
pueden planificar y organizar sus actividades de trabajo semana a semana, tal vez
en un horario flexible horas. Ochenta personas-horas en el extremo superior evita
macrogestión forzando atención a la planificación y el seguimiento del progreso
detallada por los jefes de equipo y jefes de proyecto.
En equipos de tres a seis, la regla de uno a dos proporciona una carga de
trabajo manejable para el líder del equipo. Para un equipo de cinco
contribuyentes individuales, cada uno dedicado a una tarea personal de 40 horas,
el líder del equipo será, en promedio, tienen una tarea a validar y una nueva tarea
de iniciar cada día completado. Un equipo de tres, cada uno trabajando en 80
horas personal- tareas, tareas representa un año y medio para validar y poner en
marcha todos los días; Sin embargo, las tareas tienen el doble de grande como
para iniciar y los productos de trabajo para ser validados son más grandes y / o
más complejos que las tareas hora y 40 relacionados con el personal y pueden
requerir más esfuerzo por tarea.
En grupos de 7 a 12 miembros, de los delegados líder del equipo algunas
funciones. Cada miembro del equipo es responsable de la generación y
documentación de 40 a 80 horas los planes de trabajo, cada uno de los cuales
genera un producto de trabajo que es aceptado por los criterios de vali- dación
objetivas, y de la coordinación de su o sus planes con el líder del equipo y otros
miembros del equipo. Sin embargo, el líder del equipo sigue siendo responsable
de la revisión, ing approv-, y la coordinación de los planes; el establecimiento de
objetivos de rendimiento; monitorear el progreso; Opti-zando el reparto de los
miembros del equipo y otros recursos; asegurar que los productos de trabajo
satisfacen sus criterios de validación; comunicarse con el arquitecto de software,
director del proyecto, otros elementos de la organización, y las entidades del
cliente; y asegurar que los miembros individuales del equipo están cumpliendo
con sus objetivos de rendimiento (véase la directriz 11).
9. Utilizar un enfoque de onda de laminación aumentada para la planificación.
En los proyectos de software normalmente no es posible, ni deseable, para
planificar actividades de trabajo a nivel personal semanas de uno a dos de los detalles
más de uno o dos meses antes de que el trabajo a realizar. Para planificar a nivel de
uno a dos de detalle, se debe adoptar un enfoque de onda de laminación aumentada
para la planificación detallada. El enfoque de onda de laminación consiste en
www.it-ebooks.info
refinación y revisión de los planes sobre una base mensual. El enfoque de la onda de
laminación aumentada para la planificación aumenta planificación tradicional de
onda de rodadura mediante el mantenimiento de 3 niveles de detalle en el plan como
se ilustra en la figura 11.3.
El nivel más detallado es para el próximo mes, y está programada en las de
uno a dos (40 a 80 personas-hora) nivel de detalle. El segundo nivel, menos
detallada de la planificación es
www.it-ebooks.info
n mes planificación: nn + 1 n+2
mes n + 1 de n+1N+2 n+3

planificación:
n+2 n + 3n + 4
mes n + 2 de
planificación:
FIGURA 11.3 la planificación de onda de laminación aumentada
para el mes siguiente; este plan es lo más detallado posible, pero será por
necesidad ser menos detallada que la versión procedente meses. El tercer nivel de
detalle es por tercer mes posterior. Cada uno de estos niveles de detalle debe ser
consistente con las limitaciones globales sobre el esfuerzo, el calendario, el
presupuesto y la tecnología. En proyectos de larga duración, puede ser deseable
poner al día un nivel de seis meses de detalles, además de los de un mes, dos
meses, tres meses y niveles de detalle.
Cada mes la “ola” de planificación se rueda hacia adelante mediante la
actualización de cada nivel de la planta a la luz de la evolución de la situación.
Llamamos a este enfoque de una onda rolling- aumentada debido indicamos tres
(o cuatro) niveles de detalle en el plan. Esto evita que el enfoque miope sobre las
actividades para el próximo mes a la exclusión de futuro, menos bien definido,
pero las tareas previsibles.
10. Adoptar un modelo contractual para la asignación de tareas.
actividades de trabajo de gran tamaño (el desarrollo de requerimientos, diseño,
codificación, pruebas) se descomponen en tareas de 40 a 80 horas del personal
utilizando el enfoque de la onda de laminación aumentada para la planificación.
Cada tarea se documenta en un paquete de trabajo y cada paquete de trabajo se
convierte en un contrato negociado entre theteam líder y theindividual (s)
asignado a ese paquete de trabajo.
Cada paquete de trabajo proporciona una descripción de la tarea, las relaciones
de esa tarea a otras tareas y actividades (es decir, relaciones jerárquicas entre las
actividades y tareas en la estructura de división del trabajo, y relaciones de
precedencia entre las tareas en la red del cronograma); la duración prevista de la
tarea, los números y tipos de recursos necesarios para llevar a cabo las tareas, los
productos de trabajo a ser producido, los factores de riesgo que podrían crear
problemas para completar con éxito la tarea, y los criterios de aceptación de los
productos de trabajo . Cada paquete de trabajo debe producir uno o más
productos tangibles de trabajo que deben satisfacer los criterios de aceptación
objetivas. Un ejemplo de un paquete de trabajo típico se presenta en la Tabla
11.8.
Las relaciones Member_of y Preceded_by de la Tabla 11.8 se utilizan para
imponer una estructura de división del trabajo y una red de horario en una
colección de paquetes de trabajo. Member_of identifica la actividad más amplio
al que pertenece un paquete de trabajo; el conjunto de actividades subordinadas y
tareas define la actividad más grande. Preceded_by especifica las tareas y
productos de trabajo que se deben completar antes de que un paquete de trabajo
puede ser iniciado. La red del cronograma puede determinarse a partir del
Precedido por PARENTESCO naves de los paquetes de trabajo; el camino crítico
que determina la duración de un proyecto se puede determinar a partir de la red
www.it-ebooks.info
de horario.
Una colección de paquetes de trabajo puede ser analizada para atributos tales
como Ness exhaustividad, la coherencia, la ruta crítica, necesidades de recursos
colectivos, y los factores de riesgo. El estado de ejecución de las tareas y sus
actividades de los padres (en espera / abierto / cerrado) se puede determinar
mediante el examen de estado del paquete de trabajo. El personal asignado y la
fecha de inicio
www.it-ebooks.info
TABLA 11.8 Un ejemplo de un paquete de trabajo

3.2.2.1 Paquete de trabajo
ACTIVITY_NAME: DESIGN_INPUT_SUBSYSTEM
Descripción: Especificar la estructura arquitectónica de ENTRADA y desarrollar el
plan de pruebas para INPUT
Member_of: 3.2.2
Preceded_by: 3.1.1 y 3.1.2
Plan
Planned_duration: 2
Resources_needed semanas:
Personal: 1 Telecomunicaciones alto diseñador
Habilidades: deben conocer el X25 protocolo
Métodos: a base de estado OO diseñar IEEE Std. 829
para el plan de pruebas
Herramientas: estación de trabajo 1 MACBOOK; iLogix prodigio
Viajes: Ninguno
Work_products: especificación de arquitectura para el plan de
prueba de entrada para
INPUT
Acceptance_criteria: Exitosa pares que conforman el diseño y el plan de
pruebas de cierre de sesión por el arquitecto
jefe
Risk_factors: diseñador de Telecomunicaciones no identificado
restricción de horario
Responsible_party: R. Fairley
Implementación
Estado: (pendiente / abierto / cerrado)
Personnel_assigned: (planificada / actual)
Fecha_inicial: (planificada / actual)
COMPLETION_DATE: (planificada / actual)
productos de trabajo generada: (planificada / actual)
Resources_consumed: (planificados / reales)
Legacy_comments:
fin 3.2.2.1
puede ser determinada y comparada para planificar paquetes de trabajo abiertas.

La fecha real pletion com-, consume recursos, productos de trabajo generados, y
los comentarios de legado, además, se puede determinar para los paquetes de
trabajo cerrados.
La asignación de paquetes de trabajo a las personas y las estimaciones de las
duraciones de tiempo necesario para completar las tareas son negociados por el
líder del equipo y cada miembro del equipo, sujeto a las limitaciones generales de
recursos y programación. Un acuerdo sobre un paquete de trabajo entre el líder
del equipo y un miembro del equipo constituye un contrato para la realización de
uno o más productos de trabajo dentro de la duración de tiempo especificado que
demostrar strably satisfacer los criterios de aceptación para los productos de
trabajo.
seguimiento de las entregas binaria puede (y debe) ser usado para rastrear
ciones complementa la tarea [DeMarco82]. seguimiento binario requiere que un
paquete de trabajo será acreditado como 0% de avance hasta que los productos de
www.it-ebooks.info
trabajo asociados satisfacen sus criterios de aceptación; el
www.it-ebooks.info
paquete de trabajo se convierte en 100% completa. La descomposición de los

paquetes de trabajo a una granularidad de 40 a 80 horas y personal-binario
mediante el seguimiento de proporcionar información precisa para un sistema de
información del valor ganado [Webb03], que a su vez proporciona un breve
resumen del estado del proyecto y la alerta temprana de problemas inminentes.
11. los objetivos de rendimiento establecidos para el equipo y para cada
miembro del equipo.
En su libro, La sabiduría de los equipos, Katzenbach y Smith observar que la
forma más eficaz de construir un equipo cohesionado es establecer metas de
desempeño desafiantes para todo el equipo y para cada miembro del equipo.
[Katzen93] Los objetivos deben ser difícil pero no imposible. DeMarco y Lister
incluyen horarios imposibles (plazos falsos) como una de las “maneras de éxito
seguro para inhibir la formación de equipos e interrumpir la sociología proyecto.”
[DeMarco99] Otros factores citados por Katzenbach y Smith que distinguen a los
equipos eficaces incluyen tener un propósito significativo, una enfoque común,
habilidades complementarias, y la responsabilidad mutua.
Es importante establecer objetivos de rendimiento para cada miembro del
equipo, así como para todo el equipo. Este enfoque elimina la posibilidad de que
los esfuerzos del equipo colectivos podrían diluir la responsabilidad individual, la
iniciativa y el reconocimiento. Elementos de un objetivo de rendimiento incluyen
criterios objetivos y medibles, y un marco de tiempo para alcanzar la meta. Por
ejemplo, un objetivo del equipo podría ser la reducción de horario de
esponjamiento de 20% a 10% en el próximo trimestre al reducir el número de
errores cometidos (es decir, defectos inyectados) y reduciendo así la reanudación
correctiva [Fairley05].
Es también importante que los objetivos del equipo serán discutidos y
negociados de manera abierta con todo el equipo, y se discuten que las metas
individuales, negociados, y revisados en privado con cada individuo. Los
objetivos deben ser difícil pero no imposible. El progreso hacia las metas deben
ser controlados y la acción correctiva tomada si la extrapolación de la tendencia
actual indica que un objetivo probablemente no se encontró dentro del marco de
tiempo especificado. La imposibilidad de lograr una meta ambiciosa debe
considerarse como una oportunidad para aprender de la experiencia y para
mejorar el rendimiento futuro.
El rendimiento se revisa periódicamente (por ejemplo, mensual) con el equipo
y con cada miembro del equipo. Logro de objetivos ambiciosos se celebra, se
identifican los problemas, y se identifican los impedimentos para un mejor
rendimiento. los objetivos del equipo, el progreso hacia esos objetivos y logros
del equipo se muestran de una manera pública. Revisión del rendimiento
individual es un asunto confidencial entre el individuo y el líder del equipo. Los
miembros del equipo que constantemente no cumplan con los objetivos
acordados a deben ser aconsejados para determinar las razones por las que no
pueden cumplir con los objetivos y desarrollar líneas de acción que permitan a
los miembros del equipo para mejorar su rendimiento.
Fijación de nuevos objetivos es un proceso continuo. Esto se puede hacer en
relación con el enfoque de la onda de laminación para la planificación y control
(véase la directriz 9). El establecimiento de objetivos y la medición del desempeño
no tienen que ser, y no deben ser, maquiavélico [Mach13]. Atributos de equipos
cohesionados incluyen un sentido colectivo del humor, sano escepticismo, y el
disfrute de trabajar juntos. Estos atributos facilitan la configuración colectiva de los
objetivos del equipo.
12. Garantizar interacciones diarias con cada miembro del equipo y entre los
www.it-ebooks.info
miembros del equipo. Es importante que el líder del equipo interactuar con cada
miembro del equipo y que los miembros del equipo interactúan entre sí sobre una
base diaria. Uno de los mecanismos para ING fin de • asegurar la interacción
diaria es una reunión de 15 a 20 minutos “stand-up” en el que cada equipo
www.it-ebooks.info
miembro informa brevemente sobre trabajo realizado el día anterior, el trabajo en

curso para el día actual y los problemas que deben señalarse a la atención de los
otros miembros del equipo. Problemas que deben resolverse entre dos o tres
individuos deben tenerse en cuenta, pero manejan aparte de la reunión del
equipo. Cuestiones que requieren la atención de todo el equipo deben ser
programadas para más tarde en el día o tal vez al día siguiente, en función de la
urgencia de la situación.
Un foro diaria proporciona una oportunidad para que el líder del equipo para
comunicar cualquier información nueva, el informe sobre el estado de los
trabajos en curso, para comentar sobre los últimos rumores, y para dar aviso
previo de los próximos eventos. También proporciona una oportunidad para que
los miembros del equipo de “par-off” y discutir temas de interés mutuo después
de la reunión.
correo electrónico, videoconferencia, y el trabajo en grupo herramientas nunca
deben utilizarse en lugar de las reuniones diarias “cara a cara”. Los medios
electrónicos pueden ser eficaces mecanismos de comunicaciones y debe ser
utilizado en su totalidad, pero deberían aumentar y no sustituir el contacto
humano entre los miembros del equipo y entre los miembros del equipo y el líder
del equipo. Los miembros del equipo que están en los viajes deben hablar, por
teléfono, con su jefe de equipo sobre una base diaria. Noticias de sus actividades
debe ser trans- mitidas por el líder del equipo con otros miembros del equipo
durante las reuniones diarias de pie. Un líder del equipo que actúa debe ser
designado cuando el líder oficial está ausente y la actuación y los líderes oficiales
del equipo deberá comunicar, por teléfono, sobre una base diaria.
13. Llevar a cabo reuniones semanales de revisión de estado.

El equipo debe reunirse cada semana para revisar el estado del proyecto y para
ayudar al líder del equipo en la preparación de un informe de estado semanal y
una lista de puntos de acción para los problemas que se han encontrado
recientemente. El informe de estado incluye un resumen de los progresos en el
calendario previsto y resume las tareas completadas durante la semana pasada,
las tareas que se inicien en la próxima semana, tareas a realizar en la próxima
semana, y el estado de los factores de riesgo y puntos de acción.
Problema estado se clasifica en problemas resueltos durante la semana pasada,
los nuevos problemas que han surgido en la última semana, los problemas en
curso, y los viejos problemas que se cree que han sido resueltos que han
resurgido. Los factores de riesgo son posibles problemas que podrían ocurrir,
pero no tienen todavía; un problema es un factor de riesgo que ha material- zado.
Los factores de riesgo se caracterizan por probabilidad, impacto, marco de
tiempo, y las actividades de mitigación. Las actividades de mitigación se refieren
a reducir la probabilidad y / o el impacto potencial de un factor de riesgo; que
incluyen la evitación, el traslado, la aceptación, la acción inmediata, y la acción
contingente. Los problemas y los factores de riesgo que no se puede o no debe
ser, manejados por el equipo son llevados a la reunión semanal del líder del
equipo con el director del proyecto. En proyectos pequeños, donde el líder del
equipo es también el director del proyecto,
Con base en la revisión semanal de los problemas más resueltos, nuevos,
continua y resurgido, los miembros del equipo ayudan al líder del equipo en el
desarrollo de la lista de problemas del equipo priorizado “top-N” (donde N 10)
[Boehm89]. Cada problema en la lista de la parte superior-N ha asociado un
elemento de acción que especifica la naturaleza del problema, las acciones a ser
perseguido, la persona responsable y la fecha de cierre prevista. Autoridad para la
toma de decisiones y recursos que deben aplicarse son especificados, según el
www.it-ebooks.info
caso.
www.it-ebooks.info
TABLA 11.9 Formato de un informe de estado

semanal
informe de estado semanal
Fecha
:
Para:
De:
Situación laboral:
Las tareas
completadas: tareas
a ser iniciados:
Tareas a realizar: Las áreas
problemáticas:
Problemas resueltos:
Nuevos problemas:
problemas a largo
plazo:
problemas resurgido:
Factores de riesgo:
Descripción de cada uno:
Probabilidad, impacto potencial, el tiempo de
cada uno: estrategia de mitigación recomendadas
para cada uno:
Los elementos de acción se introducen en un sistema de seguimiento y el

estado de cada elemento de acción abierta se revisarán en la reunión de estado
semanal. Los elementos de acción son tratados como informes de discrepancia
contra el proceso de desarrollo, como tales, se realiza un seguimiento hasta el
cierre de la misma manera los informes de problemas (informes de errores) son
rastreados contra el producto. Es importante que los miembros del equipo están
de acuerdo en las prioridades entre los problemas y los elementos de acción
asociados de modo que las prioridades de tareas y la asignación de recursos están
comprendidas y apoyadas por todos.
Una técnica efectiva para la presentación de informes de estado semanal es la
adopción de un formato estándar para los informes, como en la Tabla 11.9. Cada
miembro del equipo se somete, por correo electrónico, su informe semanal
individuo para el líder del equipo y para todos los demás miembros del equipo en
la tarde antes de la reunión semanal. Todo el mundo viene a la reunión semanal
de haber revisado todos los informes individuales.
opiniones de estado semanales se limitan a no más de dos horas. Los productos
que no involucran a todo el equipo se manejan por separado. Una técnica efectiva es
programar las revisiones semanales como comidas de trabajo. En uno de mis
anteriores trabajos, tuve la suerte de tener fondos disponibles para comprar
bocadillos y refrescos para las reuniones de revisión del viernes. Estos reunión
almuerzo de dos horas eran tan eficaces como revisiones del estado y como
experiencias de formación de equipos que si (y cuando) llevo a otro equipo en el
futuro, voy a pagar por los bocadillos (pizza, chino, ...) a mí mismo si es necesario.
Un programa recomendado para reuniones de estado semanales y las actividades
de seguimiento se presenta en la Tabla 11.10. Algunos renegociación de los contratos
con los miembros del equipo (el punto 4 de las actividades de seguimiento) puede
ocurrir y puede implicar la negociación fuera de las responsabilidades entre los
miembros del equipo (con el consentimiento del jefe de equipo). En un equipo
cohesionado, es bastante común para aquellas personas que se estén ejecutando antes
www.it-ebooks.info
de lo previsto en sus tareas como voluntario para ayudar a aquellos que están
corriendo detrás. El trabajo compartido y la voluntad de ayudarse entre sí son
indicadores clave de un equipo de ingenieros de software cohesiva.
14. Estructurar proyectos grandes como pequeñas colecciones de proyectos
altamente cohesivos, de forma flexible.
www.it-ebooks.info
TABLA 11.10 del orden del día y las actividades de seguimiento para las reuniones de estado
semanales
agenda de la reunión (2 horas)
1. Han almuerzo evitar discusiones técnicas (media hora)
2. Revisar los informes de estado individuales
3. Estado de la revisión de los puntos de acción abiertas
4. Generar una lista de problemas N superior colectiva revisada
5. Generar una lista revisada, priorizada de los puntos de acción
6. Generar una lista revisada de los factores de riesgo y estrategias de mitigación
actividades de seguimiento del líder del equipo

1. Introducir nuevos elementos de acción en el sistema de seguimiento
2. Vuelva a dar prioridad a los puntos de acción existentes, según sea necesario
3. Generar paquetes de trabajo para los nuevos elementos de acción
4. Volver a negociar contratos con los miembros individuales del proyecto, según sea
necesario
5. Poner en marcha estrategias de mitigación de riesgos, según sea necesario
6. Revisar los horarios y la asignación de recursos según sea necesario
7. Informar de los puntos de acción al alza y los factores de riesgo que no puede ser, o
no debe ser, manejado por el equipo
Los proyectos que requieren más de seis miembros del equipo además de un jefe
de equipo (o de 7 a 12 miembros en ciertas circunstancias; véase la directriz 5) deben
utilizar múltiples equipos. Figura
11.2 ilustra una estructura de proyecto que puede ser adaptado a las necesidades
de los proyectos que van desde 3 o 4 miembros a proyectos que tienen cientos de
miembros. En el caso de un proyecto pequeño (6 o menos miembros), una
persona puede desempeñar el papel de contacto con el cliente, el director del
proyecto, arquitecto de software (es decir, el diseñador jefe), y líder del equipo.
En proyectos de tamaño medio (de 7 a 50 miembros), múltiples jefes de equipo
(6 o menos miembros por equipo) informe a un jefe de proyecto; además son
miembros del equipo de diseño de la arquitectura de software. En proyectos
grandes (más de 50 miembros) los jefes de equipo representados en la Figura
11.2 son gerentes de subsistemas; cada gestor subsistema tendrá múltiples
equipos y jefes de equipo. Dependiendo del tamaño y la complejidad de un
subsistema, El gerente también puede ser la arquitectura de software en ese
subsistema o puede ser asistido por un arquitecto subsistema. En un gran
proyecto el director del proyecto puede ser asistido por uno o más miembros del
personal, y el arquitecto jefe puede dirigir un equipo de diseño está formado por
los arquitectos del subsistema.
Los diferentes equipos y diferentes grupos de subsistemas pueden utilizar
diferentes métodos y herramientas, según proceda, en el marco general del
proyecto. Algunos equipos pueden practicar otras técnicas de desarrollo ágil y la
programación en parejas, mientras que otros podrían utilizar una estrategia de
desarrollo incremental semanal construye y demostraciones; algunos equipos
podrían utilizar un enfoque basado en el estado para el diseño e implementación,
mientras que otros están utilizando la descomposición funcional o técnicas
orientadas a objetos.
La regla de oro para la estructuración de proyectos de software, al igual que
con el software en sí, es el diseño de una colección de elementos altamente
cohesivos, de forma flexible. En un artículo de 1968 Mel Conway observó que la
estructura de un producto de software tiende a parecerse a la estructura del
www.it-ebooks.info
equipo que lo desarrolla [Conway68]. Al igual que muchos pro encontraron
declaraciones, éste es obvio una vez señalaron: los protocolos y convenciones
elaborados entre los miembros del equipo y entre equipos convertido en las
interfaces entre los módulos de software y subsistemas desarrollados por los
miembros del equipo y los equipos.
www.it-ebooks.info
La observación de Conway puede ser denominado como la “ley de Conway”

con el fin de introducir “corolario de Fairley:”
Para maximizar la eficiencia y la eficacia, la asignación de tareas para equipos de

proyectos y para los miembros individuales del proyecto debe ser estructurado para
reflejar la estructura del producto deseado.
Una técnica para asegurar la adherencia al corolario de Fairley es la de insertar la

estructura del producto en la estructura de desglose del trabajo (EDT) dividiendo
las tareas de desarrollo en la EDT en correspondencia uno-a-uno con la
La figura 11.4 ilustran una WBS parcial en la que la estructura del producto se
denota por los productos de trabajo que resultarán de la terminación de los
correspondientes edades PACK- trabajo. Los paquetes de trabajo son, pues, las
especificaciones de los elementos PEP; en cuenta que cada elemento de la EDT
es una frase verbal que denota una actividad o tarea a ser plished acompa-.
asignación de tareas para los equipos y los individuos se genera a partir de los
paquetes de trabajo.
Cajer
o
auto
mátic
o
1 2 Manejo Do Sistema 3 Desarrollar 4Proyec
Compruebe 5 Validar 6 7 Preparar 8
ProjectAnalysis
Realizar to
Software Sistema Instalar Tech. Pubs.
Sistema CM Sistema
3.1. Construir 3.2. Construir 3.3. 3.4.

ConstruirATMHD FINAT Compra 3.5. Integrar
DIAGN r ATMHD, FINAT,
COMM MANT Y COMM
3.2.1 Build 3.2.2 Build 3.2.3 Build 3.2.4 Build 3.2.5 Integrar
Validado Procesador Grabador Terminator módulos FINAT
r [E1, [E3, D1, D2, D3, a [E4, [E6, D4]
E2] O1, O2, O3] E5]
- 3.2.1.1 - 3.2.2.1 - 3.2.3.1 - 3.2.4.1 DEST

DESV DESP ARED
- 3.2.1.2 - 3.2.2.2 - 3.2.3.2 - 3.2.4.2 CUTT
CUTV CUTP CUTR
- 3.2.1.3 - 3.2.2.3 - 3.2.3.3 - 3.2.4.3 ITTM
ITVM ITPM ITRM
ATMHD: Controladores de hardware ATM; FINAT: las transacciones financieras;

Diagn: Diagnóstico;
COMM: paquete de comunicaciones
DESX: diseño detallado de x; CUTx: código de prueba de unidad y X; ITXC: integrar y
módulo de prueba x
FIGURA 11.4 Una estructura de división del trabajo parcial
Por ejemplo, la tarea 3.2.1.2, (código y unidad de prueba el validador) podría

ser un paquete de 40 horas que se convierte en un contrato con un miembro del
equipo individual para una semana; el producto del trabajo resultante sería el
módulo validador. El uso de estructuras de desglose de trabajo orientado al
proceso y paquetes de trabajo para especificar tareas asegura que la estructura del
producto se verá reflejado en el trabajo asignado a los equipos ya
www.it-ebooks.info
miembros individuales del equipo, ya que cada paquete de trabajo debe generar
uno o más tangibles productos de trabajo que son aceptadas mediante los criterios
de aceptación objetivas. Tenga en cuenta que los requisitos para los elementos
Validador, procesador, grabadora, y el terminador de la ATM se asignan a los
módulos como esencial (IE), (OI) requisitos deseables (Di), y opcionales.
La agregación de los paquetes de trabajo y productos de trabajo completado
por un equipo REPRESENTA las contribuciones de ese equipo a un proyecto
más amplio. El paquete de trabajo para un equipo se especifica como un contrato
entre el equipo y el proyecto más grande. Ese paquete de trabajo se descompone
entonces por el líder del equipo, en consulta con los miembros del equipo, en una
colección de paquetes de trabajo y las asignaciones de trabajo para los miembros
individuales del equipo, usando la regla de la descomposición de uno a dos y la
planificación de onda rolling- aumentada.
Los sistemas grandes (las que requieren el esfuerzo de quizás cientos de
personas) deben ser repartido de manera que ningún líder miembro del equipo o
equipo individual tiene que ser consciente de, o preocupados, los esfuerzos de
más de 25 o 30 otras personas que están trabajando en el mismo subsistema. Esto
puede equivaler a cinco equipos de seis personas, además de los jefes de equipo;
colectivamente los equipos son responsables de desarrollar un subsistema de un
sistema mayor.
Por la ley de Conway y corolario de Fairley este enfoque dará lugar a un
producto con interfaces de bajo acoplamiento entre los subsistemas, bajo
acoplamiento entre los elementos de cada subsistema, y alta cohesión dentro de
los elementos generados por cada equipo pequeño. Igualmente importante, es
posible para cada miembro, y cada jefe de equipo para conocer los nombres y las
caras de todas las demás personas que trabajan en el subsistema, lo que
proporciona una identificación individual con el esfuerzo más grande evitando
así la sensación de anonimato en una gran burocracia.
Tal vez lo más importante, este enfoque permite a los jefes de equipo
subsistema para funcionar como un equipo pequeño que informa al administrador
de subsistema y trabaja con el arquitecto subsistema. El gerente subsistema puede
gestionar los jefes de equipo utilizando las mismas técnicas que los jefes de
equipo utilizan para gestionar sus equipos, incluidos los objetivos de rendimiento
individual y colectiva, aumentada de planificación, los paquetes de trabajo, la
estructura del proyecto de onda, material móvil y redes de actividades, modelos
tuales contratistas, criterios de aceptación binarios para productos de trabajo,
reuniones de estado semanales, listas de problemas N-arriba, seguimiento de
elementos de acción, gestión de riesgos y un informe del valor ganado.
A su vez, los administradores del subsistema son un equipo que informa a su
entrenador y los arquitectos del subsistema son miembros del equipo de diseño
del jefe del arquitecto. Mance objetivos Perfor- y paquetes de trabajo fluyen
hacia abajo a través de la jerarquía; compromisos negociados, productos de
trabajo, y métricas de rendimiento fluyen hacia arriba. De esta manera las
técnicas descritas equipo se puede generalizar a partir de los individuos para
proyectos de tamaño arbitrario.
15. Recuerde que las organizaciones no son nada más que los individuos y
grupos de individuos.
Es fácil olvidar esta regla cuando se encuentra en medio de un proyecto de
software. Las técnicas presentadas en esta sección hacen que sea posible lograr
un equilibrio entre las necesidades de los individuos y las necesidades de las
organizaciones. observación no-famosa de Fred Brooks hay balas de plata en
ingeniería del software es ya un tópico, si bien importante [Brooks87]. Sin
www.it-ebooks.info
embargo, grupos de individuos, que trabajan en
www.it-ebooks.info
equipos pequeños, bien organizadas y bien dirigidas por las balas “son bañados
en plata” de la ingeniería de software. Las habilidades técnicas de los individuos
y la capacidad de los individuos para fun- ción como miembros de equipos
cohesionados que participan en el trabajo en equipo-intelecto intensiva son las
claves del éxito.
Cada disciplina de ingeniería depende de las personas, procesos y tecnología.
En el software de ingeniería de las personas son el factor más importante. las
personas competentes y los equipos cohesivos pueden superar los procesos
débiles y pobres tecnología. Pero exce- procesos y tecnología excepcional
prestado nunca puede compensar la insuficiencia de conocimientos o equipos
disfuncionales.
11.6.3 Resumen de las Directrices

En esta sección se ha proporcionado 15 directrices para organizar y dirigir
equipos de software inge- niería (juegos). Las directrices se resumen en la Tabla
11.11. Estas líneas directrices pueden ser, y deben ser, a la medida para adaptarse
a su situación particular. Si usted está involucrado en el desarrollo de un sistema
de gran tamaño las técnicas descritas en la directriz 15 se pueden aplicar. Si usted
está involucrado en un proyecto ágil de 10 o menos miembros las directrices para
el uso de los paquetes de trabajo para desarrollar estructuras de desglose de
trabajo y redes criti- cal-vía de acceso no pueden ser apropiados. Sin embargo, la
mayor parte de las directrices son aplicables a todos los tipos y tamaños de los
TABLA 11.11 Quince directrices para organizar y dirigir un juego o conjunto

1. Contratar a los mejores que puedes encontrar.
2. Tratar a las personas como activos en lugar de los costos.
3. Proporcionar un equilibrio entre la especialización laboral y la variedad de empleos.
4. Mantener a los miembros del equipo juntos.
5. Limitar el tamaño del equipo.
6. Diferenciar el papel de líder del equipo.
7. Hacer que el líder del equipo agente de control de la calidad del equipo.
8. Descomponer las tareas en unidades manejables de trabajo.
9. Utilizar un enfoque de onda de laminación aumentada para la planificación.
10. Adoptar un modelo contractual negociado para la asignación de tareas.
11. los objetivos de rendimiento establecidos para el equipo y para cada miembro del
equipo.
12. Asegurar el contacto diario entre los miembros del equipo.
13. Llevar a cabo reuniones semanales de revisión de estado.
14. Estructurar proyectos grandes como pequeñas colecciones de proyectos altamente
cohesivos, de forma flexible.
15. Recuerde que las organizaciones no son nada más que los individuos y grupos de
individuos.
No se deje engañar por los 15 pasos fáciles a los conjuntos. Las directrices que
se presentan aquí son de ninguna manera completa o integrales, ni son infalibles.
No hay leyes físicas o teorías matemáticas para la construcción y el
mantenimiento de los equipos de ingeniería cerámica blandos cohesivos.
habilidades interpersonales y la buena voluntad son ingredientes clave de los
equipos de éxito. Las buenas intenciones, solos, no son suficientes. Las técnicas
www.it-ebooks.info
de pre-tantes en esta sección, cuando se aplica con el sentido común y dentro de
una organización de apoyo puede producir resultados satisfactorios.
www.it-ebooks.info
• La cultura corporativa se compone de los patrones de creencias, valores y

conductas que existen dentro de una organización.
• Una declaración de misión define los propósitos y objetivos de una
organización.
• Una declaración de visión tiene objetivos específicos y un calendario para su
consecución.
• Los activos principales de una organización de software son las habilidades
y capacidades de los gestores de proyectos, los jefes de equipo, los
desarrolladores de software, y otro personal de software.
• La primera regla de negocio es la gestión de activos de la empresa para
maximizar el retorno de la inversión en estos activos; La segunda regla es
para controlar los costos. Por desgracia, muchas organizaciones de software
confunden la segunda regla con el primero y tratan a sus ingenieros de
software como los costos en lugar de activos.
• Su personal clave son aquellos miembros del proyecto que se asignan
responsabilidades y se les da la autoridad para llevar a cabo estas tareas por
usted, el director del proyecto.
• Las responsabilidades son (o deberían ser) documentados en las
descripciones de trabajo. La autoridad es el poder de tomar las decisiones
que se deben hacer en el cumplimiento de uno de responsabilidades y el
poder para aplicar estas decisiones.
• Debe solicitar autorización; responsabilidad no puede.
• Las 15 directrices para organizar y dirigir equipos de ingeniería de software
son de ninguna manera completa o integrales, ni son infalibles. No hay leyes
físicas o teorías matemáticas para la construcción y el mantenimiento de los
equipos de ingeniería de software cohesivos.
• Sin embargo, las directrices 15, cuando se aplica con sentido común y dentro
de una organización de apoyo, pueden producir resultados satisfactorios.
Referencias
[Baker72] Baker, FT Jefe gestión del equipo programador de la programación

estructurada.
IBM Systems Journal. 11 (1):. 1972, pp 56-73.
[Boehm89] Boehm, BW Software de Gestión de Riesgos: Tutorial. Computer Society Press,
1989.
[Brooks87] Brooks, FW Sin balas de plata: Esencia y accidentes de software
Ingenieria.
IEEE Computer (abril de 1987). 20 (4), pp. 10-19.
[CMMI06] SEI. CMMI® Modelos y Módulos. http://www.sei.cmu.edu/cmmi/models/, 2006.
[Conway68] Conway, M. ¿Cómo inventar comités? Datamation (Abril): 1968. 14 (2), pp.
28-31.
[DeMarco82] DeMarco, T. Control de los proyectos de software. Yourdon Press,
1982. [DeMarco99] Demarco, T. y T. Lister. Peopleware. Dorset Publishing, 1999.
[Fairley05] Fairley, RE, y MJ Willshire. retrabajo iterativo en el desarrollo de software: El
bueno, el malo y el feo. IEEE Computer (septiembre de 2005). 38 (9), pp.
34-41.
www.it-ebooks.info
CEREMONIAS 465
[Fairley93] Fairley, RE, organizar y dirigir equipos de ingeniería de software. Perspectivas

internacionales en Ingeniería de Software. Rocky Mountain Institute de la
Cesión de Software Engineering, 1993.
[Hardgr05] Hardgrave, BC, y DJ Armstrong. la mejora de procesos de software: Es un
viaje, no un destino. Comunicación de la ACM. Vol. 48, No. 1, noviem-
bre, 2005. pp. 219-228.
[IEEE1058] IEEE Std 1058TM-1998. Norma IEEE para los planes de gestión de
[Katzen93] Katzenbach, JR, y DK Smith. La sabiduría de Equipos: La creación de la
Organización de alto rendimiento. Harper Collins, 2003.
[Mach13] Maquiavelo, N. El príncipe. Clásicos Bantam. 1984.
[Stewart97] Stewart, T. Capital intelectual. Doubleday Publishing, 1997.
[Webb03] Webb, A. Utilizando valor ganado. Guía de un director de proyecto. Gower
Publishing, 2003.
CEREMONIAS
11.1. Brevemente resumir las formas en que cada uno de los factores culturales
en la tabla 11.1 se aplica a su escuela o ambiente de trabajo.
11.2. Encuentra las declaraciones de misión y visión para su escuela o su
organiza- ción del trabajo. copiarlos en su respuesta para este ejercicio y
brevemente indicar cómo su organización escolar o laboral hace o no se
adhiere a la declaración de la misión y la declaración de visión.
Proporcionar algunos ejemplos.
11.3. El término “personal esencial” se utiliza en la Tabla 11.2. Explique
brevemente su comprensión de la diferencia entre “personal esencial” y
“personal no esencial.”
11.4. Proporcionar otro ejemplo, además de los de la Tabla 11.2, de una medida
que podría utilizarse para evaluar el nivel de innovación en una
organización de software. Explica brevemente.
11.5. Enumerar y explicar brevemente cinco responsabilidades de un software de
oper desa- individuales, similares a las de las Tablas 11.4 y 11.5.
11.6. La diferencia entre la responsabilidad y la autoridad se explica en la Sección
11.5.
a. Proporcionar y explicar brevemente una situación que ha experimentado u
observado en su vida personal o profesional por la que la autoridad era o es
com- realizó medición con responsabilidad.
www.it-ebooks.info
b. Proporcionar y explicar brevemente una situación que ha experimentado

u observado en su vida personal o profesional por la que la autoridad era
o no es com- realizó medición con responsabilidad.
11.7. Al final de la Sección 11.6 se afirma: “Si el proyecto se muestra en la Tabla
11.7 es una pequeña, todos los miembros del proyecto, excepto Joe, puede
ser ejecutores de software, además de sus otras funciones.”
a. Explique brevemente por qué Joe se excluye de ser un implementador de
software.
b. Explicar brevemente cómo podría organizarse un pequeño proyecto para
que Joe podría ser un implementador de software.
11.8. Proporcionar un ejemplo de un factor de riesgo que no se puede manejar a
nivel de equipo. Explica brevemente. Proporcionar un ejemplo de un factor
de riesgo que podría ser, pero no debe ser, manejado a nivel de equipo.
Explica brevemente.
11.9. Para las 15 directrices que figuran en la Tabla 11.11,
a. Enumerar las que usted cree que sería más fácil para una organización de
software para implementar. Brevemente explique su razonamiento.
b. Enumerar las que usted cree que sería más difícil para una organización
de software para implementar. Brevemente explique su razonamiento.
www.it-ebooks.info
APÉNDICE 11A

para las cuestiones de
organización
11A.1 LA CMMI-DEV-v1.2 marco de proceso
Como se indica en el sitio web de SEI, la Madurez de Capacidades Model®

Integración (CMMI) fue desarrollado por el Instituto de Ingeniería de Software
de la Universidad Carnegie Mellon
... mejora del proceso guía a través de un proyecto, una división o una organización
entera. CMMI ayuda a integrar funciones de organización tradicionalmente
independientes, objetivos y prioridades de mejora de procesos conjunto,
proporcionan una guía para los procesos de calidad, y proporcionar un punto de
referencia para evaluar los procesos actuales.
(ver http://www.sei.cmu.edu/cmmi/general/general.html).
Las áreas de proceso de nivel 2 en la representación por etapas de CMMI-DEV-
v1.2 tienen que ver con los procesos que se aplican a los proyectos individuales. Los
2 procesos de nivel se enumeran en la Tabla 11A.1 [CMMI06]. Es posible que todos
los proyectos de su organiza- ción a estar en el nivel 2, pero para cada proyecto para
lograr los objetivos de los procesos enumerados en la Tabla 11A.1 de diferentes
maneras. Por ejemplo, diferentes proyectos podrían alcanzar los objetivos de gestión
de la configuración utilizando diferentes métodos y herramientas.
En el nivel 3 de la representación por etapas, todos los procesos de nivel 2 y de
los procesos de nivel 3 se llevan a cabo de manera uniforme en toda la
organización. Nivel 3 procesos incluyen los procesos de desarrollo de proyectos
y procesos individuales que se aplican a nivel de organización. Los procesos de
software y sistemas de desarrollos ción son, o deberían ser adaptados a partir de
un marco común de los procesos dentro de su organización que satisfagan los
objetivos de los procesos de nivel 2 y nivel 3. Las áreas de proceso de nivel 3 que
se aplican a los proyectos individuales se enumeran en la Tabla 11A.2; las que se
aplican a nivel de organización se enumeran en la Tabla 11A.3.
El proceso de formación organización tiene la intención de promulgar los
procesos de organización en toda la organización, así como para proporcionar la
comprensión de los métodos, herramientas y técnicas para todos los niveles 2 y 3
procesos a todos los proyectos
www.it-ebooks.info
467
www.it-ebooks.info
áreas nivel 2 proceso de la tabla 11A.1 CMMI-DEV-v1.2

• Planificación de proyectos
• gestión de acuerdo con el proveedor
• Medición y análisis
• Proceso y aseguramiento de la calidad del producto
• gestión de la configuración
TABLA 11A.2 CMMI-DEV-v1.2 áreas de nivel 3 del proceso para proyectos

• requisitos desarrollo
• Solución técnica
• La integración de productos
• Verificación
• Validación
TABLA nivel 11A.3 CMMI-DEV-v1.2 3 áreas de proceso de organización

• enfoque proceso de organización
• Organizacional de definición de procesos + IPPD
• formación organización
• La gestión integrada de proyecto + IPPD
miembros en todos los proyectos. La gestión integrada de proyecto asegura que

todos los proyectos son administrados para satisfacer los objetivos del proyecto y
los objetivos de la organización de una manera uniforme. IPPD (proceso de
integración y desarrollo de productos) se incluye para proyectos que implican
coordinados de software y sistemas de desarrollo. Tenga en cuenta que manage-
ment riesgo aparece tanto en el ámbito del proyecto y el nivel de organización.
Los factores de riesgo que no se pueden manejar a nivel de proyecto y factores de
riesgo que tienen el potencial de afectar negativamente a toda la organización se
manejan a nivel de organización.
Los niveles 4 y 5 en la representación por etapas de los marcos de procesos
CMMI tienen que ver con la recopilación de datos uniforme en todos los
proyectos de su organización con el fin de:
• identificar las áreas que necesitan mejoras,

• hacer mejoras en los procesos y la tecnología, y
• evaluar el impacto de los esfuerzos de mejora.
Los procesos de nivel 4 y nivel 5 se enumeran en la Tabla 11A.4.

Nivel 4 se denomina gestionado cuantitativamente, lo que denota el uso de
uniforme recogido, informó, y la métrica en todos los proyectos en la
organización validada; por lo tanto, los dos procesos a nivel 4: rendimiento de los
procesos de organización y gestión cuantitativa del proyecto. Tenga en cuenta
que el nivel 5 se denomina optimización y no
www.it-ebooks.info
11A.2 ISO Y IEEE NORMAS 12207 469
TABLA 11A.4 niveles CMMI-DEV-v1.2 4 y 5 procesos

Nivel 4: consiguió cuantitativamente procesos • el rendimiento del proceso
Organización
• gestión de proyectos cuantitativa
Nivel 5: optimización procesos • La innovación organizativa
• análisis y resolución Causal
optimizado. La optimización se pretende dar a entender que las mejoras en la

productividad, calidad, y la satisfacción del cliente son siempre posibles. Como a
menudo se ha dicho, el camino de la mejora de procesos es más importante que el
destino de lograr un nivel de madurez cular par- [Hardgr05].
11A.2 ISO Y IEEE NORMAS 12207
Las normas 12207 para los procesos del ciclo de vida del software cubren cinco
áreas de la vida primaria del proceso del ciclo, ocho procesos de apoyo, y cuatro
procesos de organización [IEEE12207]. Los procesos del ciclo de vida primarios
son:
• adquisición,
• suministro,
• desarrollo,
• operación, y
• mantenimiento.
Los ocho soporte a las zonas de proceso son:
• documentación,
• gestión de la configuración,
• seguro de calidad,
• verificación,
• validación,
• revisiones conjuntas,
• auditorías, y
Los procesos de organización son el
• administración,
• infraestructura,
• mejora y
• los procesos de formación.
Estos procesos se integran los procesos de clientes y proveedores a nivel de

proyectos indivi- indi- como a nivel organizativo de cliente y proveedor.
www.it-ebooks.info
Las secciones principales (cláusulas) de la norma IEEE 1058 para proyectos de

software manage- planes Ment (SPMPs) incluyen [IEEE1058]:
• organización del proyecto,

• planes de procesos de gestión,
• planes de procesos técnicos,
• el apoyo a planes de proceso, y
• planes de proceso adicionales.
Como se explica en el capítulo 4, e hizo hincapié en todo este texto, el plan del
proyecto para cada proyecto debe adaptarse partir de una plantilla de
organización estándar para los planes del proyecto, que podría estar basado en
IEEE 1058.
Sección I de la Dirección de Proyectos del Conocimiento, 3ª ed. (Guía del

PMBOK®) cubre el marco de la gestión de proyectos [PMI04]. Sección I incluye
el capítulo 1 (Introducción) y el capítulo 2 (Ciclo de Vida del Proyecto y
Organización). Sección 1.5.5 del PMBOK cubre las habilidades interpersonales.
Temas mencionados incluyen:
• comunicación efectiva,
• que influyen en la organización,
• liderazgo,
• motivación,
• negociación y gestión de conflictos, y
Los temas presentados en el capítulo 2 del PMBOK incluyen:
• influencias de organización,
• sistemas de organización,
• culturas y estilos de organización,
• estructura organizativa,
• el rol de la PMO (Project Management Office) en las estructuras
organizativas, y
• el sistema de gestión de proyectos.
www.it-ebooks.info
GLOSARIO DE TÉRMINOS
Véase también el Apéndice B del Capítulo 9 para las definiciones de términos

específicos para arriesgar management. Los términos en cursiva se definen en
este glosario.
Adquiridor La persona u organización que es el principal punto de contacto
entre un proveedor y un cliente en una situación contractual. Véase también
Contrato.
Actividad Un elemento de trabajo en un proyecto de software; actividades de
nivel superior se descomponen en las actividades y tareas subordinadas.
Asignación El proceso de parcelación un presupuesto monetario, un presupuesto de
tecnología, requisitos del sistema, los requisitos de software, esfuerzo o cualquier otra
cantidad que se puede subdividir y asignado a los elementos de un proceso o un
sistema.
Ver la arquitectura de la descomposición (ADV) Una visión jerárquica de los
elementos de una arquitectura de software. Cada elemento de una ADV es
nombrado usando un sustantivo para referirse a la naturaleza orientada al
producto de un ADV. Ver también la estructura del proyecto.
Suposición Una condición aceptada como verdadera, pero que no se puede
verificar en el momento actual o el que sería demasiado caro para verificar en
el momento actual.
Autoridad El poder de hacer y poner en práctica las decisiones que se deben hacer
para cumplir con las responsabilidades de uno.
retrabajo evitables Trabajo que, en principio, no debería tener que hacer para un
producto de trabajo baselined. Véase también la línea de base, retrabajo retrospectivo,
y retrabajo correctiva.
Base Un producto de trabajo que ha satisfecho sus criterios de aceptación
predeterminados y se ha colocado bajo control de versiones. Las líneas de base
proporcionan la base para el trabajo futuro durante el desarrollo y
mantenimiento de software. Sinónimo de Base-alineados producto de trabajo.
producto de trabajo baselined Un producto de trabajo que ha satisfecho sus
criterios de aceptación predeterminados y se ha colocado bajo control de
versiones; una obra baselined
www.it-ebooks.info
La gestión y dirección de proyectos de software, Por Richard
E. Fairley Copyright © 2009 IEEE Computer Society
471
www.it-ebooks.info
472 GLOSARIO DE TÉRMINOS
producto puede ser cambiada solamente si el cambio es en respuesta a un cambio

aprobado solicitud o informe de defectos. Sinónimo de línea de base.
seguimiento binaria La práctica de contar los productos de trabajo como 0% de
avance hasta que cumplan sus criterios de aceptación predeterminados; A
continuación, se cuentan como 100% completo.
tablero de control de cambios (CCB) Las partes interesadas que aprueban las bases de
referencia iniciales y de control baselined productos de trabajo. Véase también la
solicitud de cambio y el informe de defectos.
Solicitud de Cambio (CR) Una solicitud documentada para cambiar un producto
de trabajo baselined debido a factores externos tales como un cambio en los
requisitos o un cambio a una interfaz de hardware o software. Véase también
el informe de defectos.
COCOMO Modelo de costes constructivos; acrónimo de una familia de modelos
de estimación. La fecha de finalización fecha del calendario en el que los
elementos de software de un sistema intensivo en software deben estar listos para
su entrega a un cliente o listos para la integración
en un sistema.
gestión de la configuración (CM) Los y los mecanismos de proceso utilizado para
realizar un seguimiento y control de la línea base los productos de trabajo. Ver
también cambiar la tarjeta de control.
Restricción Una de las limitaciones impuestas por los agentes externos sobre parte o la
totalidad del dominio operativo, los requisitos operacionales, los requisitos de
software, el alcance del proyecto, presupuesto monetario, presupuesto de tecnología,
recursos, fecha de finalización, y la tecnología de la plataforma.
Contrato Una declaración de entendimiento entre dos o más partes. Un contrato
puede ser informal o legalmente vinculante (es decir, formal). Ver también
adquiriente, Memo de entendimiento, y la declaración de trabajo.
retrabajo correctiva El trabajo realizado en respuesta a un informe de defectos de un
producto de trabajo baselined. Ver también retrabajo, retrabajo evitable, retrabajo
evolutiva, y la reanudación retrospectivo.
Crisis Un evento que se detiene o impide el progreso serio.
Camino critico Un camino más corto a través de una red del
cronograma.
método del camino crítico (CPM) El proceso de determinar el conjunto de (uno
o más) trayectos más largos a través de una red del cronograma. Ver también
PERT.
Cliente (1) La persona u organización que especifica las exigencias operacionales de
las limitaciones y en el desarrollo de un sistema de software, proporciona el
presupuesto monetario, y acepta los productos de trabajo entregables de un
adquirente o un proveedor. (2) La persona u organización que evalúa un producto
de software y lo compra a un vendedor para uno o más usuarios; el cliente puede o
no puede ser un usuario.
Defecto Un defecto en un producto de trabajo que hace que sea incorrecta,
incompleta, y / o inconsistente. Véase también error y fracaso.
informe de defectos (DR) Un informe documentado de un defecto que se ha
encontrado en una
producto de trabajo baselined. Véase también la solicitud
de cambio.
técnica Delphi Una técnica de estimación iterativo que se basa en los juicios de
múltiples expertos; las estimaciones de cada experto se proporcionan de forma
www.it-ebooks.info
individual, en forma aislada de los otros expertos.
requisito derivado (1) Una elaboración de una exigencia principal; (2) un requisito
de software añadido para apoyar una exigencia principal.
www.it-ebooks.info
GLOSARIO DE TÉRMINOS 473
Diseño El proceso de síntesis de un sistema que optimiza criterios de diseño

específicos al tiempo que satisface las restricciones especificadas.
Fase de desarrollo Un conjunto de tareas relacionadas que producen una o más pro-
ductos de trabajo. fases de desarrollo pueden ser intercalados, se superponen, y
iterado según lo especificado por el proceso de desarrollo que se utiliza.
Proceso de desarrollo El proceso técnico utilizado para desarrollar los elementos de
software de un sistema de software intensivo; Los ejemplos incluyen la cascada,
incremental y construcción, ágil, evolutiva, y los procesos de desarrollo en espiral.
Equipo de desarrollo Un pequeño grupo de individuos (de 3 a 5 personas) más
un jefe de equipo que se encarga de elaborar o modificar parte o tal vez toda la
elementos de software de un sistema de software intensivo. Ver también Equipo de
proyecto.
La tecnología de dominio La base tecnológica del dominio operacional.
Valor agregado Valor acumulado del presupuesto monetario asignado para todas las
tareas
terminado. Ver también Asignación y seguimiento binario.
seguimiento del valor ganado Los procesos de valor (1) comparar ganado al coste
real del trabajo realizado y (2) comparar el valor obtenido con el costo
presupuestado del trabajo programado. Véase la Tabla 8.9 para la terminología y
los cálculos de seguimiento del valor ganado.
Eficacia Las características de un proceso que facilitan la incorporación de
atributos deseados en los productos de trabajo resultantes. Ver también la
eficiencia.
Eficiencia Las características de un proceso que faciliten el desarrollo de los
productos de trabajo correspondientes ciaciones sin perder tiempo, esfuerzo,
o de otros recursos. Ver también Eficacia.
Esfuerzo Una medida del trabajo calcula como el producto del tiempo la gente
; por lo general se mide en unidades de días-persona-persona, semanas,
meses-persona, o personas-año.
Sistema Integrado Un sistema de contenido dentro de otro sistema, como en el caso
de uno o más dispositivos digitales y el software asociado incrustado en un
sistema más grande, como un avión o un reproductor de DVD. Véase también
sistema de software de uso intensivo.
Error Un error humano que resulta en un defecto de software. Ver también
fracaso.
retrabajo evolutiva El trabajo realizado en respuesta a una solicitud de cambio
aprobado para un producto de trabajo baselined. Véase también la gestión de la
configuración y cambio tablero de control.
medida de tamaño externo (ESM) Una medida de software determinó contando el
número de entradas únicas, salidas e interfaces pasivas para el software ele-
mentos de un sistema de software intensivo. Véase también la función de punto.
Fracaso Una situación que, cuando se encuentran en funcionamiento, hace que un
sistema intensivo en software incapaz de producir la respuesta deseada, que se
espera, o requerido. Ver también defectos y errores.
Fan-in El número de tareas que preceden inmediatamente a otra tarea en una red del
cronograma.
Fan-out (1) El número de tareas que tienen éxito inmediato otra tarea en una red del
cronograma; (2) el número de actividades o tareas que emanan de otra actividad
en una estructura de división del trabajo.
www.it-ebooks.info
Requerimiento funcional Una característica de un sistema de software intensivo

típicamente especifica como un par de entrada / respuesta. Véase también la necesidad
operacional, Requisitos del sistema, requisitos de software, y el atributo de calidad.
Punto de función Una medida de software determinó mediante la aplicación de
reglas de conteo bien definidos para determinar el número de entradas únicas,
salidas, archivos, consultas y caras inter en los elementos de software de un
sistema de software intensivo.
diagrama de Gantt (1) Un gráfico de tarea-Gantt es un gráfico que indica el
tiempo en el que está previsto cada tarea en un proyecto de software que
ocurra; (2) una tabla de recurso-Gantt es un gráfico que indica cuándo será
necesario un recurso en particular para llevar a cabo algunas de las tareas en la
programación del proyecto.
Gol Una declaración de intenciones no cuantificada o resultado deseado. Ver
también
Objetivo.
Guía Una declaración pragmática de una práctica que se ha encontrado para ser
eficaz en situaciones prácticas.
Análisis de impacto El proceso de evaluación de la necesidad y haciendo necesaria
cambios de horario, presupuesto, los recursos, la tecnología y los factores de riesgo
acordes con los cambios en los requisitos baselined. Véase también la solicitud de
cambio y el producto del trabajo baselined.
Inspección Un proceso de revisión formal llevada a cabo por los equipos pequeños
(es decir, de 2 a 5 personas) con el fin de encontrar defectos en los productos de
trabajo. Ver también Tutorial.
El desarrollo iterativo El proceso por el cual un producto de trabajo en varias
ocasiones se elabo- clasificación de añadir valor al producto de trabajo durante
cada una de las iteraciones de desarrollo.
Medida (norte) Un símbolo que se asigna a un atributo de un meno meno en el
mundo real; el símbolo debe ser de un conjunto de símbolos para los que se
especifican operaciones bien definidas. Ver también Medición y Métricas.
Medida (v) Para asignar un símbolo a un fenómeno en el mundo real; el símbolo
debe ser de un conjunto de símbolos para los que se especifican operaciones
bien definidas. Ver también Medición y Métricas.
Medición El proceso de asignar algún atributo de un fenómeno del mundo real a un
símbolo dentro de un conjunto de símbolos para los que las operaciones sean bien
definidos manera especificada. Ver también Medir y métrica.
Memo de entendimiento (MOU) Especificación del alcance de las actividades de
trabajo que se lleva a cabo en un proyecto de software para un cliente interno; un
MOU es típicamente un contrato informal. Véase también la declaración de
trabajo.
Métrico Un término genérico usado para referirse a medida y la medición.
Hito Un tiempo especificado dentro de un cronograma del proyecto por el cual se
especifica el progreso
debe lograrse.
presupuesto monetario El dinero disponible para adquirir y pagar por el uso de
los recursos.
estimación de Monte Carlo Un método de estimación estadística que utiliza
muestras de distribuciones de probabilidad de entrada para producir
distribuciones de probabilidad de salida.
Objetivo Una declaración cuantificada de un resultado que se desea alcanzar en
www.it-ebooks.info
un plazo determinado. Véase también la meta.
dominio operativo Se utilizará el entorno en el que entregó el software.
www.it-ebooks.info
requisito operativo Una declaración de la necesidad, el deseo, expectativa, o la

restricción de un sistema de software intensivo especificada por un usuario, cliente,
comprador o cualquier otro participante.
gestión de oportunidades El proceso de evaluar las ganancias potenciales a
realizar y los factores de riesgo implicados, y estar preparado para tomar
ventaja de las situaciones, si el potencial de ganancias de superar el potencial
de pérdidas en el juicio de los participantes del proyecto. Véase también la gestión
de riesgos.
Trabajo original Esfuerzo realizado para desarrollar líneas de base iniciales de
productos de trabajo. VerTambién Vuelva a trabajar.
IMPERTINENTE Un método estadístico usado para determinar las
distribuciones de probabilidad para la consecución de diversos hitos en un
horario, incluyendo el hito fecha final. PERT es un acrónimo de Programa de
Evaluación y Revisión Técnica. Véase también método del camino crítico.
La tecnología de plataforma El conjunto de herramientas de software, entorno de
desarrollo, artículos de hardware y sistema operativo utilizados para producir o
modificar los elementos de software de un sistema de software intensivo.
Política Una declaración de principios generales que deben observarse en toda la
organiza- ción. Una política puede aplicarse a,, recursos humanos técnica de
gestión, u otros aspectos de una organización.
requisito principal Un requisito de software desarrollado directamente a partir de un
requisito funcional o un requisito del sistema. Ver requisito también Derivado.
Procedimiento Un conjunto de tareas a realizar en el cumplimiento de un
proceso. Ver también
Técnica.
Proceso Una forma de llevar a cabo una o más actividades de trabajo y tareas;
implica típicamente, los procedimientos y el uso de herramientas de software.
Ingeniería de Procesos El proceso de desarrollo y la mejora constante de los procesos de
ingeniería de software para hacerlos más eficientes y más eficaces.
Modelo de proceso Un modelo de uno o más elementos de un proyecto de software
que hace hincapié en las actividades de trabajo y el flujo de productos de trabajo
entre las actividades de trabajo.
proceso estándar Una colección especificada de procedimientos para llevar a cabo
una o más actividades de trabajo de un proyecto de software. Véase también
Proceso y Actividad.
marco de procesos Un modelo de proceso genérico que se puede adaptar y
adaptada para ajustarse a las necesidades de los proyectos y organizaciones
particulares.
Programa Una colección de proyectos, que suele implicar múltiples disciplinas
técnicas, relacionadas con el desarrollo de un sistema de software intensivo
complejo que consta de hardware, software y elementos de la gente. Diversos
tipos de elementos de hardware, además de los dispositivos digitales, pueden ser
incluidos.
Progreso Una medida de los productos del trabajo terminado, aceptó, y la línea base.
Proyecto Un grupo de actividades coordinadas de trabajo y las tareas que utiliza
recursos para lograr objetivos específicos dentro de un plazo establecido.
Gestión de proyectos El conjunto de actividades de trabajo relacionados con la
planificación y estimación, medición y control, coordinar y dirigir, y los factores
de riesgo ing manag- para un proyecto de software.
www.it-ebooks.info
Gerente de proyecto La persona que se encarga de llevar a cabo el proyecto agement

hombre- y para la entrega de elementos de software aceptables de un sistema de
software intensivo a tiempo y dentro del presupuesto monetario.
El riesgo del proyecto La colección agregada de los factores de riesgo
identificados para un proyecto de software.
Equipo de proyecto Las partes interesadas que están directamente involucrados
en el desarrollo o la modifi- ción de un sistema de software intensivo. Véase también
el equipo de desarrollo.
Seguro de calidad El proceso de asegurar que un proyecto de software está
cumpliendo sus compromisos con los procesos de software y productos de trabajo
planificadas como se especifica en los requisitos, plan de gestión de proyectos de
software, planes de apoyo y de las políticas, procedimientos, normas o directrices a las
que deben cumplir el proceso o el producto. Contraste de verificación y validación.
atributo de calidad Una característica deseable de un sistema de software intensivo;
atributos de calidad incluyen factores tales como la seguridad, la seguridad, fiabilidad
y facilidad de modifi- cación. Véase también la necesidad operacional, Requisitos del
sistema, requisitos de software, y el requisito funcional.
Recurso Cualquier activo utilizado en la formulación o modificación de los
elementos de software de un sistema de software intensivo; Los recursos incluyen
pero no se limitan a tiempo calendario,presupuesto monetario, presupuesto de
tecnología, El personal del proyecto, otras partes interesadas, software para ser
reutilizados, y la tecnología de la plataforma.
Responsabilidad La obligación de realizar las tareas asignadas y los deberes de
su puesto de trabajo en forma satisfactoria. Véase también Autoridad.
retrabajo retrospectiva El trabajo que se podría haber hecho antes y ahora se debe
hacer para modificar un producto de trabajo baselined. Ver también retrabajo,
retrabajo evitable,y retrabajo correctiva.
Rehacer El trabajo realizado para modificar un producto de trabajo baselined. Véase
también Evolución- retrabajo ary, retrabajo evitable, retrabajo retrospectivo, y
retrabajo correctiva.
Riesgo La colección agregada de los factores de riesgo para un proyecto de
software.
Riesgo de exposición El producto de la probabilidad potencial impacto de un
factor de riesgo.
Factor de riesgo Un problema potencial que, si se convierte en un verdadero
problema, inhibirá la capacidad de entregar elementos de software aceptables para
un sistema de software intensivo a tiempo y dentro de las limitaciones del
presupuesto monetario y / o el presupuesto de tecnología. Un factor de riesgo se
caracteriza por probabilidad y el impacto potencial.
Gestión de riesgos El proceso de identificación de los factores de riesgo, y el desarrollo e
implementación de estrategias de mitigación de riesgos sobre una base continua.
Véase también gestión de oportunidad.
las estrategias de mitigación de riesgos Diferentes enfoques para hacer frente a los
factores de riesgo identificados; estrategias incluyen la evitación, el traslado, la
aceptación, la acción inmediata, y la acción contingente.
Planificación ola de rodadura El proceso de desarrollar de forma iterativa planes
detallados sobre una base mensual.
Programar El plazo dentro del cual los elementos de software de un sistema de
software siva-intención deben ser construidos o modificados. Un horario tiene
típicamente hitos intermedios.
www.it-ebooks.info
la red del cronograma Un grafo dirigido acíclico que indica el orden en el tiempo
de la es-precedido por e-está seguido por las relaciones entre las tareas en un
proyecto de software.
Alcance La medida de todas las actividades de trabajo necesarios para desarrollar o
modificar los productos de trabajo de un proyecto de software.
Arquitecto de software El jefe de diseño de los elementos de software de un sistema
de software intensivo; también coordinador de las actividades técnicas de los
equipos de desarrollo de un proyecto de software.
Ingeniería de software La disciplina de la ingeniería ocupa de desarrollar y
modificar el software para dispositivos digitales.
sistema de software intensivo Un sistema que incluye uno o más dispositivos digitales
y el software asociado. sistemas intensivos en software incluyen productos de
software, sistemas de software y sistemas embebidos. Algunos sistemas intensivos en
software proyec- ECTS son parte de un programa; algunos son proyectos de sistemas
autónomos; otros son proyectos de software-solamente.
Sólo de software proyecto Un proyecto en cuestión con el desarrollo de software
para el que el hardware y el sistema operativo son proporcionados por un equipo
fuera de la plataforma, no se necesita ningún hardware de propósito especial, y no
se requiere entrenamiento especial para los usuarios, operadores o personal de
apoyo operativo. Requisitos de software para un proyecto de software sólo se
derivan de las necesidades operacionales. Véase también sistema de software de
uso intensivo.
Sólo de software del sistema Un sistema de software intensivo para los cuales hay
ningún hardware especial o elementos humanos; la tecnología de plataforma para
el desarrollo de un único sistema por software se puede especificar como una
limitación. Los sistemas de software de sólo son a menudo productos de software.
proceso de software Una colección de procedimientos realizados para desarrollar o
modificar el elementos de software de un sistema de software intensivo.
producto de software Software construido por un proveedor para la venta a los clientes
múltiples. Ver proyecto también sólo software.
plan de gestión de proyectos de software (PAPS) El documento de control para el
desa- oping o la modificación de un sistema de software intensivo.
requisito de software Una declaración que especifique un requisito funcional o un
atributo de calidad que un componente de software de un sistema de software
intensivo debe, debería o podría poseer para satisfacer las necesidades de
funcionamiento y requisitos del sistema. Requisitos de software incluyen requisitos
primarios, requisitos derivados, las restricciones de diseño y objetivos de diseño.
Véase también Objetivos.
Sistema de software Software construido por un proveedor para un cliente específico
sobre una base tual contracción. Véase también Contrato, sólo software proyecto,
producto de software, y el sistema de software intensivo.
sistema de software intensivo Un sistema que contiene uno o más dispositivos
digitales y software asociado; las necesidades de funcionamiento, requisitos del
sistema y con- straints para un sistema de software intensivo pueden especificar: (1)
los requisitos funcionales y atributos de calidad que el hardware, el software y los
elementos humanos del sistema deben poseer o (2) los requisitos operativos pueden
especificar limitaciones en la tecnología de la plataforma, además de los requisitos
funcionales y atributos de calidad
www.it-ebooks.info
para un sistema de sólo software. sistemas intensivos en software incluyen productos de

software, sistemas de software y sistemas embebidos.
Tenedor de apuestas Cualquier individuo que afecte o se vea afectado por el
desarrollo, operación o mantenimiento de un sistema de software intensivo. Las
partes interesadas incluyen a los usuarios, tomers cliente central, compradores,
gerentes, personal de proyectos de software, el personal de operaciones, personal
de mantenimiento, y otros.
Estándar Una codificación de las prácticas y procedimientos que por lo general
se desarrolla y respaldados por una sociedad profesional o agencia
independiente.
Declaración de trabajo (SOW) Una especificación del alcance de las actividades de
trabajo que se lleva a cabo en un proyecto de software para un cliente externo; la
cerda es típicamente parte de un contrato legalmente vinculante. Ver también
Memo de entendimiento.
Proveedor Una organización de desarrollo de software que desarrolla o modifica un
sistema de software o de los elementos de software de un sistema embebido para
un adquirente individuo sujeto a un contrato legalmente vinculante.
proceso de apoyar Un proceso que soporta la tarea de desarrollar y modificar los
productos de trabajo; procesos de soporte incluyen, pero no se limitan a la gestión de
configuración, control de calidad, verificación y validación.
Sistema Una colección de interactuar componentes que existen dentro e
interactúan con un entorno.
Requisitos del sistema Un documento que especifica los requisitos funcionales y
atributos de calidad de un sistema que incluye hardware, software, y (tal vez) el
personal de operaciones. Los requisitos del sistema se derivan de requisito
operacionalmentos; Requisitos de Softwarese derivan de requisitos operacionales
y requisitos del sistema.
Tarea (1) La unidad más pequeña de la rendición de cuentas en la gestión de un
proyecto de software; (2) una unidad de nivel más bajo de trabajo en una
estructura de división del trabajo. Ver también la actividad.
Equipo Un pequeño grupo de individuos (por lo general 2 a 5), además de un
jefe de equipo que trabajan de manera conjunta para lograr objetivos comunes.
la medición del rendimiento técnico (TPM) El proceso de comparación de
previsto que los valores reales de los parámetros técnicos, tales como el
rendimiento, uso de memoria, o el rendimiento del sistema.
Técnica La forma en que un individuo lleva a cabo un procedimiento; técnicas son a
menudo idiosincrásicas para el individuo.
presupuesto de tecnología La tecnología limitados disponibles para apoyar ción
¡Ejecución de programas informáticos; incluye restricciones en uno o más
factores como espacio de memoria, tiempo de ejecución, y el ancho de banda
de comunicación.
Matriz de trazabilidad Una tabla de dos dimensiones que indica las
correspondencias entre los elementos de dos productos de trabajo tales como los
requisitos operacionales y Requisitos de Software o los requisitos del sistema y los
planes de prueba asociados.
Usuario Un individuo (u otro sistema, como en el caso de un sistema embebido)
que va a utilizar un sistema de software intensivo para llevar a cabo su o su (o
sus) actividades de trabajo o el ejercicio de sus actividades recreativas.
Validación El proceso de determinar el grado en que los productos de trabajo
www.it-ebooks.info
satisfacen sus fines previstos en sus entornos destinados.
www.it-ebooks.info
Vendedor Una organización que construye un producto de software para su venta a

múltiples
clientes.
Verificación El proceso de determinar el grado en que los productos de trabajo
satisface las condiciones puestas en ellos por otros productos de trabajo y los
procesos de trabajo. Un producto de trabajo verificado es correcta, completa y
consistente con respecto a otros productos de trabajo y los procesos de trabajo.
Tutorial Un proceso de revisión llevado a cabo con el propósito de comunicar la
información entre un grupo de interesados en el proyecto. Ver también la
inspección.
estructura de desglose del trabajo (EDT) Una descomposición jerárquica de
las actividades de trabajo en un proyecto de software. Las actividades de nivel
más bajo en la jerarquía son tareas. Cada elemento de una EDT es nombrado
usando una frase verbal para indicar la naturaleza proceso- orientado de una
EDT. Véase también Arquitectura vista descomposición.
Paquete de trabajo Especificación de una tarea en una estructura de división del
trabajo. Paquetes de trabajo para las actividades son agregados de los paquetes de
trabajo para las actividades y tareas subordinadas.
Producto de trabajo Cualquier documento, ya sea en forma electrónica o
impresa, producida por un proyecto de software; productos de trabajo incluyen
el código fuente.
www.it-ebooks.info
Directrices para los proyectos PLAZO
INTRODUCCIÓN
En este apéndice se describen algunos proyectos para los que se pueden preparar
los planes de gestión de proyectos de software. También se incluyen son un
calendario para completar diversas secciones del plan, y una plantilla para el
informe final. Cada uno de los proyectos es lo suficientemente grande como para
ser interesante y lo suficientemente pequeño como para permitir la terminación
de un plan de proyecto en un curso de trimestre o semestre. Por ejemplo, los
proyectos aquí descritos requerirían del orden de 10 a 12 personas en un horario
de 10 a 12 meses; es decir, de 100 a 144 personas-mes de esfuerzo.
Los estudiantes a veces no entienden la naturaleza de un proyecto a largo
plazo en una clase de gestión de proyectos. Se debe enfatizar a los estudiantes
que el proyecto a largo plazo no implique el desarrollo de cualquier software,
sino que les obligará a desarrollar elementos de un plan para el desarrollo de
software. Un poco de creatividad se puede requerir de los estudiantes para
completar algunos elementos de sus planes de proyecto, por ejemplo, en la
descripción de la organización adquisición o el modelo de proceso de desarrollo
para ser utilizado. El instructor puede especificar algunos de los elementos de un
proyecto hipotético para los estudiantes que pueden no tener el fondo o la
experiencia para completar esos elementos.
También los estudiantes confunden en algún momento del desarrollo del
software para un sistema con el desarrollo de hardware y software. El proyecto a
largo plazo para un curso de gestión de proyectos de software debería
concentrarse en un plan para el desarrollo de software con la suposición de que el
hardware necesario y el entorno de desarrollo de software estarán disponibles.
Las posibilidades de proyectos a largo plazo distintos de los descritos aquí
incluyen proyectos reales que los estudiantes con experiencia de trabajo están
actualmente involucrados, han estado involucrados en, o se involucran en, así
como los proyectos asignados por los instructores de la clase. proyectos a largo
plazo

www.it-ebooks.info
481
www.it-ebooks.info
482 Directrices para los proyectos PLAZO
deben ser de tamaño suficiente como para justificar un esfuerzo de planificación

significativa, pero no tan grande como para prevenir el desarrollo de un plan
dentro de las limitaciones de un curso de la longitud del cuarto o semestre.
Aunque es una práctica común en los cursos de ingeniería de software para los
estudiantes para trabajar en equipos pequeños, se recomienda que los estudiantes
trabajan individualmente en la preparación de sus planes de proyecto para que
cada estudiante pueda adquirir experiencia en los artefactos que se preparan
como estructuras de desglose de trabajo, redes de horario, y el riesgo planes de
gestión.
El programa recomendado para la realización de proyectos a largo plazo
requiere entregas semanales de los estudiantes. Los capítulos del texto están
estructurados para que los instructores para cubrir el material necesario para
completar cada asignación semanal antes de la asignación. Los instructores
pueden proporcionar información sobre las entregas semanales y permitir a los
estudiantes revisen los entregables de una manera iterativa. informes finales estu-
diantes pueden contener los resultados integrados de los (tal vez revisada)
entregas semanales. Las siguientes secciones de esta guía se describen los temas
para los proyectos a largo plazo, un calendario para la preparación de los planes
del proyecto, y una plantilla para el informe final.
Orientaciones adicionales para proyectos a largo plazo, algunas herramientas
de software, y una versión electrónica de la plantilla de informe final se puede
encontrar en la URL que aparece en el prefacio de este texto.
Descripciones de proyectos
Plan de Proyecto para el Desarrollo de los elementos

de software de un cajero automático
La planificación de un proyecto de software para los elementos de software de un
cajero automático se utiliza como el ejemplo que se ejecuta en este texto. Un
proyecto a largo plazo implicaría aumentar la recolección y los diversos
elementos de la ATM ejemplo del texto para producir un plan de gestión de
Plan del Proyecto de Desarrollo de una aplicación basada en Web

Hay varios tipos de aplicaciones basadas en Web podrían servir de base para un
proyecto a largo plazo. Los ejemplos incluyen un servicio de alquiler de vídeos,
tales como el proporcionado por Netflix o Buster Block, o un sistema de punto de
venta para una gran cadena de tiendas al por menor, o un sistema de control de
inventario a nivel nacional para un distribuidor al por mayor. Otros ejemplos son
limitadas solamente por su imaginación.
Plan de Proyecto para el Desarrollo de los elementos de

software de una unidad programable de control Inicio
Una unidad programable de control de Inicio (HCU) integra de detección y
control de los diversos elementos de una casa o apartamento, incluyendo pero no
limitado a elementos tales como la seguridad, iluminación, cámaras web, sistema
de entretenimiento, electrodomésticos, calefacción y refrigeración, y el riego. La
HCU debe ser programable para permitir el control de elementos tales como el
sistema de calefacción y refrigeración (por zonas) y un sistema de seguridad
www.it-ebooks.info
(para
www.it-ebooks.info
Descripciones de proyectos 483
un número variable de dispositivos, control individual). Otros elementos un HCU

pueden controlar refrigerador y horno, un sistema de rociadores de césped (por
zonas) y el sistema de iluminación (por toma de corriente eléctrica). Un HCU
podría incluir el control del sistema de entretenimiento en el hogar (por
dispositivo individual), y cualquier otra cosa que desee incluir (por ejemplo,
persianas, apertura y cierre, distribución automática de alimentos para mascotas).
Un sistema HCU incluiría una interfaz de usuario que tiene la contraseña
modos protegidos de funcionamiento, incluyendo un modo de sistema de
configuración que permite a un técnico entrenado para ajustar los parámetros de
la instalación, un modo adulto, un modo de niño, y tal vez un modo de
vacaciones. El software incluye una red de área local para detectar y controlar
varios dispositivos, los controladores de dispositivos de software para los
dispositivos a ser detectados y controlados, y un paquete de comunicación para
proporcionar interfaces para una empresa de seguridad, a los departamentos de
bomberos y de la policía local, y para La Internet. En este último caso es posible
que, por ejemplo, llamar a su teléfono celular y dar instrucciones a su horno para
encender, o puede instruir a un robot para retirar una comida preparada de la
rador refrigeración y colocarlo en el horno. El abanico de posibilidades para un
HCU está limitado únicamente por su imaginación.
Plan de Proyecto para el Desarrollo de los elementos

de software de un sistema simulador de conducción
Un sistema simulador de conducción (DSS) se concibe como un simulador
realista que permita a los conductores a experimentar diversas situaciones de
conducción en un entorno simulado. El simulador consistiría en una cabina de
estudiante que contiene los elementos de un automóvil moderno (o camión o
autobús o coche de carreras). Un sistema de proyección en la cabina
proporcionaría frontal realista, lateral y vistas traseras. Un sistema de sonido en
la cabina proporcionaría sonidos realistas de conducción. La cabina se monta
sobre una plataforma hidráulica que simular la experiencia de conducción en
diferentes tipos de carreteras en diversos tipos de condiciones climáticas (por
ejemplo, normal, húmeda, resbaladiza, helado, nevoso, y condiciones de niebla).
Estación del instructor permitiría la creación, reproducción y seguimiento de
escenarios de conducción, así como la capacidad de crear obstáculos y otras
condiciones de emergencia durante los escenarios de conducción. Un repositorio
de datos contendría los escenarios de conducción y software para controlar el
sistema hidráulico, y proporcionaría la capacidad de almacenar y recuperar
secuencias de comandos, para retener los registros de rendimiento de los
estudiantes, y para generar diversos tipos de informes.
Su DSS podría tener varios modos de funcionamiento, por ejemplo, el modo
novato estudiante, estudiante avanzado modo, el modo de carrera de conducción, de
modo instructor, y el modo de financiar y diagnóstico nimiento. El plan del proyecto
debe incluir actividades de trabajo para verificar y validar que el sistema sea seguro,
fácil de usar y confiable.
Hardware para un DSS sería incluyen (1) los elementos de un simulador
realista, incluyendo las características habituales de un automóvil: puertas,
asiento, volante, parabrisas, ventana lateral, ventana trasera, pantallas de espejo,
los controles del tablero de instrumentos y los indicadores, sistema estéreo, y
cualquier otra cosa que desee incluir; (2) el hardware del sistema de proyección
en la cabina de los estudiantes; (3) un sistema hidráulico en el que se monta la
cabina estudiante; (4) La estación de trabajo del instructor; (5) el hardware
repositorio de datos; (6) una red de área local para apoyar la comunicación entre
www.it-ebooks.info
los diversos elementos del hardware; (7) el servidor de la LAN y los
componentes de software del DSS; y
(8) cualquier otro hardware necesario para el DSS.
www.it-ebooks.info
Se podría suponer que el hardware está disponible y proporciona las

capacidades necesarias. El proyecto a largo plazo sería el desarrollo de un plan de
gestión de proyectos para la construcción, modificación, y tal vez la compra
(algunos de) los elementos de software necesarias para un DSS.
Un calendario para proyectos a largo plazo
Este programa de ocho semanas es adecuado para una longitud del cuarto o clase
de talla semestre. Semana 1 del proyecto lo más probable es comenzar en la
semana 2 de la clase. El horario de ocho semanas también se da tiempo para que
el deslizamiento de las prestaciones en caso de que sea necesario o deseable
extender el horario para el proyecto a largo plazo.
Como se indica en los capítulos 4 y 5 del texto, los diversos elementos de un
plan de proyecto para un proyecto término estudiante se pueden preparar en
varios niveles de detalle; por ejemplo, la EDT puede ser parcialmente
descompuesta y algunos paquetes de trabajo preparado en lugar de hacer una
amplia descomposición de un WBS y preparación de paquetes de trabajo
extensas.
Semana 2 entregables (debido al final de la clase 2
semanas):
• Resumen del sistema

° una breve descripción del sistema que se
construirá
° principales características y atributos de calidad del
sistema
° modos de operación del sistema
Semana 3 entregables (debido al final de la semana de clase 3; ver los capítulos 2 y

3):
• una descripción de las clases de usuarios y otras partes interesadas

° clases de usuarios
° otras partes interesadas y sus necesidades
• un conjunto de requisitos operacionales
° dividido en subconjuntos de los requisitos esenciales, deseables, y
opcionales
° priorizado como E1, E2, ... D1, D2, ..., O1, O2, ...
• el modelo de desarrollo de software que se utilizará
° como Incremental-construcción, evolutiva, ágil
• el entorno de desarrollo de software que se utilizará
° como Unix, Windows, Eclipse
Semana 4 entregables (debido al final de la semana de clase 4, véase el capítulo 5):
• una estructura de desglose arquitectónico (ADV) con requerimientos

asignados
° en ambas formas gráficas e indentadas
Semana 5 entregables (debido al final de la semana de clase 5, véase el capítulo 5):
www.it-ebooks.info
• una estructura de desglose de trabajo (WBS) con requerimientos asignados
° en ambas formas gráficas e indentadas
www.it-ebooks.info
UN MODELO PARA INFORME FINAL 485
Semana 6 entregables (debido al final de la semana la clase 6; véase el capítulo

6):
• estimaciones del esfuerzo, el horario, y el costo de incluir una hoja de

cálculo resumen, una copia de los resultados de la estimación de hojas de
cálculo, y una tabla resumen de lo posible, el horario y el costo
Semana 7 entregables (debido al final de la semana de la Clase 7, véase el

capítulo 5):
• una red horario, un diagrama de hito, un diagrama de Gantt, y un perfil

personal
° preparada manualmente o utilizando una herramienta de software
(por ejemplo, Microsoft Project) Semana 8 entregables (debido al final de
la semana de clase 8; véase el capítulo 5):
• paquetes de trabajo para algunos elementos PEP
Semana 9 entregables (debido al final de la semana la clase 9; véase el capítulo

9):
• algunos factores de riesgo identificados para el proyecto previsto y una

estrategia de mitigación para cada uno
• el informe final
UN MODELO PARA INFORME FINAL
Portada
• para incluir el nombre y número del curso, el instructor, nombre del

proyecto, nombre del preparador, y la fecha de presentación
Abstracto
• finalidad prevista de este informe (como si se tratara de un proyecto real para

una empresa real)
• audiencia prevista para este informe
• Resumen de esfuerzo, horario, y el costo de este proyecto
Vista general del sistema [2 entregable la semana]:

Sección 1
1.1 breve descripción
1.2 características y atributos de calidad primaria
1.3 Modos de operacion
Sección 2: Los usuarios y otras partes interesadas [un entregable semana 3]

2.1 Clases de
usuarios 2.1.1
www.it-ebooks.info
2.1.2
etcétera
www.it-ebooks.info
2.2 Otras partes interesadas y sus objetivos

2.2.1
2.2.2
etcétera
Sección 3: Requisitos de funcionamiento [a entregar la
semana 3]
3.1 requisitos esenciales (prioritario)
3.2 requisitos deseables (priorizados)
3.3 Requisitos opcionales (priorizados)
Sección 4: Modelo de desarrollo y entorno de desarrollo [un entregable semana
3]
4.1 modelo de desarrollo de software que se utilizará
4.2 entorno de desarrollo de software para ser utilizado
Sección 5: estructura de desglose arquitectónico (ADV) con requerimientos
asignados [el entregables semana 4]
5.1 sangría ADV
5.2 gráfica ADV
Sección 6: estructura de desglose del trabajo (EDT) [entregable semana 5]
6.1 WBS sangría con los requisitos asignados
6.2 WBS gráficas con los requisitos asignados
Sección 7: Estimaciones [entregable semana 6]
7.1 Estimación hoja de resumen (como en la Figura 6.14)
7.2 hoja de cálculo de estimación
7.3 Cuadro resumen de esfuerzo detallada, horario y costo
Sección 8: Programación [entregable semana 7]
8.1 la red del cronograma
8.2 gráfico de Milestone
8.3 tabla de tareas-Gantt
8.4 Características del personal
Sección 9: Paquetes de trabajo [la semana 8
entregables]
9.1 Paquete de trabajo nº 1 [nombre]
9.2 Paquete de trabajo # 2
[nombre], etc.
Sección 10: Análisis de riesgos [el entregable semana
9]
10.1 factores de riesgo identificados y estrategias de mitigación
10.1.1 factor de riesgo # 1
[nombre]
Descripción Breve
estrategia de mitigación con la explicación
10.1.2 factor de riesgo # 2
[nombre]
Descripción Breve
estrategia de mitigación con la
explicación etc.
www.it-ebooks.info
ÍNDICE
Adquirente, ver los grupos de interés CMMI-DEV-v1.2, 22, 28, 79, 116, 125, 156,
Adquisición, 87 204, 262, 319, 336, 399, 433, 467
proceso de desarrollo ágil, 66 COCOMO, 238. Véase también la estimación
Asignación de comunicación, véase también el líder,
presupuesto, 141 equipos
requisitos, 80, 88 y trabajo en equipo, y Brooks
Arquitecto, 446 Ley de 5 capas modelo de
Arquitectura, 47 comportamiento, 427
Arquitectura descomposición View Complejidad
(ADV), 177 COCOMO CPLX, 296
retrabajo evitables, ver retrabajo acoplamiento y cohesión, 297
complejidad ciclomática, 294
Base, producto, 293
criterios de aceptación, 339, 342, software, 3
345, Concepto de Operaciones, 93
351 gestión de la configuración (CM), 141, 144,
cambiar la tarjeta de control (CCB), 146. Véase también Línea de base
107, 135. y procesos de apoyo
Ver también Procesos de Constraint, 9, 86, 102, 375. Ver también
apoyo de solicitud de cambio (CR), Requisito y el plan de
338, 347 contingencia del proyecto, 385. Véase
informe (DR), 338, 342, 347 de control de también el Riesgo
versiones defecto, 107. Ver también administración
Apoyando la gestión de riesgos continua, consulte
Procesos de Gestión de Riesgos
seguimiento binario, acuerdo contractual, 110
342 memorando de entendimiento (MOU), 122
Ley Brooks, 7 declaración de trabajo (SOW), 122
Controlar
Cambio bordo (CCB), 107 de control, 135. de los procesos de
Ver también procedimientos de trabajo, 333 de los
apoyo productos del trabajo,
Solicitud de Cambio (CR), 283 265
de flujo de trabajo de
procesamiento, 283
www.it-ebooks.info
487
www.it-ebooks.info
488 ÍNDICE
retrabajo correctiva, consulte retrabajo Los modelos basados en regresión,

La gestión de crisis, ver método de Gestión 234, 245
de Riesgos del camino crítico (CPM), 190. Modelo delgado, 231
Véase también plantilla para la grabación,
Horario y planificación 256 basado en la teoría,
de atención al cliente, consulte 230
los grupos de interés herramientas, 249
EDT / CPM / PERT, 229
Defecto El desarrollo evolutivo, 64 retrabajo
lista de comprobación, 324 evolutiva, véase retrabajo
proceso de detección y reparación, 304
matrices, 307, 341 Función, consulte Requisitos de
medir y analizar, 301 esfuerzo Fundamentos
relativo para fijar, 341 introducción a, 85
informe (DR), 284, 305 proceso, 86, 109
seguimiento, 307 producto, 86
frente al error, 301 Marcos, véanse también las Directrices,
estimación de Delphi, 227 normas y modelos de flujo de trabajo
requisito derivado, consulte los requisitos CMMI-DEV-v1.2, 22, 28, 79, 116, 125, 156,
de diseño, 204, 262, 319, 336, 399, 433, 467
restricción, 86, 91, 102 People CMM, 434
meta, 89, 101 software práctico y medición
medición y control de, 285 (PSM), 311, 321 del sistema
de un proceso de desarrollo iterativo, Panel de control del proyecto
72, 39 modelos de desarrollo (PCP), el software de gestión de
ágil, 66 proyectos del plan 353
evolutiva, 64 (PAPS), 119, 156, 173, 204
directrices para el desarrollo iterativo, espiral meta-modelo, de 69 años
71 piratería, 54 prestaciones técnicas de medición
incremental de construcción, 59 (TPM), 311, 387
iterativo, 58 Los puntos de función, 217. Véase también la
requisitos a código, 55 estimación requisito funcional, consulte
Scrum, 68 Requisitos
espiral meta-modelo, de 69 años
tradicional, de 54 años diagrama de Gantt, 138, 193, 199
cascada, 55 Glosario, 404, 471
Meta, consulte
seguimiento de ganado valor y Diseño
generación de informes, 347 Estimación, Directrices, 22. Ver también Marcos,
207 Normas y modelos de flujo de
calibración para, 244 trabajo, el diseño de una EDT, 182
modelos COCOMO, 238 proceso de desarrollo, 42
restricciones sobre, 214 estimación, 262
Delphi, 227 el desarrollo iterativo, 71
esfuerzo, costo, horario, 199 la gestionar y dirigir equipos, 449
estimación de estado futuro, 345 medición y control
medida de tamaño externo (ESM), los procesos de
220 puntos de función, 217 trabajo, 361
principios fundamentales del ciclo productos de trabajo,
de vida, 209, 249 319
Monte Carlo, 233, 244 organizacional, 467
de tamaño del producto, organizar y dirigir equipos de
216 PERT, 190 ingeniería de software, 449
técnicas pragmáticas, 222 Personal Software Process (PSP),
procedimiento para, 251 PMI Cuerpo de Conocimiento, 22, 37, 81,
118,
158, 206, 263, 321, 401, 434, 470
fundaciones de productos, 116
www.it-ebooks.info
la planificación del proyecto,
125, 156 técnicas de
planificación de proyectos,
204
www.it-ebooks.info
ÍNDICE 489
la gestión del riesgo, 399 software práctico y medición

desarrollo de software de modelos de (PSM), 311, 321 del sistema
procesos, 79 equipo de proceso de atributos del producto, 276
software (TSP), 436 trabajo en equipo y control de proyectos panel (PCP),
liderazgo, 407, 434 353 fiabilidad y disponibilidad, 302
proyectos a largo plazo, 481 esfuerzo retrabajo, 339
matrices de reproceso, 340
IEEE / EIA Standard 1058: estándar para el ajustes de las olas de rodadura, 313
software de gestión de planes de horario, 133, 137, 140, 156, 166, 334, 342,
proyecto, 22, 36, 81, 118, 158, 159, 345, 347
205, 263, 320, código de software, 293
400, 433, 470 la verificación y validación del sistema,
Incremental-construir el modelo de 299 casos de uso, 278
desarrollo, 59 de inspección, 289, 322 qué medir ?, ¿qué medida
ISO / IEC e IEEE / EIA 12207 procesos del ?, 269 268
ciclo de vida Standardfor Información los procesos de trabajo, 333
de Tecnología de Software, 22, 33, productos de trabajo, 265, 281,
80, 117, 157, 205, 263, 320, 400, 434, 287 de verificación y
469. Véase también la norma ISO / validación, 299
IEC e IEEE estándar EIA / 12207: Memo de entendimiento (MOU), 122.
2008 Sistemas y de Ingeniería de Véase también Acuerdo
Software-vida del software de los Contractual y Declaración de
procesos de ciclo. Trabajo
modelos de desarrollo iterativo, 58. Ver Milestone, 123, 141, 167
también Declaración de la misión, 443. Véase
Los modelos de desarrollo también la declaración de la
de diseño de, 72 visión
directrices para, de 71 años Mythical Man-Month, 1
la adaptación de, 82
El noventa y cinco por ciento síndrome
Líder, 407. Ver también equipos y trabajo en completo, 343
equipo puede no frente no lo hará, 418
moral y la motivación, 417 requisito operativo, consulte Requisitos
peopleware, 412, 436 cuestiones de organización, 439
estilos de personalidad, 420 evaluar el capital intelectual, activos
responsabilidades, 447 443, 380
frente a administración, 408 cultura corporativa, 441
capital intelectual, gestión
Medición y control, 270, 333 de riesgos conjunta 443,
especificaciones de diseño arquitectónico, 396, 444 personal clave
285, 342 de rastreo binaria declaración de la misión, 443
Las solicitudes de cambio (CR), la gestión del riesgo, 395
283 para escoger los instrumentos estructuras para proyectos de software, 16,
de productos, 309 informes de 19,
defectos (DR), 284 136
medidas directas, 273 declaración de visión, 443
valor ganado, 347
esfuerzo, 199, 336 Peopleware, 412, 436
directrices, 311 PERT, 190
implementación, 288 Planificación, 173
medidas indirectas, 273, 275 de proyectos ágiles, 128
integración y verificación, 298 y controlar el desarrollo iterativo, 71
medidas y medición, 270 hito, CMMI-DEV-v1.2 área de proceso de
123, 141, 167 planificación,
de defectos, 301 125
requisitos operativos y las especificaciones método del camino crítico (CPM), 190 el
técnicas, 276 desarrollo de la programación del
proyecto, 188
www.it-ebooks.info
490 ÍNDICE
La planificación (continuación) horario, 133, 137, 140, 156, 166, 334, 342,
el desarrollo de la estructura de 345, 347
desglose del trabajo, 183 ámbito de aplicación, 110, 123, 175
proyectos de construcción incremental, 153 sólo de software, 52
PERT, 190 equipo, 6, 19, 153, 407, 410. Véase también
planificación previa, 123 Líder, y los equipos y el modelo de
proceso, 121 flujo de trabajo en equipo, 13, 41, 120, 174,
ola de rodadura, 175, 454 210,
recursos diagrama de Gantt, 199 267
perfiles de recursos, 193 plan de gestión de proyectos, consulta
escenarios para, 176 planificación mínima, 129
horario, 133, 137, 140, 156, 166, 334, 342, la adaptación de, 150
345, 347 plantilla para, 131, 137, 144
alcance de, 123, 124, 175 Prototyping, 74
gráfico tarea-Gantt, 193
técnicas, 173 Calidad, consulta defectos y aseguramiento
bajo restricciones, 9, 86, 102 de la reanudación, 14, 29, 34, 148
paquete, 140, 165, 185, 339, 456 trabajos atributos, 89, 93, 95, 98
Planes, 119
esbozo anotado, 159 El análisis de
contingencia, 387 requerimientos, 96
una acción inmediata, 385 derivada, 100
proyecto, 129, 130, 149 restricción, 86, 91, 102 diseño
escenarios para el desarrollo, meta, 89, 97, 100 diseño
176 deseable, 95
plan de gestión de proyectos de desarrollo, 89
software (PAPS), 119, 156, ingeniería, 88
173, 204 esencial, 95
la adaptación de, 150 IEEE / EIA Estándar 830: Práctica
técnicas para preparar, 150 Recomendada para Requisitos de
plantilla para, 130, 157 software Especificaciones, 104
La tecnología de plataforma, 10 gestión, 106
PMI Cuerpo de Conocimiento, 22, 37, 81, operativa, 90, 97
118, opcional, 95
158, 206, 263, 321, 401, 435, 470 primario, 89, 97, 99
práctico software y medición (PSM), 311, priorizado, 179
321 del sistema problemas y ejemplos, 91
requisito principal, consulte Proceso de atributos de calidad, 89, 93, 95,
Requerimiento, consulta marcos, las 98
directrices, sistema, 46
Normas, y de gestión de técnico, 98, 104
flujo de trabajo, 137 trazabilidad, 105
modelos, 41, 58 casos de uso, el 94
de soporte, 14 validación, 91, 97, 105
la adaptación de, 52, 55, 65, 82, 150, verificación, 105
técnico, 143 retrabajo retrospectiva, ver comentarios
Los modelos de proceso, ver modelos de retrabajo, 293
desarrollo y modelos de flujo de Retrabajo, 336, 339
trabajo La gestión del riesgo, 363. Véase también
Proyecto, 2 el valor acumulado y medición del
limitaciones, 9, 375 panel rendimiento técnico
de control (PCP), 353 análisis y priorización, 381 supuestos y
plan de gestión, 119, 156, 173, 204 limitaciones, 375 acción contingente, 385
organización, 16, 19, 136
la gestión de riesgos, 363. Véase también
la gestión de riesgos
papeles, 448
www.it-ebooks.info
ÍNDICE 491
continua, 366 IEEE estándar EIA / 1540: Norma para la

que controlan el proceso, 392 Gestión del Ciclo de Vida del
técnicas convencionales, 369 Software Procesos-Riesgos, 402
la gestión de crisis, 394 ISO / IEC e IEEE / EIA 12207 procesos
la exposición, 364 del ciclo de vida Standardfor
factores, 143, 366 Información de Tecnología de
glosario, 404 Software, 22, 33,
técnicas de identificación, 373 IEEE / 80, 117, 157, 205, 263, 320, 400, 433,
EIA Standard 1540: Estándar para 469. Véase también la norma ISO /
Software de Gestión de Procesos del IEC e IEEE estándar EIA / 12207:
Ciclo de Vida-Riesgo, 402 2008 Sistemas y de Ingeniería de
una acción inmediata, 384 Software-vida del software de los
impacto, 363, 381 procesos de ciclo.
conjunta, 396 Declaración de Trabajo (SOW), 122.
factor de apalancamiento, 384 Véase también Acuerdo Contractual
pérdida, 363 y memorando de entendimiento
estrategias de mitigación, 382 revisiones del estado, 459
organizacional, 395 Estructuras para proyectos de software, 16,
visión general, 366 19,
registros de riesgo, 388 136
SEI taxonomía, 374 Proveedor, 29, 34, 44
técnicas, 372 procesos de apoyo, 145
seguimiento del riesgo-N gestión de la configuración (CM), 141,
superior, 388 incertidumbre, 372 144, 146
utilidad, 364 bordo (CCB), 107, 135 de control de
cambios
Lista, 133, 137, 140, 156, 166, 334, 342, documentación, 147
345, 347 garantía de calidad (QA), 14, 29, 34, 148
Ámbito de validación, 91, 97, 105
aplicación, 110, 123, verificación, 105
175 verificación y validación (V & V), 50,
adquisición de 147
software, 87 control de versiones, 107
ingeniero, 407 Sistema
sistema intensivo, 5, 41 flujo de trabajo de
gestión de procesos, 13, 41, 120, 174, 210, ingeniería, 41 requisitos y el
267 diseño de software, 46-
producto, 6 intensiva, 5, 41
plan de gestión de proyectos (PAPS), 119, sólo de software, 52
156, 173, 204
producto de trabajo, 14 Sastrería
Scrum, 68 el desarrollo iterativo, 65, 82
SLIM, 231 los planes del proyecto, 150
Espiral meta-modelo, requisitos a código, 55
de 69 años sistema de sistema de ingeniería, 52
Las partes interesadas, 43 cascada, 56
Normas, 10, 22. Véase también marcos, las Equipos y trabajo en equipo, 6, 19, 153, 407,
directrices y los modelos de flujo de 410.
trabajo Ver también
IEEE / EIA Estándar 830: Práctica peopleware principales, 412,
Recomendada para Requisitos de 436
software Especificaciones, 104 Team Software Process (TSP), 436
IEEE / EIA Standard 1058: estándar para el Medición del Desempeño Técnico
software de gestión de planes de (TPM), 311, 387
proyecto, 22, 36, 81, 118, 158, 159, proyectos a largo plazo, 481
205, 263, 320, matriz de trazabilidad, 105, 448
400, 433, 470
Incertidumbre, 372
www.it-ebooks.info
Los casos de uso, 278
www.it-ebooks.info
492 ÍNDICE
Usuario, ver los grupos de paquete, 140, 165, 185, 339, 456
interés utilitario, 364 producto, 14
Modelos de flujo de trabajo, véase también
Vendedor, 6 Marcos,
Verificación y validación, 50 de Guías y normas ágiles, 67
validación, 91, 97, 105 CCB, 107
verificación, solicitud de cambio, 282
105 Visión detección de defectos y
el mantenimiento de la visión de reparación, 304 de estimación,
proceso y producto, 21 210
declaración, 443. Véase también desarrollo evolutivo, 65
la declaración Misión construcción incremental, 60
inspección, 289, 323
Tutorial, 292 flujo de trabajo, 13, 41, 120, 174, 210
WBS, véase la estructura de desglose de proyecto,
trabajo Trabajo 267
estructura de desglose (WBS), 177, la gestión del riesgo, 393
179, proyectos de software de sólo
180, 182, 461 53, ingeniería de sistemas de
directrices para el diseño de una EDT, software, 41 Sprint, 69
182 cascada, 56
www.it-ebooks.info

Fair PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fair PDF

Cargado por

Copyright:

Formatos disponibles

www.it-ebooks.

Publicaciones IEEE Computer Society

IEEE Computer Society / Wiley Asociación

RICHARD E. (DICK) FAIRLEY

A John Wiley & Sons, INC., Publicación

Biblioteca del Congreso de datos de catalogación en publicación está

Impreso en los Estados Unidos de

Apéndice 1A: Marcos, estándares y directrices para la gestión de proyectos

2 Los modelos de proceso para Software Development39

Apéndice 2B: Consideraciones para la Selección un

3 Proyecto de establecimiento de Foundations85

4.7 Las técnicas para la preparación de un plan de proyecto, 150

5 Planificación de proyectos Techniques173

Apéndice 5A: Marcos, estándares y directrices para las técnicas de

7 Medir y controlar el trabajo Products265

7.3 ¿Por qué medir ?, 268

8 Medir y controlar el trabajo Processes333

8.6 Valor Ganado de informes, 347

9 Proyecto de gestión de Risk363

9A.4 El PMI Cuerpo de Conocimientos,

10 Equipos, trabajo en equipo, motivación, liderazgo, y Communication407

la gestión de un proyecto de programación informática es grande como la gestión de

Los que son, o van a convertirse en gestores de proyectos de software,

Condado de Teller, Richard E. (Dick) Fairley

En muchos aspectos, la gestión de un proyecto de programación informática es

1.1 INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS DE SOFTWARE

Cuando se convierte en (o quizás ya está) el encargado de un proyecto de

La gestión y dirección de proyectos de software, Por Richard E.

Estos son los temas principales de este texto.

1.2 OBJETIVOS DE ESTE CAPÍTULO

• ¿Por qué la gestión y dirección de proyectos de software es difícil,

Apéndice 1A a este capítulo se proporciona una introducción a los elementos de los

1.3 ¿POR ADMINISTRACIÓN Y PROYECTOS software líder es

Un proyecto es un conjunto de actividades coordinadas llevadas a cabo dentro de

• objetivos deben especificarse,

• actividades de trabajo coordinadas,

En un sentido específico, los métodos, herramientas y técnicas utilizadas para

1.3.1 La complejidad del software

de ser replicado. piezas de software tienen diferentes tipos de interacciones,

1.3.2 conformidad de software

1.3.3 Variabilidad de software

dad en systems.4 intensivos en software Dado que el software es el elemento

• qué productos de trabajo tendrá que ser cambiado?

El objetivo del análisis de impacto es determinar si un cambio propuesto es “de

1.3.4 La invisibilidad de software

no son el software. En el nivel más elemental, el software reside en el netization

1.3.5 Orientado al equipo, trabajo intelecto-intensivo

200 5) no son factibles debido a limitaciones de programación entre las

Adición de mano de obra para un proyecto de software hace que

la ley de Brooks se basa en tres factores:

la ley de Brooks no sería cierto si el trabajo asignado a los nuevos miembros no

líneas de la trama secundaria pueden ser intercalados. Una limitación importante

• si el equipo es pequeño, digamos cinco o seis miembros (para limitar la

En algunos casos, los miembros del equipo pueden trabajar en pares (

entender la naturaleza del producto deseado a entregar, se debe establecer una

1.4 La naturaleza de la limitaciones del proyecto

Muchos de los problemas que se encontrará, o haber tenido, en los proyectos de

TABLA 1.1 limitaciones típicas en los proyectos de software

eRate y comprobar el código, herramientas de control de versiones para realizar

1. ámbito de aplicación: el trabajo a realizar;

Se establece el equilibrio inicial entre estos factores en su plan inicial del

1. establecer los criterios de éxito para su proyecto,

Las restricciones deben aclararse para determinar si existe alguna flexibilidad