Gua de la Ingeniera de Software de

Administracin de Conocimiento

versin 3.0

SWEBOK

Un proyecto del IEEE Computer Society

 Gua de la Ingeniera de Software
de Administracin de
Conocimiento

versin 3.0

editores
Pierre Bourque, Escuela de Tecnologa Superior (ETS)
Richard E. (Dick) Fairley, Software e Ingeniera de Sistemas Asociados (S2EA)
Derechos de autor y reimpresin Permisos. Se permite el uso personal o educativo de este material sin costes prevista dichas
copias
1) No se hacen con fines de lucro o en lugar de la compra de copias para las clases, y que este aviso y una referencia completa
a la obra original aparecen en la primera pgina de la copia y 2) no implican IEEE respaldo de los productos o servicios de
terceros . El permiso para reproducir / a publicar este material para fines comerciales, publicidad o con fines promocionales o
para la creacin de nuevas obras colectivas para la reventa o redistribucin debe ser obtenido de IEEE por escrito a la Oficina
de Derechos de Propiedad Intelectual IEEE, 445 Hoes Lane, Piscataway, NJ 08854-4.141 [email protected].

La referencia a cualquier producto comercial especfico, proceso o servicio no implica reconocimiento alguno por el IEEE.
Los puntos de vista y opinio- nes expresadas en esta publicacin no reflejan necesariamente las de la IEEE.

IEEE pone este documento a disposicin tal cual y no hace ninguna garanta, expresa o implcita, en cuanto a la exactitud,
la du- capaci-, comerciabilidad eficiencia, o el funcionamiento de este documento. En ningn caso, IEEE ser responsable de
los daos generales, consecuentes, indirectos, incidentales, ejemplares o especiales, incluso si IEEE ha sido advertido de la
posibilidad de tales daos.

Copyright 2014 IEEE. Todos los derechos

reservados. Paperback ISBN-10: 0-7695-5166-1
Paperback ISBN-13: 978-0-7695-5166-1

copias digitales de Gua SWEBOK V3.0 se pueden descargar de forma gratuita para uso personal y acadmico a travs
www.swebok.org.

El personal IEEE Computer Society para esta publicacin

Angela Burgess, Director Ejecutivo
Anne Marie Kelly, Director Ejecutivo Asociado, Director de Gobierno Evan
M. Butterfield, Director de Productos y Servicios
John Keppler, Gerente Senior de Educacin Profesional
Kate Guillemette, Producto Editor Desarrollo
Dorian McClenahan, Programa de Educacin desarrollador del producto
Michelle Phon, Educacin Profesional y Coordinador del Programa de
Certificacin Jennie Zhu-Mai, diseador editorial

Productos IEEE Computer Society y Servicios. El IEEE Computer Society de renombre mundial publica, promueve y
distribuye los de una amplia variedad de revistas de ciencia e ingeniera equipo autorizado, revistas, actas de congresos y
productos de educacin profesional. Visite la Sociedad Informtica de lawww.computer.org para ms informacin.
 TABLA DE CONTENIDO

Forewordxvii
Prlogo a la Editionxix 2004
Editorsxxi
Coeditorsxxi
contribuyendo Editorsxxi
Cambio de control Boardxxi
rea de conocimiento Editorsxxiii
Editores rea de Conocimiento de Anterior SWEBOK Versionsxxv
revisin Teamxxvii
Acknowledgementsxxix
Junta actividades profesionales, 2013 Membershipxxix
Movimientos respecto a la aprobacin de la Gua SWEBOK V3.0xxx
Movimientos respecto a la aprobacin de la Gua SWEBOK 2004 Versinxxx
Introduccin a la Guidexxxi

Captulo 1: Software requisitos 1-1

1. Requisitos de software Fundamentals1-1
1.1. Definicin de un requisito de software 1-1
1.2. Requisitos del producto y de proceso 1-2
1.3. Requisitos funcionales y no funcionales 1-3
1.4. Propiedades emergentes 1-3
1.5. Requisitos cuantificables 1-3
1.6. Requisitos del sistema y requisitos de software 1-3
2. requisitos Process1-3
2.1. Los modelos de proceso 1-4
2.2. Los actores del proceso 1-4
2.3. Administracin y Apoyo Proceso 1-4
2.4. Proceso de Calidad y Mejora 1-4
3. requisitos Elicitation1-5
3.1. requisitos Fuentes 1-5
3.2. tcnicas de obtencin 1-6
4. requisitos Analysis1-7
4.1. requisitos Clasificacin 1-7
4.2. Modelado conceptual 1-8
4.3. Diseo y requisitos arquitectnicos Asignacin 1-9
4.4. requisitos de Negociacin 1-9
4.5. Anlisis formal 1-10
5. requisitos Specification1-10
5.1. Definicin del sistema de documentos 1-10
5.2. Requisitos del sistema Especificacin 1-10
5.3. Especificacin de Requerimientos de Software 1-11
6. requisitos Validation1-11
6.1. requisitos crticas 1-11
6.2. prototipado 1-12

v
 6.3. Modelo de validacin 1-12
6.4. Prueba de aceptacion 1-12
7. Considerations1-12 prctica
7.1. La naturaleza iterativa del proceso Requisitos 1-13
7.2. Gestin del cambio 1-13
7.3. requisitos Atributos 1-13
7.4. requisitos de rastreo 1-14
7.5. La medicin de Requisitos 1-14
8. Requisitos de software Tools1-14
Matriz de Temas vs. Referencia Material1-15

Captulo 2: Software Diseo 2-1

1. El software de diseo Fundamentals2-2
1.1. Conceptos generales de diseo 2-2
1.2. Contexto de Diseo de Software 2-2
1.3. Software de Diseo de Procesos 2-2
1.4. Principios de Diseo de Software 2-3
2. Aspectos crticos de software Design2-3
2.1. concurrencia 2-4
2.2. Control y manejo de Eventos 2-4
2.3. Persistencia de datos 2-4
2.4. Distribucin de Componentes 2-4
2.5. Error y control de excepciones y la tolerancia a fallos 2-4
2.6. Interaccin y Presentacin 2-4
2.7. Seguridad 2-4
3. Estructura del software y Architecture2-4
3.1. Las estructuras arquitectnicas y puntos de vista 2-5
3.2. Estilos arquitectnicos 2-5
3.3. Patrones de diseo 2-5
3.4. Las decisiones Arquitectura Diseo 2-5
3.5. Las familias de los programas y marcos 2-5
4. Interfaz de usuario Design2-5
4.1. Principios generales para el usuario el diseo de interfaces 2-6
4.2. Interfaz de usuario Problemas Diseo 2-6
4.3. El diseo de las modalidades de interaccin del usuario 2-6
4.4. El diseo de la informacin Presentacin 2-6
4.5. Proceso de Interfaz de usuario Diseo 2-7
4.6. Localizacin e internacionalizacin 2-7
4.7. Metforas y modelos conceptuales 2-7
5. Diseo Anlisis de Calidad de Software y Evaluation2-7
5.1. Los atributos de calidad 2-7
5.2. Anlisis de calidad y tcnicas de evaluacin 2-8
5.3. medidas 2-8
6. El software de diseo Notations2-8
6.1. Las descripciones estructurales (esttico Vista) 2-8
6.2. Las descripciones de comportamiento (vista dinmica) 2-9
7. Software de Diseo y Estrategias Methods2-10
7.1. Las estrategias generales 2-10
7.2. Funcin-Oriented (Estructurado) Diseo 2-10
7.3. Diseo Orientado a Objetos 2-10
 7.4. Estructura de Datos Diseo Centrado 2-10
7.5. Diseo basado en componentes (CDB) 2-10
7.6. Otros metodos 2-10
8. El software de diseo Tools2-11
Matriz de Temas vs. Referencia Material2-12

Captulo 3: Software Construccin 3-1

1. Construccin de Software Fundamentals3-1
1.1. Complejidad minimizando 3-3
1.2. pronstico del cambio 3-3
1.3. La construccin de Verificacin 3-3
1.4. Reutilizar 3-3
1.5. Normas de construccin 3-3
2. Gerente Construction3-4
2.1. Construccin de Modelos de Ciclo de Vida 3-4
2.2. Ordenacin de la Edificacin 3-4
2.3. Medicin de la construccin 3-4
3. Considerations3-5 prctica
3.1. Diseo de la construccin 3-5
3.2. Idiomas de construccin 3-5
3.3. Codificacin 3-6
3.4. Prueba de la construccin 3-6
3.5. Construccin de Reutilizacin 3-6
3.6. Construccin con reutilizacin 3-7
3.7. construccin de Calidad 3-7
3.8. Integracin 3-7
4. construccin Technologies3-8
4.1. Diseo y Uso de la API 3-8
4.2. Orientado a Objetos Problemas de tiempo de ejecucin 3-8
4.3. Parametrizacin y Genricos 3-8
4.4. Afirmaciones, Diseo por contrato, y la programacin defensiva 3-8
4.5. Control de errores, control de excepciones, y la tolerancia a fallos 3-9
4.6. ejecutable modelos 3-9
4.7. Las tcnicas de construccin basadas en tablas de base estatal y 3-9
4.8. Configuracin de tiempo de ejecucin y la internacionalizacin 3-10
4.9. Procesamiento de la entrada Gramtica-Basado 3-10
4.10. Las primitivas de concurrencia 3-10
4.11. middleware 3-10
4.12. Mtodos de construccin de software distribuido 3-11
4.13. La construccin de sistemas heterogneos 3-11
4.14. Anlisis de Rendimiento y ajuste 3-11
4.15. Normas de plataforma 3-11
4.16. Programacin Test-First 3-11
5. Construccin de Software Tools3-12
5.1. Entornos de desarrollo 3-12
5.2. Constructores GUI 3-12
5.3. Herramientas de prueba de unidad 3-12
5.4. Perfilado, anlisis de rendimiento, y cortar Herramientas 3-12
Matriz de Temas vs. Referencia Material3-13

Captulo 4: Software Pruebas 4-1

 1. Software de Pruebas Fundamentals4-3
1.1. Terminologa de pruebas relacionados 4-3
1.2. Cuestiones clave 4-3
1.3. Relacin de las pruebas a otras actividades 4-4
2. Levels4-5 prueba
2.1. El objetivo de la prueba 4-5
2.2. Objetivos de las Pruebas 4-5
3. Techniques4-7 prueba
3.1. Sobre la base de la intuicin y la experiencia del ingeniero de software 4-8
3.2. Las tcnicas basadas en el dominio de entrada 4-8
3.3. Tcnicas de cdigo-base 4-8
3.4. Tcnicas basada en la culpa 4-9
3.5. Tcnicas de uso-Basado 4-9
3.6. Tcnicas de ensayo basado en modelos 4-10
3.7. Las tcnicas basadas en la naturaleza de la aplicacin 4-10
3.8. La seleccin y la combinacin de tcnicas 4-11
4. Prueba relacionada Measures4-11
4.1. Evaluacin de la prueba el marco del Programa 4-11
4.2. La evaluacin de las pruebas realizadas 4-12
5. Process4-12 prueba
5.1. Consideraciones prcticas 4-13
5.2. Prueba Ocupaciones 4-14
6. Software de Pruebas Tools4-15
6.1. Pruebas herramienta de soporte 4-15
6.2. Categoras de Herramientas 4-15
Matriz de Temas vs. Referencia Material4-17

Captulo 5: Software Mantenimiento 5-1

1. El software de mantenimiento Fundamentals5-1
1.1. Definiciones y terminologa 5-1
1.2. Naturaleza de Mantenimiento 5-2
1.3. La necesidad de mantenimiento 5-3
1.4. La mayora de los costos de mantenimiento 5-3
1.5. Evolucin de Software 5-3
1.6. Categoras de Mantenimiento 5-3
2. Aspectos crticos de software Maintenance5-4
2.1. Tcnico Cuestiones 5-4
2.2. Asuntos Gerenciales 5-5
2.3. Estimacin de costes de mantenimiento 5-6
2.4. Medicin de mantenimiento de software 5-7
3. mantenimiento Process5-7
3.1. Los procesos de mantenimiento 5-7
3.2. Actividades de mantenimiento 5-8
4. Las tcnicas para Maintenance5-10
4.1. programa de Comprensin 5-10
4.2. reingeniera 5-10
4.3. Ingeniera inversa 5-10
4.4. Migracin 5-10
4.5. Jubilacin 5-11

5. El software de mantenimiento Tools5-11

 Matriz de Temas vs. Referencia Material5-12

Captulo 6: Software Gestin de la configuracin 6-1

1. Gestin de la SMC Process6-2
1.1. Contexto de organizacin de SMC 6-2
1.2. Limitaciones y orientacin para el proceso SMC 6-3
1.3. La planificacin de SMC 6-3
1.4. plan de SMC 6-5
1.5. La vigilancia de la Gestin de la Configuracin de Software 6-5
2. Configuracin del software Identification6-6
2.1. Los productos que la identificacin que deben ser controlados 6-6
2.2. software Library 6-8
3. Configuracin del software Control6-8
3.1. Solicitar, evaluar y cambios que aprueba Software 6-8
3.2. Cambios en el software de aplicacin 6-9
3.3. Desviaciones y renuncias 6-10
4. Estado de la configuracin de software Accounting6-10
4.1. Software de informacin de estado de configuracin 6-10
4.2. Informes de estado de configuracin de software 6-10
5. Configuracin del software Auditing6-10
5.1. Software de Auditora de Configuracin Funcional 6-11
5.2. Auditora de Configuracin fsica de software 6-11
5.3. En-Proceso de Auditoras de una lnea de base del software 6-11
6. Gestin de la Entrega de Software y Delivery6-11
6.1. Edificio de software 6-11
6.2. Gestin de la Entrega de Software 6-12
7. Gestin de la Configuracin de Software Tools6-12
Matriz de Temas vs. Referencia Material6-13

Captulo 7: Software Ingenieria administracin 7-1

1. Iniciacin y Alcance Definition7-4
1.1. La determinacin y la negociacin de los requisitos 7-4
1.2. Anlisis de viabilidad 7-4
1.3. Proceso para el examen y revisin de los requisitos 7-5
2. Proyecto de software Planning7-5
2.1. Planificacin de procesos 7-5
2.2. determinar entregables 7-5
2.3. Esfuerzo, Calendario, y Estimacin de Costos 7-6
2.4. Asignacin de recursos 7-6
2.5. Gestin de riesgos 7-6
2.6. Gestin de la calidad 7-6
2.7. Gestin del plan 7-7
3. Proyecto de software Enactment7-7
3.1. Implementacin de Planes 7-7
3.2. Software de Adquisicin y Gestin de Proveedores Contrato 7-7
3.3. Implementacin de Proceso de medida 7-7
3.4. Process monitor 7-7
3.5. Control de procesos 7-8
3.6. informes 7-8

4. Revisin y Evaluation7-8
 4.1. La determinacin de satisfaccin de los requisitos 7-8
4.2. Revisin y Evaluacin del desempeo 7-9
5. Closure7-9
5.1. Cierre la determinacin 7-9
5.2. Actividades de cierre 7-9
6. Ingeniera de Software Measurement7-9
6.1. Establecer y mantener el compromiso de Medicin 7-9
6.2. Planificar el proceso de medicin 7-10
6.3. Realizar el proceso de medicin 7-11
6.4. evaluar Medicin 7-11
7. Ingeniera de Software de Gestin Tools7-11
Matriz de Temas vs. Referencia Material7-13

Captulo 8: Software Ingenieria Proceso 8-1

1. procesos de software Definition8-2
1.1. Gestin de procesos de software 8-3
1.2. Infraestructura de Procesos de Software 8-4
2. Software vida Cycles8-4
2.1. Categoras de procesos de software 8-5
2.2. Modelos de Ciclo de vida del software 8-5
2.3. La adaptacin de procesos de software 8-6
2.4. Consideraciones prcticas 8-6
3. Proceso de Evaluacin y software Improvement8-6
3.1. Modelos de evaluacin de procesos de software 8-7
3.2. Proceso de Software Mtodos de evaluacin 8-7
3.3. Modelos de mejora de procesos de software 8-7
3.4. Software puntuaciones proceso continuo y puesta en escena 8-8
4. software Measurement8-8
4.1. Proceso de Software y Medicin del producto 8-9
4.2. Calidad de los resultados de medicin 8-10
4.3. Informacin de software Modelos 8-10
4.4. Tcnicas de medicin de procesos de software 8-11
5. Proceso de Ingeniera de Software Tools8-12
Matriz de Temas vs. Referencia Material8-13

Captulo 9: Software Modelos de ingeniera y mtodos 9-1

1. Modeling9-1
1.1. Principios de modelado 9-2
1.2. Propiedades y Expresin de Modelos 9-3
1.3. Sintaxis, la semntica y la pragmtica 9-3
1.4. Condiciones previas, postConditions, e invariantes 9-4
2. Tipos de Models9-4
2.1. Modelado de informacin 9-5
2.2. Modelado del comportamiento 9-5
2.3. Modelado estructura 9-5
3. Anlisis de Models9-5
3.1. Para completar el anlisis 9-5
3.2. La consistencia para analizar 9-6

3.3. El anlisis de la correccin 9-6

3.4. trazabilidad 9-6
 3.5. Anlisis de interaccin 9-6
4. Ingeniera de Software Methods9-7
4.1. Los mtodos heursticos 9-7
4.2. Mtodos formales 9-7
4.3. Los mtodos de prototipado 9-8
4.4. Los mtodos giles 9-9
Matriz de Temas vs. Referencia Material9-10

Captulo 10: Software Quality10-1

1. Software de calidad Fundamentals10-2
1.1. Software de Ingeniera de la Cultura y tica 10-2
1.2. Valor y los costos de Calidad 10-3
1.3. Modelos y caractersticas de calidad 10-3
1.4. Mejora de la Calidad de Software 10-4
1.5. software de Seguridad 10-4
2. Software de Gestin de Calidad Processes10-5
2.1. Calidad de Software 10-5
2.2. Verificacin validacin 10-6
2.3. Revisiones y auditoras 10-6
3. Considerations10-9 prctica
3.1. Requisitos de calidad de software 10-9
3.2. Caracterizacin de defectos 10-10
3.3. Tcnicas de gestin de calidad de software 10-11
3.4. Medicin de la Calidad de Software 10-12
4. Software de calidad Tools10-12
Matriz de Temas vs. Referencia Material10-14

Captulo 11: Software profesional de la ingeniera Prctica 11-1

1. Professionalism11-2
1.1. Acreditacin, Certificacin y Licencias 11-3
1.2. Cdigos de tica y Conducta Profesional 11-4
1.3. La naturaleza y la funcin de las Sociedades Profesionales 11-4
1.4. La naturaleza y la funcin de las normas de ingeniera de software 11-4
1.5. Impacto econmico de Software 11-5
1.6. Contratos de trabajo 11-5
1.7. Asuntos legales 11-5
1.8. Documentacin 11-7
1.9. Anlisis compensacin 11-8
2. Dinmica de Grupos y Psychology11-9
2.1. Dinmica de trabajo en equipos / grupos 11-9
2.2. cognicin individual 11-9
2.3. Tratar con el problema Complejidad 11-10
2.4. La interaccin con las partes interesadas 11-10
2.5. Superacin de la incertidumbre y la ambigedad 11-10
2.6. Tratar con entornos multiculturales 11-10
3. comunicacin Skills11-11
3.1. Leer, comprender y resumir 11-11

3.2. Escritura 11-11

3.3. Equipo y Comunicacin Grupo 11-11
3.4. Habilidades de presentacin 11-12
 Matriz de Temas vs. Referencia Material11-13

Captulo 12: Software Ingenieria Economics12-1

1. Ingeniera de Software Economa Fundamentals12-3
1.1. Financiar 12-3
1.2. Contabilidad 12-3
1.3. Controlador 12-3
1.4. Flujo de fondos 12-3
1.5. Proceso de toma de decisiones 12-4
1.6. Valuacin 12-5
1.7. Inflacin 12-6
1.8. Depreciacin 12-6
1.9. Impuestos 12-6
1.10. Valor del tiempo de dinero 12-6
1.11. Eficiencia 12-6
1.12. Eficacia 12-6
1.13. Productividad 12-6
2. Ciclo de Vida Economics12-7
2.1. Producto 12-7
2.2. Proyecto 12-7
2.3. Programa 12-7
2.4. portafolio 12-7
2.5. Ciclo de vida del producto 12-7
2.6. Ciclo de Vida del Proyecto 12-7
2.7. propuestas 12-8
2.8. Decisiones de inversin 12-8
2.9. Planeando el horizonte 12-8
2.10. Precio y precios 12-8
2.11. Costo y costeo 12-9
2.12. Medicin del desempeo 12-9
2.13. Gestion del valor ganado 12-9
2.14. Las decisiones de terminacin 12-9
2.15. Las decisiones de reemplazo y jubilacin 12-10
3. Riesgo y Uncertainty12-10
3.1. Metas, estimaciones, y Planes 12-10
3.2. Las tcnicas de estimacin 12-11
3.3. La incertidumbre abordar 12-11
3.4. priorizacin 12-11
3.5. Las decisiones en riesgo 12-11
3.6. Las decisiones bajo incertidumbre 12-12
4. Anlisis econmico Methods12-12
4.1. Con fines de lucro Anlisis de Decisiones 12-12
4.2. Tasa de retorno mnima aceptable 12-13
4.3. Retorno de la Inversin 12-13
4.4. Rendimiento del capital invertido 12-13
4.5. Anlisis coste-beneficio 12-13

4.6. Anlisis coste-efectividad 12-13

4.7. Punto de equilibrio de analisis 12-13
4.8. Business Case 12-13
4.9. Evaluacin Atributo mltiple 12-14
 4.10. Anlisis de optimizacin 12-14
5. Considerations12-14 prctica
5.1. El suficientemente bueno Principio 12-14
5.2. Economa-Friction Free 12-15
5.3. ecosistemas 12-15
5.4. La deslocalizacin y la externalizacin 12-15
Matriz de Temas vs. Referencia Material12-16

Captulo 13: Informtica Foundations13-1

1. Resolucin de Problemas Techniques13-3
1.1. Definicin de la resolucin de problemas 13-3
1.2. Formular el problema real 13-3
1.3. Analizar el problema 13-3
1.4. Disear una estrategia de bsqueda de soluciones 13-3
1.5. La resolucin de problemas Utilizacin de programas 13-3
2. Abstraction13-4
2.1. Los niveles de abstraccin 13-4
2.2. La encapsulacin 13-4
2.3. Jerarqua 13-4
2.4. Las abstracciones alternativos 13-5
3. programacin Fundamentals13-5
3.1. El proceso de programacin 13-5
3.2. Los paradigmas de programacin 13-5
4. Lenguaje de Programacin Basics13-6
4.1. Lenguaje de Programacin general 13-6
4.2. Sintaxis y semntica de lenguajes de programacin 13-6
4.3. Bajo Programacin y Lenguajes 13-7
4.4. -Programacin y Lenguajes 13-7
4.5. vs. declarativa de programacin imperativo Idiomas 13-7
5. Herramientas de depuracin y Techniques13-8
5.1. tipos de errores 13-8
5.2. Las tcnicas de depuracin 13-8
5.3. Herramientas de depuracin 13-8
6. Estructura de datos y Representation13-9
6.1. Presentacin de la estructura de datos 13-9
6.2. tipos de Estructura de Datos 13-9
6.3. Las operaciones en Estructuras de Datos 13-9
7. Algoritmos y Complexity13-10
7.1. Descripcin general de Algoritmos 13-10
7.2. Atributos de Algoritmos 13-10
7.3. Anlisis algortmico 13-10
7.4. Estrategias de diseo algortmico 13-11
7.5. Estrategias de anlisis algortmico 13-11
8. Concepto bsico de un System13-11
8.1. Propiedades del sistema emergente 13-11

8.2. Ingeniera de Sistemas 13-12

8.3. Visin general de un sistema informtico 13-12
9. Organization13-13 equipo
9.1. Organizacin general del ordenador 13-13
9.2. Sistemas digitales 13-13
 9.3. lgica digital 13-13
9.4. Expresin de datos del ordenador 13-13
9.5. La Unidad Central de Procesamiento (CPU) 13-14
9.6. Organizacin del Sistema de memoria 13-14
9.7. Entrada y salida (I / O) 13-14
10. compilador Basics13-15
10.1. Compilador / intrprete general 13-15
10.2. Interpretacin y compilacin 13-15
10.3. El proceso de compilacin 13-15
11. Sistemas operativos Basics13-16
11.1. Operativo general Sistemas 13-16
11.2. Tareas de un sistema operativo 13-16
11.3. Las abstracciones del sistema operativo 13-17
11.4. Sistemas para realizar la clasificacin 13-17
12. Fundamentos de bases de datos y los datos Management13-17
12.1. Entidad y de esquema 13-18
12.2. Sistemas de Gestin de Bases de Datos (DBMS) 13-18
12.3. Lenguaje de consulta de base de datos 13-18
12.4. Tareas Los paquetes de DBMS 13-18
12.5. Gestin de datos 13-19
12.6. La minera de datos 13-19
13. Red de Comunicacin Basics13-19
13.1. tipos de la Red 13-19
13.2. Componentes de la Red Bsica 13-19
13.3. Protocolos de red y Estndares 13-20
13.4. La Internet 13-20
13.5. Internet de las Cosas 13-20
13.6. Virtual Private Network (VPN) 13-21
14. Computing13-21 Paralela y Distribuida
14.1. Computacin paralela y distribuida general 13-21
14.2. Diferencia entre Computacin Paralela y Distribuida 13-21
14.3. Modelos de Computacin Paralela y Distribuida 13-21
14.4. Problemas principales en Distributed Computing 13-22
15. Usuario bsico Factors13-22 Humano
15.1. Entrada y salida 13-22
15.2. Error de mensajes 13-23
15.3. La robustez del software 13-23
16. Desarrollador bsica Factors13-23 Humano
16.1. Estructura 13-24
16.2. comentarios 13-24
17. Asegurar el desarrollo de software y Maintenance13-24
17.1. Requisitos de software de seguridad 13-24
17.2. Diseo de Software de Seguridad 13-25
17.3. El software de seguridad de construccin 13-25
17.4. El software de seguridad de Pruebas 13-25

17.5. Construir Seguridad en Ingeniera de Procesos de Software 13-25

17.6. Gua de seguridad de software 13-25
Matriz de Temas vs. Referencia Material13-27

Captulo 14: Matemtico Foundations14-1

 1. Conjunto, Relaciones, Functions14-1
1.1. las operaciones Set 14-2
1.2. Propiedades del Conjunto 14-3
1.3. Relacin y funcin 14-4
2. bsico Logic14-5
2.1. Lgica proposicional 14-5
2.2. La lgica de predicados 14-5
3. Techniques14-6 prueba
3.1. Mtodos de demostracin de teoremas 14-6
4. Fundamentos de la Counting14-7
5. Los grficos y Trees14-8
5.1. Los grficos 14-8
5.2. rboles 14-10
6. discreta Probability14-13
7. Finita Machines14-14 Estado
8. Grammars14-15
8.1. Reconocimiento idioma 14-16
9. Numrica de precisin, exactitud y Errors14-17
10. nmero Theory14-18
10.1. Divisibilidad 14-18
10.2. Nmero primo, GCD 14-19
11. algebraica Structures14-19
11.1. Grupo 14-19
11.2. anillos 14-20
Matriz de Temas vs. Referencia Material14-21

Captulo 15: Ingenieria Foundations15-1

1. Mtodos empricos y Experimental Techniques15-1
1.1. experimento diseado 15-1
1.2. Estudio observacional 15-2
1.3. Estudio retrospectivo 15-2
2. Anlisis estadstico 15-2
2.1. Unidad de anlisis (unidades de muestreo), Poblacin y Muestra 15-2
2.2. Conceptos de correlacin y regresin 15-5
3. Measurement15-5
3.1. Niveles (Scales) de Medicin 15-6
3.2. Medidas directos y derivados 15-7
3.3. Fiabilidad y Validez 15-8
3.4. Fiabilidad evaluar 15-8
4. ingeniera Design15-8
4.1. Diseo de ingeniera en la Educacin en Ingeniera 15-8
4.2. El diseo como Solucin de problemas Actividad 15-9
4.3. Pasos a seguir en Diseo de Ingeniera 15-9
5. Modelado, Simulacin y Prototyping15-10
5.1. Modelado 15-10

5.2. Simulacin 15-11

5.3. prototipado 15-11
6. Standards15-12
7. Causa Raz Analysis15-12
7.1. Las tcnicas para la realizacin de anlisis de causa raz 15-13
 Matriz de Temas vs. Referencia Material15-14

Apndice A: rea de Conocimiento Descripcin Presupuesto A-1

Apndice B: IEEE e ISO / IEC Apoyo a la Ingeniera de Software

Cuerpo de conocimientos (SWEBOK) B-1

Apndice DO: Referencia consolidada Lista C-1

 PREFACIO

El software de inge- niera cuerpo de

Cada profesin se basa en un conjunto de conocimientos est constantemente en evolucin
conocimientos, a pesar de que el conocimiento ing. Sin embargo, esta gua constituye una
no siempre se define de una manera concisa. En caracterizacin valioso poder de la profesin de la
los casos en que no existe ninguna formalidad, el ingeniera de software.
cuerpo de conocimiento se GEN-ralmente
reconocido por los mdicos y puede ser
codificado en una variedad de formas para una
variedad de usos diferentes. Pero en muchos
casos, una gua para un cuerpo de conocimiento
se documenta formalmente, el aliado no baja en
una forma que permite que sea utilizado para
fines tales como el desarrollo y la acreditacin
de programas acadmicos y de capacitacin,
certificacin de especialistas, o licencia
profesional. En general, una asociacin
profesional u organismo similar mantiene la
administracin de la definicin formal de un
conjunto de conocimientos.
Durante los ltimos cuarenta y cinco aos, la
ingeniera de software ha evolucionado a partir
de una frase conferencia Catch en una profesin
de la ingeniera, caracteriza- da por la 1) una
sociedad profesional, 2) las normas que
especifican las prcticas profesionales
generalmente aceptadas;
3) un cdigo de tica, 4) actas de la conferencia,
5) libros de texto, 6) directrices del plan de
estudios y planes de estudio, 7) los criterios de
acreditacin y programas de grado acreditados,
8) la certificacin y concesin de licencias, y 9)
de esta gua al cuerpo de conocimientos.
En esta Gua para la Ingeniera de Software de
Administracin de Conocimiento, las cons-
tituye IEEE Computer Society una versin
revisada y del conjunto de conocimientos
anteriormente documentado como SWEBOK
2004 actualizado; esta versin revisada y
actualizada se denota SWEBOK V3. Este
trabajo est en cumplimiento parcial de la
responsabilidad de la sociedad para promover el
avance de la teora y la prctica de la profesin
de la ingeniera de software.
Cabe sealar que esta Gua no presenta la
totalidad del cuerpo de conocimientos de
ingeniera de soft- ware, sino que sirve como
gua para el conjunto de conocimientos que se
ha desarrollado durante ms de cuatro dcadas.
 capturado en SWEBOK 2004. La versin actual
En 1958, John Tukey, la istician stat- de de 12207 se designa como ISO / IEC 12207:
renombre mundial, acu el trmino software. 2008 e IEEE 12.207 a 2.008; eso
La ingeniera de software trmino fue utilizado proporciona la base para este V3 SWEBOK.
en el ttulo de una conferencia de la OTAN Esta gua para la Ingeniera de Software de
celebrada en Alemania en 1968. El IEEE Administracin de Conocimiento se presenta a
Computer Society public por primera vez sus usted, el lector, como un mecanismo para
Transacciones de Ingeniera de Software en adquirir los conocimientos que necesita en su
1972, y se estableci un tee de compromiso desarrollo de carrera de toda la vida como un
para el desarrollo de Dardos de ingeniera de profesional de la ingeniera de software.
software dentro de Estn- la IEEE Computer
Society en 1976.
En 1990, se inici la planificacin para una Dick Fairley, Presidente
norma interna- cional para proporcionar una Software y Comit de Ingeniera de Sistemas
visin global de ingeniera de soft- ware. La IEEE Computer Society
norma se complet en 1995 con la designacin
de la norma ISO / IEC 12207 y se le dio el
ttulo de software estndar para cesos del Ciclo Don Shafer, vicepresidente
de Vida Pro-. La versin de IEEE 12207 fue Actividades profesionales
publicada en 1996 y proporcion una base Junta IEEE Computer
importante para el conjunto de conocimientos Society

xvii
 Prlogo a la edicin de 2004

Exmenes, requisitos de software, diseo de

En esta gua, lishes la IEEE Computer Society software, y la verificacin y validacin de
esta- por primera vez una lnea de base para el software.
conjunto de conocimientos para el campo de la Durante el periodo 1981-1985, la Sociedad
ingeniera de software, y el trabajo cumple IEEE putadora Com- llev a cabo una serie de
parcialmente la responsabilidad de la sociedad talleres con- cerning la aplicacin de la ingeniera
para promover el avance de la teora y la de software
prctica en esta campo. De este modo, la
Sociedad se ha guiado por la experiencia de
disciplinas con historias ms largas, pero no
estaba vinculado por sus problemas o sus
soluciones. Cabe sealar que la Gua no PUR
puerto para definir el conjunto de
conocimientos, sino ms bien para servir como
un compendio y guas para el conjunto de
conocimientos que se ha venido desarrollando y
en evolucin ing en las ltimas cuatro dcadas.
Por otra parte, este conjunto de conocimientos
no es esttica. La gua debe, necesariamente,
desarrollar y evolucionar a medida que madura
la ingeniera de software. Sin embargo,
constituye un elemento valioso de la ingeniera
del software
infraestructura.
En 1958, John Tukey, la istician stat- de
renombre mundial, acu el trmino software.
La ingeniera de software trmino fue utilizado
en el ttulo de una conferencia de la OTAN
celebrada en Alemania en 1968. El IEEE
Computer Society public por primera vez sus
Transacciones de Ingeniera de Software en
1972. El comit establecido en la IEEE
Computer Society para el desarrollo de
estndares de ingeniera de software fue fundada
en 1976.
La primera visin integral de ingeniera de
software para salir de la IEEE Computer Society
fue resultado de un esfuerzo dirigido por
Fletcher Buckley para desarrollar el estndar
IEEE 730 para el software de cali- dad de
aseguramiento, que se complet en 1979. El
propsito de la norma IEEE Std. 730 era
proporcionar uniformes, requisitos mnimos
aceptables para la preparacin y el contenido de
los planes de ANCE assur- de calidad de
software. Esta norma fue influyente en com-
pletar las normas de desarrollo de los siguientes
temas: gestin de configuracin, software de
 denomina- cin, ISO / IEC 12207, y se le dio el
normas. Estos talleres involucrados ners ttulo de Stan- dard para los procesos de ciclo de
practitio- compartiendo sus experiencias con vida del software. Std. ISO / IEC 12207
los Standards existentes. Los talleres tambin proporciona un importante punto de partida para
se llevaron a cabo sesiones sobre la el conjunto de conocimientos capturados en este
Planificacin de las normas futuras, incluyendo libro. Era la Junta IEEE Computer Society de
uno que incluya las medidas y mtricas para la Gobernadores la aprobacin de la mocin
ingeniera de software de productos y procesos. presentada en mayo de 1993 mediante Fletcher
La planificacin tambin result en IEEE Std. Buckley, que dio lugar a la redaccin de este
1002, Taxonoma de Estndares de Ingeniera libro. La Association for Computing Machinery
de Software (1986), que proporcion una Consejo (ACM) aprob una mocin relacionada
nueva visin holstica de la ingeniera de en agosto de 1993. Los dos movimientos
software. La norma describe la forma y el condujeron a un comit conjunto bajo la
contenido de las normas de ingeniera de un direccin de Mario Barbacci y Stuart Zweben
soft- ware taxonoma. Se explican los que sirvi como copresidentes. La declaracin
diferentes tipos de Dardos de ingeniera de de la misin de la comisin conjunta era
software Estn-, sus relaciones funcionales y Establecer los conjuntos apropiados (s) de
externos, y el papel de las diversas funciones criterios y normas para la prctica profesional de
que participan en el ciclo de vida del software. la ingeniera de software sobre el cual siones
En 1990, se inici la planificacin para un industriales terio, la certificacin profesional, y
Dard Estn- internacional con una visin de los programas de estudio se pueden basar. El
conjunto. El la Planificacin centrada sobre la comit directivo
conciliacin de los puntos de vista del proceso grupos de trabajo organizados en las siguientes
de software de IEEE Std. 1074 y la norma reas:
revisada 2167A de EE.UU. Departamento de
Defensa. La revisin fue publicada como 1. Definir Obligatorio cuerpo de
aliado eventu- DoD Std. 498. La norma conocimientos y
internacional se complet en 1995 con la Prcticas recomendadas.

xix
Gua xx SWEBOK V3.0

2. Definir tica y Estndares Profesionales. Se espera que los lectores encontrarn en este
3. Definir planes de estudio para la Educacin libro uso-ful para guiarlos hacia el conocimiento
univer- y los recursos que necesitan en su carrera de por
comi, graduado, y la educacin continua. vida desa- rrollo como profesionales de
ingeniera de software.
Este libro suministra el primer componente: El libro est dedicado a Fletcher Buckley en
requerida reconocimiento a su compromiso con la
Conjunto de conocimientos y recomendar promocin de la ingeniera de software como
prcticas. una disciplina profesional y su excelencia como
El cdigo de tica y prctica profesional de la Tioner una ingeniera de software prc- en
ingeniera de software se complet en 1998 y aplicaciones de radar.
aprobado tanto por el Consejo de ACM y la
IEEE Computer Society Junta de Gobernadores.
Ha sido adoptado por numerosas empresas y Leonard L. Tripp, Fellow de IEEE 2003
otras organizaciones y est incluido en varios Presidente del Comit de Prcticas
libros de texto recientes. Profesionales, IEEE
El plan de estudios para los estudiantes est Computer Society (2001-2003)
siendo completada por un esfuerzo conjunto de
la IEEE Computer Society y de la ACM y se Presidente del Comit Directivo Conjunto IEEE
espera que est terminado en 2004. Computer Society y ACM para el Establecimiento de
Cada profesin se basa en un cuerpo de El Ingeniera de Software como una Profesin (1998-
conocimiento y las prcticas recomendadas, a 1999)
pesar de que no siempre se definen de una
manera precisa. En muchos casos, stos se Presidente del Comit de Estndares de Ingeniera de
documentan formalmente, el aliado no baja en Software, IEEE Computer Society
una forma que les permite ser utilizado para (1992-1998)
fines tales como la acreditacin de programas
acadmicos, el desarrollo de programas de
educacin y formacin, la certificacin de
especialistas, o licencia profe- sional. En
general, una sociedad profesional u organismo
relacionado mantiene la custodia de una
definicin Mal tales lucro. En los casos en que
no exista tal formalidad, el conjunto de
conocimientos y prcticas recomendadas son
generalmente reconocidos por ners practitio- y
pueden ser codificados en una variedad de
maneras para diferentes usos.
 EDITORES
Pierre Bourque, Departamento de Ingeniera de Software y TI, Escuela de Tecnologa Superior (ETS),
Canad, [email protected]
Richard E. (Dick) Fairley, Software e Ingeniera de Sistemas Asociados (S2EA), EE.UU.,
[email protected]

coeditores
Alain Abran, Departamento de Ingeniera de Software y TI, Escuela de Tecnologa Superior (ETS),
Canad, [email protected]
Juan Garbajosa, Universidad Politcnica de Madrid (Universidad Politcnica de Madrid, UPM),
Espaa, [email protected]
Gargi Keeni, Tata Consultancy Services, la India, [email protected]
Beijun Shen, Escuela de software, Shanghai Jiao Tong Universidad, China, [email protected]

editores colaboradores
Las siguientes personas contribuyeron a la edicin de la Gua de
SWEBOK V3: Don Shafer
Linda Shafer
Mary Jane Willshire
Kate Guillemette

TABLERO DE CONTROL DE CAMBIOS

Las siguientes personas sirven en la Junta de Control de Cambio V3 Gua
SWEBOK: Pierre Bourque
Richard E. (Dick) Fairley,
Presidente Dennis
Frailey Michael Gayle
Thomas Hilburn
Paul Joannou
James W.
Moore Don
Shafer Steve
Tockey

xxi
 EDITORES rea de conocimiento

Requisitos de Software
Gerald Kotonya, Facultad de Informtica y Comunicaciones, Universidad de Lancaster, Reino
Unido, [email protected]
Peter Sawyer, Facultad de Informtica y Comunicaciones, Universidad de Lancaster, Reino
Unido, [email protected]

Diseo de software
Yanchun Sol, Facultad de Ingeniera Electrnica e Informtica, Universidad de Pekn, China,
[email protected]

Construccin de software
Xin Peng, Escuela de Software de la Universidad de Fudan, China, [email protected]

Pruebas de software
Antonia Bertolino, ISTI-CNR, Italia,
[email protected] Eda Marchetti, ISTI-CNR, Italia,
[email protected]

Mantenimiento del software

Alain abril de Escuela de Tecnologa Superior (ETS), Canad,
[email protected] Mira Kajko-Mattsson, Escuela de Tecnologa de
Informacin y Comunicacin, KTH Royal Institute of Technology,
[email protected]

Gestin de la Configuracin de Software

Roger Champagne, Escuela de Tecnologa Superior (ETS), Canad, Roger.champagne @
etsmtl.ca
Alain abril de Escuela de Tecnologa Superior (ETS), Canad, [email protected]

Gestin de Ingeniera de Software

James McDonald, Departamento de Ciencias de la Computacin e Ingeniera de
Software, Monmouth University, EE.UU., [email protected]

Proceso de Ingeniera de Software

Annette Reilly, Sistemas de Informacin y Lockheed Martin Global Solutions, EE.UU.,
[email protected]
Richard E. Fairley, Software e Ingeniera de Sistemas Asociados (S2EA), EE.UU.,
[email protected]

Modelos de Ingeniera de Software y Mtodos

Michael F. Siok, Lockheed Martin Aeronutica Company, EE.UU., [email protected]

Calidad del software

J. David Blaine, EE.UU., [email protected]
Durba Biswas, Tata Consultancy Services, la India, [email protected]
Gua xxiv SWEBOK V3.0

xxiii
 Ingeniera de Software Prctica Profesional
EDITORES rea de conocimiento
Aura Sheffield, EE.UU., [email protected]
Hengming Zou, Shanghai Jiao Tong Universidad, China, [email protected]

Economa Ingeniera de Software

Christof Ebert, Servicios Consulting vectorial, Alemania, [email protected]

Fundamentos de computacin
Hengming Zou, Shanghai Jiao Tong Universidad, China, [email protected]

Fundamentos matemticos
Nabendu Chaki, Universidad de Calcuta, India, [email protected]

Fundamentos de ingeniera
Amitava Bandyopadhayay, Instituto de Estadstica de la India, la India,
[email protected] Mary Jane Willshire, Software e Ingeniera de Sistemas
Asociados (S2EA), EE.UU., [email protected]

Apndice B: IEEE y normas ISO / IEC SWEBOK Apoyando

James W. Moore, EE.UU., [email protected]
Gua xxiv SWEBOK V3.0

DE VERSIONES SWEBOK ANTERIORES

Las siguientes personas sirvieron como editores asociados, ya sea para la versin de prueba publicados
en 2001, o
la versin 2004.

Requisitos de Software
Peter Sawyer, Departamento de Informtica, Universidad de
Lancaster, Reino Unido Gerald Kotonya, Departamento de
Informtica, Universidad de Lancaster, Reino Unido

Diseo de software
Chico Tremblay, departamento de Informtica, UQAM, Canad

Construccin de software
Steve McConnell, Construx Software, EE.UU.
Terry Bollinger, la MITRE Corporation,
EE.UU.
Philippe Gabrini, departamento de Informtica, UQAM, Canad
Louis Martin, departamento de Informtica, UQAM, Canad

Pruebas de software
Antonia Bertolino, ISTI-CNR,
Italia Eda Marchetti, ISTI-CNR,
Italia

Mantenimiento del software

Thomas M. Pigoski, Techsoft Inc., EE.UU.
Alain abril de Escuela Superior de Tecnologa, Canad

Gestin de la Configuracin de Software

John A. Scott, Laboratorio Nacional Lawrence Livermore, EE.UU.
David Nisse, EE.UU.

Gestin de Ingeniera de Software

Dennis Frailey, Raytheon Company, EE.UU.
Stephen G. MacDonell, Universidad de Tecnologa de Auckland, Nueva Zelanda
Andrew R. Gray, Universidad de Otago, Nueva Zelanda

Proceso de Ingeniera de Software

Khaled El Emam, sirvi mientras que en el Canadian National Research Council,
Canad

Herramientas de ingeniera de software y mtodos

David Carrington, Facultad de Tecnologa de la Informacin e Ingeniera
Elctrica de la Universidad de Queensland, Australia
EDITORES rea de conocimiento

xxv
Gua xxiv SWEBOK V3.0

Calidad del software

Alain abril de Escuela Superior de Tecnologa, Canad
Dolores Wallace, se retir del Instituto Nacional de Estndares y Tecnologa, EE.UU.
Larry Reeker, NIST, EE.UU.

referencias Editor
Marc Bouisset, departamento de Informtica, UQAM
 equipo de revisin
Las personas que figuran a continuacin participaron en el proceso de revisin pblica de la Gua
SWEBOK V3. La membresa de la IEEE Computer Society no era un requisito para participar en
este proceso de revisin, y la informacin de pertenencia no se ha solicitado a los colaboradores.
Ms de 1.500 comentarios individuales se recogieron y debidamente adjudicadas.

Carlos C. Amaro, M. Eblen, Australia David M. Endres,

EE.UU. Mark Ardis, EE.UU. Marilyn Escue, EE.UU. Varuna
EE.UU. Eswer, India
Mora-Soto Arturo,
Espaa Ohad Barzilay,
Israel Gianni Basaglia,
Italia Denis J. Bergquist,
EE.UU. Alexander
Bogush, Reino Unido
Christopher Bohn,
EE.UU. Steve Bollweg,
EE.UU.
Reto Bonderer, Suiza
Alexei Botchkarev, Canad
Pieter Botman, Canad
Robert Bragner, EE.UU.
Kevin Brune, EE.UU.
Ogihara Bryan, EE.UU.
Luigi Buglione, Italia
Rick Cagle, EE.UU.
Barbara Canody,
EE.UU.
Rogerio A. Carvalho, Brasil
Daniel Cerys, EE.UU.
Philippe Cohard, Francia
Ricardo Colomo-Palacios,
Mauricio Coria Espaa,
Argentina Marek Cruz, Reino
Unido
Stephen Danckert,
EE.UU. Bipul K. Das,
Canad James D.
Davidson, EE.UU. Jon
Dehn, EE.UU.
Lincoln P. Djang, EE.UU.
Andreas Doblander, Austria
Yi-Ben Doo, EE.UU.
Scott J. Dougherty, Reino
Unido Regina DuBord,
EE.UU. Fedor
Dzerzhinskiy, Rusia Ann
Gua xxiv SWEBOK V3.0 EE.UU.
Istvan Fay, Hungra
Jos L. Fernndez- Bob Hillier, Canad
Snchez, Dennis J. Norman M. Hines,
Espaa Frailey, EE.UU. Dave Hirst,
EE.UU. EE.UU. Theresa L.
Tihana Galinac Hunt, EE.UU. Kenneth
Grbac, Croacia Ingham, EE.UU.
Colin Garlick, Masahiko Ishikawa, Japn
Nueva Zelanda Michael A. Jablonski, EE.UU.
Garth JG Glynn, G. Jagadeesh, India
Reino Unido Sebastin Justicia, Espaa
Jill Gostin, EE.UU. Umut Kahramankaptan, Blgica
Christiane von Gresse Pankaj Kamthan, Canad
Wangenheim, Brasil Thomas Perry Kapadia, EE.UU.
Gust, EE.UU. Tarig A. Khalid, Sudn
HN Michael KA Klaes, Alemania
Mok, MAGED Koshty, Egipto
Singapu Claude C. Laporte, Canad
r Jon D. Dong Li, China
Hagar, Ben Linders, Pases
EE.UU. Bajos Claire Lohr,
Anees Ahmed EE.UU. Vladimir
Haidary, India Mandic, Serbia
Duncan Hall, Matt Mansell, Nueva
Nueva Zelanda Zelanda, John Marien,
James Hart, EE.UU.
EE.UU.
Jens HJ
Heidrich,
Alemania Rich
Hilliard,

xxvii
Stephen P. Masticola, EE.UU. Thom Schoeffling, EE.UU.
Nancy Mead, EE.UU. Reinhard Schrage,
Fuensanta Medina-Domnguez, Alemania Neetu Sethia,
Espaa Silvia Judith Meles, India
Argentina Cindy C. Shelton, EE.UU.
Oscar A. Mondragon, Mxico Alan Shepherd, Alemania
David W. Mutschler, EE.UU. Katsutoshi Shintani, Japn
Maria Nelson, Brasil Erik Shreve, EE.UU.
John Noblin, EE.UU. Jaguaraci Silva, Brasil
Bryan G. Ogihara, M. Somasundaram, India
EE.UU. Takehisa Peraphon Sophatsathit, Tailandia
Okazaki, Japn Hanna John Standen, Reino Unido
Oktaba, Mxico Joyce Statz, EE.UU.
Chin Hwee Ong, Hong Kong Perdita P. Stevens,
Venkateswar Oruganti, India David Struble Reino
Birgit Penzenstadler, Alemania Unido, EE.UU. Ohno
Larry Peters, EE.UU. Susumu, Japn Urcun
SK Pillai, India Tanik, EE.UU. Talin
Vaclav Rajlich, Tasciyan, EE.UU.
EE.UU. Kiron Rao, J. Barrie Thompson, Reino
India Luis Reyes, Unido Steve Tockey,
EE.UU. Hassan EE.UU.
Reza, EE.UU. Steve Miguel Eduardo Torres Moreno, Colombia
Roach, EE.UU. Dawid Trawczynski, EE.UU.
Teresa L. Roberts, Adam Trendowicz, Alemania
EE.UU. Dennis Robi, Norio Ueno, Japn
EE.UU. Warren E. Cenk Uyan, Turqua
Robinson, EE.UU. Jorge Chandra Sekar Virappan, Singapur
L. Rodriguez, EE.UU. Oruganti Venkateswar, India
Alberto C. Sampaio, Portugal Jochen Vogt, Alemania
Ed Samuels, EE.UU. Hironori Washizaki, Japn
Mara Isabel Snchez-Segura, Ulf Westermann, Alemania
Espaa Vineet Sawant, EE.UU. Don Wilson, EE.UU.
R. Schaaf, EE.UU. Aharon Yadin, Israel
James C. Schatzman, Hong Zhou, Reino
EE.UU. Oscar A. Schivo, Unido
Argentina Florian
Schneider, Alemania
Gua XXVIII SWEBOK
V3.0

EXPRESIONES DE GRATITUD
Los fondos para el desarrollo de la Gua diversas maneras: Pieter Botman, Evan Butterfield,
SWEBOK V3 ha sido proporcionada por la Carine Chauny, Pierce Gibbs, Diane Girard, John
IEEE Computer Society. Los editores y Keppler, Dorian McClenahan, Kenza Meridji,
coeditores aprecian el importante trabajo Sam-uel Redwine, Annette Reilly, y Pam
realizado por los editores Ka y los editores Thompson.
colaboradores, as como por los de los miem- Finalmente, seguramente hay otras personas
bros de la Junta de Control de Cambios. El que han contribuido a esta gua, ya sea directa o
equipo editorial tambin debe reconocer la indirectamente, cuyos nombres tenemos
contribucin indispensable de los colaboradores. inadvertidamente omitido. Para esas personas,
El equipo de redaccin desea tambin agradecer ofrecemos nuestra apre- ciacin tcito y
a las personas siguien- tes que han contribuido al disculpas por haber omitido el reconocimiento
proyecto en explcito.

PRESIDENTES IEEE Computer Society

Dejan Milojicic, 2014 Presidente
David Alan Grier, 2013
presidente Thomas Conte, 2015
Presidente

PROFESIONAL actividades a bordo,

2013 MIEMBROS
Donald F. Shafer,
Presidente Pieter
Botman, PCSD Pierre
Bourque Richard
Fairley, PCSD Dennis
Frailey
S. Michael Gayle
Phillip Laplante, PCSD
Jim Moore, PCSD
Linda Shafer, Steve
PCSD Tockey,
PCSD
Charlene Chuck Walrad
xxix
Gua xxx SWEBOK V3.0

MOTIONS sobre la aprobacin de SWEBOK

V3.0 GUA
La Gua SWEBOK V3.0 fue sometida a votacin por los miembros del IEEE Computer Society
verificados en noviembre de 2013, con la siguiente pregunta: aprueba usted el manuscrito de la
Gua SWEBOK V3.0 para avanzar al formato y la publicacin
Los resultados de esta votacin haba 259 S votos y 5 Sin votos.

La siguiente mocin fue aprobada por unanimidad por la Junta de Actividades Profesionales de la
Sociedad IEEE Com- puter en diciembre de 2013:

La Junta de Actividades Profesionales de la IEEE Computer Society considera que el Gua para
la Cesin de Software Ingeniera Cuerpo de Conocimiento Versin 3.0 se ha completado con
xito; y hace suya la Gua de la Ingeniera de Software de Administracin de Conocimiento
versin 3.0 y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su
aprobacin.

La siguiente mocin fue aprobada por la Junta IEEE Computer Society de Gobernadores en diciembre de
2013:

Movido, que la Junta de Gobernadores de la IEEE Computer Society aprueba la versin 3.0 de
la Gua de la Ingeniera de Software de Administracin de Conocimiento y autoriza al Presidente
de la Junta sionales Actividades Profe- para continuar con la impresin.

MOCIONES sobre la aprobacin de

SWEBOK GUA 2004 VERSIN

La siguiente mocin fue aprobada por unanimidad por el Consejo Asesor Industrial de la Gua SWEBOK
proyecto en febrero de 2004:

El Consejo Asesor Industrial encuentra que la ingeniera del cuerpo software de proyecto
Conocimiento ini- ciada en 1998 se ha completado con xito; y hace suya la versin del 2004Gua de
la SWEBOK y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su
aprobacin.

La siguiente mocin fue aprobada por la Junta IEEE Computer Society de Gobernadores en febrero de
2004:

Movido, que la Junta de Gobernadores de la IEEE Computer Society aprueba la edicin de 2004
de la Gua de la Ingeniera de Software de Administracin de Conocimiento y autoriza al
Presidente del Comit de Prcticas pro- fesional para continuar con la impresin.

Tenga en cuenta tambin que la edicin de la Gua de la Ingeniera de Software de Administracin

de Conocimiento 2004 fue presentado por el IEEE Computer Society con la norma ISO / IEC sin
ningn cambio y fue reconocido como el informe tcnico ISO / IEC TR 19759: 2005.
 INTRODUCCIN A LA GUA

KA rea de conocimiento La Gua no debe confundirse con el Cuerpo de

Conocimiento mismo, que existe en la publicacin
Software Cuerpo de Ingeniera
SWEBOK 1 Ver www.computer.org/sevocab.
del Conocimiento

Publicacin de la versin de esta Gua a la

Ingeniera de Software de Administracin de
Conocimiento (BOK SWE- 2004) 2004 fue un
hito importante en el establecimiento de la
ingeniera de software como una disciplina de
ingeniera reconocida. El objetivo en el
desarrollo de esta actualizacin para SWEBOK
es mejorar la moneda, la legibilidad,
consistencia y facilidad de uso de la Gua.
Todas las reas de conocimiento (KAS) se han
actualizado para reflejar los cambios en la
ingeniera de software desde la publicacin de
SWEBOK 2004. Cuatro nuevos dacin Fun-
KAs y una Ingeniera de Software Prcticas
Profe- sional KA se han aadido. Las
herramientas de ingeniera de software y
mtodos KA ha sido revisada como modelos y
mtodos de ingeniera de software. herramientas
de ingeniera de software es ahora un tema en
cada una de la KAS. Tres apndices proporcio-
nar las especificaciones para la descripcin KA,
un conjunto anotada de normas pertinentes para
cada KA, y una lista de las referencias citadas en
la Gua. Esta gua, escrita bajo los auspicios de
la Junta de Actividades Profesionales de la
Sociedad IEEE Com- puter, representa un
siguiente paso en la evo-
cin de la profesin de la ingeniera de software.

Qu es la ingeniera de software?

ISO / IEC / IEEE Sistemas y de Ingeniera de

Software de vocabulario (SEVOCAB) define las
soluciones de inge- niera como la aplicacin
de una disci- plined, enfoque sistemtico y
cuantificable al desarrollo, operacin y
mantenimiento de software; es decir, la
aplicacin de la ingeniera de software).1

QU SON LOS OBJETIVOS DE LA

GUA SWEBOK?
Gua xxx SWEBOK V3.0 El primero de estos objetivos, una amplia
literatura. El propsito de la Gua es describir visin del mundo coherente de ingeniera de
la parte del cuerpo de conocimiento que es software, fue apoyada por un proceso de
gene- ralmente aceptadas, para organizar esa desarrollo que dedica aproximada- mente 150
parte, y para proporcionar acceso tpica a la los colaboradores de 33 pases. Ms informacin
misma. sobre el proceso de desarrollo se puede
La Gua para el swebok (Gua SWEBOK) se encontrar en la pgina web (www.swebok.org).
estableci con los cinco objetivos siguientes: fesionales y las sociedades adquiridas pro y los
organismos pblicos involucradosse pusieron en
1. Para promover una visin coherente de la contacto en la ingeniera de software,
ingeniera de software en todo el mundo conscientes de este proyecto para actualizar
2. Para especificar el alcance de, y aclarar el SWEBOK, e invitados a participar en el proceso
lugar de la ingeniera de software con de revisin. tores KA edi- fueron reclutados de
respecto a otras disciplinas como la Amrica del Norte, la cuenca del Pacfico, y
informtica, la gestin del pro- yecto, Europa. Las presentaciones sobre el proyecto se
ingeniera informtica y matemticas hicieron en varios lugares internacionales.
3. Para caracterizar el contenido de la El segundo de los objetivos, el deseo de
disciplina de la ingeniera de software especificar el mbito de la ingeniera de
4. Para proporcionar un acceso tpica en la software, moti- VATES la organizacin
Ingeniera de Software de Administracin fundamental de la Gua. El material que se
de Conocimiento reconoce como estar dentro de esta disciplina se
5. Para proporcionar una base para el organiza en los quince KAs enumerados en la
desarrollo curricular y para la certificacin Tabla I.1. Cada uno de estos Kas es tratado en
individual y material de licencias un captulo de esta Gua.

XXXI
Tabla I.1. El 15 SWEBOK KAs La organizacin jerrquica
Requisitos de Software
Diseo de software La organizacin de los captulos KA es
compatible con el tercero de los objetivos de una
Construccin de software caracterizacin del proyecto de los contenidos de
Pruebas de software la ingeniera de software. Las especificaciones
Mantenimiento del software detalladas proporcionadas por el equipo de
Gestin de la Configuracin de Software redaccin del proyecto para los editores
asociados en relacin con los contenidos de las
Gestin de Ingeniera de Software descripciones KA se pueden encontrar en el
Proceso de Ingeniera de Software Apndice A.
Modelos de Ingeniera de Software y Mtodos La Gua se usa una organizacin jerrquica
Calidad del software para descomponer cada KA en un conjunto de
temas con etiquetas tificables daciones. Un
Ingeniera de Software Prctica Profesional desglose de nivel dos (a veces tres) proporciona
Economa Ingeniera de Software una forma razonable para buscar temas de
Fundamentos de computacin inters. La gua trata los temas seleccionados de
Fundamentos matemticos una manera compatible con las principales
escuelas de pensamiento y con las averas que se
Fundamentos de ingeniera encuentran generalmente en la industria y en la
literatura de ingeniera de software y estndares.
Al especificar el alcance, tambin es Las averas de los temas no presumen dominios
importante adoptar la definicin de las particulares de aplicacin, usos comerciales,
disciplinas que se cruzan con la ingeniera de filosofas de gestin, mtodos de desarrollo, y
software. Con este fin, SWEBOK V3 tambin as sucesivamente. La extensin de la
reco- ognizes siete disciplinas relacionadas, que descripcin de cada tema es slo eso necesitaba
se enumeran en la tabla comprender la naturaleza generalmente aceptada
I.2. Los ingenieros de software deben, por de los temas y para que el lector encuentre xito
supuesto, tener conocimiento de material a partir material de referencia; el Cuerpo de
de estas disciplinas (y las descripciones KA en Conocimiento se encuentra en los materiales de
esta gua puede hacer referencia a ellos). No es, referencia a s mismos, no en la Gua.
sin embargo, un obje- tivo de la Gua SWEBOK
para caracterizar el conocimiento de las MATERIAL DE REFERENCIA Y MATRIZ
disciplinas relacionadas.
Para proporcionar acceso tpica en el
Tabla I.2. Disciplinas relacionadas conocimiento de la cuarta parte de los objetivos
del proyecto, la gua identifica material de
Ingeniera Informtica
referencia autorizada para cada KA. Apndice C
Ciencias de la Computacin proporciona una lista de referencia consolidado
Administracin General del Gua. Cada KA incluye referencias relevante
Matemticas de la lista consolidada de referen- cia y tambin
incluye una matriz que relaciona el material de
Gestin de proyectos
referencia para los temas incluidos.
Gestin de la calidad Cabe sealar que la Gua no pretende ser
Ingeniera de Sistemas exhaustivo en sus citas. Mucho material que es a
la vez conveniente y excelente no se hace
Los elementos pertinentes de la informtica y referencia. Material incluido en la lista de
las matemticas se presentan en los referencias Consolidated proporciona cobertura
Fundamentos de Informtica y Fundaciones KAs de los temas descritos.
matemticos de la Gua (captulos 13 y 14).
Profundidad del tratamiento
Gua
Para XXXII
lograrSWEBOK V3.0
el quinto objetivopro-SWEBOK
Viding una base para el desarrollo curricular,
 Introduccin xxxiii

certificacin y concesin de licencias, el criterio El desglose de los temas en cada KA consti-

de conocimiento gene- ralmente aceptada se ha tuye el ncleo la descripcin KA, que describen
aplicado, para distinguirse de un conocimiento la descomposicin de la KA en subreas, temas
avanzado y la investigacin (sobre la base de la y subtemas. Para cada tema o subtema, se da una
madurez) y de conocimiento especializado (por breve descripcin, junto con una o ms
motivos de generalidad de la solicitud). referencias.
El trmino equivalente reconocido El material de referencia fue elegido porque se
generalmente proviene del Instituto de Gestin considera que constituye la mejor presentacin
de Proyectos: Generalmente reconocido de los conocimientos en relacin con el tema.
significa el conocimiento y las prcticas Una matriz vincula los temas que el material de
descritas son aplicables a la mayora de los referencia.
proyectos, la mayor parte del tiempo, y no hay La ltima parte de la descripcin de cada KA
consenso sobre su valor y utilidad. 2 es la lista de referencias recomendadas y
Sin embargo, los trminos generalmente (opcionalmente) las lecturas ther de pieles.
aceptados o generalmente reconocido no normas pertinentes para cada KA se presentan
implican que el des- conocimiento ignated debe en el Apndice B de la Gua.
aplicarse de manera uniforme a todos los
esfuerzos de ingeniera de software, cada una de APNDICE A. KA Descripcin
las necesidades pro- yecto determinan que-pero Especificaciones
s implica que, ingenieros de software capaces
competentes deberan estar equipados con este Apndice A describe las especificaciones
conocimiento para su aplicacin potencial. Ms proporcionadas por el equipo editorial de los
precisamente, el conocimiento generalmente editores asociados de los contenidos, referencias,
aceptado debe ser incluido en el estudio de mate- formato y estilo de las descripciones KA
rial para la ingeniera de licencias de software recomendado.
exami- nacin que los graduados tomaran
despus de ganar cuatro aos de experiencia APNDICE B. ASIGNACIN DE
laboral. Aunque este cri- terio es especfico para Normaliza- cin A KAS
el estilo de los EEUU de la educacin y no
necesariamente se aplica a otros pases, Apndice B es una lista comentada de las
consideramos que es til. normas pertinentes, sobre todo del IEEE y de la
ISO, para cada una de la KAS de la Gua
ESTRUCTURA DE LAS DESCRIPCIONES SWEBOK.
KA
LISTA DE REFERENCIA APNDICE C.
Las descripciones KA se estructuran como sigue. CONSOLIDADO
En la introduccin, se presentan una breve
definicin de la KA y una visin general de su Apndice C contiene la lista consolidada de las
alcance y de su nave PARENTESCO con otros referencias citadas en reco- mienda la KAS
KAs. (estas referencias estn marcados con un
asterisco (*) en el texto).
2 Una gua para la Direccin de Proyectos del
Conocimiento, 5 ed, el Project Management
Institute, 2013.; www.pmi.org.
 REQUISITOS

CAPTULO 1 SOFTWARE

SIGLAS , No implica, sin embargo, que un ingeniero de

software no pudo realizar la funcin.
Confidencialidad, integridad y Un riesgo inherente en la descomposicin
CIA
Disponibilidad propuesta es que un proceso de cascada-como
TROZO Grfico Acclico Dirigido puede deducirse. Para evitar esto, el tema 2, los
DE
FSM Funcional de la medida del requisitos del proceso, est diseado para
CUERO proporcionar una visin general de alto nivel del
Consejo Internacional de Sistemas
INCOSE proceso de requisitos mediante el
Ingenieria
establecimiento de los recursos y las
UML Lenguaje de Modelado Unificado limitaciones con las que opera el proceso y que
SysML Sysml actan para configurarlo.
Una descomposicin alternativa podra utilizar
una estructura a base de pro- ducto (requisitos
INTRODUCCIN del sistema, los requisitos de soft- ware,
prototipos, casos de uso, y as sucesivamente).
El rea de conocimiento Requisitos de software La composicin basada en el proceso refleja el
(KA) se ocupa de la obtencin, anlisis, speci- hecho de que el proceso de requisitos, si ha de
ficacin, y la validacin de los requisitos de tener xito, debe ser considerada como un
software, as como la gestin de los requisitos proceso que implica actividades complejas,
Duran- todo el ciclo de vida del producto de fuertemente acoplados (tanto secuenciales y
software. Es ampliamente reconocido entre los simultneas), en lugar de como una discreta, de
investigadores y profesionales de la industria una sola vez la actividad realizada al inicio de un
que los proyectos de software son crticamente proyecto de desarrollo de software.
vulnerables cuando estn mal realizan las Los requisitos de software KA se relaciona
actividades relacionadas REQUISITOS. estrechamente con el diseo de software,
Requisitos de software expresan las pruebas de software, mantenimiento de software,
necesidades y limitaciones impuestas a un Software Configuration Management, Gestin
producto de software que contribuyen a la de Ingeniera de Software, Software de
solucin de algunos problemas del mundo real. Ingeniera de Procesos, Ingeniera de Software y
La ingeniera de requisitos plazo es Modelos Mtodos y Calidad de Software de Kas.
ampliamente utilizado en el campo para indicar
la manipulacin sistemtica de requisitos. Por DISTRIBUCIN DE TEMAS PARA
razones de coherencia, el trmino ingeniera REQUISITOS DEL SOFTWARE
no se utiliza en este KA excepto para la
ingeniera de software en s. El desglose de los temas de los requisitos de
Por la misma razn, ingeniero de requisitos, software KA se muestra en la Figura 1.1.
un trmino que aparece en la parte de la
literatura, no se utilizar tampoco. En cambio, el 1. Requisitos de software Fundamentos
trmino ingeniero de software o, en algunos [1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6,
casos especficos, los requisitos especialista se c12]
utilizar, este ltimo donde el papel en cuestin
se realiza generalmente por una persona que no 1.1. Definicin de un requisito de software
sea un ingeniero de software. Esta
En su forma ms bsica, un requisito de por algo en
software es una propiedad que debe ser exhibido

1-1
1-2 Gua SWEBOK V3.0

Figura 1.1. Desglose de temas para el KA Requisitos de software

Para resolver algn problema en el mundo real. requisitos pueden ser verificados dentro
Se puede tratar de automatizar parte de una tarea disponibles
para alguien para apoyar los procesos de negocio las limitaciones de recursos.
de una organiza- cin, para corregir defectos de Requisitos tienen otros atributos en adi- cin a
software existente, o para controlar un nombre las propiedades de comportamiento. Los
de dispositivo a slo algunos de los muchos ejemplos ms comunes incluyen una
problemas para los que son posibles soluciones clasificacin de prioridad para permitir
de software . Las formas en que los usuarios, compensaciones en la cara de los recursos finitos
pro- cesos de negocio, y dispositivos de funcin y un valor de estado para permitir el avance del
suelen ser complejas. Por extensin, por lo tanto, proyecto a vigilar. Tpicamente, los requisitos de
los requisitos de software de par- ticular son software son singularmente identificadas con los
tpicamente una compleja combinacin de varias de modo que puedan ser objeto de software de
personas en diferentes niveles de una gestin de con- figuracin durante todo el ciclo
organizacin, y que estn en una u otra manera de vida de la entidad y del software.
involucrados o relacionados con esta funcin del
entorno en el que el software operar. 1.2. Requisitos del producto y de proceso
Una propiedad esencial de todos los requisitos
de software es que sean verificables como una Un requisito de un producto es una necesidad o
caracterstica individual como requisito restriccin en el software que se desarrollarn
funcional o a nivel del sistema como un (por ejemplo, El software verificar que un
requisito no funcional. Puede ser difcil o estudiante cumple con todos los requisitos
costoso para verificar ciertos requisitos de soft- previos antes de que l o ella se registre en un
ware. Por ejemplo, la verificacin del requisito curso). Un requisito proceso es esencialmente
de caudal en un centro de llamadas puede hacer un con- straint en el desarrollo del software (por
necesario el desarrollo de software de ejemplo, El software se desarrolla utilizando
simulacin. Requisitos de software, ING un proceso RUP).
Ensayos software y personal de calidad debe Algunos de los requisitos de software generan
asegurar que el implcita
los requisitos del proceso. La eleccin de la Requisitos de software 1-3
verificacin
1-4 Gua SWEBOK V3.0

tcnica es un ejemplo. Otro podra ser el uso de y, en su caso, cuantitativamente. Es importante

tcnicas de anlisis particularmente rigurosas evitar los requisitos de vagas y no verificables que
(tales como los mtodos de especificacin
formal) para reducir los fallos que pueden
conducir a insuficiente fiabilidad. requisitos pro-
ceso Tambin pueden imponerse directamente
por la organizacin de desarrollo, su cliente, o
un tercero, tal como un regulador de la
seguridad.

1.3. Requisitos funcionales y no funcionales

Funcional requisitos describen las funciones

que el software es ejecutar; por ejemplo, para-
estera algn texto o la modulacin de una seal.
A veces se conocen como capacidades o
caractersticas. Un requisito funcional tambin
puede ser descrito como uno para el cual un
conjunto finito de pasos de prueba se puede
escribir para validar su comportamiento.
no funcional los requisitos son los que actan
para limitar la solucin. Los requisitos no
funcionales son a veces conocidos como las
restricciones o requisitos de calidad. Pueden ser
ms clasifi- sified de acuerdo a si son los
requisitos de rendimiento, requisitos de
mantenimiento, requisitos de seguridad,
requisitos de fiabilidad, requisitos de seguridad,
requisitos de interoperabilidad o uno de muchos
otros tipos de requisitos de software (ver
modelos y carac- tersticas de la Calidad La
calidad del software KA).

1.4. Propiedades emergentes

Algunos requisitos representan emergentes

como propiedades del software, es decir,
requisitos que no pueden ser tratados por un solo
componente, sino que depender de cmo
interacten todos los componentes de software.
El requisito de caudal para un centro de
llamadas, por ejemplo, depender de cmo el
sistema telefnico, sistema de informacin, y los
operadores de todos interactuaron en
condiciones reales de explota- cin. Las
propiedades emergentes dependen
fundamentalmente de la arquitectura del sistema.

1.5. Requisitos cuantificables

Requisitos de software deben expresarse tan

claramente y sin ambigedad como sea posible,
 software. Requisitos de software 1-5
dependen para su interpretacin en un juicio
subjetivo ( el software ser fiable, el
software debe ser fcil de usar). Esto es
Particularmente importante para los requisitos
no funcionales. Dos ejemplos de requisitos
cuantificados son los siguientes: software de un
centro de llamadas debe aumentar el
rendimiento del centro en un 20%; y un
sistema tendr una probabilidad de generar un
error fatal durante cualquier hora de operacin
de menos de 1 * 10 8. El requisito de caudal
est en un nivel muy alto y tendr que ser
utilizado para derivar una serie de requisitos
detallados. El requisito dad fiabili- ser
fuertemente restringir la arquitectura del
sistema.

1.6. Requisitos del sistema y

requisitos de software

En este tema, los medios del sistema

una combinacin de interaccin de

elementos para llevar a cabo un objetivo
definido. Estos incluyen elementos de
hardware, software, firmware, personas,
informacin, tcnicas, instalaciones,
servicios y otros apoyos,

como se define por el Consejo Internacional de

Soft- ware y Ingeniera de Sistemas (INCOSE)
[3].
Sistema los requisitos son los requisitos para
el sistema en su conjunto. En un sistema que
contiene los componentes de software,
requisitos de software se derivan de requisitos
del sistema.
Esta KA define las necesidades del usuario
en forma restringida, como los requisitos de los
clientes del sis- tema o usuarios finales. Los
requisitos del sistema, por el contrario, abarcan
necesidades de los usuarios, los requisitos de
otras partes interesadas (tales como las
autoridades miento de reglamentacin mentos),
y los requisitos sin una fuente humana
identificable.

2. requisitos Proceso
[1 *, c4s4] [2 *, C1-4, c6, c22,
c23]

En esta seccin se presenta el proceso de

requisitos de software, la orientacin de los
cinco temas restantes y mostrando cmo el
proceso se ajusta perfectamente a los requisitos
del proceso general de la ingeniera de
1-6 Gua SWEBOK V3.0

2.1. Los modelos de proceso que han encargado el software o que

REPRESENTA mercado objetivo del
El objetivo de este tema es el de proporcionar un software.
entendimiento de que el proceso de requisitos Los analistas de mercado: un producto de
mercado masivo
no es una actividad discreta front-end del no tendr un cliente de puesta en marcha, por
ciclo de vida soft- ware, sino ms bien un lo
proceso iniciado en el comienzo de un
proyecto que contina para ser refinado
durante todo el ciclo de vida;
identifica los requisitos de software como
elementos de configuracin y los gestiona
utilizando las mismas prcticas de gestin
de configuracin de software como otros
productos de los procesos del ciclo de vida
del software;
necesita ser adaptado al contexto de la
organizacin y del proyecto.

En particular, el tema tiene que ver con cmo

se configuran las actividades de obtencin,
anlisis, especifica- cin y validacin para
diferentes tipos de proyectos y limitaciones. El
tema tambin incluye actividades que
proporcionan la entrada en el proceso de
requisitos, tales como la comercializacin y la
factibilidad estudios.

2.2. Los actores del proceso

Este tema se presentan las funciones de las

personas que participan en el proceso de
requisitos. Este pro- ceso es fundamentalmente
interdisciplinario, y el especialista requisitos
necesita para mediar entre el dominio de la parte
interesada y la de ingeniera de soft- ware. A
menudo hay muchas personas involucradas,
adems del especialista requisitos, cada uno de
los cuales tiene una participacin en el
programa. Los titulares stake- variarn segn los
proyectos, pero siempre incluirn los usuarios /
operadores y clientes (que no tiene por qu ser el
mismo).
Ejemplos tpicos de grupos de inters de
software
incluir (pero no se limitan a) los siguientes:

Usuarios: Este grupo comprende aquellos

que operar el software. A menudo es un
grupo heterogneo que implica a personas
con diferentes roles y necesidades.
Clientes: Este grupo comprende aquellos
 la gente de marketing son a menudo calidad y la mejora del procesoRequisitos de software
de requisitos. Su 1-7
necesarios para esta- blecer las propsito es hacer hincapi en el papel clave que
necesidades del mercado y para actuar desempea el proceso de requerimientos en
como clientes de proxy. trminos de la
Reguladores: Muchos dominios de
aplicacin, como la banca y el transporte
pblico, son re- gulada. Software en estos
mbitos debe com- capas con los
requisitos de las autoridades reguladoras.
Los ingenieros de software: Estos
individuos tienen un inters legtimo en
sacar provecho de desa- oping el software,
por ejemplo, la reutilizacin de
componentes o de otros productos. Si, en
este escenario, un cliente de un producto
particu- lar tiene requisitos especficos que
comprometen la posibilidad de
reutilizacin de componentes, los
ingenieros de software deben sopesar
cuidadosamente su propio juego contra los
del cliente. Los requisitos especficos, las
limitaciones particular- mente, pueden
tener un impacto importante en el precio o
la entrega del proyecto, ya sea porque se
ajustan bien o mal con el conjunto de
habilidades de los ingenieros. ventajas y
desventajas importantes entre estos
requisitos deben ser identificados.

No ser posible satisfacer perfectamente las

necesidades de todas las partes interesadas, y
es el trabajo del ingeniero de software para
negociar compensaciones que sean aceptables
para los principales grupos de inters y dentro
de las limitaciones presupuestarias, tcnicas,
normativas, y otros. Un requisito previo para
esto es que se identifique a todos los
interesados, la naturaleza de su juego
analizados y sus requisitos provocaron.

2.3. Administracin y Apoyo Proceso

Esta seccin presenta los recursos de gestin

de proyectos requeridos y consumidos por el
proceso de los requisitos. Se establece el
contexto para el primer tema (Iniciacin y
Definicin del Alcance) del Software
Engineering Management KA. Su objetivo
prin- cipal es hacer que el vnculo entre las
actividades pro- ceso identificados en 2.1 y los
problemas de costo, recursos humanos,
capacitacin y herramientas.

2.4. Proceso de Calidad y Mejora

En este tema se refiere a la evaluacin de la

1-8 Gua SWEBOK V3.0

costo y puntualidad de un producto de software los usuarios de software / titulares stake- e

y de la satisfaccin del cliente con l. Esto ingenieros de software.
ayudar a orientar el proceso de requisitos de Un elemento crtico de la obtencin de
calidad con Dardos Estn- y modelos de mejora requisitos est informando al alcance del
de procesos para las mercancas y los sistemas proyecto. Esto implica proporcio- nando una
blandas. La calidad del proceso y la mejora est descripcin del software que se especifica y su
estrechamente relacionado tanto a la calidad del propsito y dar prioridad a los entregables
software y KA KA Proceso de Ingeniera de
Software, que comprende

la cobertura proceso de requisitos de

proceso
normas y modelos de mejora;
requirementsprocessmeasuresand

la evaluacin comparativa;
planificacin de la mejora e
implementacin;
seguridad / CIAimprovement / planningand

implementacin.

3. la obtencin de requisitos
[1 *, c4s5] [2 *, c5, c6,
c9]

La obtencin de requisitos tiene que ver con los

orgenes de los requisitos de software y cmo el
ingeniero de software puede recogerlos. Es la
primera etapa en la construccin de una
comprensin del problema se requiere el
software de resolver. Es recuento fundamen- una
actividad humana y es donde se identifican las
ERS stakehold- y las relaciones establecidas
entre el equipo de desarrollo y el cliente. Se
denomina diversamente captura de requisitos,
requisitos descubrimiento y adquisicin
requisitos.
Uno de los principios fundamentales de un
buen proceso de obtencin requisitos es el de la
comunicacin tivo effec- entre los distintos
titulares stake-. Esta comunicacin contina con
el proceso entero de desarrollo de software del
Ciclo de Vida (SDLC) con diferentes actores a
diferentes puntos en el tiempo. Antes de que
comience el desarrollo, los especialistas
requisitos pueden formar el conducto para esta
comunicacin. Deben Medi comieron entre el
dominio de los usuarios de software (y otras
partes interesadas) y el mundo de la tcnica del
ingeniero de software. Un conjunto de modelos
internamente consistentes en diferentes niveles
de abstraccin facilitar las comunicaciones entre
 Requisitos de software
polticas de la organizacin 1-9
al cliente
para garantizar las necesidades de negocios
ms importantes del cliente son las primeras en central. El ingeniero de software tiene que
cubrirse. Esto minimiza el riesgo de identificar, representar y administrar
especialistas necesidades de gasto de tiempo
elicit- requisitos de ING que son de poca
importancia, o los que resultan ser ya no es
relevante cuando se entrega el software. Por
otra parte, la descripcin debe ser escalable y
extensible para aceptar otras exigencias no se
expresa en las primeras listas formales y
compatibles con los anteriores como se
contempla en mtodos recursivos.

3.1. requisitos Fuentes

Requisitos tienen muchas fuentes en cermica

tpica blandas, y es esencial que se identifican
y evalan todas las fuentes potenciales. Este
tema est diseado para promover el
conocimiento de las diversas fuentes de
requisitos de software y de los marcos para la
gestin de los mismos. Los principales puntos
cubiertos son los siguientes:

Metas. El trmino objetivo (a veces

llamada empresa comercial o crtico de
xito fac- tor) se refiere a los objeti- vos
generales, de alto nivel de software.
Objetivos proporcionan la motiva- cin
para el software, pero a menudo son muy
vago. Los ingenieros de software deben
prestar especial atencin a la evaluacin
del valor (en relacin a la prioridad) y el
costo de las metas. Un estudio de
factibilidad es una forma relativamente
barata de hacer esto.
Conocimiento del dominio. El ingeniero
de software necesita para adquirir o tener
El conocimiento disponible sobre el
dominio de aplicacin. conocimiento del
dominio proporciona el contexto en el que
todo el conocimiento requisitos provocada
debe ajustarse con el fin de entenderlo.Es
una buena prctica para emular un enfoque
ontolgico en el dominio del
conocimiento. relacio- nes entre los
conceptos relevantes dentro del dominio
de aplicacin deben ser identificados.
Las partes interesadas (vase la seccin
2.2, actores del proceso). Gran parte del
software ha demostrado ser insatisfactorio
porque ha hecho hincapi en las
exigencias de un grupo de interesados a
expensas de los dems. Por lo tanto, el
software entregado es difcil de usar, o
subvierte las estructuras culturales o
1-10 Gua SWEBOK V3.0

los puntos de vista de muchos tipos incluso si las cooperativas interesadas y

diferentes de articulados estn disponibles, el ingeniero de
grupos de inters. software tiene que trabajar duro para obtener la
Reglas del negocio. Estas son declaraciones informacin correcta. Muchos de los requisitos de
que definen o limitan algn aspecto de la negocio o tcnicas son tcito o en la
estruc- tura o el comportamiento de la retroalimentacin que
propia empresa. Un estudiante no puede
inscribirse en los cursos del prximo
semestre si quedan algunos derechos de
matrcula no pagados sera un ejemplo de
una regla de negocio que sera una fuente
requisito para el software del curso-registro
de una uni- versidad.
El entorno operativo. Requisitos se derivan
del entorno en el que se ejecutar el
programa. Estos pueden ser, por ejemplo,
las limitaciones de tiempo en las
restricciones del software o de rendimiento
en tiempo real en un entorno empresarial.
Estos deben ser buscados activamente, ya
que pueden afectar en gran medida la
viabilidad y el costo de software as como
restringir las opciones de diseo.
El entorno de la organizacin. El software
se requiere a menudo para apoyar un pro-
ceso de negocios, la seleccin de los cuales
puede ser condicionado por la estructura, la
cultura y la poltica interna de la
organizacin. El ingeniero de software tiene
que ser sensible a stos, ya que, en general,
el nuevo software no debe forzar el cambio
no planificado en el proceso de negocio.

3.2. tcnicas de obtencin

Una vez que las fuentes de requisitos se han

iden- tificado, el ingeniero de software puede
iniciar la obtencin de informacin de los
requisitos de los mismos. Tenga en cuenta que
los requisitos rara vez se suscit confeccionada.
Ms bien, el ingeniero de software obtiene
informacin de la que l o ella formula
requisitos. Este tema se centra en tcnicas para
conseguir los interesados humanos para articular
la informacin relevante REQUISITOS. Es una
tarea muy difcil y el ingeniero de software es
necesario sensibilizar al hecho de que (por
ejemplo) los usuarios pueden tener dificultades
para describir sus tareas, puede dejar infor-
macin importante no declarada, o pueden ser
dispuestos o no pueden cooperar. Es
particularmente importante entender que la
provocacin no es una actividad pasiva y que,
 Requisitos de software
superficie utilizando entrevistas. Otra 1-11
an no se ha obtenido a partir de los usuarios
finales. La importancia de la planificacin, ventaja es que los requisitos conflictivos
verificacin y validacin en la obtencin de superficie desde el principio en una forma
requisitos no puede ser exagerada. Existe un que permite a las partes interesadas
nmero de tcnicas para los requisitos de elici- reconocen cuando stos se producen.
tacin; las principales son las siguientes: Cuando funciona bien, esta tcnica

Entrevistas. Entrevistando a las partes

interesadas es un medio tradicional de
provocar requisitos. Es importante
entender las ventajas y limitaciones de las
entrevistas y la forma en que debe llevarse
a cabo.
Escenarios. Escenarios proporcionan un
medio valioso para proporcionar contexto
a la cin elicita- de requisitos del usuario.
Permiten que el ingeniero de software para
proporcionar un marco para las preguntas
sobre las tareas del usuario al permitir que
qu pasara si y cmo se hace
preguntas que se le pregunte. El tipo ms
comn de escena- rio es la descripcin de
casos de uso. Hay un enlace aqu al Tema
4.2 (Modelado Conceptual) debido a las
notaciones de escenarios tales como
diagramas de casos de uso son comunes en
el software de modelado.
Prototipos. Esta tcnica es una herramienta
valiosa para aclarar los requisitos
ambiguos. Pueden actuar de una manera
similar a los escenarios por los pro-
usuarios Viding con un contexto en el que
puedan entender mejor lo que la
informacin que necesitan para ofrecer.
Hay una amplia gama de tcnicas-de
prototipado ups papel maqueta de diseos
de pantalla a las versiones de las pruebas
beta de productos de software y un fuerte
solapamiento de sus usos separados para
requisitos elicita- cin y para la validacin
de los requisitos (vase la seccin 6.2,
Prototyping) . Baja fidelidad prototipos se
prefieren a menudo para evitar que las
partes interesadas anclaje en la carac-
tersticas de menor importancia, incidental
de un prototipo de mayor calidad que
puede limitar la flexibilidad de diseo de
formas no deseadas.
reuniones facilitadas. El propsito de estas
reuniones es tratar de lograr un efecto
acumulativo, por el que un grupo de
personas puede traer ms informacin
sobre sus exigencias de software que
trabajando individualmente. Pueden
intercambiar ideas y refinar las ideas que
pueden ser difciles de llevar a la
1-12 Gua SWEBOK V3.0

puede resultar en un conjunto ms rico y determinar si se han cumplido los objetivos de

ms coherente de los requisitos que de otro la historia de usuario.
modo podran ser alcanzables. Sin embargo, Otras tcnicas. Una variedad de otras tcnicas
las reuniones deben ser manejados con para el apoyo a la obtencin de informacin de
cuidado (de ah la necesidad de un los requisitos existen y van desde el anlisis de
facilitador) para evitar una situacin en la productos de la competencia para aplicar los
que las habilidades crticas del equipo son datos min-ing tcnicas para el uso de fuentes de
erosionadas por la lealtad al grupo, o en las bases de datos de conocimiento de dominio o
que los requisitos que reflejan las peticin del cliente.
preocupaciones de unos pocos pelos en la
lengua (y quizs de alto nivel) las personas
que se ven favorecidas en detrimento de
otros.
Observacin. La importancia del contexto
de software dentro de la ment ENTORNO
organizacin ha llevado a la adaptacin de
las tcnicas observacionales tales como la
etnografa para la obtencin de requisitos.
Los ingenieros de software aprenden acerca
de las tareas del usuario mediante la
inmersin de s mismos en el medio
ambiente y la observacin de cmo los
usuarios realizan sus tareas mediante la
interaccin con los dems y con
herramientas de software y otros recursos.
Estas tcnicas son relativamente caros, sino
tambin instructiva porque ilustran que
muchas tareas de usuario y procesos de
negocio son demasiado sutil y complejo por
sus actores para describir fcilmente.
Historias de usuarios. Esta tcnica se utiliza
comnmente en los mtodos de adaptacin
(ver Mtodos giles en los modelos de
ingeniera de software y Mtodos Ka) y se
refiere a las descripciones de nivel cortos,
de alta de funcionalidad requerida expresada
en trminos de los clientes. Una historia de
usuario tpico tiene la siguiente forma:
Como <funcin>, quiero
<Meta / deseo> de manera que
<beneficiar> . Una historia de usuario est
destinado a contener suficiente informa-
cin para que los desarrolladores pueden
producir una estimacin razonable del
esfuerzo para que las aplicar. El objetivo es
evitar algunos de los residuos que sucede a
menudo en proyectos en los que se
utilizarn para reunir los requisitos
detallados temprano, pero se han invalidado
antes de que comience el trabajo. Antes se
implementa una historia de usuario, un
procedimiento de acep- tacin adecuada
debe ser escrita por el al cliente central para
 Requisitos de software 1-13
4. Anlisis de requerimientos
[1 *, c4s1, c4s5, c10s4,
c12s5] [2 *, c7,
c11, c12, c17]

Este tema tiene que ver con el proceso de ana-

requisitos lyzing a

detectar y resolver los conflictos entre

los requisitos;
descubrir los lmites del software y
cmo debe interactuar con su entorno
organizacional y operativa;
requisitos del sistema elaborados para
derivar los requisitos de soft- ware.

La visin tradicional de anlisis de

requisitos ha sido que ser reducido a ing
modelo- conceptual usando uno de una serie
de mtodos de anlisis, tales como el mtodo
de anlisis estructurado. Si bien el modelado
conceptual es importante, incluimos la
clasificacin de los requisitos para ayudar a
informar a soluciones de compromiso entre
los requisitos (clasificacin requisitos) y el
proceso de creacin de estas compensaciones
(requisitos de negociacin).
Se debe tener cuidado para describir los
requisitos de forma suficientemente precisa
para permitir que los requisitos para ser
validados, su aplicacin a ser verificada, y
sus costes a estimar.

4.1. requisitos Clasificacin

Los requisitos pueden ser clasificadas en

varias dimensiones. Ejemplos incluyen los
siguientes:

Si el requisito es funcional o no
funcional (ver seccin 1.3, funcional y
requerimientos no funcionales).
Si el requisito se deriva de uno o ms
requisitos de alto nivel o una propiedad
de gent gencia (vase la seccin 1.4,
propiedades emergentes), o est siendo
impuesta directamente en el software
por un actor o alguna otra fuente.
Si el requisito es en el producto o el
proceso (ver seccin 1.2, producto y
requisitos del proceso). Requisitos en el
proceso pueden limitar la eleccin de
Tor contraccin, el proceso de
ingeniera de software para ser
adoptado, o las normas que deben ser
respetados.
1-14 Gua SWEBOK V3.0

La prioridad requisito. Cuanto mayor sea la seccin 7.3, Requisitos de atributos).

priori- dad, ms esencial es el requisito para
cumplir con los objetivos generales del
software. A menudo clasificada en una
escala de coma fija como obligatoria,
altamente deseable, deseable u opcional, la
prioridad que a menudo tiene que ser equili-
brada con el coste de desarrollo e
implementacin.
El alcance de la prescripcin. mbito de
aplicacin se refiere a la medida en que un
requisito afecta a los componentes de
software y de software. Algunos de los
requisitos, en especial a algunos que no
funcionales, tienen un alcance global en que
su satisfaccin no puede ser asignado a un
componente discreto. Por lo tanto, un
requisito de mbito global puede afectar en
gran medida la arquitectura de software y el
diseo de muchos componentes, mientras
que uno con un alcance limitado puede
ofrecer una serie de opciones de diseo y
tienen poco impacto en la satisfaccin de
otras necesidades.
Volatilidad / estabilidad. Algunos de los
requisitos cambiarn durante el ciclo de
vida de la Cesin de Software, e incluso
durante el propio proceso de desarrollo. Es
til si alguna estimacin de la probabilidad
de que va a cambiar un requisito se puede
hacer. Por ejemplo, en una aplicacin de
ING banco-, los requisitos para las
funciones para el clculo y el inters de
crdito a las cuentas de los clientes tienden
a ser ms estable que un requisito para
apoyar un tipo particular de cuenta libre de
impuestos. El primero refleja una
caracterstica funda- mental del dominio
bancario (cuentas que pueden ganar
intereses), mientras que los segundos
pueden dejarlo obsoleto por un cambio a la
legislacin gubernamental. Marcar
requisitos potencialmente voltiles puede
ayudar al ingeniero de software de
establecer un diseo que es ms hormiga
tolerar de cambio.

Otras clasificaciones pueden ser apropiadas,

dependiendo de Tice prc- normal de la
organizacin y la propia aplicacin.
Hay una fuerte superposicin entre atributos
requisitos de clasificacin y requisitos (ver
4.2. Modelado conceptual comenzar la construccin deRequisitos de software
un modelo del 1-15
contexto del software. El contexto software
El desarrollo de modelos de un problema del proporciona una conexin entre los programas
mundo real es clave para el anli- sis requisitos informticos destinados y su entorno externo.
de software. Su propsito es ayudar a
comprender la situacin en la que se produce el
problema, as como que representa una
solucin. Por lo tanto, los modelos
conceptuales comprenden modelos de
entidades del dominio del problema,
configurado para reflejar sus relaciones y
dependencias del mundo real. Este tema est
estrechamente relacionado con las els
Ingeniera de Software y Mtodos Mod-KA.
Hay varios tipos de modelos pueden ser
desarrollados. Estos incluyen diagramas de
casos de uso, los modelos de flujo de datos,
modelos de estado, los modelos basados en
objetivos, las interacciones del usuario,
modelos de objetos, modelos de datos, y
muchos otros. Muchas de estas notaciones de
modelado son parte del lenguaje de modelado
unificado (UML). Utilice diagramas de casos,
por ejemplo, se utilizan rutinariamente para
representar escenarios en los que el lmite que
separa a los actores (usuarios o sistemas en el
ronment bientes externa) del comportamiento
interno donde cada caso de uso representa una
funcionalidad del sistema.
Los factores que influyen en la eleccin de la
notacin ing modelo- incluyen los siguientes:

La naturaleza del problema. Algunos tipos

de software bajo demanda que ciertos
aspectos sean ana- lisadas particularmente
rigurosa. Para modelos de ejemplo,
estatales y paramtricos, que son parte de
SysML [4], es probable que sean tant ms
impor- por software en tiempo real que
para los sistemas informa- cin, al tiempo
que normalmente sera el opuesto para
modelos de objetos y de la actividad.
La experiencia del ingeniero de software.
A menudo es ms productivo para adoptar
una notacin de modelado o mtodo con el
que el ingeniero de software con
experiencia.
Los requisitos del proceso del cliente (ver
seccin 1.2, el producto y los
requerimientos del proceso). Los clientes
pueden imponer su notacin o mtodo
favorecido o prohibir cualquier con las que
estn familiarizados. Este factor puede
entrar en conflicto con el factor anterior.

Nota que, en casi todos los casos, es til

1-16 Gua SWEBOK V3.0

Esto es crucial para la comprensin de con- propiedades Gent (tales como el peso del coche)
texto del software en su entorno operativo y para para identificar la detallada requisitos de software
que identifique los valores de sus interfaces con ABS. El diseo arquitectnico est estrechamente
el medio ambiente. identificada con el modelado conceptual (ver
Este subtema no busca ensear a un estilo seccin 4.2, conceptual
de modelado particu- lar o anotacin, sino ms Modelado).
bien proporciona orientacin sobre el propsito
e intencin de modelado.

4.3. Diseo y requisitos arquitectnicos

Asignacin

En algn momento, la arquitectura de la

solucin debe ser derivado. El diseo
arquitectnico es el punto en el que el proceso se
superpone con los requisitos de software o
sistemas de diseo e ilustra lo imposible que es
disociar limpiamente las dos tareas. Este tema
est estrechamente relacionada con la estructura
y arquitectura de software en el diseo de
software KA. En muchos casos, el ingeniero de
software acta como arquitecto de software
debido a que el proceso de anlisis y elaboracin
de los requisitos que exige ser identificados los
componentes / diseo de arquitectura que se
encargarn de satisfacer los requisitos. Esta es la
asignacin de-la requisitos de asignacin a
componentes de la arquitectura respon- sable
para satisfacer los requisitos.
La asignacin es importante para permitir Ysis
anal-detallado de las necesidades. Por lo tanto,
por ejemplo, una vez que un conjunto de
requisitos se ha asignado a un componente, los
requisitos individuales se pueden analizar an
ms para descubrir nuevos requisitos sobre cmo
el componente tiene que interactuar con otros
componen- tes con el fin de satisfacer el requisito
asignado mentos. En grandes proyectos, la
asignacin estimula una nueva ronda de anlisis
para cada subsistema. Como ejemplo, los
requisitos para un rendimiento determinado de
frenado para un coche (distancia de frenado, la
seguridad en condiciones de conduccin pobres,
suavidad de apli- cacin, la presin del pedal
necesarios, y as sucesivamente) puede ser
asignada al hardware de frenado (conjuntos
mecnicos e hidrulicos) y un sistema de frenado
antibloqueo (ABS). Slo cuando un requisito para
un sistema antibloqueo de frenos ha sido
identificado, y los requerimientos asignados a
ella, se pueden utilizar los lazos capabili- del
ABS, el hardware de frenado, y emer-
 Requisitos de software 1-17
4.4. requisitos de Negociacin

Otro trmino comnmente utilizado para este

subtema es resolucin de conflictos. Esto se
refiere resolv- ing problemas con los requisitos
donde los conflictos se producen entre dos
actores que requieren mutu- caractersticas
aliado incompatibles, entre las necesidades y
los recursos, o entre los requisitos funcionales
y no funcionales, por ejemplo, . En la mayora
de los casos, no es aconsejable para el
ingeniero de software para hacer una decisin
unilateral, lo que se hace preciso proceder a
consultar con la parte interesada (s) para llegar
a un consenso sobre una compensacin
adecuada. A menudo es importante, por
razones contractuales, que tales las decisiones
sean detectables de nuevo al cliente. Hemos
clasificado esto como un tema de anlisis de
requisitos de software debido a problemas
surgen como el resultado del anlisis. Sin
embargo, un fuerte caso tambin se puede
hacer por considerarlo un tema de validacin
de requisitos (ver tema 6, los requisitos de
validacin).
Requisitos priorizacin es necesario, no slo
como un medio para filtrar los requisitos
importantes, sino tambin con el fin de resolver
los conflictos y el plan de entregas
escalonadas, lo que significa tomar decisiones
complejas que requieren el conocimiento de
dominio detallado y buenas habilidades de
estimacin. Sin embargo, a menudo es difcil
obtener informacin real que puede actuar
como base para este tipo de decisiones.
Adems, los requisitos a menudo dependen
unos de otros, y prioridades son relativos. En la
prctica, los ingenieros de software realizan
requisitos priorizacin con frecuencia sin
necesidad de conocer todos los requisitos.
Requisitos priorizacin puede seguir un
enfoque de valor de costo que implica un
anlisis de las partes interesadas en una escala
que definen los beneficios o el valor agregado
que el cin Ejecucin del requisito les lleva,
en comparacin con las penas de no haber
implementado un requisito particular. Tambin
implica un anlisis de los ingenieros de
software de estimacin en una escala el costo
de la implementacin de cada requisito, en
relacin con otros requisitos. Otro enfoque
oritization pri- requisitos llama el proceso
analtico jerrquico implica comparar todos los
pares nicos de los requisitos para determinar
cul de los dos es de mayor prioridad, y en qu
medida.
1-18 Gua SWEBOK V3.0

4.5. Anlisis formal

Para la mayora de las carreras de ingeniera, el
preocupaciones formales de anlisis no slo el trmino memoria descriptiva se refiere a la
tema 4, sino tambin las secciones 5.3 y 6.3. En asignacin de valores numricos o los lmites a
este tema tambin se relaciona con mtodos los objetivos de diseo de un producto. En la
formales en los modelos de ingeniera de ingeniera de software, especificacin de
software y mtodos rea de Conocimiento. requisitos de software tpicamente se refiere a la
Anlisis formal ha hecho un impacto en produccin de
algunos dominios de aplicacin, en particular los
de los sistemas de alta integridad. La expresin
formal de requisitos requiere una lengua con la
semntica formalmente definidos. El uso de un
anlisis formal para la expresin requisitos tiene
dos ventajas. En primer lugar, permite a los
requisitos expresados en el idioma que se
especifique con precisin y forma ambigua, por
lo tanto (en principio) para evitar la posibilidad
de una mala interpretacin. En segundo lugar,
los requisitos se puede razonar sobre,
permitiendo propiedades deseadas del software
especificado para ser probada. razonamiento
formal requiere soporte de herramientas para ser
practicable para distintos de los sistemas
triviales nada, y herramientas generalmente se
dividen en dos tipos: los demostradores de
teoremas o las damas modelo. En ninguno de los
casos puede ser totalmente automatizado prueba,
y el nivel de competencia en razonamiento
formal sea necesario con el fin de utilizar las
herramientas restringe la aplicacin ms amplia
de anlisis formal.
El anlisis ms formal, se centra en etapas
relativamente tardas de anlisis de requisitos. Es
general- mente contraproducente para solicitar la
formalizacin hasta que los objetivos de negocio
y necesidades de los usuarios han entrado en un
enfoque ntido a travs de medios tales como los
descritos en otras partes de la seccin 4. SIN
EMBARGO, una vez que los requisitos se han
estabilizado y se han elaborado para especificar
propie- concreto lazos del software, puede ser
beneficioso para para- malize al menos los
requisitos crticos. Esto per- mite la validacin
esttica que el software especificado por los
requisitos s tiene las pro- piedades (por
ejemplo, ausencia de estancamiento) que el
cliente, los usuarios, y el ingeniero de software
de esperar que tenga.

5. Especificacin de requisitos
[1 *, c4s2, c4s3, c12s2-5] [2 *,
c10]
 Requisitos de software 1-19
un documento que pueda ser revisado de forma
sistemtica, evaluada y aprobada. Para
sistemas complejos, especialmente aquellos
que involucran componentes mercancas
nonsoft- sustanciales, como se producen hasta
tres diferentes tipos de documentos: sistema de
defini- cin, requisitos del sistema y los
requisitos de software. Para los productos de
software simple, slo se requiere el tercero de
estos. Los tres documentos se describen aqu,
con el entendimiento de que se pueden
combinar segn sea apropiado. Una
descripcin de la ingeniera de sistemas se
puede encontrar en las disciplinas de Ingeniera
de Software captulo de esta gua relacionadas.

5.1. Definicin del sistema de documentos

Este documento (a veces conocido como el

documento de requerimientos del usuario o el
concepto de documento de operaciones)
registra los requisitos del sistema. Define los
requisitos del sistema de alto nivel de la
perspectiva de dominio. Su nmero de lectores
incluye representantes de los usuarios del
sistema / clientes (marketing puede
desempear estas funciones para el software
impulsado de mercado), por lo que su
contenido debe ser expresada en trminos de
dominio. El documento enumera los requisitos
del sistema, junto con la informacin de fondo
sobre los objetivos globales para el sistema, su
entorno de destino, y una declaracin de las
limitaciones, supuestos y requisitos no
funcionales. Puede incluir modelos
conceptuales diseados para ilustrar el
contexto del sistema, escenarios de uso, y las
principales entidades de dominio, as como los
flujos de trabajo.

5.2. Requisitos del sistema Especificacin

Los desarrolladores de sistemas con software

sustancial y componentes de un forro de aire
moderno nonsoftware, por ejemplo, a menudo
se separan de la descripcin de los requisitos
del sistema de la descripcin de los requisitos
de software. En esta vista, se especifican los
requisitos del sistema, los requisitos de
software se derivan de los requisitos del
sistema y, a continuacin los requisitos para el
software com- ponentes se especifican. En
sentido estricto, la especificacin de los
requisitos del sistema es un sistema de
Engineer- ing actividad y queda fuera del
alcance de esta gua.
 Requisitos de software 1-11

5.3. Especificacin de Requerimientos de software individuales son imperativos, directivas,

Software frases dbiles, opciones y ANCES continuidades.
Indicadores para todo el documento de
especificacin de requisitos de software especificacin de software exigencias incluyen el
establece la base para un acuerdo entre los tamao, la capacidad de lectura, la especificacin,
clientes y los contratistas o proveedores (en la profundidad y la estructura del texto.
proyec- tos impulsados por el mercado, estas
funciones pueden ser jugados por las divisiones
de marketing y desarrollo) en lo que el producto
de software es a hacer, as como lo que no es
espera que lo haga.
especificacin de requisitos de software
permite una evaluacin rigurosa de los requisitos
de diseo antes de comenzar y se reduce el
rediseo ms tarde. Tambin debe proporcionar
una base realista para ing realizan estimaciones
los costos del producto, riesgos y horarios.
Las organizaciones tambin pueden utilizar un
documento de especificacin de los requisitos de
software de base para la elaboracin de planes
eficaces de verificacin y validacin.
especificacin de requisitos de software
proporciona una base informada para la
transferencia de UCT un software
PRODUCIRSE a nuevos usuarios o plataformas
de software. Por ltimo, puede proporcionar una
base para la mejora del software.
Requisitos de software a menudo se escriben
en lenguaje natural, pero, en la especificacin de
requisitos de software, esto puede
complementarse con for- mal o descripciones
semiformales. La seleccin de las anotaciones
apropiadas permite particulares los requisitos y
aspectos de la arquitectura de software que se
describirn con mayor precisin y concisin de
lenguaje natural. La regla general es que ciones
notaciones se deben utilizar que permiten los
requisitos que se describen tan precisamente
como sea posible. Esto es particularmente
crucial para crticos para la seguridad,
regulacin, y ciertos otros tipos de software
fiable. Sin embargo, la eleccin de la notacin a
menudo se cuela por la con- formacin,
habilidades y preferencias de los autores y los
lectores del documento.
Una serie de indicadores de calidad se han
desarrollado que puede ser utilizado para
relacionar la calidad de los requisitos de
software de especificacin a otras variables del
proyecto, tales como el coste, la aceptacin,
Formance per-, programar y reproducibilidad.
Los indicadores de calidad para las
declaraciones de especificacin de requisitos de
1-12 Gua SWEBOK V3.0 orientacin sobre lo que debe buscar en la forma
6. requisitos de Validacin
[1 *, c4s6] [2 *, c13, de listas de verificacin.
c15]

Los documentos de los requisitos pueden estar

sujetos a procedimientos de Val- idation y
verificacin. Los requisitos pueden ser
validados para asegurar que el ingeniero de
software ha entendido los requisitos; Tambin
es importante verificar que se ajusta a los
requisitos de docu- ment estndares de la
compaa y que es comprensible, coherente y
completa. En los casos en los estndares de la
compaa documentados o terminologa sean
incompatibles con las normas generalmente
aceptadas, una asignacin entre los dos debe
ser acordado y se anexa al documento.
Las notaciones formales ofrecen la
importante ventaja de permitir que las dos
ltimas propiedades a ser probada (en un
sentido restringido, por lo menos). Stake-
distintos titulares, entre ellos representantes del
cliente y desarrollador, deben revisar el
documento (s). Los documentos de requisitos
estn sujetos a las mismas prcticas de gestin
de configuracin como las dems prestaciones
de los procesos del ciclo de vida del software.
Cuando sea posible, los requisitos individuales
tambin estn sujetos a la gestin de
configuracin, general- mente con una
herramienta de gestin de requisitos (vase el
tema 8, requisitos de software Herramientas).
Es normal para programar explcitamente
uno o ms puntos en el proceso de requisitos
donde se validan los requisitos. El objetivo es
recoger cualquier problema antes de recursos
se comprometen a abordar los requisitos.
Requisitos validada dacin tiene que ver con el
proceso de examin- ing el documento de
requisitos para garantizar que define el
software adecuado (es decir, el software que
los usuarios esperan).

6.1. requisitos crticas

Tal vez la forma ms comn de la validacin

se realiza mediante inspeccin o revisin del
documento (s) requisitos. Un grupo de
revisores se le asigna un breve para buscar
errores, suposiciones errneas, falta de
claridad, y la desviacin de Tice prc-
estndar. La composicin del grupo que lleva a
cabo la revisin es importante (al menos una
representativa del cliente debe ser incluido para
un proyecto impulsado por el cliente, por
ejemplo), y puede ayudar a proporcionar
 Requisitos de software 1-13

Los comentarios pueden ser constituidos en la anlisis. Por ejem plos, en modelos de objetos, es
finalizacin del documento de definicin del til para llevar a cabo un anlisis esttico para
sistema, el documento de especificacin del verificar la existencia de rutas de comunicacin
sistema, el documento de especificacin de entre los objetos que, en las partes interesadas
requisitos de software, la especificacin de lnea
de base para un nuevo lanzamiento, o en
cualquier otro paso en el proceso.

6.2. prototipado

Prototipos es comnmente un medio para validar

la interpretacin que el ingeniero de software de
los requisitos de software, as como para la
obtencin de nuevos requisitos. Al igual que con
la elicitacin, hay una gama de tcnicas de
prototipado y un nmero de puntos en el proceso
donde la validacin prototipo puede ser
apropiado. La ventaja de prototipos es que
pueden hacer que sea ms fcil interpretar los
supuestos del ingeniero de soft- ware y, si es
necesario, dar informacin til acerca de por qu
estn equivocados. Por ejemplo, el
comportamiento dinmico de un usuario
interfase se puede entender mejor a travs de un
ani- acoplado prototipo que a travs de
descripcin textual o modelos grficos. La
volatilidad de un requisito que se define despus
de la creacin de un prototipo que se ha hecho es
extremadamente bajo porque no hay acuerdo
entre el interesado y el software de inge- Neer-
por lo tanto, para la creacin de prototipos
caractersticas cruciales de seguridad crtica y
sera una gran ayuda. Tambin hay desventajas,
sin embargo. Estos incluyen el peligro de la
atencin de los usuarios distraerse del ncleo
funcionalidad subyacente por cuestiones
cosmticas o problemas de calidad con el
prototipo. Por esta razn, algunos prototipos
defienden que eviten el software, tales como
maquetas basadas en rotafolio. totypes pro
pueden ser costosos de desarrollar. Sin embargo,
si evitan el desperdicio de recursos que supone
tratar de satisfacer los requisitos errneos, su
coste se puede justificar ms fcilmente.
prototipos tempranos pueden contener aspectos
de la solucin final. Los prototipos pueden ser
evolutiva en lugar de usar y tirar.

6.3. Modelo de validacin

Por lo general es necesario para validar la

calidad de los modelos desarrollados durante el
1-14 Gua SWEBOK V3.0 su producto comienza a evolucionar, descubren
dominio, el intercambio de datos. Si se utiliza
el anlisis formal notacin ciones, es posible que necesitan para recuperar los requisitos que
utilizar ing razonable formal para probar las
propiedades de especificacin. Este tema est
estrechamente relacionado con las els
Ingeniera de Software y Mtodos Mod-KA.

6.4. Prueba de aceptacion

Una propiedad esencial de un requisito de

software es que debe ser posible validar que el
producto final satisface. Requisitos que no
pueden ser validados en realidad slo son
deseos. Por tanto, una tarea importante es la
planificacin de cmo ver- ify cada requisito.
En la mayora de los casos, el diseo de las
pruebas de aceptacin hace esto por cmo los
usuarios finales normalmente, un
comportamiento camente negocio utilizando el
sistema.
Identificacin y diseo de pruebas de
aceptacin puede ser difcil para los requisitos
no funcionales (vase la seccin 1.3, funcional
y requerimientos no funcionales). Para ser
validado, primero tienen que ser analizados y
se descompone hasta el punto en que se pueden
expresar cuantitativamente.
Informacin adicional se puede encontrar en
la acep- tacin / Calificacin / pruebas de
conformidad en el Testing de Software KA.

7. Consideraciones prcticas
[1 *, c4s1, c4s4, c4s6,
c4s7] [2 *, c3, c12, c14,
c16, c18-21]

El primer nivel de descomposicin tema pre-

tantes en este KA puede parecer para describir
una secuencia lineal de actividades. Esta es una
visin simplificada del proceso.
El proceso de requisitos abarca todo el ciclo
de vida del software. La gestin del cambio y
el mantenimiento de los requisitos en un estado
que refleja con precisin el software que se
construirn, o que se ha construido, son la
clave para el xito del proceso de ingeniera de
software.
No todas las organizaciones tienen una
cultura de requisitos y gestin de docu-
Menting. Es mon com- en empresas de nueva
creacin dinmica, impulsada por un fuerte
visin de producto y los recursos limitados,
para ver la documentacin de requisitos como
una sobrecarga innecesaria. Muy a menudo, sin
embargo, ya que estas empre- sas se expanden,
a medida que crece su base de clientes, y como
 Requisitos de software 1-15

producto motivado cuenta con el fin de evaluar con el diseo y la construccin de la iteracin
el impacto de los cambios propuestos. Por lo actual. Este enfoque proporciona ERS adaptado
tanto, la documentacin y los requisitos de para el cliente con el valor de negocio de forma
gestin del cambio son la clave para el xito de rpida, mientras minimizando ing el costo de
cualquier proceso de requisitos. reproceso.
En casi todos los casos, los requisitos de la
7.1. La naturaleza iterativa del proceso comprensin
Requisitos contina evolucionando a medida que el diseo y
el desarrollo
Existe una presin general en el software de
indus- tria de los ciclos de desarrollo cada vez
ms cortos, y esto es particularmente
pronunciado en sectores altamente competitivos,
impulsados por el mercado. Por otra parte, la
mayora de los proyectos se ven limitados de
alguna manera por su entorno, y muchos son
actualizaciones o revisiones de software, tentes
ing en el que se da por la arquitectura. En la
prctica, por lo tanto, casi siempre es prctico
para implementar el proceso de requisitos como
un proceso lineal y determinista en el que los
requisitos de software son provocados a partir de
los grupos de inters, bases forrado, asignado y
entregado al equipo de desarrollo de software.
Sin duda, es un mito que los requisitos para
grandes proyectos de software estn siempre
perfectamente entendidas o perfectamente
especificados.
En su lugar, los requisitos normalmente iterar
hacia un nivel de calidad y detalle que es
suficiente para permitir que las decisiones de
diseo y de adquisiciones a realizar. En algunos
proyectos, esto puede dar lugar a los requisitos
que se baselined antes de todas sus propiedades
se entienden completamente. Se corre el riesgo
expen- retrabajo siva si surgen problemas al
final del proceso de ingeniera soft- ware. Sin
embargo, los ingenieros de software estn
necesariamente limitados por los planes de
gestin de proyectos y por lo tanto deben tomar
medidas para asegurar que la calidad de los
requisitos es tan alto como sea posible dados los
recursos disponibles. Deben, por ejemplo, hacer
explcitas las suposiciones que sustentan los
requisitos, as como los problemas conocidos.
Para los productos de software que se
desarrollan ITER tivamente, un equipo de
proyecto puede lnea de base slo a los
requisitos necesarios para la iteracin actual. El
especialista requisitos puede seguir
desarrollndose requisitos para futuras
iteraciones, mientras res desarrollos proceder
1-16 Gua SWEBOK V3.0 ware en fase de desarrollo o mantenimiento
producto. Esto a menudo conduce a la revisin
de los requisitos finales del ciclo de vida. Tal evoluciona. Esto debe incluir los diversos
vez el punto ms crucial en la comprensin de clasificacin
los requisitos de software es que una
proporcin significativa de los requisitos
cambiar. Esto es a veces debido a errores en el
anlisis, pero a menudo es una consecuencia
inevitable del cambio en el medio ambiente;
por ejemplo, el entorno operativo o de negocio
del cliente, procesos de regulacin impuestas
por las autoridades, o el mercado en el que el
software debe vender. Cualquiera que sea la
causa, es importante reconocer la inevitabilidad
del cambio y tomar medidas para mitigar sus
efectos. El cambio tiene que ser gestionado por
asegurar que los cambios propuestos pasan por
una revisin definido y tasa de aprobacin pro
y mediante la aplicacin de los requisitos
cuidadosos trac- cin, anlisis de impacto, y la
gestin de configuracin de software (ver el
KA Software Configuration Management). Por
lo tanto, los requisitos de pro- ceso no es slo
una tarea para el usuario en el desarrollo de
software, pero se extiende por todo el ciclo de
vida del software. En un proyecto tpico, el
software requisito actividades mentos
evolucionan con el tiempo de obtencin de la
gestin del cambio. Una combinacin de arriba
hacia abajo mtodos de anlisis y diseo y de
abajo hacia arriba y mtodos de
implementacin de refactorizacin que se
renen en el medio podra proporcionar lo
mejor de ambos mundos. Sin embargo, esto es
difcil de lograr en la prctica, ya que depende
en gran medida de la madurez y la experiencia
de los ingenieros de software.

7.2. Gestin del cambio

La gestin del cambio es fundamental para la

gestin de requisitos. En este tema se describe
el papel de la gestin del cambio, los
procedimientos que deben estar en su lugar, y
el anlisis que se debe aplicar a los cambios
propuestos. Tiene fuertes vnculos con la
Cesin de Software Gestin de la
Configuracin KA.

7.3. requisitos Atributos

Los requisitos deben consistir no slo en un

ficacin speci- de lo que se requiere, sino
tambin de informacin auxiliar, lo que ayuda
a manejar e interpretar los requisitos.
Requisitos atributos deben ser definidos,
registran y actualizan a medida que el soft-
 Requisitos de software 1-17

dimensiones de la exigencia (vase la seccin 7.5. La medicin de Requisitos

4.1, los requisitos de clasificacin) y el mtodo
de verificacin o seccin del plan de prueba de Como cuestin prctica, suele ser til tener
aceptacin correspondiente. Tambin puede algn concepto de volumen de las exigencias
incluir informacin adicional, como una para un producto de software en particular. Este
justificacin de resumen para cada requisito, la nmero es til para evaluar el tamao de un
fuente de cada requerimiento, y un historial de cambio en los requisitos, al estimar el costo de
cambios. Los requisitos ms importantes una tarea de desarrollo o mantenimiento, o
atribuyen, SIN EMBARGO, es un identificador simplemente para su uso como el denominador
que permite a los requisitos para ser en otras mediciones. medida del tamao
identificadas de manera nica e inequvoca. funcional (FSM) es una tc- nica para evaluar el
tamao de un cuerpo de requisitos funcio- nales.
7.4. requisitos de rastreo Informacin adicional sobre la medicin y
estndares de tamao se encuentra en el Proceso
Requisitos de rastreo tiene que ver con objeto de de Software niera Inge- KA.
reembolso ing la fuente de los requisitos y la
prediccin de los efectos de los requisitos. El 8. Requisitos de software Herramientas
rastreo es fundamental para la realizacin de
anlisis de impacto cuando los requisitos Herramientas para hacer frente a los requisitos
cambian. Un requisito debe ser trazable dadas de software se dividen en dos categoras:
vuelta a los requisitos y las partes interesadas herramientas para el modelado y herramientas
que la motivaron (de un requisito de software de para la gestin de requisitos.
nuevo a la exigencia (s) del sistema que ayuda a herramientas de gestin de requisitos
satisfacer, por ejemplo). Por el contrario, un normalmente el puerto SUP- una serie de
requisito debe ser trazable hacia adelante en los actividades, incluyendo docu- mentacin, la
requisitos de diseo y entidades que lo satisfacen localizacin, y la gestin del cambio y han
(por ejemplo, de un requisito del sistema en los tenido un impacto significativo en la prctica.
requisitos de software que se han elaborado a De hecho, ing trac- y la gestin del cambio son
partir de ella, y en en los mdulos de cdigo que realmente slo prc- ticable si es compatible con
lo implementan, o la casos de prueba una herramienta. Desde la gestin de requisitos
relacionados con ese cdigo, e incluso una es fundamental para la buena prctica de los
seccin dada en el manual de usuario que requisitos, muchas organizaciones han invertido
describe la funcionalidad real) y en el caso de en herramientas de gestin de requisitos, aunque
prueba que verifica. muchos ms manejar sus requisitos en ms ad
Los requisitos de seguimiento para un tpico hoc y generalmente menos satisfactorios
proyec- ect formarn un complejo grfico maneras (por ejemplo, utilizando hojas de
dirigido acclico (DAG) (ver Grficos en el clculo).
Computing Foundation ciones KA) de
requisitos. El mantenimiento de una matriz
grfica fecha o trazabilidad hasta-a es una
actividad que debe ser considerada durante todo
el ciclo de vida de un producto. Si la
informacin de trazabilidad no se actualiza
como los cambios en los requisitos siguen
ocurriendo, la informacin de trazabilidad deja
de ser fiable para el anlisis del impacto.
1-18 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

2011 [1 *]

Wiegers 2003
SommervilLe

[2 *]
1. Requisitos de software Fundamentos
1.1. Definicin de un requisito de software c4 c1
1.2. Requisitos del producto y de proceso c4s1 C1, C6
1.3. Requisitos funcionales y no funcionales c4s1 c12
1.4. Propiedades emergentes c10s1
1.5. Requisitos cuantificables c1
1.6. Requisitos del sistema y requisitos de software c10s4 c1
2. Requisitos Proceso
2.1. Los modelos de proceso c4s4 c3
2.2. Los actores del proceso c1, c2, c4, c6
2.3. Administracin y Apoyo Proceso c3
2.4. Proceso de Calidad y Mejora c22, c23
3. la obtencin de requisitos
3.1. requisitos Fuentes c4s5 C5, C6, C9
3.2. tcnicas de obtencin c4s5 c6
Anlisis 4. Requisitos
4.1. requisitos Clasificacin c4s1 c12
4.2. Modelado conceptual c4s5 c11
4.3. Diseo y requisitos arquitectnicos Asignacin c10s4 c17
4.4. requisitos de Negociacin c4s5 c7
4.5. Anlisis formal c12s5
5. Requisitos Especificacin
5.1. Definicin del sistema de documentos c4s2 c10
c4s2, c12s2,
5.2. Requisitos del sistema Especificacin c12s3, c12s4, c10
c12s5
5.3. Especificacin de Requerimientos de Software c4s3 c10
6. Requisitos de Validacin
6.1. requisitos crticas c4s6 c15
6.2. prototipado c4s6 c13
6.3. Modelo de validacin c4s6 c15
6.4. Prueba de aceptacion c4s6 c15
 Requisitos de software 1-19

2011 [1 *]

Wiegers 2003
SommervilLe

[2 *]
7. Consideraciones prcticas
7.1. La naturaleza iterativa del proceso Requisitos c4s4 C3, C16
7.2. Gestin del cambio c4s7 c18, c19
7.3. requisitos Atributos c4s1 c12, c14
7.4. requisitos de rastreo c20
7.5. La medicin de Requisitos c4s6 c18
8. Requisitos de software Herramientas c21
1-20 Gua SWEBOK V3.0

LECTURAS
I. Alexander y L. Beus-Dukic, Requisitos A. van Lamsweerde, Ingeniera de Requisitos:
Descubriendo [5]. A partir de los objetivos del sistema de
modelos UML a Especificaciones de
Un libro de fcil digestin y de carcter prctico software [7].
sobre los requisitos de software, esto es quizs el
mejor de los libros de texto actuales sobre cmo Sirve como una buena introduccin a la
los diferentes elementos de los requisitos de ingeniera de requisitos, pero su valor nico es
software encajan entre s. Est lleno de consejos como un libro de referencia para los requisitos
prcticos sobre (por ejemplo) la manera de orientados a objetivos lenguaje de modelado de
identificar los distintos actores del sistema y KAOS. Explica por qu el modelado meta es til
cmo evaluar soluciones alternativas. Su edad y muestra cmo se puede integrar con tcnicas
cubierta- es ejemplar y sirve como una de modelado convencionales usando UML.
referencia til para tcnicas de clave, tales como
modelado de caso de uso y requisitos de O. Gotel y A. Finkelstein, Un anlisis del
priorizacin. problema Requisitos trazabilidad [8].

C. Potts, K. Takahashi, y A. Antn, indagacin Este trabajo es una obra de referencia clsica en
Anlisis Requisitos Basado [6]. un elemento clave de la gestin de requisitos.
Basndose en estudios empricos, establece las
Este documento es una cuenta de fcil digestin razones y las barreras para el rastreo eficaz de
de trabajo que ha demostrado ser muy influyente los requisitos. Es una lectura esencial para la
en el desa- rrollo de las necesidades de comprensin de por qu los requisitos de rastreo
manipulacin. En l se describe cmo y por qu es un elemento esencial de un proceso de
la elaboracin de requisitos no puede ser un software efectivo.
proceso lineal por el cual el analista
simplemente transcribe y reformula requisitos N. Maiden y C. Ncube, La adquisicin de
provocadas por parte del cliente. El papel de los COTS Requisitos de seleccin de
escenarios se describe de una manera que ayuda software [9].
a definir su uso en el descubrimiento y la
descripcin de los requisitos. Este documento es importante porque reconoce
explcitamente que los productos de software a
menudo integran componentes de terceros.
Ofrece una visin de los problemas de la
seleccin de software off-the-shelf para
satisfacer los requisitos: por lo general hay una
falta de coincidencia. Esto desafa algunos de los
supuestos sub fijando la mayor parte de los
requisitos tradicionales dling manipulan de, que
tiende a asumir software personalizado.
 Requisitos de software 1-21

Referencias
[1 *] I. Sommerville, Ingeniera de Software, 9 [6] C. Potts, K. Takahashi, y AI Antn,
ed., Addison-Wesley, 2011. basada en la indagacin Anlisis de
Requerimientos, IEEE Software, vol. 11,
[2 *] KE Wiegers, Requisitos de software, no. 2, marzo de 1994,
segundo pp. 21-32.
ed., Microsoft Press, 2003.
[7] A. van Lamsweerde, Ingeniera de
[3] INCOSE, Manual de Sistemas de Requisitos: A partir de los objetivos del
Ingeniera: Una gua para los procesos de sistema de modelos UML a especificaciones
ciclo de vida del sistema y Actividades, de software, Wiley, 2009.
versin 3.2.2, Consejo Internacional de
Ingeniera de Sistemas, 2012. [8] O. Gotel y CW Finkelstein, Un anlisis del
problema exigencias de trazabilidad, Proc.
[4] S. Friedenthal, A. Moore, y R. Steiner, Primero Int'l Conf. Requisitos Eng., IEEE,
Una gua prctica para SysML:. El sysml, 1994.
2 ed, Morgan Kaufmann, 2012.
[9] NA Maiden y C. Ncube, La adquisicin de
[5] I. Alexander y L. Beus-Deukic, Requisitos de Eleccin COTS software,
Descubriendo Requisitos: Cmo IEEE Software, vol. 15, no. 2, marzo-abril.
especificar los productos y servicios, 1998, pp. 46-56.
Wiley, 2009.
 CAPTULO 2 DISEO

DEL SOFTWARE

SIGLAS Nosotros Tambin puede examinar y evaluar

soluciones alternativas y compensaciones.
Arquitectura Descripcin Finalmente, podemos utilizar los modelos
ADL
Idioma resultantes para planificar actividades de
CDB Diseo basado en componentes desarrollo posteriores, como la verificacin del
CRC Responsabilidad clase colaborador sistema y cin validacin, adems de su uso
como entradas y como el punto de partida de la
DFD Diagrama de flujo de datos
construccin y prueba.
ERD Relacin diagrama de entidad En una lista estndar de pro- cesos de ciclo de
IDL Interfaz de lenguaje de descripcin vida del software, tales como que en la norma
MVC de
Modelo Vista Controlador ISO / IEC / IEEE Std. 12207, procesos de ciclo
de vida del software [2], el diseo de software
OO Orientado a objetos
consta de dos actividades que se ajustan entre el
PDL Programa de Lenguaje de Diseo anlisis de los requisitos de software y la
construccin de software:

INTRODUCCIN diseo de la arquitectura de software (a

veces llamado diseo de alto nivel):
Diseo se define como tanto el proceso de desarrolla la estructura de alto nivel y
defin- ing la arquitectura, componentes, organizacin del software y se identifican
interfaces y otras caractersticas de un sistema o los distintos componentes.
componente y el resultado del proceso [que] Software de diseo detallado: especifica
[1]. Visto como un proceso, diseo de software cada componente en suficiente detalle para
es el ing la actividad del ciclo de vida del facilitar su construccin.
software en el que Engineer- mentos de software
requisito se analizan con el fin de producir una Esta rea de conocimiento Diseo de Software
descripcin de la estructura interna del software (KA) no habla de todos los temas que incluye la
que va a servir de base para su construccin. Un palabra diseo. En la terminologa de Tom
diseo de software (el resultado) describe el DeMarco [3], los temas tratados en este acuerdo
software de archi- tecture, es decir, cmo se KA principalmente con D-diseo (diseo de
descompone software y organizado en descomposicin), cuyo objetivo es el mapeo de
componentes-y las caras interrelaciones entre software en piezas componentes. Sin embargo,
esos componentes. Tambin debe describir los debido a su importancia en el campo de la
componentes a un nivel de detalle que permite arquitectura de software, tambin vamos a tratar
su construccin. FP-diseo (diseo del patrn de la familia), cuyo
El diseo de software juega un papel objetivo es establecer aspectos comunes
importante en el desarrollo de software: durante explotables en una familia de productos de
el diseo de software, ingenieros de software software. Esta KA no se ocupa de la I-diseo
producen varios modelos que forman una (diseo invencin), que se realiza generalmente
especie de anteproyecto de la solucin a durante el proceso de requisitos de software con
implementar. Podemos analizar y evaluar estos el objetivo de alizing conceptualizacin y la
modelos para determinar si son o no nos especificacin de software para satisfacer las
permitirn cumplir con los diversos requisitos. necesidades y requerimientos descu- Ered, ya
que este tema es considerado como parte de el Requisitos
Este software de diseo KA esdeespecificacin
software 1-23
proceso de requisitos (ver los requisitos de relacionada
software KA). camente a los requisitos de software, Software

2-1
2-2 Gua SWEBOK V3.0

Figura 2.1. Desglose de temas para el Software de Diseo KA

Construccin, Ingeniera de Software Ment la comprensin de los lmites del diseo. Un

Manage-, modelos de ingeniera de software y nmero de otras nociones y conceptos Tambin
met- ods, Calidad de Software y Computacin son de inters en la comprensin del diseo en
Fundaciones ciones de Kas. su sentido general: objetivos, las limitaciones,
las alternativas, las representaciones y las
DISTRIBUCIN DE TEMAS PARA EL soluciones (vase el problema tcnicas de
DISEO DEL SOFTWARE resolucin en los Fundamentos de Informtica
KA).
El desglose de temas para el Software de Diseo
KA se muestra en la Figura 2.1. 1.2. Contexto de Diseo de Software
[4 *, c3]
1. Fundamentos del diseo de software
El diseo de software es una parte importante
La conceptos, nociones, y la terminologa intro- del proceso de desarrollo de soft- ware. Para
ducido aqu forman una base subyacente para la entender el papel del diseo de software,
sub pie el papel y el alcance de diseo de tenemos que ver cmo se integra en el ciclo de
software. vida del software de desarrollo. Por lo tanto, es
importante comprender las principales
1.1. Conceptos generales de diseo caracters- ticas de anlisis de requisitos de
[4 *, c1] software, diseo de software, la construccin de
software, pruebas de software, y el
En sentido general, el diseo puede ser visto mantenimiento del software.
como una forma de resolucin de problemas.
Por ejemplo, el con- cepto de una solucin de un 1.3. Software de Diseo de Procesos
problema complejo sin solucin definitiva, es [4 *, c2]
interesante en trminos de
El diseo del software es generalmente
considerado como un proceso de dos pasos: 2- Diseo de
Software3
2-4 Gua SWEBOK V3.0

Diseo arquitectnico (tambin conocido programa de ordenador, mientras que la

como diseo de niveles altos y diseo de cohesin se define como una medida de la
nivel superior) describe cmo el software fuerza de la asociacin de los elementos
est organizado en componentes. dentro de un mdulo [1].
El diseo detallado se describe el comporta- La descomposicin y la modularizacin.
miento deseado de estos componentes. posando descomposicin y la modularizacin
significa que grandes
La salida de estos dos procesos es un conjunto
de modelos y artefactos que registran las
mayores las decisiones que se han tomado, junto
con una explicacin de los fundamentos de cada
decisin no trivial. Guardando el razonamiento,
la capacidad maintain- a largo plazo del
producto de software es mayor.

1.4. Principios de Diseo de Software

[4] [5 *, c6, c7, c21] [6 *, c1, c8,
c9]

Un principio es una completa y fundamen- tal

ley, doctrina o suposicin [7]. principios de
diseo de software son nociones clave que
proporcionan la base para muchos diferentes
enfoques de diseo de software y conceptos.
diseo de software prin- cipios incluyen la
abstraccin; acoplamiento y de cohesin; la
descomposicin y la modularizacin; cin
encapsula- / ocultar informacin; separacin de
interfaz y la implementacin; suficiencia,
integridad, y primitivo; y la separacin de
preocupaciones.

Abstraccin es una vista de un objeto que

se centra en la informacin relevante para
un propsito particular y hace caso omiso
de la der restante de la informacin [1]
(vase Abstraccin en los Fundamentos de
computacin KA). En el contexto del diseo
de software, dos mecanismos de abstraccin
clave son la parametrizacin y la
especificacin. Abstraccin por resmenes
cin parametrizacin de los detalles de
sentaciones de datos sentantes de
representacin de los datos como
parmetros con nombre. Abstraccin por la
especificacin conduce a tres tipos
principales de la abstraccin: abstraccin de
procedimientos, la abstraccin de datos, y la
abstraccin de control (iteracin).
Acoplamiento y cohesin. El acoplamiento
se define como una medida de la
interdependencia entre los mdulos en un
 2- Diseo
7, Software de Diseo Estrategias de
y Mtodos).
el software se divide en una serie de Software5
componentes nombrados ms pequeos Por el contrario, otras cuestiones trato con
que tienen interfaces bien definidas que algn aspecto del comportamiento del software
describen las interacciones de los que no est en el dominio de la aplicacin, pero
componentes. Por lo general, el objetivo es que aborda algunas de las apoyando
colocar diferentes funcionalidades y
responsabilidades en diferentes
componentes.
Encapsulacin y ocultacin de la
informacin significa la agrupacin y el
envasado de los detalles internos de una
abstraccin y haciendo esos detalles
inaccesibles a entidades externas.
La separacin de interfaz y la
implementacin. La separacin de interfaz
y la implementacin consiste en definir un
componente de specify- ing una interfaz
pblica (conocidos por los clientes) que es
independiente de los detalles de cmo se
realiza el componente (ver encapsulacin
y ocultacin de la informacin anterior).
Suficiencia, integridad y primitivo. El
logro de suficiencia y medios de
integridad para garantizar que un
componente de software captura todas las
caractersticas importantes de una
abstraccin y nada ms. Ness Primitive-
significa que el diseo debe estar basado
en patrones que son fciles de
implementar.
Separacin de intereses. Una
preocupacin es un rea de inters con
respecto a un diseo de software [8]. Una
de las preocupaciones de diseo es un rea
de diseo que es relevante para uno o ms
de sus grupos de inters. Cada vista de la
arquitectura enmarca uno o ms
preocupaciones. La separacin de las
preocupaciones por los puntos de vista
permite a las partes interesadas para
centrarse en algunas cosas a la vez y
ofrece un medio para gestionar la
complejidad [9].

2. Cuestiones clave en el diseo de software

Una serie de cuestiones clave debe ser tratado

en el diseo de software. Algunos son
problemas de calidad que todo el software debe
abordar, por ejemplo, rendimiento, seguridad,
fiabilidad, facilidad de uso, etc. Otra cuestin
importante es cmo descomponer, organizar y
componentes de software paquete. Esto es tan
fundamental que todos los enfoques de diseo
enmarcan en una forma u otra (vase la seccin
1.4, Principios de diseo de software, y el tema
2-6 Gua SWEBOK V3.0

dominios[10]. Estas cuestiones, que a menudo 2.6. Interaccin y Presentacin

crosscut la funcionalidad del sistema, se han [5 *, c16]
referido como aspectos, que no tienden a ser
unidades de soft-
descomposicin funcional de las mercancas, Este problema de diseo se ocupa de cmo es-
sino ms bien a ser propiedades que afectan al tructura y organizar las interacciones con los
rendimiento o tics seman- de los componentes usuarios, as como la presentacin de
en formas sistmicas[11]. Varias de estas informacin (por ejemplo, la separacin de
cuestiones clave, transversales se tratan en las presentacin y la lgica de negocio utilizando el
secciones siguientes (presentados en orden enfoque del Modelo-Vista-Controlador). Tenga
alfabtico). en cuenta que este tema no especifica detalles de
la interfaz de usuario, que es la tarea de diseo
2.1. concurrencia de la interfaz de usuario (vase el tema 4, diseo
[5 *, c18] de interfaz de usuario).

Diseo para la concurrencia tiene que ver con el 2.7. Seguridad

software de presentacin descomposicin en los [5 *, c12, c18] [13 *,
procesos, tareas y discusiones y hacer frente a c4]
cuestiones relacionadas con la eficiencia, la
atomicidad, sincronizacin y programacin. Diseo para la seguridad tiene que ver con la
forma de pre ventilar la divulgacin no
2.2. Control y manejo de Eventos autorizada, creacin, cambio, supresin o
[5 *, c21] negacin del acceso a la informacin y otros
recursos. Tambin tiene que ver con la forma en
Este problema de diseo se ocupa de la forma de que tolerar ataques o violacines relacionadas
organizar los datos y flujo de control, as como con la seguridad mediante la limitacin de
la forma de manejar los eventos reactivos y daos, funcionamiento continuo, acelerar la
temporales a travs de diversos mecanismos reparacin y recuperacin, y en su defecto y
como la invocacin implcita y devoluciones de recuperar de forma segura. El control de acceso
llamadas. es un con- cepto fundamental de la seguridad, y
tambin se debe garantizar el buen uso de la
2.3. Persistencia de datos criptografa.

3. Estructura del software y Arquitectura

[12 *, c9]
Este problema de diseo se ocupa de la forma de
Este problema de diseo se ocupa de cmo se pre- ventilacin, tolerar, y los errores de proceso y
manipulan de datos de larga vida dle. hacer frente a condiciones excepcionales.

2.4. Distribucin de Componentes

[5 *, c18]

Este problema de diseo se ocupa de cmo

redistribuir el software en el hardware
(INCLUYENDO hardware de ordenador y
hardware de red), cmo se comunican los
componentes, y cmo middleware se puede
utilizar para tratar con el software heterogneo.

2.5. Error y control de excepciones y la

tolerancia a fallos
[5 *, c18]
En su sentido ms estricto, una arquitectura de 2- Diseo de
Software7
software es el conjunto de las estructuras
necesarias para razonar acerca del sistema, que
comprenden elementos de software, las
relaciones entre ellos, y las propiedades de
ambos [14 *]. A mediados de la dcada de
1990, sin embargo, la arquitectura de software
comenz a surgir como una disciplina ms
amplia que implicaba el estudio de las
estructuras y arquitecturas de software de una
manera ms genrica. Esto dio lugar a una serie
de conceptos interesantes sobre el diseo de
software en diferentes nive- les de abstraccin.
Algunos de estos conceptos pueden ser tiles
en el diseo arquitectnico (por ejemplo, los
estilos arquitectnicos), as como durante el
diseo detallado (por ejemplo, el diseo Pat-
charranes). Estos conceptos de diseo tambin
se pueden utilizar para disear las familias de
programas (tambin conocido como lneas de
producto). Curiosamente, la mayora de estos
conceptos pueden ser vistas como intentos de
describir, y por lo tanto la reutilizacin, el
conocimiento de diseo.
2-8 Gua SWEBOK V3.0

3.1. Las estructuras arquitectnicas y puntos de patrones que describen la organizacin de alto
vista nivel de software, otros patrones de diseo se
[14 *, c1] pueden utilizar para describir los detalles en un
nivel inferior. Estos patrones de diseo de bajo
Las diferentes facetas de alto nivel de un diseo nivel son los siguientes:
de software pueden ser descritos y
documentados. Estas facetas son a menudo patrones de creacin (por ejemplo,
llamados puntos de vista: Una vista representa constructor, fbrica, prototipo, Singleton)
un aspecto parcial de una arquitectura de patrones estructurales (por ejemplo,
software que muestra propiedades espec- espe- adaptador, puente, compuesto, decorador,
de un sistema de software [14 *]. Vistas fachada, peso FLY-, Proxy)
pertenecen a distintos temas relacionados con el Los patrones de comportamiento (por
software de diseo, por ejemplo, la vista lgica ejemplo, comandos, intrprete, iterador,
(satisfaciendo los requisitos funcionales) frente a mediador, recuerdo, observador, estado,
la vista de procesos (problemas de concurrencia) estrategia, plantilla, visitante).
frente a la vista fsica (problemas de distribu-
cin) frente a la vista de desarrollo (como el el 3.4. Las decisiones Arquitectura Diseo
diseo se divide en unidades de ejecucin con [5 *, c6]
representacin explcita de las dependencias
entre las unidades). Varios autores utilizan El diseo arquitectnico es un proceso creativo.
diferentes terminologas-como frente a la Duran- te el proceso de diseo, los diseadores
conducta funcional vs. vistas de modelado de de software tienen que tomar una serie de
datos vs. estructurales. En resumen, un diseo de decisiones fundamentales que afectan
software es un artefacto multifactico producido profundamente el proceso de desa- rrollo de
por el proceso de diseo y generalmente software y. Es til pensar en el proceso de
compuesta de puntos de vista relativamente diseo arqui- tectural desde una perspectiva de
independientes y ortogonales. toma de decisiones en lugar de desde una
perspectiva actividad. A menudo, el impacto
3.2. Estilos arquitectnicos sobre los atributos de calidad y soluciones de
[14 *, c1, c2, c3, c4, c5] compromiso entre los atributos de calidad que
compiten son la base para las decisiones de
Un estilo arquitectnico es una especializacin diseo.
de tipos Ment y relacin ele-, junto con un
conjunto de restricciones sobre la forma en que 3.5. Las familias de los programas y marcos
se pueden utilizar [14 *]. Un estilo [5 *, C6, C7, C16]
arquitectnico de este modo puede ser visto
como para simplificar la organizacin de alto Un enfoque para proporcionar la reutilizacin de
nivel del software. Varios autores han diseos y componentes de software es el diseo
identificado una serie de grandes estilos tectural de las familias de programas, tambin conocidas
arqui-: como lneas de productos de software. Esto se
puede hacer mediante la identificacin de los
Las estructuras generales (por ejemplo, puntos en comn entre los miembros de estas
capas, tuberas y filtros, pizarra) familias y mediante el diseo de componentes
Los sistemas distribuidos (por ejemplo, reutilizables y personalizables para dar cuenta de
cliente-servidor, tres niveles, broker) la variabilidad entre los miembros de la familia.
Interactivesystems (porejemplo, Modelo En la programacin orientada a objetos (OO),
View--Controller, Presentacin-Abstraccin- una nocin relacionada clave es que de un
Control) marco: un sistema de software parcialmente
sistemas adaptables (por ejemplo, nel completado que puede ser extendido por
microker-, reflexin) instanciar apropiadamente extensiones
Otros (por ejemplo, por lotes, intrpretes, especficas (tales como plug-ins).
control pro- ceso, basado en reglas).
 2- Diseo de
3.3. Patrones de 4. Diseo de interfaz de usuario
Software9
diseo [15 *, c3, c4,
c5] diseo de interfaz de usuario es una parte esencial
de la
Sucintamente descrito, un patrn es una proceso de diseo de software. diseo de interfaz
solucin comn a un problema comn en un de usuario debe asegurarse de que la interaccin
contexto dado [16]. Mientras que los estilos entre el humano y la mquina proporciona para
arquitectnicos pueden ser vistos como un funcionamiento eficaz
2-10 Gua SWEBOK V3.0

y el control de la mquina. Para el software para interaccin del usuario y presentacin de la

alcanzar su pleno potencial, la interfaz de informacin. diseo de interfaz de usuario debe
usuario debe ser diseado para que coincida con considerar un compromiso entre los estilos ms
las habilidades, experiencia y expectativas de apropiados de interaccin
sus usuarios previstos.
1 Captulo 29 es un captulo basado en la web
disponible en http://ifs.host.cs.st-
4.1. Principios generales para el usuario el
andrews.ac.uk/Books/SE9/ WebChapters/.
diseo de interfaces
[5 *, c29-web] [17 *, c2]
1

Facilidad de aprendizaje. El software debe

ser fcil de aprender para que el usuario
pueda iniciar rpidamente tra- baja con el
software.
la familiaridad del usuario. La interfaz debe
utilizar trminos y conceptos extrados de
los experimentos de los cias personas que
vayan a utilizar el software.
Consistencia. La interfaz debe ser tienda de
campaa consis- para que las operaciones
comparables se acti- vada de la misma
manera.
sorpresa mnimo. El comportamiento del
software no debe sorprender a los usuarios.
Recuperabilidad. La interfaz debe
proporcionar mecanismos que permitan a
los usuarios a recuperarse de los errores.
gua para el usuario. La interfaz debe dar
retroalimentacin significativa cuando se
producen errores y proporcionar ayuda
contextual para los usuarios.
la diversidad de usuarios. La interfaz debe
pro- mecanismos de interaccin vide
apropiados para diversos tipos de usuarios y
para los usuarios con capacidades diferentes
(ciegos, problemas de visin, sordos, ciegos
al color, etc.).

4.2. Interfaz de usuario Problemas Diseo

[5 *, c29-web] [17 *, c2]

diseo de interfaz de usuario debe resolver dos

cuestiones fundamentales:

Cmo debe el usuario interactuar con el

software?
Cmo debe la informacin desde el
software se presenta al usuario?

diseo de interfaz de usuario debe integrar la

 2- Diseo de
s misma. El enfoque MVC (Modelo-Vista-
y la presentacin del software, los antecedentes Software11
y la experiencia de los usuarios de software y Controlador) es una forma efectiva de mantener
los dispositivos disponibles. la presentacin de informacin se separe de la
informacin que se presenta.
4.3. El diseo de las modalidades de interaccin
del usuario
[5 *, c29-web] [17 *,
c2]

La interaccin del usuario implica la emisin

de comandos y la disponibilidad de datos
asociada con el software. estilos de interaccin
del usuario se pueden clasificar en los estilos
primarios siguien- tes:

Pregunta respuesta. La interaccin es

esencialmente restringido a un nico
intercambio de preguntas y respuestas
entre el usuario y el software. El usuario
enva una pregunta al software y el
software devuelve la respuesta a la
pregunta.
Manipulacin directa. Los usuarios
interactan con los objetos en la pantalla
del ordenador. La manipulacin directa a
menudo incluye un dispositivo sealador
(como un ratn, trackball o un ger de
dedos en las pantallas tctiles) que
manipula un objeto e invoca las acciones
que especifican lo que se debe hacer con
ese objeto.
seleccin de men. El usuario selecciona
un comando de una lista de los comandos
de men.
Forma de relleno. El usuario llena en los
campos de un formulario. A veces campos
incluyen mens, en cuyo caso el
formulario tiene botones de accin para
que el usuario inicie la accin.
lenguaje de comandos. El usuario emite un
com- mand y proporciona los parmetros
relacionados para dirigir el software qu
hacer.
Lenguaje natural. El usuario emite un
com- mand en lenguaje natural. Es decir,
el lenguaje natural es una interfaz a un
lenguaje de comandos y se analiza y se
traduce en comandos de soft- ware.

4.4. El diseo de la informacin Presentacin

[5 *, c29-web] [17 *,
c2]

presentacin de la informacin puede ser

textual o grficamente cal en la naturaleza. Un
buen diseo mantiene la presentacin de
informacin por separado de la informacin en
2-12 Gua SWEBOK V3.0

Software Los ingenieros tambin tienen en ana- lyzes tareas de los usuarios, la ment
cuenta el tiempo de respuesta del software y la ENTORNO trabajo, otro software, y cmo
retroalimentacin en el diseo de presentacin los usuarios interactan con otras personas.
de infor- macin. El tiempo de respuesta se mide creacin de prototipos de software. El
generalmente desde el punto en el que un desarrollo de prototipos de software ayudan a
usuario ejecuta una cierta accin de control hasta los usuarios a guiar la evolucin de la
que el software responde con una respuesta. Una interfaz.
indicacin del progreso es deseable poder evaluacin de la interfaz. diseadores puede
mientras que el software est preparando la observar experiencias de los usuarios con la
respuesta. La retroalimentacin puede ser interfaz de evolucin.
proporcionado mediante la reformulacin de la
entrada del usuario mientras que el
procesamiento se est terminando.
Abstractos visualizaciones pueden ser
utilizados cuando grandes cantidades de
informacin se han de presentar.
De acuerdo con el estilo de presenta- cin de
la informacin, los diseadores tambin pueden
utilizar el color para mejorar la interfaz. Existen
varias pautas importantes:

Limitar el nmero de colores utilizados.

Utilice el cambio de color para mostrar el
cambio de soft-
el estado de las mercancas.
Use cdigos de colores para apoyar la tarea
del usuario.
Use cdigos de colores en un reflexivo y
consis-
manera carpa.
Use colores para facilitar el acceso de las
personas con ceguera o deficiencia
cromtica de color (por ejemplo, utilizar el
cambio de la saturacin del color y el brillo
del color, tratar de evitar combinaciones de
azul y rojo).
No dependa slo en el color para transmitir
informacin importante para los usuarios
con capacidades diferentes (ceguera,
problemas de visin, ceguera por colores,
etc.).

4.5. Proceso de Interfaz de usuario Diseo

[5 *, c29-web] [17 *, c2]

diseo de interfaz de usuario es un proceso

iterativo; prototipos de interfaz se utilizan a
menudo para determinar las caractersticas, la
organizacin, y la apariencia de la interfaz de
usuario soft- ware. Este proceso incluye tres
actividades principales:

anlisis usuario. En esta fase, el diseador

4.6. Localizacin e internacionalizacin diseo de software, incluyendo variosde-ilities
2- Diseo
Software13
[17 *, c8, c9] (mantenibilidad, portabilidad, capacidad de
prueba, la facilidad de uso)
diseo de interfaz de usuario a menudo
necesita considerar la internacionalizacin y
localizacin, que son medios para adaptar
software a los diferentes idiomas, diferencias
regionales y las exigencias tcnicas de un
mercado objetivo. La internacionalizacin es el
proceso de diseo de una aplicacin de
software para que pueda ser adaptado a
diferentes idiomas y regiones sin mayores
cambios de ingeniera. La localizacin es el
proceso de adaptacin de soft- ware
internacionalizado para una regin o idioma
mediante la adicinlocale-
especficacomponentes FIC y traducir el texto.
Localizacin e internacionalizacin deben
tener en cuenta factores tales como smbolos,
nmeros rencia Cur-, el tiempo y las unidades
de medida.

4.7. Metforas y modelos conceptuales

[17 *, c5]

los diseadores de interfaces de usuario pueden

utilizar metforas y modelos conceptuales para
establecer correspondencias entre el software y
algn sistema de referencia conocida a los
usuarios en el mundo real, lo que puede ayudar
a los usuarios a aprender ms fcilmente y usar
la interfaz. Por ejem- plo, la operacin de
borrar el archivo se puede convertir en una
metfora con el icono de un cubo de basura.
En el diseo de una interfaz de usuario, inge-
niera de software deben tener cuidado de no
usar ms de una metfora para cada concepto.
Metforas tambin problemas potenciales ent
PRESION con respecto a internacionalmente
lizacin, ya que no todas las metforas son
significativa o se aplican de la misma manera
dentro de todas las culturas.

5. Diseo Anlisis y Evaluacin de la

Calidad de Software

En esta seccin se incluye una serie de Ysis

anal- de calidad y evaluacin temas que estn
especficamente relacionados con el diseo de
software. (Vase tambin la calidad KA
software).

5.1. Los atributos de calidad

[4 *, c4]

Varios atributos contribuyen a la calidad de un

2-14 Gua SWEBOK V3.0

y -nesses (exactitud, robustez). Hay una 5.3. medidas

interesante distincin entre la calidad atri- buye [4 *, c4] [5 *,
discernibles en tiempo de ejecucin (por c24]
ejemplo, per-
Formance, seguridad, disponibilidad, los modelos de ingeniera de software y
funcionalidad, facilidad de uso), los que no mtodos KA).
discernible en tiempo de ejecucin (por ejemplo, Simulacin y prototipado: tcnicas dinmicas
modificabilidad, portabilidad, reusabilidad, la para evaluar un diseo (por ejemplo, la
capacidad de prueba), y las relacionadas con las simulacin de rendimiento o prototipos de
cualidades intrnsecas de la arquitectura (por viabilidad).
ejemplo, conceptual integri- dad, exactitud,
integridad) . (Vase tambin la calidad KA
software).

5.2. Anlisis de calidad y tcnicas de evaluacin

[4 *, c4] [5 *, c24]

Varias herramientas y tcnicas pueden ayudar en

ing analyz- y la evaluacin de la calidad del
diseo de software.

Software revisiones de diseo: tcnicas

malized informales y lucro para determinar
la calidad de los artefactos de diseo (por
ejemplo, las revisiones de la arquitectura,
las revisiones de diseo, y las inspecciones,
las tcnicas basadas en escenarios, los
requisitos de rastreo). las revisiones de
diseo de software tambin pueden evaluar
la seguridad. Ayudas para la instalacin,
fun- cionamiento, y el uso (por ejemplo,
manuales y archivos de ayuda) pueden ser
revisados.
El anlisis esttico: static formal o
semiformal anlisis (no ejecutable) que
puede ser utilizado para evaluar un diseo
(por ejemplo, anlisis de rbol a fallos o
automatizada comprobacin cruzada).
anlisis de vulnerabilidad de diseo (por
ejemplo, el anlisis esttico de las
debilidades de seguridad) puede llevarse a
cabo si la seguridad es una preocupacin. El
anlisis formal del diseo utiliza modelos
matemticos que permiten a los diseadores
predicado el comportamiento y validar el
rendimiento del software en lugar de tener
que depender por completo de la prueba.
anlisis de diseo formal puede ser utilizado
para detectar errores de especificacin y
diseo residuales (per- HAPS causado por
la imprecisin, la ambigedad, y algunas
veces otros tipos de errores). (Ver tambin
Las medidas pueden ser utilizados para evaluar 2- Diseo de
Software15
o estimar cuantitativamente diversos aspectos
de un diseo de software; por ejemplo, tamao,
estructura, o la calidad. La mayora de las
medidas que se han propuesto dependen del
mtodo utilizado para la produccin del diseo.
Estas medidas se clasifican en dos grandes
categoras:

medidas (estructurada) de diseo basados

en funciones: medidas obtenidas mediante
el anlisis fun- cional de descomposicin;
generalmente representado mediante un
diagrama de estructura (a veces llamado
un diagrama jerrquico) sobre la que se
pueden calcular diversas medi- das.
medidas de diseo orientada a objetos: la
estructura de diseo se representa
tpicamente como un diagrama de clases,
en el que se pueden calcular diversas
medidas. Medidas sobre las propiedades
del contenido interno de cada clase
tambin se pueden calcular.

6. Las notaciones de diseo de software

Existen muchas notaciones para representar

artefactos de diseo de software. Algunos se
utilizan para describir la organizacin
estructural de un diseo, otros para representar
el comportamiento de soft- ware. Ciertas
notaciones se utilizan sobre todo durante el
diseo arquitectnico y otros, principalmente
durante el diseo detallado, aunque algunas
anotaciones se pueden utilizar para ambos
propsitos. Adems, algunas anotaciones se
utilizan sobre todo en el contexto de los
mtodos de diseo especficos (ver tema 7,
Software de Diseo Estrategias y Mtodos).
Tenga en cuenta que el diseo de software a
menudo se logra usando notaciones mlti- ples.
A continuacin, se clasifican en las notaciones
para describir la vista estructural (esttico)
frente a la vista del comportamiento
(dinmico).

6.1. Las descripciones estructurales (esttico

Vista)
[4 *, c7] [5 *, c6, c7] [6 *, c4, c5, c6,
c7]
[12 *, c7] [14 *,
c7]

Las siguientes anotaciones, en su mayora, pero

no siempre grfica, describir y representar los
aspectos estructurales de un diseo de software
es que, son
2-16 Gua SWEBOK V3.0

se usa para describir los componentes otra parte, las descripciones del
principales y cmo comportamiento pueden incluir una
que estn interconectados (visin esttica): justificacin de la decisin de diseo tales como
la forma de un diseo cumplir con los
Descripcin de la arquitectura idiomas requisitos de seguridad.
(AVD): textual, a menudo formal, idiomas
utilizados para describir la arquitectura de
software en trminos de componentes y
conectores.
Clase y objeto diagramas: se utilizan para
represen- envan un conjunto de clases (y
objetos) y sus interrelaciones.
diagramas de componentes: utilizados para
representar un conjunto de componentes (
fsico y reemplazar- parte capaz [s] de un
sistema que [conforme] para y
[proporcionar] la realizacin de un conjunto
de caras inter [18]) y sus interrelaciones .
tarjetas responsabilidad clase colaboradores
(CRC): se utiliza para denotar los nombres
de los componentes (clase), sus
responsabilidades, y los nombres de sus
componentes colaboradoras.
Los diagramas de despliegue: utilizados
para representar un conjunto de nodos
(fsicas) y sus interrelaciones, y, por lo
tanto, para modelar los aspectos fsicos de
software.
diagramas entidad-relacin (ERD): se
utilizan para representar los modelos
conceptuales de los datos almacenados en
los depsitos de informacin.
Descripcin de la interfaz de idiomas (IDL):
lenguajes de programacin que se usa para
definir las interfaces (nombres y tipos de
operaciones exportados) de los
componentes de software.
los diagramas de estructura: se utiliza para
describir la estructura de los programas de
llamadas (que los mdulos de llamada, y se
llaman por, qu otros mdulos).

6.2. Las descripciones de comportamiento (vista

dinmica)
[4 *, c7, c13] [5 *, c6, c7] [6 *, c4, c5, c6, c7]
[14 *, c8]

Las siguientes notaciones y lenguajes, algunos

grfica y textual alguna, se utilizan para
describir el comportamiento dinmico de los
sistemas y componentes de software. Muchas de
estas anotaciones se uso-ful sobre todo, pero no
exclusivamente, durante el diseo detallado. Por
 2- Diseo de
diagramas de actividad: se utiliza para Software17
mostrar el flujo de control de una actividad
a. Se puede utilizar para repre- actividades
concurrentes resienten.
diagramas de comunicacin: se utilizan para
mostrar las interacciones que se producen
entre un grupo de objetos; se hace hincapi
en los objetos, sus enlaces, y los mensajes
que intercambian en estos enlaces.
diagramas de flujo de datos (DFDs): Se
utiliza para mostrar el flujo de datos entre los
elementos. Un flujo de datos gramo dia-
ofrece una descripcin basada en modelo-
ing el flujo de informacin en torno a una
red de elementos operativos, con cada
elemento haciendo uso de o la modificacin
de la informacin que fluye en ese elemento
[4 *]. Los flujos de datos (y por tanto los
diagramas de flujo de datos) se pueden
utilizar para el anlisis de la seguridad, ya
que ofrecen identifica- cin de posibles
caminos para el ataque y el cierre difusin de
la informacin confidencial.
Las tablas de decisin y diagramas: se
utilizan para REPRESENTA combinaciones
complejas de condiciones y acciones.
Diagramas de flujo: se utilizan para
representar el flujo de control y las acciones
asociadas a realizar.
Los diagramas de secuencia: se utiliza para
mostrar las interacciones entre un grupo de
objetos, con nfasis en el ordenamiento hora
de los mensajes transmitidos entre objetos.
transicin de estado y tabla de estado
diagramas: se utiliza para mostrar el flujo de
control de estado a estado y cmo el
comportamiento de un componente cambia
sobre la base de su estado actual en una
mquina de estado.
lenguajes de especificacin formales:
idiomas textuales que utilizan nociones
bsicas de matem- ticas (por ejemplo, la
lgica, set, secuencia) para definir
rigurosamente y de manera abstracta
interfaces de componentes de software y el
comportamiento, a menudo en trminos de
condiciones previas y posteriores. (Vase
tambin la Ingeniera de Software Modelos y
ods met KA).
pseudo cdigo y lenguajes de diseo de
programas (PDL): lenguajes de
programacin como estructurados utilizados
para describir, en general, en la etapa de
diseo detallado, el comportamiento de un
proce- dimiento o mtodo.
2-18 Gua SWEBOK V3.0

7. El software de diseo estrategias y mtodos diseo de mediados de 1980 (sustantivo = objeto;

verbo
Existen varias estrategias generales para ayudar = Mtodo; adjetivo = atributo), donde heren- cia
a guiar el proceso de diseo. En contraste con y el polimorfismo juegan un papel clave, al
las estrategias generales, los mtodos son ms campo del diseo basado en componentes,
especficos en cuanto a que proporcionan donde la formacin de metain- se puede definir y
generalmente un conjunto de notaciones para ser se accede a (a travs de la reflexin, por
utilizado con el mtodo, una descripcin del ejemplo). Aunque las races del diseo orientado
proceso que se utilizar cuando se sigue el a objetos provienen del concepto de abstraccin
mtodo, y un conjunto de directrices para el uso de datos, diseo impulsado por la
del mtodo. Tales mtodos son tiles como un responsabilidad ha sido propuesta como un
marco comn para los equipos de ingenieros de enfoque alternativo al diseo orientado a
software. (Ver tambin los modelos niera de objetos.
Software Engineers y Mtodos KA).
7.4. Estructura de Datos Diseo Centrado
[4 *, c14, c15]

7.1. Las estrategias estructura centrada en los datos de diseo

generales [4 *, c8, c9, c10] [12 *, comienza a partir de las estructuras de datos de
c7] un programa manipula ms que de la funcin
que realiza. El ingeniero de software
Algunos ejemplos citados con frecuencia de las primero describe las estructuras de datos de
estrategias generales tiles en el proceso de entrada y salida y luego se desarrolla la
diseo incluyen las estrategias de dividir-y- estructura de control del programa en base a
vencers y refinamiento paso a paso, de arriba estos diagramas de estructura de datos. Se han
hacia abajo frente a las estrategias de abajo hacia propuesto varias heursticas para hacer frente a
arriba, y las estrategias que hacen uso de la ejemplo especial casos-para, cuando hay una
heurstica, el uso de patrones y lenguajes tern falta de coincidencia entre las estructuras de
PAT- y el uso de un enfoque iterativo y mentales entrada y salida.
incre-.
7.5. Diseo basado en componentes (CDB)
7.2. Funcin-Oriented (Estructurado) Diseo [4 *, c17]
[4 *, c13]
Un componente de software es una unidad
Este es uno de los mtodos clsicos de diseo de independiente, que tiene interfaces bien
software, donde los centros de descomposicin definidas y dependen- cias que pueden estar
en que identifique los valores las principales compuestos y desplegado de forma
funciones del software y luego elab- perorando y independiente. aborda cuestiones de diseo
refinarlos en una de arriba hacia abajo de forma basadas en componentes relacionados con la
jerrquica. Diseo estructurado se utiliza prestacin, el desarrollo y la integracin de estos
generalmente despus de un anlisis componentes con el fin de mejorar la
estructurado, produciendo de este modo (entre reutilizacin. Reutilizados y off-the-shelf
otras cosas) diagramas de flujo de datos y software com- ponentes deben cumplir mentos el
descripciones de procesos asociados. Los mismo requisito de seguridad como un nuevo
investigadores han propuesto diversas software. gestin de la confianza es un problema
estrategias (por ejemplo, el anlisis de la de diseo; componentes tratados como hav- ing
transformacin, anlisis de transacciones) y un cierto grado de confiabilidad no debe
heurstica (por ejemplo, fan-in / fan-out, el depender de componentes o servicios sean
alcance de efecto vs. alcance de control) para menos fiables.
transformar un DFD en una arquitectura de
software en general representado como una 7.6. Otros metodos
diagrama de estructura.
 [5 2-
*, Diseo de
c19, c21]
Software19
7.3. Diseo Orientado a
Objetos [4 *, Tambin existen otros enfoques interesantes (ver
c16] los modelos de ingeniera de software y mtodos
Se han propuesto numerosos mtodos de diseo KA). Los mtodos iterativos y adaptativas
de software basados en objetos. El campo ha Imple- incrementos de software Ment y reducir
evolucionado a partir de la orientada a objetos nfasis en el requisito de software rigurosa y
temprano (OO) diseo.
 2- Diseo de
Software11

diseo orientada a aspectos es un mtodo por el 8. Herramientas de diseo de software

cual el software se construye utilizando los [14 *, c10, Apndice A]
aspectos a las aplicar las preocupaciones
transversales y extensiones que se identifican Las herramientas de diseo de software se puede
durante el proceso de los requisitos software. utilizar para apoyar la creacin de los artefactos
arquitectura orientada a servicios es una manera de diseo de software durante el proceso de
de construir software distribuido mediante desarrollo de software. Pueden apo- parte
servicios web ejecutados en ordenadores portuaria o la totalidad de las siguientes
distribuidos. sistemas de soft- ware se actividades:
construyen a menudo mediante el uso de servi-
cios de diferentes proveedores porque protocolos traducir el modelo de requisitos en una
estndar (tales como HTTP, HTTPS, SOAP) se la representacin de diseo;
han diseado para soportar la comunicacin de para proporcionar soporte para la
servicios y el intercambio de informacin de representacin de los componentes funcio-
servicio. nales y su interfaz (s);
para implementar la heurstica refinamiento
y la particin;
proporcionar directrices para la evaluacin de
la calidad.
2-12 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

al. 2010 [14

Gamma et al. 1994

Brookshear 2008

doLEMENTOS et
1999 [6 *]
2011 [5 *]
Budgen 2003

1993 [17
en 2008

Nielsen
Alabamal
Pgina-Jones
SommervilLe

[12 *]

[13 *]

[15 *]
[4 *]

nortea
*]

*]
1. Fundamentos
del Diseo de
Software
1.1. Diseo general
c1
Conceptos
1.2. El contexto de
c3
Diseo de Software
1.3. El Proceso de
c2
Diseo de
Software
1.4. Principios de C6, C7, C1, C8,
c1
Diseo de Software c21 C9
2. Cuestiones clave
en el diseo de
software
2.1. concurrencia c18
2.2. Control y
c21
Manipulacin de
Eventos
2.3. Persistencia de C9
datos
2.4. Distribucin
c18
de Componentes
2.5. Error y control
de excepciones y la c18
tolerancia a fallos
2.6. interaccin y
c16
Presentacin
c12,
2.7. Seguridad c4
c18
3. Estructura del
software y
Arquitectura
3.1. Las
estructuras c1
arquitectnicas y
puntos de vista c1, c2,
3.2. Estilos
c3, c4,
arquitectnicos
c5
c3, c4,
3.3. Patrones de
c5
diseo
 2- Diseo de
Software13

al. 2010 [14

Gamma et al. 1994

Brookshear 2008

doLEMENTOS et
1999 [6 *]
2011 [5 *]
Budgen 2003

1993 [17
en 2008

Nielsen
Alabamal
Pgina-Jones
SommervilLe

[12 *]

[13 *]

[15 *]
[4 *]

nortea
*]

*]
3.4. Las
c6
decisiones
Arquitectura
3.5. Las
Diseo C6, C7,
familias de los
C16
programas y
4. marcos
Diseo de
Interfaz de
Usuario
4.1. usuario
c29-
generalDiseo de c2
web
Interfaces
Principio
4.2. Interfaz de c29-
usuario Problemas web
Diseo
4.3. El diseo de
c29-
las modalidades
web
de interaccin del
usuario
4.4. El diseo
c29-
de la
web
informacin
Presentacin
4.5. Interfaz de c29-
usuario web
Proceso
4.6. de
Localizacin e
diseo C8, C9
internacionalizacin
4.7. Metforas y
c5
modelos
5. conceptuales
Anlisis de
Calidad de Software
de Diseo y
Evaluacin
5.1. Calidad
c4
atributos
5.2. Anlisis de
calidad y tcnicas
c4 c24
de evaluacin

5.3. medidas c4 c24

2-14 Gua SWEBOK V3.0

al. 2010 [14

Gamma et al. 1994

Brookshear 2008

doLEMENTOS et
1999 [6 *]
2011 [5 *]
Budgen 2003

1993 [17
en 2008

Nielsen
Alabamal
Pgina-Jones
SommervilLe

[12 *]

[13 *]

[15 *]
[4 *]

nortea
*]

*]
6. Diseo de
Software
notaciones
6.1. Las
C4, C5,
descripciones c7 C6, C7 c7 c7
C6, C7
estructurales
(esttico
6.2. Las Vista)
C7, C13, C4, C5,
descripciones de C6, C7 c8
c18 C6, C7
comportamiento
7. (vista
Diseo dinmica)
de
Software
estrategias y
mtodos
7.1. General C8, C9,
c7
Estrategias c10
7.2. Funcin-
Diseo Orientado c13
(estructurado)
7.3. Orientado a
c16
objetos
Diseo
7.4. Estructura de c14,
datos- c15
Diseo
7.5. Centrado
c17
Componente-
El diseo basado c19,
7.6.
(CDB)Otros metodos
c21
8. Herramientas c10,
de diseo de App.
software UN
 2- Diseo de
Software15

LECTURAS mejores libros disponibles en la actualidad en la

arquitectura de software.
Roger Pressman, Ingeniera de Software: Un
Enfoque de la practicante (sptima edicin)
[19].

Por cerca de tres dcadas, Ingeniera de

Software de Roger Pressman: Enfoque para
profesionales ha sido uno de los libros de texto
ms importantes del mundo en ingeniera de
software. Cabe destacar que este libro de texto
comple- mentarios a [5 *] integral presenta
software de diseo, incluyendo los conceptos de
diseo, diseo arquitectnico, diseo a nivel de
componentes, diseo de la interfaz de usuario,
diseo basado en patrones y diseo de
aplicaciones web.

El 4 + 1 Ver Modelo de Arquitectura [20]. El

artculo seminal The 4 + 1 Vista Modelo or-

noce una descripcin de una arquitectura de
software
utilizando cinco vistas concurrentes. Los cuatro
puntos de vista del modelo son la vista lgico, la
vista del desarrollo, la vista del proceso, y la
vista fsico. Adems, seleccionadocasos de usoo
escenarios se utilizan para ilustrar la
arquitectura. Por lo tanto, el modelo contiene 4 +
1 vistas. Las vistas se utilizan para describir el
software segn lo previsto por las diferentes
partes interesadas, tales como los usuarios
finales, desarrolladores y administradores de
proyectos.

Len Bass, Paul Clements, y Rick Kazman,

Arquitectura de software en la prctica [21].

Este libro presenta los conceptos y las mejores

ticas ticas de arquitectura de software, es decir,
cmo el software est estructurado y cmo
interactan los componentes del software.
Basndose en su propia experiencia, los autores
cubren los temas tcnicos esenciales para el
diseo, especificacin y validacin de
arquitecturas de software. Tambin hacen
hincapi en la importancia del contexto
empresarial en el que se ha diseado gran soft-
ware. Su objetivo es dar a conocer la
arquitectura de software en un entorno del
mundo real, lo que refleja tanto las
oportunidades y limitaciones que orga-
nizaciones encuentran. Este es uno de los
2-16 Gua SWEBOK V3.0
Referencias

[1] ISO / IEC / IEEE 24765: 2010 Sistemas y

de Ingeniera de Software-Vocabulario,
ISO / IEC / IEEE 2010.

[2] IEEE Std. 12207-2008 (tambin conocido

como ISO / IEC
12207: 2008) estndar para los sistemas y
software de ingeniera en software
procesos de ciclo de vida, IEEE 2008.

[3] T. DeMarco, La paradoja de Arquitectura y

Diseo de Software, Conferencia Premio
Stevens, 1999.

[4 *] D. Budgen, Diseo de software, 2 ed.,

Addison-Wesley, 2003.

[5 *] I. Sommerville, Ingeniera de Software, 9

ed., Addison-Wesley, 2011.

[6 *] M. Pgina-Jones, Fundamentos del Diseo

orientado a objetos en UML, 1st ed.,
Addison-Wesley, 1999.

[7] Diccionario Colegiado de Merriam-Webster,

ed 11., 2003.

[8] IEEE Std. 1069-2009 Estndar de

Informacin Descripcin Diseo
Tecnologa-diseo de sistemas en software,
IEEE, 2009.

[9] ISO / IEC 42010: 2011 Sistemas y Prcticas

de Ingeniera de Software recomendado
para la descripcin arquitectnica de los
sistemas intensivos Software-, ISO / IEC
2011.

[10] J. Bosch, Diseo y Uso de Software

Arquitecturas: La adopcin y el desarrollo
de un enfoque Producto-Lnea, ACM
Press, 2000.

[11] G. Kiczales et al., Programacin

orientada a aspectos, Proc. Conf
Europea 11. Programacin orientada a
objetos (ECOOP 97), Springer, 1997.
 2- Diseo de
Software17

[12 *] JG Brookshear, Ciencias de la [17 *] J. Nielsen, Ingeniera de usabilidad,

Computacin: Una visin general, 10 ed, Morgan Kaufmann, 1993.
Addison-Wesley, 2008..
[18] G. Booch, J. Rumbaugh, y I. Jacobson, La
[13 *] JH Allen et al, software de Gua del usuario de Lenguaje de Modelado
seguridad Ingeniera:. Gua para los Unificado, Addison-Wesley, 1999.
gerentes de proyecto, Addison-
Wesley, 2008. [19] RS Pressman, Ingeniera de Software:. El
enfoque de un practicante, 7 ed, McGraw-
[14 *] P. Clements et al., el software de Hill, 2010.
documentacin: Arquitecturas. Vistas y
ms all, 2 ed, Pearson Education, 2010. [20] PB Kruchten, The 4 + 1 Ver Modelo de
Arquitectura, IEEE Software, vol. 12, no.
[15 *] E. Gamma et al, patrones de diseo:.. 6, 1995, pp. 42-55.
Elementos de software orientado a objetos
reutilizables, 1st ed, Addison-Wesley [21] L. Bass, P. Clements, y R. Kazman,
Professional, 1994. Arquitectura de Software en la prctica, 3
ed., Addison-Wesley Professional, 2013.
[16] I. Jacobson, G. Booch, Rumbaugh y J.,
El proceso de desarrollo de software
unificado, Addison-Wesley Professional,
1999.
 CAPTULO 3

CONSTRUCCIN DEL

SOFTWARE

de diseo se realiza durante la actividad de

SIGLAS construccin. Por lo tanto, la construccin del
de programacin de aplicaciones software KA est estrechamente vinculado con el
API software de diseo KA.
Interfaz
A lo largo de la construccin, tanto los
COTS Commercial Off-The-Shelf ingenieros de software de prueba de unidad e
GUI Interfaz grfica del usuario integracin a prueba su trabajo.
Desarrollo integrado
IDE
Ambiente
Dios mio grupo de administracin de objetos
Interfaz de sistema operativo
POSIX
porttil
TDD Desarrollo basado en pruebas
UML Lenguaje de Modelado Unificado

INTRODUCCIN

La construccin software trmino se refiere a la

creacin detallada de software que trabaja a
travs de una combinacin de codificacin,
verificacin, la unidad de pruebas, las pruebas
de integracin, y la depuracin.
El rea de conocimiento Construccin de
Software (KA) est vinculado a todos los dems
Kas, pero est ms fuertemente relacionada con
Diseo de software y pruebas de software
debido a que el proceso de construccin de
software consiste en el diseo de software y
pruebas significativa. El proceso utiliza la salida
de diseo y proporciona una entrada a la prueba
( diseo y prueba en este caso se hace
referencia a las actividades, no la KAS). IES
Boundar- entre el diseo, construccin y pruebas
(si alguna) variarn dependiendo de los procesos
del ciclo de vida del software que se utilizan en
un proyecto.
Aunque algunos de diseo detallado se puede
realizar antes de la construccin, tanto el trabajo
 2- Diseo
gestin de proyectos, en la medida endela gestin
Por lo tanto, la construccin del software KA Software19
de cons- truccin puede presentar retos
est estrechamente vinculada a la Prueba de considerables.
Software KA tambin.
construccin de software normalmente DISTRIBUCIN DE TEMAS PARA LA
produce el mayor nmero de elementos de CONSTRUCCIN DEL SOFTWARE
configuracin que necesitan ser administrados
en un proyecto de software (archivos de cdigo La figura 3.1 muestra una representacin grfica
fuente, documentacin, casos de prueba, y as de la descomposicin de nivel superior de la
sucesivamente). Por lo tanto, la construccin avera para la Construccin de Software KA.
del software KA tambin est estrechamente
ligada a la Gestin de la Configuracin de 1. Fundamentos de software Construccin
Software KA.
Mientras que la calidad del software es fundamentos de construccin de software
importante en todos los Kas, cdigo es la incluyen
entrega definitiva de un proyecto de software,
y por lo tanto la calidad del software KA est minimizando la complejidad
estrechamente ligada a la construccin del anticipar el cambio
software KA. la construccin para la verificacin
Dado que el software la construccin requiere reutilizar
el conocimiento de algoritmos y de las normas de construccin.
prcticas de codificacin, que est
estrechamente relacionado con la Informtica Los primeros cuatro conceptos se aplican al
Fundamentos KA, que se ocupa de la diseo, as como a la construccin. Las
informtica Foundation ciones que apoyan el siguientes secciones definen
diseo y construccin de productos de
software. Tambin est relacionada con la

3-1
3-2 Gua SWEBOK V3.0

Figura 3.1. Desglose de temas para la Construccin de Software KA

 Construccin de Software 3-
3

estos conceptos y describen cmo se aplican a la pruebas independientes y las actividades

construccin. operacionales. Las tcnicas especficas que
apoyan la construccin para la verificacin
1.1. Complejidad minimizando incluyen siguiendo los estndares de
[1 *] codificacin para apoyar las revisiones de
cdigo y pruebas de unidad, la organizacin de
La mayora de las personas estn limitadas en su cdigo para apoyar pruebas automatizadas, y
capacidad de mantener estructuras complejas e restrict- ing el uso de estructuras len- guaje
informacin en sus memorias de trabajo, complejas o difciles de comprender, entre otros.
especialmente durante un perodo largo, de
tiempo. Esto demuestra ser un factor importante 1.4. Reutilizar
que influye en cmo las personas transmiten [2 *]
intencin de com- putadoras y conduce a una de
las unidades ms fuertes en la construccin de Reutilizacin refiere al uso de los activos
software: minimizando compleji- dad. La existentes en la solucin de diferentes
necesidad de reducir la complejidad se aplica problemas. En la construccin de software, los
esencialmente a todos los aspectos de la activos ical typ- que se reutilizan incluyen
construccin de software y es particularmente bibliotecas, mdu-, componentes, cdigo fuente,
crtico para las pruebas de las construcciones de y off-the-shelf comercial (COTS) activos. La
software. reutilizacin es mejor ticas ticed
En la construccin de software, complejidad sistemticamente, de acuerdo con un proceso
reducida se logra a travs enfatizando la bien definido y repetible. reutilizacin
creacin de cdigo que es simple y fcil de leer sistemtica puede permitir significativo de la
en lugar de inteligente. Esto se logra a travs de productividad de software, la calidad y mejora
hacer uso de las normas (vase la seccin 1.5, de los costes.
Normas de Construccin), el diseo modular Reutilizacin tiene dos facetas estrechamente
(ver seccin 3.1, Diseo Construccin), y otras relacionados: la construccin para la
numerosas tcnicas especficas (ver seccin 3.3, reutilizacin y reutilizacin construccin con
Coding). Tambin es apoyado por tcnicas de Los antiguos medios para crear activos de
calidad centrado con la construccin (ver sec- software reutilizables, mientras que el segundo
cin 3.7, Construccin de Calidad). medio para la reutilizacin de activos de
software en la construccin de una nueva
1.2. pronstico del cambio solucin. Reutilizacin menudo trasciende los
lmites de los proyectos, lo que significa activos
reutilizados se pueden construir en otros
proyectos u organizaciones.
[1 *] 1.5. Normas de construccin
[1 *]
La mayora del software va a cambiar con el
tiempo, y el
anticipacin de los cambios a muchos aspectos
de la construccin de software; los cambios en 1.3. La construccin de Verificacin
los entornos en los que opera el software [1 *]
tambin afectan al software de diversas maneras.
Anticipar el cambio ayuda a los ingenieros de La construccin de medios de verificacin de
software construir software extensible, lo que construccin de software de tal manera que los
significa que pueden mejorar un producto de fallos pueden ser lectura ily encontrados por los
software sin interrumpir la estructura ingenieros de software de escritura del software,
subyacente. as como por los probadores y usuarios durante
cambio Anticipando es apoyado por muchas
tcnicas espec- espe- (vase la seccin 3.3,
Coding).
3-4 Gua
La SWEBOK
aplicacinV3.0de Dardos desarrollo dares
externos o internos durante la construccin
ayuda a lograr los objetivos de un pro- yecto
para la eficiencia, la calidad y el costo. En
concreto, las opciones de progra- permisible
subconjuntos del lenguaje Ming y normas de
uso de ayudas son importantes para lograr una
mayor seguridad.
Normas que afectan directamente a
problemas de construccin incluyen

mtodos de comunicacin (por ejemplo,

Standards para formatos de documentos y
contenidos)
lenguajes de programacin (por ejemplo,
las normas len- guaje para lenguajes como
Java y C ++)
los estndares de codificacin (por
ejemplo, los estndares para las
convenciones de nomenclatura, el diseo y
la sangra)
plataformas (por ejemplo, los estndares
de interfaz de llamadas al sistema
operativo)
 Construccin de Software 3-
5

herramienta (por ejemplo, normas para (incluyendo los requisitos, el diseo y la

anotaciones esquemticas como UML planificacin) o que los solapamientos. Estos
(Unified Modeling Language)). enfoques tienden a diseo, codificacin, y las
actividades de prueba mezclar, y que a menudo
El uso de estndares externos. La tratan la combinacin de actividades como la
construccin depende de la utilizacin de construccin (ver
estndares externos para lenguajes de
construccin, herramientas de construccin,
interfaces tcnicas, y las interacciones entre el
software de construccin KA y otros KAs.
Normas proceden de numerosas fuentes,
incluyendo especificaciones de la interfaz de
hardware y software (como el Grupo de Gestin
de Objetos (OMG)) y las organizaciones inter-
nacionales (tales como el IEEE o ISO).
El uso de estndares internos. Las normas
tambin pueden ser creados sobre una base de
organizacin a nivel corpo- rativa o para su uso
en proyectos especficos. Estas normas apoyan
la coordinacin de las relaciones de grupo activi-
, lo que minimiza la complejidad, la anticipacin
del cambio, y la construccin para su
verificacin.

2. Construccin de la gestin

2.1. Construccin de Modelos de Ciclo de Vida

[1 *]

Numerosos modelos han sido creados para el

desarrollo de software; algunos hacen hincapi
en la construccin ms que otros.
Algunos modelos son ms lineal desde el
punto cons- truccin de vista, tales como la
cascada y modelos de ciclo de vida de la entrega
por etapas. Estos modelos tratan de la
construccin como una actividad que se produce
slo despus del trabajo prerrequisito importante
ha sido com- plet-requisitos detallados
incluyendo el trabajo, un extenso trabajo de
diseo y planificacin detallada. Los enfoques
ms lineales tienden a enfatizar las actividades
que preceden a la construccin (los requisitos y
diseo) y para crear menticias SEP ms claras
entre las actividades. En estos modelos, el
nfasis principal de la construccin puede ser de
codificacin.
Otros modelos son ms iterativo como el
prototipado evolutivo y desa- rrollo gil. Estos
enfoques tienden a tratar la cons- truccin como
una actividad que se produce simultneamente
con otras actividades de desarrollo de software
3-6 Gua SWEBOK V3.0 Software KA para ms informacin sobre la
el Software de Gestin y Procesos de Software
KAs). medicin).
En consecuencia, lo que se considera que es
cons- truccin depende en cierta medida en
el modelo de ciclo de vida utilizado. En
general, la construccin de software es en su
mayora codificacin y depuracin, pero
tambin implica la planificacin de la
construccin, diseo detallado, las pruebas
unitarias, pruebas de integracin, y otras
actividades.

2.2. Ordenacin de la Edificacin

[1 *]

La eleccin del mtodo de construccin es un

aspecto clave de la actividad de la
construccin-planificacin. La eleccin del
mtodo de construccin afecta el grado en que
se realizan los requisitos previos de la
construccin, el orden en que se realizan, y el
grado en que deben ser completados antes de
que comience el trabajo de construccin.
El enfoque de la construccin afecta la
capacidad del equipo de pro- yecto para reducir
la complejidad, anticiparse a los cambios, y
construir para su verificacin. Cada uno de
estos objetivos tambin pueden ser tratadas en
el pro- ceso, requisitos y diseo de los niveles,
pero que se ver influido por la eleccin del
mtodo de construccin.
planificacin de la construccin tambin
define el orden en que se crean los
componentes e integrados, la estrategia de
integracin (por ejemplo, por etapas o
integracin incremental), los procesos de
gestin de calidad de software, la asignacin de
la asignacin de tareas a los ingenieros de
software especficos, y otras tareas, de acuerdo
con el mtodo elegido.

2.3. Medicin de la construccin

[1 *]

Numerosas actividades de construccin y los

artefactos se pueden medir, incluyendo el
cdigo desarrollado, cdigo modificado,
reutilizado cdigo, el cdigo destruida, cdigo
de complejidad, las estadsticas de inspeccin
de cdigo, culpa y culpa-fix-encontrar tarifas,
el esfuerzo y la programacin. Estos surements
Measure pueden ser tiles para los propsitos
de la gestin de la construccin, lo que
garantiza la calidad durante la construccin, y
mejorar el proceso de construccin, entre otros
usos (vase la Ingeniera de Procesos de
 Construccin de Software 3-
7

3. Consideraciones prcticas sucesivamente. Pueden ser graves contribuyentes

al vulnerabilidades de seguridad.
La construccin es una actividad en la que el El tipo ms simple del lenguaje construccin es
ingeniero de software tiene que hacer frente a las un lenguaje de configuracin, en la que los
limitaciones del mundo real a veces caticos y ingenieros de software elegir entre un conjunto
cambiantes, y l o ella debe hacerlo con limitado de opciones predefinidas para crear un
precisin. Debido a la influencia de las software nuevo o personalizado
restricciones del mundo real, la construccin
est ms impulsado por consideraciones
prcticas que algunos otros Kas, e ingeniera de
software es quizs lo ms oficio- como en las
actividades de construccin.

3.1. Diseo de la construccin

[1 *]

Algunos proyectos de diseo asignan

considerable activi- dad a la construccin,
mientras que otros asignan diseo a una fase
centrada explcitamente en el diseo.
Independien- temente de la asignacin exacta,
algn trabajo de diseo detallado se producir a
nivel de la construccin, y que el trabajo de
diseo tiende a ser dictado por las limitaciones
impuestas por el problema del mundo real que
est siendo tratado por el software.
Al igual que los trabajadores de la
construccin la construccin de una estructura
fsi- cas deben hacer modificaciones a pequea
escala para dar cuenta de las lagunas no
previstos en los planes del constructor,
trabajadores de la construccin de software
deben hacer modificaciones en una escala ms
pequea o ms grande para dar cuerpo a los
detalles del diseo de software durante la
construccin .
Los detalles de la actividad de diseo a nivel
cons- truccin son esencialmente el mismo que
el descrito en el Diseo de Software KA, pero se
aplican en una escala ms pequea de
algoritmos, estructuras de datos y las interfaces.

3.2. Idiomas de construccin

[1 *]
lenguas de construccin incluyen todas las
formas de comunicacin mediante el cual un ser
humano puede especificar una solucin de un
problema ejecutable a un problema. idiomas
cons- truccin y sus implementaciones (por
ejemplo, los compiladores) pueden afectar a los
atributos de calidad de software de rendimiento,
fiabilidad, rentabilidad por-, y as
3-8 Gua SWEBOK V3.0 cadenas de texto y ms en las definiciones
instalaciones. Los archivos de configuracin
basados en texto que se utilizan tanto en los respaldadas por definiciones precisas, de forma
sistemas operativos Windows y Unix son ambigua unidades organizativas y formales (o
ejemplos de esto, y las listas de seleccin de matemticos). notaciones formales de
estilo de men de algunos generadores de construccin y ods met formales estn en la base
programas constituira, otro ejemplo de un semntica de la mayora de las formas de
lenguaje de configuracin. idiomas Toolkit se
utilizan para construir aplica- ciones de
elementos de juegos de herramientas (series
integradas de partes reutilizables especficos de
la aplicacin); que son ms complejos que los
idiomas de configuracin. idiomas Toolkit
pueden definirse explcitamente como
lenguajes de programacin de aplicaciones, o
las aplica- ciones pueden simplemente estar
implicados por el conjunto de un conjunto de
herramientas
de interfaces.
Los lenguajes de script son tipos de uso
comn de los lenguajes de programacin de
aplicaciones. En algunos lenguajes de script,
guiones son llamados archivos por lotes o
macros.
Programacin idiomas son el tipo ms
flexible de las lenguas de construccin.
Tambin contienen la menor cantidad de
informacin sobre reas especficas de
aplicacin y desarrollo de procesos-, por lo
tanto, requieren ms entrenamiento y habilidad
para utilizar con eficacia. La eleccin del len-
guaje de programacin puede tener un gran
efecto sobre la probabilidad de
vulnerabilidades de ser introducido durante
coding- por ejemplo, el uso acrtico de C y C
++ son opciones cuestionables desde un punto
de vista de la seguridad.
Hay tres tipos generales de notacin que se
utiliza para lenguajes de programacin, es
decir,

lingstica (por ejemplo, C / C ++, Java)

formales (por ejemplo, Evento-B)
visual (por ejemplo, MatLab).

notaciones lingsticas se distinguen en

parti- cular por el uso de cadenas de texto para
representar construcciones de software
complejos. La combinacin de cadenas de
texto en patrones puede tener una sintaxis frase
similar. Si se usa adecuadamente, cada uno de
tales cadena debe tener una fuerte connotacin
semntica proporcionar una comprensin
intuitiva inmediata de lo que suceder cuando
el software se ejecuta truccin cin.
Las notaciones formales depender menos
intuitiva, every- significados da de palabras y
 Construccin de Software 3-
9

notaciones de programacin del sistema, donde 3.4. Prueba de la

la precisin, comportamiento en el tiempo, y la construccin [1 *]
capacidad de prueba son ms importantes que la
facilidad de mapeo en lenguaje natural. Por-
construcciones mal tambin utilizan formas mentos, rutinas, clases, paquetes, u otras
definidas con precisin de la combinacin de estructuras);
smbolos que evitan la ambigedad de muchas documentacin de cdigo;
construcciones de lenguaje natural. Cdigo de sintona,
Visual notaciones confiar mucho menos en las
anotaciones textuales de construccin lingstica
y formal y en lugar de confiar en la
interpretacin visual directa y la colocacin de
las entidades visuales que representan el
software subyacente. Visual de la construccin
tiende a ser algo limitado por la dificultad de
hacer declaraciones complejas utilizando slo
el Organizar- cin de los iconos en una pantalla.
Sin embargo, estos iconos pueden ser
herramientas poderosas en los casos en que la
tarea de programacin principal es simplemente
para construir y ajustar una interfaz visual de
un programa, el comportamiento detallado de los
cuales tiene una definicin subyacente.

3.3. Codificacin
[1 *]

Las siguientes consideraciones se aplican a la

actividad de codificacin construccin soft-
ware:

Las tcnicas para crear el cdigo fuente

comprensible, incluyendo las convenciones
de nomenclatura y el diseo de cdigo
fuente;
El uso de clases, tipos enumerados,
variables, constantes con nombre, y otras
entidades similares;
El uso de estructuras de control;
Manipulacin de las condiciones-tanto de
error anticip y excepcional (entrada de
datos errneos, por ejemplo);
Prevencin de las infracciones a nivel de
cdigo de seguridad (desbordamientos de
bfer o lmites ndice de matriz, por
ejemplo);
El uso de recursos a travs de uso de
mecanis- y disciplina de exclusin meca-
para acceder a recursos en serie reutilizables
(incluyendo hilos y cerraduras de base de
datos);
Organizacin del cdigo fuente (en Estado-
3-10 Gua SWEBOK
Construccin implicaV3.0
dos formas de pruebas,
que a menudo son realizadas por el Neer niera
de software que escribi el cdigo:

Examen de la unidad
Pruebas de integracin.

El propsito de las pruebas de la

construccin es el de reducir la brecha entre el
momento en que los fallos se insertan en el
cdigo y el momento cuando se detectan los
fallos, reduciendo as el coste incurrido para
solucionarlos. En algunos casos, los casos de
prueba se escriben despus del cdigo ha sido
escrito. En otros casos, los casos de prueba
pueden crearse antes de cdigo est escrito.
pruebas de construccin tpicamente implica
un subconjunto de los diferentes tipos de
pruebas que se describen en el Testing de
Software KA. Por ejemplo, las pruebas de
construccin no suelen incluir las pruebas del
sistema, las pruebas alfa, pruebas beta, pruebas
de estrs, pruebas de configuracin, las pruebas
de usabilidad, u otros tipos ms especializados
de la prueba.
Dos normas se han publicado sobre el tema
de las pruebas de la construccin: Norma IEEE
829-1998, Norma IEEE para la Documentacin
de software de prueba, y la norma IEEE 1008-
1987, IEEE estndar para el software de
pruebas unitarias.
(Ver secciones 2.1.1., Pruebas unitarias, y
2.1.2., Pruebas de integracin, en el KA de
Pruebas de Software para el material de
referencia ms especializado.)

3.5. Construccin de Reutilizacin

[2 *]

Construccin para su reutilizacin crea

software que tiene el potencial para ser
reutilizado en el futuro para el presente
proyecto u otros proyectos que tienen una base
amplia, la perspectiva multisistmica.
Construccin nueva utilizacin se basa
generalmente en el anlisis y diseo de
variabilidad. Para evitar el problema de clones
de cdigo, se desea encapsular fragmentos de
cdigo reutilizables en bibliotecas o
componentes bien estructuradas.
Las tareas relacionadas con la construccin de
software para
reutilizar durante la codificacin y las pruebas
son los siguientes:
 Construccin de Software 3-
11

aplicacin variabilidad con mecanismos pruebas unitarias y pruebas de integracin

tales como la parametrizacin, la (ver sec- cin 3.4, Pruebas de construccin)
compilacin condicional, patrones de prueba de primer desarrollo (ver seccin 2.2
diseo, y as sucesivamente. en el
encapsulacin variabilidad para que los Pruebas de software KA)
activos soft- ware fcil de configurar y uso de afirmaciones y programacin
personalizar. defensiva
Prueba de la variabilidad proporcionada por depuracin
los activos de software capaces Reus-. inspecciones
Descripcin y publicacin de soft- ware revisiones tcnicas, incluyendo comentarios
activos reutilizables. enteder-ori- seguridad (ver seccin 2.3.2 en
la calidad KA Cesin de Software)
3.6. Construccin con reutilizacin el anlisis esttico (vase la seccin 2.3 de
[2 *] la Calidad KA Soft- Ware)

Construccin con reutilizacin significa crear un La tcnica o tcnicas especficas seleccionadas

nuevo software con la reutilizacin de activos de dependen de la naturaleza del software que se
software existentes. El mtodo ms popular de con- structed, as como en el conjunto de
reutilizacin es la reutilizacin de cdigo de las habilidades de los ingenieros de software que
bibliotecas proporcionadas por el len- guaje, la realizan la construccin activi- lazos. Los
plataforma, las herramientas que se utiliza, o un programadores deben conocer las buenas
repositorio organizativa. Los apartes de estos, prcticas y comunes ejemplo vulnerabilidades-
las aplica- ciones desarrolladas ampliamente hoy para, a partir de listas ampliamente reconocidos
hacen uso de muchas bibliotecas de cdigo acerca de las vulnerabilidades comunes. anlisis
abierto. Reutilizados y off-the-shelf software a esttico automatizado de cdigo para las
menudo tienen la misma o mejor calidad debilidades de seguridad est disponible para
requisitos como nuevo desarrollo de software varios lenguajes de programacin mon com- y se
(por ejemplo, nivel de seguridad). puede utilizar en proyectos crticos para la
Las tareas relacionadas con la construccin de seguridad.
software con actividades de construccin de calidad
reutilizar durante la codificacin y las pruebas diferenciada se ated de otras actividades de
son los siguientes: calidad por su enfoque. actividades de calidad de
la construccin se centran en cdigo y artefactos
La seleccin de las unidades reutilizables, que estn estrechamente relacionados con
Data- bases, procedimientos de prueba, o cdigo como el diseo, a diferencia de otros
datos de prueba. artefactos que estn conectados directamente al
La evaluacin de cdigo o prueba de menos el cdigo, como los requisitos, diseos de
reutilizacin. alto nivel, y los planes detallados.
La integracin de los activos de software
reutilizables en el software actual. 3.8. Integracin
La presentacin de la informacin [1 *]
reutilizacin de cdigo nuevo, los
procedimientos de prueba o datos de prueba.

3.7. construccin de Una actividad clave durante la construccin es el

Calidad [1 cin integracin de rutinas construidos
*] individualmente, clases, componentes y
subsistemas en un nico sis-
Adems de los fallos que resultan de los slo los fallos en la funcionalidad de seguridad,
requisitos y de diseo, defectos introducidos sino tambin fallos en otras zonas que permiten la
durante la construccin pueden dar lugar a anulacin de esta funcionalidad y otras
problemas graves de calidad -por ejem- plo, las debilidades de seguridad o violacines.
vulnerabilidades de seguridad. Esto incluye no Existen numerosas tcnicas para asegurar la
3-12 Gua
cali-SWEBOK
dad de V3.0
cdigo como se construye. Las TEM. Adems, puede necesitar ser integrado
tcnicas primarios utilizados para la calidad de con otros sistemas de software o hardware de un
la construccin incluyen sistema de software en particular.
Las preocupaciones relacionadas con la
integracin de la construccin incluyen la
planificacin de la secuencia en la que se
integrarn los componentes, la identificacin de
lo que se necesita utensilios de hardware,
creando un andamio para apoyar versiones
provisionales del software, para determinar el
grado de la prueba y la calidad del trabajo
realizado en los componentes antes de que sean
integrada, y
 Construccin de Software 3-
13

la determinacin de puntos en el proyecto en el 4.2. Orientado a Objetos Problemas

que se prueban versiones provisionales del de tiempo de ejecucin [1 *]
software.
Los programas pueden estar integrados por
medio de uno u otro
la gradual o el enfoque incremental. la lenguajes orientados a objetos soportan una serie
integracin por etapas, tambin llamada de mecanismos de ejecucin que incluye el
integracin big bang, implica retrasar la polimorfismo y la reflexin. Estos mecanismos
integracin de las partes componentes de de ejecucin aumentan la flexibilidad y
software hasta que todas las partes destinados a adaptabilidad de los programas orientados a
la liberacin de una versin se han completado. objetos. El polimorfismo es la capacidad de un
la integracin incremental se cree que ofrecen lenguaje para apoyar las operaciones generales
muchas ventajas sobre el tra- dicional por fases con- sin saber hasta que el tiempo de ejecucin
de integracin, por ejemplo, la ubicacin de qu tipo de objetos concretos del software
error ms fcil, un mejor seguimiento de los incluir. Debido a que el programa no conoce el
avances, a principios de la entrega del producto, tipo exacto de los objetos de antemano, el
y la mejora de relaciones con los clientes. En la comportamiento exacto est determinado en
integracin gradual, el ERS desarrollos escribir tiempo de ejecucin (unin llamada dinmica).
y probar un programa en pequeos trozos y La reflexin es la capacidad de un programa
luego se combinan las piezas una a la vez. para observar y modificar su propia estructura y
infraestructura de pruebas adicionales, tales el comportamiento en tiempo de ejecucin. La
como talones, los controladores y los objetos de reflexin permite la inspeccin de las clases,
imitacin, por lo general se necesita para interfaces, campos y mtodos en tiempo de
permitir la integracin incrementales. Con la ejecucin con- sin saber sus nombres en tiempo
construccin y la integracin de una unidad a la de compilacin. Tambin permite la
vez (por ejemplo, una clase o compo- nente), el instanciacin en tiempo de ejecucin de nuevos
proceso de construccin pueden proporcionar objetos y invocacin de mtodos que usan
informacin temprana a los desarrolladores y nombres de clase y mtodo con parmetros.
clientes. Otras ventajas de la integracin
incrementales incluyen la ubicacin ms fcil 4.3. Parametrizacin y Genricos
error, la mejora de progreso Monitor-ing,
unidades probado ms completamente, y as
sucesivamente.
[4 *]
4. Tecnologas de la
construccin tipos parametrizados, tambin conocidos como
genricos (ADA, Eiffel) y plantillas (C ++),
4.1. Diseo y Uso de la API [3 permiten la definicin de un tipo o clase sin
*] especificar todos los otros tipos que utiliza. Los
tipos no especificados son
Una interfaz de programacin de aplicaciones las API generalmente duran ms que sus
(API) es el conjunto de firmas que se exportan y implementaciones para una biblioteca o un marco
disponibles para los usuarios de una biblioteca o ampliamente utilizado, se desea que la API sea
un marco para escribir sus aplicaciones. Adems sencillo y se mantiene estable para facilitar el
de las firmas, una API siempre debe incluir desarrollo y mantenimiento de las aplicaciones
declaraciones sobre efectos y / o cliente.
comportamientos (es decir, su semntica) del uso API implica los procesos de ING
programa. Seleccionar-, el aprendizaje, las pruebas, la
diseo de la API debe tratar de hacer la API integracin, y posiblemente se extiende API
fcil de aprender y memorizar, dar lugar a un proporcionadas por una biblioteca o trabajo marco
cdigo legible, ser difcil de mal uso, fcil de (vase la seccin 3.6, de la construccin con la
extender, ser completa, y mantener la reutilizacin).
compatibilidad con versiones anteriores. Como
3-14 Gua SWEBOK
suministrado V3.0
como parmetros en el punto de
uso. Tros eterized tipos proporcionan una
tercera va (adems de la herencia de clases y
composicin de objetos) para com- representar
comportamientos de software orientado a
objetos.

4.4. Afirmaciones, Diseo Por contrato, y

programacin defensiva
[1 *]

Una afirmacin es un predicado ejecutable que

se coloca en un programa de por lo general una
rutina o macro- que permite controles de
tiempo de ejecucin del programa. ciones
aseveraciones son especialmente tiles en
progra- mas alta fiabilidad. Ellos permiten a los
programadores para eliminar ms rpidamente
los supuestos de interfaz que no coinciden, los
errores que se arrastran en cuando se modifica
el cdigo, y as sucesivamente. Las
afirmaciones se obtiene generalmente en el
cdigo en tiempo de desarrollo y
posteriormente se compilan fuera del cdigo
para que no se degradan el rendimiento.
 Construccin de Software 3-
15

Diseo de contrato es un enfoque de excepciones al cdigo de la biblioteca lanza, tal

desarrollo en los que las condiciones previas y vez la construccin de un reportero de excepcin
condiciones posteriores se incluyen para cada centralizada, y la normalizacin de la el uso del
rutina. Cuando se utilizan condiciones previas y programa de excepciones.
condiciones posteriores, se dice que cada clase tolerancia a fallos es una coleccin de tcnicas
de rutina o para formar un contrato con el resto que aumentan la fiabilidad del software mediante
del programa. Por otra parte, un contrato la deteccin de errores y, a continuacin se
proporciona una especificacin precisa de la recupera de ellos si es posible
semntica de una rutina, y por lo tanto ayuda a la
comprensin de su comportamiento. Diseo de
contrato se cree que mejora la calidad de la
construccin de software.
La programacin defensiva medios para
proteger a una rutina de ser roto por las entradas
no vlidas. Las formas ms comunes para
manejar las entradas no vlidas incluyen la
comprobacin de los valores de todos los
parmetros de entrada y decidir cmo manejar
las malas entradas. ciones aseveraciones son de
uso frecuente en la programacin defensiva para
comprobar los valores de entrada.

4.5. Control de errores, control de

excepciones, y la tolerancia a fallos
[1 *]

La forma en que se manejan los errores afecta la

capacidad del software para satisfacer los
requisitos relacionados con Ness correcta-,
robustez, y otros atri- buye no funcionales. Las
afirmaciones se utilizan a veces para comprobar
si hay errores. -Estn mercancas tambin se
utilizan otras tcnicas-tales de manejo de errores
como devolver un valor neutro, sustituyendo la
siguiente pieza de datos vlidos, registrando un
mensaje de advertencia, devolver un cdigo de
error, o el cierre de la soft-.
Las excepciones se utilizan para detectar y
errores de proceso o acontecimientos
excepcionales. La estructura bsica de una
excepcin es que un usos de rutina throw para
lanzar una excepcin detectada y un bloque de
manipu- manipulan de excepcin se captura la
excepcin en un bloque try-catch. El bloque try-
catch puede procesar la condicin errnea de la
rutina o puede devolver el control a la rutina de
llamada. polticas de manejo de excepciones
deben ser cuidadosamente diseadas
seguimiento ing principios comunes como la
inclusin en el mensaje de excepcin toda la
informacin que llev a la excepcin, evitando
los bloques catch vacas, conociendo las
3-16 Gua SWEBOK V3.0 de procesos tecnolgicos. la programacin
o que contiene sus efectos si la recuperacin no
es posi- ble. Las estrategias de tolerancia a basada en el estado se suele combinar
fallos ms comunes incluyen copias de
seguridad y de reintentar, utilizando el cdigo
auxiliar, utilizando algoritmos de votacin, y la
sustitucin de un valor errneo con un valor
falso que tendr un efecto benigno.

4.6. ejecutable modelos

[5 *]

ejecutable modelos abstraer los detalles de los

lenguajes de programacin especficos y las
decisiones sobre la organizacin del software.
Diferente de los modelos tradicionales de
software, una especificacin construido en un
lenguaje de modelado ejecutable como xUML
(UML ejecutable) se puede implementar en
varios entornos de software sin cambios. Un
compilador ejecutable-modelo (transformador)
puede convertir un modelo ejecutable en una
aplicacin utilizando un conjunto de decisiones
sobre el hardware de destino y el entorno de
software. Por lo tanto, la construccin de
modelos ejecutables puede considerarse como
una forma de construir software ejecutable.
ejecutable modelos son una fundacin
apoyando actividades de gestin de la
arquitectura dirigida por modelos (MDA)
inicia- tiva del Object Management Group
(OMG). Un modelo ejecutable es una forma de
especificar completamente un modelo
independiente de la plataforma (PIM); un PIM
es un modelo de una solucin a un problema
que no se basa en ningn tecnologas de
implementacin. A continuacin, un modelo de
plataforma especfica (PSM), que es un modelo
que contenga los detalles de la tacin aplica-,
puede ser producido por tejer el PIM y la
plataforma sobre la que se basa.

4.7. Las tcnicas de construccin basadas en

tablas de base estatal y
[1 *]

de programacin basado en el estado, o la

programacin basada en autmatas, es una
tecnologa de programacin utilizando
mquinas de estado finito para describir
comportamientos del programa. Los grficos
de transicin de una mquina de estados se
utilizan en todas las etapas de desa- rrollo de
software (especificacin, implementacin, ging
debug-, y documentacin). La idea principal es
la construccin de programas de ordenador de
la misma manera se realiza la automatizacin
 Construccin de Software 3-
17

con la programacin orientada a objetos,

formando un nuevo enfoque compuesto llamado, procesamiento de entrada basado en la gramtica
programacin orientado a objetos basado en implica el anlisis de sintaxis, o anlisis
estado. sintctico, de la corriente de token de entrada. Se
Un mtodo de la tabla impulsado es un trata de la creacin de una estructura de datos
esquema que utiliza tablas para buscar (llamado un rbol de anlisis sintctico o rbol de
informacin en lugar de utilizar los estados sintaxis) que representa los datos de entrada. El
lgicos (por ejemplo, si y caja). Se utiliza en las recorrido en orden de aliado del rbol de anlisis
circunstancias apropiadas, claves basadas en no baja da la expresin se acaba de analizar. El
tablas es ms simple que la lgica complicada y analizador comprueba la tabla de smbolos para la
ms fcil de modificar. Al utilizar mtodos presencia de
basadas en tablas, el programador se centra en
dos cuestiones: qu tipo de informacin a
almacenar en la tabla o tablas, y cmo efi- ciente
informacin de acceso en la tabla.

4.8. Configuracin de tiempo

de ejecucin y la
internacionalizacin
[1 *]

Para lograr una mayor flexibilidad, un programa

a menudo se construye para soportar el tiempo
de unin finales de sus Ables variabilidad.
configuracin de ejecucin es una tcnica que
une los valores de variables y ajustes del
programa cuando el programa se est
ejecutando, por lo general mediante la
actualizacin y la lectura de los archivos de
configuracin en un modo justo a tiempo. La
internacionalizacin es la activi- dad tcnica de
la preparacin de un programa, generalmente
software interactivo, para soportar mltiples
lugares. La actividad correspon- diente,
localizacin, es la actividad de la modificacin
de un programa de apoyo a un idioma local
especfica. El software interactivo puede
contener ens doz- o cientos de instrucciones,
indicaciones de estado, mensajes de ayuda,
mensajes de error, y as sucesivamente. Los
procesos de diseo y construccin deben dar
cabida a temas de cuerda y de juego de
caracteres que incluye el cual el conjunto de
caracteres se va a utilizar, qu tipo de cadenas se
usan, cmo mantener las cuerdas sin cambiar el
cdigo, y traducir las cadenas en diferentes
idiomas con un impacto mnimo en el
cdigo de procesamiento y la interfaz de
usuario.

4.9. Procesamiento de la entrada Gramtica-

Basado
[diecisis*]
3-18 Gua SWEBOK V3.0
las variables definidas por el programador que
pueblan el rbol. Despus de construir el rbol
de anlisis, el programa utiliza como entrada a
los procesos computacionales.

4.10. Las primitivas de concurrencia

[7 *]

Una primitiva de sincronizacin es una

abstraccin de programacin proporcionada
por un lenguaje de programacin o el sistema
operativo que facilita rencia concurrente y
sincronizacin. Conocidos primitivas RENCIA
concurrentes incluyen semforos, monitores y
exclusiones mutuas.
Un semforo es un tipo de datos variable o
extracto protegida que proporciona un simple
pero til abstraccin para controlar el acceso a
un recurso comn por mltiples procesos o
hilos en un entorno de programacin
concurrente.
Un monitor es un tipo de datos abstractos que
presenta un conjunto de operaciones definidas
por el programador que se ejecutan con la
exclusin mutua. Un monitor de con- tains la
declaracin de variables compartidas y
cedimientos o funciones pro que operan en esas
variables. El constructo del monitor asegura que
slo un proceso a la vez es activo dentro del
monitor. Un mutex (exclusin mutua) es un sin-
cronizacin primitiva que permite el acceso
exclusivo a un recurso compartido por slo un
proceso o hilo en
un momento.

4.11. middleware
[3 *] [6 *]

Middleware es una amplia clasificacin de

soft- ware que proporciona servicios por
encima de la capa del sistema operativo
todava por debajo de la capa de programa de
aplicacin. Middleware puede proporcionar
ERS tiempo de ejecucin contencin de
componentes de software para proporcionar el
paso de mensajes, la persistencia, y una
ubicacin transparente a travs de una red.
Middleware puede ser visto como un conector
entre los componentes que utilizan el
middleware. Moderno orientado a mensajes
middleware proporciona generalmente un bus
de servicios empresariales (ESB), que apoya
cin y la comunicacin entre mltiples
aplicaciones de soft- ware interaccin
orientada al servicio.
 Construccin de Software 3-
11

4.12. Mtodos de construccin de software algoritmo de seleccin-influye en una velocidad

distribuido y el tamao ejecucin. Anlisis de rendimiento
[7 es la investiga- cin de la conducta de un
*] programa utilizando informa- cin se reunieron
como el programa se ejecuta, con el
Un sistema distribuido es una coleccin de siste- 4.14. Anlisis de Rendimiento y ajuste
mas informticos fsicamente separados, [1 *]
posiblemente heterogneos que estn conectados
en red para proporcionar a los usuarios el acceso eficiencia-determinado cdigo en la arquitectura,
a los diversos recursos que mantiene el sistema. las decisiones de diseo detallado, y la estructura
Construccin de software distribuido se de datos y
distingue de software tradicional truccin cin
por cuestiones tales como paralelismo, comu-
nicacin, y tolerancia a fallos.
Repartido programacin tpicamente cae en
una de varias categoras arquitectnicos bsicos:
cliente-servidor, arquitectura arquitectura de 3
capas, de n niveles, dis- objetos Tributado, de
acoplamiento suelto, o estrecho acoplamiento
(vase la seccin 14.3 de los fundamentos
Informtica KA y la seccin 3.2 de la Diseo de
software KA).

4.13. La construccin de sistemas heterogneos

[6 *]

sistemas heterogneos consisten en una variedad

de unidades de computacin especializados de
diferentes tipos, tales como procesadores de
seal digital (DSPs), controladores de
microorganismos, y los procesadores perifricos.
Estas unidades de cmputo se controlan
independientemente y se comunican entre s.
Los sistemas embebidos son tpicamente
sistemas heterogneos.
El diseo de sistemas heterogneos puede
requerir la combinacin de varios lenguajes de
especificacin para el diseo de diferentes partes
del sistema, en otras palabras, codesign de
hardware / software. Los temas clave incluyen la
validacin en varios idiomas, co-simulacin e
interfaz.
Durante el codiseo hardware / software,
desarrollo de software y hardware de desarrollo
virtual de proceder simultneamente a travs de
la descomposicin gradual. La parte hardware
generalmente se simula en el campo de las
matrices de puertas programables (FPGAs) o
circui- tos integrados de aplicacin especfica
(ASIC). La parte de software se traduce en un
lenguaje de programacin de bajo nivel.
3-12 Gua SWEBOK
objetivo V3.0
de identificar posibles puntos calientes
en el pro- grama a ser mejorado.
Cdigo de sintona, lo que mejora el
rendimiento a nivel de cdigo, es la prctica de
modificar el cdigo correcto en formas que
hacen que funcione ms eficientemente.
Cdigo de sintona por lo general implica slo
cambios a pequea escala que afectan a una
sola clase, una sola rutina, o, ms comnmente,
unas pocas lneas de cdigo. Un amplio
conjunto de tcnicas de optimizacin de cdigo
est disponible, INCLUYENDO las de
sintonizacin expresiones lgicas, bucles,
transformaciones de datos, expresiones, y
rutinas. El uso de un lenguaje de bajo nivel es
otra tc- nica comn para la mejora de algunos
puntos calientes en un programa.

4.15. Normas de plataforma

[6 *] [7 *]

estndares de la plataforma permiten a los

programadores a desarrollar aplicaciones
porttiles que se pueden eje- cuta en entornos
compatibles sin cambios. estndares de la
plataforma por lo general implican un conjunto
de servicios estndar y API que compa-
implementaciones de plataforma ible deben
implementar. Ejemplos tpicos de estndares de
la plataforma son de Java
2 Platform Enterprise Edition (J2EE) y el
estndar POSIX para sistemas operativos
(Portable Operating System Interface), que
representa un conjunto de normas
implementadas principalmente para sistemas
operativos basados en UNIX.

4.16. Programacin Test-First

[1 *]

Ensayos primera programacin (tambin

conocido como Test-Driven Development-
TDD) es un estilo de desa- rrollo popular en la
que los casos de prueba se escriben antes de
escribir ningn cdigo. programacin de
pruebas en primer lugar por lo general puede
detectar defectos antes y corregirlos con ms
facilidad que los estilos de programacin
tradicionales. Por otra parte, la escritura casos
de prueba primeras fuerzas pro-programadores
a pensar acerca de los requisitos y el diseo
antes de la codificacin, exponiendo as a los
requerimientos y problemas de diseo ms
pronto.
 Construccin de Software 3-
13

5. Herramientas de software 5.3. Herramientas de

de construccin prueba de unidad [1 *] [2
*]
5.1. Entornos de desarrollo Prueba de la unidad verifica el funcionamiento
[1 de los mdulos de software en forma aislada de
*] otros elementos de software que son
separadamente contrastables (por ejemplo,
clases,
Un entorno de desarrollo o entorno de desarrollo rutinas, componentes). Prueba de la unidad es a
integrado (IDE), proporciona Comprehensive menudo auto-acoplado. Los desarrolladores
instalaciones hensive a los programadores de pueden utilizar herramientas de prueba de
software para la construccin mediante la unidad y los marcos para extender y crear
integracin de un conjunto de herramientas de ambiente de prueba automatizado. Con las
desarrollo. Las opciones de los entornos de herramientas de pruebas unitarias y marcos, el
desarrollo pueden afectar la eficiencia y la desarrollador puede codificar criterios en la
calidad de construccin de software. prueba para verificar la exactitud de la unidad
En adicional a las funciones bsicas de bajo variabilidad conjuntos de datos ous. Cada
edicin de cdigo, entornos de desarrollo prueba individual se implementa como un
modernos a menudo ofrecen otras caractersticas objeto, y un corredor de prueba se ejecuta todas
como la compila- cin y deteccin de errores las pruebas. Durante la ejecucin de la prueba,
desde dentro del edi- tor, la integracin con el los casos de prueba fallidos sern marcados e
control de cdigo fuente, construir herramientas informaron de forma automtica.
de depuracin / test /, comprimido o delinear
puntos de vista de los programas, cdigo 5.4. Perfilado, anlisis de rendimiento, y cortar
automatizado transforma y soporte para la Herramientas
refactorizacin. [1 *]

5.2. herramientas de anlisis de rendimiento se

Constructores [1 utilizan generalmente para apoyar la
GUI *] sintonizacin cdigo. Las herramientas de
anlisis per- formance ms comunes son
herramientas de perfiles. Un
Un constructor de GUI (Graphical User requeridas para el manejo de eventos. El cdigo
Interface) es una herramienta de desarrollo de de soporte se conecta widgets con los eventos
software que permite el fun desa- para crear y salientes y entrantes que activan las funciones que
mantener interfaces grficas de usuario en un proporcionan la lgica de la aplicacin.
WYSI- WYG (lo que ves es lo que obtienes) de Algunos entornos de desarrollo modernos
modo. Un constructor de interfaz grfica de proporcionan constructores GUI integradas o
usuario por lo general incluye un editor visual constructor GUI plug-ins. Tambin hay muchos
para el desarrollador para disear formas y constructores GUI independientes.
ventanas y gestionar la distribucin de los
widgets por Arrastrando, goteo y ajuste de
parmetros. Algunos constructores GUI pueden
generar automticamente el cdigo fuente
correspondiente a la interfaz grfica de diseo
visual.
Debido a que las aplicaciones GUI actuales
generalmente si- bajo el estilo orientado a
eventos (en la que el flujo del programa es
determinado por eventos y manejo de eventos),
las herramientas de desarrollo GUI suelen
proporcionar asistentes de generacin de cdigo,
que automatizan las tareas ms repetitivas
3-14 Gua SWEBOK
herramienta V3.0
de ejecucin de perfiles supervisa
el cdigo mientras se ejecuta y registra el
nmero de veces que se ejecuta cada
instruccin o cunto tiempo el programa pasa
en cada ruta declaracin o ejecucin. Pro-
presentacin del cdigo mientras se est
ejecutando da una idea de cmo funciona el
programa, donde estn los puntos calientes, y
donde los desarrolladores deben centrarse los
esfuerzos de optimizacin de cdigo.
rebanar programa implica el clculo del
conjunto de instrucciones de programa (es
decir, el programa de rebanada) que pueden
afectar a los valores de las variables
especificadas en algn punto de inters, que se
conoce como un criterio de fragmentacin.
rebanar programa puede ser utilizado para la
localizacin de la fuente de errores, programa
de comprensin, y anlisis de optimizacin.
herramientas de corte en lonchas programa
computan las rebanadas de programas para
varios lenguajes de programacin que utilizan
mtodos de anlisis estticos o dinmicos.
 Construccin de Software 3-
15

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Mellor y Balcer 2002 [5

Silberschatz et al. 2008

Gamma et al. 1994

nully Lobur 2006 [6

al. 2010 [3
doLEMENTOS et
2011 [2 *]
McConnell 2004

SommervilLe
[1 *]

[4 *]

[7 *]
*]
*]

*]
1. Fundamentos
de construccin de
software
c2, c3,
C7-C9,
1.1. minimizando
c24,
Complejidad
c27,
c28,
c31,
C3-C5,
1.2. pronstico c32, c34
C24,
del cambio
C31,
C32,
c8,C34
1.3. La construccin C23
de C20,
Verificacin C31,
1.4. Reutilizar c34 c16
1.5. Normas de
c4
construccin
2. Gestin de la
Construccin
2.1. construccin en C2, C3,
Modelos de Ciclo de C27,
Vida C29
c3, c4,
2.2. Ordenacin
c21,
de la Edificacin
c27-c29
2.3. Construccin
c25, c28
Medicin
3.
Consideracion
es 3.1.
prcticas
Diseo de la C3, C5,
construccin C24
3.2. Construccin
c4
idiomas
C5-
3.3. Codificacin
C19,
C25-
C26
3-16 Gua SWEBOK V3.0

Mellor y Balcer 2002 [5

Silberschatz et al. 2008

Gamma et al. 1994

nully Lobur 2006 [6

al. 2010 [3
doLEMENTOS et
2011 [2 *]
McConnell 2004

SommervilLe
[1 *]

[4 *]

[7 *]
*]
*]

*]
3.4. Prueba de la
c22, c23
construccin
3.5. Construccin de
c16
Reutilizacin
3.6.
c16
Construccin
con
3.7. reutilizacin
Construccin c8,
Calidad C20-C25
3.8. Integracin c29
4. Tecnologas de
la Construccin
4.1. Diseo APIy use
c7

4.2. Orientado a
C6, C7
Objetos Problemas
de
4.3.tiempo de
ejecucin
parametrizacin c1
y genricos
4.4. Afirmaciones,
Diseo por
C8, C9
contrato, y la
programacin
defensiva
4.5. Control de
errores, control de C3, C8
excepciones, y la
tolerancia a fallos
4.6. Ejecutable
c1
modelos
4.7. Las tcnicas
de construccin
c18
basadas en tablas
de base estatal y
4.8. Configuracin
de tiempo de C3, C10
ejecucin y la
internacionalizaci
4.9. Procesamiento
n c5 c8
de la entrada
Gramtica-Basado
 Construccin de Software 3-
17

Mellor y Balcer 2002 [5

Silberschatz et al. 2008

Gamma et al. 1994

nully Lobur 2006 [6

al. 2010 [3
doLEMENTOS et
2011 [2 *]
McConnell 2004

SommervilLe
[1 *]

[4 *]

[7 *]
*]
*]

*]
4.10. Las
c6
primitivas de
concurrencia
4.11. middleware c1 c8
4.12. Mtodos de
construccin de c2
software distribuido
4.13. La
construccin de C9
sistemas
heterogneos
4.14. Anlisis de
c25, c26
Rendimiento y
ajuste
4.15. Normas
c10 c1
de plataforma
4.16. Ensayos
c22
Primera
5. Programacin
Instrumento de
construccin
5.1. Entornos de
c30
desarrollo
5.2. Constructores c30
GUIExamen de
5.3.
c22 c8
la unidad
Herramientas
5.4. Perfilado,
anlisis de
c25, c26
rendimiento,y
Herramienta
s de cortado
3-18 Gua SWEBOK V3.0

LECTURAS Referencias

IEEE Std. 1517-2010 estndar para la [1 *] S. McConnell, cdigo completo, 2 ed.,

tecnologa de la informacin del sistema y Microsoft Press, 2004.
del software-Vida Procesos de reutilizacin
de procesos de ciclo, IEEE, 2010 [8]. [2 *] I. Sommerville, Ingeniera de Software, 9
ed., Addison-Wesley, 2011.
Esta norma especifica los procesos, actividades
y tareas que deben aplicarse durante cada fase [3 *] P. Clements et al, el software de
del ciclo de vida del software para permitir que documentacin: Arquitecturas. Vistas y ms
un producto de software para ser construido a all, 2 ed, Pearson Education, 2010..
partir de los activos reutilizables. Cubre el
concepto de desarrollo basado en la reutilizacin [4 *] E. Gamma et al, patrones de diseo:..
y los procesos de construccin de reutilizacin y Elementos de software orientado a objetos
la construccin con la reutilizacin. reutilizables, 1st ed, Addison-Wesley
Professional, 1994.
IEEE Std. 12207-2008 (tambin conocido como
ISO / IEC [5 *] SJ Mellor y MJ Balcer, ejecutable UML:.
12207: 2008) estndar para los sistemas y Una Fundacin para el Model-Driven
software de ingeniera en software procesos Architecture, 1st ed, Addison-Wesley,
de ciclo de vida, IEEE, 2008 [9]. 2002.

Este estndar define una serie de software los [6 *] L. y J. nulo Lobur, Lo Esencial de la
procesos de desa- rrollo, incluyendo el software Organizacin de Computadores y
de construc- cin proceso, el proceso de Arquitectura, 2 ed., Jones and Bartlett
integracin de software, y el software de proceso Publishers, 2006.
de reutilizacin.
[7 *] A. Silberschatz, PB Galvin, y G. Gagne,
Operating System Concepts, octava ed.,
Wiley, 2008.

[8] IEEE Std. 1517-2010 estndar para la

Tecnologa de la Informacin-sistema y la
duracin del ciclo de Procesos de Software
de reutilizacin de Procesos, IEEE 2010.

[9] IEEE Std. 12207-2008 (tambin conocido

como ISO / IEC
12207: 2008) estndar para los sistemas y
software de ingeniera en software procesos
de ciclo de vida, IEEE 2008.
 Construccin de Software 3-
19

CAPTULO

PRUEBA 4

SOFTWARE

KA. Vale la pena sealar que la terminologa

SIGLAS ga no es uniforme entre las diferentes co-
API Application Program Interface munidades y algunos utilizan el trmino
prueba tambin en referencia a las tcnicas
TDD Desarrollo basado en pruebas estticas.
TTCN3
Pruebas y de control de pruebas de Finito: Incluso en los programas simples, por
notacin lo que muchos casos de prueba son
XP La versin 3 extrema
Programacin tericamente posible que las pruebas tivo
tamiento podra requerir meses o aos

INTRODUCCIN

Las pruebas de software consiste en la verifica-

cin dinmica que ofrece un programa de
comportamientos esperados en un conjunto
finito de casos de prueba, adecuadamente
seleccionados a partir del dominio de ejecucin
generalmente infinita.
En la definicin anterior, palabras en cursiva
uso corresponden a cuestiones clave en la
descripcin del rea de conocimiento de Pruebas
de Software (KA):

Dinmica: Este trmino significa que las

pruebas siempre implica la ejecucin del
programa en las entradas seleccionadas.
Para ser precisos, el valor de entrada por s
sola no siempre es suficiente para SPEC- ify
una prueba, ya que un sistema complejo, no
determinista podra reaccionar a la misma
entrada con comportamientos diferentes,
dependiendo del estado del sistema. En este
KA, sin embargo, el trmino entrada se
mantendr, con la conven- cin implcita
que su significado tambin incluye un
estado de entrada fied speci- en aquellos
casos en los que es importante. tcnicas
estticas son diferentes de y complementaria
a la prueba dinmica. tcnicas estticas
estn cubiertos en la calidad del software
 siempre es fcil, para decidir si los
ejecutar. Es por esto que, en la prctica, un resultados observados de las pruebas del
conjunto completo de pruebas puede programa son aceptables o no; de lo
considerarse generalmente infi- nita, y la contrario, el esfuerzo de prueba se uso-
prueba se lleva a cabo en un subconjunto menos. El comportamiento observado puede
de todas las pruebas posibles, que est ser contrastada con las necesidades del
determinada por criterios de riesgo y usuario (comnmente conocidas como
priorizacin. Las pruebas siempre implica pruebas de validacin), contra un ficacin
un equilibrio entre los recursos y los speci- (prueba para la verificacin), o, haps
horarios, por un lado limitados y los per-, contra el comportamiento esperado de
requisitos de prueba inherentemente los requisitos implcitos o expectativas (ver
ilimitadas, por el otro. pruebas de aceptacin en el software de los
Seleccionado: Las muchas tcnicas de requisitos KA).
prueba propuestos difieren esencialmente
en cmo se selecciona el equipo de En los ltimos aos, la vista de las pruebas de
prueba, y los ingenieros de software deben software ha madurado hasta convertirse en una
ser conscientes de que los diferentes constructiva. Testing ya no se ve como una
criterios de seleccin pueden producir muy actividad que se inicia slo despus de la fase de
diferentes grados de efectividad. Cmo codificacin se completa con el propsito
identificar el criterio de seleccin ms limitado de fallos de deteccin. Las pruebas de
adecuado bajo condiciones dadas es un software es, o debera ser, omnipresente en todo
problema complejo; en la prctica, se el ciclo de desarrollo y mantenimiento de la
aplican tcnicas de anlisis de riesgos y la vida. De hecho, la planificacin de las pruebas
ingeniera de software tise exper-. de software debe comenzar con las primeras
Esperado: Debe ser posible, aunque no etapas del proceso de requisitos de software,

4-1
4-2 Gua SWEBOK V3.0

Figura 4.1. Desglose de temas para las Pruebas de Software KA

y los planes y procedimientos de prueba deben proporcionar informacin acerca de la

ser System- que avanza el desarrollo de software funcionalidad
refinados como Bly-lidades ticamente y
continuamente desarrollados y. Estas actividades
de planificacin y el diseo de prueba de la
prueba proporcionan informacin til para los
diseadores de software y ayudan a poner de
relieve las debilidades potenciales, como
descuidos de diseo / contradicciones u
omisiones / ambigedades en la documentacin.
Para muchas organizaciones, el enfoque de la
calidad soft- ware es una de prevencin: es,
obviamente, mucho mejor para prevenir los
problemas que corregirlos. Las pruebas pueden
verse, entonces, como un medio para
 Software de Pruebas
y los atributos de calidad del software y 4-3
tambin para la identificacin de fallas en
aquellos casos en los que la prevencin de
errores no ha sido eficaz. Es quizs obvio, pero
vale la pena reconocer que el software todava
puede contener errores, incluso despus de la
finalizacin de una extensa actividad de la
prueba. Los fallos de software riencia rienced
despus del parto se abordan mediante el
mantenimiento correctivo. temas de
mantenimiento de software estn cubiertas en
el mantenimiento del software KA.
En la calidad del software KA (ver Tcnicas
para el control de calidad de software), tcnicas
de gestin de la calidad del software se
clasifican principalmente en tcnicas estticas
(sin ejecucin de cdigo) y
4-4 Gua SWEBOK V3.0

tcnicas dinmicas (la ejecucin de cdigo). 1. Fundamentos de pruebas de software

Tanto catego- ras son tiles. Esta KA se centra
en tcnicas dinmicas. 1.1. Las pruebas relacionada Terminologa
Las pruebas de software tambin est
relacionado con la construccin de software (vea 1.1.1. Definiciones de Pruebas y
Pruebas de construccin en el KA Construccin terminologa relacionada
de Software). En particular, la unidad y pruebas [1 *, c1, c2] [2 *,
de integracin estn ntimamente relacionados c8]
con la construccin de software, si no es parte de
ella. Definiciones de pruebas y terminologa
relacionados con las pruebas se proporcionan en
DISTRIBUCIN DE TEMAS PARA LAS las referencias citadas y se resumen como sigue.
PRUEBAS DE SOFTWARE

El desglose de temas para el Software de 1.1.2. Las fallas fallas

Exmenes KA se muestra en la Figura 4.1. Un vs. [1 *, c1s5] [2 *, c11]
desglose ms detallado se proporciona en la
Matriz de Temas
vs Material de referencia al final de este KA. El Varias tcnicas de prueba se han desarrollado
primer tema se describen pruebas de software en las ltimas dcadas, y todava se estn
Fun- proponiendo nuevas. tcnicas generalmente
damentals. Cubre las definiciones bsicas en el aceptadas estn cubiertos en el tercer tema.
campo de pruebas de software, la terminologa Las medidas de prueba relacionados se tratan en
bsica y las cuestiones clave, y el buque el cuarto tema, mientras que las cuestiones
PARENTESCO de pruebas de software con relativas a la prueba Pro- ceso estn cubiertos en
otras actividades. el quinto. Finalmente, herramientas de prueba de
El segundo tema, los niveles de prueba, se software se presentan en el tema seis.
compone de dos subtemas (ortogonales): la
primera subtema se enumeran los niveles en los
que la prueba de software grande se subdivide
tradicionalmente, y el segundo subtema
considera la prueba para las condiciones
especficas o propie- dades y se conoce como
objetivos de la prueba. No todos los tipos de
pruebas se aplican a todos los productos de
software, ni ha sido incluido todos los tipos
posibles.
El objetivo blanco de prueba y la prueba en
conjunto determinan cmo se identifica el
conjunto de prueba, tanto con respecto a su
consistencia-la cantidad de pruebas es suficiente
para alcanzar el indicado objetivo, y a su
composicin, que los casos de prueba deberan
seleccionarse para lograr el objetivo indicado (
aunque por lo general para lograr el obje- tivo
declarado queda implcita y slo se plantea la
primera parte de las dos preguntas anteriores en
cursiva). Criterios para hacer frente a la primera
pregunta se conocen como criterios de
suficiencia de la prueba, mientras que los
relativos a la segunda pregunta son los criterios
de seleccin de las pruebas.
 Muchos trminos se utilizan en la literatura de Software de Pruebas
4-5
ingeniera de software para describir un mal
funcionamiento: Fallo sobre todo, el fracaso y
el error, entre otros. Este ga terminologa se
define precisamente en [3, c2]. Es esencial
distinguir claramente entre la causa de un mal
funcionamiento (para el que se utilizar el fallo
trmino aqu) y un efecto no deseado
observado en servicio entregado del sis- tema
(que se llama un fallo). En efecto bien puede
haber fallos en el software que nunca se
manifiestan como fracasos (ver limitaciones
tericas y prcticas de pruebas en la seccin
1.2, Temas clave). Por lo tanto ing Test- puede
revelar fallos, pero es los defectos que pueden
y deben ser removidos [3]. El defecto ms
genrico trmino puede ser utilizado para hacer
referencia a un fallo o un fracaso, cuando la
distincin no es importante [3]. Sin embargo,
se debe reconocer que la causa de un fallo no
siempre puede ser inequvocamente identi-
ficados. No existen criterios tericos para
determinar definitivamente, en general, el fallo
que provoc un fallo observada. Podra decirse
que era la falla que tuvo que ser modificado
para eliminar el fallo, pero otras
modificaciones podra haber funcionado igual
de bien. Para evitar la ambigedad, se podra
hacer referencia a las entradas de fallo causante
en lugar de fallos, es decir, aquellos conjuntos
de entradas que hacen que aparezca un fracaso.

1.2. Cuestiones clave

1.2.1. Prueba Criterios de seleccin /

Criterios prueba de adecuacin (Reglas de
parada)
[1 *, c1s14, c6s6, c12s7]

Un criterio de seleccin de la prueba es un

medio de seleccin de casos de prueba o la
determinacin de que un conjunto de casos de
prueba
4-6 Gua SWEBOK V3.0

es suficiente para un propsito determinado. en este sentido es el aforismo Dijkstra que las
Prueba criterios quacy ade- se pueden utilizar pruebas pro- grama se puede utilizar para
para decidir cuando la prueba sufi- sufi- ser, o mostrar la presencia de insectos, pero nunca para
se ha logrado [4] (ver terminacin en la seccin mostrar su ausencia [5]. La razn obvia de esto
5.1, las consideraciones prcticas). es que la prueba completa no es viable en el
software realista. Debido a esto, las pruebas
1.2.2. Pruebas Efectividad / Objetivos deben ser impulsada en funcin del riesgo [6,
para las pruebas parte 1] y puede ser visto como una estrategia de
gestin de riesgos.
[1 *, c11s4, c13s11] 1.2.6. El problema de no factibles Caminos
[1 *,
Ensayos sobre la eficacia se determina mediante c4s7]
el anlisis de un conjunto de ejecuciones del
programa. Seleccin de las pruebas que se caminos no factibles son trayectorias de flujo de
ejecutarn puede ser guiado por diferentes control que no pueden ser ejercidos por
objetivos: es slo a la luz del objetivo cualquier dato de entrada. Ellos son un problema
perseguido que la eficacia del equipo de prueba no puede signifi- en pruebas basadas en el
se puede evaluar. camino, sobre todo en la derivacin automtica
de entradas de prueba para ejercer trayectorias
1.2.3. Pruebas Defecto de Descubrimiento de flujo de control.
[1 *, 1.2.7. la
c1s14] capacidad [1 *,
de prueba c17s2]
En las pruebas para la deteccin de defectos, una
prueba exitosa
es la que hace que el sistema falle. Esto es
bastante diferente de las pruebas para demostrar la teora de las pruebas advierte contra atribuir un
que el software cumple sus especificaciones o nivel cado injustificado de confianza a una serie
otras propiedades deseadas, en los que las de pruebas con xito. Desafortunadamente, los
pruebas de caso tiene xito si no se observan resultados ms establecidos de la teora de las
fallos en virtud de casos de prueba realistas y pruebas son negativas, ya que afirman que la
entornos de prueba. prueba nunca puede alcanzar a diferencia de lo
que se consigue en realidad. La cita ms famosa
1.2.4. El problema de Oracle
[1 *, c1s9,
c9s7]

Un orculo es cualquier ser humano o agente

mecnico que decide si un programa se
comport correctamente en una prueba
determinada y, en consecuencia resulta en un
diccionario ver- de pase o Existen muchos
tipos dife- rentes de orculos fracaso.; por
ejemplo, las especificaciones inequvocas
requisitos, modelos de comportamiento, y las
anotaciones de cdigo. La automatizacin de los
orculos mecanizadas puede ser difcil y
costoso.

1.2.5. Limitaciones tericas y prcticas de las

Pruebas
[1 *,
c2s7]
El trmino capacidad de prueba de software Software de Pruebas
4-7
tiene dos significados diferentes pero
relacionados: por un lado, se refiere a la
facilidad con la que un criterio de cobertura de
la prueba dada puede ser satisfecha; por el
contrario, se define como la probabilidad,
posiblemente medir estadsticamente, que un
conjunto de casos de prueba se exponga un
fracaso si el software es defectuoso. Ambos
significados son importantes.

1.3. Relacin de las pruebas a otras actividades

Las pruebas de software se relaciona con, pero

diferente de, esttico tcnicas de gestin de la
calidad del software, Pruebas de correccin,
depuracin y construccin de programas. Sin
embargo, es informativa para con- prueba
Sider desde el punto de vista de los analistas de
la calidad del software y de los certificadores.

Pruebas estticas vs. Calidad de Software

Hombre- Tcnicas agement (Ver Tcnicas
de Gestin de la Calidad de Software en la
calidad del software KA [1 *, c12]).
Las pruebas de exactitud frente a pruebas y
verificacin formal (ver los modelos de
ingeniera de software y mtodos KA [1 *,
c17s2]).
Prueba vs. Depuracin (ver pruebas de la
construccin en la construccin del
software KA y herramientas de depuracin
y tcnicas en los cimientos Informtica
KA [1 *, c3s6]).
4-8 Gua SWEBOK V3.0

Prueba vs. Programa de Construccin (ver hilos funcionales. Las pruebas de integracin es
pruebas de la construccin en la a menudo una actividad continua en cada etapa
construccin del software KA [1 *, c3s2]). de desarrollo durante el cual los ingenieros de
software abstractos perspectivas de distancia de
2. Prueba niveles nivel inferior y se concentran en las perspectivas
del nivel en el que estn inte- grando. Para que
Las pruebas de software se realiza generalmente no sea el software pequeo, sencillo, estrategias
en niveles dife- rentes procesos en todo el de pruebas de integracin incrementales son el
manteni- miento y el desarrollo. Los niveles aliado preferido no baja de poner todos los
pueden ser distinguidos basado en el objeto de componentes juntos en las pruebas una vez que
prueba, que se llama el objetivo, o de la est a menudo llamado big bang.
finalidad, que se llama el objetivo (del nivel de
prueba). 2.1.3. Prueba del sistema
[1 *, c8] [2 *, c8]
2.1. El objetivo de la
prueba [1 *, c1s13] [2 *, c8s1] Las pruebas del sistema se ocupa de probar el
comportamiento de todo un sistema. unidad
efectiva y
El objetivo de la prueba puede variar: un mdulo menudo con el software qua chically
individual, un grupo de tales mdulos estructurado.
(relacionadas por finalidad, uso, , estrategias de integracin sistemticas
comportamiento, o estructura), o todo un modernas son tpicamente arquitectura dirigida,
sistema. Tres etapas de la prueba se pueden que consiste en integrar progresivamente los
distinguir: unidad, inte- gracin, y el sistema. componentes o subsistemas de software basado en
Estas tres etapas de prueba no implican ningn com- identificado
modelo de proceso, ni es uno cualquiera de ellos
se supone que es ms importante que los otros
dos.

2.1.1. Examen de la unidad

[1 *, c3] [2 *, c8]

Prueba de la unidad verifica el funcionamiento

en el aislamiento de elementos de software que
son comprobables por separado. Dependiendo
del contexto, estos podran ser los subprogramas
individuales o un componente ms grande hecha
de unidades altamente cohesivos. Tpicamente,
la unidad de pruebas se produce con acceso al
cdigo siendo probado y con el apoyo de
herramientas de depuracin. Los programadores
que escribieron el cdigo tpicamente, pero no
siempre, las pruebas unitarias conducta.

2.1.2. Pruebas de integracin

[1 *, c7] [2 *, c8]

Las pruebas de integracin es el proceso de

verificar las interacciones entre los componentes
de software. estrategias de pruebas de
integracin Sical cla-, como el de arriba hacia
abajo y de abajo hacia arriba, se utilizan a
pruebas de integracin se han identificado Software de Pruebas
4-9
muchos de los defectos de software. Las
pruebas del sistema se considera generalmente
adecuado para evaluar los requisitos del
sistema, tales como no funcionales seguri- dad,
velocidad, precisin y fiabilidad (ver requisitos
funcionales y no funcionales en los requisitos
de software y software KA cali- dad en el
Requisitos La calidad del software KA).
interfaces externas a otras aplicaciones,
utilidades, dispositivos de hardware, o los
entornos operativos tambin son generalmente
evaluados en este nivel.

2.2. Objetivos de las Pruebas

[1 *,
c1s7]

La prueba se llev a cabo a la vista de objeti-

vos especficos, que se indican ms o menos
explcitamente y con diferentes grados de
precisin. La indicacin de los objetivos de la
prueba en trminos precisos, cuantitativos
apoya la medicin y el control del proceso de
prueba.
Pruebas puede ser destinado a verificar
diferentes pro- piedades. Los casos de prueba
pueden ser diseados para comprobar que las
especificaciones funcionales son correctamente
mentado Implementers, que se refiere vario en
el eratura lit- como las pruebas de
conformidad, las pruebas de correccin, o
pruebas funcionales. Sin embargo, varias otras
propiedades no funcionales pueden ser
probados como bien incluyendo el
rendimiento, la fiabilidad y dad usabil-, entre
muchos otros (ver modelos y caractersticas de
calidad de la calidad del software KA).
Otros objetivos importantes para el ensayo
incluyen
pero no se limitan a la medicin de fiabilidad,
4-10 Gua SWEBOK V3.0

identificacin de las vulnerabilidades de 2.2.4. Logro fiabilidad y Evaluacin

seguridad, evaluacin de la usabilidad y la [1 *, c15] [2 *,
aceptacin de software, por lo que sera tomado c15s2]
diferentes enfoques. Tenga en cuenta que, en
general, los objetivos de la prueba varan segn Las pruebas mejora la fiabilidad mediante la
el destino de la prueba; propsitos diferentes se identificacin y correccin de fallos. Adems,
dirigen a diferentes niveles de pruebas. las medidas estadsticas de fiabilidad se pueden
Los subtemas que figuran a continuacin son derivar por casos de prueba ing generat-
los ms frecuentemente citado en la literatura. aleatoria de acuerdo con el perfil de
Tenga en cuenta que algunos tipos de pruebas funcionamiento del software (ver perfil
son ms apropiados para las pruebas de software operativo en la seccin 3.5, Tcnicas de uso-
paquetes de instalacin a medida, por ejemplo- y base). Este ltimo enfoque se denomina pruebas
otros para productos de consumo, como las de funcionamiento. Usando modelos de
pruebas beta. crecimiento fiabilidad, ambos objetivos pueden
perseguirse juntos [3] (ver Prueba de vida, la
2.2.1. La prueba de aceptacin / Calificacin evaluacin de fiabilidad en la seccin 4.1,
[1 *, c1s7] [2 *, c8s4] Evaluacin del Programa bajo Test).

2.2.5. Pruebas de regresin

[1 *, c8s11,
Las pruebas de aceptacin / calificacin c13s3]
determina si un sistema cumple con sus criterios
de aceptacin, por lo general mediante la De acuerdo con [7], pruebas de regresin es la
comprobacin de los comportamientos deseados repeticin de pruebas tiva selec- de un sistema
del sistema contra los requerimientos del cliente. o componente para verificar que las
El cliente o representativos fies por lo tanto modificaciones no han causado efectos no
speci- de un cliente o directamente realiza deseados y que el sistema o componente sigue
actividades para comprobar que se han cumplido cumpliendo con sus requisitos especificados.
sus requisitos, o en el caso de un producto de En la prctica, el enfoque es demostrar que las
consumo, que la organizacin ha cumplido con pruebas de software sigue pasando pasado
los requisitos establecidos para el mercado de previamente en un conjunto de pruebas (de
Tar conseguir. Esta actividad pruebas pueden o hecho, tambin se refiere a las pruebas de
no implicar los desarrolladores del sistema. progresin como nonre- veces). Para el
desarrollo incremental, el propsito de las
2.2.2. Prueba de la instalacin pruebas de regresin es mostrar que el
[1 *, c12s2] comportamiento del software no se ha
modificado por los cambios graduales en el
A menudo, despus de la finalizacin del software, excepto en la medida en que debera.
sistema y pruebas de aceptacin, el software se En algunos casos, una solucin de compromiso
verifica despus de la instalacin en el entorno debe hacerse entre la garanta dada por regresin
de destino. las pruebas de instalacin se puede probando cada vez que se realiza un cambio y
ver como las pruebas del sistema llevado a cabo los recursos necesarios para llevar a cabo las
en el entorno operativo de configuraciones de pruebas de regresin, que puede ser bastante
hardware ciones y otras limitaciones tiempo, debido al gran nmero de pruebas que
operacionales. procedimientos de instala- cin pueden ser ejecutados. Las pruebas de regresin
tambin pueden ser verificados. consiste en seleccionar, minimizar y / o dar
prioridad a un subconjunto de los casos de
2.2.3. Alfa y Beta Testing prueba en un conjunto de pruebas exis- tentes
[1 *, c13s7, c16s6] [2 *, c8s4] [8]. Las pruebas de regresin puede ser con-
conductos en cada uno de los niveles de ensayo
descritos en sec- cin 2.1, el objetivo de la
prueba, y pueden aplicarse a las pruebas
funcionales y no funcionales.
 Software de Pruebas
4-11
Antes se libera el software, se da a veces a un 2.2.6. Pruebas de
pequeo y selecto grupo de usuarios potenciales rendimiento [1 *, c8s6]
para el uso de prueba (pruebas alfa) y / o a un
conjunto ms amplio de
usuarios representativos (pruebas beta). Estos Las pruebas de rendimiento verifica que el
usuarios reportan problemas con el producto. software cumple con los requisitos de
Alfa y beta testing a menudo no estn funcionamiento especficos y evala
controlados y no siempre se hace referencia en caractersticas de rendimiento-por ejemplo, la
un plan de pruebas. capacidad y el tiempo de respuesta.
4-12 Gua SWEBOK V3.0

2.2.7. Pruebas de 2.2.12. Prueba de

seguridad [1 *, c8s3] [2 *, c11s4] configuracin [1 *, c8s5]

Las pruebas de seguridad se centra en la En los casos donde el software se construye para
verificacin de que el software est protegido de servir a diferentes usuarios, pruebas de
ataques externos. En particular, las pruebas de configuracin verifica el software bajo
seguridad verifica la confidenciales cialidad, diferentes configuraciones especificadas.
integridad y disponibilidad de los sistemas y sus
datos. Por lo general, las pruebas de seguridad 2.2.13. Usabilidad e inter-Ordenador prueba
incluye la verificacin contra el mal uso y el de la accin
abuso de la cermica o el sistema (pruebas [10 *, c6]
negativas) blandas.

2.2.8. Pruebas de La tarea principal de la usabilidad y las pruebas

estrs [1 *, interaccin persona-ordenador es evaluar lo fcil
c8s8] que es para los usuarios finales para aprender y
utilizar el software. En
Las pruebas de estrs ejerce de software en la en general, puede implicar pruebas del software
carga mxima de diseo, as como ms all de fun- ciones que soporta las tareas del usuario, la
ella, con el objetivo de determinar los lmites de documentacin que ayuda a los usuarios, y la
comportamiento, y para poner a prueba los capacidad del sistema para recuperarse de los
mecanismos de defensa en sistemas crticos. errores del usuario (ver diseo de la interfaz de
usuario en el software de diseo de KA).
2.2.9. Back-to-Back Testing
[7] para simular el uso de las API de aplicaciones de
usuario final. Esto implica la genera- cin de los
IEEE / ISO / IEC Standard 24765 define las parmetros de las llamadas a la API, el ajuste de
pruebas de espalda de Regreso a como prueba las condiciones del entorno externo, y a la
en el que dos o ms variantes de un programa se definicin de los datos interna que afecta a la API.
ejecutan con las mismas entradas, las salidas se
comparan, y los errores se analizan en caso de
discrepancias.

2.2.10. Prueba de recuperacin

[1 *, c14s2]

las pruebas de recuperacin est dirigido a

comprobar la capacidad de reinicio de software
despus de un fallo del sistema o de otro tipo
desastre.

2.2.11. Prueba de interfaz

[2 *, c8s1.3] [9 *, c4s4.5]

defectos de interfaz son comunes en siste- mas

complejas. pruebas de la interfaz tiene como
objetivo verificar si la interfaz componentes
correctamente para proporcionar el intercambio
correcto de datos y control de informa- cin. Por
lo general, los casos de prueba se generan a
partir de la especificacin de interfaz. Un
objetivo especfico de pruebas de la interfaz es
3. Prueba tcnicas Software de Pruebas
4-13

Uno de los objetivos de la prueba es detectar la

mayor cantidad posible de fallos. Muchas
tcnicas se han desarrollado para hacer esto [6,
parte 4]. Estas tcnicas intentan romper un
programa por ser Tematic como sis- como sea
posible en la identificacin de las entradas que
van a producir comportamientos
representativos del programa; por ejemplo,
teniendo en cuenta las subclases del dominio
de entrada, los escenarios, los estados, y los
flujos de datos.
La clasificacin de las tcnicas de prueba pre
SENTED aqu se basa en cmo se generan las
pruebas: desde la intuicin del ingeniero de
software y expe- riencia, las especificaciones,
la estructura del cdigo, las faltas reales o
imaginarios a ser descubiertos, el uso previsto,
modelos, o la naturaleza de la aplicacin. Una
categora se refiere a la utilizacin combinada
de dos o ms tcnicas.
A veces, estas tcnicas se clasifican como de
caja blanca (tambin llamada caja de vidrio), si
las pruebas se basan en la informacin sobre la
forma en que el software ha sido diseado o
codificado, o como negro-casilla si los casos de
prueba se basan nicamente en la entrada /
salida el comportamiento del software. La
siguiente lista incluye las tcnicas de prueba
que se utilizan normalmente, pero algunos
mdicos se basan en algunas de las tcnicas
ms que otros.
4-14 Gua SWEBOK V3.0

3.1. Sobre la base de la intuicin y la

experiencia del ingeniero de software 3.2.2. Las pruebas por parejas
[1 *, c9s3]
3.1.1. Ad hoc
Los casos de prueba se derivan mediante la
Tal vez la tcnica que ms se practica es la combinacin de valores interesantes para cada par
prueba ad-hoc: las pruebas se derivan depender de un conjunto de variables de entrada
de la habilidad del ingeniero de software, la
intuicin y ex- periencia con programas
similares. pruebas Ad hoc puede ser til para
identificar las pruebas casos que no generan
fcilmente por tcnicas ms formales.

3.1.2. Prueba exploratoria

pruebas exploratorias se define como

aprendizaje simultneo, diseo de la prueba, y
ejecucin de la prueba [6, parte 1]; es decir, las
pruebas no se definen por adelantado en un plan
de pruebas establecido, pero estn diseados de
forma dinmica, ejecutados, y modificados. La
eficacia de pruebas exploratorias se basa en el
conocimiento de los ingenieros de software, que
se puede derivar de varias fuentes: el
comportamiento del producto observada durante
la prueba, la familiaridad con la aplicacin, la
plataforma, el proceso falla, el tipo de fallas y
fracasos po- sible, el riesgo asociado con un
producto en particular, y as sucesivamente.

3.2. Las tcnicas basadas en el dominio de

entrada

3.2.1. Particin de equivalencia

[1 *,
c9s4]

particin de equivalencia implica la particin del

dominio de entrada en una coleccin de
subconjuntos (o clases Alent valente) en base a
un criterio especificado o con relacin. Este
criterio o relacin pueden ser diferentes
resultados computacionales, una relacin basada
en el flujo de control o flujo de datos, o una
distincin entre entradas vlidas que son
aceptados y procesados por el sistema y las
entradas no vlidas, tales como fuera de rango
Val- ues, que son no aceptado y debe generar un
mensaje de error o iniciar el procesamiento de
error. Un conjunto representativo de pruebas (a
veces slo uno) es aliado no baja tomada de cada
clase de equivalencia.
 basados Flow Control es la prueba de Software de Pruebas
ruta, cuyo
en lugar de considerar todas las combinaciones 4-15
posibles. pruebas Pairwise pertenece a prueba objetivo es ejecutar todas las trayectorias de
combinatoria, que en general tambin incluye flujo de control de entrada-salida-a en el grfico
combinaciones de ms alto nivel que los pares: de flujo de control de un programa. Dado que las
estas tcnicas se denominan t-sabia, con lo que pruebas de ruta exhaustiva por lo general no es
se considera cada combinacin posible de las factible debido a
variables de entrada t.

3.2.3. Anlisis de valores en la frontera

[1 *, c9s5]

Los casos de prueba son elegidos en o cerca de

los lmites del dominio de las variables de
entrada, con la lgica subyacente que muchos
fallos tienden a concentrarse cerca de los
valores extremos de entradas. Una extensin de
esta tcnica es la prueba de solidez, en el que
los casos de prueba se eligen tambin fuera del
dominio de entrada de variables a robustez
programa de prueba en el procesamiento de
entradas inesperadas o errneos.

3.2.4. Pruebas al azar

[1 *, c9s7]

Las pruebas se generan puramente al azar (que

no debe confundirse con la prueba estadstica
del perfil fun- cional, como se describe en
perfil operativo en la seccin 3.5). Esta forma
de pruebas se encuentra bajo el
encabezamiento de las pruebas de dominio de
entrada ya que el dominio de entrada debe ser
conocido con el fin de ser capaz de recoger
puntos al azar dentro de ella. Las pruebas al
azar proporciona un enfoque relativamente
simple para la automatizacin de pruebas;
recientemente, se han propuesto formas
mejoradas de pruebas al azar en los que pling
la entrada aleatoria sam- est dirigida por otros
criterios de seleccin de entrada [11]. las
pruebas de la pelusa o la formacin de pelusa
es una forma especial de pruebas al azar
dirigida a romper el software; Con mayor
frecuencia se utiliza para las pruebas de
seguridad.

3.3. Tcnicas de cdigo-base

3.3.1. Criterios basados en el flujo de control

[1 *, c4]

criterios de cobertura basadas en el flujo de

control se basa en cubrir todas las
declaraciones, los bloques de instrucciones, o
combinaciones especificadas de declaraciones
en un programa. El ms fuerte de los criterios
4-16 Gua SWEBOK V3.0

bucles, otros criterios menos estrictos se centran 3.4.1. error de

en la cobertura de los caminos que limitan adivinanzas [1 *, c9s8]
iteraciones del bucle, tales como la cobertura de
sentencias, cobertura de sucursales, y con-
DICIN / pruebas de decisin. La adecuacin de En adivinar de error, los casos de prueba estn
estas pruebas se mide en porcentajes; por diseados especficamente por los ingenieros de
ejemplo, cuando todas las ramas se han software que intentan anticipan las fallas ms
ejecutado al menos una vez por los ensayos, se plausibles en un programa dado. Una buena
ha logrado 100% de cobertura de rama. fuente de informacin es la historia de los fallos
detectados en los proyectos anteriores, as como
3.3.2. Criterios basados en el flujo de datos la experiencia del ingeniero de software.
[1 *, c5] 3.4.2. Las pruebas de
mutacin [1 *, c3s5]
En las pruebas basadas en el flujo de datos, el
grfico de flujo de control
est anotado con informacin sobre cmo se Un mutante es una versin ligeramente
definen las variables del programa, utilizados y modificada del programa bajo prueba, que
asesinados (sin definir). El criterio ms fuerte, difiere de ella por un pequeo cambio sintctico.
todos los caminos definicin de uso, requiere Cada caso de prueba ejerce tanto el programa
que, para cada variable, se ejecuta cada original y todos los mutantes generados: si un
segmento de trayectoria de flujo de control de caso de prueba tiene xito en la identificacin de
una definicin de esa variable a un uso de esa la dife- rencia entre el programa y un mutante, se
definicin. Con el fin de reducir el nmero de dice que este ltimo sea concebido
caminos necesarios, se emplean estrategias ms originalmente como una tcnica para evaluar la
dbiles tales como todo-definiciones y todos los prueba muerto. conjuntos (vase la seccin
usos. 4.2. Evaluacin de las pruebas realizadas),
pruebas cin mutatis es tambin un criterio de
3.3.3. Modelos de referencia de las pruebas prueba en s mismo: o bien pruebas se generan
basadas en el Cdigo aleatoriamente hasta que suficientes mutantes
[1 *, c4] han muerto, o pruebas estn diseadas
especficamente para matar mutantes
Aunque no es una tcnica en s misma, la supervivientes. En este ltimo caso, las pruebas
estructura de control de un programa puede ser de mutacin tambin puede ser categorizado
grficamente repre- sentadas usando un grfico como una tcnica basada en el cdigo. La
de flujo para visualizar tcnicas de ensayo suposicin subyacente de pruebas de mutacin,
basadas cdigo-. Un grfico de flujo es un grafo el efecto de acoplamiento, es que mediante la
dirigido, los nodos y arcos de los cuales bsqueda de fallos sintcticos simples, se
corresponderse a elementos (ver grficos y los encontraron defectos ms complejos pero reales.
rboles en los fundamentos matemticos KA) Para que la tcnica sea eficaz, un gran nmero
programar. Por ejemplo, los nodos pueden de mutantes debe ser generado y ejecutado de
representar declaraciones o secuencias forma sistemtica [12] automticamente.
ininterrumpidas de estados, y los arcos pueden
representar la transferencia de control entre los 3.5. Tcnicas de uso-Basado
nodos.
3.5.1. Perfil operativa
[1 *, c15s5]
3.4. Tcnicas basada en la
culpa [1 *, En las pruebas para la evaluacin de la fiabilidad
c1s14] (tambin llamado
pruebas de funcionamiento), el entorno de prueba
repro-
Con diferentes grados de formalizacin, tcnicas prueba especfica- mente destinados a revelar
de ensayo basadas culpa- disear casos de categoras de fallos probables o predefinidas. Para
enfocar mejor la generacin de casos de prueba duce el entorno operativo de Software
la soft- de Pruebas
ware, o el
4-17
o de seleccin, un modelo de fallo puede ser perfil operativo, lo ms estrechamente posible.
introducido que clasifica los diferentes tipos de El objetivo es inferir a partir de los resultados de
faltas. las pruebas observadas el futuro fiabilidad del
software cuando est en uso real. Para ello, las
entradas se asignan probabilidades, o perfiles, en
funcin de su frecuencia de ocurrencia en la
operacin real. perfiles fun- cional se pueden
utilizar durante la prueba del sistema
4-18 Gua SWEBOK V3.0

para guiar derivacin de casos de prueba que (Ms o menos, las salidas). Los casos de prueba
evaluarn la consecucin de los objetivos de se derivan sistemticamente por considerar cada
fiabilidad y ejercer uso relativo y importancia de posible combinacin de condiciones y sus
las distintas funciones similares a lo que se acciones resul- tantes correspondientes. Una
encontr en el entorno operativo [3]. tcnica relacionada es causa-efecto grfica [1 *,
c13s6].

3.5.2. La heurstica de observacin del 3.6.2. Las mquinas de

usuario estados finitos [1 *, c10]
[10 *, C5, C7]

principios de usabilidad pueden proporcionar siguientes.

directrices para los problemas de los
descubrimientos confirma en el diseo de la cara 3.6.1. Las tablas de decisin
del usuario inter [10 *, c1s4] (vase el diseo de
la interfaz de usuario en el software de diseo de
KA). especializadas heursticas, tambin
llamados mtodos de inspeccin facilidad de
uso, se aplican para la observacin sistemtica
del uso del sistema bajo condiciones controladas
con el fin de deter- minar qu tan bien la gente
puede utilizar el sistema y sus interfaces.
heursticas de usabilidad incluyen recorridos
cognitivos, anlisis de reclamaciones,
observaciones de campo, pensando en voz alta, y
los enfoques incluso indirectos, tales como
cuestionarios de usuario y entrevistas.

3.6. Tcnicas de ensayo basado en modelos

Un modelo en este contexto es una

representacin abstracta (formal) del software
bajo prueba, o de sus requisitos de software (ver
Modelado de los modelos de ingeniera de
software y mtodos KA). pruebas basadas en
modelos se utiliza para validar los requisitos,
comprobar su consistencia, y generar casos de
prueba se centraron en los aspectos de
comportamiento del software. Los componentes
clave de las pruebas basadas en modelo son
[13]: la notacin utilizada para representar el
modelo del software o de sus requisitos;
modelos de flujo de obra o modelos similares; la
estrategia de prueba o algoritmo utilizado para la
generacin de caso de prueba; la infraestructura
de apoyo para la ejecucin de la prueba; y la
evaluacin de los resultados de las pruebas en
comparacin con los resultados esperados.
Debido a la complejidad de las tcnicas, los
mtodos de ensayo basados en modelos se
utilizan a menudo en conjuncin con los arneses
cin de prueba automatizacin. tcnicas de
pruebas basadas en modelos incluyen los
Al modelar un programa como una mquina de telecomunicaciones, por lo Software
que dees Pruebas
4-19
estados finitos, las pruebas pueden ser particularmente adecuado para probar protocolos
seleccionados con el fin de cubrir los estados y de comuni- cacin complejos.
transiciones.
3.6.4. Flujo de Trabajo modelos
3.6.3. Las especificaciones formales [2 *, c8s3.2, c19s3.1]
[1 *, c10s11] [2 *,
c15] modelos de flujo de trabajo especifican una
secuencia de activi- lazos realizadas por los
Indicando las especificaciones en un lenguaje seres humanos y / o software aplica- ciones,
formal (ver Mtodos formales en la Engineer- generalmente representados a travs de
Software ing modelos y mtodos KA) permite notaciones grficas. Cada secuencia de acciones
la derivacin automtica de casos de prueba constituye un flujo de trabajo (tambin llamado
funcionales, y, al mismo tiempo, proporciona un escenario). Tanto cal normalmente, un y
un orculo para comprobar los resultados de flujos de trabajo alternativos deben ser probados
pruebas. [6, parte 4]. Un enfoque especial en los papeles
TTCN3 (Pruebas y control de pruebas en una especificacin de flujo de obra est
notacin de la versin 3) es un lenguaje dirigida en las pruebas de procesos de negocio.
desarrollado para escribir casos de prueba. La
notacin fue concebida para las necesidades 3.7. Las tcnicas basadas en la naturaleza
especficas de los sistemas de prueba de de la aplicacin
[1 *, Las tcnicas anteriores se aplican a todo tipo de
c9s6] soft- ware. Tcnicas adicionales para la
derivacin y ejecucin de pruebas se basan en la
Las tablas de decisin representan las relaciones naturaleza de la soft- ware siendo probado; por
lgicas entre las condiciones (aproximadamente, ejemplo,
insumos) y acciones
 Software de Pruebas 4-
11

software orientado a objetos en cada punto de decisin. Para evitar este tipo
software basado en componentes de malentendidos, una clara distincin debe
software basado en web hacerse entre las medidas relacionadas con las
programas concurrentes pruebas que proporcionan una evaluacin del
software basado en el protocolo programa que se est probando, a partir de las
sistemas de tiempo real salidas de prueba observadas y las medidas que
sistemas de seguridad crticos evalan la minuciosidad de la prueba. (Vase la
software orientada a servicios Ingeniera de Software de medicin en la
software de cdigo abierto Gestin KA Ingeniera de Software para obtener
software embebido informacin sobre los programas de medicin.
Ver Proceso de Software y Medicin del
3.8. La seleccin y la combinacin de tcnicas producto en el Proceso de Ingeniera de
Software KA para obtener informacin sobre las
3.8.1. La combinacin funcional y estructural medidas).
[1 *, c9] La medicin se considera generalmente como
funda- mental para el anlisis de calidad. La
Basado en modelos y tcnicas de ensayo basadas medicin tambin se puede utilizar para
en cdigo son a menudo contrastan tan funcional optimizar la planificacin y ejecucin de las
frente a las pruebas estructurales. Estos dos pruebas. Gestin de pruebas puede utilizar varias
enfoques para la seleccin de la prueba no deben medidas de diferencias ent proceso para
ser vistos como alternativas sino como monitorear el progreso. (Vase la seccin 5.1,
complementos; de hecho, se utilizan diferentes las consideraciones prcticas, para una dis-
fuentes de informacin y se ha demostrado que cusin de las medidas del proceso de pruebas
diferentes tipos de alta luz de los problemas. tiles para fines de gestin).
Pueden ser utilizados en combinacin,
dependiendo de consideraciones presupuestarias. 4.1. Evaluacin de la prueba el marco del
Programa

4.1.1. Las mediciones de programas que

ayudan en la planificacin y Anlisis
Diseando
[9 *, c11]
3.8.2. Determinista vs aleatoria
[1 *, Medidas basado en el tamao del software (por
c9s6] ejemplo, lneas de cdigo fuente o tamao
funcional; ver Measure
Los casos de prueba pueden seleccionarse de prueba [6, Parte 4]. Por ejemplo, la cobertura de la
una manera determinista, de acuerdo con una de rama es una tcnica de prueba popular. El logro
muchas tcnicas, o aleatoriamente extradas de de una cobertura rama medida especificada (por
alguna distribucin de insumos, tal como se ejemplo, 95% de cobertura de sucursales) no debe
suele hacer en las pruebas de fiabilidad. ser el objetivo de las pruebas per se: es una forma
comparaciones analticas y empricas erales SeV de improv- ing las posibilidades de encontrar
han llevado a cabo para analizar las condiciones fallos por intentar ejercer sistemticamente todas
que hacen que un enfoque ms eficaz que el las ramas del programa
otro.

4. Las medidas de prueba relacionados

A veces, las tcnicas de prueba son confundidos

con los objetivos de las pruebas. Tcnicas de
ensayo pueden ser vistos como auxiliares que
ayudan a asegurar el logro de objetivos de la
4-12 Gua SWEBOK
Requisitos V3.0en
Suring los requisitos de software
KA) o en la estructura del programa se pueden
usar para guiar las pruebas. Las medidas
estructurales incluyen tambin medidas que
determinan la frecuencia con la que llaman
mdulos entre s.

4.1.2. FALLO Tipos, clasificacin y

estadsticas
[9 *, c4]

La literatura es rica en pruebas de

clasificaciones y taxonomas de faltas. Para
hacer la prueba tivo ms effec-, es importante
saber qu tipos de fallos se pueden encontrar
en el software bajo prueba y la frecuencia
relativa con la que se han producido estos
fallos en el pasado. Esta informacin puede ser
uso-ful para hacer predicciones de calidad, as
como en la mejora de procesos (vase cin de
defectos caracterizacin de la calidad del
software KA).
 Software de Pruebas 4-
13

4.1.3. Densidad de 4.2.2. Siembra de

fallos [1 *, c13s4] [9 *, c4] fallos [1 *, c2s5] [9 *,
c6]

Un programa bajo prueba se puede evaluar por flujo del programa o el porcentaje de requisitos
recuento fallos descubiertos como la relacin funcionales ejercidas entre los enumerados en el
entre el nmero de fallos encontrados y el documento de especificaciones. criterios de
tamao del programa. adecuacin basados en cdigos requieren
instrumentacin apropiada del programa que se
4.1.4. Prueba de vida, Evaluacin Fiabilidad est probando.
[1 *, c15] [9 *, c3]

Una estimacin estadstica de la fiabilidad del

software, que puede ser obtenido mediante la
observacin de fiabilidad alcanzado, se puede
utilizar para evaluar un producto de software y
decidir si o no la prueba puede ser detenido (ver
seccin 2.2, Logro Fiabilidad y evaluacin).

4.1.5. Los modelos de crecimiento fiabilidad

[1 *, c15] [9 *, c8]

modelos de crecimiento Fiabilidad proporcionan

una prediccin de fiabilidad basado en fracasos.
Suponen, en gene- ral, que cuando las fallas que
causaron las fallas observadas se han fijado
(aunque algunos modelos tambin aceptan
correcciones imperfectas), exposiciones de
fiabilidad del pro- ducto estimado, en promedio,
una tendencia creciente. Hay muchos modelos
de crecimiento fiabilidad publicados. En
particular, estos modelos se dividen en el fracaso
de conteo y los modelos de tiempo medio entre
fallos.

4.2. La evaluacin de las pruebas realizadas

4.2.1. Medidas de cobertura / Minuciosidad

[9 *, c11]

Varios criterios de adecuacin de prueba

requieren que los casos de prueba ejercen
sistemticamente un conjunto de elementos
identificados en el programa o en las
especificaciones (vase el tema 3, Tcnicas de
Prueba). Para evaluar la rigurosidad de las
pruebas ejecutadas, nieros de software niera
pueden monitorear los elementos cubiertos de
manera que puedan medir dinmicamente la
relacin entre los elementos cubiertos y el
nmero total. Por ejem plos, es posible medir el
porcentaje de ramas cubiertas en el grfico de
4-14 Gua SWEBOK V3.0 medi- das deben integrarse en un definido y
En la siembra de fallos, algunos fallos se intro-
ducido artificialmente en un programa antes de
la prueba. Cuando se ejecutan las pruebas,
algunos de estos fallos cabezas de serie se dar
a conocer, as como, posiblemente, algunos
defectos que ya estaban all. En teora,
dependiendo de cules y cuntos de los
defectos artificiales se presen- ten, Ensayos
sobre la eficacia puede ser evaluado y el
nmero restante de fallos genuinos puede ser
acoplado estimacin. En la prctica, los
estadsticos cuestionan la distribu- cin y la
representatividad de los fallos sembradas en
relacin con los fallos genuinos y el tamao
pequeo de la muestra sobre la que se basan las
extrapolaciones. Algunos tambin argumentan
que esta tcnica se debe utilizar con mucho
cuidado ya que la insercin de fallos en el
software implica el riesgo evidente de dejarlos
all.

4.2.3. Puntuacin mutacin

[1 *,
c3s5]

En las pruebas de mutacin (ver pruebas de

mutacin en sec- cin 3.4, Tcnicas basada en
la culpa), la proporcin de mutantes muertos al
nmero total de mutantes generados puede ser
una medida de la eficacia del equipo de prueba
ejecutado.

4.2.4. La comparacin y la eficacia relativa

de las diferentes tcnicas

Se han realizado varios estudios para com-

parar la eficacia relativa de las diferentes
tcnicas de prueba. Es importante ser preciso
en cuanto a la propiedad contra la cual se estn
evaluando las tcnicas; lo que, por ejemplo, es
el significado exacto dado al trmino
eficacia? Posibles interpretaciones incluyen
el nmero de pruebas necesarias para encontrar
el primer fracaso, la proporcin entre el
nmero de fallos que se encuentran a travs de
pruebas de todos los defectos encontrados
durante y despus de la prueba, y la cantidad
de fiabili- dad se ha mejorado. comparaciones
analticas y empricas entre diferentes tcnicas
se han llevado a cabo de acuerdo con cada una
de las nociones de eficacia especificados
anteriormente.

5. Prueba Proceso

conceptos de pruebas, estrategias, tcnicas, y

 Software de Pruebas 4-
15

proceso controlado. El proceso de prueba es el elemento de prueba. la documentacin de

compatible con las actividades de ensayo y prueba debe hay que producir y actualizada
proporciona orientacin a los probadores y continuamente para el mismo nivel de calidad
equipos de prueba, desde la planificacin de que los dems tipos de documentacin en la
prueba para probar la evaluacin de salida, de tal ingeniera de software. documentacin de prueba
manera como para ofrecer garantas de que los tambin debe estar bajo el control de la gestin
objetivos de la prueba se cumplirn de manera de con- figuracin de software (ver el KA
tivo costo-effec-. Software Configuration Management). Por otra
parte, la documentacin de prueba incluye
5.1. Consideraciones prcticas productos de trabajo que pueden proporcionar
material para manuales de usuario y la
5.1.1. Actitudes / programacin sin ego formacin de usuarios.
[1 * c16] [9 *, c15]
5.1.5. Desarrollo basado en pruebas
La documentacin es una parte integral de la cin
Un elemento importante de la prueba con xito formalizacin del proceso de prueba [6, parte 3].
es una actitud de colaboracin hacia las documentos de prueba pueden incluir, entre otros,
actividades de prueba y garanta de calidad. Los el plan de pruebas, especificacin de diseo de la
gerentes tienen un papel clave en la promocin prueba, procedimiento de ensayo, la
de una recepcin favorable en general hacia el especificacin de casos de prueba, registro de la
descubrimiento fracaso y la correccin durante prueba, y el informe de incidente prueba. El
el desarrollo y mantenimiento de software; por software bajo prueba se documenta como
ejemplo, mediante la superacin de la
mentalidad de cdigo individual ERSHIP de
propia entre los programadores y la promocin
de un entorno de colaboracin con el equipo de
responsa- bilidad de anomalas en el cdigo.

5.1.2. Prueba guas

[1 *, c12s1] [9 *, c15s1]

Las fases de prueba pueden ser guiados por

varios objetivos, por ejemplo, las pruebas
basadas en riesgo utiliza los riesgos de los
productos de priorizar y centrarse EGY la
prueba estra-, y pruebas basadas en escenario
define casos de prueba basado en escenarios de
software especificados.

5.1.3. Prueba Gestin de proceso

[1 *, c12] [9 *, c15]

actividades de prueba llevados a cabo en

diferentes niveles (ver tema 2, los niveles de
prueba) debe ser organizada en conjunto con las
personas, herramientas, polticas y medidas en
un proceso bien definido que es una parte
integral del ciclo de vida.

5.1.4. Prueba Documentacin y los productos

[1 *, c8s12] [9 *, c4s5]
4-16 Gua SWEBOK V3.0 [1 *, c1s16]

Basado en pruebas de desarrollo (TDD) se

origin como una de las prcticas ncleo XP
(programacin extrema) y consiste en escribir
las pruebas unitarias antes de escribir el cdigo
para ensayar (ver Mtodos giles en los
modelos de ingeniera de software y mtodos
KA). De esta manera, TDD desarrolla los casos
de prueba como rogate sur- para un documento
de especificacin de requisitos de software en
lugar de como una verificacin independiente
de que el software ha implementado
correctamente los requisitos. En lugar de una
estrategia de ensayo, TDD es una prctica que
requiere que los desarrolladores de software
para definir y mantener las pruebas de unidad;
Por lo tanto, tambin puede tener un impacto
positivo en la elaboracin de las necesidades
del usuario y especificacin de requisitos de
software.

5.1.6. Interna frente del equipo de pruebas

independientes
[1 *, c16]

La formalizacin el proceso de prueba tambin

puede implicar la formalizacin de la
organizacin del equipo de pruebas. El equipo
de pruebas puede estar compuesto por
miembros internos (es decir, en el equipo del
proyecto, se trate o no en la construccin de
software), de los miembros externos (con la
esperanza de traer una perspectiva imparcial,
independiente), o de ambos miem- interna y
externa bras. Las consideraciones de costos,
plazos, niveles de madurez de las
organizaciones involucradas, y criticidad de la
aplicacin pueden guiar la decisin.

5.1.7. Costo / Esfuerzo de estimacin y

prueba mide Proceso
[1 *, c18s3] [9 *, c5s7]

Una serie de medidas relacionadas con los

recursos gastados en las pruebas, as como a la
relativa eficacia de bsqueda de errores de las
diversas fases de prueba, son utilizados por los
administradores para controlar y mejorar la
prueba
 Software de Pruebas 4-
17

proceso. Estas medidas de prueba pueden cubrir 5.2. Prueba Ocupaciones

aspectos tales como el nmero de casos de
prueba especificados, el nmero de casos de Como se muestra en la siguiente descripcin,
prueba ejecutados, el nmero de casos de prueba manejo exitoso de las actividades de prueba
pas, y el nmero de casos de prueba fall, entre depende en gran medida Cess la gestin de
otros. configuracin de software pro (vase el software
Evaluacin de los informes de las pruebas de de configuracin Manage- ment KA).
fase puede ser combinarse con el anlisis de las
causas para evaluar la efectividad del proceso de 5.2.1. Planificacin
Exmenes en la bsqueda de fallos tan pronto [1 *, c12s1,
como sea posible. Tal evaluacin puede estar c12s8]
asociada con el anlisis de riesgos. Por otra
parte, los recursos que merece la pena el gasto Al igual que todos los otros aspectos de la
en las pruebas deben ser com- realiz medicin gestin de proyectos, se deben planificar las
con el uso / criticidad de la apli- cacin: actividades de prueba. Los aspectos clave de la
diferentes tcnicas tienen diferentes costos y el planificacin de controles incluyen la
rendimiento de los diferentes niveles de coordinacin de la persona-nel, la disponibilidad
confianza en la fiabilidad del producto. de instalaciones de prueba y equipos, creacin y
mantenimiento de todos los docu- mentacin
5.1.8. Terminacin relacionada prueba, y la planificacin de
[9 *, posibles resultados no deseable. Si se mantiene
c10s4] ms de una lnea de base del software, a
continuacin, un plan- importante consideracin
Una decisin debe ser tomada en cuanto a es la que define el tiempo y el esfuerzo
cunto ing Test- es suficiente y cuando una necesarios para garantizar que el entorno de
etapa de prueba puede ser terminologa NAT. prueba se establece en la configuracin
Minuciosidad medidas, tales como la cobertura adecuada.
de cdigo alcanzado o cobertura funcional, as
como estimaciones de la densidad de culpa o de 5.2.2. Caso de prueba Generacion
su confiabilidad operativa, proporcionan un [1 *, c12s1,
apoyo til, pero no son sufi- ciente en s mismos. c12s3]
La decisin tambin implica consideraciones
sobre los costes y los riesgos que corren los Generacin de casos de prueba se basa en el
posibles fallos restantes, a diferencia de los nivel de pruebas a realizar y las tcnicas de
costos incurridos al continuar la prueba (ver ensayo particulares. Los casos de prueba deben
Criterios de seleccin Prueba / Criterios de estar bajo el con- trol de gestin de
prueba de adecuacin en la seccin 1.2, Temas configuracin de software e incluir los
clave). resultados esperados para cada prueba.

5.1.9. Prueba de Reutilizacin y 5.2.3. Prueba Entorno de desarrollo

Patrones de prueba [9 *, [1 *, c12s6]
c2s5]

Para llevar a cabo pruebas o mantenimiento de probar algunos tipos de aplicaciones, en

una forma nizado y rentable or-, los medios determinadas circunstancias, con las motivaciones
utilizados para probar cada parte del software detrs de las decisiones tomadas, forman un
deben ser reutilizados de forma sistemtica. Un patrn de prueba que puede en s mismo ser
repositorio de materiales de prueba debe estar documentados para su posterior reutilizacin en
bajo el control del software de gestin de con- proyectos similares.
figuracin de modo que los cambios en los
requisitos de software de diseo o se pueden
reflejar en cambios en las pruebas realizadas.
Las soluciones de ensayo adoptadas para
4-18 Gua SWEBOK V3.0
El entorno utilizado para la prueba debe ser
com- patible con herramientas niera otro
software adoptada niera. Se debe facilitar el
desarrollo y control de casos de prueba, as
como el registro y la recuperacin de los
resultados esperados, guiones y otros
materiales de prueba.

5.2.4. Ejecucin
[1 *,
c12s7]

La ejecucin de los ensayos deber incorporar

un prin- cipio bsico de la experimentacin
cientfica: todo lo realizado durante la prueba
debe ser realizado y documentado con claridad
suficiente como para que otra persona
 Software de Pruebas 4-
19

podran replicar los resultados. Por lo tanto, las El software. informacin de seguimiento de
pruebas deben realizarse de acuerdo con los defectos se utiliza para determinar qu aspectos
procedimientos documentados usando una de las pruebas de software y otros procesos
versin claramente definida del software bajo necesitan mejora y la eficacia de los enfoques
prueba. anteriores han sido.

5.2.5. Prueba Evaluacin de 6. Herramientas de prueba de software

resultados [9 *,
c15] 6.1. Herramienta de Pruebas Apoyo
Los resultados de las pruebas deben ser [1 *, c12s11] [9 *, c5]
evaluados para determinar si la prueba ha tenido
xito. En la mayora de los casos, xito Las pruebas requiere muchas tareas intensivas en
significa que el software lleva a cabo como se mano de obra, de funcionamiento ejecuciones
esperaba y no tena ningn principales numerosos programas Ning, y el manejo de una
resultados inesperados. No todos los resultados gran cantidad de informacin. herramientas
inesperados son necesariamente defectos, pero adecuadas pueden aliviar la carga de opera-
en algn momento se determinan a ser ciones de oficina, tediosas y hacerlos menos
simplemente ruido. Antes de que una falla puede propensos a errores. Sofisticacin herramientas
ser eliminado, es necesario un esfuerzo de CATed pueden apoyar el diseo de pruebas y
anlisis y depuracin de aislar, identificar y generacin de casos de prueba, por lo que es ms
describir. Cuando los resultados son eficaz.
particularmente importantes, una junta de
revisin formal puede ser con- Vened para 6.1.1. Seleccin de Herramientas
evaluarlas. [1 *, c12s11]

5.2.6. Informe de problemas / Orientacin a los directores y los probadores

Registro de Pruebas [1 *, c13s9] sobre cmo seleccionar las herramientas de
prueba que sern ms tiles a su nizacin y
procesos or- es un tema muy importante,
Las actividades de prueba se pueden introducir Los defectos pueden ser rastreados y analizados
en un registro de pruebas para identificar cundo para determinar cuando se introdujeron en el
se llev a cabo una prueba, que se realiza el software, por qu fueron creados (por ejemplo,
examen, lo que la configuracin del software se requisitos de mal definidos, cin incorrecta
utiliz, y otra identificacin correspondiente variable de declara-, prdida de memoria, error de
infor- macin. resultados de prueba inesperados sintaxis de programacin), y cuando podan haber
o incorrectos pueden ser grabados en un sistema sido observado por primera vez en
de notificacin de problema, los datos para el
cual constituye la base para ms tarde debug-
ging y la fijacin de los problemas que se
observaron como fallas durante la prueba.
Adems, las anomalas no clasificados como
fallos podran ser documentados en caso de que
ms tarde resultan ser ms grave de lo previsto
inicialmente. Los informes de ensayo son
tambin entradas al proceso de solicitud de la
gestin del cambio (vase Control de
Configuracin de Software en el KA Software
Configuration Management).

5.2.7. seguimiento de defectos

[9 *, c9]
4-20 Gua
comoSWEBOK V3.0
herramienta de seleccin afecta en gran
medida la eficiencia y la eficacia de la prueba.
Seleccin de herramienta depende de la
evidencia diversa, tales como las opciones de
desarrollo, los objetivos de evaluacin,
instalaciones de ejecucin, y as
sucesivamente. En general, puede no ser una
herramienta nica que va a satisfacer
necesidades particulares, por lo que un
conjunto de herramientas podra ser una opcin
apropiada.

6.2. Categoras de Herramientas

Clasificamos las herramientas disponibles de

acuerdo a
su funcionalidad:

arneses de prueba (conductores, trozos) [1

*, c3s9] proporcionan un entorno
controlado en el que las pruebas pueden
ser lanzados y las salidas de prueba se
pueden registrar. Con el fin de ejecutar
partes de un pro- grama, se proporcionan
los conductores y los talones para simular
llamadas tarde y llamados mdulos,
respectivamente.
generadores de prueba [1 *, c12s11]
proporcionar tancia asis- en los casos de
prueba generacin. La gene- racin puede
ser al azar, basado en va modelo- basa, o
una mezcla de los mismos.
herramientas de captura / reproduccin [1
*, c12s11] auto-
volver a ejecutarlo ticamente, o de
repeticin, previamente
 Software de Pruebas 4-
21

pruebas ejecutadas que han grabado las trazadores [1 *, c1s7] registrar la historia de
entradas y salidas (por ejemplo, pantallas). una
comparadores de Oracle / archivo / rutas de ejecucin del programa.
herramientas de comprobacin de asercin herramientas de pruebas de regresin [1 *,
[1 *, c9s7] ayudar a decidir si un resultado c12s16] apoyar la ejecucin adicional de un
de la prueba es exitosa o no. conjunto de pruebas despus de una seccin
analizadores de cobertura y instrumenters del software ha sido modificado. Tambin
[1 *, c4] trabajar juntos. analizadores de pueden ayudar a seleccionar un subconjunto
cobertura evaluar qu y cmo se han de pruebas de acuerdo con el cambio
ejercido muchas entidades de la grfica de realizado.
flujo del programa entre todos los herramientas de evaluacin de la fiabilidad
requeridos por el criterio de cobertura de [9 *, c8] resultados de prueba apoyo anlisis
prueba seleccionada. El anlisis se puede y cin visualiza- grfica a fin de evaluar
hacer gracias a instrumenters que insertan medi- das relacionadas fiabilidad-de
sondas de grabacin en el cdigo del acuerdo con los modelos seleccionados.
programa.
4-22 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

naik y Tripathy 2008 [1

2011 [2 *]

1993 [10
Nielsen
Kan 2003
SommervilLe

[9 *]
*]

nortea

*]
1. Fundamentos de Software
Testing
1.1. Terminologa de pruebas
relacionados
1.1.1. Definiciones de Pruebas y
c1, c2 c8
Terminologa relacionada
1.1.2. Las fallas fallas vs. c1s5 c11
1.2. Cuestiones clave
1.2.1. Criterios de seleccin de
c1s14, c6s6,
prueba/ Criterios de prueba
c12s7
de adecuacin (Reglas de
parada)
1.2.2. Prueba de Eficacia /
c13s11, c11s4
Objetivos para las pruebas
1.2.3. Las pruebas de defectos
c1s14
Identificacin
c1s9,
1.2.4. El problema de Oracle
c9s7
1.2.5. Terico y prctico
c2s7
Limitaciones de las Pruebas
1.2.6. El problema de la Inviable
c4s7
Caminos
1.2.7. la capacidad de prueba c17s2
1.3. Relacin de las pruebas de
Otras actividades
1.3.1. Prueba de Software vs.
estticoTcnicas de gestin de c12
la calidad
1.3.2. La correccin de pruebas
c17s2
vs.
Pruebas y verificacin
1.3.3. Prueba formalvs.
de depuracin c3s6
1.3.4. Las pruebas contra c3s2
2. Niveles de pruebaProgramacin
2.1. El objetivo de la prueba c1s13 c8s1
2.1.1. Examen de la unidad c3 c8
2.1.2. Pruebas de integracin c7 c8
2.1.3. Prueba del sistema c8 c8
 Software de Pruebas 4-
23

naik y Tripathy 2008 [1

2011 [2 *]

1993 [10
Nielsen
Kan 2003
SommervilLe

[9 *]
*]

nortea

*]
2.2. Objetivos de las Pruebas c1s7
2.2.1. Aceptacin / Calificacin c1s7 c8s4
2.2.2. Prueba de la instalacin c12s2
c13s7,
2.2.3. Alfa y Beta Testing c8s4
c16s6
2.2.4. Logro fiabilidady
c15 c15s2
Evaluacin
c8s11,
2.2.5. Pruebas de regresin
c13s3
2.2.6. Pruebas de rendimiento c8s6
2.2.7. Pruebas de seguridad c8s3 c11s4
2.2.8. Pruebas de estrs c8s8
2.2.9. Back-to-Back Testing
2.2.10. Prueba de recuperacin c14s2
2.2.11. Prueba de interfaz c8s1.3 c4s4.5
2.2.12. Prueba de configuracin c8s5
2.2.13. usabilidady Pruebas
c6
Human Computer
Interaction
3. Tcnicas de Prueba
3.1. Basadoen la intuicin y la
experiencia del ingeniero de
software
3.1.1. Ad hoc
3.1.2. Prueba exploratoria
3.2. Basado en el dominio de
entrada
tcnicas
3.2.1. Particin de equivalencia c9s4
3.2.2. Las pruebas por parejas c9s3
3.2.3. Anlisis de valores en la c9s5
3.2.4. Pruebas al azar frontera c9s7
3.3. Tcnicas de cdigo-base
3.3.1. -Base de flujo de control
c4
criterios
4-24 Gua SWEBOK V3.0

naik y Tripathy 2008 [1

2011 [2 *]

1993 [10
Nielsen
Kan 2003
SommervilLe

[9 *]
*]

nortea

*]
3.3.2. Criterios basados en el c5
flujo
3.3.3. de datos de referencia
Modelos
c4
de las pruebas basadas en el
Cdigo
3.4. Tcnicas basada en la culpa c1s14
3.4.1. error de adivinanzas c9s8
3.4.2. Las pruebas de mutacin c3s5
3.5. Tcnicas de uso-Basado
3.5.1. Perfil operativa c15s5
3.5.2. La heurstica de
C5, C7
observacin del usuario
3.6. Las pruebas basado en
modelos
tcnicas
3.6.1. Tabla de decisin c9s6
3.6.2. Las mquinas de estados c10
finitos
3.6.3. Pruebas de formal
c10s11 c15
Presupuesto
3.7. Las tcnicas basadasen la
naturaleza de la aplicacin
3.8. Selecciny la
combinacin de tcnicas
3.8.1. Funcional y estructural C9
3.8.2. Determinista vs aleatoria c9s6
4. Las medidas de prueba
relacionados
4.1. Evaluacin del Programa
Bajo prueba
4.1.1. Las mediciones de
programas que ayudan en la c11
planificacin y ensayo de
Proyectos
4.1.2. Tipos de fallos, clasificacin,
c4
y Estadsticas
4.1.3. Densidad de fallos c13s4 c4
4.1.4. Prueba de vida, Fiabilidad
c15 c3
Evaluacin
4.1.5. Los modelos de crecimiento c15 c8
fiabilidad
 Software de Pruebas 4-
25

naik y Tripathy 2008 [1

2011 [2 *]

1993 [10
Nielsen
Kan 2003
SommervilLe

[9 *]
*]

nortea

*]
4.2. Evaluacin deLas pruebas
realizadas
4.2.1. Cobertura / Minuciosidad
c11
medidas
4.2.2. Siembra de fallos c2s5 c6
4.2.3. Puntuacin mutacin c3s5
4.2.4. Comparaciny la
eficacia relativa de las
diferentes tcnicas
Proceso 5. Prueba
5.1. Consideraciones prcticas
5.1.1. actitudes/
c16 c15
Programacin sin ego
5.1.2. Guas de prueba c12s1 c15s1
5.1.3. Gestin de procesos de c12 c15
5.1.4. Documentacin de laprueba
c8s12 c4s5
comprobaciny productos de
5.1.5.trabajo
Desarrollo basado en pruebas c1s16
5.1.6. Independiente vs interna
c16
Equipo de prueba
5.1.7. Costo / estimacin de esfuerzoy
c18s3 c5s7
Otras medidas del proceso
5.1.8. Terminacin c10s4
5.1.9. Prueba de Reutilizacin y c2s5
Patrones
5.2. Las actividades de prueba
c12s1
5.2.1. Planificacin
c12s8
c12s1
5.2.2. Generacin de casos de
c12s3
prueba
5.2.3. Desarrollo
c12s6
Entorno de prueba
5.2.4. Ejecucin c12s7
5.2.5. Resultados de la prueba c15
Evaluacin
4-26 Gua SWEBOK V3.0

naik y Tripathy 2008 [1

2011 [2 *]

1993 [10
Nielsen
Kan 2003
SommervilLe

[9 *]
*]

nortea

*]
5.2.6. Informe de problemas /
c13s9
Prueba
Iniciar sesin
5.2.7. seguimiento de defectos C9
6. Herramientas de
prueba de software
6.1. Herramienta de c12s11 c5
soporte de pruebas
6.1.1. Seleccin de c12s11
Herramientas c1s7, c3s9,
c4, c9s7,
6.2. Categoras de Herramientas c8
c12s11,
c12s16
 Software de Pruebas 4-
27

Referencias
[1 *] S. Naik y P. Tripathy, pruebas de [8] S. Yoo y M. Harman, pruebas de regresin
software y aseguramiento de la calidad: Minimizacin, seleccin y priorizacin: una
Teora y Prctica, Wiley-Spektrum, 2008. encuesta, Pruebas de verificacin de
software y Fiabilidad, vol. 22, no. 2, marzo
[2 *] I. Sommerville, Ingeniera de Software, 9 de 2012,
ed., Addison-Wesley, 2011. pp. 67-120.

[3] MR Lyu, ed., Manual de Ingeniera de [9 *] SH Kan, mtricas y modelos en Ingeniera

Software Fiabilidad, McGraw-Hill y IEEE de Software de Calidad, 2 ed., Addison-
Computer Society Press, 1996. Wesley, 2002.

[4] H. Zhu, PAV Hall y JHR mayo, Unidad de [10 *] J. Nielsen, Ingeniera de usabilidad,
Software Cobertura de la prueba y Morgan Kaufmann, 1993.
suficiencia, ACM Computing Surveys,
vol. 29, no. 4, diciembre de 1997 pp. 366- [11] TY Chen et al., Adaptive Testing aleatoria:
427. el arte de caso de prueba Diversidad,
Diario de sistemas y software, vol. 83, no.
[5] EW Dijkstra, Notas sobre la programacin 1, enero de 2010, pp. 60-66.
estructurada, Informe TH-70-WSE-03,
Universidad Tecnolgica de Eindhoven, [12] Y. Jia y M. Harman, An Analysis
1970; y la Encuesta de Desarrollo de pruebas de
http://www.cs.utexas.edu/users/EWD/ mutacin , IEEE Trans. Ingeniera de
ewd02xx / EWD249.PDF. Software, vol. 37, no. 5, Sep.-Oct. 2011,
pp. 649-678.
[6] ISO / IEC / IEEE P29119-1 / DIS Proyecto
de Norma para Sistemas de Software y [13] M. y B. Utting Legeard, prctico basado
Testing Ingeniera--Parte 1 Software: en modelos de prueba: Un Enfoque
Conceptos y definiciones, ISO / IEC / IEEE Herramientas, Morgan Kaufmann, 2007.
2012.

[7] ISO / IEC / IEEE 24765: 2010 Sistemas y

de Ingeniera de Software-Vocabulario,
ISO / IEC / IEEE 2010.
 CAPTULO 5

MANTENIMIENTO DE

SOFTWARE

paradigma de cdigo abierto ha trado ms aten-

SIGLAS cin a la cuestin del mantenimiento de artefactos
de software desarrollados por otros.
SEO Solicitud de modificacin
En esta gua, el mantenimiento del software se
R
PR Informe de problemas define como el conjunto de actividades necesarias
Gestin de la Configuracin de para proporcionar soporte rentable de software.
SMC Las actividades se llevan a cabo durante la etapa
Software
de pre-entrega, as como
SLA Acuerdo de nivel de servicio
SQA Calidad de Software
V&V Verificacin y validacin

INTRODUCCIN

los esfuerzos de desarrollo de software como

resultado la ery deliv- de un producto de
software que satisfaga las necesidades del
usuario. En consecuencia, el producto de
software debe cambiar o evolucionar. Una vez
en funcionamiento, los defectos se descubren,
cambian entornos operativos, y los nuevos
requisitos de los usuarios superficie. La fase de
mantenimiento del ciclo de vida comienza
despus de un perodo de garanta o soporte
posterior a la implementacin del parto, pero las
actividades de mantenimiento producirse mucho
antes.
El mantenimiento de software es una parte
integral de un ciclo de vida del software. Sin
embargo, no ha recibido el mismo grado de
atencin que las otras fases tienen.
Histricamente, el desarrollo de software ha
tenido un perfil mucho ms alto que el
mantenimiento del software en la mayora de las
organizaciones. Esto est cambiando, ya que las
empresas se esfuerzan para exprimir el mximo
rendimiento de su inversin en el desarrollo de
software por el software que opera ING
mantener- el mayor tiempo posible. El
 Software
Esta primera seccin presenta de Pruebas 4-
los conceptos y
durante la etapa de posparto. actividades antes 29
terminologa que forman una base subyacente a
de la entrega incluyen la planificacin para las la comprensin de la funcin y el alcance del
operaciones de posparto, el mantenimiento, y mantenimiento del software. Los temas
la determinacin de la logstica para las proporcionan definiciones y hacer hincapi en
actividades de transicin [1 *, c6s9]. posparto por qu hay una necesidad de mantenimiento.
actividades incluyen la modificacin de Categoras de mantenimiento de software son
software, capacitacin y operativo o interfaz fundamentales para la comprensin de su
con una mesa de ayuda. significado subyacente.
El rea de conocimiento de mantenimiento
de software (KA) se relaciona con todos los 1.1. Definiciones y terminologa
dems aspectos de la ingeniera de software. [1 *, c3] [2 *, c1s2,
Por lo tanto, esta descripcin KA est C2S2]
vinculado a todos los dems de ingeniera de
software KAs de la Gua. El propsito del mantenimiento del software se
define en el estndar internacional para el
DISTRIBUCIN DE TEMAS PARA mantenimiento de software:. ISO / IEC / IEEE
MANTENIMIENTO DE SOFTWARE 14764 [1 *] 1 En el contexto de la ingeniera de
software, mantenimiento de software es
El desglose de temas para el manteni- Software esencialmente uno de los muchos procesos
Principal- KA se muestra en la Figura 5.1. tcnicos.

1. Fundamentos de mantenimiento de 1 A los efectos de la concisin y la facilidad de

software lectura ing, esta norma se refiere simplemente como
IEEE 14764 en el texto subsiguiente de esta KA.

5-1
5-2 Gua SWEBOK V3.0

Figura 5.1. Desglose de temas para el mantenimiento del software KA

El objetivo del mantenimiento del software es de los cambios propuestos, cdigo de software y
modificar el software existente, preservando su otros artefactos son
integridad. La norma internacional tambin
seala la importancia de tener algunas
actividades de mantenimiento antes de la entrega
final de software (actividades previas a la
entrega). En particular, IEEE 14764 hace
hincapi en la importancia de los aspectos de
mantenimiento previo a la entrega de
planificacin, por ejemplo.

1.2. Naturaleza de Mantenimiento

[2 *,
c1s3]

mantenimiento de software sostiene UCT el

software PRODUCIRSE lo largo de su ciclo de
vida (desde el desarrollo de las operaciones).
Las solicitudes de modificacin se registran y se
realiza un seguimiento, se determina el impacto
 Mantenimiento de Software
modificada, la prueba se lleva a cabo, y una 5-3
nueva versin del producto de software es
liberado. Adems, forma- cin y apoyo diario
se proporcionan a los usuarios. El trmino
mantenedor se define como una organizacin
que lleva a cabo actividades de mantenimiento.
En este KA, el trmino se referir en ocasiones
a las personas que per- formar esas actividades,
lo que contrasta con los desarrolladores.
IEEE 14764 identifica las principales
actividades de mantenimiento de software como
la implementacin de procesos, anlisis de
problemas y la modificacin, la implementacin
de modificacin, revisin de mantenimiento /
aceptacin, la migracin, y la jubilacin. Estas
actividades se describen en la seccin 3.2, las
actividades de mantenimiento. Mantenedores
pueden aprender a partir del conocimiento del
software de la ERS desarrollos. El contacto con
los desarrolladores y la participacin temprana
de la
5-4 Gua SWEBOK V3.0

mantenedor ayuda a reducir el esfuerzo de

mantenimiento general. En algunos casos, el 1.4. La mayora de los costos de mantenimiento
desarrollador inicial no puede ser alcanzado o ha [2 *, c4s3, c5s5.2]
pasado a otras tareas, lo que crea un desafo
adicional para man- recipientes. El Mantenimiento consume una parte importante de
mantenimiento debe tener artefactos de software la finan-
de desarrollo (por ejemplo, cdigo o docu- ciales recursos en un ciclo de vida del software.
mentacin) y apoyarlos de inmediato, y luego Una comn
evolucionar progresivamente / mantenerlas
durante un ciclo de vida del software.

1.3. La necesidad de mantenimiento

[2 *,
c1s5]

El mantenimiento es necesario para asegurar que

el software contina para satisfacer las
necesidades del usuario. manteni- miento es
aplicable al software que se desarrolla utilizando
cualquier modelo de ciclo de vida del software
(por ejemplo, espiral o lineal). productos de
software cambian debido a las acciones
correctivas y de software noncorrective.
Mantenimiento debe ser realizado con el fin de

corregir fallas;
mejorar el diseo;
implementar mejoras;
interactuar con otros softwares;
adaptar los programas a fin de que distintos
tipos de hardware, el software, las
caractersticas del sistema y de las
telecomunicaciones instalaciones se pueden
utilizar;
migrar software heredado; y
retirarse de software.

Cinco caractersticas clave incluyen las

actividades de la er maintain-:

mantener el control sobre las funciones de

da-a-da del software;
maintainingcontrolover
software
modificacin;
el perfeccionamiento de las funciones
existentes;
la identificacin de amenazas a la seguridad
y la fijacin de las vulnerabilidades de
seguridad; y
preventingsoftwareperformancefrom
degradantes a inaceptable
los niveles.
 Mantenimiento
perfec- tivo [2 *, c4s3]. IEEE de Software
14764 incluye una
percepcin de mantenimiento del software es 5-5
que se limita a fijar los fallos. Sin embargo, cuarta categora-preventivo.
estudios y encuestas realizadas a lo largo de los
aos han indicado que la dad de Divisin, ms El mantenimiento correctivo: modifi- reactiva
del 80 por ciento, del mantenimiento del cacin (o reparaciones) de un producto de
software se utiliza para acciones noncorrective software
[2 *, figura 4.1]. La agrupacin de mejoras y
correcciones juntos en los informes de gestin
contribuye a algunos conceptos errneos con
respecto a los altos costos de correcciones. La
comprensin de las categoras de
mantenimiento de software ayuda a
comprender la estructura de los costes de
mantenimiento de software. Adems, la
comprensin de los factores que influyen en la
capacidad de mantenimiento de software puede
ayudar a contener los costos. Algunos factores
medioambientales y su relacin con los costos
de mantenimiento de software incluyen los
siguientes:

Entorno de funcionamiento se refiere al

hardware
y el software.
ambiente organizacional se refiere a cies
POLI, competencia, proceso, producto, y
personal.

1.5. Evolucin de Software

[2 *,
c3s5]

El mantenimiento del software en trminos de

evolucin se abord por primera vez en la
dcada de 1960. Durante un perodo de veinte
aos, la investigacin condujo a la formulacin
de ocho leyes de la evolucin. Las
principales conclusiones son una propuesta que
el mantenimiento es desa- rrollo evolutivo y
que las decisiones de mantenimiento son
ayudados mediante la comprensin de lo que
ocurre con el software con el tiempo. Algunos
afirman que el mantenimiento se contina el
desarrollo, con la excepcin de que hay una
entrada adicional (o restriccin), en otras
palabras, que existe gran soft- ware nunca es
completa y contina evolucionando; a medida
que evoluciona, crece ms compleja si no se
toman algunas medidas para reducir esta
complejidad.

1.6. Categoras de Mantenimiento

[1 *, c3, c6s2] [2 *,
c3s3.1]

Se han definido tres categoras (tipos) de

mantenimiento: correctivo, adaptativo y
5-6 Gua SWEBOK V3.0

realizado despus de la entrega para corregir prximo lanzamiento, mientras que el envo de
problemas Ered descu-. Se incluyen en esta parches de emergencia para la versin actual,
categora es el mantenimiento de tambin crea un desafo. En la siguiente seccin
emergencia, que es una modificacin no se presentan algunos de los problemas gas Nical
programada se realiza para mantener y de gestin relacionados con el mantenimiento
temporariamente un producto de software del software. Se han agrupado bajo los
en funcionamiento en espera de siguientes encabezados de los temas:
mantenimiento correctivo.
mantenimiento adaptativo: modificacin de problemas tcnicos,
un producto de software se realiza despus asuntos Gerenciales,
de la entrega para mantener un producto de estimacin de costos, y
software que puedan utilizarse en un medicin.
entorno cambiante o cambiar. Por ejemplo,
el sistema operativo puede ser actualizado y 2.1. Tcnico Cuestiones
algunos cambios en el software puede ser
necesario. 2.1.1. La comprensin limitada
mantenimiento perfectivo: modificacin de [2 *, c6]
un producto de software despus de la
entrega para proporcionar mejoras para los comprensin limitada se refiere a la rapidez con
usuarios, mejora de la documentacin del que un ingeniero de software puede entender que
programa, y la recodificacin para mejorar para hacer un cambio o correccin en el software
el rendimiento del software, capacidad que l o ella no se desarroll. Las
maintain-, u otros atributos de software. investigaciones indican que aproximadamente la
El mantenimiento preventivo: modificacin mitad del total del esfuerzo de mantenimiento se
de un producto de software despus del dedica a pie Adjunto del software para ser
parto para detectar fallas latentes y correctas modificado. Por lo tanto, el tema de la
en el producto de software antes de que sean comprensin de software es de gran inter est a
fallos de funcionamiento. los ingenieros de software. La comprensin es
ms difcil en el cdigo fuente de la
IEEE 14764 clasifica mantenimiento representacin en orientada a texto, por ejemplo,
adaptativo y perfectivo como mejoras de donde a menudo es difcil trazar la evolucin del
mantenimiento. Tambin agrupa a las categoras software a travs de sus publicaciones /
de mantenimiento tiva correctivas y prevencin versiones si los cambios no estn documentados
en una correccin CAT- gora, como se muestra y si los desarrolladores no estn disponibles a lo
en la Tabla 5.1. explican, lo que suele ser el caso. Por lo tanto,
Tabla 5.1. Mantenimiento de Software los ingenieros de software pueden ini- cialmente
Categoras tienen una comprensin limitada del software;
Correccin Mejora an queda mucho por hacer para remediar esto.
Proactivo Preventivo perfectivo
2.1.2. Pruebas
Reactivo Correctivo Adaptado
[1 *, c6s2.2.2] [2 *, c9]

2. Cuestiones clave en el mantenimiento de otro ingeniero de software desarrollados. Del

software mismo modo, compitiendo con los desarrolladores
de software de recursos es una batalla constante.
Una serie de cuestiones clave debe ser tratada La planificacin de una versin futura, que a
para garantizar el mantenimiento eficaz de menudo incluye la codificacin
software. mantenimiento de software ofrece
retos nicos cal y de gestin tcnicamente para
los ingenieros de software-para ejemplo,
tratando de encontrar un fallo en el software que
contiene un gran nmero de lneas de cdigo que
 Mantenimiento de Software
El costo de la repeticin de la prueba completa 5-7
en una pieza importante de software es
importante en trminos de tiempo y dinero.
Con el fin de garantizar que los informes de
problemas solicitados son vlidos, el
mantenedor debe replicar o verificar los
problemas mediante la ejecucin de las pruebas
adecuadas. Las pruebas de regresin (la
repeticin de pruebas selec- tiva de software o
un componente de ver- ify que las
modificaciones no han causado efectos unin-
cuidados) es un concepto importante en las
pruebas de mantenimiento. Adems, encontrar
tiempo para probar es a menudo difcil. La
coordinacin de las pruebas cuando diferentes
miembros del equipo de mantenimiento estn
trabajando
5-8 Gua SWEBOK V3.0

sobre diferentes problemas al mismo tiempo 2.1.4. mantenibilidad

sigue siendo un desafo. Cuando el software [1 *, c6s8] [2 *,
realiza fun- ciones crticos, puede ser difcil para c12s5.5]
llevarlo fuera de lnea para la prueba.
Las pruebas no se pueden ejecutar en el lugar-ful IEEE 14 764 [1 *, c3s4] define mantenibilidad
el sistema de produccin ms sentido-. La como la capacidad del producto de software para
Prueba KA Software proporciona informacin y ser modificado. Las modificaciones pueden
referencias adicionales sobre este asunto en su incluir correcciones, mejoras, o la adaptacin del
subtema en las pruebas de regresin. software a cambios en el entorno, as como
cambios en los requisitos y especificaciones
2.1.3. Anlisis de impacto funcionales.
[1 *, c5s2.5] [2 *, Como una caracterstica de calidad del
c13s3] software principal, capacidad de mantenimiento
se debe especificar, revisado y controlado
Anlisis de impacto describe cmo llevar a cabo, durante los lazos de desarrollo de software
de manera rentable, un anlisis completo del activi- el fin de reducir los costes de
impacto de un cambio en el software existente. mantenimiento. Cuando se hace correctamente,
Mantenedores deben poseer un conocimiento el mantenimiento del software mejorar. La
profundo de la estructura y el contenido del mantenibilidad es a menudo difcil de lograr
software. Ellos usan este conocimiento para debido a las subcaractersticas menudo no son
llevar a cabo anlisis de impacto, que identifica un foco importante durante el proceso de
a todos los sistemas y productos de software desarrollo de soft- ware. Los desarrolladores
afectadas por una solicitud de cambio de estn, por lo general, ms preocupados con
software y desarrolla una estimacin de los muchas otras actividades y con frecuencia
recursos necesarios para llevar a cabo el cambio. propensos a ignorar las exigencias del
Adems, se determina el riesgo de hacer el mantenedor. Esto a su vez puede, ya menudo lo
cambio. La solicitud de cambio, a veces se llama hace, dar lugar a una falta de documentacin de
una peticin de modificacin (MR) y, a menudo software y entornos de prueba, que es una de las
llamado un informe de problemas (PR), primero principales causas de los lazos dificultades en la
debe ser analizado y traducido en trminos de comprensin del programa y anlisis de impacto
software. Anlisis de impacto se realiza despus posterior. La presencia de procesos sistemticos
de una solicitud de cambio entra en el proceso y maduros, tcnicas y herramientas de ayuda
de gestin de la configuracin soft- ware. IEEE para mejorar la capacidad de mantenimiento de
14764 establece las tareas de anlisis de software.
impacto:
2.2. Asuntos Gerenciales

analizar MRs / IPs; 2.2.1. La alineacin con los

replicar o verificar el problema; objetivos organizacionales
desarrollar opciones para la aplicacin del [2 *, c4]
modificacin;
documentar el MR / PR, los resultados y las accin.
opciones de ejecucin; Software diseado con capacidad de
obtener la aprobacin de la modificacin mantenimiento en mente facilita en gran medida
seleccionada el anlisis del impacto. ms infor- macin se
opcin. puede encontrar en el software de gestin de la
configuracin KA.
La gravedad de un problema a menudo se
utiliza para decidir cmo y cundo va a ser fijo.
El ingeniero de soft- ware a continuacin,
identifica los componen- tes afectados. Se
proporcionan varias soluciones posibles, seguido
de una recomendacin sobre el mejor curso de
objetivos de la organizacin describen cmo para Mantenimiento de Software
5-9
demostrar los retorno de la inversin de
software de man- actividades tenance.
desarrollo de software inicial es por lo general
basado en proyectos, con una escala de tiempo
definido y presupuesto. El nfasis principal es
entregar un producto que satisfaga las
necesidades del usuario a tiempo y dentro del
presupuesto. Por el contrario, el mantenimiento
de software a menudo tiene el objetivo de
extender la vida de software para el mayor
tiempo posible. Adems, puede ser impulsado
por la necesidad de satisfacer la demanda del
usuario para las actualizaciones y mejoras del
software. En ambos casos, el retorno de la
inversin es mucho menos clara, por lo que la
vista en el nivel de la alta direccin es a
menudo la de una importante actividad que
consume recursos significativos sin ningn
beneficio cuantificable clara para la
organizacin.
5-10 Gua SWEBOK V3.0

2.2.2. dotaci asignacin de la responsabilidad de

n de [2 *, c4s5, mantenimiento a un solo grupo o persona,
persona c10s4] independientemente de la estructura de la
l organiza- cin.
Dotacin de personal se refiere a la manera de
atraer y mantener al personal de mantenimiento 2.2.5. La
soft- ware. El mantenimiento no es a menudo externalizac [3 *]
visto como un trabajo glamoroso. Como in
resultado, se ve con ms frecuencia el personal
de mantenimiento de software
como ciudadanos de segunda clase, y por lo promueve una atmsfera sin ego,
tanto la moral universitarios;
sufre. reduce la dependencia de los individuos;
permite controles de auditora peridicas.
2.2.3. Proceso
[1 *, c5] [2 *, c5] Puesto que hay muchos pros y los contras de
cada opcin, la decisin debe hacerse sobre una
El proceso del ciclo de vida del software es un base de caso por caso. Lo que es importante es la
conjunto de actividades, mtodos, prcticas y delegacin o
transformaciones que PEO uso PLE para
desarrollar y mantener el software y sus
productos asociados. A nivel de proceso, las
actividades de mantenimiento de software tienen
mucho en comn con el desarrollo de software
(por ejemplo, gestin de configuracin de
software es una actividad crucial en ambos). El
mantenimiento tambin requiere varias
actividades que no se encuentran en desarrollo
de software (ver seccin 3.2 en actividades
nicas para ms detalles). Estas actividades
presentan desafos para la gestin.

2.2.4. Aspectos de organizacin de

Mantenimiento
[1 *, c7s2.3] [2 *, c10]

Aspectos organizativos describen cmo iden-

tificar qu organizacin y / o funcin ser
responsable del mantenimiento del software. El
equipo que desarrolla el software no est
necessar- ily asignado para mantener el software
una vez que est en funcionamiento.
Al decidir dnde se ubicar la funcin de
mantenimiento de software, las organizaciones
de ingeniera de software pueden ser, por
ejemplo, quedarse con el desarrollador original o
ir a un equipo de mantenimiento especfico
permanente (o personal de mantenimiento).
Tener un equipo de mantenimiento permanente
tiene muchos beneficios:

permite la especializacin;
crea canales de comunicacin;
La externalizacin y la deslocalizacin de Mantenimiento de Software
5-11
software manteni- miento se ha convertido en
una industria importante. Las organizaciones
que estn externalizando carteras enteras de
software, incluyendo el mantenimiento del
software. Ms a menudo, la opcin de la
externalizacin se selecciona por menos de
software de misin crtica, como las
organizaciones no estn dispuestos a perder el
control del software utilizado en su negocio
principal. Uno de los principales retos para los
subcontratistas es determinar el alcance de los
servicios de mantenimiento requeridos, los
trminos de un acuerdo de nivel de ser- vicio, y
los detalles contractuales. Subcontratistas
tendrn que invertir en una infraestructura de
mantenimiento y el servicio de asistencia en el
sitio remoto debe contar con personal con
hablantes de lengua nativa. La externalizacin
requiere una inver- sin inicial importante y la
configuracin de un proceso de mantenimiento
que requerir la automatizacin.

2.3. Estimacin de costes de mantenimiento

Los ingenieros de software deben entender las

diferentes categoras de mantenimiento de
software, expuestos anteriormente, con el fin
de abordar la cuestin de ing realizan
estimaciones del costo de mantenimiento de
software. Para fines de planificacin,
estimacin de costos es un aspecto importante
de la planificacin para el mantenimiento del
software.

2.3.1. Estimacin de costos

[2 *, c7s2.4]

Seccin 2.1.3 se describe cmo el anlisis del

impacto iden- tifica todos los sistemas y
productos de software afectadas por una
solicitud de cambio de software y desarrolla
una estimacin de los recursos necesarios para
llevar a cabo ese cambio.
estimaciones de los costos de mantenimiento
se ven afectados por muchos factores tcnicos
y no tcnicos. IEEE 14764 establece que los
dos mtodos ms populares a los recursos de
estimacin para el mantenimiento del software
son el uso de modelos paramtricos y el uso de
la experiencia [1 *, c7s4.1]. Una combinacin
de estos dos tambin se puede utilizar.
5-12 Gua SWEBOK V3.0

2.3.2. Los modelos modelo de calidad sugiere medidas que son

paramtricos [2 *, especficos para el mantenimiento del software.
c12s5.6] Medidas para la carac- subchar- de
mantenimiento incluyen el seguimiento
el modelo de costos paramtricos (modelos [2 *, c12]
matemticos) se ha aplicado al mantenimiento
del software. De significacin es que se El mantenedor debe determinar qu medidas son
necesitan datos histricos del pasado de adecuadas para una organizacin especfica
manteni- miento con el fin de usar y calibrar los basada en el propio contexto de esa organizacin.
modelos matemticos. atributos generador de El software
costos afectan las estimaciones.

2.3.3. Experiencia
[2 *, c12s5.5]

La experiencia, en forma de juicio de expertos,

se utiliza a menudo para estimar el esfuerzo de
mantenimiento. Claramente, el mejor enfoque
para el mantenimiento macin estimacin es
combinar los datos histricos y expe- riencia. El
coste para llevar a cabo una modificacin (en
trminos de nmero de personas y la cantidad de
tiempo) se deriva entonces. datos histricos de
estimacin de mantenimiento deben ser
proporcionados como resultado de un programa
de medicin.

2.4. Medicin de mantenimiento de software

[1 *, c6s5] [2 *, c12]

Entidades relacionadas con el mantenimiento del

software, cuyos atributos puede ser sometido a
medicin, incluyen procesos, recursos, y el
producto [2 *, c12s3.1].
Hay varias medidas de software que se pueden
derivar de los atributos del software, el proceso
de mantenimiento y personal, tamao ing
INCLUYENDO, la complejidad, la calidad, la
comprensibilidad, mantenibilidad y esfuerzo.
medidas de la complejidad del software tambin
se pueden obtener utilizando herramientas
comerciales disponibles. Estas medidas
constituyen un buen punto de partida para el
programa de medi- cin del mantenedor. La
discusin de los procesos de software y
medicin del producto tambin se presenta en la
Ingeniera de Procesos de Software KA. El tema
de un programa de medicin de software se
describe en el Software Engineering
Management KA.

2.4.1. Las medidas especficas

ING [4 *, p. 60]: Mantenimiento de Software
5-13

Analizabilidad: medidas de esfuerzo o

recursos utilizados en el intento, ya sea
para diagnosticar deficiencias o causas de
fallo o para identificar las partes del
mantenedor a ser modificados.
Mutabilidad: medidas de esfuerzo del
mantenedor asociados con la
implementacin de una modificacin cado
speci-.
Estabilidad: medidas del comporta- miento
inesperado de software, incluidos los que
se encontr durante la prueba.
La capacidad de prueba: medidas del
mantenedor del esfuerzo y de los usuarios
en el intento de probar el software
modificado.
Otras medidas que utilizan los
mantenedores incluyen
tamao del software,
complejidad del software,
comprensibilidad, y
mantenibilidad.

Proporcionar esfuerzo de mantenimiento de

software, por categoras, para diferentes
aplicaciones proporciona informacin de la
empresa a los usuarios y sus organiza- ciones.
Tambin puede permitir la comparacin de los
perfiles de mantenimiento soft- ware
internamente dentro de una organizacin.

3. Proceso de mantenimiento

Adems de la ingeniera de software cesos pro

estndar y las actividades descritas en el
estndar IEEE 14764, hay una serie de
actividades que son exclusivas de los
mantenedores.

3.1. Los procesos de mantenimiento

[1 *, c5] [2 *, c5] [5,
S5.5]

procesos de mantenimiento proporcionan

necesarias actividades y las entradas / salidas
detalladas a aquellas actividades como se
describe en IEEE 14764. actividades Cess el
mantenimiento pro- de IEEE 14764 se
muestran en la figura
5.2. las actividades de mantenimiento de
software incluyen

implementacin de procesos,
problema y el anlisis de la modificacin,
aplicacin modificacin,
5-14 Gua SWEBOK V3.0

opinin de mantenimiento / aceptacin, integridad. Estas

migracin y
Retirada del software.

Figura 5.2. Proceso de Mantenimiento de

Software

Otros modelos de procesos de mantenimiento

incluyen:

arreglo rapido,
espiral,
Osborne,
mejora iterativa, y
reutilizar-orientado.

Recientemente, metodologas giles, que

promueven los procesos de luz, tambin se han
adaptado a mante- manteni-. Este requisito surge
de la creciente demanda en constante para la
entrega rpida de los servicios de manteni-
miento. Mejoras para el proceso de
mantenimiento del software se apoya en
modelos especializados capacidad de
mantenimiento de software de vencimiento (ver
[6] y [7], que estn anotados brevemente en la
seccin Lecturas Adems).

3.2. Actividades de mantenimiento

[1 *, c5, c6s8.2, c7s3.3]

El proceso de mantenimiento contiene las

actividades y tareas necesarias para modificar un
producto soft- ware existente, preservando su
 Mantenimiento de Software
actividades y tareas son responsabilidad del 5-15
mantenedor. Como ya se ha sealado, muchas Mantenedores tambin pueden realizar
actividades de mantenimiento son similares a las actividades de apoyo, como la documentacin,
del software de Desa- cin. Mantenedores de gestin de configuracin de software,
realizar el anlisis, diseo, ing de bacalao, verificacin y validacin, resolucin de
pruebas y documentacin. Deben realizar un problemas, el software de control de calidad,
seguimiento de los requisitos en sus actividades revisin,
al igual que se hace en la documentacin de
desarrollo y actualizacin a medida que cambian
las lneas de base. IEEE 14764 recomienda que
cuando un mantenedor utiliza un proceso de
desarrollo, debe ser adaptada para satisfacer las
necesidades especficas [1 *, c5s3.2.2]. Sin
embargo, para el mantenimiento del software,
algunas actividades implican procesos nicos
para el mantenimiento del software.

3.2.1. Actividades nicas

[1 *, c3s10, c6s9, c7s2, c7s3] [2 *, c6,
c7]

Hay una serie de procesos, actividades, y

prcticas que son nicos para el mantenimiento
del software:

la comprensin del programa: actividades

necesarias para obtener un conocimiento
general de lo que lo hace un producto de
software y cmo las partes trabajan juntas.
Transicin: una secuencia controlada y
coordinada de las actividades durante el cual
el software se transfiere progresivamente de
la oper desa- al mantenedor.
solicitud de modificacin de la aceptacin /
rechazo: modificaciones que solicitan
trabajo ms all de un CER Tain tamao /
esfuerzo / complejidad pueden ser
rechazados por los mantenedores y son
redirigidos a un desarrollador.
Mantenimiento de mesa de ayuda: un
usuario final y la funcin de soporte de
mantenimiento coordinado que desencadena
la evaluacin, priorizacin y clculo de
costos de las solicitudes de modificacin.
Anlisis de impacto: una tcnica para
identificar las reas afectadas por un cambio
potencial;
Acuerdos de mantenimiento de nivel de
servicio (SLA) y licencias de mantenimiento
y con- tratos: acuerdos contractuales que
describen los servicios y los objetivos de
calidad.

3.2.2. Las actividades que apoyen

[1 *, c4s1, c5, c6s7] [2 *,
c9]
5-16 Gua SWEBOK V3.0

y las auditoras. Otra actividad importante apoyo seguido de un plan de mantenimiento. El concepto
consiste en la formacin de los mantenedores y de mantenimiento para cada producto de software
usuarios. debe ser documentado en el plan [1 *, c7s2] y
debe hacer frente a la
3.2.3. Actividades de mantenimiento
Planificacin mbito del mantenimiento de software,
[1 *, c7s3] la adaptacin del proceso de mantenimiento
de software,
Una actividad importante para el mantenimiento
del software es la planificacin, y mantenedores
debe abordar las cuestiones relacionadas con la
planificacin de una serie de perspectivas,
incluyendo

la planificacin de negocios (nivel de la

organizacin),
la planificacin del mantenimiento (nivel de
transicin),
planificacin de entregas / versin (versin
de software), y
planificacin individual cambio de software
peticin (nivel de solicitud).

A nivel de peticin individual, la planificacin

se lleva a cabo durante el anlisis de impacto
(ver sec- cin 2.1.3, el anlisis del impacto). La
actividad de planificacin de entregas / versin
requiere que el mantenedor:

recoger las fechas de disponibilidad de las

solicitudes individuales,
de acuerdo con los usuarios sobre el
contenido de versiones posteriores /
versiones,
identificar los conflictos potenciales y
desarrollar
alternativas,
evaluar el riesgo de un comunicado dado y
desarrollar un plan de respaldo en caso de
que surjan problemas, y
informar a todos los interesados.

Considerando que los proyectos de desarrollo

de software normalmente pueden durar desde
algunos meses hasta unos pocos aos, la fase de
mantenimiento suele durar muchos aos.
Haciendo estimaciones de los recursos es un
elemento clave de la planificacin del
mantenimiento. Software de planificacin de
manteni- miento debe comenzar con la decisin
de desarrollar un nuevo producto de software y
deben considerar los objetivos de calidad. Un
documento de reflexin debe ser desarrollado,
 Mantenimiento
determinar el contenido de la prximadeversin
Software/
identificacin del mantenimiento de 5-17
software versin.
organizacin, y
estimacin de los costes de mantenimiento
de software.

El siguiente paso es desarrollar un plan de

mantenimiento de software correspondiente.
Este plan debe ser preparado durante el
desarrollo de software y debe especificar cmo
los usuarios solicitar modifi- caciones de
software o reportar problemas. la planificacin
del mantenimiento de software se aborda en
IEEE 14764. Proporciona directrices para un
plan de mantenimiento. Por ltimo, al ms alto
nivel, la organizacin de mantenimiento tendr
que llevar a cabo actividades de planificacin
de negocios (y los recursos humanos,
presupuestarios financieros) al igual que todas
las otras divisiones de la organizacin. Gestin
se discute en el captulo relacionado
Disciplinas de Ingeniera de Software.

3.2.4. Gestin de la Configuracin de

Software
[1 *, c5s1.2.3] [2 *,
c11]

IEEE 14 764 describe la administracin de

configuracin de software como un elemento
crtico del proceso de manteni- miento. Ment
procedimientos manage- de configuracin de
software deben proporcionar para la verifica-
cin, validacin y auditora de cada paso
necesario para identificar, autorizar,
implementar y liberar el producto de software.
No es suficiente con realizar un seguimiento
de las solicitudes de modifi- cacin o informe
de problemas. El producto de software y los
cambios realizados a la misma deben ser
Controlled. Este control se establece por ING
implement- y aplicacin de un proceso de
software de gestin aprobado configu- racin
(SMC). La Administracin de KA del software
de configuracin proporciona detalles de SMC
y discute el proceso por el cual las solicitudes
de cambio soft- Ware presentado, evaluado y
aprobado. SMC para el mantenimiento de
software es diferente de SMC para el
desarrollo de software en el nmero de
pequeos cambios que debe ser controlada
con- el software operativo. El pro- ceso SMC
se implementa mediante el desarrollo y
siguiendo unos procedimientos del plan de
gestin y operacin de configuracin de
software. Mantenedores participan en las
Juntas de Control de configuracin para
5-18 Gua SWEBOK V3.0

3.2.5. Calidad del software 4.3. Ingeniera inversa

[1 *, c6s5, c6s7, c6s8] [2 *, [1 *, c6s2] [2 *, c7,
c12s5.3] c14s5]

No es suficiente con la esperanza de que una La ingeniera inversa es el proceso de anlisis de

mayor calidad tendr como resultado del software para identificar los componentes del
mantenimiento de soft- ware. Mantenedores software y sus interrelaciones y crear
deben tener un programa de cali- dad de representaciones del software en otra forma o en
software. Se debe planificarse y procesos debe los niveles ms altos de abstraccin. Reverse
ser implementado para apoyar el proceso de Engineer- ing es pasivo; no cambia el software o
mantenimiento. Las actividades y tcnicas para dar lugar a un nuevo software. Invertir Engineer-
la Cesin de Software Quality Assurance (SQA), esfuerzos ing producen grficos de llamada y
V & V, opiniones y auditoras deben ser grficos de flujo de control de cdigo fuente. Un
seleccionados de comn acuerdo con todos los tipo de ingeniera inversa es redocumentacin.
dems procesos para alcanzar el nivel deseado Otro tipo es la recuperacin de diseo. Por
de calidad. Tambin se recomienda que el tainer ltimo, los datos inversa inge- niera, donde los
man- adaptar el desarrollo de software procesos, esquemas lgicos son recuperados de bases de
tcnicas y resultados (por ejemplo, la datos fsicos, ha crecido en importancia en los
documentacin de la prueba), y los resultados de ltimos aos. Las herramientas son clave para
las pruebas. Ms detalles se pueden encontrar en inge- niera inversa y tareas relacionadas, como
la calidad del software KA. redocumenta- cin y recuperacin de diseo.

4. Las tcnicas para mantenimiento

Este tema se presentan algunas de las tcnicas 4.4. Migraci

generalmente aceptados utilizados en el n [1 *, c5s5]
mantenimiento del software.

4.1. programa de Durante la vida de software, que puede tener que

Comprensin [2 *, c6, ser modificada convenientemente para funcionar
c14s5] en entornos diferentes. Con el fin de migrar a un
nuevo entorno, el mantenedor
Los programadores pasan considerables lectura y trata de mejorar una estructura pro- grama y su
la comprensin de los programas con el fin de facilidad de mantenimiento. ING tcnicas
implementar los cambios de tiempo. Refactor- se pueden utilizar durante los cambios
navegadores de cdigo son herramientas clave de menor importancia.
para la comprensin del programa y se utilizan
para organizar y cdigo fuente ent PRESION.
documentacin clara y concisa tambin puede
ayudar en la comprensin del programa.

4.2. reingeniera
[2 *, c7]

Reingeniera se define como el examen y la

alteracin de software para reconstituir en una
nueva forma, e incluye el cin Ejecucin
posterior de la nueva forma. A menudo no se
lleva a cabo para mejorar la mantenibilidad, pero
para reemplazar el envejecimiento de software
ACY pierna-. Refactoring es una tc- nica
reingeniera que pretende reorganizar un
programa sin cambiar su comportamiento. Se
necesita determinar las acciones necesarias Mantenimiento de Software
5-19
para la migracin cumpla cabalmente, y luego
desarrollar y docu- mento los pasos necesarios
para llevar a cabo la migracin en un plan de
migracin que cubre los requisitos de
migracin, herramientas de migracin,
conversin del producto y datos, ejecucin,
verificacin , y apoyo. Migracin de software
tambin puede implicar una serie de
actividades adicionales, tales como

notificacin de la intencin: una

declaracin de por qu el antiguo entorno
ya no ser Apoyado, seguida de una
descripcin del nuevo entorno y su fecha
de disponibilidad es;
operaciones paralelas: poner a disposicin
los viejos y nuevos entornos de modo que
el usuario experimenta una transicin
suave al nuevo entorno;
notificacin de finalizacin: cuando se
haya completado la migracin ULed
sched-, se enva una notificacin a todos
los interesados;
 Mantenimiento de Software
5-11

opinin despus de la operacin: una rebanadoras de programas, que seleccionan

evaluacin de la operacin parale- y el slo partes de una
impacto del cambio al nuevo entorno; programa afectado por un cambio;
archivado de datos: almacenamiento de los analizadores estticos, que permiten ing
datos del software de edad. vista- general y resmenes de un contenido
del programa;
4.5. Jubilacin analizadores dinmicos, que permiten al
[1 *, tainer man- conocer la va de ejecucin de
c5s6] un programa;
analizadores de flujo de datos, que permiten
Una vez que el software ha alcanzado el final de al tainer man- realizar el seguimiento de
su vida ful uso-, debe ser retirado. Un anlisis todos los posibles flujos de datos de un
debe llevarse a cabo para ayudar a tomar la programa;
decisin de retiro. Este anlisis debe ser incluido cruzadas referencers, que generan los
en el plan de retiro, que cubre mentos de ndices de los componentes del programa; y
jubilacin requisitos, el impacto de reemplazo, analizadores de dependencia, que ayudan a
calendario, y esfuerzo. Accesibilidad de copias ERS maintain- analizar y comprender las
de archivo de datos tambin puede ser incluido. interrelaciones entre los componentes de un
Retirarse de software conlleva una serie de programa.
actividades similares a la migracin.
Herramientas de ingeniera inversa ayudan al
5. Herramientas de mantenimiento de proceso trabajando hacia atrs desde un producto
software existente para crear artefactos tales como
[1 *, c6s4] [2 *, especificacin y diseo descripciones, que a
c14] continuacin se pueden transformar para generar
un nuevo producto de una antigua. Principal-
Este tema abarca herramientas que son tambin utilizan recipientes de prueba de
particularmente importantes en el software, gestin de con- figuracin de software,
mantenimiento de software donde se est documentacin de software y herramientas de
modificando el software existen- ing. Ejemplos medicin de software.
CON RESPECTO A comprensin del programa
incluye
5-12 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Grubb y Takang 2003 [2

yoEEE / ISO / IEC 14764
2006 [1 *]

Sneed 2008
[3 *]
*]
1. Fundamentos de
mantenimiento de
software
1.1. Definiciones y terminologa c3 c1s2, C2S2
1.2. Naturaleza de Mantenimiento c1s3
1.3. La necesidad de mantenimiento c1s5
1.4. La mayora de los costos de c4s3, c5s5.2
mantenimiento
1.5. Evolucin de Software c3s5
1.6. Categoras de Mantenimiento c3, c6s2 c3s3.1, c4s3
2. Temas clave en el
mantenimiento de
software
2.1. Problemas tcnicos
2.1.1. La comprensin limitada c6
2.1.2. Pruebas c6s2.2.2 C9
2.1.3. Anlisis de impacto c5s2.5 c13s3
2.1.4. mantenibilidad c6s8, c3s4 c12s5.5
2.2. Asuntos Gerenciales
2.2.1. Alineacin con
c4
objetivos de la organizacin
2.2.2. dotacin de c4s5, c10s4
personal
2.2.3. Proceso c5 c5
2.2.4. OrganizativoAspectos de
c7s.2.3 c10
Mantenimiento
2.2.5. Subcontrataciones / todas
Offshoring
2.3. Estimacin de costes de
mantenimiento
2.3.1. Estimacin de costos c7s4.1 c7s2.4
 Mantenimiento de Software
5-13

Grubb y Takang 2003 [2

yoEEE / ISO / IEC 14764
2006 [1 *]

Sneed 2008
[3 *]
*]
2.3.2. Los modelos paramtricos c12s5.6
2.3.3. Experiencia c12s5.5
2.4. Medicin de
c6s5 c12, c12s3.1
mantenimiento de
software
2.4.1. Las medidas especficas c12
3. Proceso de
Mantenimiento
3.1. Los procesos de mantenimiento c5 c5
c5, c5s3.2.2,
3.2. Actividades de mantenimiento
c6s8.2, c7s3.3
c3s10, c6s9, c7s2,
3.2.1. Actividades nicas C6, C7
c7s3
3.2.2. Las actividades que apoyen c4s1, c5, c6s7 C9
3.2.3. Planificacin de
c7s2, c7s.3
mantenimiento
Ocupaciones
3.2.4. SoftwareGestin de la
c5s1.2.3 c11
configuracin
3.2.5. Calidad del software c6s5, c6s7, c6s8 c12s5.3
4. Tcnicas de Mantenimiento
4.1. programa de Comprensin c6, c14s5
4.2. reingeniera c7
4.3. Ingeniera inversa c6s2 c7, c14s5
4.4. Migracin c5s5
4.5. Jubilacin c5s6
5. Herramientas de Mantenimiento c6s4 c14
de Software
5-14 Gua SWEBOK V3.0

LECTURAS Referencias

A. abril y A. Abran, Gestin de [1 *] IEEE Std. 14764-2006 (tambin conocido

Mantenimiento de Software: Evaluacin y como ISO / IEC
Mejora Continua [6]. 14764: 2006) estndar para el software del
ciclo de vida del software de ingeniera y
Este libro explora el dominio de los procesos de procesos de mantenimiento, IEEE 2006.
mantenimiento de software pequeos (S3M).
Proporciona mapas ROAD- para mejorar cesos [2 *] P. Grubb y AA Takang, Mantenimiento de
pro de mantenimiento de software en las Software: Conceptos y Prctica., 2 ed,
organizaciones. En l se describe un modelo de Editorial Cientfico Mundial, 2003.
madurez especfica mantenimiento de software
organizada por niveles que permiten la [3 *] HM Sneed, Mantenimiento de Software
evaluacin comparativa y la mejora continuas como un Servicio de Oferta Marino, Proc.
con. Metas para cada rea clave Tice prc- se IEEE Conf Int'l. Mantenimiento de Software
proporcionan, y el modelo de proceso de pre- (ICSM 08), IEEE, 2008, pp. 1-5.
tantes est totalmente alineado con la
arquitectura y el marco de las normas ISO12207 [4 *] JW Moore, La Hoja de Ruta de Ingeniera
internacional ISO14764 y ISO15504 y modelos de Software: Una gua basada en
de madurez populares como ITIL, COBIT, estndares, Wiley-IEEE Computer Society
CMMI y CM3. Press, 2006.

M. Kajko-Mattsson, Hacia un Modelo de [5] ISO / IEC / IEEE 24765: 2010 Sistemas y de
Negocio de Mantenimiento, IEEE Ingeniera de Software-Vocabulario, ISO /
Int'l Conf. Mantenimiento Software IEC / IEEE 2010.
[7].
[6] A. abril y A. Abran, Gestin de
Este artculo presenta una visin general del Mantenimiento de Software: evaluacin y
modelo de madurez de mantenimiento mejora continua, Wiley-IEEE Computer
correctivas (cm3). A diferencia de otros modelos Society Press, 2008.
de procesos, CM3 es un modelo espe- cializada,
dedicado exclusivamente al mantenimiento [7] M. Kajko-Mattsson, Hacia un
correctivo del software. Se considera que el mantenimiento Modelo de negocios,
mantenimiento en trminos de las actividades a Proc. Int'l Conf. Mantenimiento de
realizar y su orden, en funcin de la informacin Software, IEEE, 2001, pp. 500-509.
utilizada por estas actividades, metas, reglas y
motivaciones para su ejecucin, y los niveles de
organizacin y roles involucrados en las
distintas etapas de un proceso tpico de
mantenimiento correctivo.
 Mantenimiento de Software
5-15

CAPTULO 6

Software Configuration Management

SIGLAS para servir a un propsito particular.

Configuracin hombre-agement (CM), a
CCB Configuration Control Board continuacin, es la disciplina de que identifique
CM Gestin de la configuracin los valores de la configuracin de un sistema en
FCA Auditora de Configuracin distintos puntos en el tiempo con el fin de
Funcional sistemticamente control- ling cambios en la
PCA Auditora de Configuracin fsica configuracin y el mantenimiento de la
integridad y la trazabilidad de la configuracin
Control de Configuracin de
SCCE de todo el ciclo de vida del sistema. Se define
Software
formalmente como
SCI Tablero
Software Elemento de
Configuracin
Gestin de la Configuracin de Una disciplina aplicando direccin
SMC
Software adminis- tracin y tcnica y vigilancia a:
Plan de Gestin de la Configuracin tificar iden- y documentar las
PGCS caractersticas funcionales y cal
de Software
Physicians de un elemento de
SCR Solicitud de cambio de software
configuracin, los cambios de control a
Estado de la configuracin de las caractersticas, el procesamiento y la
SCSA
software aplicacin de registro y cambio de
SDD Contabilidad
Documento de Diseo de Software informe de estado, y verifican El
Capability Maturity Model cumplimiento con los requisitos
SEI / especificados. [1]
Integration de Software Engineering
CMMI
Institute
gestin de configuracin de software (SCM)
SQA Calidad de Software
es un proceso de ciclo de vida del software de
Requisito de software apoyo que beneficia a las actividades de gestin
SRS
Especificacin de proyectos, desarrollo y mantenimiento,
actividades de aseguramiento de la calidad, as
como los clientes y usuarios del producto final.
INTRODUCCIN Los conceptos de gestin de la configuracin
se aplican a todos los artculos que deben ser
Un sistema puede ser definido como la controlados, aunque hay algunas diferencias en
combinacin de elementos organizados para la implementacin de hardware entre el CM y
lograr uno o ms propsitos declarados [1] CM software.
interactuar. La configuracin de un sistema es la SMC est estrechamente relacionado con el
carac- tersticas funcionales y fsicas de aseguramiento de la cali- dad (SQA) actividad
hardware o software que se exponen en tcnica- de software. Tal como se define en el rea de
cal documentacin o conseguidos en un conocimiento de Calidad de Software (KA),
producto [1]; Tambin se puede considerar SQA procesos garantizan que los productos de
como una coleccin de versiones especficas de software y procesos en el ciclo de vida del
hardware, firmware, software o elementos proyecto se ajustan a sus requerimientos
combinados de acuerdo a los procedimientos especificados por la planificacin, la
especficos de construccin promulgacin, y la realizacin de un conjunto de
actividades para proporcionar la confianza objetivos SQA. En algunos contextos pro- yecto,
adecuada de que la calidad se est los requisitos especficos SQA prescriben ciertas
construyendo en el software. actividades de actividades de SCM.
SCM ayudan en el cumplimiento de estos

6-1
6-2 Gua SWEBOK V3.0

Figura 6.1. Desglose de temas para el Software Configuration Management KA

Las actividades de la SCM son la gestin y la informacin de configuracin. Desde la

Planificacin del proceso de SMC, identificacin perspectiva del ingeniero de software, SCM
de la configuracin de software, el control de la facilita
configuracin de software, la contabilidad de
estado de configuracin de software, auditora
de configuracin de software, y la gestin de
versin de software y la entrega.
El software de configuracin de
administracin de KA se relaciona con los
dems Kas, ya que el objeto de la gestin de la
configuracin es el artefacto pro ducido y
utilizado en todo el software de inge- niera
proceso.

DISTRIBUCIN DE TEMAS
PARA LA GESTIN DE
CONFIGURACIN DEL
SOFTWARE

El desglose de los temas para el Config-

Software de Gestin URACIN KA se muestra
en la Figura 6.1.

1. Gestin del Proceso de SMC

SCM controla la evolucin y la integridad de un

producto mediante la identificacin de sus
elementos; la gestin y el control del cambio; y
verificar, grabacin, y la informacin sobre la
 Configuracin del software de gestin de 6-
el desarrollo y el cambio aplicacin activi- 3
lazos. Una implementacin exitosa de SMC
requiere una planificacin y una gestin
cuidadosa. Esto, a su vez, requiere una
comprensin del contexto de la organizacin
para, y las limitaciones impuestas a, el diseo y
la implementacin del proceso de SMC.

1.1. Contexto de organizacin de SMC

[2 *, c6, Ann. D] [3 *, la introduccin] [4
*, c29]

Para planificar un proceso de SMC para un

proyecto, es preciso proceder a entender el
contexto de la organizacin y las relaciones
entre los elementos de la organizacin. SMC
interacta con otras actividades o elementos de
la organizacin.
Los elementos de la organizacin
responsable de la ingeniera de software
procesos de apoyo pueden estructurarse de
varias maneras. Aunque la responsabili- dad
para realizar ciertas tareas SCM podra ser
asignado a otras partes de la organizacin (por
ejemplo, la organizacin de desarrollo), el
responsa- bilidad global para SCM menudo
recae en un elemento zational orga- distinta o
persona designada.
El software se desarroll con frecuencia
como parte de un sistema ms grande que
contiene los elementos de hardware y
firmware. En este caso, las actividades se
llevan a cabo SCM
6-4 Gua SWEBOK V3.0

en paralelo con el hardware y el firmware CM el nivel de formalismo seleccionado para

activi- dades y deben ser compatibles con CM a implementar el software afecta al diseo y la
nivel de sistema. Tenga en cuenta que el implementacin del proceso de SMC.
firmware contiene hardware y software; Por lo Una gua para el diseo y la implementacin de
tanto, ambos conceptos CM de hardware y un proceso de SMC tambin se puede obtener de
software son aplicables. mejores prcticas, como se refleja en las normas
SMC podra interactuar con la actividad de sobre el software
aseguramiento de la calidad de una organizacin
en temas como la gestin de registros y
elementos no conformes. Respecto al primero,
algunos artculos bajo control SMC tambin
pueden incluir datos sobre los proyectos sujetos
a las disposiciones del programa de garanta de
calidad de la organizacin. La gestin de
elementos no conformes es aliado no baja de la
responsabilidad de la actividad de aseguramiento
de la calidad; Sin embargo, SCM puede ayudar
con pista- ing e informar sobre los elementos de
configuracin de software que caen en esta
categora.
Tal vez la relacin ms estrecha es con el
desarrollo de software y mantenimiento or-
nizaciones. Es dentro de este contexto que
muchas de las tareas de control de la
configuracin del software se con- canalizado.
Con frecuencia, las mismas herramientas
soportan desa- rrollo, el mantenimiento y los
propsitos de SCM.

1.2. Limitaciones y orientacin para el

proceso SMC
[2 *, c6, Ann. D, Ann. E] [3 *, C2, C5]
[5 *, c19s2.2]

Limitaciones que afectan, y una gua para el

proceso de SMC provenir de varias fuentes.
normativas y procedimientos de exponen a
niveles de organizacin corporativos u otros
podran influir o prescribir el diseo y la
implementacin del pro- ceso SMC para un
proyecto determinado. Adems, el contrato entre
el comprador y el proveedor podra con-
disposiciones Tain que afectan el proceso de
SMC. Por ejemplo, podran ser necesarias
ciertas auditoras de configuracin, o puede ser
especificado que ciertos artculos pueden colocar
bajo CM. Cuando los productos de software para
ser desarrollados tienen el potencial de afectar a
la seguridad pblica, los organismos reguladores
externos pueden imponer limitaciones. Por
ltimo, el proceso del ciclo de vida del software
particular elegido para un proyecto de software y
 Configuracin
1.3.1. Organizacin del software de gestin
y responsabilidades de 6-
SMC
ingeniera emitido por las diversas normas 5
orga- nizaciones (ver Apndice B de las [2 *, Ann. DS5, Ann. DS6] [3 *, c10-
normas). 11]
[4 *, introduccin,
1.3. La planificacin de SMC c29]
[2 *, c6, Ann. D, Ann. E] [3 *, c23] [4 *,
c29] Para evitar la confusin sobre quin desarrollar
dada actividades de SCM o tareas, la organizacin
La planificacin de un proceso de SMC para
un proyecto dado debe ser coherente con el
contexto organiza- zational, las restricciones
aplicables, comnmente aceptado orientacin
com-, y la naturaleza del proyecto (por
ejemplo, el tamao, la criticidad de seguridad,
y la seguridad). Las principales actividades
cubiertas son la identificacin del software de
configuracin, control de configuracin de
software, la contabilidad de estado de
configuracin de software, auditora de
configuracin de software, y la gestin de
versin de software y la entrega. Adems,
cuestiones como la organizacin y
responsabilidades, recursos y horarios, la
seleccin de herramientas y la aplicacin, el
control de proveedores y subcontratistas, y el
control de la interfaz son tpicamente sidered
con-. Los resultados de la actividad de
planificacin se registran en un Plan de SCM
(SCMP), que es Tpicamente sujeto a SQA
revisin y auditora.
Ramificacin y las estrategias que se
fusionan deben ser cuidadosamente planeado y
comunicado, ya que impactan en muchas
actividades de la SCM. Desde el punto un
SCM stand-, una rama se define como un
conjunto de la evolucin de versiones de
archivo fuente [1]. La fusin consiste en la
combinacin de diferentes cambios en el
mismo archivo [1]. Este Tpicamente se
produce cuando ms de una persona cambia de
un elemento de configuracin. Hay muchas
estrategias de ramas y la mezcla de uso comn
(vase la seccin Lecturas adicionales para una
discusin adicional).
El modelo de ciclo de vida de desarrollo de
software (vase el ciclo de vida del software
Modelos en el proceso de ingeniera de
software KA) tambin afecta SCM actividades,
y la planificacin SMC debe tener esto en
cuenta. Por ejemplo, la integracin continua es
una prctica comn en muchos enfoques desa-
rrollo de software. Por lo general se caracteriza
por ciclos de acumulacin de prueba de
implementar frecuentes. SCM actividades
deben planificarse en consecuencia.
6-6 Gua SWEBOK V3.0

papeles para que participen en el proceso de mantenimiento, formacin, y la

SMC deben ser claramente identificados. Las personalizacin?
responsabilidades especficas para las Alcance: cmo se deployed- las nuevas
actividades o tareas SCM dados tambin tienen herramientas, por ejemplo, a travs de toda la
que ser asignados a entidades de organizacin, organizacin o slo en proyectos especficos?
ya sea por ttulo o por el elemento de la Propiedad: quin es el responsable de la
organizacin. Los informes dad y canales introduccin de nuevas herramientas?
globales de Autor-SMC tambin deben ser
identificados, aunque esto puede ser logrado en
la etapa de planificacin de la gestin de
proyectos o la garanta de calidad.

1.3.2. Recursos SCM y horarios

[2 *, Ann. DS8] [3 *,
c23]

La planificacin de SMC identifica el personal y

las herramientas que participan en la realizacin
de actividades y tareas de SCM. Se abordan
cuestiones de programacin mediante el
establecimiento de secuencias necesarias tareas
de SCM y que identifique los valores de sus
relaciones con los programas de los proyectos y
los hitos establecidos en el proyecto de manage-
ment etapa de planificacin. Tambin se
especifican los requisitos de formacin
necesarios para la ejecucin de los planes y la
formacin de los nuevos miembros del personal.

1.3.3. Herramienta Seleccin e

implementacin
[3 *, c26s2, c26s6] [4 *,
c29s5]

En cuanto a cualquier rea de la ingeniera de

software, la seleccin e implementacin de
herramientas de SCM deben ser cuidadosamente
planificadas. Los siguientes pre- guntas deben
ser considerados:

Organizacin: lo que motiva adquisi- cin

de herramientas desde una perspectiva
organizacional?
Herramientas: podemos utilizar
herramientas comerciales o a desarrollar
nosotros mismos?
Medio Ambiente: cules son las
limitaciones impuestas por la organizacin
y su tc- nico contexto?
Legado: cmo utilizarn los proyectos (o
no) las nuevas herramientas?
Financiacin: quin va a pagar por la
adquisicin de las herramientas,
 Futuro: cul es el plan para el uso de las ser establecidos. Configuracin
Este ltimodel software
incluyede gestin
la de 6-
7
herramientas en el futuro? consideracin de lo que debe estar disponible
Cambiar: su capacidad de adaptacin son las para la vigilancia del cumplimiento efectivo de
herramientas? informacin SMC.
Ramas y la mezcla: son capaci- dades de
dichas herramientas compatibles con el ing
rama-planificada y estrategias de la
fusin?
Integracin: hacer las diferentes
herramientas de SCM inte- rejilla entre s?
Con otras herramientas en uso en la
organizacin?
Migracin: el repositorio puede mantenida
por la herramienta de control de versiones
ser portado a otra herramienta de control
de versiones, manteniendo la historia com-
pleta de los elementos de configuracin
que contiene?

SMC por lo general requiere un conjunto de

herramientas, en lugar de una sola herramienta.
Tales conjuntos de herramientas son algunas
veces referidos como bancos de trabajo. En un
texto tan con-, otra consideracin importante
en la Planificacin para la seleccin de la
herramienta es determinar si el banco de
trabajo SMC estar abierto (en otras palabras,
las herramientas de diferentes proveedores
sern utilizados en diferentes actividades del
proceso SMC) o integrada (donde se han
diseado elementos del banco de trabajo para
trabajar juntos).
El tamao de la organizacin y el tipo de
proyectos que participan tambin puede afectar
a la seleccin de herramientas (ver tema 7,
Configuracin de Software Manage-
Herramientas Ment).

1.3.4. Vendedor / Control de Subcontratista

[2 *, c13] [3 *, c13s9,
c14s2]

Un proyecto de software puede adquirir o

hacer uso de los productos de software
adquiridos, tales como compiladores y otras
herramientas. la planificacin SMC considera
si y cmo se tomarn estos elementos bajo
control con- figuracin (por ejemplo, integrado
en las bibliotecas pro- yecto) y cmo van a ser
evaluados y gestionados cambios o
actualizaciones.
Consideraciones similares se aplican al
software subcontratado. Al utilizar el software
de subcontratacin, tanto los requisitos de
SCM a ser impuestas sobre el proceso de SMC
del subcontratista como parte del subcontrato y
los medios para vigilar pliance com- necesitan
6-8 Gua SWEBOK V3.0

1.3.5. control de Horarios de SCM (coordinacin con otro

interfaz [2 *, c12] [3 *, actividades del proyecto)
c24s4] Recursos SCM (herramientas, recursos
fsicos,
Cuando un elemento de software de interfaz con responsabilidades, autoridades, las polticas
otro elemento de software o hardware, un aplicables, directivas y procedimientos)
cambio a cualquiera de elemento puede afectar Actividades SCM (identificacin de la
al otro. La planificacin para el proceso SMC configuracin, control de configuracin, etc.)
considera cmo se identificarn los elementos de
interfaz y cmo se gestionen y cambios en los
elementos. El papel SCM puede ser parte de un
proceso de sistema de nivel ms grande para la
especificacin y control de la interfaz; puede
tratarse de especificaciones de interfaz, planes
de control de interfaz, y los documentos de
control de interfaz. En este caso, la planificacin
de SMC para el control de la interfaz tiene lugar
dentro del contexto del proceso de nivel del
sistema.

1.4. plan de SMC

[2 *, Ann. D] [3 *, c23] [4 *,
c29s1]

Los resultados de la planificacin SMC para un

proyecto dado se registran en una configuracin
de software manage- ment Plan (SCMP), un
documento vivo que sirve como referencia
para el proceso de SMC. Se mantiene (es decir,
actualizada y aprobada) segn sea necesario
durante el ciclo de vida del software. En
Menting imple- PGCS, normalmente es
necesario desarrollar una serie de
procedimientos ms detallados, subordinados
que define cmo los requisitos especficos se
llevar a cabo durante actividades- del da a da,
por ejemplo, que se utilizarn estrategias de
ramificacin y con qu frecuencia se basa
ocurrir y auto-pruebas apareadas de todo tipo se
ejecutan.
Orientacin sobre la creacin y mantenimiento
de un PGCS, basado en la informacin
producida por la actividad de planificacin, est
disponible a partir de diversas fuentes, como por
ejemplo [2 *]. Esta referencia proporciona
requisitos para la informacin a ser contenida en
un SCMP; Tambin define y describe seis
catego- ras de informacin SMC que deben
incluirse en un SCMP:

Introduccin (propsito, el alcance, los

trminos utilizados)
Gestin de SMC (organizacin,
 y recursos humanos) Configuracin del software de gestin de 6-
9
Mantenimiento SCMP.

1.5. La vigilancia de la Gestin de la

Configuracin de Software
[3 *,
c11s3]

Despus del proceso de SMC se ha

implementado, un cierto grado de vigilancia
puede ser necesario para garantizar que las
disposiciones de la PGCS se realicen
adecuadamente. No es probable que sean los
requisitos espec- SQA espe- para garantizar el
cumplimiento de los procesos y procedimientos
especificados SCM. La persona responsable de
SMC asegura que los que tienen la
responsabilidad de realizar las tareas asignadas
SCM definidos correctamente. La autoridad de
control de calidad de software, como parte de
una actividad de auditora El cumplimiento,
tambin puede realizar esta vigilancia.
El uso de herramientas de SCM integrados
con capacidad de control de procesos puede
hacer ms fcil la tarea de vigilancia. Algunas
herramientas facilitan el proceso pliance com-
mientras que proporciona flexibilidad para el
ingeniero de soft- ware para adaptar los
procedimientos. Otras herramientas de cumplir
proceso, dejando el ingeniero de software con
menos flexibilidad. requisitos de vigilancia y el
nivel de flexibilidad para ser proporcionados al
ingeniero de software son consideraciones
importantes en la seleccin de herramientas.

1.5.1. Medidas de SCM y Medicin

[3 *, c9s2, c25s2-
s3]

SCM medidas pueden ser diseados para

proporcionar informacin CIFIC espe- sobre el
producto en evolucin o para proporcionar
informacin sobre el funcionamiento del
proceso de SMC. Uno de los objetivos
relacionados con el proceso de seguimiento de
SMC es descubrir las oportunidades de mejora
de procesos. Las mediciones de los procesos
SCM proporcionan un buen medio para el
seguimiento de la eficacia de las actividades de
la SCM de manera continua. Estas mediciones
son tiles en characteriz- ing el estado actual
del proceso, as como en la provisin de una
base para hacer comparaciones en el tiempo. El
anlisis de las mediciones puede producir
6-10 Gua SWEBOK V3.0

ideas que lleva a procesar los cambios y 2.1. Los productos que la identificacin que deben
actualizaciones correspondientes a la PGCS. ser controlados
Bibliotecas de software y las diversas [2 *, c8s2.2] [4 *,
posibilidades de herramientas SCM c29s1.1]
proporcionan fuentes para extraer informacin
acerca de las caractersticas del proceso de SMC Uno de los primeros pasos en el cambio de control
(as como el suministro de informacin agement es
hombre-proyecto y). Por ejemplo, informacin la identificacin de los elementos de software que
se desea controlar.
sobre el tiempo requerido para llevar a cabo
varios tipos de cambios sera til en una evalua-
cin de los criterios para determinar qu niveles
de autoridad son ptimas para la autorizacin de
ciertos tipos de cambios y para la estimacin de
cambios en el futuro.
Se debe tener cuidado para mantener el foco
de la vigilancia en las ideas que se pueden
obtener a partir de las mediciones, no en las
propias mediciones. La discusin de los
procesos de software y medicin del producto se
presenta en el Proceso de Cesin de Software
Ingeniera KA. programas de software surement
Measure se describen en el Software
Engineering Management KA.

1.5.2. En-Proceso de Auditoras de SMC

[3 *,
C1S1]

Las auditoras pueden ser llevadas a cabo

durante el proceso de ingeniera de software para
investigar la tus esta- actual de elementos
especficos de la configuracin o para evaluar la
aplicacin del proceso de SMC. En-proceso de
auditora de SMC proporciona un mecanismo
mal ms para- para el seguimiento de los
aspectos seleccionados del proceso y puede ser
coordinado con la funcin SQA (ver tema 5,
Software configuraciones Auditora cin).

2. Identificacin de la configuracin de
software
[2 *, c8] [4 *,
c29s1.1]

identificacin de la configuracin de software

identifica los elementos a controlar, establece
esquemas de identificacin de los elementos y
sus versiones, y establece las herramientas y
tcnicas a utilizar en la adquisicin y gestin de
elementos controlados. Estas actividades
proporcionan la base para las otras actividades
de la SCM.
 seguimiento adecuadoConfiguracin del software
de estas de gestin de 6-
relaciones
Esto implica la comprensin de la 11
configuracin del software en el contexto de la tambin es importante para apoyar la
configuracin del sistema, la seleccin de los trazabilidad. El diseo del esquema de
elementos de configuracin de software, identificacin para LIC
desarrollo de una estrategia para los elementos
de software de etiquetado y la descripcin de
sus relaciones, y la identificacin tanto de las
lneas de base a ser utilizados y el
procedimiento para la adquisicin de una lnea
de base de los artculos.

2.1.1. Configuracin del software

[1, c3]

configuracin del software son las

caractersticas funcionales y ical phys- de
hardware o software como se indica en la
documentacin tcnica o se alcance en un
producto. Puede ser visto como parte de una
configuracin general del sistema.

2.1.2. Software Elemento de Configuracin

[4 *, c29s1.1]

Un elemento de configuracin (CI) es un

elemento o agregacin gacin de hardware o
software o ambos que est diseado para ser
manejado como una sola entidad. Un elemento
de configuracin de software (SCI) es una
entidad de software que se ha establecido como
un elemento de configuracin [1]. El SCM
controla tpicamente una variedad de artculos,
adems del propio cdigo. los elementos de
software con potencial para convertirse en LIC
incluye planes, especifi- caciones y
documentacin de diseo, pruebas de mate-
riales, herramientas de software, la fuente y el
cdigo ejecutable, libreras de cdigo, datos y
diccionarios de datos y documentacin para la
instalacin, mantenimiento, operaciones, y el
uso de software .
Seleccin de LIC es un proceso importante
en el que se debe lograr un equilibrio entre
proporcionar una visibilidad adecuada para el
control de proyectos poses PUR y proporcionar
un nmero manejable de artculos controlados.

2.1.3. Software Relaciones

elemento de configuracin
[3 *, c7s4]

Las relaciones estructurales entre los LIC

seleccionados, y sus partes constituyentes,
afectan a otras actividades o tareas SCM, tales
como la construccin de software o el anlisis
del impacto de los cambios propuestos.
6-12 Gua SWEBOK V3.0

Figura 6.2. Adquisicin de artculos

debe considerar la necesidad de asignar todos los cambios aprobados en la lnea de base,
elementos identificados a la estructura del representa la configuracin actual aprobado.
software, as como la necesidad de apoyar la lneas de base utilizados comnmente incluyen
evolucin de los elementos de software y sus fun- cional, asignado, de desarrollo, y el producto
relaciones.

2.1.4. Versin del software

[1, c3] [4 *, c29s3]

los elementos de software evolucionar como

Ceeds pro de proyectos de software. Una versin
de un elemento de software es una instancia
identifica- do de un elemento. Puede ser
considerado como un estado de un elemento en
evolucin. Una variante es una versin de un
programa resultante de la aplicacin de la
diversidad soft- ware.

2.1.5. Base
[1, c3]

Una lnea de base software es un aprobado

formalmente ver- sin de un elemento de
configuracin (con independencia de los medios
de comunicacin) que se designa formalmente y
se fija en un momento especfico durante el ciclo
de vida del elemento de configuracin. El
trmino tambin se utiliza para referirse a una
ver- sin particular de un elemento de
configuracin de software que ha sido acordado.
En cualquier caso, la lnea de base slo puede
modificarse a travs de procedimientos trol das a
cambios formales. Una lnea de base, junto con
 Configuracin del software de gestin de 6-
lneas de base. La lnea de base funcional 13
corresponde a los requisitos del sistema
revisado. La lnea de base asignarse los
corresponde a la especificacin de requisitos de
software y los requisitos de la interfaz de
software revisado. La lnea de base del
desarrollo representa la configuracin de
software que evoluciona a la hora seleccionada
durante el ciclo de vida del software. Cambio
autoridad de esta lnea de base normalmente
recae principalmente en la organizacin de
desarrollo, sino que puede ser compartida con
otras organizaciones (por ejemplo, SMC o de
prueba). La lnea de base del producto se
corresponde con el producto de software para
la integracin completado entregado sis- tema.
Las lneas de base a utilizar para un proyecto
dado, junto con los niveles asociados de
autoridad necesario para la aprobacin del
cambio, son Tpicamente identificado en el
SCMP.

2.1.6. La adquisicin de elementos de

configuracin de software
[3 *, c18]

los elementos de configuracin de software se

colocan bajo control SCM en diferentes
momentos; es decir, que se incorporan en una
lnea de base en particular en un punto
particular en el ciclo de vida del software. El
evento desencadenante es la realizacin de
algn tipo de tarea formal de aceptacin, tales
como una revisin formal. Figura
6.2 caracteriza el crecimiento de los artculos
baselined medida que avanza el ciclo de vida.
Esta cifra se basa en el modelo de cascada para
los propsitos de la ilustracin solamente; los
subndices usados en la figura indican
versiones
6-14 Gua SWEBOK V3.0

de los elementos cambiantes. La solicitud de qu cambios hacer, la autoridad de approv- ing

cambio de software ciertos cambios, el apoyo a la cin Ejecucin de
(SCR) se describe en la seccin 3.1. esos cambios, y el concepto de desviaciones
En la adquisicin de un SCI, se deben formales de los requisitos del proyecto, as como
establecer su origen y integri- dad inicial. exenciones de ellos. La informacin derivada de
Despus de la adquisi- cin de un SCI, cambios estas actividades es til en la medicin de trfico
en el elemento debe ser formalmente aprobado el cambio y la rotura, as como los aspectos de
como adecuado para el SCI y la lnea de base reproceso.
que participan, como se define en el PGCS.
Despus de la aprobacin, el elemento se 3.1. Solicitar, evaluar y cambios que aprueba
incorpora en la lnea de base software de Software
acuerdo con el procedimiento adecuado.
[2 *, c9s2.4] [4 *,
2.2. software Library c29s2]
[3 *, c1s3] [4 *,
c29s1.2] El primer paso en la gestin de cambios para
controlada
artculos es determinar qu cambios hacer. los
Una biblioteca de software es una coleccin trabajo y progreso.
controlada de software y la documentacin
relacionada diseado para ayudar en el 3. Control de Configuracin de Software
desarrollo de software, uso o mantenimiento [1]. [2 *, c9] [4 *, c29s2]
Tambin es fundamental para la versin de
software agement hombre- y actividades de control de la configuracin de software se ocupa
entrega. Existen varios tipos de bibliotecas de la gestin de cambios durante el ciclo de vida
podran ser utilizados, cada uno correspondiente del software. Cubre el proceso para determinar
a nivel particular del elemento de software de
madurez. Por ejemplo, una biblioteca de trabajo
podra apoyar la codificacin y una biblioteca de
soporte proyecto podra apoyar de Exmenes,
mientras que una librera maestra podra ser
utilizado para productos termi- nado. Un nivel
adecuado de SCM trol con- (lnea de base y el
nivel de autoridad para el cambio asociado) est
asociado con cada biblioteca. Seguridad, en
trminos de control de acceso y las instala- copia
de seguridad, es un aspecto clave de la gestin
de la biblioteca.
La herramienta (s) que se utiliza para cada
biblioteca debe ser compatible con las
necesidades de control de SMC para esa
biblioteca, tanto en trminos de control de LIC y
controlar el acceso a la biblioteca. A nivel
biblioteca de trabajo, se trata de una capacidad
de gestin de cdigo que sirve Desa- ERS,
mantenedores, y SCM. Se centra en el hombre-
envejecimiento de las versiones de los elementos
de software, mientras que SUP- portar las
actividades de mltiples desarrolladores. En los
niveles ms altos de control, el acceso es ms
restringida y SCM es el usuario principal.
Estas bibliotecas son tambin una importante
fuente de informacin para las mediciones de
software de proceso de solicitud de cambio Configuracin del software de gestin de 6-
15
(vase un flujo tpico de un proceso de
solicitud de cambio en la figura 6.3)
proporciona procedimientos formales para la
presentacin y el registro de las solicitudes de
cambio, evaluar el costo TiAl poten- y el
impacto de un cambio propuesto, y aceptar,
modificar, difiriendo, o rechazar el cambio
propuesto. Una solicitud de cambio (CR) es
una peticin para expandir o reducir el alcance
del proyecto; modificar las polticas, procesos,
planes o procedimientos; modificar los costos o
presupuestos; o horarios Revisar [1]. Las
solicitudes de cambios en el software artculos
con- figuracin pueden ser originados por
cualquier persona en cualquier momento del
ciclo de vida del software y pueden incluir una
propuesta de solucin y la prioridad solicitada.
Una fuente de un CR es el inicio de una accin
correctiva en respuesta a los informes de
problemas. Independientemente de la fuente, el
tipo de cambio (por ejemplo, defecto o mejora)
que se registra en el CR Software (SCR).
Esto proporciona una oportunidad para el
seguimiento de defectos y la recoleccin de las
mediciones por tipo de actividad el cambio
cambio. Una vez que se recibe una SCR, una
evaluacin tcnica (tambin conocido como un
anlisis de impacto) se lleva a cabo para
determinar la extensin de las modificaciones
que seran necesarias se debe aceptar la
solicitud de cambio. Una buena comprensin
de las relaciones entre el software (y,
posiblemente, el hardware) elementos es
importante para esta tarea. Por ltimo, una
autoridad realiz medicin-com- establecida
con la lnea de base afectada, el SCI
involucrados, y la naturaleza del cambio
evaluar los aspectos tcnicos y de gestin de
la solicitud de cambio y, o bien aceptar,
modificar, rechazar o posponer el cambio
propuesto.
6-16 Gua SWEBOK V3.0

Figura 6.3. Flujo de un proceso de control de cambios

3.1.1. Junta de Control de Configuracin de

Software Una solicitud de cambio de software eficaz (SCR)
[2 *, c9s2.2] [3 *, c11s1] [4 *, proceso requiere el uso de herramientas de apoyo
c29s2] y procedi- mientos para originar las solicitudes de
cambio, enforc- ing el flujo del proceso de
La autoridad para aceptar o rechazar los cambios cambio, la captura
propuestos se apoya con una entidad tpicamente
conocida como un tablero de control de
configuracin (CCB). En proyectos ms
pequeos, esta autoridad puede residir de
manera efectiva con el lder o una persona
asignada en lugar de una tabla con varias
personas. Puede haber varios niveles de
autoridad cambian dependiendo de una variedad
de terios teria, tales como el carcter crtico del
tema planteado y la naturaleza del cambio (por
ejemplo, impacto en el presupuesto y el
calendario), o punto actual del proyecto en la
vida ciclo. La composicin de los CCBs se
utilizan para un sistema dado vara en funcin de
estos criterios (un representante SCM siempre
estara presente). Todos los interesados, de
acuerdo al nivel de la CCB, estn representados.
Cuando el alcance de la autoridad de un CCB es
estrictamente cermica blandas, que se conoce
como una Junta de Control de Configuracin de
Software (SCCE). Las actividades de la CCB
son tpicamente sujetos a auditora o revisin de
calidad del software.

3.1.2. Software Proceso de Solicitud de

Cambio
[3 *, c1s4,
c8s4]
 Configuracin del software de gestin de 6-
decisiones CCB, y la informacin del proceso 17
de cambio que se informa. Un vnculo entre
esta capacidad de la herramienta y el sistema
de reporte de problema puede facilitar el
seguimiento de soluciones para problemas
detectados.

3.2. Cambios en el software de aplicacin

[4 *, c29]

SCRs aprobados se implementan utilizando los

procedimientos de software definidos de
acuerdo con los requisitos de programacin
aplicables. Puesto que un nmero de SCRs
aprobados podra implementarse de forma
simultnea, es necesario proporcionar un
medio para el seguimiento que SCRs se
incorporan en las versiones de software
particulares y lneas de base. Como parte del
cierre del proceso de cambio, cambios plet
com- pueden someterse a auditoras de
configuracin y la calidad del software de
verificacin-Esto incluye garantizar que se han
realizado cambios aprobados. El proceso de
solicitud de cambio de software descrito
anteriormente por lo general documentar el
SMC (y otra) informacin de aprobacin para
el cambio.
Los cambios pueden ser apoyadas por
herramientas de control de cdigo fuente sin
ver-. Estas herramientas permiten a un equipo
de ingenieros de software, o un solo ingeniero
de software, para realizar un seguimiento y
documentar los cambios en el cdigo fuente.
Estas herramientas proporcionan un nico
repositorio para almacenar el cdigo fuente,
puede evitar ms de un ingeniero de soft- ware
de la edicin del mismo mdulo, al mismo
tiempo, y registrar todos los cambios
realizados en el
6-18 Gua SWEBOK V3.0

cdigo fuente. Los ingenieros de software de sistema de informacin, la informacin de

verificacin mdulos del repositorio, hacer estado de configuracin para ser administrado
cambios, documentar los cambios, a por los las configuraciones cambiantes deben ser
continuacin, guarde los mdulos editados en el identificados, recogidos, y mantenido. Diversa
repositorio. Si es necesario, los cambios tambin informacin y las mediciones son necesarias
pueden ser descartados, la restauracin de una para apoyar el proceso de SMC y para cumplir
lnea de base anterior. herramientas ms potentes con el estado de con- figuracin necesidades de
pueden apoyar el desarrollo paralelo y entornos informacin de gestin, ingeniera de software, y
distribuidos geogrficamente. Estas otras actividades relacionadas. Los tipos de
herramientas se pueden manifestar como informacin disponibles incluyen la
aplicaciones independientes, especializados bajo identificacin de la configuracin aprobada, as
el control de un grupo independiente SMC. como la identificacin y tus implementacin
Tambin pueden aparecer como una parte actual de esta- cambios, desviaciones, y las
integrada del entorno de la ingeniera de renuncias.
software. Por ltimo, pueden ser tan elemental Alguna forma de soporte de la herramienta
como un sistema de control de cambios automatizada es preciso proceder para llevar a
rudimentaria provisto de un sistema operativo. cabo la recogida de datos SCSA y tareas de
informes; esto podra ser una capacidad de base
3.3. Desviaciones y renuncias de datos, una herramienta independiente, o una
[1, c3] capacidad de un entorno de herramientas ms
amplio e integrado.
Las limitaciones impuestas a un software
Engineer- esfuerzo ing o las especificaciones 4.2. Informes de estado de configuracin de
que se producen durante las actividades de software
desarrollo podra contener disposiciones que no [2 *, c10s2.4] [3 *, c1s5, c9s1, c17]
pueden ser satisfechas en el punto designado en
el ciclo de vida. Una desviacin es un rizacin informacin reportada puede ser utilizado por
autori- escrita, otorgada con anterioridad a la varios elementos, incluyendo los proyectos de
fabricacin de un elemento, para apartarse de organizacin y el equipo de desarrollo, el equipo
una actuacin en particular o requisito de diseo de mantenimiento, gestin de proyectos, y la
para un nmero determinado de unidades o un calidad del software activi- dades. Informes
perodo especfico de tiempo. Una renuncia es pueden tomar la forma de Que- hoc Ries
un diez autorizacin ESCRITO para aceptar un anuncios para responder a preguntas especficas
elemento de configuracin o de otro elemento o la produccin peridica de informes
designado que se encuentra, durante la produc- prediseados. Algunos infor- macin producida
cin o despus de haber sido presentado para su por la actividad contable de estado durante el
inspeccin, a apartarse de los requisitos curso del ciclo de vida podra convertirse en los
especificados, pero se considera ertheless nev- registros de control de calidad.
adecuado para uso como-es o despus de la Adems de informar el estado actual de la
reanudacin por un mtodo aprobado. En estos configuracin, la informacin obtenida por el
casos, un proceso formal se utiliza para obtener SCSA puede servir como base de diversas
la aprobacin de las desviaciones de las mediciones. Los ejemplos incluyen el nmero de
renuncias, o de, las disposiciones. solicitudes de cambio por SCI y el tiempo medio
necesario para ejecutar una solicitud de cambio.
4. El software de contabilidad de estado de
configuracin 5. Auditora de configuracin de software
[2 *, c10]
gestionar una configuracin efectiva.
Software de contabilidad estado de
configuracin (SCSA) es un elemento de gestin 4.1. Software de informacin de estado de
de la configuracin sisting con- del registro y la configuracin
notificacin de la informa- cin necesaria para [2 *, c10s2.1]
Los diseos de actividad SCSA y opera un sis- Configuracin del software
[2 *,dec11]
gestin de 6-
19
tema para la captura y presentacin de la
informacin necesaria a medida que avanza el Una auditora de software es una examina- cin
ciclo de vida. Como en cualquier independiente de un producto de trabajo o
conjunto de productos de trabajo para evaluar el
cumplimiento de las especificaciones, normas,
acuerdos contractuales, u otros criterios [1]. Las
auditoras se llevaron a cabo de acuerdo con un
proceso bien definido que consiste en diversas
funciones y responsabilidades auditor. En
consecuencia, cada auditora debe ser
cuidadosamente planificado. Una auditora
puede requerir un n- mero de personas para
realizar una variedad de tareas durante un
perodo relativamente corto de tiempo.
Herramientas de apoyo
 Configuracin del software de gestin de 6-
11

la planificacin y realizacin de una auditora desarrollo.

pueden facilitar enormemente el proceso.
auditora de configuracin software determina 6. Gestin de la Entrega de Software y
el grado en que un elemento satisface las Entrega
caractersticas funcionales y fsicas requeridas. [2 *, c14] [3 *, c8s2]
auditoras informal de este tipo puede llevarse a
cabo en puntos clave del ciclo de vida. Hay dos En este contexto, la liberacin se refiere a la
tipos de auditoras formales podran ser distribu- cin de un elemento de configuracin de
requeridos por el contrato que rige (por ejem- software fuera
plo, en los contratos que cubren software
crtico): la Auditora funcional de configuracin
(FCA) y la configuracin de auditora fsica
(PCA). La conclusin con xito de estas
auditoras puede ser un requisito previo para el
establecimiento de la lnea base del producto.

5.1. Software de Auditora de Configuracin

Funcional
[2 *, c11s2.1]

El propsito de la FCA software es para

asegurar que el elemento de software auditado es
consistente con sus especificaciones de
gobierno. La salida de las mercancas de las
actividades de verificacin y validacin blandos
(vase Verificacin y validacin en el software
de cali- dad KA) es un insumo clave para esta
auditora.

5.2. Auditora de Configuracin fsica de

software
[2 *, c11s2.2]

El propsito de la auditora de software guracin

fsica cin (PCA) es asegurar que la
documentacin de proyectos y de referencia es
consistente con el producto de software como
incorporado.

5.3. En-Proceso de Auditoras de una lnea de

base del software
[2 *, c11s2.3]

Como se mencion anteriormente, las auditoras

pueden ser llevadas a cabo durante el proceso de
desarrollo para investigar el estado actual de los
elementos especficos de la con- figuracin. En
este caso, una auditora se podra aplicar a los
elementos de lnea de base de la muestra para
asegurar que per- formance es consistente con
las especificaciones o para asegurar que la
documentacin evolucin sigue siendo
compatible con el elemento de referencia en
6-12 Gua SWEBOK V3.0 software proporcionan esta capacidad. Estas
la actividad de desarrollo; esto incluye
comunicados internos, as como la distribucin herramientas varan en complejidad desde que
a los clientes. Cuando diferentes versiones de requiere el ingeniero de software para aprender
un elemento de software estn disponibles para un lenguaje de script espe- cializada a los
la entrega (tales como versiones para diferentes enfoques orientados a grficos que ocultan gran
formas plataformas o versiones con diferentes parte de la complejidad de una instalacin de
capacidades), frecuentemente es necesario acumulacin inteligente.
volver a crear versiones especficas y El proceso de construccin y los productos
empaquetar los materiales adecuados para la son a menudo sub- ject de verificacin de la
entrega de la versin. La biblioteca de software calidad del software. Las salidas de
es un elemento clave en la realizacin de tareas
de liberacin y entrega.

6.1. Edificio de software

[4 *,
c29s4]

Software edificio es la actividad de la

combinacin de las versiones correctas de los
elementos de configuracin de software,
utilizando los datos de configuracin
apropiados, en un programa ejecutable para la
entrega a un cliente u otro receptor, tal como la
actividad de pruebas. Para sistemas con
hardware o firmware, el programa ejecutable
se entrega a la activi- dad de la capacidad del
sistema. Construir instrucciones de asegurar
que las medidas adecuadas de construccin se
toman en la secuencia correcta. Adems de la
creacin de software para los nuevos
lanzamientos, por lo general es tambin
necesaria para SMC para tener la capacidad de
reproducir versiones anteriores para la
recuperacin, pruebas, mantenimiento, o para
fines de liberacin adicionales.
El software se construye a partir de versiones
particulares de herramientas de apoyo, tales
como compiladores (vase Fundamentos Piler
Com- en los Fundamentos de Informtica KA).
Puede ser que sea necesario reconstruir una
copia exacta de un elemento de configuracin
de software previamente construida. En este
caso, las herramientas de apoyo y las
instrucciones de construccin asociados deben
estar bajo el control de SMC para garantizar la
disponibilidad de las versiones correctas de las
herramientas.
Una capacidad de herramienta es til para la
seleccin de las versiones rect angulares del
elementos de software para un entorno de
destino dado y para automatizar el proceso de
construccin del software de las versiones
seleccionadas y datos de configuracin
apropiados. Para proyectos con am- bientes
desarrollo paralelos o distribuidos, esta
capacidad herramienta es necesaria. La
mayora de los entornos de ingeniera de
 Configuracin del software de gestin de 6-
13

el proceso de construccin podra ser necesaria 7. Las herramientas de Software

para futuras referencias y puede convertirse en [3 *, c26s1] [4 *,
los registros de control de calidad. c8s2]

6.2. Gestin de la Entrega de Cuando se habla de herramientas Ment manage-

Software [4 *, c29s3.2] de configuracin de software, es til para
clasificarlos. herramientas de SCM se pueden
dividir en tres clases en trminos
gestin de versiones de software abarca la contenidos de liberacin de los SCR que se han
identificacin, el empaquetado, y la entrega de recibido. Esta capacidad herramienta tambin
los elementos de un ejemplo de producto-para, puede mantener informacin sobre diversas
un programa capaz execut-, documentacin, plataformas de destino y en diversos entornos de
notas de la versin, y datos de configuracin. clientes.
Teniendo en cuenta que los cambios de producto
pueden producirse de manera continua, una
preocupacin por la gestin de la liberacin es
determinar cundo deben emitir un comunicado.
La gravedad de los problemas abordados por la
liberacin y la medicin de la falla den- sidades
de las versiones anteriores afectan a esta
decisin. La tarea de envasado debe identificar
qu producto artculos son para ser entregados y
luego seleccione las variantes correctas de esos
elementos, dada la aplica- cin previsto del
producto. La informacin documento- ing el
contenido fsico de un comunicado se conoce
como un documento de descripcin de la
versin. Las notas de la versin describen
tpicamente nuevas capacidades, problemas
conocidos y requisitos de plataforma necesarios
para el funcionamiento adecuado del producto.
El paquete que se lanzar tambin contiene
instrucciones de instalacin o actualizacin. Este
ltimo puede ser complicado por el hecho de
que algunos usuarios actuales podran tener
versiones que son varias las viejas versiones. En
algunos casos, la administracin de liberacin
puede ser necesario con el fin de realizar un
seguimiento de la distribucin del producto a
varios clientes o Sistemas de destino, por
ejemplo, en un caso donde se requiere el
proveedor para notificar a un cliente de los
problemas recin denunciados. Por ltimo, un
mecanismo para asegurar la integridad del
artculo publicado se puede implementar, por
ejemplo mediante la liberacin de una firma
digital con l.
Se necesita una capacidad de herramienta
para apoyar estas funciones de gestin de
versiones. Se uso-ful tener una relacin con la
capacidad de herramienta de apoyo al proceso de
solicitud de cambio con el fin de asignar los
6-14 Gua SWEBOK
del mbito V3.0 a
de aplicacin la que proporcionan
apoyo: el apoyo vidual indicacin, el apoyo
relacionada con el proyecto, y el apoyo-
proceso panywide com-.
herramientas de apoyo individual son
apropiadas y por lo general suficiente para
organizaciones o grupos de desarrollo de
pequeas y sin variantes de sus productos de
software u otras exigencias SCM compleja.
Incluyen:

herramientas de control de versiones:

pista, documentar y almacenar elementos
de configuracin individuales como el
cdigo fuente y la documentacin externa.
Construir herramientas de manipulacin:
en su forma ms simple, este tipo de
herramientas de compilacin y enlace para
una versin ejecutable del software. Ms
herramientas avanzadas de construccin
extracto de la ltima versin del software
de control de versiones, realizar
comprobaciones de cali- dad, ejecutar
pruebas de regresin, y producir diversos
tipos de informes, entre otras tareas.
Cambiar las herramientas de control: sobre
todo apoyar el control de las solicitudes de
cambio y eventos noti- ficacin (por
ejemplo, cambios en el estado de solicitud
de cambio, los hitos alcanzados).

herramientas de apoyo relacionados con el

proyecto principal respaldar la gestin del
espacio de trabajo para los equipos e
integradores de desarrollo; por lo general son
capaces de apo- entornos de desarrollo de
puertos distribuido. Tales herramientas son
apropiadas para medianas y grandes organiza-
ciones con las variantes de sus productos de
software y desarrollo paralelo pero no hay
requisitos de certificacin.
herramientas de apoyo en procesos de toda
la compaa puede Tpicamente automatizar
partes de un pro- ceso de toda la compaa,
proporcionando soporte para mentos de flujo
de trabajo manage-, roles y responsabilidades.
Ellos son capaces de manejar muchos artculos,
datos y ciclos de vida. Estas herramientas se
suman el apoyo relacionados con el proyecto
mediante el apoyo a un proceso de desarrollo
ms formal, incluyendo los requisitos de
certificacin.
 Configuracin del software de gestin de 6-
15

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

2011 [4 *]
2012 [2

2006 [5
Hass 2003

SommervilLe
yoEEE 828-

[3 *]

Mugirre
*]

*]
1. Gestin del Proceso de SMC

1.1. Contexto de organizacin de

c6, ann.D Introduccin c29
SMC
1.2. Limitaciones y c6, ann.D,
c2 c19s2.2 introduccin
orientacin para el proceso Ana
c29
SMC c6, ann.D,
1.3. La planificacin de SMC c23 c29
Ana
1.3.1. Organizacin y SMC
ann.Ds5-6 c10-11 introduccin
Responsabilidades
c29
1.3.2. Recursos y SCM
ann.Ds8 c23
horarios
1.3.3. Seleccin de
c26s2; s6 c29s5
herramientas y
Implementacin
1.3.4. Vendedor / Control de
c13 c13s9-c14s2
Subcontratista
1.3.5. control de interfaz c12 c24s4
1.4. plan de SMC ann.D c23 c29s1
1.5. La vigilancia de software
c11s3
Gestin de la configuracin
1.5.1. Medidas SCMy c9s2;
Medicin c25s2-s3
1.5.2. En-Proceso de
C1S1
Auditoras de SMC
Identificacin 2.
c29s1.1
Configuracin del
software
2.1. La identificacin de
c8s2.2 c29s1.1
elementos que se van
Revisado
2.1.1. Configuracin del
software
2.1.2. SoftwareElemento de
c29s1.1
configuracin
2.1.3. SoftwareRelaciones
c7s4
entre los elementos de
configuracin
2.1.4. Versin del software c29s3
6-16 Gua SWEBOK V3.0

2011 [4 *]
2012 [2

2006 [5
Hass 2003

SommervilLe
yoEEE 828-

[3 *]

Mugirre
*]

*]
2.1.5. Base
2.1.6. Software de
c18
adquisicin de
Elementos
2.2. softwarede configuracin
Library c1s3 c29s1.2
3. Configuracin del software
C9 c29s2
Controlar
3.1. Solicitar, evaluar,Los
c9s2.4 c29s2
cambios que aprueba y
Software
3.1.1. Configuracin del
c9s2.2 c11s1 c29s2
software
Tabla de control
3.1.2. Software Proceso
c1s4, c8s4
de Solicitud de Cambio
3.2. La implementacin de
c29
software
cambios
3.3. Desviaciones y renuncias
4. Configuracin de Software
c10
Determinacin del estado de
4.1. SoftwareInformacin de
c10s2.1
estado de configuracin
4.2. Configuracin del c1s5, c9s1,
c10s2.4
software c17
5. Informes de estado
Configuracin del software
c11
Revisin de cuentas
5.1. software funcional
c11s2.1
Auditora de configuracin
5.2. software fsica
c11s2.2
Auditora de configuracin
5.3. En-Proceso de auditoras
c11s2.3
de una
6. Lnea de basededel software
El software
c14 c8s2 c29s3
administracin de
lanzamientos
6.1. EdificioydeEntrega
software c29s4
6.2. Lanzamiento de software
c29s3.2
administracin
7. Configuracin del software
c26s1
Herramientas administrativas
 Configuracin del software de gestin de 6-
17

LECTURAS Referencias

Stephen P. Berczuk y Brad Appleton, Patrones [1] ISO / IEC / IEEE 24765: 2010 Sistemas y de
de Gestin de la Configuracin de Ingeniera de Software-Vocabulario, ISO /
Software: El trabajo en equipo eficaz, IEC / IEEE 2010.
prctica Integracin [6].
[2 *] IEEE Std. 828-2012, Norma para Sistemas
Este libro expresa prcticas de SCM y de Gestin de la Configuracin de Software
estrategias tiles como patrones. Los patrones e Ingeniera, IEEE 2012.
pueden ser implementado utilizando diversas
herramientas, sino que se expresa de una manera [3 *] AMJ Hass, Principios y Prcticas de
independiente del instrumento. gestin de configuracin, 1st ed., Addison-
Wesley, 2003.
CMMI para el Desarrollo, versin 1.3, pp.
137-147 [7]. [4 *] I. Sommerville, Ingeniera de Software, 9
ed., Addison-Wesley, 2011.
Este modelo presenta una recopilacin de las
mejores ticas ticas para ayudar a las [5 *] JW Moore, La Hoja de Ruta de Ingeniera
organizaciones de desarrollo de software a de Software: Una gua basada en
mejorar sus procesos. En el nivel de madurez 2, estndares, Wiley-IEEE Computer Society
sugiere actividades de gestin de configuracin. Press, 2006.

[6] SP Berczuk y B. Appleton, Patrones de

Gestin de la Configuracin del Software:
El trabajo en equipo, la integracin
prctica, Addison-Wesley Professional,
2003.

[7] CMMI equipo de productos, CMMI para

el Desarrollo, Versin 1.3, Software
Engineering Institute, 2010; http: //
resources.sei.cmu.edu/library/asset-view.
cfm? assetId = 9661.
6-18 Gua SWEBOK V3.0

CAPTULO 7

GESTIN DE INGENIERA DE SOFTWARE

SWX.
SIGLAS

PMBOK Gua para la Direccin de Proyectos

Gua del Conocimiento
SDLC Ciclo de vida del desarrollo de
SEM programas
Gestin de Ingeniera de Software
SQA Calidad de Software
Extensin de software para el
SWX
PMBOK
WBS Gua
Estructura de desglose del trabajo

INTRODUCCIN

la gestin de la ingeniera de software se puede

definir como la aplicacin de gestin de las
actividades de planificacin, coordinacin,
medicin, monitoreo, pesca de arrastre con- y
informes1-para asegurar que los productos de
software y servicios de ingeniera de software se
entregan de manera eficiente, efectiva y en
beneficio de grupos de inters. La disciplina
relacionada tienen una gestin es un elemento
importante de todas las reas de conocimiento
(KAS), pero por supuesto es ms relevante para
este KA que a otros KAs. La medicin es
tambin un aspecto importante de todos los
KAs; el tema de los programas La medicin se
presenta en este KA.
En un sentido, debera ser posible para
gestionar un proyecto de ingeniera de software
de la misma manera se gestionan otras
actividades complejas. Sin embargo, hay
aspectos especficos de los proyectos de
software y procesos del ciclo de vida del
software que complican la gestin eficaz,
incluyendo los siguientes:

1 Los trminos inicio, planificacin, ejecucin,

seguimiento y control, y de cierre se utiliza para
describir grupos de proceso en el PMBOK Gua y
 A menudo hay una rpida tasa de cambio en
Los clientes a menudo no saben lo que se la tecnologa subyacente.
necesita o lo que es factible.
Los clientes a menudo carecen de actividades de gestin de la ingeniera de
reconocimiento por las complejidades software se producen en tres niveles: gestin de
inherentes a la ingeniera de software, en la organizacin y estructura de infraestructura,
particular sobre el impacto de los gestin de proyectos y gestin del programa de
requisitos de ING cam- bios. medicin. Los dos ltimos se tratan en detalle en
Es probable que el aumento de la esta descripcin KA. Sin embargo, esto no es
comprensin y las condiciones cambiantes para disminuir la importancia de los problemas
generarn requisitos nuevos o modificados de gestin de la organizacin y de
de software. infraestructura. En general se acepta que los
Como resultado de cambios en los gerentes de ingeniera de software de
requisitos, soft- ware se construye a organizacin deben estar familiarizados con el
menudo usando un proceso iterativo en proyecto manage- ment conocimiento y la
lugar de como una secuencia de tareas medicin del software descrito en este KA.
cerradas. Tambin deben poseer algunos conocimientos de
La ingeniera de software incorpora dominio de destino. Del mismo modo, tambin
necesariamente las tasas de creatividad y es til si los gerentes de proyectos y programas
disciplina. El mantenimiento de un complejos en los que el software es un
equilibrio adecuado entre los dos es a componente de la arquitectura del sistema son
veces difcil. conscientes de las diferencias que los procesos
El grado de novedad y complejidad es a de software introducen en la gestin de
menudo alta. proyectos y la medicin del proyecto.

7-1
7-2 Gua SWEBOK V3.0

Figura 7.1. Desglose de temas para la Ingeniera de Software de Gestin de KA

Otros aspectos de la gestin de las analizar los resultados anteriores pro- yecto e
organizaciones ejercen un impacto en la implementar mejoras).
ingeniera de software (por ejemplo, polticas de
la organizacin y los procedimientos que
constituyen el marco en el que se llevan a cabo
proyectos de ingeniera de software). Estas
normativas y procedimientos de pueden
necesitar ser ajustado por los requisitos de
software eficaz Desa-, crear y mantener.
Adems, una serie de polticas especficas para
la ingeniera de software puede necesitar estar en
su lugar o establecido para la gestin eficaz de la
ingeniera de software a nivel nizational or-. Por
ejemplo, las polticas son generalmente
necesarios para establecer procesos de toda la
organizacin o procedimientos especficos para
tareas de ingeniera de software, tales como
diseo de software, software de construc- cin,
la estimacin, el seguimiento y la presentacin
de informes. Este tipo de polticas son
importantes para la gestin efectiva a largo plazo
de los proyectos de ingeniera de software en
toda la organizacin (por ejemplo, el
establecimiento de una base constante por el que
 Ingeniera de Software de Gestin de 7-3
Otro aspecto importante de la gestin de la
organizacin son las polticas y procedimientos
de gestin de personal para la contratacin,
capacitacin y mentor personal ing para el
desarrollo profesional, no slo a nivel de
proyecto, sino tambin a la Cess Suc a ms
largo plazo de una organizacin. el personal de
ingeniera de software pueden presentar retos
de formacin o gestin de personal nico (por
ejemplo, el mantenimiento de la moneda en un
contexto donde la tecno- loga subyacente sufre
un cambio rpido y continuo).
gestin de la comunicacin tambin se
menciona a menudo como un aspecto pasado
por alto pero importante del rendimiento de las
personas en un campo en el que es necesaria la
comprensin precisa de las necesidades del
usuario, requisitos de software y diseos de
software. Por otra parte, la gestin de carteras,
que pro- porciona una visin de conjunto, no
slo de software actualmente en fase de
desarrollo en diversos proyectos y programas
(proyectos integrados), sino tambin de
software previstas y actualmente en uso en una
organiza- cin, se deseable. Adems, la
reutilizacin de software es la clave
7-4 Gua SWEBOK V3.0

factor en el mantenimiento y la mejora de la Por desgracia, una percepcin comn de la

productividad y la competitividad. reutilizacin industria del software es que los productos de
efectiva requiere una visin estratgica que software se Ered deliv- tarde, por encima del
refleja las ventajas y desventajas de presupuesto, de mala calidad y con una
reutilizacin. funcionalidad incompleta. La medicin-informada
Adems de comprender los aspectos de
gestin que son influenciados de forma nica
por los proyectos de software, ingenieros de
software deben tener algn conocimiento de los
aspectos ms generales de gestin que se tratan
en este KA (incluso en los primeros aos
despus de la graduacin).
Los atributos de la cultura organizacional y el
comporta- miento, adems de la gestin de otras
reas funcionales de la empresa, tienen una
influencia, aunque sea indirectamente, en los
procesos de ingeniera de software de una
organizacin.
Extensa informacin relativa a la gestin de
proyectos de software se puede encontrar en la
Gua para la Direccin de Proyectos del
Conocimiento (Gua del PMBOK) y el
software de la extensin de la Gua PMBOK
(SWX) [1] [2]. Cada una de estas guas incluye
KAs diez proyectos de gestin: gestin de la
integracin de proyectos, gestin del alcance del
proyecto, gestin del tiempo, gestin de
proyectos, el costo del proyecto de gestin de
calidad de proyectos, gestin de recursos
humanos, gestin de proyectos comunicaciones
del proyecto, la gestin de riesgos de proyectos,
gestin de proyectos y adquisiciones gestin de
los interesados del proyecto. Cada KA tiene
relacin directa con esta Ingeniera de Software
de Gestin de KA.
La informacin adicional tambin se
proporciona en las otras referencias y otras
lecturas de este KA. Este Ingeniera de Software
de Gestin de KA se compone de los cesos de
gestin de proyectos de software pro en los
primeros cinco temas en la Figura 7.1 (Initiative
cin y definicin del alcance, Software Proyecto
planificacin, proyecto de software
promulgacin, revisin y evaluacin, de cierre),
adems de Ingeniera de Software medicin en el
sexto tema y herramientas de software de gestin
de ingeniera en el sptimo tema. Si bien la
gestin de proyectos y gestin de medi- cin a
menudo se considera una unidad independiente, y
de hecho cada s posee muchos atributos nicos,
la estrecha relacin que ha dado lugar a
tratamiento combinado en este KA.
 Ingeniera de Software de Gestin de 7-5
-gestin de un principio bsico de cualquier
verdadera disciplina inge- niera (ver Medicin
de las fundaciones inge- niera KA) -pueden
ayudar a mejorar la percepcin y la realidad.
En esencia, la gestin sin medicin (cualitativa
y cuantitativa) sugiere una falta de disciplina, y
la medicin sin gestin sugiere una falta de
propsito o contexto. La gestin eficaz requiere
una combinacin de ambos medicin y
experiencia.
Las siguientes definiciones de trabajo se
adoptan aqu:

administracin es un sistema de procesos y

controles necesarios para lograr los
objetivos estratgicos fijados por la
organizacin.
Medicin se refiere a la asignacin de los
UE Val- y etiquetas a los productos de
trabajo de ingeniera de software, los
procesos y los recursos ms los modelos
que se derivan de ellos, si estos modelos
son desarrollados usando tcnicas
estadsticas u otras [3 *, C7, C8].

Las secciones de gestin de proyectos de

ingeniera de software en este KA hacen un
amplio uso de la seccin de medicin de la
ingeniera de software.
Esta KA est estrechamente relacionado con
otros en la Gua SWEBOK, y la lectura de las
siguientes descripciones KA en conjuncin con
ste ser particularmente til:

El Fundamentos de Ingeniera KA describe

algunos conceptos generales de medicin
que son aplicables directamente a la
seccin de ingeniera de software de
medicin de este KA. Adems, los
conceptos y tcnicas presentados en la
seccin Anlisis estadstico de los
Fundamentos de Ingeniera KA se aplican
directamente a muchos temas en este KA.
Los requisitos de software KA se
describen algunas de las actividades que
deben ser formados per- durante la fase
Volumen defini- cin Iniciacin y del
proyecto.
El software de configuracin de
administracin de KA se ocupa de la
identificacin, el control, el registro del
estado, y la auditora de software de con-
figuraciones junto con la administracin de
la versin de software y herramientas de
administracin y gestin de software de
configu- racin.
7-6 Gua SWEBOK V3.0

El Proceso de Ingeniera de Software KA son satisfactorios;

describe los modelos del ciclo de vida del Cierre, que se ocupa de las actividades
software y las relaciones entre los procesos logrado completar un proyecto;
y productos de trabajo. Ingeniera de Software de medicin, el cual
La calidad del software KA hace hincapi se ocupa del desarrollo eficaz y
en cali- dad como un objetivo de la gestin
y como un objetivo de muchas actividades
de ingeniera de software.
La Ingeniera de Software Economa KA
discute cmo tomar decisiones relacionadas
con el software en un contexto empresarial.

DISTRIBUCIN DE TEMAS PARA LA

GESTIN DE INGENIERA DE
SOFTWARE

Debido a que la mayora de los modelos de ciclo

de vida del software de desarrollo requieren
actividades similares que puedan ser eje- cuta de
diferentes maneras, el desglose de los temas es
basado en la actividad. Esa ruptura se muestra en
la Figura 7.1. Los elementos del Break-nivel
superior mostrado en esa figura son las
actividades que se realizan por lo general cuando
se est gestionando un proyecto de desarrollo de
software, independiente del modelo de ciclo de
vida de desarrollo de software (ver Software
Modelos de Ciclo de Vida de la Ingeniera de
Software proceso KA) que ha sido elegido para
un proyecto especfico. No hay intencin en esta
averiado para recomendar un modelo especfico
del ciclo de vida. El desglose implica slo lo que
sucede y no implica cundo, cmo, o cuntas
veces se produce cada actividad. Los siete temas
son:

Iniciacin y definicin del alcance, que se

refieren a la decisin de embarcarse en un
proyecto de ingeniera de software;
Software de planificacin, que se ocupa de
las actividades llevadas a cabo para preparar
un proyecto de ingeniera de software
exitoso desde el punto de vista de gestin;
Proyecto de software Promulgacin, que se
ocupa de las actividades de gestin de la
ingeniera de software generalmente
aceptados que se producen durante la
ejecucin de un proyecto de ingeniera de
software;
Revisin y evaluacin, que tratan de
garantizar que, horario, costo, y las
actividades de ingeniera tcnica de calidad
 Ingeniera
estimaciones aproximadas de Software
de esfuerzo y de
el Gestin
coste de 7-7
implementacin de programas de medicin en
organizaciones de ingeniera de software; sobre la base de mtodos apropiados (vase la
Herramientas de software de gestin de seccin 2.3, Esfuerzo, Schedule, y el coste de
ingeniera, que describe la seleccin y el estimacin).
uso de herramientas para la gestin de un
proyecto de ingeniera de software.

1. Iniciacin y Definicin del Alcance

El objetivo de estas actividades es de

determinacin eficaz de los requisitos de
software utilizando mtodos de obtencin
variabilidad ous y la evaluacin de la
viabilidad del proyecto a partir de una variedad
de puntos de vista. Una vez que se ha
establecido la viabilidad del proyecto, las
tareas restantes en esta seccin son los ficacin
speci- de los requisitos y seleccin de los pro-
cesos de revisin y revisin de requisitos.

1.1. La determinacin y la
negociacin de los requisitos
[3 *, c3]

Determinar y est llevando a cabo los

requisitos establecidos de negociacin de los
lmites visibles para el conjunto de tareas (ver
los requisitos de software KA). Las actividades
incluyen la obtencin de requisitos, anli- sis,
especificacin y validacin. Mtodos y
tcnicas deben ser seleccionadas y aplicadas,
teniendo en cuenta las diversas perspectivas de
los interesados. Esto lleva a la determinacin
del alcance del proyecto con el fin de cumplir
con los objetivos y satisfacer las restricciones.

1.2. Anlisis de viabilidad

[4 *, c4]

El propsito del anlisis de viabilidad es el

desarrollo de una descripcin clara de los
objetivos del proyecto y eva- comi enfoques
alternativos con el fin de determinar si el
proyecto propuesto es la mejor alternativa,
dadas las limitaciones de la tecnologa, los
recursos, las finanzas, y las consideraciones
polticas sociales /. Un proyecto inicial y la
declaracin del alcance del producto, los
entregables del proyecto, las limitaciones de
duracin del proyecto, y una estimacin de los
recursos necesarios deben estar preparados.
Los recursos incluyen un nmero suficiente
de personas que tienen las habilidades
necesarias, las instalaciones, la infraestructura
y el apoyo (ya sea interna o externamente).
Anlisis de viabilidad a menudo requiere
7-8 Gua SWEBOK V3.0

1.3. Proceso para el examen y revisin de 2.1. Planificacin de

los requisitos procesos [3 *, c3, c4, c5] [5 *,
[3 *, c3] c1]
del software, verificacin y validacin, opiniones
Dada la inevitabilidad del cambio, las partes y auditoras (ver la calidad KA software ).
interesadas deben ponerse de acuerdo sobre los Procesos y responsabilidades para la revisin en
medios por los cuales los requisitos y alcance curso y la revisin del plan de proyecto y los
han de ser examinado y revisado (por ejemplo, planes relacionados tambin deben estar
procedimientos de gestin del cambio, claramente establecidos y acordados.
retrospectivas ciclo tivos iteraciones). Esto
implica claramente que el alcance y requisitos
no sern inamovibles, pero pueden y deben ser
revisados en puntos predeter- MINED como se
desarrolla el proyecto (por ejemplo, en el
momento en que se crean las prioridades de
retraso acumulado o al hito comentarios). Si se
aceptan los cambios, entonces algn tipo de
anlisis de trazabilidad y anlisis de riesgos se
debe utilizar para determinar el impacto de esos
cambios (vase la seccin 2.5, Gestin de
Riesgos y Control de Configuracin de Software
en el KA Software Configuration Management).
Un enfoque de cambio administrado tambin
puede formar la base para la evaluacin del xito
durante el cierre de un ciclo incremental o un
proyecto completo, basado en los cambios que
se han producido a lo largo del camino (vase el
tema 5, Cierre).

2. Planificacin de proyectos de software

El primer paso en la planificacin de proyectos

de software debe ser la seleccin de un modelo
de desa- rrollo ciclo de vida del software
apropiado y quiz adaptndola basado en el
alcance del proyecto, los requisitos de software,
y una evaluacin de riesgos. Otros factores que
deben consi- Ered incluir la naturaleza del
dominio de aplicacin, complejidad funcional y
tcnica, y los requisitos de calidad blandos Ware
(ver Requisitos de calidad de software en la
calidad del software KA).
En todos los SDLCs, evaluacin de riesgos
debe ser un elemento de la planificacin inicial
del proyecto, y el perfil de riesgo del proyecto
deben ser discutidos y aceptados por todos los
interesados. procesos de gestin de la calidad del
software (ver Gestin de la Calidad de Software
Procesos en la calidad KA software) deben
determinarse como parte del proceso de
planificacin y dan lugar a procedimientos y
responsabilidades para la garanta de la calidad
Software de ciclo de vida de desarrollo inspeccin, elIngeniera de Software
software de Gestin
probado) debede ser
7-9
(SDLC) els mo- abarcan un continuo que va identificado y caracterizado. Oportunidades para
desde predictivo para adaptable (consulte el la reutilizacin de componentes de software de
software del ciclo de vida Los modelos de la proyec- tos anteriores o para utilizar los
Ingeniera de Procesos de Software KA). productos de software off-the-shelf
SDLCs predictivos se caracterizan por el
desarrollo de los requisitos de soft- ware
detalladas, la planificacin detallada del
proyecto, y planificacin mnima para la
iteracin entre fases de desarrollo. SDLCs
adaptativos estn diseados para adaptarse a
los requisitos de software emergentes y el
ajuste iterativo de planes. A predictiva SDLC
altamente pre- ejecuta los primeros cinco
procesos enumerados en la figura 7.1 en una
secuencia lineal con siones revi- a fases
anteriores slo cuando sea necesario. SDLCs
tivos adaptaciones se caracterizan por ciclos
desa- rrollo iterativos. SDLCs en la gama
media de los incrementos SDLC continuum
producto de funcio- nalidad ya sea en un
horario planificada de antemano (en el lado
predictivo del continuo) o como los pro- ductos
de los ciclos de desarrollo frecuentemente
actualizadas (en el lado de adaptacin del
continuo) .
SDLCs bien conocidos incluyen los modelos
de cascada, incremental y espiral ms diversas
formas de desarrollo gil de software [2] [3 *,
c2].
mtodos pertinentes (vase la Engineer-
Software ing modelos y mtodos KA) y las
herramientas debe ser seleccionado como parte
de la planificacin. Las herramientas
automatizadas que se utilizarn a lo largo del
proyecto tambin se deben planificar y
adquiridas. Las herramientas pueden incluir
herramientas para la programacin de
proyectos, los requisitos de software, diseo de
software, la construccin de software,
mantenimiento de software, gestin de
configuracin de software, proceso de
ingeniera de software, la calidad del software,
y otros. Si bien muchas de estas herramientas
debe seleccionarse con base principalmente en
las consideraciones tcnicas discutidas en otros
Kas, algunos de ellos estn estrechamente
relacionados con las consideraciones Ment
manage- discutidos en este captulo.

2.2. determinar entregables

[3 *, c4, c5,
c6]

El producto (s) de trabajo de cada actividad de

proyecto (por ejemplo, la arquitectura software
docu- mentos de diseo, informes de
7-10 Gua SWEBOK V3.0

deben ser evaluados. Adquisicin de software y as como por las cuestiones relativas al personal
el uso de terceros para desarrollar las (por ejem- plo, la productividad de las personas
prestaciones debe ser planeada y proveedores y los equipos, la dinmica del equipo, y
seleccionados (ver seccin 3.2, Software de estructuras de equipo).
Adquisicin y Gestin de Proveedores de
contrato). 2.5. Gestin de riesgos
[3 *, c9] [5 *, c5]
2.3. Esfuerzo, Calendario, y Estimacin de
Costos Riesgo e incertidumbre estn relacionados pero
[3 *, c6] distintos conceptos. La incertidumbre resulta de
la falta de informa- cin. El riesgo se caracteriza
El rango estimado de esfuerzo requerido para un por la probabilidad de un evento que se traducir
proyecto, o partes de un proyecto, se puede en un impacto negativo adems de una
determinar utilizando un modelo de estimacin caracterizacin de los efectos negativos sobre un
calibrada en base al tamao y esfuerzo datos proyec- ect. El riesgo es a menudo el resultado
histricos (cuando est disponible) y otros de la incertidumbre. Lo contrario de riesgo es la
mtodos pertinentes, tales como el juicio de oportunidad, que se caracterizarse por la
expertos y la analoga. dependencias de tareas se probabilidad de que un evento que tenga se
pueden establecer y oportunidades potenciales puede producir un resultado positivo.
para la realizacin de tareas al mismo tiempo y La gestin del riesgo implica la identificacin
de forma secuencial pueden ser identificados y de factores de riesgo y anlisis de la
documentados mediante un diagrama de Gantt, probabilidad y el impacto poten- cial de cada
por ejem- plo. Para proyectos SDLC predictivos, factor de riesgo, la priorizacin de los factores
el calendario previsto de tareas con tiempos de de riesgo, y el desarrollo de estrategias de
inicio proyectada, ciones durabilidad y el final mitigacin de riesgos para reducir la
de los tiempos se produce normalmente durante probabilidad y minimizar el impacto negativo si
la planificacin. Para proyectos SDLC de un factor de riesgo se convierte en un problema.
adaptacin, una estimacin general de esfuerzo y mtodos de evaluacin de riesgos (por ejemplo,
el horario tpicamente se desarroll a partir de la la opinin de expertos, datos histricos, rboles
comprensin inicial de los requisitos, o, de decisin, y simulaciones de procesos) a veces
alternativamente, las restricciones sobre el se pueden utilizar con el fin de identificar y
esfuerzo global y el calendario puede ser evaluar los factores de riesgo.
especificado y se utiliza para determinar una condiciones de abandono del proyecto
estimacin inicial de la n- mero ciclos y tambin se pueden determinar en este punto de
estimaciones del esfuerzo de iterativos y otros la discusin con todos los interesados. aspectos
recursos asignados a cada ciclo. de software nica de riesgo, tales como la
Recursos necesarios (por ejemplo, personas y tendencia ingenieros de software para aadir
herramientas) pueden traducirse en estimaciones caractersticas que no sean necesarios, o los
de costos. la estimacin inicial de esfuerzo, riesgos relacionados con la naturaleza intangible
horario, y el costo es una actividad iterativa que del software, puede influir en el riesgo hombre-
debe ser negociado y revisado entre las partes agement de un proyecto de software. aten- cin
interesadas afectadas hasta que se alcanza particular, se debe prestar a la gestin de los
consenso sobre los recursos y el tiempo riesgos relacionados con los requisitos de
disponible para la finalizacin del proyecto. calidad de software, tales como la seguridad o la
seguridad (ver la calidad KA Software). La
2.4. Asignacin de recursos gestin del riesgo debe hacerse no slo en el
[3 *, c5, c10, c11] comienzo de un proyecto, sino tambin a
intervalos peridicos a lo largo del ciclo de vida
del proyecto.

Equipos, instalaciones y personas deben incluyendo el catin alo variabilidad

asignarse los que las tareas identificadas, de responsabilidades
para la realizacin de
 Ingeniera de Software de Gestin de 7-
2.6. Gestin de la calidad 11
[3 *, c4] [4 *, c24]
ous elementos de un proyecto y el proyecto en los requisitos de calidad de software deben ser
general. Una matriz que muestra quin es identifi- cado, tal vez en trminos cuantitativos y
responsable de, responsables de, consultado cualitativos, para un proyecto de software y los
sobre, e informado sobre cada una de las tareas productos de trabajo asociados. Los umbrales
se pueden utilizar. La asignacin de recursos se para las mediciones de calidad aceptables deben
basa en, y limitada por la disponibilidad de establecerse para cada requisito de calidad de
recursos y su uso ptimo, como se software basada en las necesidades de las partes
interesadas
7-12 Gua SWEBOK V3.0

y expectativas. Procedimientos relacionados con Las actividades del proyecto deben llevarse a cabo
el software en curso Garanta de Calidad (SQA) en ajustan al plan del proyecto y los planes de
y la mejora de la calidad durante todo el proceso apoyo. Recursos (por ejemplo, personal,
de desarrollo, y para la verificacin y validacin tecnologa y financiacin) son utilizados y
del producto software entregable, tambin deben productos de trabajo (por
especificarse durante la planificacin de la
calidad (por ejemplo, las revisiones e
inspecciones tcnicas o de- mostraciones de
completado funcionalidad, vase la calidad del
software KA).

2.7. Gestin del plan

[3 *, c4]

Para proyectos de software, donde el cambio es

un tacin tivas, los planes deben ser manejados.
Administrar el plan de proyecto por lo tanto
debe ser planificada. Planes y procesos
seleccionados para el desarrollo de software
deben ser controlados de forma sistemtica,
revisados, informaron, y, en su caso, revisada.
Planes asociados a los procesos de apoyo (por
ejem- plo, la documentacin, configuracin de
software agement hombre- y resolucin de
problemas) tambin deberan ser manejadas.
Informes, seguimiento y control de un proyecto
debe encajar dentro de la SDLC seleccionado y
las realidades del proyecto; planes deben tener
en cuenta los diversos artefactos que sern
utilizados para la edad causados por el hombre
del proyecto.

3. La promulgacin del proyecto de software

Durante software del proyecto promulgacin

(tambin conocidos como la ejecucin del
proyecto) los planes se implementan y se
promulgan los procesos incorporados en los
planes. En todo momento, debe haber un
enfoque en el cumplimiento de los procesos
seleccionados SDLC, con una expectativa
primordial que la adhesin dar lugar a la
exitosa satisfaccin de los requisitos de las
partes interesadas y el logro de los objeti- vos
del proyecto. Fundamental para la incorporacin
son las actividades de gestin en curso de
supervisin, control-ling, y generacin de
informes.

3.1. Implementacin de Planes

[4 *, c2]
 Ingeniera
relacionados debe de Software de Gestin
ser continuamente de 7-y
evaluado
ejemplo, diseo de software, cdigo de 13
software y pruebas de software de los casos) se al
generan.

3.2. Software de Adquisicin y Gestin de

Proveedores Contrato
[3 *, c3, c4]

adquisicin de software y contrato de

abastecimiento agement hombre- se ocupa de
los aspectos que intervienen en la contratacin
con clientes del software desa- rrollo
organizacin que adquieren los productos de
trabajo y entregables con los proveedores que
suministran productos o servicios a la
organizacin de ingeniera de software.
Esto puede implicar la seleccin de los tipos
apropiados de contratos, como el precio fijo, el
tiempo y mate- als, de costo ms una cuota fija,
o el costo ms gasto de incentivo. Acuerdos
con clientes y proveedores normalmente, un
especifican camente el alcance del trabajo y los
Ables deliver- e incluyen clusulas tales como
las sanciones de entrega o de no entrega tarda
y acuerdos de propiedad intelectual que
especifican lo que el proveedor o proveedores
estn ofreciendo y lo que el adquirente es pagar
- ing para, adems de lo que ser entregado y
propiedad del adquirente. Para el software est
siendo desarrollado por los proveedores
(internos o externos a la organizacin de
desarrollo de software), los acuerdos com-
comnmente indican los requisitos de calidad
de software para la aceptacin del software
entregado.
Despus de que el acuerdo se ha puesto en
marcha, cution eje- del proyecto de acuerdo
con los trminos del acuerdo debe gestionarse
(vase el captulo 12 de SWX, Gestin de
adquisicin de software, para ms informacin
sobre este tema [2]).

3.3. Implementacin de Proceso de medida

[3 *, c7]

El proceso de medicin debe ser promulgada

Duran- el proyecto de software para asegurar
que se recogen los datos relevantes y tiles (ver
secciones 6.2, planificar el proceso de
medicin, y 6.3, realizar el proceso de
medicin).

3.4. Process monitor

[3 *, c8]

La adhesin al plan del proyecto y planes

7-14 Gua SWEBOK V3.0

intervalos predeterminados. Adems, se deben proyecto (por ejemplo, los requisitos de software
evaluar los productos y los criterios pletion com- especifi- cacin) para dar cabida a eventos no
para cada tarea. Entregables deben ser evaluados previstos y sus implicaciones.
en trminos de sus caractersticas requeridas En algunos casos, el proceso de control puede
(por ejemplo, a travs de las inspecciones o llevar al abandono del proyecto. En todos los
mediante la demostracin de la funcionalidad de casos,
trabajo). gasto esfuerzo, horario de la
adherencia, y los costes hasta la fecha deben ser
analizados, y el uso de recursos examinados. El
perfil de riesgo del proyecto (ver seccin 2.5,
gestin de riesgos) debe ser revisada, y la
adhesin a los requisitos de calidad de software
eva- uated (ver Requisitos de calidad de
software en la calidad del software KA).
Los datos de medicin deben ser analizados
(vase Sta- Anlisis Statistical en los
Fundamentos de Ingeniera KA). El anlisis de
varianza basado en la desviacin de real de los
resultados y valores esperados debe ser
determinado. Esto puede incluir los excesos de
costes, cronograma deslizamiento, u otras
medidas similares. identificacin y anlisis de
los datos de calidad y otra de medicin de
valores atpicos se deben realizar (por ejemplo,
anlisis de defectos; ver Software Medicin de
la Calidad en el Software Quality KA).
exposiciones de riesgo deben ser recalculados
(ver seccin 2.5, Gestin de Riesgos). Estas
actividades pueden permitir la deteccin del
problema e identificacin excepcin basada en
umbrales que se han superado. Los resultados
deben ser reportados cuando se han superado los
umbrales, o segn sea necesario.

3.5. Control de procesos

[3 *, C7,
C8]

Los resultados de las actividades de seguimiento

de proyectos proporcionan la base sobre la cual
se pueden tomar decisiones. En su caso, y
cuando la probabilidad y el impacto de los
factores de riesgo se entienden, se pueden
realizar cambios al proyecto. Esto puede tomar
la forma de accin correctiva (por ejemplo,
volver a probar ciertos componentes de
software); que puede implicar calificacin
incorpora acciones adicionales (por ejemplo, la
decisin de utilizar la creacin de prototipos
para ayudar en software de validacin de los
requisitos; ver Prototipos en los requisitos de
software KA); y / o puede implicar la revisin
del plan del proyecto y otros documentos del
 Ingeniera de
Como en la actividad Software
proceso dedecontrol
Gestin de 7-
procedimientos de gestin de control de 15
configuracin de software y configuracin de anteriormente (vase sec- cin 3.5, Process
software deben ser atendidas (ver el software Control), configuracin de software
de configuracin Hombre- agement KA), las
decisiones deben ser documentados y
comunicados a todas las partes interesadas, los
planes deben ser revisados y revisados cuando
sea necesario, y los datos pertinentes
registrados ( vase la seccin 6.3, Per- formar
el proceso de medicin).

3.6. informes
[3 *, c11]

En especificado y acordado veces, el progreso

hasta la fecha se debe informar, tanto dentro de
la organiza- cin (por ejemplo, a un co- mit de
direccin del proyecto) y para los
colaboradores externos (por ejemplo, clientes o
usuarios). Los informes deben centrarse en las
necesidades de informacin del pblico
objetivo en comparacin con el estado
detallado de informes dentro del equipo del
proyecto.

4. Revisin y Evaluacin

En tiempos pre-especificados y segn sea

necesario, reso general prog- hacia el logro de
los objetivos planteados y la satisfaccin de las
partes interesadas (usuarios y clientes)
requisitos deben ser evaluados. Del mismo
modo, las evaluaciones de la eficacia del
proceso de software, el personal involucrado, y
las herramientas y mtodos empleados tambin
deben llevarse a cabo larmente REG y como
determinados por las circunstancias.

4.1. La determinacin de satisfaccin de los

requisitos
[4 *, c8]

Debido a lograr la satisfaccin de las partes

interesadas es un objetivo principal de la
gerente de ingeniera de software, el progreso
hacia este objetivo debe evaluarse
peridicamente. El progreso debe ser evaluado
en el logro de los principales hitos del proyecto
(por ejemplo, la finalizacin de la arquitectura
de diseo de software o la finalizacin de una
revisin tcnica de software), oa la conclusin
de un ciclo de desarrollo iterativo que se
traduce en un incremento del producto. Las
variaciones de los requisitos de software deben
ser identificados y deben tomarse acciones
Apropiada.
7-16 Gua SWEBOK V3.0

procedimientos de gestin de configuracin de 5.2. Actividades de

software de control y se deben seguir (vase el cierre [2, s3.7, S4.8]
Software Configuration Management KA), las
decisiones docu-
mentado y comunicado a todas las partes de las partes interesadas; problemas conocidos
interesadas, los planes de examinar y modificar deben ser documentados.
cuando sea necesario, y se registran los datos
pertinentes (vase la seccin 6.3, realizar el
proceso de medicin).

4.2. Revisin y Evaluacin del desempeo

[3 *, c8, c10]

evaluaciones de desempeo peridicas para el

proyecto sonal per- pueden proporcionar
informacin en cuanto a la probabilidad de
cumplimiento de los planes y procesos, as como
posibles reas de dificultad (por ejemplo,
conflictos miembros del equipo). Los diversos
mtodos, herramientas y tcnicas empleadas
deben ser evaluados para su eficacia y
conveniencia, y el proceso siendo utilizados por
el proyecto tambin deben ser evaluados
sistemtica y peridicamente para Evance rel-,
utilidad y eficacia en el contexto del proyecto.
En su caso, se deben hacer cambios y
gestionados.

5. Cierre

Un proyecto completo, una fase importante de

un proyecto, o un ciclo de desarrollo iterativo
alcanza ClO seguro de que cuando se han
aprobado y completado todos los planes y
procesos. Los criterios para el proyecto, la fase o
el xito iteracin deberan ser evaluados. Una
vez que se establece el cierre, de archivo,
retrospectivo, y de mejora de procesos
actividades se pueden realizar.

5.1. Cierre la determinacin

[1, s3.7, S4.6]

El cierre se produce cuando las tareas

especificadas para un proyecto, una fase, o una
iteracin se han com- plet logro y satisfactoria
de los criterios pletion com- ha sido confirmada.
Requisitos de software se pueden confirmar que
se cumple o no, y el grado de consecucin de los
objetivos se pueden determinar. procesos de
cierre deben involucrar a las partes interesadas y
el resultado en la documentacin de aceptacin
Tras el cierre se haya confirmado, el archivo de Ingeniera de Software de Gestin de 7-
17
los materiales del proyecto debe llevarse a
cabo de acuerdo con los grupos de inters
acordada ods met, la ubicacin y la duracin,
posiblemente incluyendo la destruccin de la
informacin sensible, el software y el medio en
el que las copias son residentes. base de datos
de medicin de la organizacin debe
actualizarse con los datos relevantes del
proyecto. Un proyecto, la fase o anlisis
retrospectivo iteracin deben llevarse a cabo
para que los temas, problemas, riesgos y
oportunidades encontradas pueden ser
analizados (ver tema 4, Revisin y
Evaluacin). Las lecciones aprendidas deben
extraerse del proyecto y se introducen en el
aprendizaje y la mejora de los esfuerzos de
organizacin.

6. Medicin de Ingeniera de Software

La importancia de la medicin y su papel en

mejores prcticas de gestin y de ingeniera es
ampliamente reconocido (vase Medicin de
los Fundamentos de Ingeniera KA). surement
medi- efectiva se ha convertido en una de las
piedras angulares de la madurez de la
organizacin. La medida puede ser aplicada a
las organizaciones, proyectos, procesos y
productos de trabajo. En esta seccin se centra
en la aplicacin de la medida a nivel de
proyec- tos, procesos y productos de trabajo.
Esta seccin sigue el estndar IEEE 15939:
2008 [6], que describe un proceso para definir
las actividades y tareas necesarias para
implementar un proceso de medicin de
software. El estndar tambin incluye un
modelo de informacin de medicin.

6.1. Establecer y mantener el

compromiso de Medicin
[7 *, c1, c2] 2

Requisitos para la medicin. Cada

esfuerzo de medicin debe ser guiada por
objetivos de la organizacin y accionado
por un conjunto de requisitos de medicin
establecidos por

2 Tenga en cuenta que estos dos captulos se

pueden descargar de forma gratuita desde
www.psmsc.com/ PSMBook.asp.
7-18 Gua SWEBOK V3.0

la organizacin y el proyecto (por ejem- plo, se pueden derivar de negocio, objetivos de

un objetivo de la organizacin podran ser la organizacin, regulacin y / o de
los primeros en el mercado con nuevos productos. Ellos deben ser identificados y
productos).
mbito de aplicacin de la medicin. La
unidad organizativa a la que cada requisito
de medicin se va a aplicar debe ser
establecido. Esto puede consistir en un rea
funcional, un solo proyecto, un solo sitio, o
toda una empresa.El mbito temporal de la
medicin de esfuerzo tambin debe ser
considerado porque puede ser necesario
series de tiempo de algunas mediciones; por
ejemplo, para calibrar los modelos esti-
macin (ver seccin 2.3, Esfuerzo, ULE
Sched-, y estimacin de costos).
el compromiso del equipo de medicin. El
compromiso debe establecerse formalmente,
comunica, y apoyado por los recursos (ver
siguiente punto).
Recursos para la medicin. El compromiso
de una organiza- cin de medicin es un
factor esencial para el xito, como lo
demuestra la asignacin de recursos para
implement- ing el proceso de medicin.
Asignacin de recursos incluye la
asignacin de responsabili- dad para las
diversas tareas del proceso de medicin
(tales como el analista y bibliotecario). ade-
cuada financiacin, formacin, herramientas
y apoyo para llevar a cabo el proceso
tambin deben asignarse.

6.2. Planificar el proceso de medicin

[7 *, c1, c2]

Caracterizar la unidad organizativa. La

unidad de organizacin proporciona el
contexto para la medicin, por lo que el
contexto de la organizacin debe ser
explcita, incluyendo los straints confirma
que la organizacin impone en el proceso de
medicin. La caracterizacin se puede
afirmar en trminos de procesos de
organizacin, dominios de aplicacin, la
tecnologa, las interfaces de organizacin y
estructura organizativa.
Identificar las necesidades de informacin.
Las necesidades de informacin se basan en
los objetivos, limitaciones, riesgos y
problemas de la unidad organizativa. Ellos
 Ingeniera de Software de Gestin de 7-
proceso de medicin.
priorizado. A continuacin, un subconjunto 19
de los objetivos que se abordarn se puede Identificar recursos para poner a disposicin
seleccionar, documentado, com- municated, de
y revisado por los interesados. la aplicacin de los previsto y aprobado
Optar por medidas. medidas candidatos
deben ser seleccionados, con claros vnculos
con las necesidades de informa- cin. Las
medidas deben ser seleccionados en base a
las prioridades de las necesidades de
informacin y otros criterios tales como
coste de la recogida, el grado de interrupcin
del proceso durante la recogida, la facilidad
de obtencin, los datos Consistente precisa, y
la facilidad de anlisis y ing informe-.
Debido a las caractersticas de calidad
interna (ver modelos y caractersticas de
calidad de la calidad del software KA) a
menudo no contenida en los requisitos de
software contractuales, es importante tener
en cuenta medi- suring la calidad interna del
software para proporcionar un indicador
temprano de potencial cuestiones que puedan
afectar a las partes interesadas externas.
Definir la recogida de datos, anlisis y
procedimientos de ING informe-. Esto
abarca procedimientos de recogida y
horarios, almacenamiento, verifica- cin,
anlisis, informes y gestin de la
configuracin de datos.
Seleccione los criterios de evaluacin de los
productos de informacin. Criterios para la
evaluacin estn influidos por los tantes
objeciones tcnicas y comerciales de la
unidad organizativa. Los productos de
informacin incluyen los asociados con el
producto que se produce, as como los
asociados con los procesos que se utilizan
para administrar y medir el proyecto.
Proporcionar recursos para las tareas de
medicin. El plan de medicin debe ser
revisado y aprobado por los interesados
apropiados para incluir todos los
procedimientos de recoleccin de datos;
procedimientos de almacenamiento, anlisis
y presentacin de informes; criterios de
evaluacin; horarios; y responsabilidades.
cri- terios para la revisin de estos artefactos
deberan haberse establecido a nivel de
unidad organizativa o superior y deben
utilizarse como base para estas revisiones.
Dichos criterios deben tener en cuenta la
experiencia previa, la capacidad de
disponibilidad de recursos, y las posibles
interrupciones a los proyectos cuando se
proponen cambios desde ticas ticas actuales.
Aprobacin demuestra el compromiso con el
 Ingeniera de Software de Gestin de 7-11

tareas de medicin. La disponibilidad de Fundamentos de ingeniera KA). Los

recursos puede ser puesta en escena en los resultados y conclusiones son generalmente
casos en que los cambios han de ser revisados, usando un proceso definido por la
pilotado antes del despliegue generalizado. organizacin (que puede ser formal o
Debern tener en cuenta a los recursos informal). Los proveedores de datos y
necesarios para la implementacin exitosa usuarios de medida deben participar en la
de nuevos procedimientos o medidas. revisin de los datos para asegurarse de que
Adquirir y desplegar tecnologas de apoyo. son significativos y precisos y que puedan
Esto incluye la evaluacintecnologas de dar lugar a acciones razonables.
soporte disponibles de, la seleccin de las Comunicar los resultados. Los productos de
tecnologas ms adecuadas, de adquisicin informacin deben ser documentados y
de esas tecnologas, y el despliegue de esas comunicados a los usuarios y grupos de
tecnologas. inters.

6.3. Realizar el proceso de medicin 6.4. evaluar Medicin

[7 *, c1, c2] [7 *, c1, c2]

Integrar los procedimientos de medicin con apropiado a la naturaleza de los datos y las
los procesos de software Evant rel. Los necesidades de informacin. Los resultados de
procedimientos de medicin, tales como la este anlisis son tpicamente indicadores tales
recopilacin de datos, deben integrarse en como grficos, nmeros u otras indicaciones
los procesos de software que se est que sern interpretadas, resultando en
midiendo. Esto puede implicar cam- ing conclusiones y recomendaciones que se
procesos de software actuales para presentar a las partes interesadas (ver Anlisis
acomodar la recopilacin de datos de fecha estadstico en el
o actividades de generacin. Tambin puede
implicar el anlisis de los procesos de soft-
ware actuales para reducir al mnimo
esfuerzo adicional y la evaluacin del efecto
de los empleados para asegurar que se
aceptarn los procedimientos de medicin.
problemas de moral y otros factores
humanos deben ser considerados. Adems,
los procedimientos de medicin deben ser
comu- nicated a los que proporcionan los
datos. Tambin puede ser necesario
proporcionar formacin y apoyo.
procedimientos de anlisis de datos y de
informacin estn tpicamente integrados en
los procesos de organizacin y / o proyecto
de manera similar.
Recolectar datos. Los datos deben
recogerse, que ha comprobado, y se
almacenan. Coleccin veces se puede
automatizar mediante el uso de software de
Engineer- herramientas de gestin de ING
(vase el tema 7, la Cesin de Software de
Gestin de Herramientas de ingeniera) para
analizar los datos y elaborar informes. Los
datos pueden ser agregados, transformadas,
o recodificados como parte del proceso de
anlisis, utilizando un grado de rigor
7-12 Gua SWEBOK V3.0
Evaluar productos de informacin y el
proceso surement medi- contra
especificado Evaluation criterios acin y
determinar las fortalezas y debilidades de
los productos de informacin o proceso,
respectivamente. La evaluacin puede ser
realizada por un proceso interno o una
auditora nal externamente; que debe
incluir la retroalimentacin de los
usuarios de medicin. Las lecciones
aprendidas deben ser registrados en una
base de datos adecuada.
Identificar las mejoras potenciales. Tales
mejoras pueden ser cambios en el
formato de los indicadores, los cambios
en unidades medidas, o reclasificacin de
categoras de medicin. Los costos y los
beneficios potenciales de las mejoras
deben ser determinados y acciones de
mejora apropiadas deben ser reportados.
Comunicar las mejoras propuestas para el
propietario del proceso de medicin y
ERS stakehold- para su revisin y
aprobacin. Adems, la falta de mejoras
potenciales debe comuni- nicated si el
anlisis no identifica ninguna mejora.

7. Herramientas de Gestin de Ingeniera de

Software
[3 *, c5, c6,
c7]

herramientas de gestin de la ingeniera de

software a menudo se utilizan para
proporcionar visibilidad y control de los
procesos de gestin de ingeniera de software.
Algunas herramientas son automatizados,
mientras que otros son manualmente
implementado. Ha habido una tendencia
reciente hacia el uso de suites integradas de
ingeniera de software herramientas que se
utilizan en un proyecto para planificar,
recopilar y registrar, monitorear y controlar, y
 Ingeniera de Software de Gestin de 7-13

proyecto de informe e informacin del producto. y estimaciones subjetivas de las probabilidades

Las herramientas pueden de los eventos de riesgo. herramientas de
puede dividir en las siguientes categoras: simulacin Monte Carlo se pueden utilizar para
Planificacin de proyectos y herramientas de producir distribuciones de probabilidad de
seguimiento. planificacin de proyectos y esfuerzo, horario, y el riesgo mediante la
herramientas de seguimiento se pueden utilizar combinacin de mltiples distribuciones de
para estimar el esfuerzo y el coste del proyecto probabilidad de entrada de una manera
compaero y preparar los programas del algortmica.
proyecto. Algunos proyectos utilizan Herramientas de comunicacin. Las
herramientas automatizadas esti- macin que herramientas de comunicacin pueden ayudar a
aceptan como entrada el tamao estimado y proporcionar informacin oportuna y consistente
otras caractersticas de un producto de software a las partes interesadas que participan en un
y producen estimaciones del esfuerzo total, el proyecto. Estas herramientas pueden incluir
cronograma y costo requerido. herramientas de cosas como las notificaciones de correo
planificacin tambin incluyen herramientas de electrnico y transmisiones de los miembros del
programacin que analizan las tareas dentro de equipo y las partes interesadas. Tambin
una estructura de desglose de trabajo incluyen comu- nicacin de las actas de las
automatizado, su estimacin acoplado reuniones regulares del proyecto, reuniones
duraciones, sus relaciones de precedencia, y los diarias de stand-up, adems de grficos que
recursos asignados a cada tarea para pro- ducir muestran el progreso, el trabajo atrasado, y
un calendario en forma de un diagrama de Gantt. solicitud de mantenimiento resoluciones.
herramientas de seguimiento se pueden Herramientas de medicin. Herramientas de
utilizar para realizar un seguimiento de los hitos medicin SUP- actividades portuarias
del proyecto, reuniones de estado del proyecto relacionadas con el programa de medicin cin
programadas regularmente, ciclos de iteracin (vase el tema 6, Software Engineer- Medicin
programadas, demostraciones de productos y / o ing) de software. Hay pocas herramientas
elementos de accin. completamente automatizadas en esta categora.
Herramientas de gestin de riesgos. instrumentos de medicin utilizados para reunir,
herramientas de gestin del riesgo (ver seccin analizar y reportar los datos de medicin de
2.5, gestin de riesgos) se pueden utilizar para proyecto pueden estar basados en hojas de
realizar un seguimiento de la identificacin del clculo desarrollados por los miembros del
riesgo, estimacin y supervisin. Estas equipo de proyecto o empleados organizativas.
herramientas incluyen el uso de enfoques como
la simulacin o de rboles de decisin para
analizar el efecto de los costos versus beneficios
7-14 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

BoEHM y Turner 2003

mcGarry et al. 2001

2011 [4 *]
2009 [3
JustaLey de

SommervilLe

[5 *]

[7 *]
*]
1. Iniciacin y Alcance
Definicin
1.1. La determinacin y la
c3
negociacin de los
requisitos
1.2. Anlisis de viabilidad c4
1.3. proceso parael examen y
c3
revisin de los requisitos
2. software de planificacin
2.1. Planificacin de c2, c3, c4, c5 c1
procesos
2.2. determinar entregables c4, c5, c6
2.3. Esfuerzo, Planificar,y
c6
Estimacin de Costos
2.4. Asignacin de recursos C5, C10,
2.5. Gestin de riesgos C11
C9 c5
2.6. Gestin de la calidad c4 c24
2.7. Gestin del plan c4
La promulgacin 3. Proyecto de
Software
3.1. Implementacin de Planes c2
3.2. Software de Adquisicin y
C3, C4
Proveedor Gestin de contratos
3.3. Implementacin de
c7
Proceso de medida
3.4. Process monitor c8
3.5. Control de procesos C7, C8
3.6. informes c11
4. Revisin y Evaluacin
4.1. La determinacin de
satisfaccin de los requisitos
4.2. revisandoy la evaluacin del
c8, c10
desempeo
 Ingeniera de Software de Gestin de 7-15

BoEHM y Turner 2003

mcGarry et al. 2001

2011 [4 *]
2009 [3
JustaLey de

SommervilLe

[5 *]

[7 *]
*]
5. Cierre
5.1. Cierre la determinacin
5.2. Actividades de cierre
6. Software de
Ingeniera de medicin
6.1. Establecer y mantener
c1, c2
Compromiso de medicin
6.2. Planificar la Medicin
c1, c2
Proceso
6.3. Realizar la medicin
c1, c2
Proceso
6.4. evaluar Medicin c1, c2
7. Herramientas de
C5, C6, C7
Gestin de Ingeniera
de Software
7-16 Gua SWEBOK V3.0

LECTURAS software complejo, y sistemas de hardware, as

como los resultados de la inspeccin y las
Una gua para la Direccin de Proyectos mtricas de prueba para monitorear el estado del
(PMBOK Gua) [1]. proyecto Tor.

La Gua PMBOK proporciona directrices para

la gestin de proyectos individuales y define los
conceptos relacionados con la gestin de
proyectos. Tambin describe el ciclo de vida de
gestin de proyectos y sus procesos
relacionados, as como el ciclo de vida del
proyecto. Es una gua reconocida a nivel
mundial para la profesin agement el proyecto
hombre-.

Software de Extensin a la Gua de los

Fundamentos de la Direccin de
Proyectos (Gua del PMBOK) [2].

SWX ofrece adaptaciones y ampliaciones de las

prcticas genricas de gestin de proyectos
documentados en la Gua PMBOK para
proyectos de software ing manag-. La principal
contribucin de esta extensin de la Gua
PMBOK es una descripcin de los procesos
que son aplicables para la gestin de proyectos
de software de ciclo de vida de adaptacin.

La adopcin de la norma IEEE ISO / IEC 15939

[6].

Esta norma internacional identifica un proceso

que es compatible con la definicin de un
conjunto adecuado de medidas para hacer frente
a las necesidades especficas de informacin. Se
identidades FIES las actividades y tareas que son
necesarias para identificar con xito, definir,
seleccionar, aplicar y mejorar la medicin dentro
de un proyecto global o la estructura
organizativa de medicin.

J. McDonald, gestin del desarrollo de software

de sistemas intensivos, Wiley, 2010 [8].

Este libro de texto proporciona una introduccin

a la gestin de proyectos para el comienzo de los
desarrolladores de software y hard- ware ms
avanzado material nico para los
administradores de proyectos experimentados.
Los estudios de casos se incluyen la
planificacin y la gestin de verifica- cin y
validacin para grandes proyectos de software,
 Ingeniera de Software de Gestin de 7-17
Referencias

[1] Instituto de Gestin de Proyectos, una gua

para la Direccin de Proyectos del
Conocimiento (PMBOK (R) Gua), 5 ed.,
Project Management Institute, 2013.

[2] Instituto de Gestin de Proyectos y IEEE

Computer Society, software de la
extensin de la Gua del PMBOK
quinta edicin, Project Management
Institute, 2013.

[3 *] RE Fairley, gestionar y liderar proyectos

de software, Wiley-IEEE Computer
Society Press, 2009.

[4 *] I. Sommerville, Ingeniera de Software, 9

ed., Addison-Wesley, 2011.

[5 *] B. Boehm y R. Turner, Equilibrio de la

agilidad y disciplina: una gua para los
perplejos, Addison-Wesley, 2003.

[6] IEEE Std. 15939-2008 La adopcin del

estndar ISO / IEC 15939: 2007 Sistemas
y Procesos de Ingeniera de Software de
Mediciones, IEEE 2008.

[7 *] J. McGarry et al, Practical Software

de medicin:. Informacin Objetivo
para los decisores, Addison-Wesley
Professional, 2001.

[8] J. McDonald, gestin del desarrollo de

software de sistemas intensivos, John
Wiley and Sons, Inc., 2010.
 CAPTULO 8

SOFTWARE INGENIERA DE PROCESOS

de software. Para facilitar la lectura , la

SIGLAS ingeniera de software

Business Process Modeling

BPMN
Notacin
Software Asistida por Ordenador
CASO
Ingenieria
CM Gestin de la configuracin
Capability Maturity Model
CMMI
Integration
GQM Meta-pregunta-Metric
IDEF0 integracin Definicin
LOE Nivel de esfuerzo
ODC Clasificacin de defectos ortogonal
SDLC Ciclo de vida del desarrollo de
SPLC programas
Software del ciclo de vida del
UML producto
Lenguaje de Modelado Unificado

INTRODUCCIN

Un proceso de ingeniera consiste en un

conjunto de actividades interrelacionadas que
transforman una o ms entradas en salidas,
mientras que consume recursos cumpla
cabalmente la transformacin. Muchos de los
procesos de disciplinas de ingeniera
tradicionales (por ejemplo, elctrica, mecnica,
civil, qumicos) se refieren a la transformacin
de la energa y las entidades fsicas de una forma
a otra, como en una presa hidroelctrica que
transforma la energa potencial en energa
elctrica o una refinera de petrleo que utiliza
procesos qumicos para transformar el petrleo
crudo en gasolina.
En esta rea de conocimiento (KA), ingeniera
de software procesos tienen que ver con las
actividades de trabajo realizado por los
ingenieros de software para desarrollar,
mantener y operar el software, tales como los
requisitos, diseo, construccin, pruebas, gestin
de con- figuracin, y otra procesos de ingeniera
 la adaptacinIngeniera de Software de Gestin
y la implementacin de 7-19
de procesos
procesose denominaproceso de softwareen de software para un proyecto de software
este KA. Adems, tenga en cuenta que el especfico (ver Proceso de Planificacin en el
proceso de software se refiere a las KA Software Engineering Management). Els y
actividades de trabajo, no el proceso de ejecu- mtodos mo- apoyan un enfoque sistemtico
cin para el software implementado. para el desarrollo de software y modificacin.
procesos de software se especifican para un La calidad KA software se ocupa de la
nmero de razones: para facilitar la planificacin, aseguramiento y control de
comprensin humana, la comunicacin y la procesos para el proyecto y la calidad del
coordinacin; para ayudar agement-hombre de producto. Medicin y medicin de los resultados
los proyectos de software; para medir y en la Ingeniera Foundation ciones KA son
mejorar la calidad de los productos de software esenciales para la evaluacin de los procesos de
de una manera eficiente; para apoyar proceso software y control- ling.
de mejora cin; y para proporcionar una base
para el puerto SUP- automatizado de ejecucin DISTRIBUCIN DE TEMAS DE
del proceso. INGENIERA DE PROCESOS DE
SWEBOK KAs estrechamente relacionados SOFTWARE
con este proceso de Ingeniera de Software KA
incluyen el software de gestin de ingeniera, Como se ilustra en la Figura 8.1, este KA tiene
modelos de ingeniera de software y Mtodos, que ver con la definicin de procesos de
y Calidad de Software; el tema Anlisis Causa software, los ciclos de vida del software,
Raz Medicin y que se encuentra en los evaluacin de procesos de software y la mejora,
Fundamentos de Ingeniera KA tambin est la medicin del software, el software y
estrechamente relacionado. Software de herramientas de proceso de inge- niera.
gestin de ingeniera se ocupa de la adaptacin,

8-1
8-2 Gua SWEBOK V3.0

Figura 8.1. Desglose de los temas para el Proceso de Ingeniera de Software KA

1. Proceso de definicin de software especificadas deben ser satisfechas antes de que

[1 *, P177] [2 *, P295] [3 *, p28-29, p36, c5] un proceso puede ser con xito

Este tema tiene que ver con una definicin de

proceso de software, gestin de procesos de
software, y la infraestructura de procesos de
software.
Como se mencion anteriormente, un proceso
de software es un conjunto de actividades y
tareas interrelacionadas que transforman los
productos de trabajo de entrada en productos de
trabajo de salida. Como mnimo, la descripcin
de un pro- ceso de software incluye entradas
requiere, transformar las actividades de trabajo y
genera salidas. Como se ilustra en la Figura 8.2,
un proceso de software tambin puede incluir su
entrada y criterios de salida y la descomposicin
de las actividades de trabajo en tareas, que son
las unidades ms pequeas de trabajo sujetas a la
responsabilidad de gestin. Una entrada de
proceso puede ser un evento ing Trigger o la
salida de otro proceso. Los criterios de ingreso
deben ser satisfechas antes de que un proceso
pueda comenzar. Todas las condiciones
 Software de Ingeniera de Procesos
concluido, incluyendo los criterios de 8-3
aceptacin para el producto del trabajo de salida
o productos de trabajo.
Un proceso de software puede incluir
subprocesos. Por ejemplo, la validacin de los
requisitos de software es un proceso utilizado
para determinar si los requisitos
proporcionarn una base adecuada para el
desarrollo de software; es un subproceso del
proceso de requisitos de software. Las entradas
para la validacin de requisitos son tpicamente
unos requisitos de software valor especificado
y los recursos necesarios para realizar la
validacin (personal, herramientas de
validacin, tiempo suficiente). Las tareas de la
actividad de validacin requisitos podran
incluir requisitos de los comentarios,
prototipado y validacin del modelo. Estas
tareas incluyen las asignaciones de trabajo para
las personas y equipos. La salida de validacin
de requisitos suele ser una especificacin de
requisitos de software validado que
proporciona entradas para el diseo de
software y el software de Exmenes procesos
ing. validacin de requisitos y otros
subprocesos del proceso de requisitos de
software son a menudo intercalada y reiterada
en varias formas;
8-4 Gua SWEBOK V3.0

Figura 8.2. Elementos de un proceso de software

el proceso de requisitos de software y sus 454]

subprogramas, cesos pueden entraba y sala
varias veces durante el desarrollo de software o Dos objetivos de la gestin de procesos de
modificacin. software
definicin completa de un proceso de software son para darse cuenta de la eficiencia y eficacia
tambin puede incluir las funciones y que
competencias, TI SUP- puerto, tcnicas de
ingeniera de software y herramientas, y
ambiente de trabajo necesario para llevar a cabo
el proceso, as como los enfoques y medidas
(indicadores clave de rendimiento) que se utiliza
para determinar la la eficiencia y la eficacia de la
realizacin del proceso.
Adems, un proceso de software puede incluir
actividades tivas tcnicas, colaborativas y
administraciones intercalados.
Notaciones para la definicin de procesos de
software incluyen listas textuales de actividades
que lo componen y las tareas que se describen en
lenguaje natural; diagramas de flujo de datos;
grficos de estado; BPMN; IDEF0; redes de
Petri; y los diagramas de actividad UML. Las
tareas de transformacin dentro de un proceso
pueden definirse como procedimien- tos; un
procedimiento se puede especificar como un
conjunto ordenado de pasos o, alternativamente,
como una lista de control del trabajo a llevar a
cabo en la realizacin de una tarea.
Se debe enfatizar que no hay mejor proceso de
software o conjunto de procesos de software.
procesos de soft- ware deben ser seleccionados,
adaptados, y se aplican segn sea apropiado para
cada proyecto y cada contexto de la
organizacin. No hay proceso ideal, o un
conjunto de procesos, existe.

1.1. Gestin de procesos de software

[3 *, s26.1] [4 *, p453-
 Software de Ingeniera de Procesos
resultado de un enfoque sistemtico para 8-5
accomplish- ing procesos de software y
producir trabajo Pro- ductos-ya sea a nivel
individual, proyecto, o el nivel y organizativa
para introducir procesos nuevos o mejorados.
Los procesos se cambian con la expectativa
de que un proceso nuevo o modificado
mejorar la eficiencia y / o la eficacia del
proceso y la calidad de los productos de trabajo
resultantes. El cambio a un nuevo proceso, la
mejora de un proceso existente, el cambio
organizacional y cambio de infraestructura
(insercin de la tecnologa o los cambios de
herramientas) estn estrechamente
relacionados, ya que todos estn inicia
generalmente con el objetivo de mejorar el
coste, el desarrollo sched- ULE, o la calidad de
los productos de software. cambio de proceso
tiene un impacto no slo para el producto de
software; que a menudo conducen al cambio
organizativo. El cambio de un proceso o la
introduccin de un nuevo proceso puede tener
efectos de la ondulacin a lo largo de un orga-
nizacin. Por ejemplo, los cambios en las
herramientas informticas infra- estructura y la
tecnologa a menudo requieren cambios en el
proceso.
Los procesos existentes pueden ser
modificados cuando otros procesos nuevos se
despliegan por primera vez (por ejemplo, la
introduccin de una actividad de inspeccin
dentro de un proyecto de desarrollo de
software probablemente tendr un impacto en
las pruebas de software proceso- ver revisiones
y auditoras de la calidad de software y KA en
las pruebas de software KA). Estas situa-
ciones tambin pueden ser denominados
evolucin del proceso. Si las modificaciones
son extensas, a continuacin, los cambios en la
cultura y la empresa modelo de organizacin es
probable que sea necesario para acomodar los
cambios en el proceso.
8-6 Gua SWEBOK V3.0

1.2. Infraestructura de Procesos de Software proceso influye en la calidad del producto de

[2 *, P183, P186] [4 *, p437- software.
438]
2. Ciclos de vida del software
El establecimiento, implementacin y gestin de [1 *, c2] [2 *, p190]
procesos de software y modelos de ciclo de vida
del software a menudo se produce en el nivel de En este tema se aborda categoras de pro- cesos de
los proyectos de software individuales. Sin software, modelos de ciclo de vida del software,
embargo, la aplicacin sistemtica de los software
procesos de software y de ciclo de vida del
software els mo- travs de una organizacin
puede proporcionar beneficios a todos los
trabajos de software dentro de la organizacin, a
pesar de que requiere un compromiso a nivel
orga- zational. Una infraestructura de proceso de
software puede proporcionar definiciones de los
procesos, las polticas de preting inter y la
aplicacin de los procesos, y las descripciones
de los procedimientos que se utilizarn para
implementar los procesos. Adems, una
infraestructura de proceso de software puede
proporcionar financiacin, herramientas, ING
forma-, y miembros del personal que hayan sido
asignadas responsabilidades para establecer y
mantener la infraestructura de proceso de
software.
infraestructura de proceso de software vara,
Dependiendo del tamao y la complejidad de la
organizacin y los proyectos llevados a cabo
dentro de la organizacin. , organizaciones y
proyectos sencillos pequeos tienen necesidades
de infraestructura pequeos y sencillos. Grandes,
organizaciones y proyectos complejos, por sidad
nece-, tienen infraestructuras de procesos de
software ms grandes y complejos. En el ltimo
caso, se pueden establecer diferentes unidades
organizativas (tal como un grupo de procesos de
ingeniera de software o un comit ing steer-)
para supervisar la aplicacin y mejora de los
procesos de software.
Un error comn es que el establecimiento de
una infraestructura de proceso de software e
implementacin de procesos de software
repetibles aadir tiempo y costo para el
desarrollo y mantenimiento de software. Hay un
costo asociado con la introduccin o la mejora
de un proceso de software; Sin embargo, expe-
riencia ha demostrado que la aplicacin de la
mejora sistemtica de los procesos de software
tiende a dar lugar a menor costo mediante la
mejora de la eficiencia, Ance Evitar- de
repeticin del trabajo, y el software ms fiable y
asequible. por lo tanto el rendimiento del
adaptacin de procesos, y consideraciones considerados como menosSoftware de aIngeniera
efectivo menos quede Procesos
8-7
prcticas. Un ciclo de vida de desarrollo de otros procesos de software se llevan a cabo al
software (SDLC) incluye los procesos de mismo tiempo (por ejemplo, planificacin de
software utilizados para especificar y prueba de software durante el anlisis de los
transformar los requisitos de software en un requisitos de software puede mejorar los
producto de software erable deliv-. Un ciclo de requisitos de software).
vida del producto de software (SPLC) incluye
un software de ciclo de vida de desarrollo de
software ms procesos adicionales que
proporcionan para el despliegue,
mantenimiento, soporte, la evolucin, la
jubilacin, y todos los dems procesos
inception--a la jubilacin para un producto de
software, incluyendo la gestin de
configuracin de software y los procesos de
garanta de calidad del software que se aplican
a lo largo de un ciclo de vida del software de
producto. Un ciclo de vida del producto de
software puede incluir software PLE ciclos de
vida de desarrollo mltiples para desarrollar y
mejorar el software.
procesos de software individuales no tienen
ningn pedido ral tempo entre ellos. Las naves
PARENTESCO temporales entre los procesos
de software son proporcionados por un modelo
de ciclo de vida del software: ya sea un SDLC
o SPLC. modelos de ciclo de vida suelen
destacar los procesos de software clave dentro
del modelo y sus interdependencias y
relaciones cias temporales y lgicas. las
definiciones detalladas de los procesos de
software en un modelo de ciclo de vida se
pueden proporcionar directamente o por
referencia a otros documentos.
Adems de transmitir las relaciones
temporales y lgicas entre los procesos de
software, el modelo de desarrollo de software
de ciclo de vida (o modelos usan dentro de una
organizacin) incluye los mecanismos de
control para la aplicacin de criterios de
entrada y salida (por ejemplo, las revisiones del
proyecto, el cliente approv- del als, las pruebas
de software , umbrales de calidad, onstrations
demos-, equipo de consenso). La salida de un
proceso de software a menudo proporciona la
entrada para ERS oth- (por ejemplo, requisitos
de software proporcionan entrada para un
proceso de diseo arquitectnico software y los
cesos de construccin de software y pruebas de
software pro). ejecucin concurrente de varias
actividades del proceso de software pueden
producir una salida compartida (por ejemplo,
las especificaciones de la interfaz para las
interfaces entre los mltiples componentes de
software desarrollados por diferentes equipos).
Algunos procesos de software pueden ser
8-8 Gua SWEBOK V3.0

2.1. Categoras de procesos de software software para proteger la seguridad de MENT el

[1 *, Prefacio] [2 *, p294-295] [3 *, c22- desarrollo ambiente y reducir el riesgo de actos
c24] maliciosos. procesos de soft- ware tambin
pueden ser desarrollados para proporcionar un
Muchos procesos diferentes de software se han fundamento adecuado para el establecimiento de
definido para su uso en las diversas partes de los la confianza en la integridad del software.
ciclos de vida de desarrollo de software de
mantenimiento y software. Estos procesos se
pueden clasificar como sigue:

1. procesos primarios cesos incluir pro de

software para el desarrollo, operacin y
mantenimiento de software.
2. apoyar los procesos se aplican de forma
intermitente o continua durante todo el ciclo
de vida del producto de software para
apoyar cesos pro primarias; que incluyen
procesos de software, tales como gestin de
la configuracin, Ance assur- calidad, y la
verificacin y validacin.
3. procesos de organizacin proporcionar
puerto SUP- para la ingeniera de software;
que incluyen capacitacin, anlisis de
medicin de procesos, gestin de
infraestructuras, gestin de cartera y
reutilizacin, mejora de procesos de
organizacin y gestin de los modelos del
ciclo de vida del software.
4. procesos entre proyectos, tales como la
reutilizacin, la lnea de productos soft-
ware, y la ingeniera de dominio; que
involucran a ms de un proyecto de
software solo en una organizacin.

procesos de software, adems de los

mencionados anteriormente incluyen los
siguientes.
los procesos de gestin de proyectos incluyen
procesos para la planificacin y la estimacin,
gestin de recursos, medicin y control, lo que
lleva, la gestin de riesgos, la gestin de las
partes interesadas, y que coordinara la primaria,
el apoyo, la organizacin, y entre proyectos de
procesos de software Desa-, crear y mantener
proyectos.
procesos de software tambin se han
desarrollado para necesidades particulares, tales
como las actividades del proceso que se ocupan
de las caractersticas de calidad de software (ver
la calidad KA Software). Por ejemplo, los
problemas de seguridad durante el desarrollo de
software pueden requerir uno o ms procesos de
2.2. Modelos de Ciclo de vida del software implementados en Software
cada unodede
Ingeniera de Procesos
los incrementos.
8-9
[1 *, c2] [2 *, S3.2] [3 *, S2.1] Los requisitos de software pueden ser
[5] rigurosamente controladas, como en un modelo
lineal, o puede haber cierta flexibilidad en la
La naturaleza intangible y maleable de revisin de los requisitos de software como el
software permite una amplia variedad de producto de software evoluciona. modelos giles
modelos de ciclo de vida del software de pueden definir el alcance del producto y de alto
desarrollo, que van desde los modelos lineales nivel incluye inicialmente; Sin embargo, gil
en los que las fases de desarrollo de software
se lleva a cabo secuencialmente con
retroalimentacin y iteracin, segn sea
necesario, seguido de la integracin, ing Test-,
y la entrega de una producto nico; a los
modelos iterativo en el que se desarrolla
software en incrementos de aumentar la
funcionalidad en ciclos iterativos; a los
modelos giles que normalmente implican
manifestaciones frecuentes de software que
trabaja con un representante del cliente o
usuario que dirige el desarrollo del software en
ciclos iterativos cortos que producen
incrementos pequeos de trabajo, software
entregable. modelos incrementales, iterativos y
giles pueden entregar los primeros
subconjuntos de software que trabaja en el
entorno del usuario, si lo desea.
modelos lineales SDLC se refieren a veces
como los modelos de prediccin del ciclo de
vida de desarrollo de software, mientras que
SDLCs iterativos y giles se conocen como
modelos de adaptacin del ciclo de vida de
desarrollo de software. Cabe sealar que
variabilidad actividades de mantenimiento OU
durante una SPLC puede llevarse a cabo
utilizando diferentes modelos SDLC, segn sea
apropiado para las actividades de
mantenimiento.
Una caracterstica distintiva de los diferentes
modelos de ciclo de vida de desarrollo de
software es la manera en que se gestionan los
requisitos de software. modelos de desarrollo
del odo Lin- desarrollan tpicamente por un
juego completo de los requisitos de software,
en la medida en que sea posible, durante la
iniciacin y planificacin de proyectos. Los
requisitos de software son entonces
rigurosamente controlados. Los cambios en los
requisitos de software se basan en las
solicitudes de cambio que son procesados por
un tablero de control de cambios (vase la
Solicitud, la evaluacin y aprobacin de
software Cambios en el Consejo de Control de
Cambios en el Software de Gestin de Con-
figuracin KA). Un modelo incremental
produce incrementos sucesivos de traba- jando,
software entregable basado en la particin de
los requisitos de software para ser
8-10 Gua SWEBOK V3.0

modelos estn diseados para facilitar la adaptarse para reflejar las realidades del
evolucin de los requisitos de software durante desarrollo y mantenimiento de software dentro del
el proyecto. contexto de la organizacin y ambiente de
Se debe enfatizar que el continuo de SDLCs negocios.
de lineal a gil no es una lnea delgada, recta. Otra consideracin prctica: procesos de
Elementos de diferentes enfoques pueden ser software (como la gestin de la configuracin,
incorporados en un modelo especfico; por ejem-
plo, un software de modelo de ciclo de vida de
desarrollo incremental puede incorporar
requisitos de software secuenciales y fases de
diseo, pero permitir una gran flexibilidad en la
revisin de los requisitos de software y la
arquitectura durante la construccin de software.

2.3. La adaptacin de procesos de software

[1 *, s2.7] [2 *, p51]

SDLCs predefinida, SPLCS, y procesos de soft-

ware individuales a menudo necesitan ser
adaptados (o a medida) para servir mejor a las
necesidades locales. contexto organiza- cional,
las innovaciones en la tecnologa, el tamao del
proyecto, la criticidad del producto, los
requisitos normativos, prcticas de la industria, y
la cultura corporativa pueden determinar las
adaptaciones necesarias. La adaptacin de los
procesos de software individuales y los modelos
del ciclo de vida del software (desarrollo de
productos) y puede consistir en aadir ms
detalles a los procesos de software, actividades,
tareas y procedimientos para abordar los
problemas crticos. Puede consistir en el uso de
un conjunto alter- nar de las actividades que
logra el propsito y los resultados del proceso de
software. La adaptacin tambin puede incluir la
omisin de los procesos o actividades de
software de un modelo de ciclo de vida del
producto o de desarrollo que son claramente
inaplicables al alcance del trabajo a ser
realizado.

2.4. Consideraciones prcticas

[2 *, p188-190]

En la prctica, los procesos y actividades de

software a menudo se entrelazan, se superponen,
y se aplican concurrente tualmente. Los modelos
del ciclo de vida del software que especifican los
procesos de software Creta dis-, con criterios de
entrada y salida rigurosamente especificadas y
los lmites e interfaces prescritas, deben ser
reconocidos como idealizaciones que deben
 Software
se lleva a cabo utilizando tanto de
unIngeniera
modelo dedeProcesos
construccin y pruebas) se pueden adaptar para 8-11
facilitar su manejo Tate, soporte, evaluacin y un mtodo de evaluacin. El
mantenimiento, migracin, y el retiro del modelo puede proporcionar una norma para una
software. evaluacin comparativa
Otros factores a tener en cuenta en la
definicin y la adaptacin de un modelo de
ciclo de vida del software incluyen la
conformidad requerida a las normas, las
Directivas y polticas; demandas de los
clientes; criticidad del producto de software; y
organizativo ridad maduracin y competencias.
Otros factores incluyen la naturaleza del
trabajo (por ejemplo, modificacin del
software existen- tes contra nuevo desarrollo) y
el dominio de aplicacin (por ejemplo, el
espacio areo frente a la gestin del hotel).

3. Software de evaluacin y
mejora de procesos
[2 *, P188, P194] [3 *, c26] [4 *, P397,
c15]

Este proceso de modelos de evaluacin de

software direcciones tema, ods met evaluacin
de procesos de software, modelos de mejora de
procesos de software, y continua y por etapas
clasificaciones de proceso. evaluaciones del
proceso de software se utilizan para evaluar la
forma y el contenido de un proceso de
software, que podr ser indicada por un
conjunto estandarizado de criterios. En algunos
casos, los trminos evaluacin de proceso y
capacidad de evaluacin se utilizan en lugar
de la evaluacin del proceso. evaluaciones de
capacidad se realizan tpicamente por un
adquirente (o adquirente potencial) o por un
agente externo en nombre de un adquirente (o
adquirente potencial). Los resultados se
utilizan como un indicador de si los procesos
de software utilizados por un proveedor (o
potencial proveedor) son aceptables para el
adquirente. Las evaluaciones del desempeo se
realizan normalmente dentro de una organiza-
cin para identificar los procesos de software
en necesidad de mejorar o para determinar si
un proceso (o procesos) satisface los criterios a
un nivel dado de capacidad de proceso o
madurez.
evaluaciones del proceso se realizan en los
nive- les de organizaciones enteras, unidades
organizativas dentro de las organizaciones y
proyectos individuales. La evaluacin puede
incluir temas como evalua- cin si se estn
cumpliendo de entrada de proceso de software
y terios salida teria, para revisar los factores de
riesgo y la gestin del riesgo, o para identificar
las lecciones aprendidas. evaluacin de proceso
8-12 Gua SWEBOK V3.0

la comparacin entre los proyectos dentro de una objetivas que indica la consecucin de los
organiza- cin y entre organizaciones. objetivos y resultados de un proceso de software
Una auditora de proceso difiere de un proceso definido. Por ejemplo, una evaluacin cuantitativa
de Assessment. Las evaluaciones se realizaron del proceso de inspeccin soft- ware puede ser
para determinar niveles de capacidad o madurez realizada por
y para identificar los procesos de software que
ser mejorado. Las auditoras se realizan
normalmente para verificar el cumplimiento con
las polticas y normas. Auditoras proporcionan
visibilidad cin manage- en las operaciones
reales que se lleva a cabo en la organizacin
para que las decisiones precisas y significativas
se pueden hacer cuestiones ING concern- que
estn afectando a una actividad de
mantenimiento de desarrollo pro- yecto, o un
tema relacionado con el software.
factores de xito de los procesos de software
evalua- cin y mejora dentro del software
Engineer- organizaciones ing incluyen buque
gestin patrocinio, la planificacin, la
formacin, los lderes experimentados y capaces,
el compromiso del equipo, gestin de las
expectativas, el uso de agentes de cambio,
adems de proyectos piloto y experimentacin
con herramientas. fac- tores adicionales incluyen
la independencia del evaluador y la oportunidad
de la evaluacin.

3.1. Modelos de evaluacin de procesos de

software
[2 *, S4.5, S4.6] [3 *, s26.5] [4 *, p44-
48]

los modelos de evaluacin de procesos de

software suelen incluir criterios de evaluacin de
los procesos de software que son consideradas
como buenas prcticas. Estas prcticas pueden
hacer frente a los procesos de software Desa-
Ment solamente, o tambin pueden incluir temas
tales como el mantenimiento de software,
gestin de proyectos de software, ingeniera de
sistemas, o la gestin de recursos humanos.

3.2. Proceso de Software Mtodos de evaluacin

[1 *, p322-331] [3 *, s26.3]
[4 *, p44-48, s16.4] [6]

Un mtodo de evaluacin de procesos de

software puede ser cualitativa o cuantitativa. Las
valoraciones cualitativas se basan en el juicio de
expertos; evaluaciones cuantitativas asignar
puntuaciones numricas a los procesos de
software basados en el anlisis de pruebas
 Software demejoras
identificar y priorizar Ingeniera dedeseadas
Procesos
examinar los pasos del procedimiento seguido 8-13
y los resultados obtenidos, adems de los datos (planificacin); la introduccin de una mejora,
relativos a los defectos encontrados y el tiempo incluyendo la gestin y la formacin (hacer) el
requerido para encontrar y corregir los defectos cambio; evaluacin de la mejora
en comparacin con las pruebas de software.
Un mtodo tpico de proceso de software
evalua- cin incluye la planificacin,
determinacin de los hechos (por collect-
pruebas ing a travs de cuestionarios,
entrevistas y observacin de las prcticas de
trabajo), la recopilacin y validacin de los
datos del proceso, y el anlisis y generacin de
informes. evaluaciones del proceso pueden
confiar en el criterio subjetivo, cualitativo del
evaluador, o en la presencia objetiva o ausencia
de artefactos definidos, registros y otras
pruebas.
Las actividades llevadas a cabo durante una
evaluacin de procesos de software y la
distribucin del esfuerzo de las actividades de
evaluacin son diferentes dependiendo del
propsito de la evaluacin de procesos de
software. evaluaciones del proceso de software
se pueden emprender para desarrollar
calificaciones de capacidad que se utilizan para
hacer recomendaciones para mejoras en el
proceso o pueden llevarse a cabo para obtener
una calificacin de madurez de los procesos
con el fin de calificar para un contrato o
premio.
La calidad de los resultados de la evaluacin
depende del mtodo de evaluacin de procesos
de software, la integridad y la calidad de los
datos obtenidos, la capacidad y la objetividad
del equipo de evaluacin, y las pruebas
examinadas durante la evaluacin. El objetivo
de un proceso de evaluacin de software es
para obtener conocimientos que establecer el
estado actual de un proceso o procesos y
proporcionar una base para la mejora de
procesos; la realizacin de una evaluacin de
procesos de software siguiendo una lista de
comprobacin para la conformidad y sin
hacerse una idea agrega poco valor.

3.3. Modelos de mejora de procesos de software

[2 *, p187-188] [3 *, s26.5] [4 *,
s2.7]

modelos de mejora de procesos de software

enfatiza tamao ciclos iterativos de mejora
continua. Un ciclo de mejora de procesos de
software general afecta a los subprocesos de
medicin, lyzing ana- y cambiantes. El modelo
de Plan-Do-Check-Act es un enfoque iterativo
bien conocido para la mejora de procesos de
software. Las actividades de mejora incluyen
8-14 Gua SWEBOK V3.0

en comparacin con los resultados anteriores o nivel 1, pero de forma puntual, de manera
ejemplares de proceso y costes (control); y hacer informal. En el nivel 2, un proceso de software
modificaciones adicionales (en funciones). El (valoracin capacidad) o los procesos en el nivel
Plan-Do-Check-Act modelo de mejora de de madurez 2 estn siendo per- forman de una
procesos se puede aplicar, por ejemplo, para manera que proporciona una gestin
mejorar los procesos de software que mejoran la
prevencin de defectos.

3.4. Software puntuaciones proceso continuo

y puesta en escena
[1 *, p28-34] [3 *, s26.5] [4 *, p39-45]

Software de la capacidad de proceso y software

de madurez de los procesos se clasifican
normalmente usando cinco o seis niveles para
caracterizar la capacidad o madurez de los
procesos de software utilizados dentro de una
organizacin.
Un sistema de evaluacin continua implica la
asignacin de una calificacin a cada una de
procesos de software de inters; una por etapas
se establece sistema de clasificacin por la
asignacin de una calificacin por edades de la
misma a todos los procesos de software dentro
de un nivel de proceso especificado. A re-
presentacin de continua y el proceso de lev- els
se proporciona en la Tabla 8.1 puesta en escena.
modelos continuos suelen utilizar un nivel 0
opinin; por etapas modelos Tpicamente no lo
hacen.

Tabla 8.1. Niveles de software proceso de

calificacin
La La
representacin representacin
Nivel
continua de los por etapas de
niveles de niveles de
0 capacidad
Incompleto madurez
1 realizado Inicial
2 Gestionado Gestionado
3 definido definido
cuantitativam
4
ente
5 Gestionado
Optimizacin

En la Tabla 8.1, el nivel de 0 indica que un

proceso de software se lleva a cabo de forma
incompleta o no se puede realizar. En el nivel 1,
se est realizando un proceso de software
(valoracin capacidad), o se estn realizando los
procesos de software en un grupo de madurez
visibilidad de los productos de trabajo inspeccin se introduce, Software de Ingeniera
el esfuerzo combinadode Procesos
8-15
intermedios y puede ejercer algn control sobre de la inspeccin
las transiciones entre procesos. En el nivel 3,
un nico proceso de software o los procesos en
un nivel 3 grupo de madurez ms el proceso o
los procesos en el nivel de madurez 2 estn
bien definidas (tal vez en las polticas y
procedimientos de organizacin) y se repiten a
travs de dife- rentes proyectos. Nivel 3 de la
capacidad del proceso o madurez proporciona
la base para el proceso de mejora ment travs
de una organizacin porque el proceso es (o
procesos estn) llev a cabo en un ner Hombre-
similar. Esto permite la recogida de datos de
rendimiento de manera uniforme a travs de
mltiples proyectos. En el nivel de madurez 4,
las medidas cuantitativas pueden ser aplicados
y utilizados para la evaluacin de procesos;
anlisis tical estads- puede ser utilizado. Al
nivel de madurez 5, se aplican los mecanismos
para el proceso continuo de mejoras.
representaciones continuos y por etapas se
pueden utilizar para determinar el orden en que
los procesos de software son un ser mejorado.
En la representacin continua, los diferentes
niveles de capacidad para diferentes procesos
de software proporcionan una gua para
determinar el orden en que sern mejorados
procesos de software. En la repre- sentacin
por etapas, la satisfaccin de los objetivos de
un conjunto de procesos de software dentro de
un nivel de madurez se lleva a cabo para ese
nivel de madurez, lo que proporciona una base
para la mejora de todos los procesos de
software en el siguiente nivel superior.

4. Medicin de software
[3 *, s26.2] [4 *,
s18.1.1]

Este proceso de software direcciones tema y

medicin pro- ducto, la calidad de los
resultados de medicin, modelos de
informacin, software y tcnicas de medicin
de procesos de software (ver Medicin en los
Fundamentos de Ingeniera KA).
Antes de que un nuevo proceso se ejecute o
un proceso actual es modificado, los resultados
de medicin de la situacin actual deben
obtenerse a proporcio- nar una lnea de base
para la comparacin entre la situacin actual y
la nueva situacin. Para exami- plo, antes de
introducir el proceso de inspeccin de
software, el esfuerzo necesario para reparar
defectos descubiertos por las pruebas deben ser
medidos. Despus de un perodo de puesta en
marcha ini- cial despus de que el proceso de
8-16 Gua SWEBOK V3.0

adems de las pruebas puede ser comparada con arriba recin introducido se ha reducido el nmero
la cantidad anterior de esfuerzo requerido para restante de defectos en el software.
probar solo. consideraciones simi- lar se aplican medidas de productos que pueden ser
si se cambia un proceso. importantes en la determinacin de la eficacia de
los pro- cesos de software incluyen la complejidad
4.1. Proceso de Software y Medicin del del producto, defectos totales, densidad de
producto defectos, y la calidad de los requisitos,
[1 *, S6.3, P273] [3 *, s26.2,
P638]

procesos de software y medicin del producto

tienen que ver con la determinacin de la
eficiencia y la eficacia de un proceso de
software, la actividad o tarea. La eficiencia de
un proceso de software, la actividad o tarea es la
relacin entre los recursos consumidos
efectivamente a los recursos esperados o
deseados para ser consumidos en el
cumplimiento de un proceso de software, la
actividad o tarea (vase la eficiencia en el
software de Economa Ingeniera KA). Esfuerzo
(o el costo equivalente) es la principal medida de
los recursos para la mayora de los procesos de
software, las actividades y tareas; que se mide en
unidades tales como horas-persona-persona,
das, semanas, o entre el personal y persona-
meses de esfuerzo o en unidades monetarias
equivalentes-tales como euros o dlares.
Eficacia es la relacin de salida real a la salida
esperado producido por un proceso de software,
la actividad, o tarea; por ejemplo, el nmero real
de los defectos detectados y corregidos durante
las pruebas de software para el nmero esperado
de defectos para ser detectados y corregidos,
quiz basada en los datos his- trica para
proyectos similares (vase la Eficacia en el
software de Economa Ingeniera KA). Tenga en
cuenta que la medicin de los procesos de
software effec- tividad requiere la medicin de
los atributos de productos de referencia; por
ejemplo, la medicin de los defectos de software
descubierto y corregido durante pruebas de
software.
Hay que tener cuidado en la medicin de los
atributos del producto con el fin de determinar la
efectividad del proceso. Por ejemplo, el nmero
de defectos detectados y corregidos por la
prueba no puede alcanzar el nmero esperado de
defectos y por lo tanto proporcionar una medida
engaosamente baja efectividad, ya sea porque
el software que est siendo probado es de mejor-
que la habitual calidad o quizs debido a la
introduccin de un proceso de inspeccin aguas
 Software de Ingeniera
los defectos que encuentran, como en de la Procesos
unidad
documentacin de diseo, y otros productos de 8-17
trabajo relacionados. de pruebas por los desarrolladores de software o
Tambin tenga en cuenta que la eficiencia y en un equipo gil de funciones cruzadas. O el
la eficacia son conceptos independientes. Un clculo de la productividad puede incluir ya sea
proceso de software eficaz puede ser ineficaz el esfuerzo del software
en la consecucin de un resultado de procesos
de software deseado; por ejemplo, la cantidad
de esfuerzo realizado para encontrar defectos
de software y solucin podra ser muy alto y
resultar en una baja eficiencia, en comparacin
con las expectativas.
Un proceso eficiente puede ser ineficaz en
acompa- plishing la transformacin deseada de
los productos de trabajo de entrada en los
productos de trabajo de salida; por ejemplo, el
hecho de encontrar y corregir un nmero
suficiente de defectos de software durante el
proceso de prueba.
Las causas de la baja eficiencia y / o baja
efectividad en la forma de un proceso de
software, la actividad o tarea se ejecuta podra
incluir uno o ms de los siguientes problemas:
trabajo de entrada pro- ductos deficientes,
personal sin experiencia, la falta de
herramientas e infraestructura adecuados , el
aprendizaje de un nuevo proceso, un producto
complejo, o un dominio del producto
desconocido. La eficiencia y eficacia de la
ejecucin de procesos de software tambin se
ven afectados (ya sea positiva o
negativamente) por factores tales como Turn-
sobre en el personal de software, cambios de
horario, un nuevo representante del cliente, o
una nueva poltica organizativa.
En la ingeniera de software, la
productividad en per- que forman un proceso,
actividad o la tarea es la relacin de salida
producida dividida por recursos consumidos;
por ejemplo, el nmero de defectos de software
dis- cubierto y corregida dividida por horas-
hombre de esfuerzo (vase la productividad en
el Engineer- Software ing Economa KA). La
medicin precisa de la productividad debe
incluir el esfuerzo total usado para satisfa- isfy
los criterios de salida de un proceso de
software, activi- dad o la tarea; por ejemplo, el
esfuerzo requerido para corregir defectos
descubiertos durante el software de Exmenes
deben ser incluidos en la productividad del
desarrollo de software.
El clculo de la productividad se debe tener
en cuenta el contexto en el que se lleva a cabo
el trabajo. Por ejemplo, se incluir el esfuerzo
para corregir los defectos descubiertos en el
cal- culacin productividad de un equipo de
software si los miembros del equipo de corregir
8-18 Gua SWEBOK V3.0

desarrolladores o el esfuerzo de un equipo ING de la Ingeniera de Software de Gestin de KA

Ensayos independientes, dependiendo de quin describe un proceso para la implementacin de un
fija los defectos encontrados por los probadores programa de medicin de software.
independientes. Tenga en cuenta que este
ejemplo se refiere al esfuerzo de los equipos de
Ircops o equipos de probadores desa- y no a los
individuos. la productividad del software
calculado al nivel de los individuos puede ser
engaoso debido a los muchos factores que
pueden afectar la productividad individual de los
ingenieros de software.
definiciones estandarizadas y las reglas de
recuento para la medicin de los procesos de
software y productos de trabajo son necesarias
para proporcionar resultados de medicin
estandarizados a travs de proyectos dentro de
una organizacin, para rellenar un depsito de
datos cal histricamente que pueden ser
analizados para identificar procesos de software
que necesitan ser mejoradas y para construir
modelos predictivos basados en los datos
acumulados. En el ejemplo anterior, seran
necesarias las definiciones de defectos de
software y personal-horas de pruebas esfuerzo
ms contando reglas para defectos y esfuerzo
para obtener resultados de medicin
satisfactorios.
La medida en que se institucionaliza el
proceso de software es importante; insuficiencia
ins- titucionalizacin de un proceso de software
puede explicar por qu los buenos los
procesos de software no siempre pro duce
resultados anticipados. procesos de software
pueden ser institucionalizados por adopcin
dentro de la unidad organizativa local oa travs
de unidades ms grandes de una empresa.

4.2. Calidad de los resultados de medicin

[4 *, s3.4-3.7]

La calidad del proceso y medicin del producto

resultados se determina principalmente por la
fiabilidad y la validez de los resultados medidos.
Las mediciones que no satisfacen estos criterios
de calidad pueden dar lugar a interpretaciones
errneas y las iniciativas de mejora de procesos
de software defectuoso. Otras propiedades
deseables de mediciones de software incluyen la
facilidad de recoleccin, anlisis, y previa
presentacin ms una fuerte correlacin entre la
causa y efecto.
El tema de ingeniera de software de medicin
 datos diferente varanSoftware de Ingeniera
ampliamente de de
losProcesos
4.3. Informacin de software Modelos 8-19
[1 *, p310-311] [3 *, p712-713] [4 *, s19.2] resultados reales para ese conjunto de datos,
en cuyo caso el modelo derivado no es
Software modelos de informacin permiten el aplicable para establecer los nuevos datos y
modelado, anlisis y prediccin de procesos de no se deben aplicar para analizar o hacer
software y producto de software atributos para predicciones para proyectos futuros;
proporcionar respuestas a las preguntas
pertinentes y lograr los objetivos del proceso y
mejora del producto. datos necesarios pueden
ser recogidos y retenidos en un repositorio; Los
datos pueden ser ana- lisadas y los modelos se
pueden construir. La validacin y el
perfeccionamiento de los modelos de
informacin de software se producen durante
los proyectos de software y despus de la
conclusin de los proyectos para asegurar que
el nivel de precisin es suficiente y que sus
limitaciones son conocidas y comprendidas.
modelos de informacin de software tambin
pueden ser desarrolladas para contextos
distintos proyectos de software; por ejemplo,
un modelo de informacin de software podra
ser desarrollado para los procesos que se
aplican en toda la organizacin, tales como los
procesos de garanta de calidad del software
software de gestin de configu- racin o en el
nivel de organizacin.
edificio de informacin de software modelo
de anlisis impulsado implica el desarrollo, la
calibracin y evaluacin de un modelo. Un
software de infor- macin modelo se desarrolla
mediante el establecimiento de una
transformacin planteado la hiptesis de
variables de entrada en resultados deseados;
por ejemplo, el tamao y la complejidad de los
productos pueden ser transformados en
estimacin acoplado esfuerzo necesario para
desarrollar un producto de software utilizando
una ecuacin de regresin desarrollado a partir
de los datos observados de proyectos
anteriores. Un modelo se calibra mediante el
ajuste de los parmetros en el modelo para que
coincida con los resultados observados de
proyectos anteriores; Por ejemplo, el exponente
en un modelo de regresin no lineal puede ser
cambiado mediante la aplicacin de la ecuacin
de regresin a un conjunto diferente de
proyectos anteriores distintos de los proyectos
utilizados para desarrollar el modelo. Un
modelo se evala mediante la comparacin de
los resultados calculados con los resultados
reales para un conjunto diferente de datos
similares. Hay tres posibles Evaluacin
resultados:

1. resultados calculados para un conjunto de

 Software de Ingeniera de Procesos
8-11

2. Los resultados calculados para un nuevo Tcnicas de medicin de proceso tambin

conjunto de datos se encuentran cerca de los proporcionan la informacin necesaria para
resultados reales de ese conjunto de datos, medir los efectos de las iniciativas de mejora de
en cuyo caso los menores se realizan ajustes procesos. tcnicas surement medi- proceso
a los parmetros del modelo para mejorar el puede ser utilizado para recoger datos tanto
acuerdo; cuantitativos como cualitativos.
3. Los resultados calculados para los nuevos
conjunto de datos y conjuntos de datos 4.4.1. Tcnicas de medicin de procesos
posteriores estn muy cerca y no se cuantitativa
necesitan ajustes en el modelo.
4.4. Tcnicas de medicin de procesos de
La evaluacin continua del modelo puede software
Cate indicacin de una necesidad de adaptacin [1 *, c8]
en el tiempo como el con- texto en el que se
aplica el modelo de cambios. tcnicas de medicin de procesos de software se
Las Metas / Preguntas / Mtrica mtodo utilizan para recopilar datos de proceso y producto
(GQM) fue pensado originalmente para el de trabajo, transformar los datos en informacin
establecimiento de actividades La medicin, pero til, y analizar la informacin para identificar las
tambin se pueden utilizar para guiar el anlisis y actividades del proceso que son candidatos para la
mejora de procesos de software. Se puede utilizar mejora. En algunos casos, pueden ser necesarios
para guiar la construccin de informacin de nuevos procesos de software.
software modelo de anlisis impulsada;
resultados obtenidos del modelo de informacin
de software se pueden utilizar
para guiar la mejora del proceso.
El siguiente ejemplo ilustra la aplicacin
del mtodo GQM:

Objetivo: Reducir la solicitud de cambio

promedio
tiempo de procesamiento en un 10% dentro
de los seis meses.
Pregunta 1-1: Cul es el tiempo de
procesamiento de solicitud de cambio de
lnea de base?
Mtricas 1-1-1: Promedio de solicitud de
cambio
los tiempos de procesamiento en la fecha de
inicio
Mtricas 1-1-2: La desviacin estndar del
cambio
tiempos de procesamiento de peticin a la fecha
de inicio
Pregunta 1-2: Cul es la hora actual de
procesamiento de solicitud de cambio?
Mtricas 1-2-1: Promedio de solicitud de
cambio
tiempos procesando en ese momento
Mtricas 1-2-2: La desviacin estndar del
cambio
los tiempos de procesamiento de solicitudes
actualmente
8-12 Gua SWEBOK V3.0 [4 *, S5.1, S5.7,
s9.8]

El propsito de las tcnicas de medicin de

procesos cuantitativos es recoger, transformar
y analizar los datos de proceso cuantitativo y
producto de trabajo que se puede utilizar para
indicar dnde se necesitan mejoras de proceso
y para evaluar los resultados de las iniciativas
de mejora de procesos. Tcnicas de medicin
de proceso cuantitativo se utilizan para COL-
lect y analizar los datos en forma numrica a la
que tcnicas matemticas y estadsticas se
pueden aplicar.
datos de proceso cuantitativos se pueden
recoger como un subproducto de los procesos
de software. Por ejemplo, el nmero de
defectos detectados durante las pruebas de
software y las horas de personal gastados
pueden debe desechar por por medicin
directa, y la productivi- dad de descubrimiento
defecto se pueden derivar por calculat-
defectos ing descubiertos por personal horas.
Herramientas bsicas para el control de
calidad se pueden utilizar para analizar los
datos de medicin de procesos cuantitativos
(por ejemplo, hojas de verificacin, diagramas
de Pareto, histogramas, diagramas de
dispersin, grficos de series, grficos de
control y diagramas de causa y efecto) (vase
el anlisis de causa raz en la Ingeniera
fundamentos KA). Adems, diversas tcnicas
estadsticas se pueden usar de ese rango de
clculo de las medianas y los medios para
mtodos de anlisis multivariante (ver Anlisis
estadstico en los Fundamentos de Ingeniera
KA).
Los datos recogidos usando proceso
cuantitativo medi- tcnicas surement tambin
se pueden utilizar como entradas a los modelos
de simulacin (ver Modelando, Prototyp- Ing,
y Simulacin en la Ingeniera Foundation
ciones KA); estos modelos se pueden utilizar
para evaluar el impacto de diferentes enfoques
para la mejora de procesos de software.
Clasificacin de defectos ortogonal (ODC)
se puede utilizar para analizar los datos Ment
medicin cuantitativa del proceso. ODC se
puede utilizar para los defectos de grupo
detectado en categoras y vincular los defectos
en
 Software de Ingeniera de Procesos
8-13

cada categora para los procesos del proceso de Adems, las herramientas de negocio de
software o software, donde un grupo de defectos propsito general, tal como una hoja de clculo,
origi- NATed (ver Defecto Caracterizacin en la puede ser til.
Soft mercancas Quality KA). defectos interfaz Ingeniera de Software (CASE), herramientas
de software, por ejemplo, pueden haberse de ayuda de computadora pueden reforzar el uso
originado durante una inade- equiparan proceso de procesos integrados, apoyar la ejecucin de
de diseo de software; mejorar el proceso de las definiciones de procesos defi-, y
diseo de software reducir el nmero de proporcionar orientacin a los seres humanos en
defectos de la interfaz de software. ODC puede la formacin de per- procesos bien definidos.
proporcionar datos cuantitativos para la herramientas simples, tales como procesadores
aplicacin de anlisis de causa raz. Control de texto y hojas de clculo se pueden utilizar
Estadstico de Procesos se puede utilizar para para preparar las descripciones textuales de pro-
realizar un seguimiento de la estabilidad del cesos, actividades y tareas; Estas herramientas
proceso, o la falta de estabilidad del proceso, tambin SUP- puerto de trazabilidad entre las
el uso de grficos de control. entradas y salidas de mltiples procesos de
software (como el anlisis de las necesidades de
4.4.2. Tcnicas de medicin de procesos los interesados, los requisitos de software cin
cualitativos especificaciones, arquitectura de software, y el
[1 *, s6.4] diseo detallado de software), as como los
resultados de los procesos de software como la
Cualitativa tcnicas- medicin de procesos que documentacin , componentes de software,
incluyen entrevistas, cuestionarios y la opinin casos de prueba, y la informacin de errores.
de expertos, se puede utilizar para aumentar las La mayor parte de las reas de conocimiento
tcnicas de medicin de procesos cuantitativos. en esta gua se describen las herramientas
tcnicas de consenso del grupo, incluyendo la especializadas que pueden ser utilizados para
tcnica Delphi, se pueden utilizar para obtener gestionar los procesos dentro de ese KA. En
un consenso entre los grupos de interesados. particu- lar, vase la Gestin de la Configuracin
de Software KA para una discusin de las
5. Herramientas de Ingeniera de Software herramientas de gestin de configuracin de
Process software que pueden ser utilizados para
[1 *, s8.7] gestionar la construccin, integracin y procesos
para liberar los productos de software. Otras
herramientas de proceso de software soportan herramientas, como los de gestin de requisitos
muchas de las notaciones ciones utilizadas para y pruebas, se describen en la KAs apropiado.
definir, implementar y gestionar los procesos de herramientas de proceso de software pueden
software individuales y los modelos del ciclo de apoyar proyectos que involucran
vida del software. Incluyen editores para geogrficamente equipos dispersos (virtuales).
anotaciones tales como diagramas de flujo de Cada vez ms, las herramientas de proceso de
datos, grficos de estado, BPMN, diagramas software estn disponibles a travs de las
IDEF0, redes de Petri, y los diagramas de instalaciones de computacin en la nube, as
actividad UML. En algunos casos, las como a travs de infraestructuras dedicadas.
herramientas de proceso de software permiten Un panel de control de proyectos o en el
diferentes tipos de anlisis y simulaciones (por salpicadero pueden dis- proceso seleccionado el
ejemplo, de simulacin de eventos discretos). En juego y los atributos del producto para proyectos
de software e indicar las medidas que estn
dentro de los lmites de control y aquellos que
necesitan una accin correctiva.
8-14 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

2011 [3 *]
2009 [1

2009 [2
JustaLey de

Kan 2003
SommervilLe

[4 *]
Mugirre
*]

*]
p28-29,
1. Definicin del proceso de software P177 P295 p36,
c5
1.1. Gestin de procesos de software s26.1 p453-454
P183, P186
1.2. Infraestructura de Procesos de p437-438
Software
2. Ciclos de vida del software c2 p190
c22, c23,
2.1. Categoras de procesos de software prefacio p294-295
c24
2.2. Modelos de Ciclo de vida del c2 S3.2 S2.1
software
2.3. La adaptacin de procesos de s2.7 p51
software
2.4. Consideraciones prcticas p188-190
3. Software de Evaluacin y
P188, P194 c26 P397, c15
Mejora de Procesos
S4.5,
3.1. Modelos de evaluacin de procesos de s26.5 p44-48
S4.6
software
3.2. Evaluacin de Procesos de Software p44-48,
p322-331 s26.3
mtodos s16.4
3.3. Modelos de mejora de procesos
p187-188 s26.5 s2.7
de software
3.4. Calificaciones continuas y puesta en p28-34 s26.5 p39-45
4. escena
Medicin de Software s26.2 s18.1.1
4.1. Proceso de software y de productos S6.3, s26.2,
Medicin P273 P638
S3.4,
S3.5,
4.2. Calidad de los resultados de
S3.6,
medicin
s3.7
4.3. Informacin de software Modelos p310-311 pag. 712- s19.2
713 S5.1,
4.4. Medicin de Procesos de Software s6.4,
S5.7,
tcnicas c8
s9.8
5. Proceso de Ingeniera de Software s8.7
Herramientas
 Software de Ingeniera de Procesos
8-15

LECTURAS forman las evaluaciones de proceso.

Software de la extensin de la Gua para la

Direccin de Proyectos de Knowledge
(SWX) [5].

SWX ofrece adaptaciones y ampliaciones de las

prcticas genricas de gestin de proyectos
documentado en la Gua PMBOK para la
gestin de proyectos de software. La principal
contribucin de esta extensin de la Gua del
PMBOK es descrip- cin de los procesos que
son aplicables para la gestin de proyectos de
software de ciclo de vida de adaptacin.

D. Gibson, D. Goldenson, y K. Kost,

Rendimiento de resultados de mejora
de proceso basado en CMMI [6].

Este informe tcnico resume pblicamente

dispo- evidencia emprica poder sobre los
resultados de rendimiento que pueden ocurrir
como consecuencia de la mejora de procesos
basados CMMI-. El informe contiene una serie
de breves descripciones de casos que fueron
CREADA con la colaboracin de representantes
de 10 organizaciones que han logrado notables
resultados de rendimiento cuantitativo a travs
de sus esfuerzos de mejora basados en CMMI.

CMMI para el Desarrollo, versin 1.3 [7].

CMMI para el Desarrollo, versin 1.3

proporciona un conjunto integrado de directrices
para el proceso de ING Desa- y la mejora de
productos y servicios. Estas directrices incluyen
las mejores prcticas para el desarrollo y mejora
de productos y servicios para satisfacer las
necesidades de los clientes y usuarios finales.

ISO / IEC 15504-1: 2004 Informacin

tecnologa-Proceso de evaluacin-Parte 1:
Conceptos y vocabulario [8].

Este estndar, conocido comnmente como

SPICE (Software Mejora de Procesos y
determinacin de la capacidad), incluye
mltiples partes. Parte 1 proporciona conceptos
y vocabulario para los procesos de desarrollo de
software y funciones de gestin de negocio-
relacionados. Otras partes de 15504 definen los
requisitos y procedimientos para per- que
8-16 Gua SWEBOK V3.0
Referencias

[1 *] RE Fairley, gestionar y liderar proyectos

de software, Wiley-IEEE Computer
Society Press, 2009.

[2 *] JW Moore, La Hoja de Ruta de Ingeniera

de Software: Una gua basada en
estndares, Wiley-IEEE Computer Society
Press, 2006.

[3 *] I. Sommerville, Ingeniera de Software, 9

ed., Addison-Wesley, 2011.

[4 *] SH Kan, mtricas y modelos en Ingeniera

de Software de Calidad, 2 ed., Addison-
Wesley, 2002.

[5] Instituto de Gestin de Proyectos y IEEE

Computer Society, software de la
extensin de la Gua del PMBOK
quinta edicin, ed: Project Management
Institute, 2013.

[6] D. Gibson, D. Goldenson, y K. Kost,

Rendimiento Resultados de la mejora
de procesos basado en CMMI,
Software Engineering Institute, 2006;
http: //
resources.sei.cmu.edu/library/asset-
view. cfm? assetId = 8065.

[7] CMMI equipo de productos, CMMI

para el Desarrollo, Versin 1.3,
Software Engineering Institute, 2010;
http: //
resources.sei.cmu.edu/library/asset-
view. cfm? assetId = 9661.

[8] ISO / IEC 15504-1: 2004, Informacin

Tecnologa-Proceso de Evaluacin-Parte
1: Conceptos y Vocabulario, ISO / IEC
2004.
 Software de Ingeniera de Procesos
8-17

CAPTULO 9

Modelos y mtodos de software de

ingeniera

SIGLAS DISTRIBUCIN DE TEMAS PARA

MODELOS Y MTODOS DE
3GL Idioma tercera generacin INGENIERA DE SOFTWARE
BNF Backus-Naur Form
FDD Desarrollo de funciones-Driven Este captulo sobre modelos de ingeniera de
software y
Desarrollo integrado
IDE mtodos se divide en cuatro reas temticas
Ambiente
principales:
PBI Producto Cartera de artculos
RAD Desarrollo rpido de aplicaciones Modelado: Se analiza la prctica general de
UML Lenguaje de Modelado Unificado la modelizacin y presenta temas en los
principios de modelado; propiedades y
XP Programacin extrema
expresin de los modelos; modelado de
sintaxis, la semntica y la pragmtica; y las
INTRODUCCIN condiciones previas, postcondi- ciones, e
invariantes.
modelos y mtodos de ingeniera de software Tipos de modelos: Brevemente discute
imponen estructura en la ingeniera de software modelos y agregacin de submodelos y
con el objetivo de hacer que la actividad proporciona algunas caractersticas
sistemtica y repetible, y en definitiva ms generales de los tipos de modelo
xito-orientado. El uso de modelos proporciona comnmente encontradas en la prctica de
un enfoque para la resolucin de problemas, una la ingeniera de software.
notacin, y los procedimientos para la Anlisis de Modelos: Presenta algunas de las
construccin y anlisis de modelo. Mtodos tcnicas de anlisis comunes utilizados en
proporcionan una aproximacin a la ing modelo- para verificar la integridad, la
especificacin sistemtica, diseo, construccin, consistencia, rectness cor-, trazabilidad, y la
pruebas y verificacin del software de punto interaccin.
final y los productos de trabajo asociados. Mtodos de ingeniera de software: Presenta
modelos y mtodos de ingeniera de software un breve resumen de los mtodos de
varan ampliamente en su alcance-de abordar ingeniera de software de uso comn. La
una sola fase del ciclo de vida del software de discusin se gua al lector a travs de un
cubrir el ciclo de vida del software pleta com-. resumen de los mtodos heursticos,
El nfasis en esta rea de conocimiento (KA) mtodos formales, la creacin de prototipos,
est en ingeniera de software modelos y y los mtodos giles.
mtodos que abarcan mltiples fases del ciclo de
vida del software, ya que los mtodos El desglose de los temas para los modelos de
especficos para las fases individuales del ciclo ingeniera de software y mtodos KA se muestra
de vida estn cubiertas por otra KAs. en la Figura 9.1.

1. Modelado
Modelizacin de software se est convirtiendo tcnica para ayudar a los ingenieros de software a
en un omnipresente entender,

9-1
9-2 Gua SWEBOK V3.0

Figura 9.1. Desglose de los temas de los modelos de ingeniera de software y mtodos KA

ingeniero, y comunicar los aspectos del soft- decisiones sobre el software o elementos de la
ware a las partes interesadas pertinentes. Las misma, y la comunicacin de los
partes interesadas son aquellas personas o partes
que tienen un inters explcitas o implcitas en el
software (por ejemplo, usuario, comprador,
proveedor, arquitecto, certificando autori- dad,
evaluador, desarrollador, ingeniero de software,
y tal vez otros).
Si bien hay muchos lenguajes de modelado,
notaciones, tcnicas y herramientas en la
literatura y en la prctica, hay que unifica
conceptos generales que se aplican en alguna
forma a todos ellos. Las siguientes secciones
proporcionan antecedentes sobre estos conceptos
generales.

1.1. Principios de modelado

[1 *, C2S2, c5s1, c5s2] [2 *, C2S2] [3 *,
c5s0]

Modelado proporciona al ingeniero de software

con un enfoque organizado y sistemtico de los
aspectos significativos tando sentantes de
software en estudio, facilitando la toma de
 Modelos de Ingeniera de Software y Mtodos 9-
decisiones importantes a otros en las 3
comunidades interesadas. Hay tres principios
generales que guan este tipo de actividades de
modelado:

Modelar los Fundamentos: Buenos

modelos no suelen representan cada
aspecto o caracterstica del software bajo
todas las condiciones posibles. Modelado
por lo general implica el desarrollo de slo
aquellos aspectos o caractersticas del
software que necesitan respuestas
especficas, abstraerse de cualquier
informacin no esencial. Este enfoque
mantiene los modelos manejable y til.
proporcionar Perspectiva: Modelado
proporciona vistas del software bajo
estudio utilizando un conjunto definido de
normas para la expresin del modelo
dentro de cada vista. Este enfoque
perspectiva- impulsado proporciona
dimensionalidad al modelo (por ejemplo,
una vista estructural, vista del
comportamiento, vista temporal, vista
organizativa, y otros puntos de vista como
relevante). La organizacin de la
informacin en vistas centra los esfuerzos
de modelado de software en concreto
9-4 Gua SWEBOK V3.0

preocupaciones pertinentes a la vista aseveraciones, restricciones, funciones o

mediante las apropiadas notacin, el descripciones de componentes.
vocabulario, mtodos y herramientas. Exactitud: El grado en que el modelo
Permitir comunicaciones efectivas: satisface sus necesidades y cationes de diseo
Modelado emplea el dominio de aplicacin especificacin y est libre de defectos.
del vocabulario del software, un lenguaje de
modelado, y la expresin semntica (en
otras palabras, tras tanto dentro del contexto
ing). Cuando se utiliza de manera rigurosa y
sistemtica, esta modelado resultado en un
enfoque de informes que facilita la
comunicacin eficaz de la informacin de
software para interesados en el proyecto.

Un modelo es una abstraccin o

simplificacin de un componente de software.
Una consecuencia del uso de la abstraccin es
que hay una nica abstraccin completa- mente
describe un componente de software. Por el
contrario, el modelo del software se representa
como una agregacin de abstracciones, que,
cuando se toman juntos-describir aspectos
seleccionados, perspectivas o puntos de vista,
slo aquellos que son necesarios para tomar
decisiones informadas y responder a las razones
de la creacin de la modelo en el primer lugar.
Esta simplificacin conduce a un conjunto de
supuestos sobre el contexto en el que se coloca
el modelo que tambin deben ser capturado en el
modelo. Entonces, al reutilizar el modelo, estos
supuestos pueden ser validados primero en
establecer la relevancia del modelo reutilizados
dentro de su nuevo uso y el contexto.

1.2. Propiedades y Expresin de Modelos

[1 *, c5s2, c5s3] [3 *, c4s1.1p7,
c4s6p3,
c5s0p3]

Propiedades de los modelos son aquellos las

distintas prestaciones distintivas de un modelo
en particular utilizados para caracterizar su
integridad, la consistencia y exactitud dentro de
la notacin de modelado elegido y utillaje
utilizado. Propiedades de los modelos incluyen
los siguientes:

Lo completo: El grado en que se han

aplicado todos los requisitos y comprobada
dentro del modelo.
Consistencia: El grado en que el modelo no
contiene requisitos conflictivos, ciones
 Modelos de Ingeniera de Software y Mtodos 9-
Los modelos se construyen para representar 5
objetos del mundo real y sus comportamientos Los modelos pueden ser sorprendentemente
para responder a preguntas especficas acerca engaoso. El hecho de que un modelo es una
de cmo se espera que el software para operar. abstraccin con la falta de informa- cin puede
Interrogar a los modelos, ya sea a travs de la conducir a uno en un falso sentido de completa-
exploracin, simulacin, o revisin-puede mente la comprensin del software de un solo
exponer reas de incertidumbre dentro del modelo. Un modelo completo ( completo
modelo y el software al que se refiere el siendo
modelo. Estas incertidumbres y preguntas sin
respuesta sobre los requisitos, diseo y / o
implementacin pueden ser manejados de
manera apropiada.
El elemento de expresin primaria de un
modelo es una entidad. Una entidad puede
representar artefactos de hormign (por
ejemplo, procesadores, sensores, o robots) o
artefactos abstractas (por ejemplo, mdu- los
de software o protocolos de comunicacin).
entidades modelo se conectan a otras entidades
que utilizan rela- ciones (en otras palabras,
lneas o los operadores textuales en las
entidades de destino). Expresin de las
entidades modelo se puede realizar usando
textuales o grficas lenguajes de modelado;
Ambos tipos de lenguaje de modelado se
conectan a travs de entidades del modelo de
construcciones del lenguaje especficos. El
significado de una entidad puede ser
representado por su forma, atributos de texto, o
ambos. En general, la informacin textual se
adhiere a la estructura sintctica del idioma.
Los significados Cise previas relacionadas con
el modelado de contexto, estructura y
comportamiento de uso de estas entidades y las
relaciones depende del lenguaje de modelado
utilizado, el rigor del diseo aplicado al
esfuerzo de modelado, la vista especfica est
construyendo, y la entidad a la que el elemento
notacin especfica puede estar unido.
Mltiples vistas del modelo pueden ser
necesarios para capturar la semntica
necesarios del software.
Al usar los modelos soportados con
automatizacin cin, los modelos se pueden
comprobar la integridad y consistencia. La
utilidad de estas comprobaciones depende en
gran medida del nivel de rigor tctica
semntica y sin- aplicada al esfuerzo de
modelado en adi- cin al soporte de
herramientas explcita. La correccin es
Tpicamente comprobado a travs de la
simulacin y / o revisin.

1.3. Sintaxis, la semntica y la pragmtica

[2 * c2s2.2.2p6] [3 *,
c5s0]
9-6 Gua SWEBOK V3.0

en relacin con el esfuerzo de modelado) puede entorno de modelado; esto puede no ser obvia. El
haber una unin de varios submodelos y modelo debe ser revisado para supuestos
cualquiera de los modelos de funcin especiales. documentados. Mientras que la sintaxis de
El examen y la relacin tivo de toma de modelado puede ser idntico, el modelo puede
decisiones a un modelo nico dentro de esta significar algo muy diferente en el nuevo entorno,
coleccin de submodelos pueden ser que es un contexto diferente. Adems, consideran
problemticos. que como software madura y se realizan cambios,
La comprensin de los significados precisos de la discordia semntica
constructos ELING MOD- tambin puede ser
difcil. lenguajes de modelado se definen por
reglas sintcticas y semnticas. Para lenguajes
textuales, la sintaxis se define utilizando una
gramtica notacin que define construcciones
len- guaje vlidos (por ejemplo, la Forma
Backus-Naur (BNF)). Para lenguajes grficos, la
sintaxis se define usando modelos grficos
llamados els metamod-. Al igual que con BNF,
metamodelos definen las construcciones
sintcticas vlidas de un lenguaje de modelado
grfico; metamodelo define cmo estos
constructos se pueden componer para producir
modelos vlidos. La semntica de lenguajes de
modelado especifican el significado que se
atribuye a las entidades y relaciones capturados
dentro del modelo. Por ejemplo, un diagrama
simple de dos cajas conectadas por una lnea est
abierto a una variedad de interpretaciones.
Sabiendo que el diagrama en el que se colocan las
cajas y CONECTADOS es un diagrama de objeto
o un diagrama de actividad
puede ayudar en la interpretacin de este
modelo.
Como cuestin prctica, por lo general hay un
buen entendimiento de la semntica de un
modelo de software especfico debido al
lenguaje de modelado elegido, cmo se utiliza
ese lenguaje de modelado para expresar las
entidades y las relaciones dentro de ese modelo,
la base de la experiencia del modelador (s) y el
contexto dentro del cual se ha llevado a cabo el
modelado y representado. El significado se com-
municated a travs del modelo incluso en
presencia de informacin incompleta a travs de
abstraccin; pragmtica explica cmo el
significado se materializa en el modelo y su
contexto y comunicarse efectivamente a otros
ingenieros de software.
Todava hay casos, sin embargo, donde se
necesita cautela cin en relacin con el
modelado y la semntica. Por ejemplo, las piezas
modelo importado de otro modelo o de la
biblioteca deben ser examinados para supuestos
semnticos que entran en conflicto en el nuevo
puede ser introducido, lo que conduce a especfico; queModelos
puededeestar
Ingeniera de Software
compuesta y Mtodos
de uno o 9-
7
errores. Con muchos ingenieros de software ms diagramas. La coleccin de submodelos
que trabajan en una parte del modelo con el puede emplear mltiples
tiempo junto con las actualizaciones de la
herramienta y tal vez nuevas exigencias, hay
oportunidades para partes del modelo para
representar algo diferente de la intencin del
autor original y el contexto modelo inicial.

1.4. Condiciones previas,

postConditions, e invariantes
[2 *, c4s4] [4 *, c10s4p2,
c10s5p2p4]

Al modelar las funciones o mtodos, el

ingeniero de software suele comenzar con un
conjunto de suposiciones sobre el estado del
software antes de, durante y despus de la
funcin o mtodo cutis eje-. Estos supuestos
son esenciales para el funcionamiento rect
angular de la funcin o mtodo y se agrupan,
para la discusin, como un conjunto de
condiciones previas, postcondiciones, e
invariantes.

Condiciones previas: Un conjunto de

condiciones que deben ser satisfechas
antes de la ejecucin de la funcin o
mtodo. Si estas condiciones previas no se
sostienen antes de la ejecucin de la
funcin o mtodo, la funcin o mtodo
pueden producir resultados involuntaria de
OU.
poscondiciones: Un conjunto de
condiciones que se garantiza que sea cierto
despus de la funcin o mtodo ha
ejecutado con xito. Por lo general, las
condiciones posteriores representan cmo
el estado del software ha cambiado, cmo
par- metros pasados a la funcin o
mtodo han cambiado, cmo los valores
de datos han cambiado, o cmo se ha visto
afectado el valor de retorno.
invariantes: Un conjunto de condiciones
dentro del entorno operativo que persisten
(en otras palabras, no cambie) antes y
despus de la ejecucin de la funcin o
mtodo. Estas invariantes son pertinentes
y necesarios para el software y el correcto
funcionamiento de la funcin o mtodo.

2. tipos Modelos de

Un modelo tpico consiste en una agregacin

de submodelos. Cada submodelo es una
descripcin parcial y se crea para un propsito
9-8 Gua SWEBOK V3.0

lenguajes de modelado o una sola modelado evento de activacin guardado o descuido que se
LANGUAGE. El Lenguaje de Modelado produce en el entorno de modelado. modelos de
Unificado (UML) reconoce una rica coleccin flujo de control representan cmo una secuencia
de modelar dia- gramos. El uso de estos de acontecimientos provoca procesos para ser
diagramas, junto con las construcciones del activado o desactivado. Los datos de flujo
lenguaje de modelado, lleva cerca de tres tipos tamiento ior se tipifica como una secuencia de
de modelos generales de uso comn: los pasos donde los datos se mueve a travs de
modelos de informacin, modelos de procesos hacia almacenes de datos o sumideros de
comportamiento, y los modelos de estructura datos.
(ver seccin 1.1).

2.1. Modelado de informacin

[1 *, c7s2.2] [3 *, c8s1]

modelos de informacin proporcionan un foco

central en datos e informacin. Un modelo de
informacin es una representacin abstracta que
identifica y define un conjunto de conceptos,
propiedades, relaciones y con- straints en
entidades de datos. El modelo de informacin
semntica o tual concepcin se utiliza a menudo
para proporcionar algo de formalismo y el
contexto para el software que se modela como se
ve desde la perspectiva problema, sin
preocuparse de cmo este modelo es en realidad
asignado a la implementacin del software. El
modelo de informacin semntica o conceptual
es una abstraccin y, como tal, incluye slo los
conceptos, propiedades, relaciones y
restricciones necesarias para conceptualizar el
punto de vista del mundo real de la informacin.
transformaciones posteriores del modelo de
informacin semntica o conceptual conducen a
la elaboracin de modelos de datos, entonces
Physicians cal lgico y como se implementa en
el software.

2.2. Modelado del comportamiento

[1 *, c7s2.1, c7s2.3, c7s2.4] [2 *, c9s2]
[3 *,
c5s4]

modelos de comportamiento identifican y

definen las fun- ciones del software que est
siendo modelado. Tamiento modelos ioral
generalmente tomar tres formas bsicas:
mquinas de estado, los modelos de flujo de
control, y Data- modelos de flujo. Las mquinas
de estado proporcionan un modelo de software
como una coleccin de estados definidos,
eventos y transiciones. Las transiciones de
software de un estado a otro por medio de un
2.3. Modelado estructura modelosModelos de Ingeniera
de estado de Software
se alcanzan por uny Mtodos
conjunto9-
9
[1 *, c7s2.5, c7s3.1, c7s3.2] [3 *, c5s3] [4 *, c4] de entradas correctas); modelos tambin se
pueden examinar para Ness COMPLETE-
modelos de estructura ilustran la composicin manualmente mediante inspecciones u otras
fsica o lgica de software a partir de sus tcnicas de revisin (ver la calidad KA
diversas partes compo- nente. modelado de Software). errores
estructuras establece el lmite definido entre el
software en ejecucin o modelado y el entorno
en el cual se va a operar. Algunas
construcciones estructurales comunes
utilizados en el modelado de la estructura son
la composicin, la descomposicin, la
generalizacin y especializacin de entidades;
identificacin de las relaciones Evant rel- y
cardinalidad entre entidades; y la definicin de
proceso o caras inter funcionales. diagramas de
estructura proporcionados por el UML para el
modelado de la estructura incluyen clases,
componentes, objetos, despliegue y diagramas
de embalaje.

3. Anlisis de Modelos

El desarrollo de modelos permite el ingeniero

de software la oportunidad de estudiar, razonar
sobre, y comprender la estructura, funcin, uso
fun- cional, y las consideraciones de montaje
se asocia a los programas. Es necesario un
anlisis de los modelos construidos para
asegurar que estos modelos son completos,
coherentes, y lo suficientemente correcta para
servir a su propsito previsto para las partes
interesadas.
Las secciones siguientes describen
brevemente las tcnicas de anlisis utilizadas
generalmente con modelos de software para
asegurarse de que el ingeniero de software y
otras partes interesadas adquieren valor
adecuado en el desarrollo y uso de modelos.

3.1. Para completar el anlisis

[3 *, c4s1.1p7, c4s6] [5 *, P8-
11]

Con el fin de tener un software que satisfaga

plenamente las necesidades de los interesados,
la integridad es crtico del proceso de
obtencin de requisitos para codificar
mentacin imple-. Integridad es el grado en el
que todos los requisitos especificados han sido
implementado y verificado. Los modelos
pueden ser comprobados por la totalidad de
una herramienta de modelado que utiliza
tcnicas tales como el anlisis estructural y
anlisis de espacio de estado de accesibilidad
(que aseguran que todos los caminos en los
9-10 Gua SWEBOK V3.0

y avisos generados por estas herramientas de

anlisis y demostrado en una inspeccin o El desarrollo de software normalmente implica el
revisin indican las acciones correctivas uso, creacin y modificacin de muchos
necesarias probables para garantizar la productos de trabajo, tales como documentos de
integridad de los modelos. planificacin, especificacin ciones de proceso,
requisitos de software, diagramas, diseos
3.2. La consistencia para analizar
[3 *, c4s1.1p7, c4s6] [5 *, P8-11]

La consistencia es el grado en que los modelos

con- tienen no hay requisitos en conflicto,
afirmaciones, straints con-, funciones o
descripciones de componentes. Tpicamente, la
comprobacin de consistencia se logra con la
herramienta de modelado utilizando una funcin
de anlisis automatizado; modelos tambin se
pueden examinar para consistencia de forma
manual mediante inspecciones u otras tcnicas
de revisin (ver la calidad KA Software). Al
igual que con integridad, errores y avisos
generados por estas herramientas de anlisis y
demostrado en una inspeccin o revisin indican
la necesidad de una accin correctiva.

3.3. El anlisis de la correccin

[5 *, P8-11]

La correccin es el grado en que un modelo sat-

isfies sus requisitos de software y las
especificaciones de diseo de software, est libre
de defectos, y, en ltima instancia, cumple las
necesidades de los interesados. El anlisis de la
correccin incluye la verificacin de correccin
sintctica del modelo (es decir, el uso correcto
de la gramtica lenguaje de modelado y
construcciones) y la verificacin de la
correccin semntica del modelo (es decir, el
uso del lenguaje de modelado construye para
representar correctamente el significado de que
que est siendo modelado). Para analizar un
modelo de correccin sintctica y semntica, se
analiza que, ya sea de forma automtica (por
ejemplo, usando la herramienta de modelado
para comprobar modelo correccin sintctica) o
manualmente (mediante inspecciones u otras
tcnicas de revisin) -searching para posibles
defectos y luego retirar o la reparacin de los
defectos confirmados antes de que el software
est liberado para su uso.

3.4. trazabilidad
[3 *, c4s7.1, c4s7.2]
y pseudo-cdigo, cdigo escrito a mano y anlisis para Modelos de Ingeniera
el ingeniero de de Software ypara
software Mtodos 9-
11
generado herramienta, casos manuales y revisar el diseo de interaccin y verificar que
automatizados de prueba e informes, y las diferentes partes de la obra de software
archivos y datos. Estos productos de trabajo juntos para proporcionar las funciones previstas.
pueden estar relacionados a travs de diferentes
relaciones de dependencia (por ejemplo, usos,
implementos, y las pruebas). A medida que se
desarrolla el software, gestionar, mantener, o
extendido, hay una necesidad de asignar y
controlar estas relaciones de trazabilidad para
demostrar los requisitos de software coherencia
con el modelo de software (consulte Requisitos
de seguimiento en los requisitos de software
KA) y los muchos productos de trabajo. El uso
de trazabilidad suele mejorar el manage- ment
de productos de trabajo de software y software
de calidad pro- ceso; sino que tambin
proporciona garantas a los titulares de stake-
que todos los requisitos se han cumplido. La
trazabilidad permite cambiar el anlisis una vez
que el software es desarrollado y puesto en
libertad, ya que las relaciones a los productos
de trabajo de software fcilmente se pueden
desplazar para evaluar el impacto del cambio.
Las herramientas de modelado suelen
proporcionar alguna automatizado o manual de
los medios para espec- ify y gestionar enlaces
de trazabilidad entre los requisitos, diseo,
cdigo y / o entidades de prueba que puedan
ser representados en los modelos y otros
productos de trabajo de software. (Para obtener
ms informacin sobre la trazabilidad, ver el
KA Software Configuration Management).

3.5. Anlisis de interaccin

[2 *, c10, c11] [3 *, c29s1.1, c29s5] [4 *,
c5]

Interaccin anlisis se centra en las relaciones

de las comunicaciones o de control de flujo
entre entidades utilizadas para llevar a cabo
una tarea o funcin especfica dentro del
modelo de software. Este anlisis plos ines el
comportamiento dinmico de las interacciones
entre las diferentes porciones del modelo de
software, incluyendo otras capas de software
(tal como el sistema oper- ating, middleware, y
aplicaciones). Tambin puede ser importante
para algunas aplicaciones de software para
examinar las interacciones entre la aplicacin
de software orde- nador y el software de
interfaz de usuario. Algunos entornos de
modelado de software proporcionan
instalaciones de simulacin para estudiar
aspectos del comportamiento dinmico de
software de modelado. de ping paso- a travs
de la simulacin proporciona una opcin de
9-12 Gua SWEBOK V3.0

4. Mtodos de ingeniera de software modelo de datos se construye desde el punto

de vista de los datos o informaciones
Software mtodos de ingeniera proporcionan un utilizados. Las tablas de datos y barcos
enfoque sistemtico y nizado or- al desarrollo de PARENTESCO definen los modelos de
soft- ware para un equipo de destino. Existen datos. Este mtodo mo- datos eling se utiliza
numerosos mtodos entre los que elegir, y es principalmente para definir y analizar las
importante para el ingeniero de software para necesidades de datos de apoyo
elegir un mtodo o mtodos para la tarea de
desarrollo de software a la mano apropiada; esta
eleccin puede tener un efecto dramtico en el
xito del proyecto de software. El uso de estos
mtodos de ingeniera de software, junto con la
gente de la derecha conjunto de habilidades y
herramientas permiten a los ingenieros de
software para visualizar los detalles del software
y, finalmente, transformar la representacin en
un conjunto de trabajo de cdigo y datos.
mtodos de ingeniera de software
seleccionados se dis- cussed a continuacin. Las
reas temticas se organizan en las discusiones
de los mtodos heursticos, Mtodos formales,
mtodos de prototipos, y los mtodos giles.

4.1. Los mtodos heursticos

[1 *, c13, c15, c16] [3 *, c2s2.2, c5s4.1,
c7s1,]

Los mtodos heursticos son aquellos mtodos

de ingeniera de software basados en la
experiencia que han sido y son bastante
ampliamente practicados en el software indus-
tria. Esta rea temtica contiene tres grandes
categoras: Discusin del anlisis estructurado y
mtodos de diseo, mtodos de modelado de
datos y mtodos de anlisis y diseo orientados
a objetos.

Anlisis estructurado y mtodos de diseo:

El modelo de software se desarrolla
principalmente a partir de un punto de vista
funcional o conductual, a partir de una vista
de alto nivel del software (incluyendo
elementos de datos y de control) y luego
descomponiendo progresivamente o refin-
ing los componentes del modelo a travs de
increas- diseos vez ms detalladas . El
diseo detallado finalmente converge a los
detalles o especificaciones del software que
deben codificarse muy especficos (con la
mano, generado automticamente, o
ambos), construido, probado y verificado.
Los mtodos de modelado de datos: El
 Modelos
anlisis dederequerimientos,
Ingeniera de Software
y / oy Mtodos 9-
etapas de
diseos de bases de datos o datos de 13
repositorios Tpicamente encuentran en diseo especfico para describir la entrada /
software de negocios, donde los datos se salida comportamiento. lenguajes de
gestiona activamente como un recurso especificacin son idiomas no directamente
sistemas de negocio o activo. ejecutables; son
ods Anlisis y Diseo Orientado a Objetos
met-: El modelo orientado a objetos se
representa como una coleccin de objetos
que encapsulan datos y las relaciones e
interactuar con otros objetos a travs de
mtodos. Los objetos pueden ser objetos
del mundo real o elementos virtuales. El
modelo de software se construye
utilizando diagramas para constituir vistas
seleccionadas del software. refinamiento
progresivo del software mode- los conduce
a un diseo detallado. El diseo detallado
se luego se convirti bien a travs de
iteracin sucesiva o transformada
(utilizando algn mecanismo) en la vista
de la implementacin del modelo, donde el
cdigo y Envoltorios enfoque para el
lanzamiento eventual producto de software
y el despliegue ing se expresa.

4.2. Mtodos formales

[1 *, c18] [3 *, c27] [5 *, p8-
24]

Los mtodos formales son los mtodos de

ingeniera de software utilizadas para
especificar, desarrollar y verificar el software
mediante la aplicacin de un riguroso notacin
y lenguaje basado camente mathemat-. A
travs del uso de un lenguaje de especificacin,
el modelo de software se puede comprobar la
consistencia (en otras palabras, la falta de
ambigedad), integridad, y la correccin de
forma sistemtica y automatizada o la moda
semi-automatizado. Este tema est relacionado
con la seccin de anli- sis formal de los
requisitos de software KA.
Esta seccin se ocupa de los lenguajes de
especificacin, el refinamiento de programas y
de derivacin, cationes verificables formal, y la
inferencia lgica.

especificacin de Idiomas: Lenguajes de

especificacin proporcionan la base
matemtica de un mtodo formal;
lenguajes de especificacin son formales,
los lenguajes de programacin de alto
nivel (en otras palabras, no es un lenguaje
clsico de tercera generacin (3GL)
programa- lenguaje ming) utilizado
durante la especificacin de software,
9-14 Gua SWEBOK V3.0

tpicamente compuesto de una notacin y predecir el comportamiento del software sin

sintaxis, la semntica para el uso de la tener que ejecutar el software. Algunos
notacin, y un conjunto de relaciones entornos de desarrollo integrado (IDE)
permitidos para objetos. incluyen formas de representar estas pruebas
Programa de Perfeccionamiento y junto con el diseo o cdigo.
Derivacin: Pro- gram refinamiento es el
proceso de creacin de un nivel ms bajo (o
ms detallada) especificacin utilizando una
serie de transformaciones. Es a travs de
sucesivas transformaciones que el ingeniero
de software se deriva una representacin
ejecutable de un programa. Las
especificaciones pueden ser refinados,
aadiendo detalles hasta que el modelo se
puede formu- lated en un lenguaje de
programacin 3GL o en una parte ejecutable
de la lengua especifica- cin elegida. Este
refinamiento especificacin se hace posible
mediante la definicin de las
especificaciones con propiedades
semnticas precisas; las especificaciones
deben establecer no slo las relaciones entre
las entidades, sino tambin los significados
de tiempo de ejecucin exactos de esas
relaciones y operaciones.
La verificacin formal: Modelo de cheques
es un mtodo de verificacin formal; que
por lo general implica la realizacin de
anlisis cin o de alcanzabilidad un
exploratorios espacio de estado para
demostrar que el diseo de software
representado tiene o conserva ciertas
propiedades modelo de inter- est. Un
ejemplo de comprobacin de modelo es un
anlisis que verifica programa correcto
comporta- ior bajo posible entrelazado de
eventos o mensajes llegados. El uso de
cationes verificables formales requiere un
modelo determinado de forma rigurosa el
software y en su entorno operativo; este
modelo a menudo toma la forma de una
mquina de estados finitos u otro autmata
formalmente definido.
La inferencia lgica: La inferencia lgica es
un mtodo de diseo de software que
implica especificar las condiciones previas y
condiciones posteriores alrededor de cada
bloque importante del diseo, y el uso de la
lgica del desarrollo de la prueba de que las
condiciones previas y condiciones
posteriores deben tener en todas las entradas
matemtica. Esto proporciona una manera
para que el ingeniero de software para
 Modelos
interesados en deelIngeniera de Software
proyecto, y Mtodos 9-
impulsado
4.3. Los mtodos de prototipado 15
[1 *, c12s2] [3 *, c2s3.1] [6 *, principalmente por las razones subyacentes
c7s3p5] que llevaron a promover el desarrollo del
totipo en el primer lugar. totypes Pro-
creacin de prototipos de software es una pueden ser evaluados o probados contra el
actividad que generalmente crea siones ver- software implementado real o contra
incompletas o mnimamente funcionales de
una aplicacin de software, por lo general
para prueba- ing nuevas caractersticas,
solicitando informacin sobre los requisitos
de software o interfaces de usuario, fur- Ther
explorar requisitos de software, diseo de
software, o opciones de implementacin, y / o
la obtencin de alguna otra informacin til
sobre el software. El ingeniero de software
selecciona un mtodo de creacin de
prototipos para entender el menos aspectos o
compo- nentes del software primero entiende;
este enfoque es en contraste con otros
mtodos de ingeniera de software que
normalmente comienzan desarrollo con las
porciones ms entendidos primeros.
Tpicamente, el producto proto-
mecanografiada no se convierta en el
producto de software final sin extensa
retrabajo desarrollo o la refactorizacin.
En esta seccin se analiza estilos de creacin
de prototipos, Tar recibe, y tcnicas de
evaluacin en breve.

Estilo de prototipos: Esto se refiere a los

diversos enfoques para desarrollar
prototipos. prototipos pueden
desarrollarse como cdigo o productos de
papel de usar y tirar, como una evolucin
de un diseo traba- jando, o como una
especificacin ejecutable. Diferentes
procesos del ciclo de vida de prototipos
se utilizan normalmente para cada estilo.
El estilo CHO-sen se basa en el tipo de
resultados que necesita el proyecto, la
calidad de los resultados es necesario, y
la urgencia de los resultados.
Objetivo de prototipos: El objetivo de la
actividad proto- tipo es el producto
especfico que se est servido por el
esfuerzo de creacin de prototipos. Los
ejemplos de objetivos de creacin de
prototipos incluyen una especificacin de
requisitos, un elemento de diseo
arquitectnico o componente, un
algoritmo, o una interfaz de usuario
hombre-mquina.
Tcnicas de Evaluacin de prototipos:
Un proto- tipo puede ser usado o
evaluado en un n- mero de maneras por
el ingeniero de software u otros
9-16 Gua SWEBOK V3.0

un objetivo conjunto de requisitos (por ensayaron. Cada ment incre- de software se

ejemplo, un prototipo requisitos); el prueba con pruebas automatizados y
prototipo tambin puede servir como manuales; un incremento puede ser liberado
modelo para un futuro esfuerzo de con frecuencia, como cada dos semanas ms
desarrollo de software (por ejemplo, como o menos.
en una especificacin de interfaz de
usuario).

4.4. Los mtodos giles

[3 *, c3] [6 *, c7s3p7] [7 *, c6, App.
UN]

Los mtodos giles nacieron en la dcada de

1990 a partir de la necesidad de reducir la gran
sobrecarga aparente asocia- dos con el peso
pesado, los mtodos basados en planes utilizados
en los proyectos de desarrollo de software a gran
escala. Los mtodos giles son considerados
mtodos ligeros en cuanto a que se caracterizan
por ciclos cortos, iteraciones de desarrollo tiva,
equipos auto-organizados, los diseos ms
simples, la refactorizacin de cdigo, desarrollo
basado en pruebas, la participacin de cliente
frecuente, y un nfasis en la creacin de un
trabajo demostrable producto con cada ciclo de
desarrollo.
Muchos mtodos giles estn disponibles en la
lit- eratura; algunos de los enfoques ms
populares, que se discuten aqu en breve,
incluyen desarrollo rpido de aplicaciones
(RAD), eXtreme Pro- gramacin (XP), Scrum, y
el desarrollo de funciones-Driven (FDD).

RAD: mtodos rpidos de desarrollo de

software se utilizan principalmente en el
desarrollo de aplicaciones sistemas de
negocios-intensivo de datos. El mtodo
RAD est habilitado con fines especiales
herramientas de desarrollo Base de datos se
utilizan los ingenieros de software para
desarrollar rpidamente, probar e
implementar aplicaciones nuevas o
modificadas de negocio.
XP: Este mtodo utiliza historias o
escenarios para las necesidades, desarrolla
pruebas en primer lugar, tiene implicacin
directa con el cliente en el equipo (por lo
general la definicin de las pruebas de
aceptacin), utiliza la programacin en
parejas, y prev continua- refactorizacin
cdigo ous e integracin. Historias se
descomponen en tareas, priorizado,
estimacin aparearon, desarrollados, y se
 Modelos de Ingeniera de Software y Mtodos 9-
software.
MelEste enfoque gil gestin es ms 17
amigable que los otros proyectos. El scrum
master gestiona las actividades dentro del
proyecto de la subasta; cada incremento se
llama una carrera de velocidad y no dura
ms de 30 das. Se desarrolla una lista de
reserva de pedidos de productos de
artculos (PBI) a partir del cual se
identifican las tareas, definidas, prioridad,
y estima. Una versin traba- jando del
software ha sido probado y puesto en
libertad en cada incremento. Las reuniones
diarias de scrum asegurar el trabajo se
logr planificar.
FDD: Este es un enfoque basado en
modelos, corto, iterativo de desarrollo de
software tivo usando un proceso de cinco
fases: (1) el desarrollo de un modelo de
producto a alcance la amplitud del
dominio, (2) crear la lista de necesidades o
caractersticas, (3 ) construir el plan de
desarrollo de funciones, (4) el desarrollo
de diseos para funciones de iteracin
especfica, y
(5) de cdigo, prueba, y luego integrar las
funciones. FDD es similar a un enfoque
incremental de desarrollo de software;
Tambin es similar a XP, excepto que la
propiedad del cdigo es asignado a
individuos ms que el equipo. FDD hace
hincapi en un enfoque de arquitectura
global para el software, que promueve la
creacin de la funcin correctamente la
primera vez en lugar de enfatizar
refactorizacin continua.

Hay muchas ms variaciones de ods met

giles en la literatura y en la prctica. Tenga en
cuenta que siempre habr un lugar para los
pesos pesados, mtodos de ingeniera de
software basados en plan, as como los lugares
donde brillan los mtodos giles. Hay nuevos
mtodos derivados de combinaciones de los
mtodos giles y basadas en el plan donde los
practicantes estn definiendo nuevos mtodos
que equilibren las caractersticas necesarias en
ambos mtodos de peso pesado y ligero basado
principalmente en las necesidades de negocio
que prevalece zational nizaciones. Estas
necesidades de negocio, ya que por lo general
representado por algunos de los interesados en
el proyecto, deben y no conducir la eleccin en
el uso de mtodo de ingeniera de software una
sobre otra o en la construccin de un nuevo
mtodo de las mejores caractersticas de una
combinacin de mtodos de ingeniera de
9-18 Gua SWEBOK V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Mellor y Balcer 2002 [2

BoEHM y Turner 2003

Brookshear 2008
1999 [4 *]
2011 [3 *]
Budgen 2003

Pgina-Jones
SommervilLe

Ala 1990
[1 *]

[6 *]
[5 *]

[7 *]
*]
1. Modelado
C2S
1.1. Modelado
2, C2S2 c5s0
principios
c5s1
1.2. Propiedades , c4s1.1p7,
c5s2,
c5s2
y Expresin de c4s6p3,
c5s3
Modelos c5s0p3
1.3. Sintaxis, la
c2s2.2.2
semntica y la c5s0
P6
pragmtica
1.4. Condiciones c10s4p2,
previas, c4s4 c10s5
postConditions, e p2p4
2. invariantes
Tipos de Modelos
2.1. Modelado
c7s2.2 c8s1
de informacin
c7s2.1,
2.2. conductual
c7s2.3, c9s2 c5s4
Modelado
c7s2.4
c7s2.5,
2.3. Estructura
c7s3.1, c5s3 c4
Modelado
c7s3.2
3. Anlisis de
Modelos
3.1. Para c4s1.1p7,
pp8-11
completar el c4s6
anlisis
3.2. La c4s1.1p7,
pp8-11
consistencia para c4s6
analizar
3.3. El anlisis de
pp8-11
la correccin
c4s7.1,
3.4. trazabilidad
c4s7.2
3.5. Interaccin c29s1.1,
c10, c11 c5
Anlisis c29s5
 Modelos de Ingeniera de Software y Mtodos 9-
11

Mellor y Balcer 2002 [2

BoEHM y Turner 2003

Brookshear 2008
1999 [4 *]
2011 [3 *]
Budgen 2003

Pgina-Jones
SommervilLe

Ala 1990
[1 *]

[6 *]
[5 *]

[7 *]
*]
4. Mtodos de
ingeniera de
software c2s2.2,
4.1. Los c13, c15,
c7s1,
mtodos c16
c5s4.1
heursticos
4.2. Mtodos c18 c27 pp8-24
formales
4.3. prototipado
c12s2 c2s3.1 c7s3p5
mtodos
c6, app.
4.4. Los mtodos c3 c7s3p7
UN
giles
9-12 Gua SWEBOK V3.0

Referencias
[1 *] D. Budgen, Diseo de software, 2 ed., [5 *] JM Wing, Introduccin de un
Addison-Wesley, 2003. especificador de mtodos formales,
Computer, vol. 23, no. 9, 1990, pp. 8, 10-23.
[2 *] SJ Mellor y MJ Balcer, ejecutable UML:.
Una Fundacin para el Model-Driven [6 *] JG Brookshear, Ciencias de la
Architecture, 1st ed, Addison-Wesley, Computacin:. Una visin general, 10 ed,
2002. Addison-Wesley, 2008.

[3 *] I. Sommerville, Ingeniera de Software, 9 [7 *] B. Boehm y R. Turner, Equilibrio de la

ed., Addison-Wesley, 2011. agilidad y disciplina: una gua para los
perplejos, Addison-Wesley, 2003.
[4 *] M. Pgina-Jones, Fundamentos del Diseo
orientado a objetos en UML, 1st ed.,
Addison-Wesley, 1999.
 Modelos de Ingeniera de Software y Mtodos 9-
13

CAPTULO 10 CALIDAD

DEL SOFTWARE

SIGLAS calidad , donde elcliente es el rbitro final[3 *,

P8].
Capability Maturity Model Ms recientemente, la calidad del software se
CMMI
Integration define como la capacidad de producto de
cosq Costo de la Calidad del Software software para satisfacer necesidades expresadas
Commercial Off-The-Shelf o implcitas, en condiciones especiales
COTS requisitos [4] y como el grado en que un
Software
producto de software cumple creada; Sin
FMEA Modo de Fallos y Anlisis de
embargo, la calidad depende del grado en que
TLC Efectos
Anlisis del rbol de fallos esos requisitos cado blecimientos representan
PDCA Planificar-Hacer-Verificar-Actuar con exactitud las necesidades de los interesados,
PDSA Plan-Do-Study-Act deseos y expectativas[5]. Ambas definiciones
abrazan la premisa de conformidad con los
QFD Despliegue de la funcin de calidad
requisitos. Ni se refiere a tipos de los requisitos
SPI Mejora de Procesos de Software (por ejemplo, funcional, fiabilidad, rendimiento,
SQA Calidad de Software fiabilidad, o cualquier otra caracterstica).
SQC Control de Calidad de Software Significativamente, sin embargo, estas
definiciones hacen hincapi en que la calidad
SQM Gestin de la calidad del software
depende de los requisitos.
TQM Total Quality Management Estas definiciones se ilustran tambin otra
V&V Verificacin y validacin razn de la prevalencia de la calidad del software
largo de esta gua: una ambigedad frecuente de
la calidad del software frente a los requisitos de
INTRODUCCIN calidad de software ( los -ilities es una
abreviatura comn). los requisitos de calidad de
Cul es la calidad del software, y por qu es tan software son en realidad los atributos de (o
impor- tante que se incluye en muchas reas de limitaciones) sobre los requisitos funcionales (lo
conocimiento (KAS) de la gua SWEBOK? que hace el sistema). Requisitos de software
Una de las razones es que la calidad del tambin pueden especificar el uso de recursos,
software trmino est sobrecargado. La calidad un protocolo de comunicacin, o muchas otras
del software puede referirse: a deseable caractersticas. Esta KA intenta claridad
caractersticas capaces de productos de software, mediante el uso de la calidad del software en el
en la medida en que un determinado posi- sentido ms amplio de las definiciones anteriores
producto de software sess esas caractersticas, y y mediante el uso de los requisitos de calidad de
para procesos, herramientas y tcnicas utilizadas software como con- straints sobre los requisitos
para lograr esas caractersticas. Con los aos, los funcionales. La calidad del software se logra
autores y organizaciones han definido el trmino mediante la conformidad con todos los
calidad diferente. Para Phil Crosby, que era la requisitos, independientemente de lo que es
conformidad con los requisitos [1]. Watts caracterstico manera especificada o cmo se
Humphrey refiere a l como lograr excelentes agrupan o se nombra requisitos.
niveles deaptitud para el uso[2]. Entre tanto, La calidad del software tambin se considera
IBM acu la frase impulsada por el mercado en muchos de los SWEBOK KAs porque es un
eter param bsica de un esfuerzo de ingeniera
de software. Para todos los productos neered el equilibrio de las limitaciones de costo y
nieros, el objetivo principal es ofrecer un valor cronograma de desarrollo; esto a veces se
mximo de las partes interesadas, mientras que caracteriza como aptitud para

10-1
10-2 Gua SWEBOK V3.0

Figura 10.1. Desglose de los temas de la calidad del software KA

utilizar.valor de los grupos de inters se ingenieros de software que requieren

expresa en los requisitos. Para productos de
software, los interesados podran valorar el
precio (lo que pagan por el producto), tiempo de
espera (la rapidez con que reciben el producto),
y la calidad del software.
Esta KA aborda las definiciones y proporciona
una visin general de las prcticas, herramientas
y tcnicas para la definicin de la calidad del
software y para valorar el estado de la calidad
del software durante el desarrollo,
mantenimiento y despliegue. Las referencias
citadas proporcionan detalles adicionales.

DISTRIBUCIN DE TEMAS PARA LA

CALIDAD DEL SOFTWARE

El desglose de los temas para la Calidad del

Software
KA se presenta en la figura 10.1.

1. Fundamentos de la calidad del software

Llegar a un acuerdo sobre lo que constituye la

calidad de todos los grupos de inters y la
comunicacin clara de ese acuerdo a los
 Calidad de Software 10-
los muchos aspectos de la calidad se definen 3
formalmente
y discutido.
Un ingeniero de software debe entender los
conceptos cali- dad, las caractersticas, valores
y su aplicacin al software bajo desarrollo o
mantenimiento. El concepto importante es que
los requisitos de software definen los atributos
de calidad requeridos del software. Requisitos
de software influyen en los mtodos de
medicin y los criterios de acep- tacin para
evaluar el grado en que el software y la
documentacin relacionada a alcanzar los
niveles de calidad deseados.

1.1. Software de Ingeniera de la Cultura y tica

[3 *, c1s4] [6 *,
c2s3.5]

Software Se espera que los ingenieros

compartir un compromiso para la calidad del
software como parte de su cultura. Una cultura
de ingeniera de software saludable incluye
muchas caractersticas, incluyendo el
entendimiento de que los equilibrios entre
costes, plazos y calidad son un principio bsico
de la ingeniera de cualquier pro- ducto. Una
tica fuerte de ingeniera de software asume
10-4 Gua SWEBOK V3.0

que los ingenieros informan con precisin la software producto al cliente. costos ure Fail
informacin, con- diciones, y los resultados externos incluyen actividades para responder a
relacionados con la calidad. problemas de software descubiertas despus de
La tica tambin juegan un papel importante la entrega al cliente. Los ingenieros de software
en la calidad del software, la cultura, y las deben ser capaces de utilizar mtodos cosq para
actitudes de los ingenieros de software. El IEEE determinar los niveles de calidad del software y
Computer Society y la ACM han desarrollado un tambin deben ser capaces de presentar
cdigo de tica y la prctica pro- fesional (ver alternativas de calidad y sus costos para que las
Cdigos de tica y Conducta Profesional de la compensaciones entre costo, horario, y la
Ingeniera de Software KA Prctica entrega de valor para los accionistas
Profesional). Puede ser hecho.

1.2. Valor y los costos de 1.3. Modelos y caractersticas de calidad

Calidad [7 *, c17, [3 *, c24s1] [7 *, c2s4] [8 *,
c22] c17]

Definir y luego la consecucin de la calidad del de software, pruebas de nivel de sistema, pruebas
software no es simple. Las caractersticas de de aceptacin); los costos de evaluacin se
calidad pueden o pueden no ser necesarios, o se extenderan a los proveedores de software
les puede pedir a un mayor o menor grado, y las subcontratados. Los costos de fallos internos son
compensaciones se pueden hacer entre ellos. los que se incurre para fijar defectos encontrados
Para ayudar a determinar el nivel de calidad del durante las actividades de evaluacin y descubri
software, es decir, el logro de valor para los antes de la entrega de la
accionistas, esta seccin presenta coste de la
calidad del software (cosq): un conjunto de
medidas derivadas de la evaluacin econmica
de los procesos de desarrollo y mantenimiento
de software de calidad. Las mediciones cosq son
ejemplos de mediciones de proceso que pueden
utilizarse para inferir carac- tersticas de un
producto.
La premisa subyacente a la cosq es que el
nivel de calidad en un producto de software se
puede deducir de los costes de las actividades
relacionadas con la oferta- ing con las
consecuencias de la mala calidad. La mala
calidad significa que el producto de software no
totalmente satisfacer necesidades expresadas o
implcitas o Hay cuatro categoras de calidad
coste de estable- ci requisitos.: prevencin,
evaluacin, fallo interno y externo fracaso.
Prevencin costos incluyen las inversiones en
los esfuerzos de mejora de procesos de software,
infra- estructura de calidad, herramientas de
calidad, formacin, auditoras y revisiones Ment
manage-. Estos costos son por lo general no es
especfico de un proyecto; que abarcan la
organizacin. surgen los costos de evaluacin de
las actividades del proyecto que encuentran
defectos. Estas actividades de evaluacin se
pueden clasificar en los costos de los exmenes
(diseo, pares) y los costos de las pruebas
(pruebas software de la unidad, de integracin
 Calidad de Software 10-
Terminologa para caractersticas de calidad de 5
software difiere de una taxonoma (o modelo
de la calidad del software) a otro, cada modelo
tal vez tener un nmero diferente de niveles
jerrquicos y un nmero total diferente de
caractersticas. Varios autores han producido
modelos de caractersticas de calidad de
software o atributos que pueden ser tiles para
la discusin, la planificacin, y la calificacin
de la calidad de los productos de software. ISO
/ IEC 25010: 2011 [4] define la calidad del
producto y la calidad en uso como dos modelos
de calidad relacionados. Apndice B de la Gua
de SWE- BOK proporciona una lista de las
normas aplicables para cada KA. Normas de
este KA cubren diversas formas de caracterizar
la calidad del software.

1.3.1. Calidad de Procesos de Software

gestin de la calidad del software y la calidad

de los procesos niera de software niera tienen
una influencia directa en la calidad del
producto de software.
Modelos y criterios que evalan los lazos
capabili- de organizaciones de software son
principalmente pro- yecto organizacin y
consideraciones de gestin y, como tales, estn
cubiertos en el Proceso de Gestin de
Ingeniera de Software e Ingeniera de
Software de Kas.
No es posible distinguir por completo la
calidad del proceso de la calidad del producto
debido a los resultados del proceso incluyen
productos. La determinacin de si un proceso
tiene la capacidad de productos Duce
consistentemente pro de la calidad deseada no
es simple.
El proceso de ingeniera de software,
discutido en el proceso de ingeniera de
software KA, las influencias de las
caractersticas de calidad de software pro-
ductos, que a su vez afectan a la calidad
percibida por los interesados.
10-6 Gua SWEBOK V3.0

1.3.2. Calidad del producto de software fallos / defecto, la eliminacin, y pre- vencin, y
(3) el proceso de mejora de la calidad.
El ingeniero de software, en primer lugar, debe La teora y los conceptos detrs de la mejora de
determinar el verdadero propsito del software. la calidad, tales como la construccin de la
En este sentido, requisitos de los interesados son calidad a travs de la deteccin temprana y la
de suma importancia, y que incluyen los prevencin de defectos, la mejora continua de las
requisitos de calidad, adems de los requisitos partes interesadas, y enfoque son pertinentes para
fun- cionales. Por lo tanto, los ingenieros de la ingeniera de software. Estos conceptos se
software tienen la responsabilidad de obtener los basan en el trabajo de los expertos
requisitos de calidad que pueden no ser explcita
al principio y al Deben conocerse su
importancia, as como el nivel de difi- cultad en
el logro de ellos. Todos los procesos de
desarrollo de software (por ejemplo, la
obtencin de requisitos, diseo, construccin,
construccin, control, mejora de la calidad)
estn diseados con estos requisitos de calidad
en la mente y puede llevar a los costes de
desarrollo adicionales si los atributos tales como
la seguridad, la seguridad y la fiabilidad son
importantes. Los costos de desa- rrollo
adicionales ayudan a asegurar que la calidad
obtenida puede canjearse por los beneficios
anticipados.
El trmino producto de trabajo significa
cualquier artefacto que es el resultado de un
proceso utilizado para crear el producto de
software final. Ejemplos de un UCT trabajo
PRODUCIRSE incluyen una especificacin de
sistema / subsistema, una especificacin de
requisitos de software para un componente de
software de un sistema, una descripcin de
diseo de software, cdigo fuente, prueba de
software documen- tacin, o informes. Aunque
se describen algunos tratamientos de calidad en
trminos de rendimiento del software y el
sistema final, buenas prcticas de ingeniera
requiere que se evalen productos de trabajo
intermedios correspondientes a la calidad
durante todo el proceso de ingeniera de
software.

1.4. Mejora de la Calidad de Software

[3 *, c1s4] [9 *, c24] [10 *,
c11s2.4]

La calidad de los productos de software se puede

mejorar a travs de procesos preventivas o un
proceso iterativo tiva de la mejora continua, que
requiere control de la gestin, coordinacin, y la
retroalimentacin de muchos procesos
concurrentes: (1) los procesos del ciclo de vida
del software, (2) el proceso de deteccin de
en la calidad que han declarado que la calidad para desarrollar software crticoCalidad de Software 10-
seguridad-.
7
de un producto est directamente relacionada software indirecta se incluye en entornos de
con la calidad del proceso utilizado para ingeniera de software y entornos de prueba de
crearlo. Enfoques como el ciclo de mejora de software.
Deming de Ley del Plan-Do-Fecha entrada
(PDCA), entrega evolutivo, kaizen, y el
despliegue de la funcin de calidad (QFD)
ofrecen tcnicas para especificar los objetivos
de calidad y determinar si se cumplen. El ideal
del Instituto de Ingeniera de Software es otro
mtodo [7 *]. gestin de cali- dad ahora es
reconocido por la Gua SWE- BOK como una
disciplina importante.
patrocinio de gestin de procesos y
productos apoya las evaluaciones y las
conclusiones resultantes. A continuacin, un
programa de mejora se desarrolla la
identificacin de acciones detalladas y
proyectos de mejora que deben abordarse en un
plazo de tiempo posible. apoyo a la gestin
implica que cada proyecto mejora tiene
suficientes recursos para lograr el objetivo
definido para ello. patrocinio de gestin se
solicita con frecuencia mediante la
implementacin de actividades de
comunicacin proactivas.

1.5. software de Seguridad

[9 *,
c11s3]

sistemas de seguridad crticos son aquellos en

los que un fallo de sis- tema podra daar la
vida humana, los dems seres vivos, las
estructuras fsicas, o el medio ambiente. El
software en estos sistemas es crtico para la
seguridad. Hay un nmero creciente de
aplicaciones de software crtico en un nmero
creciente de industrias. Ejemplos de sistemas
con software crtico seguridad- incluyen
sistemas de transporte masivo, plantas de
fabricacin de productos qumicos, y
dispositivos mdicos. El fracaso de software en
estos sistemas podra tener efectos
catastrficos. Existen normas indus- tria, como
DO-178C [11], y emerg- procesos ing,
herramientas y tcnicas para el Desa- software
safetycritical ing. La intencin de estas normas,
instrumentos y tcnicas es reducir el riesgo de
defectos de inyeccin en el software y por lo
tanto mejorar la fiabilidad del software.
software crtico puede ser categorizado como
directo o indirecto. Directa es que el software
embed- ded en un sistema crtico para la
seguridad, como por ejemplo el ordenador de
control de vuelo de una aeronave. Indirecta
incluye aplicaciones de software utilizadas
10-8 Gua SWEBOK V3.0

Tres tcnicas complementarias para reduccin utilizados. dades SQA activi- definir y evaluar la
ing el riesgo de fallo son la evitacin, deteccin adecuacin de los procesos de software para
y eliminacin, y la limitacin del dao. Estos proporcionar evidencia que establezca la
software tcnicas impacto requisitos funcionales, confianza de que los procesos de software son
requisitos de rendimiento del software y los consignados para piado y producir productos de
procesos de desarrollo. El aumento de los software de calidad traje- poder para los fines
niveles de riesgo implican el aumento de los previstos [5]. actividades SQC examinan
niveles de calidad del software assur- tcnicas artefactos especficos del proyecto (docu- mentos
ANCE y control tales como las inspecciones. y ejecutables) para determinar si
Los niveles ms altos de riesgo pueden requerir
una revisin ms detallada de los requisitos, el
diseo y el cdigo o el uso de tcnicas analticas
ms formales. Otra tcnica para la gestin de
riesgos y control- software Ling es la
construccin de casos de aseguramiento. Un
caso de aseguramiento es un artefacto razonada,
auditable creado para apoyar la afirmacin de
que su demanda o demandas son satisfechas.
Contiene las siguientes acciones y sus
relaciones: una o ms afirmaciones sobre
propiedades; argumentos que enlazan
lgicamente parte, las pruebas y las posibles
hiptesis a las reclamaciones; y un conjunto de
pruebas y los supuestos que apoyan estos
argumentos [12].

2. Procesos de software de gestin de calidad

gestin de la calidad del software es el conjunto

de todos los procesos que garanticen que los
productos de software, servicios y la
implementacin de procesos de ciclo de vida
cumplen los objetivos de calidad de software de
organizacin y lograr la satisfaccin de las
partes interesadas [13, 14]. SQM define los
procesos, los dueos del proceso, los requisitos
para los procesos, mediciones de los procesos y
sus salidas y retroalimentacin Nels Chan
durante todo el ciclo de vida del software.
SQM comprende cuatro subcategoras:
software de planificacin de la calidad,
aseguramiento de la calidad del software (SQA),
control de la calidad del software (SQC), y la
mejora de procesos de software (SPI). la
planificacin de la calidad del software incluye
la determinacin de cules estndares de calidad
se van a utilizar, la definicin de objetivos de
calidad especficos, y estimar el esfuerzo y el
calendario de actividades de calidad de software.
En algunos casos, la planificacin de la calidad
del software tambin incluye la definicin de los
procesos de calidad de software para ser
 la funcin SQA con respecto Calidad de Software La
al proyecto. 10-
cumplir con las normas establecidas para el 9
proyecto (incluyendo los requisitos, funcin SQA tambin puede ser
limitaciones, diseos, contratos y planes). SQC organizativamente independiente de la proyec-
evala inter- medio productos, as como los ect; es decir, libre de tcnica, de gestin y
productos finales.
La cuarta categora SQM se trata de la
mejora tiene varios nombres en el software
indus- tria, incluyendo SPI, la mejora de la
calidad del software y el software de acciones
correctivas y preventivas. Las actividades en
esta categora buscan mejorar la eficacia del
proceso, la eficiencia, y otras carac- tersticas
con el objetivo ltimo de mejorar la calidad del
software. Aunque SPI podra incluirse en
cualquiera de las tres primeras categoras, un
nmero creciente de organizaciones de
organizar SPI en una cate- gora separada que
puede extenderse a travs de muchos proyectos
(ver el Proceso de Ingeniera de Software KA).
los procesos de calidad de software consisten
en tareas y tcnicas para indicar cmo se estn
implementando planes de software (por
ejemplo, gestin de software, desarrollo,
gestin de la calidad, o los planes de gestin de
configuracin) y qu tan bien los productos
intermedios y finales estn cumpliendo con sus
requisitos especificados. Los resultados de
estas tareas se montan en los informes de
gestin antes de que se tomen medidas
correctivas. La gestin de un proceso de SQM
tiene la tarea de garantizar que los resultados
de estos informes son exactos.
La gestin del riesgo tambin puede jugar un
papel importante en la entrega de software de
calidad. La incorporacin de anlisis de riesgos
y la gestin gas nicas disciplinados en los
procesos del ciclo de vida del software puede
ayudar a mejorar la calidad del producto (vase
la Ingeniera de Software de Gestin de KA
para mate- rial relacionado en la gestin de
riesgos).

2.1. Calidad de Software

[7 *, C4-C6, c11, c12, c26-
27]

Para sofocar un malentendido generalizado,

chorro suave de garanta de calidad cermica
no est probando. aseguramiento de la calidad
del software (SQA) es un conjunto de
actividades que definen y evaluar la
adecuacin de los procesos de software para
proporcionar evidencia que establece con-
fianza que los procesos de software son
apropiados y producen productos de software
de calidad adecuada para sus fines previstos.
Un atributo clave de SQA es la objetividad de
10-10 Gua SWEBOK V3.0

las presiones financieras del proyecto [5]. SQA

tiene dos aspectos: de garanta de producto y de El propsito de V & V es ayudar a la
garanta de proceso, que se explican en la calidad de construccin organizacin desa-
seccin 2.3. rrollo en el sistema durante el ciclo de vida.
El plan de la calidad del software (en algunos procesos de V & V proporcionan una
sectores de la industria que se denomina el plan evaluacin objetiva de los productos y
de software de aseguramiento de la calidad) procesos en todo el
define las actividades y tareas empleadas para
garantizar que el software desarrollado para un
producto especfico satisface mentos del
proyecto establecidos requisitos y necesidades
de los usuarios dentro de los costos del proyecto
y las restricciones del cronograma y es
proporcional a los riesgos del proyecto. El
PACS asegura primero que los objetivos de
calidad estn claramente definidos y entendidos.
actividades y tareas de calidad del plan SQA
se especifican con sus costos, necesidades de
recursos, objetivos y calendario en relacin con
los objetivos relacionados con la ingeniera de
software Ment manage-, desarrollo de software,
software y planes de man- tenance. El plan SQA
debe ser consistentes con el plan de gestin de
configuracin de software (ver el software de
configuracin Manage- ment KA). El plan SQA
identifica documentos, normas, prcticas y
convenciones que rigen el proyecto y cmo estos
artculos son revisados y monitoreados para
asegurar la adecuacin y cumplimiento. El plan
SQA tambin medidas; tcnicas estadsticas; los
procedimientos para la presentacin de informes
de problemas y acciones correctivas; recursos
tales como herramientas, tcnicas y
metodologas; la seguridad de los medios
fsicos; formacin; y SQA informes y docu-
mentacin. Por otra parte, el plan de SQA se
ocupa de las actividades de aseguramiento de la
calidad del software de cualquier otro tipo de
actividad se describe en los planes a dicho
software como la adquisicin de software de
proveedores para el proyecto, el software off-
the-shelf comercial (COTS) de instalacin, y
servicio despus de la entrega de El software.
Tambin puede contener la aceptacin crite- ria,
as como la presentacin de informes y la
gestin de activi- lazos que son crticos para la
calidad del software.

2.2. Verificacin validacin

[9 *, c2s2.3, c8, c15s1.1,
c21s3.3]

Como se indica en [15],

 garanta de producto y auditoras Calidad de Software
de 10-
ciclo vital. Esta evaluacin demuestra si 11
los requisitos son correctos, com- pleta, aseguramiento de proceso son normalmente
precisa, coherente y comprobable. Los llevadas a cabo por la garanta de la calidad del
procesos de V & V determinar si los software (SQA) personal independiente del
productos de desarrollo de una actividad desarrollo
dada se ajustan a los requisitos de que la
actividad y si el producto cumple sus
necesidades de uso y de usuarios
previstos.

La verificacin es un intento de asegurar que

el producto se ha construido correctamente, en
el sentido de que los productos de salida de una
actividad cumplen con las especificacio- nes
que se les imponen en las actividades
anteriores. La validacin es un intento de
asegurar que el producto adecuado est
construido, es decir, el producto cumple con su
finalidad especfica. Tanto el proceso de
verificacin y validacin del proceso
comienzan temprano en la fase de desarrollo o
mantenimiento. Proporcionan un examen de las
caractersticas clave del producto en relacin
tanto con predecesora inmediata del producto y
las especificaciones que deben cumplirse.
El propsito de la planificacin de V & V es
asegurar que cada recurso, el papel y la
responsabilidad est claramente asignadas. Los
documentos del plan de V & V resultantes
describen los diversos recursos y sus funciones
y actividades, as como las tcnicas y
herramientas que se utilizarn. La comprensin
de los diferentes efectos de cada actividad V y
V ayuda en la planificacin cuidadosa de las
tcnicas y los recursos necesarios para el
cumplimiento de sus fines. El plan tambin se
ocupa de la ment manage-, la comunicacin,
las polticas y procedimientos de las
actividades de V & V y su interaccin, as
como los requisitos de informacin y
documentacin defecto.

2.3. Revisiones y auditoras

[9 *, c24s3] [16
*]

Los comentarios y los procesos de auditora se

definen ampliamente como la electricidad
esttica sentido de que no hay programas o
modelos de software son artefactos de
ingeniera de software ejecutados examen, con
respecto a las normas que han sido establecidas
por la organizacin o pro- yecto para esos
artefactos. Los diferentes tipos de revisiones y
auditoras se distinguen por su finalidad, nive-
les de la Independencia, herramientas y
tcnicas, roles, y por el tema de la actividad. la
10-12 Gua SWEBOK V3.0

equipos. revisiones por la direccin estn a incluir informes de auditora, informes, V & V
cargo de la gestin de la organizacin o informes y planes de muchos tipos, incluyendo la
proyecto. El personal de inge- niera lleva a cabo gestin de riesgos, gestin de proyectos, gestin
revisiones tcnicas. de configuracin de software, la seguridad de
software, y Assessment riesgo, entre otros
revisiones por la direccin evalan proyecto progresar. (Consulte el software de gestin de
real Inge- niera y el software de configu- racin de
resultados con respecto a los planes. Gestin KAs para el material relacionado).
Revisiones tcnicas (incluidas las
inspecciones, paso a paso, y la
comprobacin de escritorio) examinar
productos de trabajo de ingeniera.
auditoras de aseguramiento de proceso.
actividades de aseguramiento proceso SQA
asegurarse de que los procesos utilizados
para desarrollar, instalar, operar y mantener
el software se ajustan a los contratos,
cumplir con las leyes, normas y
regulaciones impuestas y son adecuados,
eficientes y eficaces para el fin previsto [5].
auditoras de garanta de producto.
actividades de garanta de producto SQA se
aseguran para proporcionar evidencia de
que los productos de software y la
documentacin relacionada se identifican en
y cumplir con los contratos; y asegurar que
se identifican y tratan [5] mances
nonconfor-.

2.3.1. Los comentarios de gestin

Como se indica en [16 *],

El propsito de una revisin por la

direccin es monitorear el progreso,
determinar el estado de los planes y
programas, y evaluar la eficacia de los
procesos de gestin, herramientas y
tcnicas. revisiones por la direccin
comprense resultados efectivos contra
los planes para determinar el estado de los
proyectos o esfuerzos de manteni- miento.
Los principales parmetros de revisin-
hombre agement son los costos del
proyecto, el calendario, el alcance y la
calidad. revisiones por la direccin
evalan las decisiones sobre las acciones
correctivas, cambios en la asignacin de
los recursos, o cambios en el alcance del
proyecto.

Las entradas a exmenes de gestin pueden

 2.3.2. Tcnico Comentarios adhesin a la codificacin Calidad
de lasdenormas,
Software 10-
la
13
estructura y
Como se indica en [16 *],

El propsito de una revisin tcnica es

evaluar un producto de software por un
equipo de personal cualificado para
determinar su idoneidad para el uso
previsto e identificar las discrepancias
de las especificaciones y normas.
Proporciona administracin evidencia
para confirmar el estado tcnico del
proyecto.

Aunque cualquier producto de trabajo puede

ser revisada, revisiones tcnicas se realizan en
los principales productos de trabajo de
ingeniera de software de los requisitos de
software y diseo de software.
Propsito, funciones, actividades, y lo ms
importante es el nivel de formalidad distinguen
diferentes tipos de exmenes tcnicos. Las
inspecciones son los ms formales, Tutoriales
menos, y las revisiones de pares o controles
documentales son los menos formal.
Ejemplos de roles especficos incluyen un
tomador de decisiones (es decir, el plomo de
software), un lder de opinin, una grabadora, y
damas (miembros del personal tcnico que
examinan los productos de trabajo). Las
revisiones tambin se distinguen por si las
reuniones (cara a cara o electrnico) estn
incluidos en el proceso. En algunos mtodos de
revisin de damas solitario exami- productos
de trabajo ine y enviar sus resultados a un
coordinador. En otros mtodos de damas
trabajan cooperativamente en las reuniones.
Una revisin tcnica puede requerir que las
aportaciones obligatorias estar en su lugar a fin
de proceder:

Declaracin de objetivos
producto de software especfico
plan especfico de gestin de proyectos
lista de temas relacionados con este
producto
procedimiento de revisin tcnica.

El equipo sigue el procedi- opinin pro-

documentado. La revisin tcnica se completa
una vez que todas las actividades enumeradas
en el examen se han completado.
Revisiones tcnicas de cdigo fuente pueden
incluir una amplia variedad de problemas tales
como el anlisis de algoritmos de, la utilizacin
de los recursos crticos de ordenador, la
10-14 Gua SWEBOK V3.0

organizacin de cdigo para la capacidad de grabadora, un lector, y algunos (de dos a cinco)
prueba, y Seguridad- Damas (inspectores). Los miembros de un equipo
consideraciones crticas. de inspec- cin pueden poseer diferentes
Tenga en cuenta que las revisiones tcnicas de conocimientos, tales como experiencia en el
los modelos de cdigo fuente o el diseo tales campo, experiencia en mtodos de diseo de
como UML tambin se denominan anlisis software, o la experiencia lenguaje de
esttico (vase el tema 3, Consideraciones programacin. las inspecciones se realizan
prcticas). normalmente en un relativamente

2.3.3. inspecciones

El propsito de la inspeccin es detectar e

identificar anomalas de productos de software
[16 *]. Algunos diferenciadores importantes de
las inspecciones en comparacin con otros tipos
de revisiones tcnicas son las siguientes:

1. Reglas. Las inspecciones se basan en el

examen de un producto de trabajo con
respecto a un conjunto definido de criterios
especificados por la organizacin.
Conjuntos de reglas pueden ser definidos
para diferentes tipos de workproducts (por
ejemplo, reglas para los requerimientos, las
descripciones de la arquitectura, el cdigo
fuente).
2. Muestreo. Ms bien que intento de
examinar cada palabra y figura en un
documento, el proceso de inspeccin
permite las fichas para eva- subconjuntos
comi definidos (muestras) de los docu-
mentos que se examina.
3. Mirar. Las personas que llevan a cabo las
posiciones de gestin sobre los miembros
del grupo de inspeccin no participan en la
inspeccin. Esta es una distincin clave
entre revisin y revisin por la direccin.
4. LED. Un mediador imparcial que est
entrenado en tcnicas de inspeccin
conduce reuniones de inspeccin.
5. Reunin. El proceso de inspeccin incluye
reuniones (cara a cara o electrnico) con-
canalizado por un moderador de acuerdo
con un procedimiento formal en el que los
equipos de inspeccin miem- bros informan
las anomalas que han encontrado y otras
cuestiones.

Las inspecciones de software siempre

implican el autor de un producto intermedio o
final; otras opiniones no. Las inspecciones
tambin incluyen un lder de inspeccin, una
 Calidad de Software 10-
pequea seccin del producto a la vez 15
(muestras). Cada miembro del equipo examina
el producto de software y otros insumos de
revisin antes de la reunin de revisin, tal vez
mediante la aplicacin de una tc- nica
analtica (ver seccin 3.3.3) a una pequea
seccin del producto o de la totalidad del
producto con un enfoque en slo un aspecto-
por ejemplo, interfaces. Durante la inspeccin,
el moderador lleva a cabo la sesin y verifica
que todo el mundo ha preparado para la
inspeccin y lleva a cabo la sesin. Las
inspecciones grabadora cin documentos
anomalas encontradas. Un conjunto de reglas,
con criterios y preguntas pertinentes a los
temas de inters, es una herramienta comn
utilizada en las inspecciones. La lista resultante
a menudo clasifica las anomalas (ver seccin
3.2, defecto caracterizacin cin) y es revisada
para su integridad y picante Accu por el
equipo. La decisin de salida de inspeccin
corresponde a una de las siguientes opciones:

1. Encaja con ninguna o, a lo sumo,

reelaboracin de menor importancia
2. Aceptar con la verificacin de retrabajo
3. Volver a inspeccionar.

2.3.4. Tutoriales

Como se indica en [16 *],

El propsito de un recorrido sistemtica

es evaluar un producto de software. A
travs de pie- puede llevarse a cabo con
el propsito de educar a una audiencia
con respecto a un producto soft- ware.

Tutoriales se distinguen de las inspecciones.

La diferencia principal es que los Ents autor
Las presiones para el trabajo de productos a los
dems participantes en una reunin (cara a cara
o electrnico). A diferencia de una inspeccin,
los participantes de la reunin pueden no haber
visto necesariamente el material antes de la
reunin. Las reuniones pueden llevarse a cabo
Mally menos de lucro. El autor toma el papel
de explicar y que muestra el material a los
participantes y solicita retroalimentacin. Al
igual que las inspecciones, tutoriales puede
llevarse a cabo en cualquier tipo de trabajo-
producto, incluyendo plan de proyecto,
requisitos, diseo, cdigo fuente, y los
informes de las pruebas.
10-16 Gua SWEBOK V3.0

2.3.5. Proceso de aseguramiento y funcional (lo que hace el sistema) y calidad

Aseguramiento de auditoras los componentes comerciales (externos) o
estndar (inter- nal) para ser utilizados en el
Como se indica en [16 *], sistema de

El propsito de una auditora de software

consiste en pro- porcionar una evaluacin
independiente de la con- Formance de
productos de software y pro cesos a los
reglamentos aplicables, normas,
directrices, planes y procedimientos.

Proceso auditoras de aseguramiento de

determinar la idoneidad de los planes, los
programas y los requisitos para lograr los
objetivos del proyecto [5]. La auditora es una
actividad organizada formalmente con los
participantes que tienen roles tales espec- espe-
como auditor principal, otro auditor, una
grabadora, o un iniciador y que incluye un
representativo de la organizacin auditada.
Auditoras identifican los casos de no
conformidad y producir un informe que requiere
el equipo para tomar medidas correctivas.
Si bien puede haber muchos nombres formales
para revisiones y auditoras, tales como los
identificados en el estndar [16 *], el punto
importante es que pueden ocurrir en casi
cualquier producto en cualquier etapa del
proceso de desarrollo o mantenimiento.

3. Consideraciones prcticas

3.1. Requisitos de calidad de software

[9 *, c11s1] [18 *,
c12] [17 *, c15s3.2.2, c15s3.3.1,
c16s9.10]

3.1.1. Los factores de influencia

Hay varios factores que influyen en la

planificacin, gestin y seleccin de actividades
SQM y tcnicas, incluyendo

el dominio del sistema en el que reside el

soft- ware; las funciones del sistema podra
ser crtico para la seguridad, de misin
crtica, negocio-crtica, la seguridad crticos
el entorno fsico en el que reside el sistema
de soft- ware
(qu tan bien el sistema realiza sus
funciones) requisitos del sistema y software
 Calidad
un rango de valores que de Software
representan la10-
las normas especficas de ingeniera de 17
software complejidad del software, la criticidad,
aplicable riesgo, nivel de seguridad, nivel de
los mtodos y herramientas de software seguridad,
para ser utilizados para el desarrollo y
mantenimiento y para la evaluacin y
mejora de cali- dad
el presupuesto, el personal, la organizacin
del proyecto, planes, y la programacin de
todos los procesos
los usuarios previstos y el uso del sistema
el nivel de integridad del sistema.

La informacin sobre estos factores influye

en cmo se organizan y documentada, la forma
especfica se seleccionan las actividades de
SQM, qu recursos son necesarios, y cules de
esos recursos imponen lmites a los esfuerzos
de los procesos SQM.

3.1.2. Confianza

En los casos en que un fallo del sistema puede

tener consecuencias muy graves, la fiabilidad
global (Ware hardware, software y humana u
operativo) es el principal requisito de calidad
ms all de la funcionalidad bsica. Este es el
caso por las siguientes razones: las fallas del
sistema afectan a un gran nmero de personas;
los usuarios a menudo rechazan los sistemas
que son poco fiables, complica o inseguros; los
costes de fallos del sistema pueden ser
enormes; y sistemas poco confiables pueden
causar prdida de informacin. Sistema y
fiabilidad soft- ware incluyen caractersticas
tales como la disponibilidad, fiabilidad,
seguridad, y la seguridad. Cuando en desarrollo
de software fiable, herramientas y tcnicas se
pueden aplicar para reducir el riesgo de
inyeccin de fallos en los entregables
intermedios o el producto de software final.
Verificacin, validacin cin, y pruebas de
procesos, tcnicas, mtodos y herramientas de
identificar las fallas que la fiabilidad impacto
tan pronto como sea posible en el ciclo de vida.
Addition- aliado, mecanismos puede necesitar
estar en el lugar en el software para protegerse
contra los ataques externos y de tolerar fallos.

3.1.3. Los niveles de integridad de software

Definicin de los niveles de integridad es un

mtodo de riesgo
administracin.

los niveles de integridad de software son

10-18 Gua SWEBOK V3.0

rendimiento deseado, fiabilidad, u otras lenguas evolucionan, junto con los avances en el
caractersticas nicas en proyectos que software en general tecnolo- gas, aparecen
definen la importancia del software para nuevas clases de defectos, y se requiere una gran
el usuario y adquirente. Las cantidad de esfuerzo para interpretar clases
caractersticas utilizadas para determinar definidas anteriormente. Cuando el seguimiento
el nivel de integridad puede variar de defectos, el ingeniero de soft- ware est
dependiendo de la aplicacin prevista y el interesado no slo en el nmero de defectos, sino
uso del sistema. El software es una parte tambin los tipos. Informacin por s sola, sin un
del sistema, y su nivel de integridad se ha poco de clasificacin, puede no ser suficiente para
de determinar como una parte de ese identificar las causas subyacentes de los defectos.
sistema.

Los niveles de integridad de software

asignadas pueden cambiar a medida que
evoluciona el software. Diseo, codificacin
procesal, y la tecnologa de caractersticas
implementadas en el sistema o software puede
subir o bajar los niveles de integridad de
software asignadas. Los niveles de integridad de
software establecidos para un proyecto son el
resultado de acuerdos entre el adquiriente,
proveedor, desarrollador, y las autoridades de
aseguramiento independientes. Un esquema de
nivel de integridad de software es una
herramienta utilizada en la determinacin de
niveles de integridad de software. [5]
Como se ha indicado en [17 *] los niveles de
integridad se pueden aplicar durante el
desarrollo para asignar los esfuerzos de
verificacin y validacin adicionales a los
componentes de alta integridad.

3.2. Caracterizacin de defectos

[3 *, c3s3, c8s8,
c10s2]

Software de evaluacin de la calidad (es decir, el

control de calidad de software) Tcnicas de
encontrar defectos, fallas y fracasos. La
caracterizacin de estas tcnicas conduce a una
comprensin del producto, facilita las
correcciones en el proceso o el producto, e
informa a la gestin y otras partes interesadas de
la tus esta- del proceso o producto. Existen
muchas taxonomas y, si bien se han hecho
intentos de obtener el consenso, la literatura
indica que hay un buen nmero en uso.
Caracterizacin defecto tambin se utiliza en
auditoras y revisiones, con el lder de opinin a
menudo se presenta una lista de problemas
proporcionados por los miembros del equipo
para su examen en una reunin de revisin.
A medida que nuevos mtodos de diseo y las
Los tipos especficos de problemas deben ser o desde el software en el servicio Calidad
y por lodetanto
Software 10-
19
agrupados para identificar tendencias en el pueden ser utilizados para estimar la
tiempo. El punto es establecer una taxonoma probabilidad de fallos futuros y para ayudar en
de defectos que sea significativo para la las decisiones sobre cundo detener la prueba.
organiza- cin y para los ingenieros de Una probable accin resultante de SQM hallazgo
software. Ings es eliminar los defectos del producto objeto
actividades de control de la calidad del software de examen (por ejemplo, encontrar y corregir
descubrir infor- macin en todas las etapas de errores, crear nueva construccin). Otras
desarrollo de software y mantenimiento. En actividades intentan eliminar
algunos casos, la palabra defecto est
sobrecargado para referirse a diferentes tipos
de anomalas. Sin embargo, diferentes cultivos
de ingeniera y Standards pueden utilizar algo
diferentes significados para estos trminos. La
variedad de trminos solicita esta sec- cin
para proporcionar un conjunto ampliamente
utilizado de las definiciones [19]:

Error de clculo: La diferencia entre un

valor calculado, observado o medido o
condicin y el verdadero, especificado, o
el valor o condicin tericamente
correcto
Error: Una accin humana que produce
un resultado incorrecto. Un resbaln o un
error que hace que per- sona. Tambin
llamado error humano.
Defecto: Un imperfeccin o deficiencia
en un producto de trabajo donde ese
producto de trabajo no cumple con sus
requisitos o especificaciones y necesita ser
reparado o reemplazado. Un defecto es
causado por una persona que cometa un
error.
Culpa: Un defecto en el cdigo fuente. Un
paso, proceso o definicin incorrecta de
datos en el programa de ordenador. La
codificacin de un error humano en el
cdigo fuente. Culpa es el nombre formal
de un error.
Fracaso: Un evento en el cual un sistema
o componente de sistema no realiza una
funcin requerida dentro de los lmites
especificados. Un fallo se produce
cuando una falla se encuentra por el
procesador en condiciones especificadas.

Usando estas definiciones tres mediciones de

calidad de soft- ware ampliamente utilizados
son la densidad de defectos (nmero de
defectos por unidad de tamao de documentos),
la densidad de fallo (nmero de fallos por 1K
lneas de cdigo), y la intensidad fallo (fallos
por uso-hora o por prueba -hora). modelos de
fiabilidad se construyen a partir de datos de
fallos recogidos durante las pruebas de software
 Calidad de Software 10-
11

las causas de los defectos, por ejemplo, anlisis Se utilizan sobre todo para verificar los requisitos
de la causa raz (RCA). RCA actividades de software y diseos. En su mayora se han
incluyen analizar y resumir los resultados para utilizado en la veri ficacin de partes cruciales de
encontrar las causas de raz y el uso de tcnicas los sistemas crticos, como los requisitos de
de medicin para mejorar el producto y el seguridad y proteccin especficas. (Ver
proceso, as como para realizar un seguimiento
de los defectos y su eliminacin. La mejora de
procesos se discute principalmente en el proceso
de software Engineer- ing KA, con el proceso de
SQM ser una fuente de informacin.
Los datos sobre las insuficiencias y defectos
encontrados por las tcnicas de control de
calidad de software se pueden perder a menos
que se graban. Para algunas tcnicas (por
ejemplo, revisiones tcnicas, auditoras,
inspecciones), grabadoras estn presentes para
establecer cin tales informa-, junto con las
cuestiones y decisiones. Cuando se utilizan
herramientas automatiza apareadas (ver tema 4,
Software cali- dad Herramientas), la salida de la
herramienta puede proporcionar la informacin
de defectos. Los informes sobre defectos se
proporcionan a la gestin de la organizacin.

3.3. Tcnicas de gestin de calidad de software

[7 *, c7s3] [8 *, c17] [9 *, c12s5, c15s1, P417]
[diecisis*]

tcnicas de control de calidad de software se

pueden cat- egorized de muchas maneras, pero
un enfoque sencillo utiliza slo dos categoras:
estticas y dinmicas. tcnicas dinmicas
implican la ejecucin del software; tcnicas
estticas implican documentos de anlisis y el
cdigo fuente, pero no ejecutar el software.

3.3.1. Tcnicas estticas

tcnicas estticas examinan software de

documentacin cin (incluidos los requisitos de
interfaz, ciones especificacin, diseos y
modelos) y el cdigo fuente del software sin
ejecutar el cdigo. Hay muchas herramientas y
tcnicas para el examen de forma esttica
productos de trabajo soft- ware (vase la seccin
2.3.2). En adi- cin, herramientas que analizan
fuente de flujo de control de cdigo y la
bsqueda de cdigo muerto se considera que son
herramientas de anlisis esttico, ya que no
implican la ejecucin del cdigo de software.
Otros, ms formales, los tipos de tcnicas de
anlisis son conocidos como mtodos formales.
10-12 Gua SWEBOK V3.0
Tambin Mtodos formales en la Engineer-
Software ing modelos y mtodos KA).

3.3.2. Las tcnicas dinmicas

tcnicas dinmicas implican la ejecucin del

cdigo de soft- ware. Diferentes tipos de
tcnicas dinmicas se realizan durante todo el
desarrollo y mantenimiento de software.
tcnicas Generalmente, estos son pruebas, pero
tcnicas tales como La simulacin y anlisis
del modelo pueden considerarse dinmica (ver
los modelos ingeniera de software y Mtodos
KA). La lectura de cdigos se considera una
tcnica esttica, pero el software de inge-
nieros pueden ejecutar el cdigo a medida que
leen a travs de l experiment. La lectura de
cdigos puede utilizar tcnicas dinmicas. Esta
discrepancia en la categorizacin indica que las
personas con diferentes roles y experiencia en
la organizacin pueden considerar y aplicar
estas tcnicas de forma diferente.
Diferentes grupos pueden realizar pruebas
durante el desarrollo de software, incluidos los
grupos inde- pendiente del equipo de
desarrollo. La Prueba KA Software est
dedicado enteramente a este tema.

3.3.3. Pruebas

Dos tipos de pruebas pueden caer bajo V & V

debido a su responsabilidad por la calidad de
los mate- riales utilizados en el proyecto:

Evaluacin y pruebas de herramientas que

se utilizarn en el proyecto
pruebas de conformidad (o revisin de
pruebas Mance confor-) de componentes y
COTS Pro- ductos para ser utilizados en el
producto.

A veces, una (de terceros o IV y V)

independiente organizacin puede ser la tarea
de realizar pruebas o para controlar el proceso
de prueba V & V pueden ser llamados para
evaluar la prueba en s: adecuacin de los
planes, procesos y procedimientos, y la
adecuacin y la precisin de resultados.
El tercero no es el desarrollador, ni est
asociada con el desarrollo del producto. En
cambio, el tercero es un independiente para sus
instalaciones, por lo general acreditado por
algn organismo de la autoridad. Su propsito
es poner a prueba un producto para la
conformidad con un conjunto especfico de
requisitos (vase la Prueba KA Software).
 Calidad de Software 10-
13

3.4. Medicin de la Calidad de Software anlisis de tendencia (por ejemplo, grficos

[3 *, c4] [8 *, c17] [9 *, de control; ver La caja de herramientas de
p90] calidad en la lista de lecturas adicionales)
la prediccin (por ejemplo, modelos de
mediciones de calidad de software se utilizan fiabilidad).
para apoyar la toma de decisiones. Con la
creciente sofisticacin de software, las tcnicas basadas en la estadstica descriptiva y
cuestiones de calidad van ms all de si es o no pruebas a menudo proporcionan una instantnea
el software funciona a lo bien que logra los de la ms
objetivos de calidad medibles.
Decisiones soportados por surement medi-
calidad del software incluyen los niveles de
calidad del software determinar (en particular,
porque los modelos de la calidad del producto de
software incluyen medidas para determinar el
grado en que el producto de software logra las
metas de calidad); cuestiones de gestin sobre el
esfuerzo, costo y cronograma; determinar
cundo parar de Exmenes y liberar un producto
(ver terminacin en la seccin 5.1, las
consideraciones prcticas, en el KA Soft-
Testing Ware); y determinar la eficacia de los
esfuerzos de mejora de procesos.
El costo de los procesos SQM es un problema
FRECUENTEMENTE criado en la decisin de
cmo se deben organizar un proyecto o un grupo
de desarrollo y mantenimiento de las mercancas
blandas. A menudo, se utilizan modelos
genricos de costo, que se basan en cuando se
encuentra un defecto y la cantidad de esfuerzo
que se necesita para corregir el defecto relacin
tivo a encontrar el defecto ms temprano en el
proceso de desa- rrollo. los datos de medicin de
la calidad de software recopilados internamente
pueden dar una mejor idea de costo dentro de
este proyecto u organizacin.
Mientras que los datos de medicin de la
calidad del software puede ser til en s mismo
(por ejemplo, el nmero de requisitos
defectuosos o la proporcin de los requisitos
defectuosos), las tcnicas matemticas y grficas
se pueden aplicar para ayudar en la
interpretacin de las medidas (vase la
Ingeniera fundamentos KA). Estas tcnicas
incluyen

estadstica descriptiva base (por ejemplo,

anlisis de Pareto, diagramas de
funcionamiento, diagramas de dispersin,
distribucin normal)
pruebas estadsticas (por ejemplo, la prueba
binomial, chi-
squared test)
10-14 Gua SWEBOK V3.0 semntico sin ejecutar el cdigo, y presentar los
reas problemticas del producto de software
bajo examen. Las tablas y grficos resultantes resultados a los usuarios. Hay una gran variedad
son ayudas de visualizacin, que la decisin en la profundidad, THOR oughness, y el alcance
MAK- ERS puede utilizar para enfocar los de herramientas de anlisis esttico que
recursos y llevar a cabo mejoras pro Cess en el
que parecen estar ms se necesita. Los
resultados de anlisis de tendencias pueden
indicar que se est cumpliendo un horario, tal
como en la prueba, o que ciertas clases de
fallos pueden llegar a ser ms probable que
ocurra a menos que se tome alguna accin
correctiva en el desarrollo. Las tcnicas de
prediccin facilitar la estimacin de esfuerzo
de pruebas y el horario y en la prediccin de
fallos. Ms discusin sobre la medicin en
general aparece en el Proceso de Ingeniera de
Software Ingeniera de Software y Gestin de
Kas. informacin ms especfica sobre la
medicin de la prueba se presenta en la Prueba
de Software KA.
Software de medicin de la calidad incluye
medi- suring ocurrencias de defectos y la
aplicacin de mtodos estadsticos para
comprender los tipos de defectos que se
producen con mayor frecuencia. Esta
informacin puede ser utilizada por la mejora
de procesos de software para los mtodos de
minera determinantes para prevenir, reducir, o
eliminar su recurrencia. Tambin ayudan en la
comprensin de las tendencias, lo bien que la
deteccin y contencin tcni- cas estn
trabajando, y qu tan bien los procesos, crear y
mantener desarrollos estn progresando. A
partir de estos mtodos de medicin, los
perfiles de defectos se pueden desarrollar para
un dominio apli- cacin especfica. Entonces,
para el siguiente proyecto de software dentro
de esa organizacin, los perfiles se pueden
utilizar para guiar los procesos que SQM es,
hacer el esfuerzo donde los problemas son ms
probable que ocurra. Del mismo modo, puntos
de referencia, o recuentos de defectos tpicos
de ese dominio, pueden servir como una ayuda
en la determinacin cuando el producto est
listo para la entrega. Discusin del sobre con
los datos de SQM para mejorar los procesos
rrollo y mantenimiento desa- aparece en la
Gestin de Ingeniera de Software y Software
Ingeniera de Procesos de Kas.

4. Herramientas de Calidad de Software

herramientas de calidad de software incluyen

herramientas de anlisis esttico y dinmico. El
anlisis esttico de cdigo fuente de entrada de
herramientas, realizar el anlisis sintctico y
 Calidad de Software 10-
15

se puede aplicar a los artefactos incluyendo Herramientas que apoyan el seguimiento de

modelos, adems de cdigo fuente. (Vase el los problemas ms software para
truc