Swebok v3 PDF

Guía de la Ingeniería de Software de
Administración de Conocimiento
versión 3.0
SWEBOK ®
Un proyecto del IEEE Computer Society

Guía de la Ingeniería de Software
de Administración de
Conocimiento
versión 3.0
editores
Pierre Bourque, Escuela de Tecnología Superior (ETS)
Richard E. (Dick) Fairley, Software e Ingeniería de Sistemas Asociados (S2EA)
Derechos de autor y reimpresión 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 página 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 creación de nuevas obras colectivas para la reventa o redistribución debe ser obtenido de IEEE por escrito a la Oficina
de Derechos de Propiedad Intelectual IEEE, 445 Hoes Lane, Piscataway, NJ 08854-4.141 opubs-permissions@ieee.org.
La referencia a cualquier producto comercial específico, proceso o servicio no implica reconocimiento alguno por el IEEE.
Los puntos de vista y opiniones expresadas en esta publicación no reflejan necesariamente las de la IEEE.
IEEE pone este documento a disposición “tal cual” y no hace ninguna garantía, expresa o implícita, en cuanto a la exactitud,
la du- capaci-, comerciabilidad eficiencia, o el funcionamiento de este documento. En ningún caso, IEEE ser responsable de
los daños generales, consecuentes, indirectos, incidentales, ejemplares o especiales, incluso si IEEE ha sido advertido de la
posibilidad de tales daños.
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 Guía SWEBOK V3.0 se pueden descargar de forma gratuita para uso personal y académico a través
www.swebok.org.
El personal IEEE Computer Society para esta publicación

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 Educación Profesional
Kate Guillemette, Producto Editor Desarrollo
Dorian McClenahan, Programa de Educación desarrollador del producto
Michelle Phon, Educación Profesional y Coordinador del Programa de
Certificación Jennie Zhu-Mai, diseñador 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 ingeniería equipo autorizado, revistas, actas de congresos y
productos de educación profesional. Visite la Sociedad Informática de lawww.computer.org para más información.
TABLA DE CONTENIDO
Forewordxvii
Prólogo a la Editionxix 2004
Editorsxxi
Coeditorsxxi
contribuyendo Editorsxxi
Cambio de control Boardxxi
Área de conocimiento Editorsxxiii
Editores Área de Conocimiento de Anterior SWEBOK Versionsxxv
revisión Teamxxvii
Acknowledgementsxxix
Junta actividades profesionales, 2013 Membershipxxix
Movimientos respecto a la aprobación de la Guía SWEBOK V3.0xxx
Movimientos respecto a la aprobación de la Guía SWEBOK 2004 Versiónxxx
Introducción a la Guidexxxi
Capítulo 1: Software requisitos 1-1

1. Requisitos de software Fundamentals1-1
1.1. Definición 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. Administración 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. técnicas de obtención 1-6
4. requisitos Analysis1-7
4.1. requisitos Clasificación 1-7
4.2. Modelado conceptual 1-8
4.3. Diseño y requisitos arquitectónicos Asignación 1-9
4.4. requisitos de Negociación 1-9
4.5. Análisis formal 1-10
5. requisitos Specification1-10
5.1. Definición del sistema de documentos 1-10
5.2. Requisitos del sistema Especificación 1-10
5.3. Especificación de Requerimientos de Software 1-11
6. requisitos Validation1-11
6.1. requisitos críticas 1-11
6.2. prototipado 1-12
v
6.3. Modelo de validación 1-12
6.4. Prueba de aceptacion 1-12
7. Considerations1-12 práctica
7.1. La naturaleza iterativa del proceso Requisitos 1-13
7.2. Gestión del cambio 1-13
7.3. requisitos Atributos 1-13
7.4. requisitos de rastreo 1-14
7.5. La medición de Requisitos 1-14
8. Requisitos de software Tools1-14
Matriz de Temas vs. Referencia Material1-15
Capítulo 2: Software Diseño 2-1

1. El software de diseño Fundamentals2-2
1.1. Conceptos generales de diseño 2-2
1.2. Contexto de Diseño de Software 2-2
1.3. Software de Diseño de Procesos 2-2
1.4. Principios de Diseño de Software 2-3
2. Aspectos críticos 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. Distribución de Componentes 2-4
2.5. Error y control de excepciones y la tolerancia a fallos 2-4
2.6. Interacción y Presentación 2-4
2.7. Seguridad 2-4
3. Estructura del software y Architecture2-4
3.1. Las estructuras arquitectónicas y puntos de vista 2-5
3.2. Estilos arquitectónicos 2-5
3.3. Patrones de diseño 2-5
3.4. Las decisiones Arquitectura Diseño 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 diseño de interfaces 2-6
4.2. Interfaz de usuario Problemas Diseño 2-6
4.3. El diseño de las modalidades de interacción del usuario 2-6
4.4. El diseño de la información Presentación 2-6
4.5. Proceso de Interfaz de usuario Diseño 2-7
4.6. Localización e internacionalización 2-7
4.7. Metáforas y modelos conceptuales 2-7
5. Diseño Análisis de Calidad de Software y Evaluation2-7
5.1. Los atributos de calidad 2-7
5.2. Análisis de calidad y técnicas de evaluación 2-8
5.3. medidas 2-8
6. El software de diseño Notations2-8
6.1. Las descripciones estructurales (estático Vista) 2-8
6.2. Las descripciones de comportamiento (vista dinámica) 2-9
7. Software de Diseño y Estrategias Methods2-10
7.1. Las estrategias generales 2-10
7.2. Función-Oriented (Estructurado) Diseño 2-10
7.3. Diseño Orientado a Objetos 2-10
7.4. Estructura de Datos Diseño Centrado 2-10
7.5. Diseño basado en componentes (CDB) 2-10
7.6. Otros metodos 2-10
8. El software de diseño Tools2-11
Capítulo 3: Software Construcción 3-1

1. Construcción de Software Fundamentals3-1
1.1. Complejidad minimizando 3-3
1.2. pronóstico del cambio 3-3
1.3. La construcción de Verificación 3-3
1.4. Reutilizar 3-3
1.5. Normas de construcción 3-3
2. Gerente Construction3-4
2.1. Construcción de Modelos de Ciclo de Vida 3-4
2.2. Ordenación de la Edificación 3-4
2.3. Medición de la construcción 3-4
3.1. Diseño de la construcción 3-5
3.2. Idiomas de construcción 3-5
3.3. Codificación 3-6
3.4. Prueba de la construcción 3-6
3.5. Construcción de Reutilización 3-6
3.6. Construcción con reutilización 3-7
3.7. construcción de Calidad 3-7
3.8. Integración 3-7
4. construcción Technologies3-8
4.1. Diseño y Uso de la API 3-8
4.2. Orientado a Objetos Problemas de tiempo de ejecución 3-8
4.3. Parametrización y Genéricos 3-8
4.4. Afirmaciones, Diseño por contrato, y la programación 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 técnicas de construcción basadas en tablas de base estatal y 3-9
4.8. Configuración de tiempo de ejecución y la internacionalización 3-10
4.9. Procesamiento de la entrada Gramática-Basado 3-10
4.10. Las primitivas de concurrencia 3-10
4.11. middleware 3-10
4.12. Métodos de construcción de software distribuido 3-11
4.13. La construcción de sistemas heterogéneos 3-11
4.14. Análisis de Rendimiento y ajuste 3-11
4.15. Normas de plataforma 3-11
4.16. Programación Test-First 3-11
5. Construcción 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, análisis de rendimiento, y cortar Herramientas 3-12
Capítulo 4: Software Pruebas 4-1

1. Software de Pruebas Fundamentals4-3
1.1. Terminología de pruebas relacionados 4-3
1.2. Cuestiones clave 4-3
1.3. Relación 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 intuición y la experiencia del ingeniero de software 4-8
3.2. Las técnicas basadas en el dominio de entrada 4-8
3.3. Técnicas de código-base 4-8
3.4. Técnicas basada en la culpa 4-9
3.5. Técnicas de uso-Basado 4-9
3.6. Técnicas de ensayo basado en modelos 4-10
3.7. Las técnicas basadas en la naturaleza de la aplicación 4-10
3.8. La selección y la combinación de técnicas 4-11
4. Prueba relacionada Measures4-11
4.1. Evaluación de la prueba el marco del Programa 4-11
4.2. La evaluación de las pruebas realizadas 4-12
5. Process4-12 prueba
5.1. Consideraciones prácticas 4-13
5.2. Prueba Ocupaciones 4-14
6. Software de Pruebas Tools4-15
6.1. Pruebas herramienta de soporte 4-15
6.2. Categorías de Herramientas 4-15
Capítulo 5: Software Mantenimiento 5-1

1. El software de mantenimiento Fundamentals5-1
1.1. Definiciones y terminología 5-1
1.2. Naturaleza de Mantenimiento 5-2
1.3. La necesidad de mantenimiento 5-3
1.4. La mayoría de los costos de mantenimiento 5-3
1.5. Evolución de Software 5-3
1.6. Categorías de Mantenimiento 5-3
2. Aspectos críticos de software Maintenance5-4
2.1. Técnico Cuestiones 5-4
2.2. Asuntos Gerenciales 5-5
2.3. Estimación de costes de mantenimiento 5-6
2.4. Medición 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 técnicas para Maintenance5-10
4.1. programa de Comprensión 5-10
4.2. reingeniería 5-10
4.3. Ingeniería inversa 5-10
4.4. Migración 5-10
4.5. Jubilación 5-11
5. El software de mantenimiento Tools5-11

Capítulo 6: Software Gestión de la configuración 6-1

1. Gestión de la SMC Process6-2
1.1. Contexto de organización de SMC 6-2
1.2. Limitaciones y orientación para el proceso SMC 6-3
1.3. La planificación de SMC 6-3
1.4. plan de SMC 6-5
1.5. La vigilancia de la Gestión de la Configuración de Software 6-5
2. Configuración del software Identification6-6
2.1. Los productos que la identificación que deben ser controlados 6-6
2.2. software Library 6-8
3. Configuración del software Control6-8
3.1. Solicitar, evaluar y cambios que aprueba Software 6-8
3.2. Cambios en el software de aplicación 6-9
3.3. Desviaciones y renuncias 6-10
4. Estado de la configuración de software Accounting6-10
4.1. Software de información de estado de configuración 6-10
4.2. Informes de estado de configuración de software 6-10
5. Configuración del software Auditing6-10
5.1. Software de Auditoría de Configuración Funcional 6-11
5.2. Auditoría de Configuración física de software 6-11
5.3. En-Proceso de Auditorías de una línea de base del software 6-11
6. Gestión de la Entrega de Software y Delivery6-11
6.1. Edificio de software 6-11
6.2. Gestión de la Entrega de Software 6-12
7. Gestión de la Configuración de Software Tools6-12
Capítulo 7: Software Ingenieria administración 7-1

1. Iniciación y Alcance Definition7-4
1.1. La determinación y la negociación de los requisitos 7-4
1.2. Análisis de viabilidad 7-4
1.3. Proceso para el examen y revisión de los requisitos 7-5
2. Proyecto de software Planning7-5
2.1. Planificación de procesos 7-5
2.2. determinar entregables 7-5
2.3. Esfuerzo, Calendario, y Estimación de Costos 7-6
2.4. Asignación de recursos 7-6
2.5. Gestión de riesgos 7-6
2.6. Gestión de la calidad 7-6
2.7. Gestión del plan 7-7
3. Proyecto de software Enactment7-7
3.1. Implementación de Planes 7-7
3.2. Software de Adquisición y Gestión de Proveedores Contrato 7-7
3.3. Implementación 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. Revisión y Evaluation7-8
4.1. La determinación de satisfacción de los requisitos 7-8
4.2. Revisión y Evaluación del desempeño 7-9
5. Closure7-9
5.1. Cierre la determinación 7-9
5.2. Actividades de cierre 7-9
6. Ingeniería de Software Measurement7-9
6.1. Establecer y mantener el compromiso de Medición 7-9
6.2. Planificar el proceso de medición 7-10
6.3. Realizar el proceso de medición 7-11
6.4. evaluar Medición 7-11
7. Ingeniería de Software de Gestión Tools7-11
Capítulo 8: Software Ingenieria Proceso 8-1

1. procesos de software Definition8-2
1.1. Gestión de procesos de software 8-3
1.2. Infraestructura de Procesos de Software 8-4
2. Software vida Cycles8-4
2.1. Categorías de procesos de software 8-5
2.2. Modelos de Ciclo de vida del software 8-5
2.3. La adaptación de procesos de software 8-6
2.4. Consideraciones prácticas 8-6
3. Proceso de Evaluación y software Improvement8-6
3.1. Modelos de evaluación de procesos de software 8-7
3.2. Proceso de Software Métodos de evaluación 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 Medición del producto 8-9
4.2. Calidad de los resultados de medición 8-10
4.3. Información de software Modelos 8-10
4.4. Técnicas de medición de procesos de software 8-11
5. Proceso de Ingeniería de Software Tools8-12
Capítulo 9: Software Modelos de ingeniería y métodos 9-1

1. Modeling9-1
1.1. Principios de modelado 9-2
1.2. Propiedades y Expresión de Modelos 9-3
1.3. Sintaxis, la semántica y la pragmática 9-3
1.4. Condiciones previas, postConditions, e invariantes 9-4
2. Tipos de Models9-4
2.1. Modelado de información 9-5
2.2. Modelado del comportamiento 9-5
2.3. Modelado estructura 9-5
3. Análisis de Models9-5
3.1. Para completar el análisis 9-5
3.2. La consistencia para analizar 9-6
3.3. El análisis de la corrección 9-6

3.4. trazabilidad 9-6
3.5. Análisis de interacción 9-6
4. Ingeniería de Software Methods9-7
4.1. Los métodos heurísticos 9-7
4.2. Métodos formales 9-7
4.3. Los métodos de prototipado 9-8
4.4. Los métodos ágiles 9-9
Capítulo 10: Software Quality10-1

1. Software de calidad Fundamentals10-2
1.1. Software de Ingeniería de la Cultura y Ética 10-2
1.2. Valor y los costos de Calidad 10-3
1.3. Modelos y características de calidad 10-3
1.4. Mejora de la Calidad de Software 10-4
1.5. software de Seguridad 10-4
2. Software de Gestión de Calidad Processes10-5
2.1. Calidad de Software 10-5
2.2. Verificación validación 10-6
2.3. Revisiones y auditorías 10-6
3.1. Requisitos de calidad de software 10-9
3.2. Caracterización de defectos 10-10
3.3. Técnicas de gestión de calidad de software 10-11
3.4. Medición de la Calidad de Software 10-12
4. Software de calidad Tools10-12
Capítulo 11: Software profesional de la ingeniería Práctica 11-1

1. Professionalism11-2
1.1. Acreditación, Certificación y Licencias 11-3
1.2. Códigos de Ética y Conducta Profesional 11-4
1.3. La naturaleza y la función de las Sociedades Profesionales 11-4
1.4. La naturaleza y la función de las normas de ingeniería de software 11-4
1.5. Impacto económico de Software 11-5
1.6. Contratos de trabajo 11-5
1.7. Asuntos legales 11-5
1.8. Documentación 11-7
1.9. Análisis compensación 11-8
2. Dinámica de Grupos y Psychology11-9
2.1. Dinámica de trabajo en equipos / grupos 11-9
2.2. cognición individual 11-9
2.3. Tratar con el problema Complejidad 11-10
2.4. La interacción con las partes interesadas 11-10
2.5. Superación de la incertidumbre y la ambigüedad 11-10
2.6. Tratar con entornos multiculturales 11-10
3. comunicación Skills11-11
3.1. Leer, comprender y resumir 11-11
3.2. Escritura 11-11

3.3. Equipo y Comunicación Grupo 11-11
3.4. Habilidades de presentación 11-12
Capítulo 12: Software Ingenieria Economics12-1

1. Ingeniería de Software Economía 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. Valuación 12-5
1.7. Inflación 12-6
1.8. Depreciación 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 inversión 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. Medición del desempeño 12-9
2.13. Gestion del valor ganado 12-9
2.14. Las decisiones de terminación 12-9
2.15. Las decisiones de reemplazo y jubilación 12-10
3. Riesgo y Uncertainty12-10
3.1. Metas, estimaciones, y Planes 12-10
3.2. Las técnicas de estimación 12-11
3.3. La incertidumbre abordar 12-11
3.4. priorización 12-11
3.5. Las decisiones en riesgo 12-11
3.6. Las decisiones bajo incertidumbre 12-12
4. Análisis económico Methods12-12
4.1. Con fines de lucro Análisis de Decisiones 12-12
4.2. Tasa de retorno mínima aceptable 12-13
4.3. Retorno de la Inversión 12-13
4.4. Rendimiento del capital invertido 12-13
4.5. Análisis coste-beneficio 12-13
4.6. Análisis coste-efectividad 12-13

4.7. Punto de equilibrio de analisis 12-13
4.8. Business Case 12-13
4.9. Evaluación Atributo múltiple 12-14
4.10. Análisis de optimización 12-14
5.1. El “suficientemente bueno” Principio 12-14
5.2. Economía-Friction Free 12-15
5.3. ecosistemas 12-15
5.4. La deslocalización y la externalización 12-15
Capítulo 13: Informática Foundations13-1

1. Resolución de Problemas Techniques13-3
1.1. Definición de la resolución de problemas 13-3
1.2. Formular el problema real 13-3
1.3. Analizar el problema 13-3
1.4. Diseñar una estrategia de búsqueda de soluciones 13-3
1.5. La resolución de problemas Utilización de programas 13-3
2. Abstraction13-4
2.1. Los niveles de abstracción 13-4
2.2. La encapsulación 13-4
2.3. Jerarquía 13-4
2.4. Las abstracciones alternativos 13-5
3. programación Fundamentals13-5
3.1. El proceso de programación 13-5
3.2. Los paradigmas de programación 13-5
4. Lenguaje de Programación Basics13-6
4.1. Lenguaje de Programación general 13-6
4.2. Sintaxis y semántica de lenguajes de programación 13-6
4.3. Bajo Programación y Lenguajes 13-7
4.4. -Programación y Lenguajes 13-7
4.5. vs. declarativa de programación imperativo Idiomas 13-7
5. Herramientas de depuración y Techniques13-8
5.1. tipos de errores 13-8
5.2. Las técnicas de depuración 13-8
5.3. Herramientas de depuración 13-8
6. Estructura de datos y Representation13-9
6.1. Presentación 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. Descripción general de Algoritmos 13-10
7.2. Atributos de Algoritmos 13-10
7.3. Análisis algorítmico 13-10
7.4. Estrategias de diseño algorítmico 13-11
7.5. Estrategias de análisis algorítmico 13-11
8. Concepto básico de un System13-11
8.1. Propiedades del sistema emergente 13-11
8.2. Ingeniería de Sistemas 13-12

8.3. Visión general de un sistema informático 13-12
9. Organization13-13 equipo
9.1. Organización general del ordenador 13-13
9.2. Sistemas digitales 13-13
9.3. lógica digital 13-13
9.4. Expresión de datos del ordenador 13-13
9.5. La Unidad Central de Procesamiento (CPU) 13-14
9.6. Organización del Sistema de memoria 13-14
9.7. Entrada y salida (I / O) 13-14
10. compilador Basics13-15
10.1. Compilador / intérprete general 13-15
10.2. Interpretación y compilación 13-15
10.3. El proceso de compilación 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 clasificación 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 Gestión 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. Gestión de datos 13-19
12.6. La minería de datos 13-19
13. Red de Comunicación Basics13-19
13.1. tipos de la Red 13-19
13.2. Componentes de la Red Básica 13-19
13.3. Protocolos de red y Estándares 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. Computación paralela y distribuida general 13-21
14.2. Diferencia entre Computación Paralela y Distribuida 13-21
14.3. Modelos de Computación Paralela y Distribuida 13-21
14.4. Problemas principales en Distributed Computing 13-22
15. Usuario básico 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 básica 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. Diseño de Software de Seguridad 13-25
17.3. El software de seguridad de construcción 13-25
17.4. El software de seguridad de Pruebas 13-25
17.5. Construir Seguridad en Ingeniería de Procesos de Software 13-25

17.6. Guía de seguridad de software 13-25
Capítulo 14: Matemático Foundations14-1

1. Conjunto, Relaciones, Functions14-1
1.1. las operaciones Set 14-2
1.2. Propiedades del Conjunto 14-3
1.3. Relación y función 14-4
2. básico Logic14-5
2.1. Lógica proposicional 14-5
2.2. La lógica de predicados 14-5
3. Techniques14-6 prueba
3.1. Métodos de demostración de teoremas 14-6
4. Fundamentos de la Counting14-7
5. Los gráficos y Trees14-8
5.1. Los gráficos 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. Numérica de precisión, exactitud y Errors14-17
10. número Theory14-18
10.1. Divisibilidad 14-18
10.2. Número primo, GCD 14-19
11. algebraica Structures14-19
11.1. Grupo 14-19
11.2. anillos 14-20
Capítulo 15: Ingenieria Foundations15-1

1. Métodos empíricos y Experimental Techniques15-1
1.1. experimento diseñado 15-1
1.2. Estudio observacional 15-2
1.3. Estudio retrospectivo 15-2
2. Análisis estadístico 15-2
2.1. Unidad de análisis (unidades de muestreo), Población y Muestra 15-2
2.2. Conceptos de correlación y regresión 15-5
3. Measurement15-5
3.1. Niveles (Scales) de Medición 15-6
3.2. Medidas directos y derivados 15-7
3.3. Fiabilidad y Validez 15-8
3.4. Fiabilidad evaluar 15-8
4. ingeniería Design15-8
4.1. Diseño de ingeniería en la Educación en Ingeniería 15-8
4.2. El diseño como Solución de problemas Actividad 15-9
4.3. Pasos a seguir en Diseño de Ingeniería 15-9
5. Modelado, Simulación y Prototyping15-10
5.1. Modelado 15-10
5.2. Simulación 15-11

5.3. prototipado 15-11
6. Standards15-12
7. Causa Raíz Analysis15-12
7.1. Las técnicas para la realización de análisis de causa raíz 15-13
Apéndice A: Área de Conocimiento Descripción Presupuesto A-1
Apéndice B: IEEE e ISO / IEC Apoyo a la Ingeniería de Software

Cuerpo de conocimientos (SWEBOK) B-1
Apéndice DO: Referencia consolidada Lista C-1

PREFACIO
El software de inge- niería cuerpo de

Cada profesión se basa en un conjunto de conocimientos está constantemente en evolución
conocimientos, a pesar de que el conocimiento ing. Sin embargo, esta guía constituye una
no siempre se define de una manera concisa. En caracterización valioso poder de la profesión de la
los casos en que no existe ninguna formalidad, el ingeniería de software.
cuerpo de conocimiento se “GEN-ralmente
reconocido” por los médicos y puede ser
codificado en una variedad de formas para una
variedad de usos diferentes. Pero en muchos
casos, una guía 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 acreditación
de programas académicos y de capacitación,
certificación de especialistas, o licencia
profesional. En general, una asociación
profesional u organismo similar mantiene la
administración de la definición formal de un
conjunto de conocimientos.
Durante los últimos cuarenta y cinco años, la
ingeniería de software ha evolucionado a partir
de una frase conferencia Catch en una profesión
de la ingeniería, caracteriza- da por la 1) una
sociedad profesional, 2) las normas que
especifican las prácticas profesionales
generalmente aceptadas;
3) un código 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
acreditación y programas de grado acreditados,
8) la certificación y concesión de licencias, y 9)
de esta guía al cuerpo de conocimientos.
En esta Guía para la Ingeniería de Software de
Administración de Conocimiento, las cons-
tituye IEEE Computer Society una versión
revisada y del conjunto de conocimientos
anteriormente documentado como SWEBOK
2004 actualizado; esta versión 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 teoría y la práctica de la profesión
de la ingeniería de software.
Cabe señalar que esta Guía no presenta la
totalidad del cuerpo de conocimientos de
ingeniería de software, sino que sirve como
guía para el conjunto de conocimientos que se
ha desarrollado durante más de cuatro décadas.
capturado en SWEBOK 2004. La versión actual
En 1958, John Tukey, la istician stat- de de 12207 se designa como ISO / IEC 12207:
renombre mundial, acuñó el término software. 2008 e IEEE 12.207 a 2.008; eso
La ingeniería de software término fue utilizado proporciona la base para este V3 SWEBOK.
en el título de una conferencia de la OTAN Esta guía para la Ingeniería de Software de
celebrada en Alemania en 1968. El IEEE Administración de Conocimiento se presenta a
Computer Society publicó por primera vez sus usted, el lector, como un mecanismo para
Transacciones de Ingeniería 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 ingeniería de profesional de la ingeniería de software.
software dentro de Están- la IEEE Computer
Society en 1976.
En 1990, se inició la planificación para una Dick Fairley, Presidente
norma internacional para proporcionar una Software y Comité de Ingeniería de Sistemas
visión global de ingeniería de software. La IEEE Computer Society
norma se completó en 1995 con la designación
de la norma ISO / IEC 12207 y se le dio el
título de software estándar para cesos del Ciclo Don Shafer, vicepresidente
de Vida Pro-. La versión de IEEE 12207 fue Actividades profesionales
publicada en 1996 y proporcionó una base Junta IEEE Computer
importante para el conjunto de conocimientos Society
xvii
Prólogo a la edición de 2004
Exámenes, requisitos de software, diseño de

En esta guía, lishes la IEEE Computer Society software, y la verificación y validación de
esta- por primera vez una línea de base para el software.
conjunto de conocimientos para el campo de la Durante el periodo 1981-1985, la Sociedad
ingeniería 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 aplicación de la ingeniería
para promover el avance de la teoría y la de software
práctica en esta campo. De este modo, la
Sociedad se ha guiado por la experiencia de
disciplinas con historias más largas, pero no
estaba vinculado por sus problemas o sus
soluciones. Cabe señalar que la Guía no PUR
puerto para definir el conjunto de
conocimientos, sino más bien para servir como
un compendio y guías para el conjunto de
conocimientos que se ha venido desarrollando y
en evolución ing en las últimas cuatro décadas.
Por otra parte, este conjunto de conocimientos
no es estática. La guía debe, necesariamente,
desarrollar y evolucionar a medida que madura
la ingeniería de software. Sin embargo,
constituye un elemento valioso de la ingeniería
del software
infraestructura.
En 1958, John Tukey, la istician stat- de
renombre mundial, acuñó el término software.
La ingeniería de software término fue utilizado
en el título de una conferencia de la OTAN
celebrada en Alemania en 1968. El IEEE
Computer Society publicó por primera vez sus
Transacciones de Ingeniería de Software en
1972. El comité establecido en la IEEE
Computer Society para el desarrollo de
estándares de ingeniería de software fue fundada
en 1976.
La primera visión integral de ingeniería de
software para salir de la IEEE Computer Society
fue resultado de un esfuerzo dirigido por
Fletcher Buckley para desarrollar el estándar
IEEE 730 para el software de calidad de
aseguramiento, que se completó en 1979. El
propósito de la norma IEEE Std. 730 era
proporcionar uniformes, requisitos mínimos
aceptables para la preparación 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: gestión de configuración, software de
denomina- ción, ISO / IEC 12207, y se le dio el
normas. Estos talleres involucrados ners título 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 también proporciona un importante punto de partida para
se llevaron a cabo sesiones sobre la el conjunto de conocimientos capturados en este
Planificación de las normas futuras, incluyendo libro. Era la Junta IEEE Computer Society de
uno que incluya las medidas y métricas para la Gobernadores la aprobación de la moción
ingeniería de software de productos y procesos. presentada en mayo de 1993 mediante Fletcher
La planificación también resultó en IEEE Std. Buckley, que dio lugar a la redacción de este
1002, Taxonomía de Estándares de Ingeniería libro. La Association for Computing Machinery
de Software (1986), que proporcionó una Consejo (ACM) aprobó una moción relacionada
nueva visión holística de la ingeniería 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 ingeniería de un dirección de Mario Barbacci y Stuart Zweben
software taxonomía. Se explican los que sirvió como copresidentes. La declaración
diferentes tipos de Dardos de ingeniería de de la misión de la comisión conjunta era
software Están-, sus relaciones funcionales y “Establecer los conjuntos apropiados (s) de
externos, y el papel de las diversas funciones criterios y normas para la práctica profesional de
que participan en el ciclo de vida del software. la ingeniería de software sobre el cual siones
En 1990, se inició la planificación para un industriales terio, la certificación profesional, y
Dard Están- internacional con una visión de los programas de estudio se pueden basar.” El
conjunto. El la Planificación centrada sobre la comité directivo
conciliación 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 revisión fue publicada como 1. Definir Obligatorio cuerpo de
aliado eventu- DoD Std. 498. La norma conocimientos y
internacional se completó en 1995 con la Prácticas recomendadas.
xix
Guía xx SWEBOK® V3.0
2. Definir Ética y Estándares Profesionales. Se espera que los lectores encontrarán en este
3. Definir planes de estudio para la Educación libro uso-ful para guiarlos hacia el conocimiento
univer- y los recursos que necesitan en su carrera de por
comió, graduado, y la educación continua. vida desarrollo como profesionales de
ingeniería 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 promoción de la ingeniería de software como
prácticas. una disciplina profesional y su excelencia como
El código de ética y práctica profesional de la Tioner una ingeniería de software prác- en
ingeniería 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 Prácticas
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 profesión se basa en un cuerpo de El Ingeniería de Software como una Profesión (1998-
conocimiento y las prácticas recomendadas, a 1999)
pesar de que no siempre se definen de una
manera precisa. En muchos casos, éstos se Presidente del Comité de Estándares de Ingeniería 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 acreditación de programas
académicos, el desarrollo de programas de
educación y formación, la certificación de
especialistas, o licencia profesional. En
general, una sociedad profesional u organismo
relacionado mantiene la custodia de una
definición Mal tales lucro. En los casos en que
no exista tal formalidad, el conjunto de
conocimientos y prácticas recomendadas son
“generalmente reconocidos” por ners practitio- y
pueden ser codificados en una variedad de
maneras para diferentes usos.
EDITORES
Pierre Bourque, Departamento de Ingeniería de Software y TI, Escuela de Tecnología Superior (ETS),
Canadá, pierre.bourque@etsmtl.ca
Richard E. (Dick) Fairley, Software e Ingeniería de Sistemas Asociados (S2EA), EE.UU.,
dickfairley@gmail.com
coeditores
Alain Abran, Departamento de Ingeniería de Software y TI, Escuela de Tecnología Superior (ETS),
Canadá, alain.abran@etsmtl.ca
Juan Garbajosa, Universidad Politécnica de Madrid (Universidad Politécnica de Madrid, UPM),
España, juan.garbajosa@upm.es
Gargi Keeni, Tata Consultancy Services, la India, gargi@ieee.org
Beijun Shen, Escuela de software, Shanghai Jiao Tong Universidad, China, bjshen@sjtu.edu.cn
editores colaboradores
Las siguientes personas contribuyeron a la edición de la Guía 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 Guía
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 Informática y Comunicaciones, Universidad de Lancaster, Reino
Unido, gerald@comp.lancs.ac.uk
Peter Sawyer, Facultad de Informática y Comunicaciones, Universidad de Lancaster, Reino
Unido, sawyer@comp.lancs.ac.uk
Diseño de software
Yanchun Sol, Facultad de Ingeniería Electrónica e Informática, Universidad de Pekín, China,
sunyc@pku.edu.cn
Construcción de software
Xin Peng, Escuela de Software de la Universidad de Fudan, China, pengxin@fudan.edu.cn
Pruebas de software
Antonia Bertolino, ISTI-CNR, Italia,
antonia.bertolino@isti.cnr.it Eda Marchetti, ISTI-CNR, Italia,
eda.marchetti@isti.cnr.it
Mantenimiento del software

Alain abril de Escuela de Tecnología Superior (ETS), Canadá,
alain.april@etsmtl.ca Mira Kajko-Mattsson, Escuela de Tecnología de
Información y Comunicación, KTH Royal Institute of Technology,
mekm2@kth.se
Gestión de la Configuración de Software

Roger Champagne, Escuela de Tecnología Superior (ETS), Canadá, Roger.champagne @
etsmtl.ca
Alain abril de Escuela de Tecnología Superior (ETS), Canadá, alain.april@etsmtl.ca
Gestión de Ingeniería de Software

James McDonald, Departamento de Ciencias de la Computación e Ingeniería de
Software, Monmouth University, EE.UU., jamesmc@monmouth.edu
Proceso de Ingeniería de Software

Annette Reilly, Sistemas de Información y Lockheed Martin Global Solutions, EE.UU.,
annette.reilly@computer.org
Richard E. Fairley, Software e Ingeniería de Sistemas Asociados (S2EA), EE.UU.,
dickfairley@gmail.com
Modelos de Ingeniería de Software y Métodos

Michael F. Siok, Lockheed Martin Aeronáutica Company, EE.UU., mike.f.siok@lmco.com
Calidad del software

J. David Blaine, EE.UU., jdavidblaine@gmail.com
Durba Biswas, Tata Consultancy Services, la India, durba.biswas@tcs.com
Guía xxiv SWEBOK® V3.0
xxiii
Ingeniería de Software Práctica Profesional
Aura Sheffield, EE.UU., arsheff@acm.org
Hengming Zou, Shanghai Jiao Tong Universidad, China, zou@sjtu.edu.cn
Economía Ingeniería de Software

Christof Ebert, Servicios Consulting vectorial, Alemania, christof.ebert@vector.com
Fundamentos de computación
Hengming Zou, Shanghai Jiao Tong Universidad, China, zou@sjtu.edu.cn
Fundamentos matemáticos
Nabendu Chaki, Universidad de Calcuta, India, nabendu@ieee.org
Fundamentos de ingeniería
Amitava Bandyopadhayay, Instituto de Estadística de la India, la India,
bamitava@isical.ac.in Mary Jane Willshire, Software e Ingeniería de Sistemas
Asociados (S2EA), EE.UU., mj.fairley@gmail.com
Apéndice B: IEEE y normas ISO / IEC SWEBOK Apoyando

James W. Moore, EE.UU., James.W.Moore@ieee.org
DE VERSIONES SWEBOK ANTERIORES

Las siguientes personas sirvieron como editores asociados, ya sea para la versión de prueba publicados
en 2001, o
la versión 2004.
Peter Sawyer, Departamento de Informática, Universidad de
Lancaster, Reino Unido Gerald Kotonya, Departamento de
Informática, Universidad de Lancaster, Reino Unido
Diseño de software
Chico Tremblay, departamento de Informática, UQAM, Canadá
Construcción de software
Steve McConnell, Construx Software, EE.UU.
Terry Bollinger, la MITRE Corporation,
EE.UU.
Philippe Gabrini, departamento de Informática, UQAM, Canadá
Louis Martin, departamento de Informática, 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 Tecnología, Canadá
Gestión de la Configuración de Software

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

Dennis Frailey, Raytheon Company, EE.UU.
Stephen G. MacDonell, Universidad de Tecnología de Auckland, Nueva Zelanda
Andrew R. Gray, Universidad de Otago, Nueva Zelanda
Proceso de Ingeniería de Software

Khaled El Emam, sirvió mientras que en el Canadian National Research Council,
Canadá
Herramientas de ingeniería de software y métodos

David Carrington, Facultad de Tecnología de la Información e Ingeniería
Eléctrica de la Universidad de Queensland, Australia
xxv
Calidad del software

Alain abril de Escuela Superior de Tecnología, Canadá
Dolores Wallace, se retiró del Instituto Nacional de Estándares y Tecnología, EE.UU.
Larry Reeker, NIST, EE.UU.
referencias Editor
Marc Bouisset, departamento de Informática, UQAM
equipo de revisión
Las personas que figuran a continuación participaron en el proceso de revisión pública de la Guía
SWEBOK V3. La membresía de la IEEE Computer Society no era un requisito para participar en
este proceso de revisión, y la información de pertenencia no se ha solicitado a los colaboradores.
Más 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,
España 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 España,
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
Guía xxiv SWEBOK® V3.0 EE.UU.
Istvan Fay, Hungría
José L. Fernández- Bob Hillier, Canadá
Sánchez, Dennis J. Norman M. Hines,
España 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, Japón
Nueva Zelanda Michael A. Jablonski, EE.UU.
Garth JG Glynn, G. Jagadeesh, India
Reino Unido Sebastián Justicia, España
Jill Gostin, EE.UU. Umut Kahramankaptan, Bélgica
Christiane von Gresse Pankaj Kamthan, Canadá
Wangenheim, Brasil Thomas Perry Kapadia, EE.UU.
Gust, EE.UU. Tarig A. Khalid, Sudán
HN Michael KA Klaes, Alemania
Mok, MAGED Koshty, Egipto
Singapu Claude C. Laporte, Canadá
r Jon D. Dong Li, China
Hagar, Ben Linders, Países
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-Domínguez, Alemania Neetu Sethia,
España Silvia Judith Meles, India
Argentina Cindy C. Shelton, EE.UU.
Oscar A. Mondragon, México Alan Shepherd, Alemania
David W. Mutschler, EE.UU. Katsutoshi Shintani, Japón
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, Japón Hanna John Standen, Reino Unido
Oktaba, México 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, Japón 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, Japón
EE.UU. Warren E. Cenk Uyan, Turquía
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, Japón
María Isabel Sánchez-Segura, Ulf Westermann, Alemania
España 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
Guía XXVIII SWEBOK®
V3.0
EXPRESIONES DE GRATITUD
Los fondos para el desarrollo de la Guía 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 guía, ya sea directa o
equipo editorial también debe reconocer la indirectamente, cuyos nombres tenemos
contribución indispensable de los colaboradores. inadvertidamente omitido. Para esas personas,
El equipo de redacción desea también agradecer ofrecemos nuestra apre- ciación tácito y
a las personas siguientes que han contribuido al disculpas por haber omitido el reconocimiento
proyecto en explícito.
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
Guía xxx SWEBOK® V3.0
MOTIONS sobre la aprobación de SWEBOK

V3.0 GUÍA
La Guía SWEBOK V3.0 fue sometida a votación por los miembros del IEEE Computer Society
verificados en noviembre de 2013, con la siguiente pregunta: “¿aprueba usted el manuscrito de la
Guía SWEBOK V3.0 para avanzar al formato y la publicación”
Los resultados de esta votación había 259 Sí votos y 5 Sin votos.
La siguiente moción 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 Guía para
la Cesión de Software Ingeniería Cuerpo de Conocimiento Versión 3.0 se ha completado con
éxito; y hace suya la Guía de la Ingeniería de Software de Administración de Conocimiento
versión 3.0 y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su
aprobación.
La siguiente moción 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 versión 3.0 de
la Guía de la Ingeniería de Software de Administración de Conocimiento y autoriza al Presidente
de la Junta sionales Actividades Profe- para continuar con la impresión.
MOCIONES sobre la aprobación de

SWEBOK GUÍA 2004 VERSIÓN
La siguiente moción fue aprobada por unanimidad por el Consejo Asesor Industrial de la Guía SWEBOK
proyecto en febrero de 2004:
El Consejo Asesor Industrial encuentra que la ingeniería del cuerpo software de proyecto
Conocimiento ini- ciada en 1998 se ha completado con éxito; y hace suya la versión del 2004Guía de
la SWEBOK y lo recomienda a la Junta IEEE Computer Society de Gobernadores para su
aprobación.
La siguiente moción 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 edición de 2004
de la Guía de la Ingeniería de Software de Administración de Conocimiento y autoriza al
Presidente del Comité de Prácticas profesional para continuar con la impresión.
Tenga en cuenta también que la edición de la Guía de la Ingeniería de Software de Administración

de Conocimiento 2004 fue presentado por el IEEE Computer Society con la norma ISO / IEC sin
ningún cambio y fue reconocido como el informe técnico ISO / IEC TR 19759: 2005.
INTRODUCCIÓN A LA GUÍA
KA Área de conocimiento La Guía no debe confundirse con el Cuerpo de

Conocimiento mismo, que existe en la publicación
Software Cuerpo de Ingeniería
SWEBOK 1 Ver www.computer.org/sevocab.
del Conocimiento
Publicación de la versión de esta Guía a la

Ingeniería de Software de Administración de
Conocimiento (BOK SWE- 2004) 2004 fue un
hito importante en el establecimiento de la
ingeniería de software como una disciplina de
ingeniería reconocida. El objetivo en el
desarrollo de esta actualización para SWEBOK
es mejorar la moneda, la legibilidad,
consistencia y facilidad de uso de la Guía.
Todas las áreas de conocimiento (KAS) se han
actualizado para reflejar los cambios en la
ingeniería de software desde la publicación de
SWEBOK 2004. Cuatro nuevos dación Fun-
KAs y una Ingeniería de Software Prácticas
Profe- sional KA se han añadido. Las
herramientas de ingeniería de software y
métodos KA ha sido revisada como modelos y
métodos de ingeniería de software. herramientas
de ingeniería de software es ahora un tema en
cada una de la KAS. Tres apéndices proporcio-
nar las especificaciones para la descripción KA,
un conjunto anotada de normas pertinentes para
cada KA, y una lista de las referencias citadas en
la Guía. Esta guía, escrita bajo los auspicios de
la Junta de Actividades Profesionales de la
Sociedad IEEE Com- puter, representa un
siguiente paso en la evo-
ción de la profesión de la ingeniería de software.
Qué es la ingeniería de software?
ISO / IEC / IEEE Sistemas y de Ingeniería de

Software de vocabulario (SEVOCAB) define las
soluciones de inge- niería como “la aplicación
de una disci- plined, enfoque sistemático y
cuantificable al desarrollo, operación y
mantenimiento de software; es decir, la
aplicación de la ingeniería de software).”1
¿QUÉ SON LOS OBJETIVOS DE LA

GUÍA SWEBOK?
Guía xxx SWEBOK® V3.0 El primero de estos objetivos, una amplia
literatura. El propósito de la Guía es describir visión del mundo coherente de ingeniería de
la parte del cuerpo de conocimiento que es software, fue apoyada por un proceso de
generalmente aceptadas, para organizar esa desarrollo que dedica aproximadamente 150
parte, y para proporcionar acceso tópica a la los colaboradores de 33 países. Más información
misma. sobre el proceso de desarrollo se puede
La Guía para el swebok (Guía SWEBOK) se encontrar en la página web (www.swebok.org).
estableció con los cinco objetivos siguientes: fesionales y las sociedades adquiridas pro y los
organismos públicos involucradosse pusieron en
1. Para promover una visión coherente de la contacto en la ingeniería de software,
ingeniería 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 ingeniería de software con de revisión. tores KA edi- fueron reclutados de
respecto a otras disciplinas como la América del Norte, la cuenca del Pacífico, y
informática, la gestión del proyecto, Europa. Las presentaciones sobre el proyecto se
ingeniería informática y matemáticas hicieron en varios lugares internacionales.
3. Para caracterizar el contenido de la El segundo de los objetivos, el deseo de
disciplina de la ingeniería de software especificar el ámbito de la ingeniería de
4. Para proporcionar un acceso tópica en la software, moti- VATES la organización
Ingeniería de Software de Administración fundamental de la Guía. 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 certificación Tabla I.1. Cada uno de estos Kas es tratado en
individual y material de licencias un capítulo de esta Guía.
XXXI
Tabla I.1. El 15 SWEBOK KAs La organización jerárquica
Diseño de software La organización de los capítulos KA es
compatible con el tercero de los objetivos de una
Construcción de software caracterización del proyecto de los contenidos de
Pruebas de software la ingeniería de software. Las especificaciones
Mantenimiento del software detalladas proporcionadas por el equipo de
Gestión de la Configuración de Software redacción del proyecto para los editores
asociados en relación con los contenidos de las
Gestión de Ingeniería de Software descripciones KA se pueden encontrar en el
Proceso de Ingeniería de Software Apéndice A.
Modelos de Ingeniería de Software y Métodos La Guía se usa una organización jerárquica
Calidad del software para descomponer cada KA en un conjunto de
temas con etiquetas tificables daciones. Un
Ingeniería de Software Práctica Profesional desglose de nivel dos (a veces tres) proporciona
Economía Ingeniería de Software una forma razonable para buscar temas de
Fundamentos de computación interés. La guía trata los temas seleccionados de
Fundamentos matemáticos una manera compatible con las principales
escuelas de pensamiento y con las averías que se
Fundamentos de ingeniería encuentran generalmente en la industria y en la
literatura de ingeniería de software y estándares.
Al especificar el alcance, también es Las averías de los temas no presumen dominios
importante adoptar la definición de las particulares de aplicación, usos comerciales,
disciplinas que se cruzan con la ingeniería de filosofías de gestión, métodos de desarrollo, y
software. Con este fin, SWEBOK V3 también así sucesivamente. La extensión de la
reco- ognizes siete disciplinas relacionadas, que descripción de cada tema es sólo 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 guía puede hacer referencia a ellos). No es, referencia a sí mismos, no en la Guía.
sin embargo, un objetivo de la Guía SWEBOK
para caracterizar el conocimiento de las MATERIAL DE REFERENCIA Y MATRIZ
disciplinas relacionadas.
Para proporcionar acceso tópica en el
Tabla I.2. Disciplinas relacionadas conocimiento de la cuarta parte de los objetivos
del proyecto, la guía identifica material de
Ingeniería Informática
referencia autorizada para cada KA. Apéndice C
Ciencias de la Computación proporciona una lista de referencia consolidado
Administración General del Guía. Cada KA incluye referencias relevante
Matemáticas de la lista consolidada de referencia y también
incluye una matriz que relaciona el material de
Gestión de proyectos
referencia para los temas incluidos.
Gestión de la calidad Cabe señalar que la Guía no pretende ser
Ingeniería de Sistemas exhaustivo en sus citas. Mucho material que es a
la vez conveniente y excelente no se hace
Los elementos pertinentes de la informática y referencia. Material incluido en la lista de
las matemáticas se presentan en los referencias Consolidated proporciona cobertura
Fundamentos de Informática y Fundaciones KAs de los temas descritos.
matemáticos de la Guía (capítulos 13 y 14).
Profundidad del tratamiento
Guía
Para XXXII
lograrSWEBOK® V3.0
el quinto objetivopro-SWEBOK
Viding una base para el desarrollo curricular,
Introducción xxxiii
certificación y concesión de licencias, el criterio El desglose de los temas en cada KA consti-

de conocimiento generalmente aceptada se ha tuye el núcleo la descripción KA, que describen
aplicado, para distinguirse de un conocimiento la descomposición de la KA en subáreas, temas
avanzado y la investigación (sobre la base de la y subtemas. Para cada tema o subtema, se da una
madurez) y de conocimiento especializado (por breve descripción, junto con una o más
motivos de generalidad de la solicitud). referencias.
El término equivalente reconocido El material de referencia fue elegido porque se
generalmente proviene del Instituto de Gestión considera que constituye la mejor presentación
de Proyectos: “Generalmente reconocido de los conocimientos en relación con el tema.
significa el conocimiento y las prácticas Una matriz vincula los temas que el material de
descritas son aplicables a la mayoría de los referencia.
proyectos, la mayor parte del tiempo, y no hay La última parte de la descripción de cada KA
consenso sobre su valor y utilidad.” 2 es la lista de referencias recomendadas y
Sin embargo, los términos “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 Apéndice B de la Guía.
aplicarse de manera uniforme a todos los
esfuerzos de ingeniería de software, cada una de APÉNDICE A. KA Descripción
las necesidades proyecto determinan que-pero Especificaciones
sí implica que, ingenieros de software capaces
competentes deberían estar equipados con este Apéndice A describe las especificaciones
conocimiento para su aplicación potencial. Más 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 ingeniería de licencias de software recomendado.
exami- nación que los graduados tomarían
después de ganar cuatro años de experiencia APÉNDICE B. ASIGNACIÓN DE
laboral. Aunque este criterio es específico para Normaliza- ción A KAS
el estilo de los EEUU de la educación y no
necesariamente se aplica a otros países, Apéndice 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 Guía
ESTRUCTURA DE LAS DESCRIPCIONES SWEBOK.
KA
LISTA DE REFERENCIA APÉNDICE C.
Las descripciones KA se estructuran como sigue. CONSOLIDADO
En la introducción, se presentan una breve
definición de la KA y una visión general de su Apéndice C contiene la lista consolidada de las
alcance y de su nave PARENTESCO con otros referencias citadas en recomienda la KAS
KAs. (estas referencias están marcados con un
asterisco (*) en el texto).
2 Una guía para la Dirección de Proyectos del
Conocimiento, 5 ed, el Project Management
Institute, 2013.; www.pmi.org.
REQUISITOS
CAPÍTULO 1 SOFTWARE
SIGLAS , No implica, sin embargo, que un ingeniero de

software no pudo realizar la función.
Confidencialidad, integridad y Un riesgo inherente en la descomposición
CIA
Disponibilidad propuesta es que un proceso de cascada-como
TROZO Gráfico Acíclico Dirigido puede deducirse. Para evitar esto, el tema 2, los
DE
FSM Funcional de la medida del requisitos del proceso, está diseñado para
CUERO proporcionar una visión 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 actúan para configurarlo.
Una descomposición alternativa podría utilizar
una estructura a base de producto (requisitos
INTRODUCCIÓN del sistema, los requisitos de software,
prototipos, casos de uso, y así sucesivamente).
El área de conocimiento Requisitos de software La composición basada en el proceso refleja el
(KA) se ocupa de la obtención, análisis, speci- hecho de que el proceso de requisitos, si ha de
ficación, y la validación de los requisitos de tener éxito, debe ser considerada como un
software, así como la gestión 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 simultáneas), 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 críticamente proyecto de desarrollo de software.
vulnerables cuando están mal realizan las Los requisitos de software KA se relaciona
actividades relacionadas REQUISITOS. estrechamente con el diseño de software,
Requisitos de software expresan las pruebas de software, mantenimiento de software,
necesidades y limitaciones impuestas a un Software Configuration Management, Gestión
producto de software que contribuyen a la de Ingeniería de Software, Software de
solución de algunos problemas del mundo real. Ingeniería de Procesos, Ingeniería de Software y
La “ingeniería de requisitos” plazo es Modelos Métodos y Calidad de Software de Kas.
ampliamente utilizado en el campo para indicar
la manipulación sistemática de requisitos. Por DISTRIBUCIÓN DE TEMAS PARA
razones de coherencia, el término “ingeniería” REQUISITOS DEL SOFTWARE
no se utiliza en este KA excepto para la
ingeniería de software en sí. El desglose de los temas de los requisitos de
Por la misma razón, “ingeniero de requisitos”, software KA se muestra en la Figura 1.1.
un término que aparece en la parte de la
literatura, no se utilizará tampoco. En cambio, el 1. Requisitos de software Fundamentos
término “ingeniero de software” o, en algunos [1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6,
casos específicos, “los requisitos especialista” se c12]
utilizará, este último donde el papel en cuestión
se realiza generalmente por una persona que no 1.1. Definición de un requisito de software
sea un ingeniero de software. Esta
En su forma más básica, un requisito de por algo en
software es una propiedad que debe ser exhibido
1-1
1-2 Guía SWEBOK® V3.0
Figura 1.1. Desglose de temas para el KA Requisitos de software
Para resolver algún 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- ción, para corregir defectos de Requisitos tienen otros atributos en adi- ción a
software existente, o para controlar un nombre las propiedades de comportamiento. Los
de dispositivo a sólo algunos de los muchos ejemplos más comunes incluyen una
problemas para los que son posibles soluciones clasificación de prioridad para permitir
de software . Las formas en que los usuarios, compensaciones en la cara de los recursos finitos
procesos de negocio, y dispositivos de función y un valor de estado para permitir el avance del
suelen ser complejas. Por extensión, por lo tanto, proyecto a vigilar. Tıpicamente, los requisitos de
los requisitos de software de particular son software son singularmente identificadas con los
típicamente una compleja combinación de varias de modo que puedan ser objeto de software de
personas en diferentes niveles de una gestión de con- figuración durante todo el ciclo
organización, y que están en una u otra manera de vida de la entidad y del software.
involucrados o relacionados con esta función 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
característica individual como requisito restricción en el software que se desarrollarán
funcional o a nivel del sistema como un (por ejemplo, “El software verificará que un
requisito no funcional. Puede ser difícil 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 verificación del requisito curso”). Un requisito proceso es esencialmente
de caudal en un centro de llamadas puede hacer un constraint en el desarrollo del software (por
necesario el desarrollo de software de ejemplo, “El software se desarrolla utilizando
simulación. Requisitos de software, ING un proceso RUP”).
Ensayos software y personal de calidad debe Algunos de los requisitos de software generan
asegurar que el implícita
los requisitos del proceso. La elección de la Requisitos de software 1-3
verificación
técnica es un ejemplo. Otro podría ser el uso de y, en su caso, cuantitativamente. Es importante

técnicas de análisis particularmente rigurosas evitar los requisitos de vagas y no verificables que
(tales como los métodos de especificación
formal) para reducir los fallos que pueden
conducir a insuficiente fiabilidad. requisitos pro-
ceso También pueden imponerse directamente
por la organización 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 algún texto o la modulación de una señal.
A veces se conocen como capacidades o
características. Un requisito funcional también
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 actúan
para limitar la solución. Los requisitos no
funcionales son a veces conocidos como las
restricciones o requisitos de calidad. Pueden ser
más 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- terísticas 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 cómo
interactúen todos los componentes de software.
El requisito de caudal para un centro de
llamadas, por ejemplo, dependerá de cómo el
sistema telefónico, sistema de información, y los
operadores de todos interactuaron en
condiciones reales de explota- ción. Las
propiedades emergentes dependen
fundamentalmente de la arquitectura del sistema.
1.5. Requisitos cuantificables
Requisitos de software deben expresarse tan

claramente y sin ambigüedad como sea posible,
software. Requisitos de software 1-5
dependen para su interpretación en un juicio
subjetivo ( “el software será fiable”, “el
software debe ser fácil 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 operación
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 combinación de interacción de

elementos para llevar a cabo un objetivo
definido. Estos incluyen elementos de
hardware, software, firmware, personas,
información, técnicas, instalaciones,
servicios y otros apoyos,
como se define por el Consejo Internacional de

Soft- ware y Ingeniería 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 sistema 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 reglamentación mentos),
y los requisitos sin una fuente humana
identificable.
2. requisitos Proceso
[1 *, c4s4] [2 *, C1-4, c6, c22,
c23]
En esta sección se presenta el proceso de

requisitos de software, la orientación de los
cinco temas restantes y mostrando cómo el
proceso se ajusta perfectamente a los requisitos
del proceso general de la ingeniería de
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 software, sino más bien un lo
proceso iniciado en el comienzo de un
proyecto que continúa para ser refinado
durante todo el ciclo de vida;
• identifica los requisitos de software como
elementos de configuración y los gestiona
utilizando las mismas prácticas de gestión
de configuración de software como otros
productos de los procesos del ciclo de vida
del software;
• necesita ser adaptado al contexto de la
organización y del proyecto.
En particular, el tema tiene que ver con cómo

se configuran las actividades de obtención,
análisis, especifica- ción y validación para
diferentes tipos de proyectos y limitaciones. El
tema también incluye actividades que
proporcionan la entrada en el proceso de
requisitos, tales como la comercialización 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 proceso es fundamentalmente
interdisciplinario, y el especialista requisitos
necesita para mediar entre el dominio de la parte
interesada y la de ingeniería de software. A
menudo hay muchas personas involucradas,
además del especialista requisitos, cada uno de
los cuales tiene una participación en el
programa. Los titulares stake- variarán según los
proyectos, pero siempre incluirán los usuarios /
operadores y clientes (que no tiene por qué ser el
mismo).
Ejemplos típicos de grupos de interés de
software
incluir (pero no se limitan a) los siguientes:
• Usuarios: Este grupo comprende aquellos

que operará el software. A menudo es un
grupo heterogéneo 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 establecer las propósito es hacer hincapié en el papel clave que
necesidades del mercado y para actuar desempeña el proceso de requerimientos en
como clientes de proxy. términos de la
• Reguladores: Muchos dominios de
aplicación, como la banca y el transporte
público, 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 interés legítimo en
sacar provecho de desa- oping el software,
por ejemplo, la reutilización de
componentes o de otros productos. Si, en
este escenario, un cliente de un producto
particular tiene requisitos específicos que
comprometen la posibilidad de
reutilización de componentes, los
ingenieros de software deben sopesar
cuidadosamente su propio juego contra los
del cliente. Los requisitos específicos, las
limitaciones particularmente, 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 interés y dentro
de las limitaciones presupuestarias, técnicas,
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. Administración y Apoyo Proceso
Esta sección presenta los recursos de gestión

de proyectos requeridos y consumidos por el
proceso de los requisitos. Se establece el
contexto para el primer tema (Iniciación y
Definición del Alcance) del Software
Engineering Management KA. Su objetivo
principal es hacer que el vínculo entre las
actividades proceso identificados en 2.1 y los
problemas de costo, recursos humanos,
capacitación y herramientas.
2.4. Proceso de Calidad y Mejora
En este tema se refiere a la evaluación de la

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

y de la satisfacción del cliente con él. Esto ingenieros de software.
ayudará a orientar el proceso de requisitos de Un elemento crítico de la obtención de
calidad con Dardos Están- y modelos de mejora requisitos está informando al alcance del
de procesos para las mercancías y los sistemas proyecto. Esto implica proporcionando una
blandas. La calidad del proceso y la mejora está descripción del software que se especifica y su
estrechamente relacionado tanto a la calidad del propósito y dar prioridad a los entregables
software y KA KA Proceso de Ingeniería de
Software, que comprende
• la cobertura proceso de requisitos de

proceso
normas y modelos de mejora;
• requirementsprocessmeasuresand
la evaluación comparativa;
• planificación de la mejora e
implementación;
• seguridad / CIAimprovement / planningand
implementación.
3. la obtención de requisitos
[1 *, c4s5] [2 *, c5, c6,
c9]
La obtención de requisitos tiene que ver con los

orígenes de los requisitos de software y cómo el
ingeniero de software puede recogerlos. Es la
primera etapa en la construcción de una
comprensión 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 “adquisición
requisitos”.
Uno de los principios fundamentales de un
buen proceso de obtención requisitos es el de la
comunicación tivo effec- entre los distintos
titulares stake-. Esta comunicación continúa 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
comunicación. Deben Medi comieron entre el
dominio de los usuarios de software (y otras
partes interesadas) y el mundo de la técnica del
ingeniero de software. Un conjunto de modelos
internamente consistentes en diferentes niveles
de abstracción facilitar las comunicaciones entre
Requisitos de software
políticas de la organización 1-9
al cliente
para garantizar las necesidades de negocios
más 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 descripción 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 métodos recursivos.
3.1. requisitos Fuentes
Requisitos tienen muchas fuentes en cerámica

típica blandas, y es esencial que se identifican
y evalúan todas las fuentes potenciales. Este
tema está diseñado para promover el
conocimiento de las diversas fuentes de
requisitos de software y de los marcos para la
gestión de los mismos. Los principales puntos
cubiertos son los siguientes:
• Metas. El término “objetivo” (a veces

llamada “empresa comercial” o “crítico de
éxito factor”) se refiere a los objetivos
generales, de alto nivel de software.
Objetivos proporcionan la motiva- ción
para el software, pero a menudo son muy
vago. Los ingenieros de software deben
prestar especial atención a la evaluación
del valor (en relación 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 aplicación. conocimiento del
dominio proporciona el contexto en el que
todo el conocimiento requisitos provocada
debe ajustarse con el fin de entenderlo.Es
una buena práctica para emular un enfoque
ontológico en el dominio del
conocimiento. relaciones entre los
conceptos relevantes dentro del dominio
de aplicación deben ser identificados.
• Las partes interesadas (véase la sección
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 demás. Por lo tanto, el
software entregado es difícil de usar, o
subvierte las estructuras culturales o
los “puntos de vista” de muchos tipos incluso si las cooperativas interesadas y

diferentes de articulados están disponibles, el ingeniero de
grupos de interés. software tiene que trabajar duro para obtener la
• Reglas del negocio. Estas son declaraciones información correcta. Muchos de los requisitos de
que definen o limitan algún aspecto de la negocio o técnicas son tácito o en la
estructura o el comportamiento de la retroalimentación que
propia empresa. “Un estudiante no puede
inscribirse en los cursos del próximo
semestre si quedan algunos derechos de
matrícula no pagados” sería un ejemplo de
una regla de negocio que sería una fuente
requisito para el software del curso-registro
de una universidad.
• 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 diseño.
• El entorno de la organización. El software
se requiere a menudo para apoyar un pro-
ceso de negocios, la selección de los cuales
puede ser condicionado por la estructura, la
cultura y la política interna de la
organización. 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. técnicas de obtención
Una vez que las fuentes de requisitos se han

identificado, el ingeniero de software puede
iniciar la obtención de información de los
requisitos de los mismos. Tenga en cuenta que
los requisitos rara vez se suscitó confeccionada.
Más bien, el ingeniero de software obtiene
información de la que él o ella formula
requisitos. Este tema se centra en técnicas para
conseguir los interesados humanos para articular
la información relevante REQUISITOS. Es una
tarea muy difícil 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-
mación importante no declarada, o pueden ser
dispuestos o no pueden cooperar. Es
particularmente importante entender que la
provocación no es una actividad pasiva y que,
Requisitos de software
superficie utilizando entrevistas. Otra 1-11
aún no se ha obtenido a partir de los usuarios
finales. La importancia de la planificación, ventaja es que los requisitos conflictivos
verificación y validación en la obtención de superficie desde el principio en una forma
requisitos no puede ser exagerada. Existe un que permite a las partes interesadas
número de técnicas para los requisitos de elici- reconocen cuando éstos se producen.
tación; las principales son las siguientes: Cuando funciona bien, esta técnica
• 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 ción 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é pasaría si” y “cómo se hace”
preguntas que se le pregunte. El tipo más
común de escenario es la descripción 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 técnica 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
información que necesitan para ofrecer.
Hay una amplia gama de técnicas-de
prototipado ups papel maqueta de diseños
de pantalla a las versiones de las pruebas
beta de productos de software y un fuerte
solapamiento de sus usos separados para
requisitos elicita- ción y para la validación
de los requisitos (véase la sección 6.2,
Prototyping) . Baja fidelidad prototipos se
prefieren a menudo para evitar que las
partes interesadas “anclaje” en la carac-
terísticas de menor importancia, incidental
de un prototipo de mayor calidad que
puede limitar la flexibilidad de diseño de
formas no deseadas.
• reuniones facilitadas. El propósito de estas
reuniones es tratar de lograr un efecto
acumulativo, por el que un grupo de
personas puede traer más información
sobre sus exigencias de software que
trabajando individualmente. Pueden
intercambiar ideas y refinar las ideas que
pueden ser difíciles de llevar a la
puede resultar en un conjunto más rico y determinar si se han cumplido los objetivos de
más coherente de los requisitos que de otro la historia de usuario.
modo podrían ser alcanzables. Sin embargo, • Otras técnicas. Una variedad de otras técnicas
las reuniones deben ser manejados con para el apoyo a la obtención de información de
cuidado (de ahí la necesidad de un los requisitos existen y van desde el análisis de
facilitador) para evitar una situación en la productos de la competencia para aplicar los
que las habilidades críticas del equipo son datos min-ing técnicas 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 petición del cliente.
preocupaciones de unos pocos pelos en la
lengua (y quizás de alto nivel) las personas
que se ven favorecidas en detrimento de
otros.
• Observación. La importancia del contexto
de software dentro de la ment ENTORNO
organización ha llevado a la adaptación de
las técnicas observacionales tales como la
etnografía para la obtención de requisitos.
Los ingenieros de software aprenden acerca
de las tareas del usuario mediante la
inmersión de sí mismos en el medio
ambiente y la observación de cómo los
usuarios realizan sus tareas mediante la
interacción con los demás y con
herramientas de software y otros recursos.
Estas técnicas son relativamente caros, sino
también instructiva porque ilustran que
muchas tareas de usuario y procesos de
negocio son demasiado sutil y complejo por
sus actores para describir fácilmente.
• Historias de usuarios. Esta técnica se utiliza
comúnmente en los métodos de adaptación
(ver Métodos ágiles en los modelos de
ingeniería de software y Métodos Ka) y se
refiere a las descripciones de nivel cortos,
de alta de funcionalidad requerida expresada
en términos de los clientes. Una historia de
usuario típico tiene la siguiente forma:
“Como <función>, quiero
<Meta / deseo> de manera que
<beneficiar> “. Una historia de usuario está
destinado a contener suficiente informa-
ción para que los desarrolladores pueden
producir una estimación 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
utilizarán 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- tación adecuada
debe ser escrita por el al cliente central para
Requisitos de software 1-13
4. Análisis 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 límites del software y
cómo debe interactuar con su entorno
organizacional y operativa;
• requisitos del sistema elaborados para
derivar los requisitos de software.
La visión tradicional de análisis de

requisitos ha sido que ser reducido a ing
modelo- conceptual usando uno de una serie
de métodos de análisis, tales como el método
de análisis estructurado. Si bien el modelado
conceptual es importante, incluimos la
clasificación de los requisitos para ayudar a
informar a soluciones de compromiso entre
los requisitos (clasificación requisitos) y el
proceso de creación de estas compensaciones
(requisitos de negociación).
Se debe tener cuidado para describir los
requisitos de forma suficientemente precisa
para permitir que los requisitos para ser
validados, su aplicación a ser verificada, y
sus costes a estimar.
4.1. requisitos Clasificación
Los requisitos pueden ser clasificadas en

varias dimensiones. Ejemplos incluyen los
siguientes:
• Si el requisito es funcional o no
funcional (ver sección 1.3, funcional y
requerimientos no funcionales).
• Si el requisito se deriva de uno o más
requisitos de alto nivel o una propiedad
de gent gencia (véase la sección 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 sección 1.2, producto y
requisitos del proceso). Requisitos en el
proceso pueden limitar la elección de
Tor contracción, el proceso de
ingeniería de software para ser
adoptado, o las normas que deben ser
respetados.
• La prioridad requisito. Cuanto mayor sea la sección 7.3, Requisitos de atributos).

prioridad, más 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
implementación.
• El alcance de la prescripción. Ámbito de
aplicación 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 satisfacción 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
diseño de muchos componentes, mientras
que uno con un alcance limitado puede
ofrecer una serie de opciones de diseño y
tienen poco impacto en la satisfacción de
otras necesidades.
• Volatilidad / estabilidad. Algunos de los
requisitos cambiarán durante el ciclo de
vida de la Cesión de Software, e incluso
durante el propio proceso de desarrollo. Es
útil si alguna estimación de la probabilidad
de que va a cambiar un requisito se puede
hacer. Por ejemplo, en una aplicación de
ING banco-, los requisitos para las
funciones para el cálculo y el interés de
crédito a las cuentas de los clientes tienden
a ser más estable que un requisito para
apoyar un tipo particular de cuenta libre de
impuestos. El primero refleja una
característica fundamental del dominio
bancario (cuentas que pueden ganar
intereses), mientras que los segundos
pueden dejarlo obsoleto por un cambio a la
legislación gubernamental. Marcar
requisitos potencialmente volátiles puede
ayudar al ingeniero de software de
establecer un diseño que es más hormiga
tolerar de cambio.
Otras clasificaciones pueden ser apropiadas,

dependiendo de Tice prác- normal de la
organización y la propia aplicación.
Hay una fuerte superposición entre atributos
requisitos de clasificación y requisitos (ver
4.2. Modelado conceptual comenzar la construcción deRequisitos de software
un modelo del 1-15
contexto del software. El contexto software
El desarrollo de modelos de un problema del proporciona una conexión entre los programas
mundo real es clave para el análi- sis requisitos informáticos destinados y su entorno externo.
de software. Su propósito es ayudar a
comprender la situación en la que se produce el
problema, así como que representa una
solución. 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
Ingeniería de Software y Métodos 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 límite 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 elección de la
notación 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 paramétricos, que son parte de
SysML [4], es probable que sean tant más
impor- por software en tiempo real que
para los sistemas informa- ción, al tiempo
que normalmente sería el opuesto para
modelos de objetos y de la actividad.
• La experiencia del ingeniero de software.
A menudo es más productivo para adoptar
una notación de modelado o método con el
que el ingeniero de software con
experiencia.
• Los requisitos del proceso del cliente (ver
sección 1.2, el producto y los
requerimientos del proceso). Los clientes
pueden imponer su notación o método
favorecido o prohibir cualquier con las que
están familiarizados. Este factor puede
entrar en conflicto con el factor anterior.
Nota que, en casi todos los casos, es útil

Esto es crucial para la comprensión 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 diseño arquitectónico está estrechamente
el medio ambiente. identificada con el modelado conceptual (ver
Este subtema no busca “enseñar” a un estilo sección 4.2, conceptual
de modelado particular o anotación, sino más Modelado).
bien proporciona orientación sobre el propósito
e intención de modelado.
4.3. Diseño y requisitos arquitectónicos

Asignación
En algún momento, la arquitectura de la

solución debe ser derivado. El diseño
arquitectónico es el punto en el que el proceso se
superpone con los requisitos de software o
sistemas de diseño 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 diseño de
software KA. En muchos casos, el ingeniero de
software actúa como arquitecto de software
debido a que el proceso de análisis y elaboración
de los requisitos que exige ser identificados los
componentes / diseño de arquitectura que se
encargarán de satisfacer los requisitos. Esta es la
asignación de-la requisitos de asignación a
componentes de la arquitectura responsable
para satisfacer los requisitos.
La asignación 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 aún
más para descubrir nuevos requisitos sobre cómo
el componente tiene que interactuar con otros
componentes con el fin de satisfacer el requisito
asignado mentos. En grandes proyectos, la
asignación estimula una nueva ronda de análisis
para cada subsistema. Como ejemplo, los
requisitos para un rendimiento determinado de
frenado para un coche (distancia de frenado, la
seguridad en condiciones de conducción pobres,
suavidad de apli- cación, la presión del pedal
necesarios, y así sucesivamente) puede ser
asignada al hardware de frenado (conjuntos
mecánicos e hidráulicos) y un sistema de frenado
antibloqueo (ABS). Sólo 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-
4.4. requisitos de Negociación
Otro término comúnmente utilizado para este

subtema es “resolución de conflictos”. Esto se
refiere resolv- ing problemas con los requisitos
donde los conflictos se producen entre dos
actores que requieren mutu- características
aliado incompatibles, entre las necesidades y
los recursos, o entre los requisitos funcionales
y no funcionales, por ejemplo, . En la mayoría
de los casos, no es aconsejable para el
ingeniero de software para hacer una decisión
unilateral, lo que se hace preciso proceder a
consultar con la parte interesada (s) para llegar
a un consenso sobre una compensación
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 análisis de
requisitos de software debido a problemas
surgen como el resultado del análisis. Sin
embargo, un fuerte caso también se puede
hacer por considerarlo un tema de validación
de requisitos (ver tema 6, los requisitos de
validación).
Requisitos priorización es necesario, no sólo
como un medio para filtrar los requisitos
importantes, sino también 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
estimación. Sin embargo, a menudo es difícil
obtener información real que puede actuar
como base para este tipo de decisiones.
Además, los requisitos a menudo dependen
unos de otros, y prioridades son relativos. En la
práctica, los ingenieros de software realizan
requisitos priorización con frecuencia sin
necesidad de conocer todos los requisitos.
Requisitos priorización puede seguir un
enfoque de valor de costo que implica un
análisis de las partes interesadas en una escala
que definen los beneficios o el valor agregado
que el ción ¡Ejecución del requisito les lleva,
en comparación con las penas de no haber
implementado un requisito particular. También
implica un análisis de los ingenieros de
software de estimación en una escala el costo
de la implementación de cada requisito, en
relación con otros requisitos. Otro enfoque
oritization pri- requisitos llama el proceso
analítico jerárquico implica comparar todos los
pares únicos de los requisitos para determinar
cuál de los dos es de mayor prioridad, y en qué
medida.
4.5. Análisis formal

Para la mayoría de las carreras de ingeniería, el
preocupaciones formales de análisis no sólo el término “memoria descriptiva” se refiere a la
tema 4, sino también las secciones 5.3 y 6.3. En asignación de valores numéricos o los límites a
este tema también se relaciona con métodos los objetivos de diseño de un producto. En la
formales en los modelos de ingeniería de ingeniería de software, “especificación de
software y métodos Área de Conocimiento. requisitos de software” típicamente se refiere a la
Análisis formal ha hecho un impacto en producción de
algunos dominios de aplicación, en particular los
de los sistemas de alta integridad. La expresión
formal de requisitos requiere una lengua con la
semántica formalmente definidos. El uso de un
análisis formal para la expresión requisitos tiene
dos ventajas. En primer lugar, permite a los
requisitos expresados en el idioma que se
especifique con precisión y forma ambigua, por
lo tanto (en principio) para evitar la posibilidad
de una mala interpretación. 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 aplicación más amplia
de análisis formal.
El análisis más formal, se centra en etapas
relativamente tardías de análisis de requisitos. Es
generalmente contraproducente para solicitar la
formalización hasta que los objetivos de negocio
y necesidades de los usuarios han entrado en un
enfoque nítido a través de medios tales como los
descritos en otras partes de la sección 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 críticos. Esto permite la validación
estática que el software especificado por los
requisitos sí tiene las propiedades (por
ejemplo, ausencia de estancamiento) que el
cliente, los usuarios, y el ingeniero de software
de esperar que tenga.
5. Especificación de requisitos
[1 *, c4s2, c4s3, c12s2-5] [2 *,
c10]
un documento que pueda ser revisado de forma
sistemática, evaluada y aprobada. Para
sistemas complejos, especialmente aquellos
que involucran componentes mercancías
nonsoft- sustanciales, como se producen hasta
tres diferentes tipos de documentos: sistema de
defini- ción, requisitos del sistema y los
requisitos de software. Para los productos de
software simple, sólo se requiere el tercero de
estos. Los tres documentos se describen aquí,
con el entendimiento de que se pueden
combinar según sea apropiado. Una
descripción de la ingeniería de sistemas se
puede encontrar en las disciplinas de Ingeniería
de Software capítulo de esta guía relacionadas.
5.1. Definición 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 número de lectores
incluye representantes de los usuarios del
sistema / clientes (marketing puede
desempeñar estas funciones para el software
impulsado de mercado), por lo que su
contenido debe ser expresada en términos de
dominio. El documento enumera los requisitos
del sistema, junto con la información de fondo
sobre los objetivos globales para el sistema, su
entorno de destino, y una declaración de las
limitaciones, supuestos y requisitos no
funcionales. Puede incluir modelos
conceptuales diseñados 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 Especificación
Los desarrolladores de sistemas con software

sustancial y componentes de un forro de aire
moderno nonsoftware, por ejemplo, a menudo
se separan de la descripción de los requisitos
del sistema de la descripción 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 continuación los requisitos para el
software componentes se especifican. En
sentido estricto, la especificación de los
requisitos del sistema es un sistema de
Engineer- ing actividad y queda fuera del
alcance de esta guía.
5.3. Especificación de Requerimientos de software individuales son imperativos, directivas,

Software frases débiles, opciones y ANCES continuidades.
Indicadores para todo el documento de
especificación de requisitos de software especificación de software exigencias incluyen el
establece la base para un acuerdo entre los tamaño, la capacidad de lectura, la especificación,
clientes y los contratistas o proveedores (en la profundidad y la estructura del texto.
proyectos 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.
especificación de requisitos de software
permite una evaluación rigurosa de los requisitos
de diseño antes de comenzar y se reduce el
rediseño más tarde. También debe proporcionar
una base realista para ing realizan estimaciones
los costos del producto, riesgos y horarios.
Las organizaciones también pueden utilizar un
documento de especificación de los requisitos de
software de base para la elaboración de planes
eficaces de verificación y validación.
especificación 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 especificación de
requisitos de software, esto puede
complementarse con formal o descripciones
semiformales. La selección de las anotaciones
apropiadas permite particulares los requisitos y
aspectos de la arquitectura de software que se
describirán con mayor precisión y concisión 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 críticos para la seguridad,
regulación, y ciertos otros tipos de software
fiable. Sin embargo, la elección de la notación a
menudo se cuela por la con- formación,
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 especificación a otras variables del
proyecto, tales como el coste, la aceptación,
Formance per-, programar y reproducibilidad.
Los indicadores de calidad para las
declaraciones de especificación de requisitos de
1-12 Guía SWEBOK® V3.0 orientación sobre lo que debe buscar en la forma
6. requisitos de Validación
[1 *, c4s6] [2 *, c13, de listas de verificación.
c15]
Los documentos de los requisitos pueden estar

sujetos a procedimientos de Val- idation y
verificación. Los requisitos pueden ser
validados para asegurar que el ingeniero de
software ha entendido los requisitos; También
es importante verificar que se ajusta a los
requisitos de document estándares de la
compañía y que es comprensible, coherente y
completa. En los casos en los estándares de la
compañía documentados o terminología sean
incompatibles con las normas generalmente
aceptadas, una asignación 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
están sujetos a las mismas prácticas de gestión
de configuración como las demás prestaciones
de los procesos del ciclo de vida del software.
Cuando sea posible, los requisitos individuales
también están sujetos a la gestión de
configuración, generalmente con una
herramienta de gestión de requisitos (véase el
tema 8, requisitos de software Herramientas).
Es normal para programar explícitamente
uno o más 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 dación 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 críticas
Tal vez la forma más común de la validación

se realiza mediante inspección o revisión del
documento (s) requisitos. Un grupo de
revisores se le asigna un breve para buscar
errores, suposiciones erróneas, falta de
claridad, y la desviación de Tice prác-
estándar. La composición del grupo que lleva a
cabo la revisión 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
Los comentarios pueden ser constituidos en la análisis. Por ejem plos, en modelos de objetos, es
finalización del documento de definición del útil para llevar a cabo un análisis estático para
sistema, el documento de especificación del verificar la existencia de rutas de comunicación
sistema, el documento de especificación de entre los objetos que, en las partes interesadas
requisitos de software, la especificación de línea
de base para un nuevo lanzamiento, o en
cualquier otro paso en el proceso.
6.2. prototipado
Prototipos es comúnmente un medio para validar

la interpretación que el ingeniero de software de
los requisitos de software, así como para la
obtención de nuevos requisitos. Al igual que con
la elicitación, hay una gama de técnicas de
prototipado y un número de puntos en el proceso
donde la validación prototipo puede ser
apropiado. La ventaja de prototipos es que
pueden hacer que sea más fácil interpretar los
supuestos del ingeniero de software y, si es
necesario, dar información útil acerca de por qué
están equivocados. Por ejemplo, el
comportamiento dinámico de un usuario
interfase se puede entender mejor a través de un
ani- acoplado prototipo que a través de
descripción textual o modelos gráficos. La
volatilidad de un requisito que se define después
de la creación 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 creación de prototipos
características cruciales de seguridad crítica y
sería una gran ayuda. También hay desventajas,
sin embargo. Estos incluyen el peligro de la
atención de los usuarios distraerse del núcleo
funcionalidad subyacente por cuestiones
cosméticas o problemas de calidad con el
prototipo. Por esta razón, 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 erróneos, su
coste se puede justificar más fácilmente.
prototipos tempranos pueden contener aspectos
de la solución final. Los prototipos pueden ser
evolutiva en lugar de usar y tirar.
6.3. Modelo de validación
Por lo general es necesario para validar la

calidad de los modelos desarrollados durante el
1-14 Guía SWEBOK® V3.0 su producto comienza a evolucionar, descubren
dominio, el intercambio de datos. Si se utiliza
el análisis formal notación ciones, es posible que necesitan para recuperar los requisitos que
utilizar ing razonable formal para probar las
propiedades de especificación. Este tema está
estrechamente relacionado con las els
Ingeniería de Software y Métodos 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 sólo son
“deseos.” Por tanto, una tarea importante es la
planificación de cómo ver- ify cada requisito.
En la mayoría de los casos, el diseño de las
pruebas de aceptación hace esto por cómo los
usuarios finales normalmente, un
comportamiento camente negocio utilizando el
sistema.
Identificación y diseño de pruebas de
aceptación puede ser difícil para los requisitos
no funcionales (véase la sección 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.
Información adicional se puede encontrar en
la acep- tación / Calificación / pruebas de
conformidad en el Testing de Software KA.
7. Consideraciones prácticas
[1 *, c4s1, c4s4, c4s6,
c4s7] [2 *, c3, c12, c14,
c16, c18-21]
El primer nivel de descomposición tema pre-

tantes en este KA puede parecer para describir
una secuencia lineal de actividades. Esta es una
visión simplificada del proceso.
El proceso de requisitos abarca todo el ciclo
de vida del software. La gestión del cambio y
el mantenimiento de los requisitos en un estado
que refleja con precisión el software que se
construirán, o que se ha construido, son la
clave para el éxito del proceso de ingeniería de
software.
No todas las organizaciones tienen una
cultura de requisitos y gestión de docu-
Menting. Es mon comen empresas de nueva
creación dinámica, impulsada por un fuerte
“visión de producto” y los recursos limitados,
para ver la documentación de requisitos como
una sobrecarga innecesaria. Muy a menudo, sin
embargo, ya que estas empresas se expanden,
a medida que crece su base de clientes, y como
producto motivado cuenta con el fin de evaluar con el diseño y la construcción de la iteración
el impacto de los cambios propuestos. Por lo actual. Este enfoque proporciona ERS adaptado
tanto, la documentación y los requisitos de para el cliente con el valor de negocio de forma
gestión del cambio son la clave para el éxito de rápida, 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 comprensión
Requisitos continúa evolucionando a medida que el diseño y
el desarrollo
Existe una presión general en el software de
industria de los ciclos de desarrollo cada vez
más cortos, y esto es particularmente
pronunciado en sectores altamente competitivos,
impulsados por el mercado. Por otra parte, la
mayoría 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
práctica, por lo tanto, casi siempre es práctico
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 interés, bases forrado, asignado y
entregado al equipo de desarrollo de software.
Sin duda, es un mito que los requisitos para
grandes proyectos de software están 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
diseño 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 ingeniería software. Sin
embargo, los ingenieros de software están
necesariamente limitados por los planes de
gestión 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
explícitas 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 línea de base sólo a los
requisitos necesarios para la iteración actual. El
especialista requisitos puede seguir
desarrollándose requisitos para futuras
iteraciones, mientras res desarrollos proceder
1-16 Guía SWEBOK® V3.0 ware en fase de desarrollo o mantenimiento
producto. Esto a menudo conduce a la revisión
de los requisitos finales del ciclo de vida. Tal evoluciona. Esto debe incluir los diversos
vez el punto más crucial en la comprensión de clasificación
los requisitos de software es que una
proporción significativa de los requisitos
cambiará. Esto es a veces debido a errores en el
análisis, 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 regulación 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 revisión definido y tasa de aprobación pro
y mediante la aplicación de los requisitos
cuidadosos trac- ción, análisis de impacto, y la
gestión de configuración de software (ver el
KA Software Configuration Management). Por
lo tanto, los requisitos de proceso no es sólo
una tarea para el usuario en el desarrollo de
software, pero se extiende por todo el ciclo de
vida del software. En un proyecto típico, el
software requisito actividades mentos
evolucionan con el tiempo de obtención de la
gestión del cambio. Una combinación de arriba
hacia abajo métodos de análisis y diseño y de
abajo hacia arriba y métodos de
implementación de refactorización que se
reúnen en el medio podría proporcionar lo
mejor de ambos mundos. Sin embargo, esto es
difícil de lograr en la práctica, ya que depende
en gran medida de la madurez y la experiencia
de los ingenieros de software.
7.2. Gestión del cambio
La gestión del cambio es fundamental para la

gestión de requisitos. En este tema se describe
el papel de la gestión del cambio, los
procedimientos que deben estar en su lugar, y
el análisis que se debe aplicar a los cambios
propuestos. Tiene fuertes vínculos con la
Cesión de Software Gestión de la
Configuración KA.
7.3. requisitos Atributos
Los requisitos deben consistir no sólo en un

ficación speci- de lo que se requiere, sino
también de información auxiliar, lo que ayuda
a manejar e interpretar los requisitos.
Requisitos atributos deben ser definidos,
registran y actualizan a medida que el soft-
dimensiones de la exigencia (véase la sección 7.5. La medición de Requisitos

4.1, los requisitos de clasificación) y el método
de verificación o sección del plan de prueba de Como cuestión práctica, suele ser útil tener
aceptación correspondiente. También puede algún concepto de “volumen” de las exigencias
incluir información adicional, como una para un producto de software en particular. Este
justificación de resumen para cada requisito, la número es útil para evaluar el “tamaño” de un
fuente de cada requerimiento, y un historial de cambio en los requisitos, al estimar el costo de
cambios. Los requisitos más 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 tamaño
identificadas de manera única e inequívoca. funcional (FSM) es una téc- nica para evaluar el
tamaño de un cuerpo de requisitos funcionales.
7.4. requisitos de rastreo Información adicional sobre la medición y
estándares de tamaño se encuentra en el Proceso
Requisitos de rastreo tiene que ver con objeto de de Software niería Inge- KA.
reembolso ing la fuente de los requisitos y la
predicción de los efectos de los requisitos. El 8. Requisitos de software Herramientas
rastreo es fundamental para la realización de
análisis 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 categorías:
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 gestión de requisitos.
nuevo a la exigencia (s) del sistema que ayuda a herramientas de gestión 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- mentación, la
requisitos de diseño y entidades que lo satisfacen localización, y la gestión del cambio y han
(por ejemplo, de un requisito del sistema en los tenido un impacto significativo en la práctica.
requisitos de software que se han elaborado a De hecho, ing trac- y la gestión del cambio son
partir de ella, y en en los módulos de código que realmente sólo prác- ticable si es compatible con
lo implementan, o la casos de prueba una herramienta. Desde la gestión de requisitos
relacionados con ese código, e incluso una es fundamental para la buena práctica de los
sección dada en el manual de usuario que requisitos, muchas organizaciones han invertido
describe la funcionalidad real) y en el caso de en herramientas de gestión de requisitos, aunque
prueba que verifica. muchos más manejar sus requisitos en más ad
Los requisitos de seguimiento para un típico hoc y generalmente menos satisfactorios
proyec- ect formarán un complejo gráfico maneras (por ejemplo, utilizando hojas de
dirigido acíclico (DAG) (ver Gráficos en el cálculo).
Computing Foundation ciones KA) de
requisitos. El mantenimiento de una matriz
gráfica fecha o trazabilidad hasta-a es una
actividad que debe ser considerada durante todo
el ciclo de vida de un producto. Si la
información de trazabilidad no se actualiza
como los cambios en los requisitos siguen
ocurriendo, la información de trazabilidad deja
de ser fiable para el análisis del impacto.
MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA
2011 [1 *]
Wiegers 2003
SommervilLe
[2 *]
1. Requisitos de software Fundamentos
1.1. Definición 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. Administración y Apoyo Proceso c3
2.4. Proceso de Calidad y Mejora c22, c23
3. la obtención de requisitos
3.1. requisitos Fuentes c4s5 C5, C6, C9
3.2. técnicas de obtención c4s5 c6
Análisis 4. Requisitos
4.1. requisitos Clasificación c4s1 c12
4.2. Modelado conceptual c4s5 c11
4.3. Diseño y requisitos arquitectónicos Asignación c10s4 c17
4.4. requisitos de Negociación c4s5 c7
4.5. Análisis formal c12s5
5. Requisitos Especificación
5.1. Definición del sistema de documentos c4s2 c10
c4s2, c12s2,
5.2. Requisitos del sistema Especificación c12s3, c12s4, c10
c12s5
5.3. Especificación de Requerimientos de Software c4s3 c10
6. Requisitos de Validación
6.1. requisitos críticas c4s6 c15
6.2. prototipado c4s6 c13
6.3. Modelo de validación c4s6 c15
6.4. Prueba de aceptacion c4s6 c15
2011 [1 *]
Wiegers 2003
SommervilLe
[2 *]
7.1. La naturaleza iterativa del proceso Requisitos c4s4 C3, C16
7.2. Gestión del cambio c4s7 c18, c19
7.3. requisitos Atributos c4s1 c12, c14
7.4. requisitos de rastreo c20
7.5. La medición de Requisitos c4s6 c18
8. Requisitos de software Herramientas c21
LECTURAS
I. Alexander y L. Beus-Dukic, Requisitos A. van Lamsweerde, Ingeniería de Requisitos:
Descubriendo [5]. A partir de los objetivos del sistema de
modelos UML a Especificaciones de
Un libro de fácil digestión y de carácter práctico software [7].
sobre los requisitos de software, esto es quizás el
mejor de los libros de texto actuales sobre cómo Sirve como una buena introducción a la
los diferentes elementos de los requisitos de ingeniería de requisitos, pero su valor único es
software encajan entre sí. Está lleno de consejos como un libro de referencia para los requisitos
prácticos 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
cómo evaluar soluciones alternativas. Su edad y muestra cómo se puede integrar con técnicas
cubierta- es ejemplar y sirve como una de modelado convencionales usando UML.
referencia útil para técnicas de clave, tales como
modelado de caso de uso y requisitos de O. Gotel y A. Finkelstein, “Un análisis del
priorización. problema Requisitos trazabilidad” [8].
C. Potts, K. Takahashi, y A. Antón, “indagación Este trabajo es una obra de referencia clásica en
Análisis Requisitos Basado” [6]. un elemento clave de la gestión de requisitos.
Basándose en estudios empíricos, establece las
Este documento es una cuenta de fácil digestión 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 desarrollo de las necesidades de comprensión de por qué los requisitos de rastreo
manipulación. En él se describe cómo y por qué es un elemento esencial de un proceso de
la elaboración 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 adquisición de
provocadas por parte del cliente. El papel de los COTS Requisitos de selección de
escenarios se describe de una manera que ayuda software” [9].
a definir su uso en el descubrimiento y la
descripción de los requisitos. Este documento es importante porque reconoce
explícitamente que los productos de software a
menudo integran componentes de terceros.
Ofrece una visión de los problemas de la
selección de software off-the-shelf para
satisfacer los requisitos: por lo general hay una
falta de coincidencia. Esto desafía algunos de los
supuestos sub fijando la mayor parte de los
requisitos tradicionales dling manipulan de, que
tiende a asumir software personalizado.
Referencias
[1 *] I. Sommerville, Ingeniería de Software, 9ª [6] C. Potts, K. Takahashi, y AI Antón,
ed., Addison-Wesley, 2011. “basada en la indagación Análisis 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, Ingeniería de
[3] INCOSE, Manual de Sistemas de Requisitos: A partir de los objetivos del
Ingeniería: Una guía para los procesos de sistema de modelos UML a especificaciones
ciclo de vida del sistema y Actividades, de software, Wiley, 2009.
versión 3.2.2, Consejo Internacional de
Ingeniería de Sistemas, 2012. [8] O. Gotel y CW Finkelstein, “Un análisis del
problema exigencias de trazabilidad,” Proc.
[4] S. Friedenthal, A. Moore, y R. Steiner, Primero Int'l Conf. Requisitos Eng., IEEE,
Una guía práctica para SysML:. El sysml, 1994.
2ª ed, Morgan Kaufmann, 2012.
[9] NA Maiden y C. Ncube, “La adquisición de
[5] I. Alexander y L. Beus-Deukic, Requisitos de Elección COTS software”,
Descubriendo Requisitos: Cómo IEEE Software, vol. 15, no. 2, marzo-abril.
especificar los productos y servicios, 1998, pp. 46-56.
Wiley, 2009.
CAPÍTULO 2 DISEÑO
DEL SOFTWARE
SIGLAS Nosotros También puede examinar y evaluar

soluciones alternativas y compensaciones.
Arquitectura Descripción Finalmente, podemos utilizar los modelos
ADL
Idioma resultantes para planificar actividades de
CDB Diseño basado en componentes desarrollo posteriores, como la verificación del
CRC Responsabilidad clase colaborador sistema y ción validación, además de su uso
como entradas y como el punto de partida de la
DFD Diagrama de flujo de datos
construcción y prueba.
ERD Relación diagrama de entidad En una lista estándar de procesos de ciclo de
IDL Interfaz de lenguaje de descripción 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 diseño de software
OO Orientado a objetos
consta de dos actividades que se ajustan entre el
PDL Programa de Lenguaje de Diseño análisis de los requisitos de software y la
construcción de software:
INTRODUCCIÓN • diseño de la arquitectura de software (a

veces llamado diseño de alto nivel):
Diseño se define como tanto “el proceso de desarrolla la estructura de alto nivel y
defin- ing la arquitectura, componentes, organización del software y se identifican
interfaces y otras características de un sistema o los distintos componentes.
componente” y “el resultado del proceso [que]” • Software de diseño detallado: especifica
[1]. Visto como un proceso, diseño de software cada componente en suficiente detalle para
es el ing la actividad del ciclo de vida del facilitar su construcción.
software en el que Engineer- mentos de software
requisito se analizan con el fin de producir una Esta área de conocimiento Diseño de Software
descripción de la estructura interna del software (KA) no habla de todos los temas que incluye la
que va a servir de base para su construcción. Un palabra “diseño”. En la terminología de Tom
diseño de software (el resultado) describe el DeMarco [3], los temas tratados en este acuerdo
software de architecture, es decir, cómo se KA principalmente con D-diseño (diseño de
descompone software y organizado en descomposición), cuyo objetivo es el mapeo de
componentes-y las caras interrelaciones entre software en piezas componentes. Sin embargo,
esos componentes. También debe describir los debido a su importancia en el campo de la
componentes a un nivel de detalle que permite arquitectura de software, también vamos a tratar
su construcción. FP-diseño (diseño del patrón de la familia), cuyo
El diseño 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 diseño de software, ingenieros de software software. Esta KA no se ocupa de la I-diseño
producen varios modelos que forman una (diseño invención), que se realiza generalmente
especie de anteproyecto de la solución a durante el proceso de requisitos de software con
implementar. Podemos analizar y evaluar estos el objetivo de alizing conceptualización y la
modelos para determinar si son o no nos especificación de software para satisfacer las
permitirán cumplir con los diversos requisitos. necesidades y requerimientos descu- Ered, ya
que este tema es considerado como parte de el Requisitos
Este software de diseño KA esdeespecificación
software 1-23
proceso de requisitos (ver los requisitos de relacionada
software KA). camente a los requisitos de software, Software
2-1
Figura 2.1. Desglose de temas para el Software de Diseño KA
Construcción, Ingeniería de Software Ment la comprensión de los límites del diseño. Un

Manage-, modelos de ingeniería de software y número de otras nociones y conceptos También
met- ods, Calidad de Software y Computación son de interés en la comprensión del diseño en
Fundaciones ciones de Kas. su sentido general: objetivos, las limitaciones,
las alternativas, las representaciones y las
DISTRIBUCIÓN DE TEMAS PARA EL soluciones (véase el problema técnicas de
DISEÑO DEL SOFTWARE resolución en los Fundamentos de Informática
KA).
El desglose de temas para el Software de Diseño
KA se muestra en la Figura 2.1. 1.2. Contexto de Diseño de Software
[4 *, c3]
1. Fundamentos del diseño de software
El diseño de software es una parte importante
La conceptos, nociones, y la terminología intro- del proceso de desarrollo de software. Para
ducido aquí forman una base subyacente para la entender el papel del diseño de software,
sub pie el papel y el alcance de diseño de tenemos que ver cómo 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 diseño caracterís- ticas de análisis de requisitos de
[4 *, c1] software, diseño de software, la construcción de
software, pruebas de software, y el
En sentido general, el diseño puede ser visto mantenimiento del software.
como una forma de resolución de problemas.
Por ejemplo, el concepto de una solución de un 1.3. Software de Diseño de Procesos
problema complejo sin solución definitiva, es [4 *, c2]
interesante en términos de
El diseño del software es generalmente
considerado como un proceso de dos pasos: 2- Diseño de
Software3
• Diseño arquitectónico (también conocido programa de ordenador”, mientras que la

como diseño de niveles altos y diseño de cohesión se define como “una medida de la
nivel superior) describe cómo el software fuerza de la asociación de los elementos
está organizado en componentes. dentro de un módulo” [1].
• El diseño detallado se describe el comporta- • La descomposición y la modularización.
miento deseado de estos componentes. posando descomposición y la modularización
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 explicación de los fundamentos de cada
decisión no trivial. Guardando el razonamiento,
la capacidad maintain- a largo plazo del
producto de software es mayor.
1.4. Principios de Diseño de Software

[4] [5 *, c6, c7, c21] [6 *, c1, c8,
c9]
Un principio es “una completa y fundamental

ley, doctrina o suposición” [7]. principios de
diseño de software son nociones clave que
proporcionan la base para muchos diferentes
enfoques de diseño de software y conceptos.
diseño de software principios incluyen la
abstracción; acoplamiento y de cohesión; la
descomposición y la modularización; ción
encapsula- / ocultar información; separación de
interfaz y la implementación; suficiencia,
integridad, y primitivo; y la separación de
preocupaciones.
• Abstracción es “una vista de un objeto que

se centra en la información relevante para
un propósito particular y hace caso omiso
de la der restante de la información” [1]
(véase Abstracción en los Fundamentos de
computación KA). En el contexto del diseño
de software, dos mecanismos de abstracción
clave son la parametrización y la
especificación. Abstracción por resúmenes
ción parametrización de los detalles de
sentaciones de datos sentantes de
representación de los datos como
parámetros con nombre. Abstracción por la
especificación conduce a tres tipos
principales de la abstracción: abstracción de
procedimientos, la abstracción de datos, y la
abstracción de control (iteración).
• Acoplamiento y cohesión. El acoplamiento
se define como “una medida de la
interdependencia entre los módulos en un
2- Diseño
7, Software de Diseño Estrategias de
y Métodos).
el software se divide en una serie de Software5
componentes nombrados más pequeños Por el contrario, otras cuestiones “trato con
que tienen interfaces bien definidas que algún aspecto del comportamiento del software
describen las interacciones de los que no está en el dominio de la aplicación, pero
componentes. Por lo general, el objetivo es que aborda algunas de las apoyando
colocar diferentes funcionalidades y
responsabilidades en diferentes
componentes.
• Encapsulación y ocultación de la
información significa la agrupación y el
envasado de los detalles internos de una
abstracción y haciendo esos detalles
inaccesibles a entidades externas.
• La separación de interfaz y la
implementación. La separación de interfaz
y la implementación consiste en definir un
componente de specify- ing una interfaz
pública (conocidos por los clientes) que es
independiente de los detalles de cómo se
realiza el componente (ver encapsulación
y ocultación de la información anterior).
• Suficiencia, integridad y primitivo. El
logro de suficiencia y medios de
integridad para garantizar que un
componente de software captura todas las
características importantes de una
abstracción y nada más. Ness Primitive-
significa que el diseño debe estar basado
en patrones que son fáciles de
implementar.
• Separación de intereses. Una
preocupación es un “área de interés con
respecto a un diseño de software” [8]. Una
de las preocupaciones de diseño es un área
de diseño que es relevante para uno o más
de sus grupos de interés. Cada vista de la
arquitectura enmarca uno o más
preocupaciones. La separación 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 diseño de software
Una serie de cuestiones clave debe ser tratado

en el diseño de software. Algunos son
problemas de calidad que todo el software debe
abordar, por ejemplo, rendimiento, seguridad,
fiabilidad, facilidad de uso, etc. Otra cuestión
importante es cómo descomponer, organizar y
componentes de software paquete. Esto es tan
fundamental que todos los enfoques de diseño
enmarcan en una forma u otra (véase la sección
1.4, Principios de diseño de software, y el tema
dominios”[10]. Estas cuestiones, que a menudo 2.6. Interacción y Presentación

crosscut la funcionalidad del sistema, se han [5 *, c16]
referido como aspectos, que “no tienden a ser
unidades de soft-
descomposición funcional de las mercancías, Este problema de diseño se ocupa de cómo es-
sino más 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 presentación de
en formas sistémicas”[11]. Varias de estas información (por ejemplo, la separación de
cuestiones clave, transversales se tratan en las presentación y la lógica de negocio utilizando el
secciones siguientes (presentados en orden enfoque del Modelo-Vista-Controlador). Tenga
alfabético). en cuenta que este tema no especifica detalles de
la interfaz de usuario, que es la tarea de diseño
2.1. concurrencia de la interfaz de usuario (véase el tema 4, diseño
[5 *, c18] de interfaz de usuario).
Diseño para la concurrencia tiene que ver con el 2.7. Seguridad

software de presentación descomposición en los [5 *, c12, c18] [13 *,
procesos, tareas y discusiones y hacer frente a c4]
cuestiones relacionadas con la eficiencia, la
atomicidad, sincronización y programación. Diseño para la seguridad tiene que ver con la
forma de pre ventilar la divulgación no
2.2. Control y manejo de Eventos autorizada, creación, cambio, supresión o
[5 *, c21] negación del acceso a la información y otros
recursos. También tiene que ver con la forma en
Este problema de diseño se ocupa de la forma de que tolerar ataques o violaciónes relacionadas
organizar los datos y flujo de control, así como con la seguridad mediante la limitación de
la forma de manejar los eventos reactivos y daños, funcionamiento continuo, acelerar la
temporales a través de diversos mecanismos reparación y recuperación, y en su defecto y
como la invocación implícita y devoluciones de recuperar de forma segura. El control de acceso
llamadas. es un concepto fundamental de la seguridad, y
también se debe garantizar el buen uso de la
2.3. Persistencia de datos criptografía.
3. Estructura del software y Arquitectura

[12 *, c9]
Este problema de diseño se ocupa de la forma de
Este problema de diseño se ocupa de cómo se pre- ventilación, tolerar, y los errores de proceso y
manipulan de datos de larga vida dle. hacer frente a condiciones excepcionales.
2.4. Distribución de Componentes

[5 *, c18]
Este problema de diseño se ocupa de cómo

redistribuir el software en el hardware
(INCLUYENDO hardware de ordenador y
hardware de red), cómo se comunican los
componentes, y cómo middleware se puede
utilizar para tratar con el software heterogéneo.
2.5. Error y control de excepciones y la

tolerancia a fallos
[5 *, c18]
En su sentido más estricto, una arquitectura de 2- Diseño 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 década de
1990, sin embargo, la arquitectura de software
comenzó a surgir como una disciplina más
amplia que implicaba el estudio de las
estructuras y arquitecturas de software de una
manera más genérica. Esto dio lugar a una serie
de conceptos interesantes sobre el diseño de
software en diferentes niveles de abstracción.
Algunos de estos conceptos pueden ser útiles
en el diseño arquitectónico (por ejemplo, los
estilos arquitectónicos), así como durante el
diseño detallado (por ejemplo, el diseño Pat-
charranes). Estos conceptos de diseño también
se pueden utilizar para diseñar las familias de
programas (también conocido como líneas de
producto). Curiosamente, la mayoría de estos
conceptos pueden ser vistas como intentos de
describir, y por lo tanto la reutilización, el
conocimiento de diseño.
3.1. Las estructuras arquitectónicas y puntos de patrones que describen la organización de alto
vista nivel de software, otros patrones de diseño se
[14 *, c1] pueden utilizar para describir los detalles en un
nivel inferior. Estos patrones de diseño de bajo
Las diferentes facetas de alto nivel de un diseño nivel son los siguientes:
de software pueden ser descritos y
documentados. Estas facetas son a menudo • patrones de creación (por ejemplo,
llamados puntos de vista: “Una vista representa constructor, fábrica, 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 diseño, por ejemplo, la vista lógica ejemplo, comandos, intérprete, 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 física (problemas de distribu-
ción) frente a la vista de desarrollo (como el el 3.4. Las decisiones Arquitectura Diseño
diseño se divide en unidades de ejecución con [5 *, c6]
representación explícita de las dependencias
entre las unidades). Varios autores utilizan El diseño arquitectónico es un proceso creativo.
diferentes terminologías-como frente a la Duran- te el proceso de diseño, los diseñadores
conducta funcional vs. vistas de modelado de de software tienen que tomar una serie de
datos vs. estructurales. En resumen, un diseño de decisiones fundamentales que afectan
software es un artefacto multifacético producido profundamente el proceso de desarrollo de
por el proceso de diseño y generalmente software y. Es útil pensar en el proceso de
compuesta de puntos de vista relativamente diseño 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 arquitectónicos 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 arquitectónico es “una especialización diseño.
de tipos Ment y relación 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]
arquitectónico de este modo puede ser visto
como para simplificar la organización de alto Un enfoque para proporcionar la reutilización de
nivel del software. Varios autores han diseños y componentes de software es el diseño
identificado una serie de grandes estilos tectural de las familias de programas, también conocidas
arqui-: como líneas de productos de software. Esto se
puede hacer mediante la identificación de los
• Las estructuras generales (por ejemplo, puntos en común entre los miembros de estas
capas, tuberías y filtros, pizarra) familias y mediante el diseño 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 programación orientada a objetos (OO),
View--Controller, Presentación-Abstracción- una noción 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-, reflexión) instanciar apropiadamente extensiones
• Otros (por ejemplo, por lotes, intérpretes, específicas (tales como plug-ins).
control proceso, basado en reglas).
2- Diseño de
3.3. Patrones de 4. Diseño de interfaz de usuario
Software9
diseño [15 *, c3, c4,
c5] diseño de interfaz de usuario es una parte esencial
de la
Sucintamente descrito, un patrón es “una proceso de diseño de software. diseño de interfaz
solución común a un problema común en un de usuario debe asegurarse de que la interacción
contexto dado” [16]. Mientras que los estilos entre el humano y la máquina proporciona para
arquitectónicos pueden ser vistos como un funcionamiento eficaz
y el control de la máquina. Para el software para interacción del usuario y presentación de la

alcanzar su pleno potencial, la interfaz de información. diseño de interfaz de usuario debe
usuario debe ser diseñado para que coincida con considerar un compromiso entre los estilos más
las habilidades, experiencia y expectativas de apropiados de interacción
sus usuarios previstos.
1 Capítulo 29 es un capítulo 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/.
diseño de interfaces
[5 *, c29-web] [17 *, c2]
1
• Facilidad de aprendizaje. El software debe

ser fácil de aprender para que el usuario
pueda iniciar rápidamente trabaja con el
software.
• la familiaridad del usuario. La interfaz debe
utilizar términos y conceptos extraídos de
los experimentos de los cias personas que
vayan a utilizar el software.
• Consistencia. La interfaz debe ser tienda de
campaña consis- para que las operaciones
comparables se acti- vada de la misma
manera.
• sorpresa mínimo. 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.
• guía para el usuario. La interfaz debe dar
retroalimentación significativa cuando se
producen errores y proporcionar ayuda
contextual para los usuarios.
• la diversidad de usuarios. La interfaz debe
pro- mecanismos de interacción vide
apropiados para diversos tipos de usuarios y
para los usuarios con capacidades diferentes
(ciegos, problemas de visión, sordos, ciegos
al color, etc.).
4.2. Interfaz de usuario Problemas Diseño

[5 *, c29-web] [17 *, c2]
diseño de interfaz de usuario debe resolver dos
cuestiones fundamentales:
• ¿Cómo debe el usuario interactuar con el

software?
• ¿Cómo debe la información desde el
software se presenta al usuario?
diseño de interfaz de usuario debe integrar la

2- Diseño de
sí misma. El enfoque MVC (Modelo-Vista-
y la presentación 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 presentación de información se separe de la
información que se presenta.
4.3. El diseño de las modalidades de interacción
del usuario
[5 *, c29-web] [17 *,
c2]
La interacción del usuario implica la emisión

de comandos y la disponibilidad de datos
asociada con el software. estilos de interacción
del usuario se pueden clasificar en los estilos
primarios siguientes:
• Pregunta respuesta. La interacción es

esencialmente restringido a un único
intercambio de preguntas y respuestas
entre el usuario y el software. El usuario
envía una pregunta al software y el
software devuelve la respuesta a la
pregunta.
• Manipulación directa. Los usuarios
interactúan con los objetos en la pantalla
del ordenador. La manipulación directa a
menudo incluye un dispositivo señalador
(como un ratón, trackball o un ger de
dedos en las pantallas táctiles) que
manipula un objeto e invoca las acciones
que especifican lo que se debe hacer con
ese objeto.
• selección 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 menús, en cuyo caso el
formulario tiene botones de acción para
que el usuario inicie la acción.
• lenguaje de comandos. El usuario emite un
com- mand y proporciona los parámetros
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 software.
4.4. El diseño de la información Presentación

[5 *, c29-web] [17 *,
c2]
presentación de la información puede ser

textual o gráficamente cal en la naturaleza. Un
buen diseño mantiene la presentación de
información por separado de la información en
Software Los ingenieros también tienen en ana- lyzes tareas de los usuarios, la ment
cuenta el tiempo de respuesta del software y la ENTORNO trabajo, otro software, y cómo
retroalimentación en el diseño de presentación los usuarios interactúan con otras personas.
de infor- mación. El tiempo de respuesta se mide • creación de prototipos de software. El
generalmente desde el punto en el que un desarrollo de prototipos de software ayudan a
usuario ejecuta una cierta acción de control hasta los usuarios a guiar la evolución de la
que el software responde con una respuesta. Una interfaz.
indicación del progreso es deseable poder • evaluación de la interfaz. diseñadores puede
mientras que el software está preparando la observar experiencias de los usuarios con la
respuesta. La retroalimentación puede ser interfaz de evolución.
proporcionado mediante la reformulación de la
entrada del usuario mientras que el
procesamiento se está terminando.
Abstractos visualizaciones pueden ser
utilizados cuando grandes cantidades de
información se han de presentar.
De acuerdo con el estilo de presenta- ción de
la información, los diseñadores también pueden
utilizar el color para mejorar la interfaz. Existen
varias pautas importantes:
• Limitar el número de colores utilizados.

• Utilice el cambio de color para mostrar el
cambio de soft-
el estado de las mercancías.
• Use códigos de colores para apoyar la tarea
del usuario.
• Use códigos de colores en un reflexivo y
consis-
manera carpa.
• Use colores para facilitar el acceso de las
personas con ceguera o deficiencia
cromática de color (por ejemplo, utilizar el
cambio de la saturación del color y el brillo
del color, tratar de evitar combinaciones de
azul y rojo).
• No dependa sólo en el color para transmitir
información importante para los usuarios
con capacidades diferentes (ceguera,
problemas de visión, ceguera por colores,
etc.).
4.5. Proceso de Interfaz de usuario Diseño

[5 *, c29-web] [17 *, c2]
diseño de interfaz de usuario es un proceso

iterativo; prototipos de interfaz se utilizan a
menudo para determinar las características, la
organización, y la apariencia de la interfaz de
usuario software. Este proceso incluye tres
actividades principales:
• análisis usuario. En esta fase, el diseñador

4.6. Localización e internacionalización diseño de software, incluyendo variosde“-ilities”
2- Diseño
Software13
[17 *, c8, c9] (mantenibilidad, portabilidad, capacidad de
prueba, la facilidad de uso)
diseño de interfaz de usuario a menudo
necesita considerar la internacionalización y
localización, que son medios para adaptar
software a los diferentes idiomas, diferencias
regionales y las exigencias técnicas de un
mercado objetivo. La internacionalización es el
proceso de diseño de una aplicación de
software para que pueda ser adaptado a
diferentes idiomas y regiones sin mayores
cambios de ingeniería. La localización es el
proceso de adaptación de software
internacionalizado para una región o idioma
mediante la adiciónlocale-
específicacomponentes FIC y traducir el texto.
Localización e internacionalización deben
tener en cuenta factores tales como símbolos,
números rencia Cur-, el tiempo y las unidades
de medida.
4.7. Metáforas y modelos conceptuales

[17 *, c5]
los diseñadores de interfaces de usuario pueden

utilizar metáforas y modelos conceptuales para
establecer correspondencias entre el software y
algún sistema de referencia conocida a los
usuarios en el mundo real, lo que puede ayudar
a los usuarios a aprender más fácilmente y usar
la interfaz. Por ejemplo, la operación de
“borrar el archivo” se puede convertir en una
metáfora con el icono de un cubo de basura.
En el diseño de una interfaz de usuario, inge-
niería de software deben tener cuidado de no
usar más de una metáfora para cada concepto.
Metáforas también problemas potenciales ent
PRESION con respecto a internacionalmente
lización, ya que no todas las metáforas son
significativa o se aplican de la misma manera
dentro de todas las culturas.
5. Diseño Análisis y Evaluación de la

Calidad de Software
En esta sección se incluye una serie de Ysis

anal- de calidad y evaluación temas que están
específicamente relacionados con el diseño de
software. (Véase también la calidad KA
software).
5.1. Los atributos de calidad

[4 *, c4]
Varios atributos contribuyen a la calidad de un

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

interesante distinción entre la calidad atribuye [4 *, c4] [5 *,
discernibles en tiempo de ejecución (por c24]
ejemplo, per-
Formance, seguridad, disponibilidad, los modelos de ingeniería de software y
funcionalidad, facilidad de uso), los que no métodos KA).
discernible en tiempo de ejecución (por ejemplo, • Simulación y prototipado: técnicas dinámicas
modificabilidad, portabilidad, reusabilidad, la para evaluar un diseño (por ejemplo, la
capacidad de prueba), y las relacionadas con las simulación de rendimiento o prototipos de
cualidades intrínsecas de la arquitectura (por viabilidad).
ejemplo, conceptual integridad, exactitud,
integridad) . (Véase también la calidad KA
software).
5.2. Análisis de calidad y técnicas de evaluación

[4 *, c4] [5 *, c24]
Varias herramientas y técnicas pueden ayudar en

ing analyz- y la evaluación de la calidad del
diseño de software.
• Software revisiones de diseño: técnicas

malized informales y lucro para determinar
la calidad de los artefactos de diseño (por
ejemplo, las revisiones de la arquitectura,
las revisiones de diseño, y las inspecciones,
las técnicas basadas en escenarios, los
requisitos de rastreo). las revisiones de
diseño de software también pueden evaluar
la seguridad. Ayudas para la instalación,
funcionamiento, y el uso (por ejemplo,
manuales y archivos de ayuda) pueden ser
revisados.
• El análisis estático: static formal o
semiformal análisis (no ejecutable) que
puede ser utilizado para evaluar un diseño
(por ejemplo, análisis de árbol a fallos o
automatizada comprobación cruzada).
análisis de vulnerabilidad de diseño (por
ejemplo, el análisis estático de las
debilidades de seguridad) puede llevarse a
cabo si la seguridad es una preocupación. El
análisis formal del diseño utiliza modelos
matemáticos que permiten a los diseñadores
predicado el comportamiento y validar el
rendimiento del software en lugar de tener
que depender por completo de la prueba.
análisis de diseño formal puede ser utilizado
para detectar errores de especificación y
diseño residuales (per- HAPS causado por
la imprecisión, la ambigüedad, y algunas
veces otros tipos de errores). (Ver también
Las medidas pueden ser utilizados para evaluar 2- Diseño de
Software15
o estimar cuantitativamente diversos aspectos
de un diseño de software; por ejemplo, tamaño,
estructura, o la calidad. La mayoría de las
medidas que se han propuesto dependen del
método utilizado para la producción del diseño.
Estas medidas se clasifican en dos grandes
categorías:
• medidas (estructurada) de diseño basados

en funciones: medidas obtenidas mediante
el análisis funcional de descomposición;
generalmente representado mediante un
diagrama de estructura (a veces llamado
un diagrama jerárquico) sobre la que se
pueden calcular diversas medidas.
• medidas de diseño orientada a objetos: la
estructura de diseño se representa
típicamente como un diagrama de clases,
en el que se pueden calcular diversas
medidas. Medidas sobre las propiedades
del contenido interno de cada clase
también se pueden calcular.
6. Las notaciones de diseño de software
Existen muchas notaciones para representar

artefactos de diseño de software. Algunos se
utilizan para describir la organización
estructural de un diseño, otros para representar
el comportamiento de software. Ciertas
notaciones se utilizan sobre todo durante el
diseño arquitectónico y otros, principalmente
durante el diseño detallado, aunque algunas
anotaciones se pueden utilizar para ambos
propósitos. Además, algunas anotaciones se
utilizan sobre todo en el contexto de los
métodos de diseño específicos (ver tema 7,
Software de Diseño Estrategias y Métodos).
Tenga en cuenta que el diseño de software a
menudo se logra usando notaciones múlti- ples.
A continuación, se clasifican en las notaciones
para describir la vista estructural (estático)
frente a la vista del comportamiento
(dinámico).
6.1. Las descripciones estructurales (estático

Vista)
[4 *, c7] [5 *, c6, c7] [6 *, c4, c5, c6,
c7]
[12 *, c7] [14 *,
c7]
Las siguientes anotaciones, en su mayoría, pero

no siempre gráfica, describir y representar los
aspectos estructurales de un diseño de software
es que, son
se usa para describir los componentes otra parte, las descripciones del
principales y cómo comportamiento pueden incluir una
que están interconectados (visión estática): justificación de la decisión de diseño tales como
la forma de un diseño cumplirá con los
• Descripción de la arquitectura idiomas requisitos de seguridad.
(AVD): textual, a menudo formal, idiomas
utilizados para describir la arquitectura de
software en términos de componentes y
conectores.
• Clase y objeto diagramas: se utilizan para
represen- envían un conjunto de clases (y
objetos) y sus interrelaciones.
• diagramas de componentes: utilizados para
representar un conjunto de componentes (
“físico y reemplazar- parte capaz [s] de un
sistema que [conforme] para y
[proporcionar] la realización 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
(físicas) y sus interrelaciones, y, por lo
tanto, para modelar los aspectos físicos de
software.
• diagramas entidad-relación (ERD): se
utilizan para representar los modelos
conceptuales de los datos almacenados en
los depósitos de información.
• Descripción de la interfaz de idiomas (IDL):
lenguajes de programación 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 módulos de llamada, y se
llaman por, qué otros módulos).
6.2. Las descripciones de comportamiento (vista

dinámica)
[4 *, c7, c13] [5 *, c6, c7] [6 *, c4, c5, c6, c7]
[14 *, c8]
Las siguientes notaciones y lenguajes, algunos

gráfica y textual alguna, se utilizan para
describir el comportamiento dinámico de los
sistemas y componentes de software. Muchas de
estas anotaciones se uso-ful sobre todo, pero no
exclusivamente, durante el diseño detallado. Por
2- Diseño 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 comunicación: 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 descripción basada en modelo-
ing el flujo de información en torno a una
red de elementos operativos, con cada
elemento haciendo uso de o la modificación
de la información que fluye en ese elemento”
[4 *]. Los flujos de datos (y por tanto los
diagramas de flujo de datos) se pueden
utilizar para el análisis de la seguridad, ya
que ofrecen identifica- ción de posibles
caminos para el ataque y el cierre difusión de
la información confidencial.
• Las tablas de decisión 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.
• transición de estado y tabla de estado
diagramas: se utiliza para mostrar el flujo de
control de estado a estado y cómo el
comportamiento de un componente cambia
sobre la base de su estado actual en una
máquina de estado.
• lenguajes de especificación formales:
idiomas textuales que utilizan nociones
básicas de matemá- ticas (por ejemplo, la
lógica, set, secuencia) para definir
rigurosamente y de manera abstracta
interfaces de componentes de software y el
comportamiento, a menudo en términos de
condiciones previas y posteriores. (Véase
también la Ingeniería de Software Modelos y
ods met KA).
• pseudo código y lenguajes de diseño de
programas (PDL): lenguajes de
programación como estructurados utilizados
para describir, en general, en la etapa de
diseño detallado, el comportamiento de un
procedimiento o método.
7. El software de diseño estrategias y métodos diseño de mediados de 1980 (sustantivo = objeto;

verbo
Existen varias estrategias generales para ayudar = Método; adjetivo = atributo), donde herencia
a guiar el proceso de diseño. En contraste con y el polimorfismo juegan un papel clave, al
las estrategias generales, los métodos son más campo del diseño basado en componentes,
específicos en cuanto a que proporcionan donde la formación de metain- se puede definir y
generalmente un conjunto de notaciones para ser se accede a (a través de la reflexión, por
utilizado con el método, una descripción del ejemplo). Aunque las raíces del diseño orientado
proceso que se utilizará cuando se sigue el a objetos provienen del concepto de abstracción
método, y un conjunto de directrices para el uso de datos, diseño impulsado por la
del método. Tales métodos son útiles como un responsabilidad ha sido propuesta como un
marco común para los equipos de ingenieros de enfoque alternativo al diseño orientado a
software. (Ver también los modelos niería de objetos.
Software Engineers y Métodos KA).
7.4. Estructura de Datos Diseño Centrado
[4 *, c14, c15]
7.1. Las estrategias estructura centrada en los datos de diseño

generales [4 *, c8, c9, c10] [12 *, comienza a partir de las estructuras de datos de
c7] un programa manipula más que de la función
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
diseño incluyen las estrategias de dividir-y- estructura de control del programa en base a
vencerás 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 heurísticas para hacer frente a
arriba, y las estrategias que hacen uso de la ejemplo especial casos-para, cuando hay una
heurística, 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. Diseño basado en componentes (CDB)
7.2. Función-Oriented (Estructurado) Diseño [4 *, c17]
[4 *, c13]
Un componente de software es una unidad
Este es uno de los métodos clásicos de diseño de independiente, que tiene interfaces bien
software, donde los centros de descomposición definidas y dependencias 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 diseño
refinarlos en una de arriba hacia abajo de forma basadas en componentes relacionados con la
jerárquica. Diseño estructurado se utiliza prestación, el desarrollo y la integración de estos
generalmente después de un análisis componentes con el fin de mejorar la
estructurado, produciendo de este modo (entre reutilización. Reutilizados y off-the-shelf
otras cosas) diagramas de flujo de datos y software componentes deben cumplir mentos el
descripciones de procesos asociados. Los mismo requisito de seguridad como un nuevo
investigadores han propuesto diversas software. gestión de la confianza es un problema
estrategias (por ejemplo, el análisis de la de diseño; componentes tratados como hav- ing
transformación, análisis de transacciones) y un cierto grado de confiabilidad no debe
heurística (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-
*, Diseño de
c19, c21]
Software19
7.3. Diseño Orientado a
Objetos [4 *, También existen otros enfoques interesantes (ver
c16] los modelos de ingeniería de software y métodos
Se han propuesto numerosos métodos de diseño KA). Los métodos 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) diseño.
2- Diseño de
Software11
diseño orientada a aspectos es un método por el 8. Herramientas de diseño de software

cual el software se construye utilizando los [14 *, c10, Apéndice A]
aspectos a las aplicará las preocupaciones
transversales y extensiones que se identifican Las herramientas de diseño de software se puede
durante el proceso de los requisitos software. utilizar para apoyar la creación de los artefactos
arquitectura orientada a servicios es una manera de diseño 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 software se actividades:
construyen a menudo mediante el uso de servi-
cios de diferentes proveedores porque protocolos • traducir el modelo de requisitos en una
estándar (tales como HTTP, HTTPS, SOAP) se la representación de diseño;
han diseñado para soportar la comunicación de • para proporcionar soporte para la
servicios y el intercambio de información de representación de los componentes funcio-
servicio. nales y su interfaz (s);
• para implementar la heurística refinamiento
y la partición;
• proporcionar directrices para la evaluación de
la calidad.
al. 2010 [14
Gamma et al. 1994

Brookshear 2008
doLEMENTOS et
1999 [6 *]
2011 [5 *]
Budgen 2003
1993 [17
en 2008
Nielsen
Alabamal
Página-Jones
SommervilLe
[12 *]
[13 *]
[15 *]
[4 *]
nortea
*]
*]
1. Fundamentos
del Diseño de
Software
1.1. Diseño general
c1
Conceptos
1.2. El contexto de
c3
Diseño de Software
1.3. El Proceso de
c2
Diseño de
Software
1.4. Principios de C6, C7, C1, C8,
c1
Diseño de Software c21 C9
2. Cuestiones clave
en el diseño de
software
2.1. concurrencia c18
2.2. Control y
c21
Manipulación de
Eventos
2.3. Persistencia de C9
datos
2.4. Distribución
c18
de Componentes
2.5. Error y control
de excepciones y la c18
tolerancia a fallos
2.6. interacción y
c16
Presentación
c12,
2.7. Seguridad c4
c18
3. Estructura del
software y
Arquitectura
3.1. Las
estructuras c1
arquitectónicas y
puntos de vista c1, c2,
3.2. Estilos
c3, c4,
arquitectónicos
c5
c3, c4,
3.3. Patrones de
c5
diseño
2- Diseño 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
Página-Jones
SommervilLe
[12 *]
[13 *]
[15 *]
[4 *]
nortea
*]
*]
3.4. Las
c6
decisiones
Arquitectura
3.5. Las
Diseño C6, C7,
familias de los
C16
programas y
4. marcos
Diseño de
Interfaz de
Usuario
4.1. usuario
c29-
generalDiseño de c2
web
Interfaces
Principio
4.2. Interfaz de c29-
usuario Problemas web
Diseño
4.3. El diseño de
c29-
las modalidades
web
de interacción del
usuario
4.4. El diseño
c29-
de la
web
información
Presentación
4.5. Interfaz de c29-
usuario web
Proceso
4.6. de
Localización e
diseño C8, C9
internacionalización
4.7. Metáforas y
c5
modelos
5. conceptuales
Análisis de
Calidad de Software
de Diseño y
Evaluación
5.1. Calidad
c4
atributos
5.2. Análisis de
calidad y técnicas
c4 c24
de evaluación
5.3. medidas c4 c24

al. 2010 [14
Gamma et al. 1994

Brookshear 2008
doLEMENTOS et
1999 [6 *]
2011 [5 *]
Budgen 2003
1993 [17
en 2008
Nielsen
Alabamal
Página-Jones
SommervilLe
[12 *]
[13 *]
[15 *]
[4 *]
nortea
*]
*]
6. Diseño de
Software
notaciones
6.1. Las
C4, C5,
descripciones c7 C6, C7 c7 c7
C6, C7
estructurales
(estático
6.2. Las Vista)
C7, C13, C4, C5,
descripciones de C6, C7 c8
c18 C6, C7
comportamiento
7. (vista
Diseño dinámica)
de
Software
estrategias y
métodos
7.1. General C8, C9,
c7
Estrategias c10
7.2. FunciÃ³n-
Diseño Orientado c13
(estructurado)
7.3. Orientado a
c16
objetos
Diseño
7.4. Estructura de c14,
datos- c15
Diseño
7.5. Centrado
c17
Componente-
El diseño basado c19,
7.6.
(CDB)Otros metodos
c21
8. Herramientas c10,
de diseño de App.
software UN
2- Diseño de
Software15
LECTURAS mejores libros disponibles en la actualidad en la

arquitectura de software.
Roger Pressman, Ingeniería de Software: Un
Enfoque de la practicante (séptima edición)
[19].
Por cerca de tres décadas, Ingeniería de

Software de Roger Pressman: Enfoque para
profesionales ha sido uno de los libros de texto
más importantes del mundo en ingeniería de
software. Cabe destacar que este libro de texto
complementarios a [5 *] integral presenta
software de diseño, incluyendo los conceptos de
diseño, diseño arquitectónico, diseño a nivel de
componentes, diseño de la interfaz de usuario,
diseño basado en patrones y diseño de
aplicaciones web.
“El 4 + 1 Ver Modelo de Arquitectura” [20]. El
artículo seminal “The 4 + 1 Vista Modelo” or-

noce una descripción de una arquitectura de
software
utilizando cinco vistas concurrentes. Los cuatro
puntos de vista del modelo son la vista lógico, la
vista del desarrollo, la vista del proceso, y la
vista físico. Además, 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 según 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 práctica [21].
Este libro presenta los conceptos y las mejores

ticas ticas de arquitectura de software, es decir,
cómo el software está estructurado y cómo
interactúan los componentes del software.
Basándose en su propia experiencia, los autores
cubren los temas técnicos esenciales para el
diseño, especificación y validación de
arquitecturas de software. También hacen
hincapié en la importancia del contexto
empresarial en el que se ha diseñado 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
Referencias
[1] ISO / IEC / IEEE 24765: 2010 Sistemas y

de Ingeniería de Software-Vocabulario,
ISO / IEC / IEEE 2010.
[2] IEEE Std. 12207-2008 (también conocido

como ISO / IEC
12207: 2008) estándar para los sistemas y
software de ingeniería en software
procesos de ciclo de vida, IEEE 2008.
[3] T. DeMarco, “La paradoja de Arquitectura y

Diseño de Software,” Conferencia Premio
Stevens, 1999.
[4 *] D. Budgen, Diseño de software, 2ª ed.,

Addison-Wesley, 2003.
[5 *] I. Sommerville, Ingeniería de Software, 9ª

ed., Addison-Wesley, 2011.
[6 *] M. Página-Jones, Fundamentos del Diseño

orientado a objetos en UML, 1st ed.,
[7] Diccionario Colegiado de Merriam-Webster,

ed 11., 2003.
[8] IEEE Std. 1069-2009 Estándar de

Información Descripción Diseño
Tecnología-diseño de sistemas en software,
IEEE, 2009.
[9] ISO / IEC 42010: 2011 Sistemas y Prácticas

de Ingeniería de Software recomendado
para la descripción arquitectónica de los
sistemas intensivos Software-, ISO / IEC
2011.
[10] J. Bosch, Diseño y Uso de Software

Arquitecturas: La adopción y el desarrollo
de un enfoque Producto-Línea, ACM
Press, 2000.
[11] G. Kiczales et al., “Programación

orientada a aspectos,” Proc. Conf
Europea 11. Programación orientada a
objetos (ECOOP 97), Springer, 1997.
2- Diseño de
Software17
[12 *] JG Brookshear, Ciencias de la [17 *] J. Nielsen, Ingeniería de usabilidad,

Computación: Una visión 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 Guía del usuario de Lenguaje de Modelado
seguridad Ingeniería:. Guía para los Unificado, Addison-Wesley, 1999.
gerentes de proyecto, Addison-
Wesley, 2008. [19] RS Pressman, Ingeniería de Software:. El
enfoque de un practicante, 7ª ed, McGraw-
[14 *] P. Clements et al., el software de Hill, 2010.
documentación: Arquitecturas. Vistas y
más 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 diseño:.. 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 práctica, 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.
CAPÍTULO 3
CONSTRUCCIÓN DEL
SOFTWARE
de diseño se realiza durante la actividad de

SIGLAS construcción. Por lo tanto, la construcción del
de programación de aplicaciones software KA está estrechamente vinculado con el
API software de diseño KA.
Interfaz
A lo largo de la construcción, tanto los
COTS Commercial Off-The-Shelf ingenieros de software de prueba de unidad e
GUI Interfaz gráfica del usuario integración a prueba su trabajo.
Desarrollo integrado
IDE
Ambiente
Dios mio grupo de administración de objetos
Interfaz de sistema operativo
POSIX
portátil
TDD Desarrollo basado en pruebas
UML Lenguaje de Modelado Unificado
INTRODUCCIÓN
La construcción software término se refiere a la

creación detallada de software que trabaja a
través de una combinación de codificación,
verificación, la unidad de pruebas, las pruebas
de integración, y la depuración.
El área de conocimiento Construcción de
Software (KA) está vinculado a todos los demás
Kas, pero está más fuertemente relacionada con
Diseño de software y pruebas de software
debido a que el proceso de construcción de
software consiste en el diseño de software y
pruebas significativa. El proceso utiliza la salida
de diseño y proporciona una entrada a la prueba
( “diseño” y “prueba” en este caso se hace
referencia a las actividades, no la KAS). IES
Boundar- entre el diseño, construcción y pruebas
(si alguna) variarán dependiendo de los procesos
del ciclo de vida del software que se utilizan en
un proyecto.
Aunque algunos de diseño detallado se puede
realizar antes de la construcción, tanto el trabajo
2- Diseño
gestión de proyectos, en la medida endela gestión
Por lo tanto, la construcción del software KA Software19
de cons- trucción puede presentar retos
está estrechamente vinculada a la Prueba de considerables.
Software KA también.
construcción de software normalmente DISTRIBUCIÓN DE TEMAS PARA LA
produce el mayor número de elementos de CONSTRUCCIÓN DEL SOFTWARE
configuración que necesitan ser administrados
en un proyecto de software (archivos de código La figura 3.1 muestra una representación gráfica
fuente, documentación, casos de prueba, y así de la descomposición de nivel superior de la
sucesivamente). Por lo tanto, la construcción avería para la Construcción de Software KA.
del software KA también está estrechamente
ligada a la Gestión de la Configuración de 1. Fundamentos de software Construcción
Software KA.
Mientras que la calidad del software es fundamentos de construcción de software
importante en todos los Kas, código 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 construcción del • anticipar el cambio
software KA. • la construcción para la verificación
Dado que el software la construcción requiere • reutilizar
el conocimiento de algoritmos y de las • normas de construcción.
prácticas de codificación, que está
estrechamente relacionado con la Informática Los primeros cuatro conceptos se aplican al
Fundamentos KA, que se ocupa de la diseño, así como a la construcción. Las
informática Foundation ciones que apoyan el siguientes secciones definen
diseño y construcción de productos de
software. También está relacionada con la
3-1
Figura 3.1. Desglose de temas para la Construcción de Software KA

Construcción de Software 3-
3
estos conceptos y describen cómo se aplican a la pruebas independientes y las actividades

construcción. operacionales. Las técnicas específicas que
apoyan la construcción para la verificación
1.1. Complejidad minimizando incluyen siguiendo los estándares de
[1 *] codificación para apoyar las revisiones de
código y pruebas de unidad, la organización de
La mayoría de las personas están limitadas en su código para apoyar pruebas automatizadas, y
capacidad de mantener estructuras complejas e restrict- ing el uso de estructuras lenguaje
información en sus memorias de trabajo, complejas o difíciles de comprender, entre otros.
especialmente durante un período largo, de
tiempo. Esto demuestra ser un factor importante 1.4. Reutilizar
que influye en cómo las personas transmiten [2 *]
intención de computadoras y conduce a una de
las unidades más fuertes en la construcción de Reutilización refiere al uso de los activos
software: minimizando complejidad. La existentes en la solución de diferentes
necesidad de reducir la complejidad se aplica problemas. En la construcción de software, los
esencialmente a todos los aspectos de la activos ical typ- que se reutilizan incluyen
construcción de software y es particularmente bibliotecas, módu-, componentes, código fuente,
crítico para las pruebas de las construcciones de y off-the-shelf comercial (COTS) activos. La
software. reutilización es mejor ticas ticed
En la construcción de software, complejidad sistemáticamente, de acuerdo con un proceso
reducida se logra a través enfatizando la bien definido y repetible. reutilización
creación de código que es simple y fácil de leer sistemática puede permitir significativo de la
en lugar de inteligente. Esto se logra a través de productividad de software, la calidad y mejora
hacer uso de las normas (véase la sección 1.5, de los costes.
Normas de Construcción), el diseño modular Reutilización tiene dos facetas estrechamente
(ver sección 3.1, Diseño Construcción), y otras relacionados: “la construcción para la
numerosas técnicas específicas (ver sección 3.3, reutilización” y “reutilización construcción con”
Coding). También es apoyado por técnicas de Los antiguos medios para crear activos de
calidad centrado con la construcción (ver sec- software reutilizables, mientras que el segundo
ción 3.7, Construcción de Calidad). medio para la reutilización de activos de
software en la construcción de una nueva
1.2. pronóstico del cambio solución. Reutilización menudo trasciende los
límites de los proyectos, lo que significa activos
reutilizados se pueden construir en otros
proyectos u organizaciones.
[1 *] 1.5. Normas de construcción
[1 *]
La mayoría del software va a cambiar con el
tiempo, y el
anticipación de los cambios a muchos aspectos
de la construcción de software; los cambios en 1.3. La construcción de Verificación
los entornos en los que opera el software [1 *]
también afectan al software de diversas maneras.
Anticipar el cambio ayuda a los ingenieros de La construcción de medios de verificación de
software construir software extensible, lo que construcción 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
técnicas especí- espe- (véase la sección 3.3,
Coding).
3-4 Guía
LaSWEBOK® V3.0de
aplicación Dardos desarrollo dares
externos o internos durante la construcción
ayuda a lograr los objetivos de un proyecto
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 construcción incluyen
• métodos de comunicación (por ejemplo,

Standards para formatos de documentos y
contenidos)
• lenguajes de programación (por ejemplo,
las normas lenguaje para lenguajes como
Java y C ++)
• los estándares de codificación (por
ejemplo, los estándares para las
convenciones de nomenclatura, el diseño y
la sangría)
• plataformas (por ejemplo, los estándares
de interfaz de llamadas al sistema
operativo)
5
• herramienta (por ejemplo, normas para (incluyendo los requisitos, el diseño y la

anotaciones esquemáticas como UML planificación) o que los solapamientos. Estos
(Unified Modeling Language)). enfoques tienden a diseño, codificación, y las
actividades de prueba mezclar, y que a menudo
El uso de estándares externos. La tratan la combinación de actividades como la
construcción depende de la utilización de construcción (ver
estándares externos para lenguajes de
construcción, herramientas de construcción,
interfaces técnicas, y las interacciones entre el
software de construcción KA y otros KAs.
Normas proceden de numerosas fuentes,
incluyendo especificaciones de la interfaz de
hardware y software (como el Grupo de Gestión
de Objetos (OMG)) y las organizaciones inter-
nacionales (tales como el IEEE o ISO).
El uso de estándares internos. Las normas
también pueden ser creados sobre una base de
organización a nivel corporativa o para su uso
en proyectos específicos. Estas normas apoyan
la coordinación de las relaciones de grupo activi-
, lo que minimiza la complejidad, la anticipación
del cambio, y la construcción para su
verificación.
2. Construcción de la gestión
2.1. Construcción de Modelos de Ciclo de Vida

[1 *]
Numerosos modelos han sido creados para el

desarrollo de software; algunos hacen hincapié
en la construcción más que otros.
Algunos modelos son más lineal desde el
punto cons- trucción de vista, tales como la
cascada y modelos de ciclo de vida de la entrega
por etapas. Estos modelos tratan de la
construcción como una actividad que se produce
sólo después del trabajo prerrequisito importante
ha sido com- pletó-requisitos detallados
incluyendo el trabajo, un extenso trabajo de
diseño y planificación detallada. Los enfoques
más lineales tienden a enfatizar las actividades
que preceden a la construcción (los requisitos y
diseño) y para crear menticias SEP más claras
entre las actividades. En estos modelos, el
énfasis principal de la construcción puede ser de
codificación.
Otros modelos son más iterativo como el
prototipado evolutivo y desarrollo ágil. Estos
enfoques tienden a tratar la cons- trucción como
una actividad que se produce simultáneamente
con otras actividades de desarrollo de software
3-6 Guía SWEBOK® V3.0 Software KA para más información sobre la
el Software de Gestión y Procesos de Software
KAs). medición).
En consecuencia, lo que se considera que es
“cons- trucción” depende en cierta medida en
el modelo de ciclo de vida utilizado. En
general, la construcción de software es en su
mayoría codificación y depuración, pero
también implica la planificación de la
construcción, diseño detallado, las pruebas
unitarias, pruebas de integración, y otras
actividades.
2.2. Ordenación de la Edificación

[1 *]
La elección del método de construcción es un

aspecto clave de la actividad de la
construcción-planificación. La elección del
método de construcción afecta el grado en que
se realizan los requisitos previos de la
construcción, el orden en que se realizan, y el
grado en que deben ser completados antes de
que comience el trabajo de construcción.
El enfoque de la construcción afecta la
capacidad del equipo de proyecto para reducir
la complejidad, anticiparse a los cambios, y
construir para su verificación. Cada uno de
estos objetivos también pueden ser tratadas en
el proceso, requisitos y diseño de los niveles,
pero que se verá influido por la elección del
método de construcción.
planificación de la construcción también
define el orden en que se crean los
componentes e integrados, la estrategia de
integración (por ejemplo, por etapas o
integración incremental), los procesos de
gestión de calidad de software, la asignación de
la asignación de tareas a los ingenieros de
software específicos, y otras tareas, de acuerdo
con el método elegido.
2.3. Medición de la construcción

[1 *]
Numerosas actividades de construcción y los

artefactos se pueden medir, incluyendo el
código desarrollado, código modificado,
reutilizado código, el código destruida, código
de complejidad, las estadísticas de inspección
de código, culpa y culpa-fix-encontrar tarifas,
el esfuerzo y la programación. Estos surements
Measure pueden ser útiles para los propósitos
de la gestión de la construcción, lo que
garantiza la calidad durante la construcción, y
mejorar el proceso de construcción, entre otros
usos (véase la Ingeniería de Procesos de
7
3. Consideraciones prácticas sucesivamente. Pueden ser graves contribuyentes

al vulnerabilidades de seguridad.
La construcción es una actividad en la que el El tipo más simple del lenguaje construcción es
ingeniero de software tiene que hacer frente a las un lenguaje de configuración, en la que los
limitaciones del mundo real a veces caóticos y ingenieros de software elegir entre un conjunto
cambiantes, y él o ella debe hacerlo con limitado de opciones predefinidas para crear un
precisión. Debido a la influencia de las software nuevo o personalizado
restricciones del mundo real, la construcción
está más impulsado por consideraciones
prácticas que algunos otros Kas, e ingeniería de
software es quizás lo más oficio- como en las
actividades de construcción.
3.1. Diseño de la construcción

[1 *]
Algunos proyectos de diseño asignan

considerable actividad a la construcción,
mientras que otros asignan diseño a una fase
centrada explícitamente en el diseño.
Independien- temente de la asignación exacta,
algún trabajo de diseño detallado se producirá a
nivel de la construcción, y que el trabajo de
diseño 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
construcción la construcción de una estructura
físi- cas deben hacer modificaciones a pequeña
escala para dar cuenta de las lagunas no
previstos en los planes del constructor,
trabajadores de la construcción de software
deben hacer modificaciones en una escala más
pequeña o más grande para dar cuerpo a los
detalles del diseño de software durante la
construcción .
Los detalles de la actividad de diseño a nivel
cons- trucción son esencialmente el mismo que
el descrito en el Diseño de Software KA, pero se
aplican en una escala más pequeña de
algoritmos, estructuras de datos y las interfaces.
3.2. Idiomas de construcción

[1 *]
lenguas de construcción incluyen todas las
formas de comunicación mediante el cual un ser
humano puede especificar una solución de un
problema ejecutable a un problema. idiomas
cons- trucción 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 Guía SWEBOK® V3.0 cadenas de texto y más en las definiciones
instalaciones. Los archivos de configuración
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 selección de matemáticos). notaciones formales de
estilo de menú de algunos generadores de construcción y ods met formales están en la base
programas constituiría, otro ejemplo de un semántica de la mayoría de las formas de
lenguaje de configuración. idiomas Toolkit se
utilizan para construir aplicaciones de
elementos de juegos de herramientas (series
integradas de partes reutilizables específicos de
la aplicación); que son más complejos que los
idiomas de configuración. idiomas Toolkit
pueden definirse explícitamente como
lenguajes de programación de aplicaciones, o
las aplicaciones pueden simplemente estar
implicados por el conjunto de un conjunto de
herramientas
de interfaces.
Los lenguajes de script son tipos de uso
común de los lenguajes de programación de
aplicaciones. En algunos lenguajes de script,
guiones son llamados archivos por lotes o
macros.
Programación idiomas son el tipo más
flexible de las lenguas de construcción.
También contienen la menor cantidad de
información sobre áreas específicas de
aplicación y desarrollo de procesos-, por lo
tanto, requieren más entrenamiento y habilidad
para utilizar con eficacia. La elección del len-
guaje de programación puede tener un gran
efecto sobre la probabilidad de
vulnerabilidades de ser introducido durante
coding- por ejemplo, el uso acrítico de C y C
++ son opciones cuestionables desde un punto
de vista de la seguridad.
Hay tres tipos generales de notación que se
utiliza para lenguajes de programación, es
decir,
• lingüística (por ejemplo, C / C ++, Java)

• formales (por ejemplo, Evento-B)
• visual (por ejemplo, MatLab).
notaciones lingüísticas se distinguen en

particular por el uso de cadenas de texto para
representar construcciones de software
complejos. La combinación 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 connotación
semántica proporcionar una comprensión
intuitiva inmediata de lo que sucederá cuando
el software se ejecuta trucción ción.
Las notaciones formales depender menos
intuitiva, every- significados día de palabras y
9
notaciones de programación del sistema, donde 3.4. Prueba de la

la precisión, comportamiento en el tiempo, y la construcción [1 *]
capacidad de prueba son más importantes que la
facilidad de mapeo en lenguaje natural. Por-
construcciones mal también utilizan formas mentos, rutinas, clases, paquetes, u otras
definidas con precisión de la combinación de estructuras);
símbolos que evitan la ambigüedad de muchas • documentación de código;
construcciones de lenguaje natural. • Código de sintonía,
Visual notaciones confiar mucho menos en las
anotaciones textuales de construcción lingüística
y formal y en lugar de confiar en la
interpretación visual directa y la colocación de
las entidades visuales que representan el
software subyacente. Visual de la construcción
tiende a ser algo limitado por la dificultad de
hacer declaraciones “complejas” utilizando sólo
el Organizar- ción de los iconos en una pantalla.
Sin embargo, estos iconos pueden ser
herramientas poderosas en los casos en que la
tarea de programación principal es simplemente
para construir y “ajustar” una interfaz visual de
un programa, el comportamiento detallado de los
cuales tiene una definición subyacente.
3.3. Codificación
[1 *]
Las siguientes consideraciones se aplican a la

actividad de codificación construcción soft-
ware:
• Las técnicas para crear el código fuente

comprensible, incluyendo las convenciones
de nomenclatura y el diseño de código
fuente;
• El uso de clases, tipos enumerados,
variables, constantes con nombre, y otras
entidades similares;
• El uso de estructuras de control;
• Manipulación de las condiciones-tanto de
error anticipó y excepcional (entrada de
datos erróneos, por ejemplo);
• Prevención de las infracciones a nivel de
código de seguridad (desbordamientos de
búfer o límites índice de matriz, por
ejemplo);
• El uso de recursos a través de uso de
mecanis- y disciplina de exclusión meca-
para acceder a recursos en serie reutilizables
(incluyendo hilos y cerraduras de base de
datos);
• Organización del código fuente (en Estado-
3-10 Guía SWEBOK®
Construcción implicaV3.0
dos formas de pruebas,
que a menudo son realizadas por el Neer niería
de software que escribió el código:
• Examen de la unidad
• Pruebas de integración.
El propósito de las pruebas de la

construcción es el de reducir la brecha entre el
momento en que los fallos se insertan en el
código y el momento cuando se detectan los
fallos, reduciendo así el coste incurrido para
solucionarlos. En algunos casos, los casos de
prueba se escriben después del código ha sido
escrito. En otros casos, los casos de prueba
pueden crearse antes de código está escrito.
pruebas de construcción típicamente implica
un subconjunto de los diferentes tipos de
pruebas que se describen en el Testing de
Software KA. Por ejemplo, las pruebas de
construcción no suelen incluir las pruebas del
sistema, las pruebas alfa, pruebas beta, pruebas
de estrés, pruebas de configuración, las pruebas
de usabilidad, u otros tipos más especializados
de la prueba.
Dos normas se han publicado sobre el tema
de las pruebas de la construcción: Norma IEEE
829-1998, Norma IEEE para la Documentación
de software de prueba, y la norma IEEE 1008-
1987, IEEE estándar para el software de
pruebas unitarias.
(Ver secciones 2.1.1., Pruebas unitarias, y
2.1.2., Pruebas de integración, en el KA de
Pruebas de Software para el material de
referencia más especializado.)
3.5. Construcción de Reutilización

[2 *]
Construcción para su reutilización 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 multisistémica.
Construcción nueva utilización se basa
generalmente en el análisis y diseño de
variabilidad. Para evitar el problema de clones
de código, se desea encapsular fragmentos de
código reutilizables en bibliotecas o
componentes bien estructuradas.
Las tareas relacionadas con la construcción de
software para
reutilizar durante la codificación y las pruebas
son los siguientes:
11
• aplicación variabilidad con mecanismos • pruebas unitarias y pruebas de integración

tales como la parametrización, la (ver sec- ción 3.4, Pruebas de construcción)
compilación condicional, patrones de • prueba de primer desarrollo (ver sección 2.2
diseño, y así sucesivamente. en el
• encapsulación variabilidad para que los Pruebas de software KA)
activos software fácil de configurar y • uso de afirmaciones y programación
personalizar. defensiva
• Prueba de la variabilidad proporcionada por • depuración
los activos de software capaces Reus-. • inspecciones
• Descripción y publicación de software • revisiones técnicas, incluyendo comentarios
activos reutilizables. enteder-ori- seguridad (ver sección 2.3.2 en
la calidad KA Cesión de Software)
3.6. Construcción con reutilización • el análisis estático (véase la sección 2.3 de
[2 *] la Calidad KA Soft- Ware)
Construcción con reutilización significa crear un La técnica o técnicas específicas seleccionadas

nuevo software con la reutilización de activos de dependen de la naturaleza del software que se
software existentes. El método más popular de con- structed, así como en el conjunto de
reutilización es la reutilización de código de las habilidades de los ingenieros de software que
bibliotecas proporcionadas por el lenguaje, la realizan la construcción activi- lazos. Los
plataforma, las herramientas que se utiliza, o un programadores deben conocer las buenas
repositorio organizativa. Los apartes de estos, prácticas y comunes ejemplo vulnerabilidades-
las aplicaciones desarrolladas ampliamente hoy para, a partir de listas ampliamente reconocidos
hacen uso de muchas bibliotecas de código acerca de las vulnerabilidades comunes. análisis
abierto. Reutilizados y off-the-shelf software a estático automatizado de código para las
menudo tienen la misma o mejor calidad debilidades de seguridad está disponible para
requisitos como nuevo desarrollo de software varios lenguajes de programación mon com- y se
(por ejemplo, nivel de seguridad). puede utilizar en proyectos críticos para la
Las tareas relacionadas con la construcción de seguridad.
software con actividades de construcción de calidad
reutilizar durante la codificación y las pruebas diferenciada se ated de otras actividades de
son los siguientes: calidad por su enfoque. actividades de calidad de
la construcción se centran en código y artefactos
• La selección de las unidades reutilizables, que están estrechamente relacionados con
Data- bases, procedimientos de prueba, o código como el diseño, a diferencia de otros
datos de prueba. artefactos que están conectados directamente al
• La evaluación de código o prueba de menos el código, como los requisitos, diseños de
reutilización. alto nivel, y los planes detallados.
• La integración de los activos de software
reutilizables en el software actual. 3.8. Integración
• La presentación de la información [1 *]
reutilización de código nuevo, los
procedimientos de prueba o datos de prueba.
3.7. construcción de Una actividad clave durante la construcción es el

Calidad [1 ción integración de rutinas construidos
*] individualmente, clases, componentes y
subsistemas en un único sis-
Además de los fallos que resultan de los sólo los fallos en la funcionalidad de seguridad,
requisitos y de diseño, defectos introducidos sino también fallos en otras zonas que permiten la
durante la construcción pueden dar lugar a anulación de esta funcionalidad y otras
problemas graves de calidad -por ejemplo, las debilidades de seguridad o violaciónes.
vulnerabilidades de seguridad. Esto incluye no Existen numerosas técnicas para asegurar la
3-12 Guía
cali-SWEBOK®
dad de V3.0
código como se construye. Las TEM. Además, puede necesitar ser integrado
técnicas primarios utilizados para la calidad de con otros sistemas de software o hardware de un
la construcción incluyen sistema de software en particular.
Las preocupaciones relacionadas con la
integración de la construcción incluyen la
planificación de la secuencia en la que se
integrarán los componentes, la identificación 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
13
la determinación de puntos en el proyecto en el 4.2. Orientado a Objetos Problemas

que se prueban versiones provisionales del de tiempo de ejecución [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
integración por etapas, también llamada de mecanismos de ejecución que incluye el
integración “big bang”, implica retrasar la polimorfismo y la reflexión. Estos mecanismos
integración de las partes componentes de de ejecución aumentan la flexibilidad y
software hasta que todas las partes destinados a adaptabilidad de los programas orientados a
la liberación de una versión se han completado. objetos. El polimorfismo es la capacidad de un
la integración incremental se cree que ofrecen lenguaje para apoyar las operaciones generales
muchas ventajas sobre el tradicional por fases con- sin saber hasta que el tiempo de ejecución
de integración, por ejemplo, la ubicación de qué tipo de objetos concretos del software
error más fácil, 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
integración gradual, el ERS desarrollos escribir tiempo de ejecución (unión llamada dinámica).
y probar un programa en pequeños trozos y La reflexión 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 ejecución. La
como talones, los controladores y los objetos de reflexión permite la inspección de las clases,
imitación, por lo general se necesita para interfaces, campos y métodos en tiempo de
permitir la integración incrementales. Con la ejecución con- sin saber sus nombres en tiempo
construcción y la integración de una unidad a la de compilación. También permite la
vez (por ejemplo, una clase o componente), el instanciación en tiempo de ejecución de nuevos
proceso de construcción pueden proporcionar objetos y invocación de métodos que usan
información temprana a los desarrolladores y nombres de clase y método con parámetros.
clientes. Otras ventajas de la integración
incrementales incluyen la ubicación más fácil 4.3. Parametrización y Genéricos
error, la mejora de progreso Monitor-ing,
unidades probado más completamente, y así
sucesivamente.
[4 *]
4. Tecnologías de la
construcción tipos parametrizados, también conocidos como
genéricos (ADA, Eiffel) y plantillas (C ++),
4.1. Diseño y Uso de la API [3 permiten la definición de un tipo o clase sin
*] especificar todos los otros tipos que utiliza. Los
tipos no especificados son
Una interfaz de programación de aplicaciones las API generalmente duran más 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. Además 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 semántica) del uso API implica los procesos de ING
programa. Seleccionar-, el aprendizaje, las pruebas, la
diseño de la API debe tratar de hacer la API integración, y posiblemente se extiende API
fácil de aprender y memorizar, dar lugar a un proporcionadas por una biblioteca o trabajo marco
código legible, ser difícil de mal uso, fácil de (véase la sección 3.6, de la construcción con la
extender, ser completa, y mantener la reutilización).
compatibilidad con versiones anteriores. Como
3-14 Guía SWEBOK®
suministrado V3.0
como parámetros en el punto de
uso. Tros eterized tipos proporcionan una
tercera vía (además de la herencia de clases y
composición de objetos) para com- representar
comportamientos de software orientado a
objetos.
4.4. Afirmaciones, Diseño Por contrato, y

programación defensiva
[1 *]
Una afirmación es un predicado ejecutable que

se coloca en un programa de por lo general una
rutina o macro- que permite controles de
tiempo de ejecución del programa. ciones
aseveraciones son especialmente útiles en
programas alta fiabilidad. Ellos permiten a los
programadores para eliminar más rápidamente
los supuestos de interfaz que no coinciden, los
errores que se arrastran en cuando se modifica
el código, y así sucesivamente. Las
afirmaciones se obtiene generalmente en el
código en tiempo de desarrollo y
posteriormente se compilan fuera del código
para que no se degradan el rendimiento.
15
Diseño de contrato es un enfoque de excepciones al código de la biblioteca lanza, tal

desarrollo en los que las condiciones previas y vez la construcción de un reportero de excepción
condiciones posteriores se incluyen para cada centralizada, y la normalización 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 colección de técnicas
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 detección de errores y, a continuación se
proporciona una especificación precisa de la recupera de ellos si es posible
semántica de una rutina, y por lo tanto ayuda a la
comprensión de su comportamiento. Diseño de
contrato se cree que mejora la calidad de la
construcción de software.
La programación defensiva medios para
proteger a una rutina de ser roto por las entradas
no válidas. Las formas más comunes para
manejar las entradas no válidas incluyen la
comprobación de los valores de todos los
parámetros de entrada y decidir cómo manejar
las malas entradas. ciones aseveraciones son de
uso frecuente en la programación 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 atribuye no funcionales. Las
afirmaciones se utilizan a veces para comprobar
si hay errores. -Están mercancías también se
utilizan otras técnicas-tales de manejo de errores
como devolver un valor neutro, sustituyendo la
siguiente pieza de datos válidos, registrando un
mensaje de advertencia, devolver un código de
error, o el cierre de la soft-.
Las excepciones se utilizan para detectar y
errores de proceso o acontecimientos
excepcionales. La estructura básica de una
excepción es que un usos de rutina throw para
lanzar una excepción detectada y un bloque de
manipu- manipulan de excepción se captura la
excepción en un bloque try-catch. El bloque try-
catch puede procesar la condición errónea de la
rutina o puede devolver el control a la rutina de
llamada. políticas de manejo de excepciones
deben ser cuidadosamente diseñadas
seguimiento ing principios comunes como la
inclusión en el mensaje de excepción toda la
información que llevó a la excepción, evitando
los bloques catch vacías, conociendo las
3-16 Guía SWEBOK® V3.0 de procesos tecnológicos. la programación
o que contiene sus efectos si la recuperación no
es posible. Las estrategias de tolerancia a basada en el estado se suele combinar
fallos más comunes incluyen copias de
seguridad y de reintentar, utilizando el código
auxiliar, utilizando algoritmos de votación, y la
sustitución de un valor erróneo con un valor
falso que tendrá un efecto benigno.
4.6. ejecutable modelos

[5 *]
ejecutable modelos abstraer los detalles de los

lenguajes de programación específicos y las
decisiones sobre la organización del software.
Diferente de los modelos tradicionales de
software, una especificación 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
aplicación utilizando un conjunto de decisiones
sobre el hardware de destino y el entorno de
software. Por lo tanto, la construcción de
modelos ejecutables puede considerarse como
una forma de construir software ejecutable.
ejecutable modelos son una fundación
apoyando actividades de gestión de la
arquitectura dirigida por modelos (MDA)
iniciativa 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 solución a un problema
que no se basa en ningún tecnologías de
implementación. A continuación, un modelo de
plataforma específica (PSM), que es un modelo
que contenga los detalles de la tación aplica-,
puede ser producido por tejer el PIM y la
plataforma sobre la que se basa.
4.7. Las técnicas de construcción basadas en

tablas de base estatal y
[1 *]
de programación basado en el estado, o la

programación basada en autómatas, es una
tecnología de programación utilizando
máquinas de estado finito para describir
comportamientos del programa. Los gráficos
de transición de una máquina de estados se
utilizan en todas las etapas de desarrollo de
software (especificación, implementación, ging
debug-, y documentación). La idea principal es
la construcción de programas de ordenador de
la misma manera se realiza la automatización
17
con la programación orientada a objetos,

formando un nuevo enfoque compuesto llamado, procesamiento de entrada basado en la gramática
programación orientado a objetos basado en implica el análisis de sintaxis, o análisis
estado. sintáctico, de la corriente de token de entrada. Se
Un método de la tabla impulsado es un trata de la creación de una estructura de datos
esquema que utiliza tablas para buscar (llamado un árbol de análisis sintáctico o árbol de
información en lugar de utilizar los estados sintaxis) que representa los datos de entrada. El
lógicos (por ejemplo, si y caja). Se utiliza en las recorrido en orden de aliado del árbol de análisis
circunstancias apropiadas, claves basadas en no baja da la expresión se acaba de analizar. El
tablas es más simple que la lógica complicada y analizador comprueba la tabla de símbolos para la
más fácil de modificar. Al utilizar métodos presencia de
basadas en tablas, el programador se centra en
dos cuestiones: qué tipo de información a
almacenar en la tabla o tablas, y cómo eficiente
información de acceso en la tabla.
4.8. Configuración de tiempo

de ejecución y la
internacionalización
[1 *]
Para lograr una mayor flexibilidad, un programa

a menudo se construye para soportar el tiempo
de unión finales de sus Ables variabilidad.
configuración de ejecución es una técnica que
une los valores de variables y ajustes del
programa cuando el programa se está
ejecutando, por lo general mediante la
actualización y la lectura de los archivos de
configuración en un modo justo a tiempo. La
internacionalización es la actividad técnica de
la preparación de un programa, generalmente
software interactivo, para soportar múltiples
lugares. La actividad correspondiente,
localización, es la actividad de la modificación
de un programa de apoyo a un idioma local
específica. 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 diseño y construcción 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, cómo mantener las cuerdas sin cambiar el
código, y traducir las cadenas en diferentes
idiomas con un impacto mínimo en el
código de procesamiento y la interfaz de
usuario.
4.9. Procesamiento de la entrada Gramática-

Basado
[dieciséis*]
las variables definidas por el programador que
pueblan el árbol. Después de construir el árbol
de análisis, el programa utiliza como entrada a
los procesos computacionales.
4.10. Las primitivas de concurrencia

[7 *]
Una primitiva de sincronización es una

abstracción de programación proporcionada
por un lenguaje de programación o el sistema
operativo que facilita rencia concurrente y
sincronización. Conocidos primitivas RENCIA
concurrentes incluyen semáforos, monitores y
exclusiones mutuas.
Un semáforo es un tipo de datos variable o
extracto protegida que proporciona un simple
pero útil abstracción para controlar el acceso a
un recurso común por múltiples procesos o
hilos en un entorno de programación
concurrente.
Un monitor es un tipo de datos abstractos que
presenta un conjunto de operaciones definidas
por el programador que se ejecutan con la
exclusión mutua. Un monitor de con- tains la
declaración de variables compartidas y
cedimientos o funciones pro que operan en esas
variables. El constructo del monitor asegura que
sólo un proceso a la vez es activo dentro del
monitor. Un mutex (exclusión mutua) es un sin-
cronización primitiva que permite el acceso
exclusivo a un recurso compartido por sólo un
proceso o hilo en
un momento.
4.11. middleware
[3 *] [6 *]
Middleware es una amplia clasificación de

software que proporciona servicios por
encima de la capa del sistema operativo
todavía por debajo de la capa de programa de
aplicación. Middleware puede proporcionar
ERS tiempo de ejecución contención de
componentes de software para proporcionar el
paso de mensajes, la persistencia, y una
ubicación transparente a través 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
ción y la comunicación entre múltiples
aplicaciones de software interacción
orientada al servicio.
11
4.12. Métodos de construcción de software algoritmo de selección-influye en una velocidad

distribuido y el tamaño ejecución. Análisis de rendimiento
[7 es la investiga- ción de la conducta de un
*] programa utilizando informa- ción se reunieron
como el programa se ejecuta, con el
Un sistema distribuido es una colección de siste- 4.14. Análisis de Rendimiento y ajuste
mas informáticos físicamente separados, [1 *]
posiblemente heterogéneos que están conectados
en red para proporcionar a los usuarios el acceso eficiencia-determinado código en la arquitectura,
a los diversos recursos que mantiene el sistema. las decisiones de diseño detallado, y la estructura
Construcción de software distribuido se de datos y
distingue de software tradicional trucción ción
por cuestiones tales como paralelismo, comu-
nicación, y tolerancia a fallos.
Repartido programación típicamente cae en
una de varias categorías arquitectónicos básicos:
cliente-servidor, arquitectura arquitectura de 3
capas, de n niveles, dis- objetos Tributado, de
acoplamiento suelto, o estrecho acoplamiento
(véase la sección 14.3 de los fundamentos
Informática KA y la sección 3.2 de la Diseño de
software KA).
4.13. La construcción de sistemas heterogéneos

[6 *]
sistemas heterogéneos consisten en una variedad

de unidades de computación especializados de
diferentes tipos, tales como procesadores de
señal digital (DSPs), controladores de
microorganismos, y los procesadores periféricos.
Estas unidades de cómputo se controlan
independientemente y se comunican entre sí.
Los sistemas embebidos son típicamente
sistemas heterogéneos.
El diseño de sistemas heterogéneos puede
requerir la combinación de varios lenguajes de
especificación para el diseño de diferentes partes
del sistema, en otras palabras, codesign de
hardware / software. Los temas clave incluyen la
validación en varios idiomas, co-simulación e
interfaz.
Durante el codiseño hardware / software,
desarrollo de software y hardware de desarrollo
virtual de proceder simultáneamente a través de
la descomposición gradual. La parte hardware
generalmente se simula en el campo de las
matrices de puertas programables (FPGAs) o
circuitos integrados de aplicación específica
(ASIC). La parte de software se traduce en un
lenguaje de programación de bajo nivel.
3-12 Guía SWEBOK®
objetivo V3.0
de identificar posibles puntos calientes
en el programa a ser mejorado.
Código de sintonía, lo que mejora el
rendimiento a nivel de código, es la práctica de
modificar el código correcto en formas que
hacen que funcione más eficientemente.
Código de sintonía por lo general implica sólo
cambios a pequeña escala que afectan a una
sola clase, una sola rutina, o, más comúnmente,
unas pocas líneas de código. Un amplio
conjunto de técnicas de optimización de código
está disponible, INCLUYENDO las de
sintonización expresiones lógicas, bucles,
transformaciones de datos, expresiones, y
rutinas. El uso de un lenguaje de bajo nivel es
otra téc- nica común para la mejora de algunos
puntos calientes en un programa.
4.15. Normas de plataforma

[6 *] [7 *]
estándares de la plataforma permiten a los

programadores a desarrollar aplicaciones
portátiles que se pueden ejecuta en entornos
compatibles sin cambios. estándares de la
plataforma por lo general implican un conjunto
de servicios estándar y API que compa-
implementaciones de plataforma ible deben
implementar. Ejemplos típicos de estándares de
la plataforma son de Java
2 Platform Enterprise Edition (J2EE) y el
estándar POSIX para sistemas operativos
(Portable Operating System Interface), que
representa un conjunto de normas
implementadas principalmente para sistemas
operativos basados en UNIX.
4.16. Programación Test-First

[1 *]
Ensayos primera programación (también

conocido como Test-Driven Development-
TDD) es un estilo de desarrollo popular en la
que los casos de prueba se escriben antes de
escribir ningún código. programación de
pruebas en primer lugar por lo general puede
detectar defectos antes y corregirlos con más
facilidad que los estilos de programación
tradicionales. Por otra parte, la escritura casos
de prueba primeras fuerzas pro-programadores
a pensar acerca de los requisitos y el diseño
antes de la codificación, exponiendo así a los
requerimientos y problemas de diseño más
pronto.
13
5. Herramientas de software 5.3. Herramientas de

de construcción prueba de unidad [1 *] [2
*]
5.1. Entornos de desarrollo Prueba de la unidad verifica el funcionamiento
[1 de los módulos 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 construcción mediante la unidad y los marcos para extender y crear
integración 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 construcción de software. prueba para verificar la exactitud de la unidad
En adicional a las funciones básicas de bajo variabilidad conjuntos de datos ous. Cada
edición de código, entornos de desarrollo prueba individual se implementa como un
modernos a menudo ofrecen otras características objeto, y un corredor de prueba se ejecuta todas
como la compila- ción y detección de errores las pruebas. Durante la ejecución de la prueba,
desde dentro del editor, la integración con el los casos de prueba fallidos serán marcados e
control de código fuente, construir herramientas informaron de forma automática.
de depuración / test /, comprimido o delinear
puntos de vista de los programas, código 5.4. Perfilado, análisis de rendimiento, y cortar
automatizado transforma y soporte para la Herramientas
refactorización. [1 *]
5.2. herramientas de análisis de rendimiento se

Constructores [1 utilizan generalmente para apoyar la
GUI *] sintonización código. Las herramientas de
análisis per- formance más comunes son
herramientas de perfiles. Un
Un constructor de GUI (Graphical User requeridas para el manejo de eventos. El código
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 gráficas de usuario en un proporcionan la lógica de la aplicación.
WYSI- WYG (lo que ves es lo que obtienes) de Algunos entornos de desarrollo modernos
modo. Un constructor de interfaz gráfica de proporcionan constructores GUI integradas o
usuario por lo general incluye un editor visual constructor GUI plug-ins. También hay muchos
para el desarrollador para diseñar formas y constructores GUI independientes.
ventanas y gestionar la distribución de los
widgets por Arrastrando, goteo y ajuste de
parámetros. Algunos constructores GUI pueden
generar automáticamente el código fuente
correspondiente a la interfaz gráfica de diseño
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 generación de código,
que automatizan las tareas más repetitivas
3-14 Guía SWEBOK®
herramienta V3.0
de ejecución de perfiles supervisa
el código mientras se ejecuta y registra el
número de veces que se ejecuta cada
instrucción o cuánto tiempo el programa pasa
en cada ruta declaración o ejecución. Pro-
presentación del código mientras se está
ejecutando da una idea de cómo funciona el
programa, donde están los puntos calientes, y
donde los desarrolladores deben centrarse los
esfuerzos de optimización de código.
rebanar programa implica el cálculo del
conjunto de instrucciones de programa (es
decir, el programa de rebanada) que pueden
afectar a los valores de las variables
especificadas en algún punto de interés, que se
conoce como un criterio de fragmentación.
rebanar programa puede ser utilizado para la
localización de la fuente de errores, programa
de comprensión, y análisis de optimización.
herramientas de corte en lonchas programa
computan las rebanadas de programas para
varios lenguajes de programación que utilizan
métodos de análisis estáticos o dinámicos.
15
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 construcción de
software
c2, c3,
C7-C9,
1.1. minimizando
c24,
Complejidad
c27,
c28,
c31,
C3-C5,
1.2. pronóstico c32, c34
C24,
del cambio
C31,
C32,
c8,C34
1.3. La construcción C23
de C20,
Verificación C31,
1.4. Reutilizar c34 c16
1.5. Normas de
c4
construcción
2. Gestión de la
Construcción
2.1. construcción en C2, C3,
Modelos de Ciclo de C27,
Vida C29
c3, c4,
2.2. Ordenación
c21,
de la Edificación
c27-c29
2.3. Construcción
c25, c28
Medición
3.
Consideracion
es 3.1.
prácticas
Diseño de la C3, C5,
construcción C24
3.2. Construcción
c4
idiomas
C5-
3.3. Codificación
C19,
C25-
C26

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
construcción
3.5. Construcción de
c16
Reutilización
3.6.
c16
Construcción
con
3.7. reutilización
Construcción c8,
Calidad C20-C25
3.8. Integración c29
4. Tecnologías de
la Construcción
4.1. Diseño APIy use
c7
4.2. Orientado a
C6, C7
Objetos Problemas
de
4.3.tiempo de
ejecución
parametrización c1
y genéricos
4.4. Afirmaciones,
Diseño por
C8, C9
contrato, y la
programación
defensiva
4.5. Control de
errores, control de C3, C8
excepciones, y la
tolerancia a fallos
4.6. Ejecutable
c1
modelos
4.7. Las técnicas
de construcción
c18
basadas en tablas
de base estatal y
4.8. Configuración
de tiempo de C3, C10
ejecución y la
internacionalizació
4.9. Procesamiento
nde la entrada c5 c8
Gramática-Basado
17

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. Métodos de
construcción de c2
software distribuido
4.13. La
construcción de C9
sistemas
heterogéneos
4.14. Análisis de
c25, c26
Rendimiento y
ajuste
4.15. Normas
c10 c1
de plataforma
4.16. Ensayos
c22
Primera
5. Programación
Instrumento de
construcción
5.1. Entornos de
c30
desarrollo
5.2. Constructores c30
GUIExamen de
5.3.
c22 c8
la unidad
Herramientas
5.4. Perfilado,
análisis de
c25, c26
rendimiento,y
Herramienta
s de cortado
LECTURAS Referencias
IEEE Std. 1517-2010 estándar para la [1 *] S. McConnell, código completo, 2ª ed.,

tecnología de la información del sistema y Microsoft Press, 2004.
del software-Vida Procesos de reutilización
de procesos de ciclo, IEEE, 2010 [8]. [2 *] I. Sommerville, Ingeniería de Software, 9ª
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 documentación: Arquitecturas. Vistas y más
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 reutilización [4 *] E. Gamma et al, patrones de diseño:..
y los procesos de construcción de reutilización y Elementos de software orientado a objetos
la construcción con la reutilización. reutilizables, 1st ed, Addison-Wesley
Professional, 1994.
IEEE Std. 12207-2008 (también conocido como
ISO / IEC [5 *] SJ Mellor y MJ Balcer, ejecutable UML:.
12207: 2008) estándar para los sistemas y Una Fundación para el Model-Driven
software de ingeniería en software procesos Architecture, 1st ed, Addison-Wesley,
de ciclo de vida, IEEE, 2008 [9]. 2002.
Este estándar define una serie de software los [6 *] L. y J. nulo Lobur, Lo Esencial de la
procesos de desarrollo, incluyendo el software Organización de Computadores y
de construc- ción proceso, el proceso de Arquitectura, 2ª ed., Jones and Bartlett
integración de software, y el software de proceso Publishers, 2006.
de reutilización.
[7 *] A. Silberschatz, PB Galvin, y G. Gagne,
Operating System Concepts, octava ed.,
Wiley, 2008.
[8] IEEE Std. 1517-2010 estándar para la

Tecnología de la Información-sistema y la
duración del ciclo de Procesos de Software
de reutilización de Procesos, IEEE 2010.

como ISO / IEC
software de ingeniería en software procesos
de ciclo de vida, IEEE 2008.
19
CAPÍTULO
PRUEBA 4
SOFTWARE
KA. Vale la pena señalar que la terminología

SIGLAS gía no es uniforme entre las diferentes co-
API Application Program Interface munidades y algunos utilizan el término
“prueba” también en referencia a las técnicas
TDD Desarrollo basado en pruebas estáticas.
TTCN3
Pruebas y de control de pruebas de • Finito: Incluso en los programas simples, por
notación lo que muchos casos de prueba son
XP La versión 3 extrema
Programación teóricamente posible que las pruebas tivo
tamiento podría requerir meses o años
INTRODUCCIÓN
Las pruebas de software consiste en la verifica-

ción dinámica que ofrece un programa de
comportamientos esperados en un conjunto
finito de casos de prueba, adecuadamente
seleccionados a partir del dominio de ejecución
generalmente infinita.
En la definición anterior, palabras en cursiva
uso corresponden a cuestiones clave en la
descripción del área de conocimiento de Pruebas
de Software (KA):
• Dinámica: Este término significa que las

pruebas siempre implica la ejecución 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 podría reaccionar a la misma
entrada con comportamientos diferentes,
dependiendo del estado del sistema. En este
KA, sin embargo, el término “entrada” se
mantendrá, con la conven- ción implícita
que su significado también incluye un
estado de entrada fied speci- en aquellos
casos en los que es importante. técnicas
estáticas son diferentes de y complementaria
a la prueba dinámica. técnicas estáticas
están cubiertos en la calidad del software
siempre es fácil, para decidir si los
ejecutar. Es por esto que, en la práctica, un resultados observados de las pruebas del
conjunto completo de pruebas puede programa son aceptables o no; de lo
considerarse generalmente infinita, 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 (comúnmente conocidas como
priorización. Las pruebas siempre implica pruebas de validación), contra un ficación
un equilibrio entre los recursos y los speci- (prueba para la verificación), o, haps
horarios, por un lado limitados y los per-, contra el comportamiento esperado de
requisitos de prueba inherentemente los requisitos implícitos o expectativas (ver
ilimitadas, por el otro. pruebas de aceptación en el software de los
• Seleccionado: Las muchas técnicas de requisitos KA).
prueba propuestos difieren esencialmente
en cómo se selecciona el equipo de En los últimos años, 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 selección pueden producir muy actividad que se inicia sólo después de la fase de
diferentes grados de efectividad. Cómo codificación se completa con el propósito
identificar el criterio de selección más limitado de fallos de detección. Las pruebas de
adecuado bajo condiciones dadas es un software es, o debería ser, omnipresente en todo
problema complejo; en la práctica, se el ciclo de desarrollo y mantenimiento de la
aplican técnicas de análisis de riesgos y la vida. De hecho, la planificación de las pruebas
ingeniería 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
Figura 4.1. Desglose de temas para las Pruebas de Software KA
y los planes y procedimientos de prueba deben proporcionar información acerca de la

ser System- que avanza el desarrollo de software funcionalidad
refinados como Bly-lidades ticamente y
continuamente desarrollados y. Estas actividades
de planificación y el diseño de prueba de la
prueba proporcionan información útil para los
diseñadores de software y ayudan a poner de
relieve las debilidades potenciales, como
descuidos de diseño / contradicciones u
omisiones / ambigüedades en la documentación.
Para muchas organizaciones, el enfoque de la
calidad software es una de prevención: 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
también para la identificación de fallas en
aquellos casos en los que la prevención de
errores no ha sido eficaz. Es quizás obvio, pero
vale la pena reconocer que el software todavía
puede contener errores, incluso después de la
finalización de una extensa actividad de la
prueba. Los fallos de software riencia rienced
después del parto se abordan mediante el
mantenimiento correctivo. temas de
mantenimiento de software están cubiertas en
el mantenimiento del software KA.
En la calidad del software KA (ver Técnicas
para el control de calidad de software), técnicas
de gestión de la calidad del software se
clasifican principalmente en técnicas estáticas
(sin ejecución de código) y
técnicas dinámicas (la ejecución de código). 1. Fundamentos de pruebas de software

Tanto catego- rías son útiles. Esta KA se centra
en técnicas dinámicas. 1.1. Las pruebas relacionada Terminología
Las pruebas de software también está
relacionado con la construcción de software (vea 1.1.1. Definiciones de Pruebas y
Pruebas de construcción en el KA Construcción terminología relacionada
de Software). En particular, la unidad y pruebas [1 *, c1, c2] [2 *,
de integración están íntimamente relacionados c8]
con la construcción de software, si no es parte de
ella. Definiciones de pruebas y terminología
relacionados con las pruebas se proporcionan en
DISTRIBUCIÓN 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

Exámenes KA se muestra en la Figura 4.1. Un vs. [1 *, c1s5] [2 *, c11]
desglose más detallado se proporciona en la
Matriz de Temas
vs Material de referencia al final de este KA. El Varias técnicas de prueba se han desarrollado
primer tema se describen pruebas de software en las últimas décadas, y todavía se están
Fun- proponiendo nuevas. técnicas generalmente
damentals. Cubre las definiciones básicas en el aceptadas están cubiertos en el tercer tema.
campo de pruebas de software, la terminología Las medidas de prueba relacionados se tratan en
básica 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 están 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
específicas o propiedades 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 cómo 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
composición, que los casos de prueba deberían
seleccionarse para lograr el objetivo indicado (
aunque por lo general “para lograr el objetivo
declarado” queda implícita y sólo 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 selección de las pruebas.
Muchos términos se utilizan en la literatura de Software de Pruebas
4-5
ingeniería de software para describir un mal
funcionamiento: Fallo sobre todo, el fracaso y
el error, entre otros. Este gía terminología se
define precisamente en [3, c2]. Es esencial
distinguir claramente entre la causa de un mal
funcionamiento (para el que se utilizará el fallo
término aquí) y un efecto no deseado
observado en servicio entregado del sistema
(que se llama un fallo). En efecto bien puede
haber fallos en el software que nunca se
manifiestan como fracasos (ver limitaciones
teóricas y prácticas de pruebas en la sección
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 más
genérico término puede ser utilizado para hacer
referencia a un fallo o un fracaso, cuando la
distinción no es importante [3]. Sin embargo,
se debe reconocer que la causa de un fallo no
siempre puede ser inequívocamente identi-
ficados. No existen criterios teóricos para
determinar definitivamente, en general, el fallo
que provocó un fallo observada. Podría decirse
que era la falla que tuvo que ser modificado
para eliminar el fallo, pero otras
modificaciones podría haber funcionado igual
de bien. Para evitar la ambigüedad, se podría
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 selección /

Criterios prueba de adecuación (Reglas de
parada)
[1 *, c1s14, c6s6, c12s7]
Un criterio de selección de la prueba es un

medio de selección de casos de prueba o la
determinación de que un conjunto de casos de
prueba
es suficiente para un propósito determinado. en este sentido es el aforismo Dijkstra que “las
Prueba criterios quacy ade- se pueden utilizar pruebas programa 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 terminación en la sección mostrar su ausencia” [5]. La razón obvia de esto
5.1, las consideraciones prácticas). 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 función del riesgo [6,
para las pruebas parte 1] y puede ser visto como una estrategia de
gestión de riesgos.
[1 *, c11s4, c13s11] 1.2.6. El problema de no factibles Caminos
[1 *,
Ensayos sobre la eficacia se determina mediante c4s7]
el análisis de un conjunto de ejecuciones del
programa. Selección de las pruebas que se caminos no factibles son trayectorias de flujo de
ejecutarán puede ser guiado por diferentes control que no pueden ser ejercidos por
objetivos: es sólo 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 derivación automática
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 detección de defectos, una
prueba exitosa
es la que hace que el sistema falle. Esto es
bastante diferente de las pruebas para demostrar la teoría 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 más establecidos de la teoría 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 más famosa
1.2.4. El problema de Oracle
[1 *, c1s9,
c9s7]
Un oráculo es cualquier ser humano o agente

mecánico 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 diferentes de oráculos “fracaso”.; por
ejemplo, las especificaciones inequívocas
requisitos, modelos de comportamiento, y las
anotaciones de código. La automatización de los
oráculos mecanizadas puede ser difícil y
costoso.
1.2.5. Limitaciones teóricas y prácticas de las

Pruebas
[1 *,
c2s7]
El término “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 estadísticamente, que un
conjunto de casos de prueba se exponga un
fracaso si el software es defectuoso. Ambos
significados son importantes.
1.3. Relación de las pruebas a otras actividades
Las pruebas de software se relaciona con, pero

diferente de, estático técnicas de gestión de la
calidad del software, Pruebas de corrección,
depuración y construcción 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 estáticas vs. Calidad de Software

Hombre- Técnicas agement (Ver Técnicas
de Gestión de la Calidad de Software en la
calidad del software KA [1 *, c12]).
• Las pruebas de exactitud frente a pruebas y
verificación formal (ver los modelos de
ingeniería de software y métodos KA [1 *,
c17s2]).
• Prueba vs. Depuración (ver pruebas de la
construcción en la construcción del
software KA y herramientas de depuración
y técnicas en los cimientos Informática
KA [1 *, c3s6]).
• Prueba vs. Programa de Construcción (ver hilos funcionales. Las pruebas de integración es
pruebas de la construcción en la a menudo una actividad continua en cada etapa
construcción 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 están inte- grando. Para que
Las pruebas de software se realiza generalmente no sea el software pequeño, sencillo, estrategias
en niveles diferentes procesos en todo el de pruebas de integración incrementales son el
mantenimiento 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 módulo menudo con el software quía chically
individual, un grupo de tales módulos estructurado.
(relacionadas por finalidad, uso, , estrategias de integración sistemáticas
comportamiento, o estructura), o todo un modernas son típicamente arquitectura dirigida,
sistema. Tres etapas de la prueba se pueden que consiste en integrar progresivamente los
distinguir: unidad, inte- gración, y el sistema. componentes o subsistemas de software basado en
Estas tres etapas de prueba no implican ningún com- identificado
modelo de proceso, ni es uno cualquiera de ellos
se supone que es más 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 podrían ser los subprogramas
individuales o un componente más grande hecha
de unidades altamente cohesivos. Típicamente,
la unidad de pruebas se produce con acceso al
código siendo probado y con el apoyo de
herramientas de depuración. Los programadores
que escribieron el código típicamente, pero no
siempre, las pruebas unitarias conducta.
2.1.2. Pruebas de integración

[1 *, c7] [2 *, c8]
Las pruebas de integración es el proceso de

verificar las interacciones entre los componentes
de software. estrategias de pruebas de
integración Sical cla-, como el de arriba hacia
abajo y de abajo hacia arriba, se utilizan a
pruebas de integración 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 seguridad,
velocidad, precisión y fiabilidad (ver requisitos
funcionales y no funcionales en los requisitos
de software y software KA calidad en el
Requisitos La calidad del software KA).
interfaces externas a otras aplicaciones,
utilidades, dispositivos de hardware, o los
entornos operativos también 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 específicos, que se indican más o menos
explícitamente y con diferentes grados de
precisión. La indicación de los objetivos de la
prueba en términos precisos, cuantitativos
apoya la medición y el control del proceso de
prueba.
Pruebas puede ser destinado a verificar
diferentes propiedades. Los casos de prueba
pueden ser diseñados 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 corrección, 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 características de
calidad de la calidad del software KA).
Otros objetivos importantes para el ensayo
incluyen
pero no se limitan a la medición de fiabilidad,
identificación de las vulnerabilidades de 2.2.4. Logro fiabilidad y Evaluación

seguridad, evaluación de la usabilidad y la [1 *, c15] [2 *,
aceptación de software, por lo que sería tomado c15s2]
diferentes enfoques. Tenga en cuenta que, en
general, los objetivos de la prueba varían según Las pruebas mejora la fiabilidad mediante la
el destino de la prueba; propósitos diferentes se identificación y corrección de fallos. Además,
dirigen a diferentes niveles de pruebas. las medidas estadísticas de fiabilidad se pueden
Los subtemas que figuran a continuación son derivar por casos de prueba ing generat-
los más 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 más apropiados para las pruebas de software operativo en la sección 3.5, Técnicas de uso-
paquetes de instalación 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 aceptación / Calificación evaluación de fiabilidad en la sección 4.1,
[1 *, c1s7] [2 *, c8s4] Evaluación del Programa bajo Test).
2.2.5. Pruebas de regresión

[1 *, c8s11,
Las pruebas de aceptación / calificación c13s3]
determina si un sistema cumple con sus criterios
de aceptación, por lo general mediante la De acuerdo con [7], pruebas de regresión es la
comprobación de los comportamientos deseados “repetición 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 práctica, el enfoque es demostrar que las
consumo, que la organización 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, también se refiere a las pruebas de
no implicar los desarrolladores del sistema. progresión como nonre- veces). Para el
desarrollo incremental, el propósito de las
2.2.2. Prueba de la instalación pruebas de regresión es mostrar que el
[1 *, c12s2] comportamiento del software no se ha
modificado por los cambios graduales en el
A menudo, después de la finalización del software, excepto en la medida en que debería.
sistema y pruebas de aceptación, el software se En algunos casos, una solución de compromiso
verifica después de la instalación en el entorno debe hacerse entre la garantía dada por regresión
de destino. las pruebas de instalación 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 regresión, que puede ser bastante
hardware ciones y otras limitaciones tiempo, debido al gran número de pruebas que
operacionales. procedimientos de instala- ción pueden ser ejecutados. Las pruebas de regresión
también 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 existentes
[1 *, c13s7, c16s6] [2 *, c8s4] [8]. Las pruebas de regresión puede ser con-
conductos en cada uno de los niveles de ensayo
descritos en sec- ción 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
pequeño y selecto grupo de usuarios potenciales rendimiento [1 *, c8s6]
para el uso de prueba (pruebas alfa) y / o a un
conjunto más 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 están funcionamiento específicos y evalúa
controlados y no siempre se hace referencia en características de rendimiento-por ejemplo, la
un plan de pruebas. capacidad y el tiempo de respuesta.
2.2.7. Pruebas de 2.2.12. Prueba de

seguridad [1 *, c8s3] [2 *, c11s4] configuración [1 *, c8s5]
Las pruebas de seguridad se centra en la En los casos donde el software se construye para
verificación de que el software está protegido de servir a diferentes usuarios, pruebas de
ataques externos. En particular, las pruebas de configuración 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 verificación contra el mal uso y el de la acción
abuso de la cerámica o el sistema (pruebas [10 *, c6]
negativas) blandas.
2.2.8. Pruebas de La tarea principal de la usabilidad y las pruebas

estrés [1 *, interacción persona-ordenador es evaluar lo fácil
c8s8] que es para los usuarios finales para aprender y
utilizar el software. En
Las pruebas de estrés ejerce de software en la en general, puede implicar pruebas del software
carga máxima de diseño, así como más allá de funciones que soporta las tareas del usuario, la
ella, con el objetivo de determinar los límites de documentación 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 críticos. errores del usuario (ver diseño de la interfaz de
usuario en el software de diseño 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- ción de los
IEEE / ISO / IEC Standard 24765 define las parámetros 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 más variantes de un programa se definición 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 recuperación

[1 *, c14s2]
las pruebas de recuperación está dirigido a

comprobar la capacidad de reinicio de software
después 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 sistemas

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- ción. Por
lo general, los casos de prueba se generan a
partir de la especificación de interfaz. Un
objetivo específico de pruebas de la interfaz es
3. Prueba técnicas Software de Pruebas
4-13
Uno de los objetivos de la prueba es detectar la

mayor cantidad posible de fallos. Muchas
técnicas se han desarrollado para hacer esto [6,
parte 4]. Estas técnicas intentan “romper” un
programa por ser Tematic como sis- como sea
posible en la identificación 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 clasificación de las técnicas de prueba pre
SENTED aquí se basa en cómo se generan las
pruebas: desde la intuición del ingeniero de
software y experiencia, las especificaciones,
la estructura del código, las faltas reales o
imaginarios a ser descubiertos, el uso previsto,
modelos, o la naturaleza de la aplicación. Una
categoría se refiere a la utilización combinada
de dos o más técnicas.
A veces, estas técnicas se clasifican como de
caja blanca (también llamada caja de vidrio), si
las pruebas se basan en la información sobre la
forma en que el software ha sido diseñado 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 técnicas de prueba
que se utilizan normalmente, pero algunos
médicos se basan en algunas de las técnicas
más que otros.
3.1. Sobre la base de la intuición 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 técnica que más se practica es la combinación 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
intuición y experiencia con programas
similares. pruebas Ad hoc puede ser útil para
identificar las pruebas casos que no generan
fácilmente por técnicas más formales.
3.1.2. Prueba exploratoria
pruebas exploratorias se define como

aprendizaje simultáneo, diseño de la prueba, y
ejecución de la prueba [6, parte 1]; es decir, las
pruebas no se definen por adelantado en un plan
de pruebas establecido, pero están diseñados de
forma dinámica, 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 aplicación, la
plataforma, el proceso falla, el tipo de fallas y
fracasos posible, el riesgo asociado con un
producto en particular, y así sucesivamente.
3.2. Las técnicas basadas en el dominio de

entrada
3.2.1. Partición de equivalencia

[1 *,
c9s4]
partición de equivalencia implica la partición del

dominio de entrada en una colección de
subconjuntos (o clases Alent valente) en base a
un criterio especificado o con relación. Este
criterio o relación pueden ser diferentes
resultados computacionales, una relación basada
en el flujo de control o flujo de datos, o una
distinción entre entradas válidas que son
aceptados y procesados por el sistema y las
entradas no válidas, 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 sólo 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 también incluye flujo de control de entrada-salida-a en el gráfico
combinaciones de más alto nivel que los pares: de flujo de control de un programa. Dado que las
estas técnicas se denominan t-sabia, con lo que pruebas de ruta exhaustiva por lo general no es
se considera cada combinación posible de las factible debido a
variables de entrada t.
3.2.3. Análisis de valores en la frontera

[1 *, c9s5]
Los casos de prueba son elegidos en o cerca de

los límites del dominio de las variables de
entrada, con la lógica subyacente que muchos
fallos tienden a concentrarse cerca de los
valores extremos de entradas. Una extensión de
esta técnica es la prueba de solidez, en el que
los casos de prueba se eligen también fuera del
dominio de entrada de variables a robustez
programa de prueba en el procesamiento de
entradas inesperadas o erróneos.
3.2.4. Pruebas al azar

[1 *, c9s7]
Las pruebas se generan puramente al azar (que

no debe confundirse con la prueba estadística
del perfil funcional, como se describe en
perfil operativo en la sección 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 automatización 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 selección de entrada [11]. las
pruebas de la pelusa o la formación 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. Técnicas de código-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 más fuerte de los criterios
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-
DICIÓN / pruebas de decisión. La adecuación de En adivinar de error, los casos de prueba están
estas pruebas se mide en porcentajes; por diseñados específicamente por los ingenieros de
ejemplo, cuando todas las ramas se han software que intentan anticipan las fallas más
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 información 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
mutación [1 *, c3s5]
En las pruebas basadas en el flujo de datos, el
gráfico de flujo de control
está anotado con información sobre cómo se Un mutante es una versión ligeramente
definen las variables del programa, utilizados y modificada del programa bajo prueba, que
asesinados (sin definir). El criterio más fuerte, difiere de ella por un pequeño cambio sintáctico.
todos los caminos definición 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 identificación de
una definición de esa variable a un uso de esa la diferencia entre el programa y un mutante, se
definición. Con el fin de reducir el número de dice que este último sea concebido
caminos necesarios, se emplean estrategias más originalmente como una técnica para evaluar la
débiles tales como todo-definiciones y todos los prueba “muerto”. conjuntos (véase la sección
usos. 4.2. Evaluación de las pruebas realizadas),
pruebas ción mutatis es también un criterio de
3.3.3. Modelos de referencia de las pruebas prueba en sí mismo: o bien pruebas se generan
basadas en el Código aleatoriamente hasta que suficientes mutantes
[1 *, c4] han muerto, o pruebas están diseñadas
específicamente para matar mutantes
Aunque no es una técnica en sí misma, la supervivientes. En este último caso, las pruebas
estructura de control de un programa puede ser de mutación también puede ser categorizado
gráficamente representadas usando un gráfico como una técnica basada en el código. La
de flujo para visualizar técnicas de ensayo suposición subyacente de pruebas de mutación,
basadas código-. Un gráfico de flujo es un grafo el efecto de acoplamiento, es que mediante la
dirigido, los nodos y arcos de los cuales búsqueda de fallos sintácticos simples, se
corresponderse a elementos (ver gráficos y los encontraron defectos más complejos pero reales.
árboles en los fundamentos matemáticos KA) Para que la técnica sea eficaz, un gran número
programar. Por ejemplo, los nodos pueden de mutantes debe ser generado y ejecutado de
representar declaraciones o secuencias forma sistemática [12] automáticamente.
ininterrumpidas de estados, y los arcos pueden
representar la transferencia de control entre los 3.5. Técnicas de uso-Basado
nodos.
3.5.1. Perfil operativa
[1 *, c15s5]
3.4. Técnicas basada en la
culpa [1 *, En las pruebas para la evaluación de la fiabilidad
c1s14] (también llamado
pruebas de funcionamiento), el entorno de prueba
repro-
Con diferentes grados de formalización, técnicas prueba específica- mente destinados a revelar
de ensayo basadas culpa- diseñar casos de categorías de fallos probables o predefinidas. Para
enfocar mejor la generación de casos de prueba duce el entorno operativo de Software
la soft- de Pruebas
ware, o el
4-17
o de selección, un modelo de fallo puede ser perfil operativo, lo más 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
función de su frecuencia de ocurrencia en la
operación real. perfiles funcional se pueden
utilizar durante la prueba del sistema
para guiar derivación de casos de prueba que (Más o menos, las salidas). Los casos de prueba
evaluarán la consecución de los objetivos de se derivan sistemáticamente por considerar cada
fiabilidad y ejercer uso relativo y importancia de posible combinación de condiciones y sus
las distintas funciones similares a lo que se acciones resultantes correspondientes. Una
encontró en el entorno operativo [3]. técnica relacionada es causa-efecto gráfica [1 *,
c13s6].
3.5.2. La heurística de observación del 3.6.2. Las máquinas 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 diseño de la cara 3.6.1. Las tablas de decisión
del usuario inter [10 *, c1s4] (véase el diseño de
la interfaz de usuario en el software de diseño de
KA). especializadas heurísticas, también
llamados métodos de inspección facilidad de
uso, se aplican para la observación sistemática
del uso del sistema bajo condiciones controladas
con el fin de determinar qué tan bien la gente
puede utilizar el sistema y sus interfaces.
heurísticas de usabilidad incluyen recorridos
cognitivos, análisis de reclamaciones,
observaciones de campo, pensando en voz alta, y
los enfoques incluso indirectos, tales como
cuestionarios de usuario y entrevistas.
3.6. Técnicas de ensayo basado en modelos
Un modelo en este contexto es una

representación abstracta (formal) del software
bajo prueba, o de sus requisitos de software (ver
Modelado de los modelos de ingeniería de
software y métodos 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 notación 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
generación de caso de prueba; la infraestructura
de apoyo para la ejecución de la prueba; y la
evaluación de los resultados de las pruebas en
comparación con los resultados esperados.
Debido a la complejidad de las técnicas, los
métodos de ensayo basados en modelos se
utilizan a menudo en conjunción con los arneses
ción de prueba automatización. técnicas de
pruebas basadas en modelos incluyen los
Al modelar un programa como una máquina 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- cación 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 aplicaciones,
formal (ver Métodos formales en la Engineer- generalmente representados a través de
Software ing modelos y métodos KA) permite notaciones gráficas. Cada secuencia de acciones
la derivación automática de casos de prueba constituye un flujo de trabajo (también llamado
funcionales, y, al mismo tiempo, proporciona un escenario). Tanto cal normalmente, un y
un oráculo 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 especificación de flujo de obra está
notación de la versión 3) es un lenguaje dirigida en las pruebas de procesos de negocio.
desarrollado para escribir casos de prueba. La
notación fue concebida para las necesidades 3.7. Las técnicas basadas en la naturaleza
específicas de los sistemas de prueba de de la aplicación
[1 *, Las técnicas anteriores se aplican a todo tipo de
c9s6] software. Técnicas adicionales para la
derivación y ejecución de pruebas se basan en la
Las tablas de decisión representan las relaciones naturaleza de la software siendo probado; por
lógicas entre las condiciones (aproximadamente, ejemplo,
insumos) y acciones
Software de Pruebas 4-
11
• software orientado a objetos en cada punto de decisión. Para evitar este tipo
• software basado en componentes de malentendidos, una clara distinción debe
• software basado en web hacerse entre las medidas relacionadas con las
• programas concurrentes pruebas que proporcionan una evaluación 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 críticos evalúan la minuciosidad de la prueba. (Véase la
• software orientada a servicios Ingeniería de Software de medición en la
• software de código abierto Gestión KA Ingeniería de Software para obtener
• software embebido información sobre los programas de medición.
Ver Proceso de Software y Medición del
3.8. La selección y la combinación de técnicas producto en el Proceso de Ingeniería de
Software KA para obtener información sobre las
3.8.1. La combinación funcional y estructural medidas).
[1 *, c9] La medición se considera generalmente como
fundamental para el análisis de calidad. La
Basado en modelos y técnicas de ensayo basadas medición también se puede utilizar para
en código son a menudo contrastan tan funcional optimizar la planificación y ejecución de las
frente a las pruebas estructurales. Estos dos pruebas. Gestión de pruebas puede utilizar varias
enfoques para la selección de la prueba no deben medidas de diferencias ent proceso para
ser vistos como alternativas sino como monitorear el progreso. (Véase la sección 5.1,
complementos; de hecho, se utilizan diferentes las consideraciones prácticas, para una dis-
fuentes de información y se ha demostrado que cusión de las medidas del proceso de pruebas
diferentes tipos de alta luz de los problemas. útiles para fines de gestión).
Pueden ser utilizados en combinación,
dependiendo de consideraciones presupuestarias. 4.1. Evaluación de la prueba el marco del
Programa
4.1.1. Las mediciones de programas que

ayudan en la planificación y Análisis
Diseñando
[9 *, c11]
3.8.2. Determinista vs aleatoria
[1 *, Medidas basado en el tamaño del software (por
c9s6] ejemplo, líneas de código fuente o tamaño
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 técnica de prueba popular. El logro
muchas técnicas, o aleatoriamente extraídas de de una cobertura rama medida especificada (por
alguna distribución 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 analíticas y empíricas erales SeV de improv- ing las posibilidades de encontrar
han llevado a cabo para analizar las condiciones fallos por intentar ejercer sistemáticamente todas
que hacen que un enfoque más eficaz que el las ramas del programa
otro.
4. Las medidas de prueba relacionados
A veces, las técnicas de prueba son confundidos

con los objetivos de las pruebas. Técnicas de
ensayo pueden ser vistos como auxiliares que
ayudan a asegurar el logro de objetivos de la
4-12 Guía SWEBOK®
Requisitos V3.0 en
Suring los requisitos de software
KA) o en la estructura del programa se pueden
usar para guiar las pruebas. Las medidas
estructurales incluyen también medidas que
determinan la frecuencia con la que llaman
módulos entre sí.
4.1.2. FALLO Tipos, clasificación y

estadísticas
[9 *, c4]
La literatura es rica en pruebas de

clasificaciones y taxonomías de faltas. Para
hacer la prueba tivo más 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 información puede ser
uso-ful para hacer predicciones de calidad, así
como en la mejora de procesos (véase ción de
defectos caracterización de la calidad del
software KA).
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 relación funcionales ejercidas entre los enumerados en el
entre el número de fallos encontrados y el documento de especificaciones. criterios de
tamaño del programa. adecuación basados en códigos requieren
instrumentación apropiada del programa que se
4.1.4. Prueba de vida, Evaluación Fiabilidad está probando.
[1 *, c15] [9 *, c3]
Una estimación estadística de la fiabilidad del

software, que puede ser obtenido mediante la
observación de fiabilidad alcanzado, se puede
utilizar para evaluar un producto de software y
decidir si o no la prueba puede ser detenido (ver
sección 2.2, Logro Fiabilidad y evaluación).
4.1.5. Los modelos de crecimiento fiabilidad

[1 *, c15] [9 *, c8]
modelos de crecimiento Fiabilidad proporcionan

una predicción de fiabilidad basado en fracasos.
Suponen, en general, que cuando las fallas que
causaron las fallas observadas se han fijado
(aunque algunos modelos también aceptan
correcciones imperfectas), exposiciones de
fiabilidad del producto 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 evaluación de las pruebas realizadas
4.2.1. Medidas de cobertura / Minuciosidad

[9 *, c11]
Varios criterios de adecuación de prueba

requieren que los casos de prueba ejercen
sistemáticamente un conjunto de elementos
identificados en el programa o en las
especificaciones (véase el tema 3, Técnicas de
Prueba). Para evaluar la rigurosidad de las
pruebas ejecutadas, nieros de software niería
pueden monitorear los elementos cubiertos de
manera que puedan medir dinámicamente la
relación entre los elementos cubiertos y el
número total. Por ejem plos, es posible medir el
porcentaje de ramas cubiertas en el gráfico de
4-14 Guía SWEBOK® V3.0 medidas 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 teoría,
dependiendo de cuáles y cuántos de los
defectos artificiales se presen- ten, Ensayos
sobre la eficacia puede ser evaluado y el
número restante de fallos genuinos puede ser
acoplado estimación. En la práctica, los
estadísticos cuestionan la distribu- ción y la
representatividad de los fallos sembradas en
relación con los fallos genuinos y el tamaño
pequeño de la muestra sobre la que se basan las
extrapolaciones. Algunos también argumentan
que esta técnica se debe utilizar con mucho
cuidado ya que la inserción de fallos en el
software implica el riesgo evidente de dejarlos
allí.
4.2.3. Puntuación mutación

[1 *,
c3s5]
En las pruebas de mutación (ver pruebas de

mutación en sec- ción 3.4, Técnicas basada en
la culpa), la proporción de mutantes muertos al
número total de mutantes generados puede ser
una medida de la eficacia del equipo de prueba
ejecutado.
4.2.4. La comparación y la eficacia relativa

de las diferentes técnicas
Se han realizado varios estudios para com-

parar la eficacia relativa de las diferentes
técnicas de prueba. Es importante ser preciso
en cuanto a la propiedad contra la cual se están
evaluando las técnicas; lo que, por ejemplo, es
el significado exacto dado al término
“eficacia”? Posibles interpretaciones incluyen
el número de pruebas necesarias para encontrar
el primer fracaso, la proporción entre el
número de fallos que se encuentran a través de
pruebas de todos los defectos encontrados
durante y después de la prueba, y la cantidad
de fiabilidad se ha mejorado. comparaciones
analíticas y empíricas entre diferentes técnicas
se han llevado a cabo de acuerdo con cada una
de las nociones de eficacia especificados
anteriormente.
5. Prueba Proceso
conceptos de pruebas, estrategias, técnicas, y

15
proceso controlado. El proceso de prueba es el elemento de prueba. la documentación de

compatible con las actividades de ensayo y prueba debe hay que producir y actualizada
proporciona orientación a los probadores y continuamente para el mismo nivel de calidad
equipos de prueba, desde la planificación de que los demás tipos de documentación en la
prueba para probar la evaluación de salida, de tal ingeniería de software. documentación de prueba
manera como para ofrecer garantías de que los también debe estar bajo el control de la gestión
objetivos de la prueba se cumplirán de manera de con- figuración de software (ver el KA
tivo costo-effec-. Software Configuration Management). Por otra
parte, la documentación de prueba incluye
5.1. Consideraciones prácticas productos de trabajo que pueden proporcionar
material para manuales de usuario y la
5.1.1. Actitudes / programación sin ego formación de usuarios.
[1 * c16] [9 *, c15]
5.1.5. Desarrollo basado en pruebas
La documentación es una parte integral de la ción
Un elemento importante de la prueba con éxito formalización del proceso de prueba [6, parte 3].
es una actitud de colaboración hacia las documentos de prueba pueden incluir, entre otros,
actividades de prueba y garantía de calidad. Los el plan de pruebas, especificación de diseño de la
gerentes tienen un papel clave en la promoción prueba, procedimiento de ensayo, la
de una recepción favorable en general hacia el especificación de casos de prueba, registro de la
descubrimiento fracaso y la corrección 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 superación de la
mentalidad de código individual ERSHIP de
propia entre los programadores y la promoción
de un entorno de colaboración con el equipo de
responsabilidad de anomalías en el código.
5.1.2. Prueba guías

[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 Gestión 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, políticas y medidas en
un proceso bien definido que es una parte
integral del ciclo de vida.
5.1.4. Prueba Documentación y los productos

[1 *, c8s12] [9 *, c4s5]
4-16 Guía SWEBOK® V3.0 [1 *, c1s16]
Basado en pruebas de desarrollo (TDD) se

originó como una de las prácticas núcleo XP
(programación extrema) y consiste en escribir
las pruebas unitarias antes de escribir el código
para ensayar (ver Métodos ágiles en los
modelos de ingeniería de software y métodos
KA). De esta manera, TDD desarrolla los casos
de prueba como rogate sur- para un documento
de especificación de requisitos de software en
lugar de como una verificación independiente
de que el software ha implementado
correctamente los requisitos. En lugar de una
estrategia de ensayo, TDD es una práctica que
requiere que los desarrolladores de software
para definir y mantener las pruebas de unidad;
Por lo tanto, también puede tener un impacto
positivo en la elaboración de las necesidades
del usuario y especificación de requisitos de
software.
5.1.6. Interna frente del equipo de pruebas

independientes
[1 *, c16]
La formalización el proceso de prueba también

puede implicar la formalización de la
organización 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 construcción 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
aplicación pueden guiar la decisión.
5.1.7. Costo / Esfuerzo de estimación 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 búsqueda de errores de las
diversas fases de prueba, son utilizados por los
administradores para controlar y mejorar la
prueba
17
proceso. Estas medidas de prueba pueden cubrir 5.2. Prueba Ocupaciones

aspectos tales como el número de casos de
prueba especificados, el número de casos de Como se muestra en la siguiente descripción,
prueba ejecutados, el número de casos de prueba manejo exitoso de las actividades de prueba
pasó, y el número de casos de prueba falló, entre depende en gran medida Cess la gestión de
otros. configuración de software pro (véase el software
Evaluación de los informes de las pruebas de de configuración Manage- ment KA).
fase puede ser combinarse con el análisis de las
causas para evaluar la efectividad del proceso de 5.2.1. Planificación
Exámenes en la búsqueda de fallos tan pronto [1 *, c12s1,
como sea posible. Tal evaluación puede estar c12s8]
asociada con el análisis 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ó medición gestión de proyectos, se deben planificar las
con el uso / criticidad de la apli- cación: actividades de prueba. Los aspectos clave de la
diferentes técnicas tienen diferentes costos y el planificación de controles incluyen la
rendimiento de los diferentes niveles de coordinación de la persona-nel, la disponibilidad
confianza en la fiabilidad del producto. de instalaciones de prueba y equipos, creación y
mantenimiento de todos los docu- mentación
5.1.8. Terminación relacionada prueba, y la planificación de
[9 *, posibles resultados no deseable. Si se mantiene
c10s4] más de una línea de base del software, a
continuación, un plan- importante consideración
Una decisión debe ser tomada en cuanto a es la que define el tiempo y el esfuerzo
cuánto ing Test- es suficiente y cuando una necesarios para garantizar que el entorno de
etapa de prueba puede ser terminología NAT. prueba se establece en la configuración
Minuciosidad medidas, tales como la cobertura adecuada.
de código 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 suficiente en sí mismos. c12s3]
La decisión también implica consideraciones
sobre los costes y los riesgos que corren los Generación de casos de prueba se basa en el
posibles fallos restantes, a diferencia de los nivel de pruebas a realizar y las técnicas de
costos incurridos al continuar la prueba (ver ensayo particulares. Los casos de prueba deben
Criterios de selección Prueba / Criterios de estar bajo el control de gestión de
prueba de adecuación en la sección 1.2, Temas configuración de software e incluir los
clave). resultados esperados para cada prueba.
5.1.9. Prueba de Reutilización 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 detrás de las decisiones tomadas, forman un
deben ser reutilizados de forma sistemática. Un patrón de prueba que puede en sí mismo ser
repositorio de materiales de prueba debe estar documentados para su posterior reutilización en
bajo el control del software de gestión de con- proyectos similares.
figuración de modo que los cambios en los
requisitos de software de diseño o se pueden
reflejar en cambios en las pruebas realizadas.
Las soluciones de ensayo adoptadas para
El entorno utilizado para la prueba debe ser
compatible con herramientas niería otro
software adoptada niería. Se debe facilitar el
desarrollo y control de casos de prueba, así
como el registro y la recuperación de los
resultados esperados, guiones y otros
materiales de prueba.
5.2.4. Ejecución
[1 *,
c12s7]
La ejecución de los ensayos deberá incorporar

un principio básico de la experimentación
científica: todo lo realizado durante la prueba
debe ser realizado y documentado con claridad
suficiente como para que otra persona
19
podrían replicar los resultados. Por lo tanto, las El software. información 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
versión claramente definida del software bajo necesitan mejora y la eficacia de los enfoques
prueba. anteriores han sido.
5.2.5. Prueba Evaluación 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 mayoría 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 tenía ningún principales numerosos programas Ning, y el manejo de una
resultados inesperados. No todos los resultados gran cantidad de información. herramientas
inesperados son necesariamente defectos, pero adecuadas pueden aliviar la carga de opera-
en algún momento se determinan a ser ciones de oficina, tediosas y hacerlos menos
simplemente ruido. Antes de que una falla puede propensos a errores. Sofisticación herramientas
ser eliminado, es necesario un esfuerzo de CATed pueden apoyar el diseño de pruebas y
análisis y depuración de aislar, identificar y generación de casos de prueba, por lo que es más
describir. Cuando los resultados son eficaz.
particularmente importantes, una junta de
revisión formal puede ser con- Vened para 6.1.1. Selección de Herramientas
evaluarlas. [1 *, c12s11]
5.2.6. Informe de problemas / Orientación a los directores y los probadores

Registro de Pruebas [1 *, c13s9] sobre cómo seleccionar las herramientas de
prueba que serán más útiles a su nización 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 cuándo 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 configuración del software se requisitos de mal definidos, ción incorrecta
utilizó, y otra identificación correspondiente variable de declara-, pérdida de memoria, error de
infor- mación. resultados de prueba inesperados sintaxis de programación), y cuando podían haber
o incorrectos pueden ser grabados en un sistema sido observado por primera vez en
de notificación de problema, los datos para el
cual constituye la base para más tarde debug-
ging y la fijación de los problemas que se
observaron como fallas durante la prueba.
Además, las anomalías no clasificados como
fallos podrían ser documentados en caso de que
más tarde resultan ser más grave de lo previsto
inicialmente. Los informes de ensayo son
también entradas al proceso de solicitud de la
gestión del cambio (véase Control de
Configuración de Software en el KA Software
Configuration Management).
5.2.7. seguimiento de defectos

[9 *, c9]
4-20 Guía
comoSWEBOK® V3.0
herramienta de selección afecta en gran
medida la eficiencia y la eficacia de la prueba.
Selección de herramienta depende de la
evidencia diversa, tales como las opciones de
desarrollo, los objetivos de evaluación,
instalaciones de ejecución, y así
sucesivamente. En general, puede no ser una
herramienta única que va a satisfacer
necesidades particulares, por lo que un
conjunto de herramientas podría ser una opción
apropiada.
6.2. Categorías 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 programa, se proporcionan
los conductores y los talones para simular
llamadas tarde y llamados módulos,
respectivamente.
• generadores de prueba [1 *, c12s11]
proporcionar tancia asis- en los casos de
prueba generación. La gene- ración puede
ser al azar, basado en vía modelo- basa, o
una mezcla de los mismos.
• herramientas de captura / reproducción [1
*, c12s11] auto-
volver a ejecutarlo ticamente, o de
repetición, previamente
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 ejecución del programa.
herramientas de comprobación de aserción • herramientas de pruebas de regresión [1 *,
[1 *, c9s7] ayudar a decidir si un resultado c12s16] apoyar la ejecución adicional de un
de la prueba es exitosa o no. conjunto de pruebas después de una sección
• analizadores de cobertura y instrumenters del software ha sido modificado. También
[1 *, c4] trabajar juntos. analizadores de pueden ayudar a seleccionar un subconjunto
cobertura evaluar qué y cómo se han de pruebas de acuerdo con el cambio
ejercido muchas entidades de la gráfica de realizado.
flujo del programa entre todos los • herramientas de evaluación de la fiabilidad
requeridos por el criterio de cobertura de [9 *, c8] resultados de prueba apoyo análisis
prueba seleccionada. El análisis se puede y ción visualiza- gráfica a fin de evaluar
hacer gracias a instrumenters que insertan medidas relacionadas fiabilidad-de
sondas de grabación en el código del acuerdo con los modelos seleccionados.
programa.
naik y Tripathy 2008 [1
2011 [2 *]
1993 [10
Nielsen
Kan 2003
SommervilLe
[9 *]
*]
nortea
*]
1. Fundamentos de Software
Testing
1.1. Terminología de pruebas
relacionados
1.1.1. Definiciones de Pruebas y
c1, c2 c8
Terminología relacionada
1.1.2. Las fallas fallas vs. c1s5 c11
1.2. Cuestiones clave
1.2.1. Criterios de selección de
c1s14, c6s6,
prueba/ Criterios de prueba
c12s7
de adecuación (Reglas de
parada)
1.2.2. Prueba de Eficacia /
c13s11, c11s4
Objetivos para las pruebas
1.2.3. Las pruebas de defectos
c1s14
Identificación
c1s9,
1.2.4. El problema de Oracle
c9s7
1.2.5. Teórico y práctico
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. Relación de las pruebas de
Otras actividades
1.3.1. Prueba de Software vs.
estáticoTécnicas de gestión de c12
la calidad
1.3.2. La corrección de pruebas
c17s2
vs.
Pruebas y verificación
1.3.3. Prueba formalvs.
de depuración c3s6
1.3.4. Las pruebas contra c3s2
2. Niveles de pruebaProgramación
2.1. El objetivo de la prueba c1s13 c8s1
2.1.1. Examen de la unidad c3 c8
2.1.2. Pruebas de integración c7 c8
2.1.3. Prueba del sistema c8 c8
23
2011 [2 *]
1993 [10
Nielsen
Kan 2003
SommervilLe
[9 *]
*]
nortea
*]
2.2. Objetivos de las Pruebas c1s7
2.2.1. Aceptación / Calificación c1s7 c8s4
2.2.2. Prueba de la instalación c12s2
c13s7,
2.2.3. Alfa y Beta Testing c8s4
c16s6
2.2.4. Logro fiabilidady
c15 c15s2
Evaluación
c8s11,
2.2.5. Pruebas de regresión
c13s3
2.2.6. Pruebas de rendimiento c8s6
2.2.7. Pruebas de seguridad c8s3 c11s4
2.2.8. Pruebas de estrés c8s8
2.2.9. Back-to-Back Testing
2.2.10. Prueba de recuperación c14s2
2.2.11. Prueba de interfaz c8s1.3 c4s4.5
2.2.12. Prueba de configuración c8s5
2.2.13. usabilidady Pruebas
c6
Human Computer
Interaction
3. Técnicas de Prueba
3.1. Basadoen la intuición 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
técnicas
3.2.1. Partición de equivalencia c9s4
3.2.2. Las pruebas por parejas c9s3
3.2.3. Análisis de valores en la c9s5
3.2.4. Pruebas al azar frontera c9s7
3.3. Técnicas de código-base
3.3.1. -Base de flujo de control
c4
criterios
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
Código
3.4. Técnicas basada en la culpa c1s14
3.4.1. error de adivinanzas c9s8
3.4.2. Las pruebas de mutación c3s5
3.5. Técnicas de uso-Basado
3.5.1. Perfil operativa c15s5
3.5.2. La heurística de
C5, C7
observación del usuario
3.6. Las pruebas basado en
modelos
técnicas
3.6.1. Tabla de decisión c9s6
3.6.2. Las máquinas de estados c10
finitos
3.6.3. Pruebas de formal
c10s11 c15
Presupuesto
3.7. Las técnicas basadasen la
naturaleza de la aplicación
3.8. Seleccióny la
combinación de técnicas
3.8.1. Funcional y estructural C9
3.8.2. Determinista vs aleatoria c9s6
4. Las medidas de prueba
relacionados
4.1. Evaluación del Programa
Bajo prueba
4.1.1. Las mediciones de
programas que ayudan en la c11
planificación y ensayo de
Proyectos
4.1.2. Tipos de fallos, clasificación,
c4
y Estadísticas
4.1.3. Densidad de fallos c13s4 c4
4.1.4. Prueba de vida, Fiabilidad
c15 c3
Evaluación
4.1.5. Los modelos de crecimiento c15 c8
fiabilidad
25
2011 [2 *]
1993 [10
Nielsen
Kan 2003
SommervilLe
[9 *]
*]
nortea
*]
4.2. Evaluación deLas pruebas
realizadas
4.2.1. Cobertura / Minuciosidad
c11
medidas
4.2.2. Siembra de fallos c2s5 c6
4.2.3. Puntuación mutación c3s5
4.2.4. Comparacióny la
eficacia relativa de las
diferentes técnicas
Proceso 5. Prueba
5.1. Consideraciones prácticas
5.1.1. actitudes/
c16 c15
Programación sin ego
5.1.2. Guías de prueba c12s1 c15s1
5.1.3. Gestión de procesos de c12 c15
5.1.4. Documentación de laprueba
c8s12 c4s5
comprobacióny 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 / estimación de esfuerzoy
c18s3 c5s7
Otras medidas del proceso
5.1.8. Terminación c10s4
5.1.9. Prueba de Reutilización y c2s5
Patrones
5.2. Las actividades de prueba
c12s1
5.2.1. Planificación
c12s8
c12s1
5.2.2. Generación de casos de
c12s3
prueba
5.2.3. Desarrollo
c12s6
Entorno de prueba
5.2.4. Ejecución c12s7
5.2.5. Resultados de la prueba c15
Evaluación
2011 [2 *]
1993 [10
Nielsen
Kan 2003
SommervilLe
[9 *]
*]
nortea
*]
5.2.6. Informe de problemas /
c13s9
Prueba
Iniciar sesión
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. Selección de c12s11
Herramientas c1s7, c3s9,
c4, c9s7,
6.2. Categorías de Herramientas c8
c12s11,
c12s16
27
Referencias
[1 *] S. Naik y P. Tripathy, pruebas de [8] S. Yoo y M. Harman, “pruebas de regresión
software y aseguramiento de la calidad: Minimización, selección y priorización: una
Teoría y Práctica, Wiley-Spektrum, 2008. encuesta,” Pruebas de verificación de
software y Fiabilidad, vol. 22, no. 2, marzo
[2 *] I. Sommerville, Ingeniería de Software, 9ª de 2012,
ed., Addison-Wesley, 2011. pp. 67-120.
[3] MR Lyu, ed., Manual de Ingeniería de [9 *] SH Kan, métricas y modelos en Ingeniería

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, Ingeniería 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 programación 1, enero de 2010, pp. 60-66.
estructurada,” Informe TH-70-WSE-03,
Universidad Tecnológica 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/ mutación “, IEEE Trans. Ingeniería 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, práctico basado
Testing Ingeniería--Parte 1 Software: en modelos de prueba: Un Enfoque
Conceptos y definiciones, ISO / IEC / IEEE Herramientas, Morgan Kaufmann, 2007.
2012.

CAPÍTULO 5
MANTENIMIENTO DE
SOFTWARE
paradigma de código abierto ha traído más aten-

SIGLAS ción a la cuestión del mantenimiento de artefactos
de software desarrollados por otros.
SEÑO Solicitud de modificación
En esta guía, el mantenimiento del software se
R
PR Informe de problemas define como el conjunto de actividades necesarias
Gestión de la Configuración 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 Verificación y validación
INTRODUCCIÓN
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
después de un período de garantía o soporte
posterior a la implementación 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
atención que las otras fases tienen.
Históricamente, el desarrollo de software ha
tenido un perfil mucho más alto que el
mantenimiento del software en la mayoría de las
organizaciones. Esto está cambiando, ya que las
empresas se esfuerzan para exprimir el máximo
rendimiento de su inversión en el desarrollo de
software por el software que opera ING
mantener- el mayor tiempo posible. El
Software
Esta primera sección presenta de Pruebas 4-
los conceptos y
durante la etapa de posparto. actividades antes 29
terminología que forman una base subyacente a
de la entrega incluyen la planificación para las la comprensión de la función y el alcance del
operaciones de posparto, el mantenimiento, y mantenimiento del software. Los temas
la determinación de la logística para las proporcionan definiciones y hacer hincapié en
actividades de transición [1 *, c6s9]. posparto por qué hay una necesidad de mantenimiento.
actividades incluyen la modificación de Categorías de mantenimiento de software son
software, capacitación y operativo o interfaz fundamentales para la comprensión 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 terminología
demás aspectos de la ingeniería de software. [1 *, c3] [2 *, c1s2,
Por lo tanto, esta descripción KA está C2S2]
vinculado a todos los demás de ingeniería de
software KAs de la Guía. El propósito del mantenimiento del software se
define en el estándar internacional para el
DISTRIBUCIÓN DE TEMAS PARA mantenimiento de software:. ISO / IEC / IEEE
MANTENIMIENTO DE SOFTWARE 14764 [1 *] 1 En el contexto de la ingeniería 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. técnicos.
1. Fundamentos de mantenimiento de 1 A los efectos de la concisión y la facilidad de

software lectura ing, esta norma se refiere simplemente como
IEEE 14764 en el texto subsiguiente de esta KA.
5-1
Figura 5.1. Desglose de temas para el mantenimiento del software KA
El objetivo del mantenimiento del software es de los cambios propuestos, código de software y
modificar el software existente, preservando su otros artefactos son
integridad. La norma internacional también
señala 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
planificación, 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 modificación 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 versión del producto de software es
liberado. Además, forma- ción y apoyo diario
se proporcionan a los usuarios. El término
mantenedor se define como una organización
que lleva a cabo actividades de mantenimiento.
En este KA, el término 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 implementación de procesos, análisis de
problemas y la modificación, la implementación
de modificación, revisión de mantenimiento /
aceptación, la migración, y la jubilación. Estas
actividades se describen en la sección 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 participación temprana
de la
mantenedor ayuda a reducir el esfuerzo de

mantenimiento general. En algunos casos, el 1.4. La mayoría 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 desafío
adicional para man- recipientes. El Mantenimiento consume una parte importante de
mantenimiento debe tener artefactos de software la finan-
de desarrollo (por ejemplo, código o docu- ciales recursos en un ciclo de vida del software.
mentación) y apoyarlos de inmediato, y luego Una común
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 continúa para satisfacer las
necesidades del usuario. mantenimiento 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 diseño;
• implementar mejoras;
• interactuar con otros softwares;
• adaptar los programas a fin de que distintos
tipos de hardware, el software, las
características del sistema y de las
telecomunicaciones instalaciones se pueden
utilizar;
• migrar software heredado; y
• retirarse de software.
Cinco características clave incluyen las

actividades de la er maintain-:
• mantener el control sobre las funciones de

día-a-día del software;
• maintainingcontrolover
software
modificación;
• el perfeccionamiento de las funciones
existentes;
• la identificación de amenazas a la seguridad
y la fijación de las vulnerabilidades de
seguridad; y
• preventingsoftwareperformancefrom
degradantes a inaceptable
los niveles.
Mantenimiento
perfectivo [2 *, c4s3]. IEEE de Software
14764 incluye una
percepción de mantenimiento del software es 5-5
que se limita a fijar los fallos. Sin embargo, cuarta categoría-preventivo.
estudios y encuestas realizadas a lo largo de los
años han indicado que la dad de División, más • El mantenimiento correctivo: modifi- reactiva
del 80 por ciento, del mantenimiento del cación (o reparaciones) de un producto de
software se utiliza para acciones noncorrective software
[2 *, figura 4.1]. La agrupación de mejoras y
correcciones juntos en los informes de gestión
contribuye a algunos conceptos erróneos con
respecto a los altos costos de correcciones. La
comprensión de las categorías de
mantenimiento de software ayuda a
comprender la estructura de los costes de
mantenimiento de software. Además, la
comprensión de los factores que influyen en la
capacidad de mantenimiento de software puede
ayudar a contener los costos. Algunos factores
medioambientales y su relación 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. Evolución de Software

[2 *,
c3s5]
El mantenimiento del software en términos de

evolución se abordó por primera vez en la
década de 1960. Durante un período de veinte
años, la investigación condujo a la formulación
de ocho “leyes de la evolución.” Las
principales conclusiones son una propuesta que
el mantenimiento es desarrollo evolutivo y
que las decisiones de mantenimiento son
ayudados mediante la comprensión de lo que
ocurre con el software con el tiempo. Algunos
afirman que el mantenimiento se continúa el
desarrollo, con la excepción de que hay una
entrada adicional (o restricción), en otras
palabras, que existe gran software nunca es
completa y continúa evolucionando; a medida
que evoluciona, crece más compleja si no se
toman algunas medidas para reducir esta
complejidad.
1.6. Categorías de Mantenimiento

[1 *, c3, c6s2] [2 *,
c3s3.1]
Se han definido tres categorías (tipos) de

mantenimiento: correctivo, adaptativo y
realizado después de la entrega para corregir próximo lanzamiento, mientras que el envío de
problemas Ered descu-. Se incluyen en esta parches de emergencia para la versión actual,
categoría es el mantenimiento de también crea un desafío. En la siguiente sección
emergencia, que es una modificación no se presentan algunos de los problemas gías Nical
programada se realiza para mantener y de gestión 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: modificación de • problemas técnicos,
un producto de software se realiza después • asuntos Gerenciales,
de la entrega para mantener un producto de • estimación de costos, y
software que puedan utilizarse en un • medición.
entorno cambiante o cambiar. Por ejemplo,
el sistema operativo puede ser actualizado y 2.1. Técnico Cuestiones
algunos cambios en el software puede ser
necesario. 2.1.1. La comprensión limitada
• mantenimiento perfectivo: modificación de [2 *, c6]
un producto de software después de la
entrega para proporcionar mejoras para los comprensión limitada se refiere a la rapidez con
usuarios, mejora de la documentación del que un ingeniero de software puede entender que
programa, y la recodificación para mejorar para hacer un cambio o corrección 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: modificación mitad del total del esfuerzo de mantenimiento se
de un producto de software después 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 comprensión de software es de gran inter est a
fallos de funcionamiento. los ingenieros de software. La comprensión es
más difícil en el código fuente de la
IEEE 14764 clasifica mantenimiento representación en orientada a texto, por ejemplo,
adaptativo y perfectivo como mejoras de donde a menudo es difícil trazar la evolución del
mantenimiento. También agrupa a las categorías software a través de sus publicaciones /
de mantenimiento tiva correctivas y prevención versiones si los cambios no están documentados
en una corrección CAT- goría, como se muestra y si los desarrolladores no están 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 inicialmente
Categorías tienen una comprensión limitada del software;
Corrección Mejora aún 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 planificación de una versión futura, que a
para garantizar el mantenimiento eficaz de menudo incluye la codificación
software. mantenimiento de software ofrece
retos únicos cal y de gestión técnicamente para
los ingenieros de software-para ejemplo,
tratando de encontrar un fallo en el software que
contiene un gran número de líneas de código que
El costo de la repetición de la prueba completa 5-7
en una pieza importante de software es
importante en términos de tiempo y dinero.
Con el fin de garantizar que los informes de
problemas solicitados son válidos, el
mantenedor debe replicar o verificar los
problemas mediante la ejecución de las pruebas
adecuadas. Las pruebas de regresión (la
repetición de pruebas selectiva 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. Además, encontrar
tiempo para probar es a menudo difícil. La
coordinación de las pruebas cuando diferentes
miembros del equipo de mantenimiento están
trabajando
sobre diferentes problemas al mismo tiempo 2.1.4. mantenibilidad

sigue siendo un desafío. Cuando el software [1 *, c6s8] [2 *,
realiza funciones críticos, puede ser difícil para c12s5.5]
llevarlo fuera de línea para la prueba.
Las pruebas no se pueden ejecutar en el lugar-ful IEEE 14 764 [1 *, c3s4] define mantenibilidad
el sistema de producción más sentido-. La como la capacidad del producto de software para
Prueba KA Software proporciona información y ser modificado. Las modificaciones pueden
referencias adicionales sobre este asunto en su incluir correcciones, mejoras, o la adaptación del
subtema en las pruebas de regresión. software a cambios en el entorno, así como
cambios en los requisitos y especificaciones
2.1.3. Análisis de impacto funcionales.
[1 *, c5s2.5] [2 *, Como una característica de calidad del
c13s3] software principal, capacidad de mantenimiento
se debe especificar, revisado y controlado
Análisis de impacto describe cómo llevar a cabo, durante los lazos de desarrollo de software
de manera rentable, un análisis 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 difícil de lograr
software. Ellos usan este conocimiento para debido a las subcaracterísticas menudo no son
llevar a cabo análisis de impacto, que identifica un foco importante durante el proceso de
a todos los sistemas y productos de software desarrollo de software. Los desarrolladores
afectadas por una solicitud de cambio de están, por lo general, más preocupados con
software y desarrolla una estimación de los muchas otras actividades y con frecuencia
recursos necesarios para llevar a cabo el cambio. propensos a ignorar las exigencias del
Además, 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 documentación de
una petición de modificación (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 términos de comprensión del programa y análisis de impacto
software. Análisis de impacto se realiza después posterior. La presencia de procesos sistemáticos
de una solicitud de cambio entra en el proceso y maduros, técnicas y herramientas de ayuda
de gestión de la configuración software. IEEE para mejorar la capacidad de mantenimiento de
14764 establece las tareas de análisis de software.
impacto:
2.2. Asuntos Gerenciales
• analizar MRs / IPs; 2.2.1. La alineación con los

• replicar o verificar el problema; objetivos organizacionales
• desarrollar opciones para la aplicación del [2 *, c4]
modificación;
• documentar el MR / PR, los resultados y las acción.
opciones de ejecución; Software diseñado con capacidad de
• obtener la aprobación de la modificación mantenimiento en mente facilita en gran medida
seleccionada el análisis del impacto. más infor- mación se
opción. puede encontrar en el software de gestión de la
configuración KA.
La gravedad de un problema a menudo se
utiliza para decidir cómo y cuándo va a ser fijo.
El ingeniero de software a continuación,
identifica los componentes afectados. Se
proporcionan varias soluciones posibles, seguido
de una recomendación sobre el mejor curso de
objetivos de la organización describen cómo para Mantenimiento de Software
5-9
demostrar los retorno de la inversión 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. Además, 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
inversión es mucho menos clara, por lo que la
vista en el nivel de la alta dirección es a
menudo la de una importante actividad que
consume recursos significativos sin ningún
beneficio cuantificable clara para la
organización.
2.2.2. dotació asignación 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- ción.
Dotación de personal se refiere a la manera de
atraer y mantener al personal de mantenimiento 2.2.5. La
software. El mantenimiento no es a menudo externalizac [3 *]
visto como un trabajo glamoroso. Como ión
resultado, se ve con más frecuencia el personal
de mantenimiento de software
como “ciudadanos de segunda clase”, y por lo • promueve una atmósfera sin ego,
tanto la moral universitarios;
sufre. • reduce la dependencia de los individuos;
• permite controles de auditoría periódicas.
2.2.3. Proceso
[1 *, c5] [2 *, c5] Puesto que hay muchos pros y los contras de
cada opción, la decisión 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, métodos, prácticas y delegación 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 común con el desarrollo de software
(por ejemplo, gestión de configuración de
software es una actividad crucial en ambos). El
mantenimiento también requiere varias
actividades que no se encuentran en desarrollo
de software (ver sección 3.2 en actividades
únicas para más detalles). Estas actividades
presentan desafíos para la gestión.
2.2.4. Aspectos de organización de

Mantenimiento
[1 *, c7s2.3] [2 *, c10]
Aspectos organizativos describen cómo iden-

tificar qué organización y / o función 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 dónde se ubicará la función de
mantenimiento de software, las organizaciones
de ingeniería de software pueden ser, por
ejemplo, quedarse con el desarrollador original o
ir a un equipo de mantenimiento específico
permanente (o personal de mantenimiento).
Tener un equipo de mantenimiento permanente
tiene muchos beneficios:
• permite la especialización;
• crea canales de comunicación;
La externalización y la deslocalización de Mantenimiento de Software
5-11
software mantenimiento se ha convertido en
una industria importante. Las organizaciones
que están externalizando carteras enteras de
software, incluyendo el mantenimiento del
software. Más a menudo, la opción de la
externalización se selecciona por menos de
software de misión crítica, como las
organizaciones no están 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
términos de un acuerdo de nivel de servicio, y
los detalles contractuales. Subcontratistas
tendrán 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 externalización
requiere una inver- sión inicial importante y la
configuración de un proceso de mantenimiento
que requerirá la automatización.
2.3. Estimación de costes de mantenimiento
Los ingenieros de software deben entender las

diferentes categorías de mantenimiento de
software, expuestos anteriormente, con el fin
de abordar la cuestión de ing realizan
estimaciones del costo de mantenimiento de
software. Para fines de planificación,
estimación de costos es un aspecto importante
de la planificación para el mantenimiento del
software.
2.3.1. Estimación de costos

[2 *, c7s2.4]
Sección 2.1.3 se describe cómo el análisis del

impacto identifica todos los sistemas y
productos de software afectadas por una
solicitud de cambio de software y desarrolla
una estimación de los recursos necesarios para
llevar a cabo ese cambio.
estimaciones de los costos de mantenimiento
se ven afectados por muchos factores técnicos
y no técnicos. IEEE 14764 establece que “los
dos métodos más populares a los recursos de
estimación para el mantenimiento del software
son el uso de modelos paramétricos y el uso de
la experiencia” [1 *, c7s4.1]. Una combinación
de estos dos también se puede utilizar.
2.3.2. Los modelos modelo de calidad sugiere medidas que son

paramétricos [2 *, específicos para el mantenimiento del software.
c12s5.6] Medidas para la carac- subchar- de
mantenimiento incluyen el seguimiento
el modelo de costos paramétricos (modelos [2 *, c12]
matemáticos) se ha aplicado al mantenimiento
del software. De significación es que se El mantenedor debe determinar qué medidas son
necesitan datos históricos del pasado de adecuadas para una organización específica
mantenimiento con el fin de usar y calibrar los basada en el propio contexto de esa organización.
modelos matemáticos. 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 mación estimación es
combinar los datos históricos y experiencia. El
coste para llevar a cabo una modificación (en
términos de número de personas y la cantidad de
tiempo) se deriva entonces. datos históricos de
estimación de mantenimiento deben ser
proporcionados como resultado de un programa
de medición.
2.4. Medición de mantenimiento de software

[1 *, c6s5] [2 *, c12]
Entidades relacionadas con el mantenimiento del

software, cuyos atributos puede ser sometido a
medición, 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, tamaño ing
INCLUYENDO, la complejidad, la calidad, la
comprensibilidad, mantenibilidad y esfuerzo.
medidas de la complejidad del software también
se pueden obtener utilizando herramientas
comerciales disponibles. Estas medidas
constituyen un buen punto de partida para el
programa de medi- ción del mantenedor. La
discusión de los procesos de software y
medición del producto también se presenta en la
Ingeniería de Procesos de Software KA. El tema
de un programa de medición de software se
describe en el Software Engineering
Management KA.
2.4.1. Las medidas específicas

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
implementación de una modificación cado
speci-.
• Estabilidad: medidas del comportamiento
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
• tamaño del software,
• complejidad del software,
• comprensibilidad, y
• mantenibilidad.
Proporcionar esfuerzo de mantenimiento de

software, por categorías, para diferentes
aplicaciones proporciona información de la
empresa a los usuarios y sus organizaciones.
También puede permitir la comparación de los
perfiles de mantenimiento software
internamente dentro de una organización.
3. Proceso de mantenimiento
Además de la ingeniería de software cesos pro

estándar y las actividades descritas en el
estándar 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
• implementación de procesos,
• problema y el análisis de la modificación,
• aplicación modificación,
• opinión de mantenimiento / aceptación, integridad. Estas

• migración 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, metodologías ágiles, que

promueven los procesos de luz, también se han
adaptado a mante- manteni-. Este requisito surge
de la creciente demanda en constante para la
entrega rápida 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 están anotados brevemente en la
sección Lecturas Además).
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 software existente, preservando su
actividades y tareas son responsabilidad del 5-15
mantenedor. Como ya se ha señalado, muchas Mantenedores también pueden realizar
actividades de mantenimiento son similares a las actividades de apoyo, como la documentación,
del software de Desa- ción. Mantenedores de gestión de configuración de software,
realizar el análisis, diseño, ing de bacalao, verificación y validación, resolución de
pruebas y documentación. Deben realizar un problemas, el software de control de calidad,
seguimiento de los requisitos en sus actividades revisión,
al igual que se hace en la documentación de
desarrollo y actualización a medida que cambian
las líneas de base. IEEE 14764 recomienda que
cuando un mantenedor utiliza un proceso de
desarrollo, debe ser adaptada para satisfacer las
necesidades específicas [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

prácticas que son únicos para el mantenimiento
del software:
• la comprensión del programa: actividades

necesarias para obtener un conocimiento
general de lo que lo hace un producto de
software y cómo las partes trabajan juntas.
• Transición: una secuencia controlada y
coordinada de las actividades durante el cual
el software se transfiere progresivamente de
la oper desa- al mantenedor.
• solicitud de modificación de la aceptación /
rechazo: modificaciones que solicitan
trabajo más allá de un CER Tain tamaño /
esfuerzo / complejidad pueden ser
rechazados por los mantenedores y son
redirigidos a un desarrollador.
• Mantenimiento de mesa de ayuda: un
usuario final y la función de soporte de
mantenimiento coordinado que desencadena
la evaluación, priorización y cálculo de
costos de las solicitudes de modificación.
• Análisis de impacto: una técnica para
identificar las áreas afectadas por un cambio
potencial;
• Acuerdos de mantenimiento de nivel de
servicio (SLA) y licencias de mantenimiento
y contratos: acuerdos contractuales que
describen los servicios y los objetivos de
calidad.
3.2.2. Las actividades que apoyen

[1 *, c4s1, c5, c6s7] [2 *,
c9]
y las auditorías. Otra actividad importante apoyo seguido de un plan de mantenimiento. El concepto
consiste en la formación 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
Planificación • ámbito del mantenimiento de software,
[1 *, c7s3] • la adaptación del proceso de mantenimiento
de software,
Una actividad importante para el mantenimiento
del software es la planificación, y mantenedores
debe abordar las cuestiones relacionadas con la
planificación de una serie de perspectivas,
incluyendo
• la planificación de negocios (nivel de la

organización),
• la planificación del mantenimiento (nivel de
transición),
• planificación de entregas / versión (versión
de software), y
• planificación individual cambio de software
petición (nivel de solicitud).
A nivel de petición individual, la planificación

se lleva a cabo durante el análisis de impacto
(ver sec- ción 2.1.3, el análisis del impacto). La
actividad de planificación de entregas / versión
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 años, la fase de
mantenimiento suele durar muchos años.
Haciendo estimaciones de los recursos es un
elemento clave de la planificación del
mantenimiento. Software de planificación de
mantenimiento debe comenzar con la decisión
de desarrollar un nuevo producto de software y
deben considerar los objetivos de calidad. Un
documento de reflexión debe ser desarrollado,
Mantenimiento
determinar el contenido de la próximadeversión
Software/
• identificación del mantenimiento de 5-17
software versión.
organización, y
• estimación 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 cómo
los usuarios solicitar modificaciones de
software o reportar problemas. la planificación
del mantenimiento de software se aborda en
IEEE 14764. Proporciona directrices para un
plan de mantenimiento. Por último, al más alto
nivel, la organización de mantenimiento tendrá
que llevar a cabo actividades de planificación
de negocios (y los recursos humanos,
presupuestarios financieros) al igual que todas
las otras divisiones de la organización. Gestión
se discute en el capítulo relacionado
Disciplinas de Ingeniería de Software.
3.2.4. Gestión de la Configuración de

Software
[1 *, c5s1.2.3] [2 *,
c11]
IEEE 14 764 describe la administración de

configuración de software como un elemento
crítico del proceso de mantenimiento. Ment
procedimientos manage- de configuración de
software deben proporcionar para la verifica-
ción, validación y auditoría 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- cación 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 aplicación de un proceso de
software de gestión aprobado configu- ración
(SMC). La Administración de KA del software
de configuración 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 número de
pequeños cambios que debe ser controlada
con- el software operativo. El proceso SMC
se implementa mediante el desarrollo y
siguiendo unos procedimientos del plan de
gestión y operación de configuración de
software. Mantenedores participan en las
Juntas de Control de configuración para
3.2.5. Calidad del software 4.3. Ingeniería inversa

[1 *, c6s5, c6s7, c6s8] [2 *, [1 *, c6s2] [2 *, c7,
c12s5.3] c14s5]
No es suficiente con la esperanza de que una La ingeniería inversa es el proceso de análisis de

mayor calidad tendrá como resultado del software para identificar los componentes del
mantenimiento de software. Mantenedores software y sus interrelaciones y crear
deben tener un programa de calidad de representaciones del software en otra forma o en
software. Se debe planificarse y procesos debe los niveles más altos de abstracción. Reverse
ser implementado para apoyar el proceso de Engineer- ing es pasivo; no cambia el software o
mantenimiento. Las actividades y técnicas para dar lugar a un nuevo software. Invertir Engineer-
la Cesión de Software Quality Assurance (SQA), esfuerzos ing producen gráficos de llamada y
V & V, opiniones y auditorías deben ser gráficos de flujo de control de código fuente. Un
seleccionados de común acuerdo con todos los tipo de ingeniería inversa es redocumentación.
demás procesos para alcanzar el nivel deseado Otro tipo es la recuperación de diseño. Por
de calidad. También se recomienda que el tainer último, los datos inversa inge- niería, donde los
man- adaptar el desarrollo de software procesos, esquemas lógicos son recuperados de bases de
técnicas y resultados (por ejemplo, la datos físicos, ha crecido en importancia en los
documentación de la prueba), y los resultados de últimos años. Las herramientas son clave para
las pruebas. Más detalles se pueden encontrar en inge- niería inversa y tareas relacionadas, como
la calidad del software KA. redocumenta- ción y recuperación de diseño.
4. Las técnicas para mantenimiento
Este tema se presentan algunas de las técnicas 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

Comprensión [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 programa y su
la comprensión de los programas con el fin de facilidad de mantenimiento. ING técnicas
implementar los cambios de tiempo. Refactor- se pueden utilizar durante los cambios
navegadores de código son herramientas clave de menor importancia.
para la comprensión del programa y se utilizan
para organizar y código fuente ent PRESION.
documentación clara y concisa también puede
ayudar en la comprensión del programa.
4.2. reingeniería
[2 *, c7]
Reingeniería se define como el examen y la

alteración de software para reconstituir en una
nueva forma, e incluye el ción ¡Ejecución
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 téc- nica
reingeniería que pretende reorganizar un
programa sin cambiar su comportamiento. Se
necesita determinar las acciones necesarias Mantenimiento de Software
5-19
para la migración cumpla cabalmente, y luego
desarrollar y documento los pasos necesarios
para llevar a cabo la migración en un plan de
migración que cubre los requisitos de
migración, herramientas de migración,
conversión del producto y datos, ejecución,
verificación , y apoyo. Migración de software
también puede implicar una serie de
actividades adicionales, tales como
• notificación de la intención: una

declaración de por qué el antiguo entorno
ya no ser Apoyado, seguida de una
descripción del nuevo entorno y su fecha
de disponibilidad es;
• operaciones paralelas: poner a disposición
los viejos y nuevos entornos de modo que
el usuario experimenta una transición
suave al nuevo entorno;
• notificación de finalización: cuando se
haya completado la migración ULed
sched-, se envía una notificación a todos
los interesados;
5-11
• opinión después de la operación: una • rebanadoras de programas, que seleccionan

evaluación de la operación parale- y el sólo partes de una
impacto del cambio al nuevo entorno; programa afectado por un cambio;
• archivado de datos: almacenamiento de los • analizadores estáticos, que permiten ing
datos del software de edad. vista- general y resúmenes de un contenido
del programa;
4.5. Jubilación • analizadores dinámicos, que permiten al
[1 *, tainer man- conocer la vía de ejecución 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 análisis todos los posibles flujos de datos de un
debe llevarse a cabo para ayudar a tomar la programa;
decisión de retiro. Este análisis debe ser incluido • cruzadas referencers, que generan los
en el plan de retiro, que cubre mentos de índices de los componentes del programa; y
jubilación 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 también puede ser incluido. interrelaciones entre los componentes de un
Retirarse de software conlleva una serie de programa.
actividades similares a la migración.
Herramientas de ingeniería inversa ayudan al
5. Herramientas de mantenimiento de proceso trabajando hacia atrás desde un producto
software existente para crear artefactos tales como
[1 *, c6s4] [2 *, especificación y diseño descripciones, que a
c14] continuación se pueden transformar para generar
un nuevo producto de una antigua. Principal-
Este tema abarca herramientas que son también utilizan recipientes de prueba de
particularmente importantes en el software, gestión de con- figuración de software,
mantenimiento de software donde se está documentación de software y herramientas de
modificando el software existen- ing. Ejemplos medición de software.
CON RESPECTO A comprensión del programa
incluye
Grubb y Takang 2003 [2

yoEEE / ISO / IEC 14764
2006 [1 *]
Sneed 2008
[3 *]
*]
1. Fundamentos de
mantenimiento de
software
1.1. Definiciones y terminología c3 c1s2, C2S2
1.2. Naturaleza de Mantenimiento c1s3
1.3. La necesidad de mantenimiento c1s5
1.4. La mayoría de los costos de c4s3, c5s5.2
mantenimiento
1.5. Evolución de Software c3s5
1.6. Categorías de Mantenimiento c3, c6s2 c3s3.1, c4s3
2. Temas clave en el
mantenimiento de
software
2.1. Problemas técnicos
2.1.1. La comprensión limitada c6
2.1.2. Pruebas c6s2.2.2 C9
2.1.3. Análisis de impacto c5s2.5 c13s3
2.1.4. mantenibilidad c6s8, c3s4 c12s5.5
2.2. Asuntos Gerenciales
2.2.1. Alineación con
c4
objetivos de la organización
2.2.2. dotación 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. Estimación de costes de
mantenimiento
2.3.1. Estimación de costos c7s4.1 c7s2.4
5-13
Grubb y Takang 2003 [2

yoEEE / ISO / IEC 14764
2006 [1 *]
Sneed 2008
[3 *]
*]
2.3.2. Los modelos paramétricos c12s5.6
2.3.3. Experiencia c12s5.5
2.4. Medición de
c6s5 c12, c12s3.1
mantenimiento de
software
2.4.1. Las medidas específicas 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. Planificación de
c7s2, c7s.3
mantenimiento
Ocupaciones
3.2.4. SoftwareGestión de la
c5s1.2.3 c11
configuración
3.2.5. Calidad del software c6s5, c6s7, c6s8 c12s5.3
4. Técnicas de Mantenimiento
4.1. programa de Comprensión c6, c14s5
4.2. reingeniería c7
4.3. Ingeniería inversa c6s2 c7, c14s5
4.4. Migración c5s5
4.5. Jubilación c5s6
5. Herramientas de Mantenimiento c6s4 c14
de Software
A. abril y A. Abran, Gestión de [1 *] IEEE Std. 14764-2006 (también conocido

Mantenimiento de Software: Evaluación y como ISO / IEC
Mejora Continua [6]. 14764: 2006) estándar para el software del
ciclo de vida del software de ingeniería y
Este libro explora el dominio de los procesos de procesos de mantenimiento, IEEE 2006.
mantenimiento de software pequeños (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 Práctica., 2ª ed,
organizaciones. En él se describe un modelo de Editorial Científico Mundial, 2003.
madurez específica mantenimiento de software
organizada por niveles que permiten la [3 *] HM Sneed, “Mantenimiento de Software
evaluación comparativa y la mejora continuas como un Servicio de Oferta Marino”, Proc.
con. Metas para cada área clave Tice prác- 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 Ingeniería
internacional ISO14764 y ISO15504 y modelos de Software: Una guía basada en
de madurez populares como ITIL, COBIT, estándares, 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 Ingeniería de Software-Vocabulario, ISO /
Int'l Conf. Mantenimiento Software IEC / IEEE 2010.
[7].
[6] A. abril y A. Abran, Gestión de
Este artículo presenta una visión general del Mantenimiento de Software: evaluación 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 términos de las actividades a Proc. Int'l Conf. Mantenimiento de
realizar y su orden, en función de la información Software, IEEE, 2001, pp. 500-509.
utilizada por estas actividades, metas, reglas y
motivaciones para su ejecución, y los niveles de
organización y roles involucrados en las
distintas etapas de un proceso típico de
mantenimiento correctivo.
5-15
CAPÍTULO 6
Software Configuration Management
SIGLAS para servir a un propósito particular.

Configuración hombre-agement (CM), a
CCB Configuration Control Board continuación, es la disciplina de que identifique
CM Gestión de la configuración los valores de la configuración de un sistema en
FCA Auditoría de Configuración distintos puntos en el tiempo con el fin de
Funcional sistemáticamente control- ling cambios en la
PCA Auditoría de Configuración física configuración y el mantenimiento de la
integridad y la trazabilidad de la configuración
Control de Configuración de
SCCE de todo el ciclo de vida del sistema. Se define
Software
formalmente como
SCI Tablero
Software Elemento de
Configuración
Gestión de la Configuración de Una disciplina aplicando dirección
SMC
Software adminis- tración y técnica y vigilancia a:
Plan de Gestión de la Configuración tificar iden- y documentar las
PGCS características funcionales y cal
de Software
Physicians de un elemento de
SCR Solicitud de cambio de software
configuración, los cambios de control a
Estado de la configuración de las características, el procesamiento y la
SCSA
software aplicación de registro y cambio de
SDD Contabilidad
Documento de Diseño de Software informe de estado, y verifican El
Capability Maturity Model cumplimiento con los requisitos
SEI / especificados. [1]
Integration de Software Engineering
CMMI
Institute
gestión de configuración de software (SCM)
es un proceso de ciclo de vida del software de
Requisito de software apoyo que beneficia a las actividades de gestión
SRS
Especificación de proyectos, desarrollo y mantenimiento,
actividades de aseguramiento de la calidad, así
como los clientes y usuarios del producto final.
INTRODUCCIÓN Los conceptos de gestión de la configuración
se aplican a todos los artículos que deben ser
Un sistema puede ser definido como la controlados, aunque hay algunas diferencias en
combinación de elementos organizados para la implementación de hardware entre el CM y
lograr uno o más propósitos declarados [1] CM software.
interactuar. La configuración de un sistema es la SMC está estrechamente relacionado con el
carac- terísticas funcionales y físicas de aseguramiento de la calidad (SQA) actividad
hardware o software que se exponen en técnica- de software. Tal como se define en el área de
cal documentación o conseguidos en un conocimiento de Calidad de Software (KA),
producto [1]; También se puede considerar SQA procesos garantizan que los productos de
como una colección de versiones específicas 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 planificación, la
específicos de construcción promulgación, y la realización de un conjunto de
actividades para proporcionar la confianza objetivos SQA. En algunos contextos proyecto,
adecuada de que la calidad se está los requisitos específicos SQA prescriben ciertas
construyendo en el software. actividades de actividades de SCM.
SCM ayudan en el cumplimiento de estos
6-1
Figura 6.1. Desglose de temas para el Software Configuration Management KA
Las actividades de la SCM son la gestión y la información de configuración. Desde la

Planificación del proceso de SMC, identificación perspectiva del ingeniero de software, SCM
de la configuración de software, el control de la facilita
configuración de software, la contabilidad de
estado de configuración de software, auditoría
de configuración de software, y la gestión de
versión de software y la entrega.
El software de configuración de
administración de KA se relaciona con los
demás Kas, ya que el objeto de la gestión de la
configuración es el artefacto pro ducido y
utilizado en todo el software de inge- niería
proceso.
DISTRIBUCIÓN DE TEMAS
PARA LA GESTIÓN DE
CONFIGURACIÓN DEL
SOFTWARE
El desglose de los temas para el Config-

Software de Gestión URACIÓN KA se muestra
en la Figura 6.1.
1. Gestión del Proceso de SMC
SCM controla la evolución y la integridad de un

producto mediante la identificación de sus
elementos; la gestión y el control del cambio; y
verificar, grabación, y la información sobre la
Configuración del software de gestión de 6-
el desarrollo y el cambio aplicación activi- 3
lazos. Una implementación exitosa de SMC
requiere una planificación y una gestión
cuidadosa. Esto, a su vez, requiere una
comprensión del contexto de la organización
para, y las limitaciones impuestas a, el diseño y
la implementación del proceso de SMC.
1.1. Contexto de organización de SMC

[2 *, c6, Ann. D] [3 *, la introducción] [4
*, c29]
Para planificar un proceso de SMC para un

proyecto, es preciso proceder a entender el
contexto de la organización y las relaciones
entre los elementos de la organización. SMC
interactúa con otras actividades o elementos de
la organización.
Los elementos de la organización
responsable de la ingeniería de software
procesos de apoyo pueden estructurarse de
varias maneras. Aunque la responsabilidad
para realizar ciertas tareas SCM podría ser
asignado a otras partes de la organización (por
ejemplo, la organización de desarrollo), el
responsabilidad 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 más grande que
contiene los elementos de hardware y
firmware. En este caso, las actividades se
llevan a cabo SCM
en paralelo con el hardware y el firmware CM el nivel de formalismo seleccionado para

actividades y deben ser compatibles con CM a implementar el software afecta al diseño y la
nivel de sistema. Tenga en cuenta que el implementación del proceso de SMC.
firmware contiene hardware y software; Por lo Una guía para el diseño y la implementación de
tanto, ambos conceptos CM de hardware y un proceso de SMC también se puede obtener de
software son aplicables. “mejores prácticas”, como se refleja en las normas
SMC podría interactuar con la actividad de sobre el software
aseguramiento de la calidad de una organización
en temas como la gestión de registros y
elementos no conformes. Respecto al primero,
algunos artículos bajo control SMC también
pueden incluir datos sobre los proyectos sujetos
a las disposiciones del programa de garantía de
calidad de la organización. La gestión 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
configuración de software que caen en esta
categoría.
Tal vez la relación más 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
configuración del software se con- canalizado.
Con frecuencia, las mismas herramientas
soportan desarrollo, el mantenimiento y los
propósitos de SCM.
1.2. Limitaciones y orientación para el

proceso SMC
[2 *, c6, Ann. D, Ann. E] [3 *, C2, C5]
[5 *, c19s2.2]
Limitaciones que afectan, y una guía para el

proceso de SMC provenir de varias fuentes.
normativas y procedimientos de exponen a
niveles de organización corporativos u otros
podrían influir o prescribir el diseño y la
implementación del proceso SMC para un
proyecto determinado. Además, el contrato entre
el comprador y el proveedor podría con-
disposiciones Tain que afectan el proceso de
SMC. Por ejemplo, podrían ser necesarias
ciertas auditorías de configuración, o puede ser
especificado que ciertos artículos pueden colocar
bajo CM. Cuando los productos de software para
ser desarrollados tienen el potencial de afectar a
la seguridad pública, 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
Configuración
1.3.1. Organización del software de gestión
y responsabilidades de 6-
SMC
ingeniería emitido por las diversas normas 5
organizaciones (ver Apéndice B de las [2 *, Ann. DS5, Ann. DS6] [3 *, c10-
normas). 11]
[4 *, introducción,
1.3. La planificación de SMC c29]
[2 *, c6, Ann. D, Ann. E] [3 *, c23] [4 *,
c29] Para evitar la confusión sobre quién desarrollará
dada actividades de SCM o tareas, la organización
La planificación de un proceso de SMC para
un proyecto dado debe ser coherente con el
contexto organiza- zational, las restricciones
aplicables, comúnmente aceptado orientación
com-, y la naturaleza del proyecto (por
ejemplo, el tamaño, la criticidad de seguridad,
y la seguridad). Las principales actividades
cubiertas son la identificación del software de
configuración, control de configuración de
software, la contabilidad de estado de
configuración de software, auditoría de
configuración de software, y la gestión de
versión de software y la entrega. Además,
cuestiones como la organización y
responsabilidades, recursos y horarios, la
selección de herramientas y la aplicación, el
control de proveedores y subcontratistas, y el
control de la interfaz son típicamente sidered
con-. Los resultados de la actividad de
planificación se registran en un Plan de SCM
(SCMP), que es Tıpicamente sujeto a SQA
revisión y auditoría.
Ramificación 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 evolución de versiones de
archivo fuente [1]. La fusión consiste en la
combinación de diferentes cambios en el
mismo archivo [1]. Este Tıpicamente se
produce cuando más de una persona cambia de
un elemento de configuración. Hay muchas
estrategias de ramas y la mezcla de uso común
(véase la sección Lecturas adicionales para una
discusión adicional).
El modelo de ciclo de vida de desarrollo de
software (véase el ciclo de vida del software
Modelos en el proceso de ingeniería de
software KA) también afecta SCM actividades,
y la planificación SMC debe tener esto en
cuenta. Por ejemplo, la integración continua es
una práctica común en muchos enfoques desa-
rrollo de software. Por lo general se caracteriza
por ciclos de acumulación de prueba de
implementar frecuentes. SCM actividades
deben planificarse en consecuencia.
papeles para que participen en el proceso de mantenimiento, formación, y la

SMC deben ser claramente identificados. Las personalización?
responsabilidades específicas para las • Alcance: cómo se deployed- las nuevas
actividades o tareas SCM dados también tienen herramientas, por ejemplo, a través de toda la
que ser asignados a entidades de organización, organización o sólo en proyectos específicos?
ya sea por título o por el elemento de la • Propiedad: ¿quién es el responsable de la
organización. Los informes dad y canales introducción de nuevas herramientas?
globales de Autor-SMC también deben ser
identificados, aunque esto puede ser logrado en
la etapa de planificación de la gestión de
proyectos o la garantía de calidad.
1.3.2. Recursos SCM y horarios

[2 *, Ann. DS8] [3 *,
c23]
La planificación de SMC identifica el personal y

las herramientas que participan en la realización
de actividades y tareas de SCM. Se abordan
cuestiones de programación 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 planificación. También se
especifican los requisitos de formación
necesarios para la ejecución de los planes y la
formación de los nuevos miembros del personal.
1.3.3. Herramienta Selección e

implementación
[3 *, c26s2, c26s6] [4 *,
c29s5]
En cuanto a cualquier área de la ingeniería de

software, la selección e implementación de
herramientas de SCM deben ser cuidadosamente
planificadas. Los siguientes preguntas deben
ser considerados:
• Organización: lo que motiva adquisi- ción

de herramientas desde una perspectiva
organizacional?
• Herramientas: podemos utilizar
herramientas comerciales o a desarrollar
nosotros mismos?
• Medio Ambiente: ¿cuáles son las
limitaciones impuestas por la organización
y su téc- nico contexto?
• Legado: cómo utilizarán los proyectos (o
no) las nuevas herramientas?
• Financiación: ¿quién va a pagar por la
adquisición de las herramientas,
• Futuro: ¿cuál es el plan para el uso de las ser establecidos. Configuración
Este últimodel software
incluyede gestión
la de 6-
7
herramientas en el futuro? consideración de lo que debe estar disponible
• Cambiar: su capacidad de adaptación son las para la vigilancia del cumplimiento efectivo de
herramientas? información SMC.
• Ramas y la mezcla: son capacidades de
dichas herramientas compatibles con el ing
rama-planificada y estrategias de la
fusión?
• Integración: hacer las diferentes
herramientas de SCM inte- rejilla entre sí?
Con otras herramientas en uso en la
organización?
• Migración: 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 configuración
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 consideración importante
en la Planificación para la selección de la
herramienta es determinar si el banco de
trabajo SMC estará abierto (en otras palabras,
las herramientas de diferentes proveedores
serán utilizados en diferentes actividades del
proceso SMC) o integrada (donde se han
diseñado elementos del banco de trabajo para
trabajar juntos).
El tamaño de la organización y el tipo de
proyectos que participan también puede afectar
a la selección de herramientas (ver tema 7,
Configuración 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 planificación SMC considera
si y cómo se tomarán estos elementos bajo
control con- figuración (por ejemplo, integrado
en las bibliotecas proyecto) y cómo van a ser
evaluados y gestionados cambios o
actualizaciones.
Consideraciones similares se aplican al
software subcontratado. Al utilizar el software
de subcontratación, 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
1.3.5. control de • Horarios de SCM (coordinación con otro

interfaz [2 *, c12] [3 *, actividades del proyecto)
c24s4] • Recursos SCM (herramientas, recursos
físicos,
Cuando un elemento de software de interfaz con responsabilidades, autoridades, las políticas
otro elemento de software o hardware, un aplicables, directivas y procedimientos)
cambio a cualquiera de elemento puede afectar • Actividades SCM (identificación de la
al otro. La planificación para el proceso SMC configuración, control de configuración, etc.)
considera cómo se identificarán los elementos de
interfaz y cómo se gestionen y cambios en los
elementos. El papel SCM puede ser parte de un
proceso de sistema de nivel más grande para la
especificación 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 planificación
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 planificación SMC para un

proyecto dado se registran en una configuración
de software management Plan (SCMP), un
“documento vivo” que sirve como referencia
para el proceso de SMC. Se mantiene (es decir,
actualizada y aprobada) según sea necesario
durante el ciclo de vida del software. En
Menting imple- PGCS, normalmente es
necesario desarrollar una serie de
procedimientos más detallados, subordinados
que define cómo los requisitos específicos se
llevará a cabo durante actividades- del día a día,
por ejemplo, que se utilizarán estrategias de
ramificación y con qué frecuencia se basa
ocurrir y auto-pruebas apareadas de todo tipo se
ejecutan.
Orientación sobre la creación y mantenimiento
de un PGCS, basado en la información
producida por la actividad de planificación, está
disponible a partir de diversas fuentes, como por
ejemplo [2 *]. Esta referencia proporciona
requisitos para la información a ser contenida en
un SCMP; También define y describe seis
catego- rías de información SMC que deben
incluirse en un SCMP:
• Introducción (propósito, el alcance, los

términos utilizados)
• Gestión de SMC (organización,
y recursos humanos) Configuración del software de gestión de 6-
9
• Mantenimiento SCMP.
1.5. La vigilancia de la Gestión de la

Configuración de Software
[3 *,
c11s3]
Después 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 auditoría El cumplimiento,
también puede realizar esta vigilancia.
El uso de herramientas de SCM integrados
con capacidad de control de procesos puede
hacer más fácil la tarea de vigilancia. Algunas
herramientas facilitan el proceso pliance com-
mientras que proporciona flexibilidad para el
ingeniero de software 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 selección de herramientas.
1.5.1. Medidas de SCM y Medición

[3 *, c9s2, c25s2-
s3]
SCM medidas pueden ser diseñados para

proporcionar información CIFIC espe- sobre el
producto en evolución o para proporcionar
información 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 provisión de una
base para hacer comparaciones en el tiempo. El
análisis de las mediciones puede producir
ideas que lleva a procesar los cambios y 2.1. Los productos que la identificación 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 información
acerca de las características del proceso de SMC Uno de los primeros pasos en el cambio de control
(así como el suministro de información agement es
hombre-proyecto y). Por ejemplo, información la identificación de los elementos de software que
se desea controlar.
sobre el tiempo requerido para llevar a cabo
varios tipos de cambios sería útil en una evalua-
ción de los criterios para determinar qué niveles
de autoridad son óptimas para la autorización de
ciertos tipos de cambios y para la estimación 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 discusión de los
procesos de software y medición del producto se
presenta en el Proceso de Cesión de Software
Ingeniería KA. programas de software surement
Measure se describen en el Software
Engineering Management KA.
1.5.2. En-Proceso de Auditorías de SMC

[3 *,
C1S1]
Las auditorías pueden ser llevadas a cabo

durante el proceso de ingeniería de software para
investigar la tus esta- actual de elementos
específicos de la configuración o para evaluar la
aplicación del proceso de SMC. En-proceso de
auditoría de SMC proporciona un mecanismo
mal más para- para el seguimiento de los
aspectos seleccionados del proceso y puede ser
coordinado con la función SQA (ver tema 5,
Software configuraciones Auditoría ción).
2. Identificación de la configuración de
software
[2 *, c8] [4 *,
c29s1.1]
identificación de la configuración de software

identifica los elementos a controlar, establece
esquemas de identificación de los elementos y
sus versiones, y establece las herramientas y
técnicas a utilizar en la adquisición y gestión de
elementos controlados. Estas actividades
proporcionan la base para las otras actividades
de la SCM.
seguimiento adecuadoConfiguración del software
de estas de gestión de 6-
relaciones
Esto implica la comprensión de la 11
configuración del software en el contexto de la también es importante para apoyar la
configuración del sistema, la selección de los trazabilidad. El diseño del esquema de
elementos de configuración de software, identificación para LIC
desarrollo de una estrategia para los elementos
de software de etiquetado y la descripción de
sus relaciones, y la identificación tanto de las
líneas de base a ser utilizados y el
procedimiento para la adquisición de una línea
de base de los artículos.
2.1.1. Configuración del software

[1, c3]
configuración del software son las

características funcionales y ical phys- de
hardware o software como se indica en la
documentación técnica o se alcance en un
producto. Puede ser visto como parte de una
configuración general del sistema.
2.1.2. Software Elemento de Configuración

[4 *, c29s1.1]
Un elemento de configuración (CI) es un

elemento o agregación gación de hardware o
software o ambos que está diseñado para ser
manejado como una sola entidad. Un elemento
de configuración de software (SCI) es una
entidad de software que se ha establecido como
un elemento de configuración [1]. El SCM
controla típicamente una variedad de artículos,
además del propio código. los elementos de
software con potencial para convertirse en LIC
incluye planes, especificaciones y
documentación de diseño, pruebas de mate-
riales, herramientas de software, la fuente y el
código ejecutable, librerías de código, datos y
diccionarios de datos y documentación para la
instalación, mantenimiento, operaciones, y el
uso de software .
Selección 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 número manejable de artículos controlados.
2.1.3. Software Relaciones

elemento de configuración
[3 *, c7s4]
Las relaciones estructurales entre los LIC

seleccionados, y sus partes constituyentes,
afectan a otras actividades o tareas SCM, tales
como la construcción de software o el análisis
del impacto de los cambios propuestos.
Figura 6.2. Adquisición de artículos
debe considerar la necesidad de asignar todos los cambios aprobados en la línea de base,
elementos identificados a la estructura del representa la configuración actual aprobado.
software, así como la necesidad de apoyar la líneas de base utilizados comúnmente incluyen
evolución de los elementos de software y sus funcional, asignado, de desarrollo, y el producto
relaciones.
2.1.4. Versión del software

[1, c3] [4 *, c29s3]
los elementos de software evolucionar como

Ceeds pro de proyectos de software. Una versión
de un elemento de software es una instancia
identificado de un elemento. Puede ser
considerado como un estado de un elemento en
evolución. Una variante es una versión de un
programa resultante de la aplicación de la
diversidad software.
2.1.5. Base
[1, c3]
Una línea de base software es un aprobado

formalmente ver- sión de un elemento de
configuración (con independencia de los medios
de comunicación) que se designa formalmente y
se fija en un momento específico durante el ciclo
de vida del elemento de configuración. El
término también se utiliza para referirse a una
ver- sión particular de un elemento de
configuración de software que ha sido acordado.
En cualquier caso, la línea de base sólo puede
modificarse a través de procedimientos trol das a
cambios formales. Una línea de base, junto con
líneas de base. La línea de base funcional 13
corresponde a los requisitos del sistema
revisado. La línea de base asignarse los
corresponde a la especificación de requisitos de
software y los requisitos de la interfaz de
software revisado. La línea de base del
desarrollo representa la configuración de
software que evoluciona a la hora seleccionada
durante el ciclo de vida del software. Cambio
autoridad de esta línea de base normalmente
recae principalmente en la organización de
desarrollo, sino que puede ser compartida con
otras organizaciones (por ejemplo, SMC o de
prueba). La línea de base del producto se
corresponde con el producto de software para
la integración completado entregado sistema.
Las líneas de base a utilizar para un proyecto
dado, junto con los niveles asociados de
autoridad necesario para la aprobación del
cambio, son Tıpicamente identificado en el
SCMP.
2.1.6. La adquisición de elementos de

configuración de software
[3 *, c18]
los elementos de configuración de software se

colocan bajo control SCM en diferentes
momentos; es decir, que se incorporan en una
línea de base en particular en un punto
particular en el ciclo de vida del software. El
evento desencadenante es la realización de
algún tipo de tarea formal de aceptación, tales
como una revisión formal. Figura
6.2 caracteriza el crecimiento de los artículos
baselined medida que avanza el ciclo de vida.
Esta cifra se basa en el modelo de cascada para
los propósitos de la ilustración solamente; los
subíndices usados en la figura indican
versiones
de los elementos cambiantes. La solicitud de qué cambios hacer, la autoridad de approv- ing
cambio de software ciertos cambios, el apoyo a la ción ¡Ejecución de
(SCR) se describe en la sección 3.1. esos cambios, y el concepto de desviaciones
En la adquisición de un SCI, se deben formales de los requisitos del proyecto, así como
establecer su origen y integridad inicial. exenciones de ellos. La información derivada de
Después de la adquisi- ción de un SCI, cambios estas actividades es útil en la medición de tráfico
en el elemento debe ser formalmente aprobado el cambio y la rotura, así como los aspectos de
como adecuado para el SCI y la línea de base reproceso.
que participan, como se define en el PGCS.
Después de la aprobación, el elemento se 3.1. Solicitar, evaluar y cambios que aprueba
incorpora en la línea 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 gestión de cambios para
controlada
artículos es determinar qué cambios hacer. los
Una biblioteca de software es una colección trabajo y progreso.
controlada de software y la documentación
relacionada diseñado para ayudar en el 3. Control de Configuración de Software
desarrollo de software, uso o mantenimiento [1]. [2 *, c9] [4 *, c29s2]
También es fundamental para la versión de
software agement hombre- y actividades de control de la configuración de software se ocupa
entrega. Existen varios tipos de bibliotecas de la gestión de cambios durante el ciclo de vida
podrían 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
podría apoyar la codificación y una biblioteca de
soporte proyecto podría apoyar de Exámenes,
mientras que una librería maestra podría ser
utilizado para productos terminado. Un nivel
adecuado de SCM trol con- (línea de base y el
nivel de autoridad para el cambio asociado) está
asociado con cada biblioteca. Seguridad, en
términos de control de acceso y las instala- copia
de seguridad, es un aspecto clave de la gestión
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 términos de control de LIC y
controlar el acceso a la biblioteca. A nivel
biblioteca de trabajo, se trata de una capacidad
de gestión de código 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 múltiples desarrolladores. En los
niveles más altos de control, el acceso es más
restringida y SCM es el usuario principal.
Estas bibliotecas son también una importante
fuente de información para las mediciones de
software de proceso de solicitud de cambio Configuración del software de gestión de 6-
15
(véase un flujo típico de un proceso de
solicitud de cambio en la figura 6.3)
proporciona procedimientos formales para la
presentación 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 petición para expandir o reducir el alcance
del proyecto; modificar las políticas, procesos,
planes o procedimientos; modificar los costos o
presupuestos; o horarios Revisar [1]. Las
solicitudes de cambios en el software artículos
con- figuración pueden ser originados por
cualquier persona en cualquier momento del
ciclo de vida del software y pueden incluir una
propuesta de solución y la prioridad solicitada.
Una fuente de un CR es el inicio de una acción
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 recolección de las
mediciones por tipo de actividad el cambio
cambio. Una vez que se recibe una SCR, una
evaluación técnica (también conocido como un
análisis de impacto) se lleva a cabo para
determinar la extensión de las modificaciones
que serían necesarias se debe aceptar la
solicitud de cambio. Una buena comprensión
de las relaciones entre el software (y,
posiblemente, el hardware) elementos es
importante para esta tarea. Por último, una
autoridad realizó medición-com- establecida
con la línea de base afectada, el SCI
involucrados, y la naturaleza del cambio
evaluará los aspectos técnicos y de gestión de
la solicitud de cambio y, o bien aceptar,
modificar, rechazar o posponer el cambio
propuesto.
Figura 6.3. Flujo de un proceso de control de cambios
3.1.1. Junta de Control de Configuración 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 procedimientos 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 típicamente
conocida como un tablero de control de
configuración (CCB). En proyectos más
pequeños, esta autoridad puede residir de
manera efectiva con el líder 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 carácter crítico 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 composición de los CCBs se
utilizan para un sistema dado varía en función de
estos criterios (un representante SCM siempre
estaría presente). Todos los interesados, de
acuerdo al nivel de la CCB, están representados.
Cuando el alcance de la autoridad de un CCB es
estrictamente cerámica blandas, que se conoce
como una Junta de Control de Configuración de
Software (SCCE). Las actividades de la CCB
son típicamente sujetos a auditoría o revisión de
calidad del software.
3.1.2. Software Proceso de Solicitud de

Cambio
[3 *, c1s4,
c8s4]
decisiones CCB, y la información del proceso 17
de cambio que se informa. Un vínculo 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 aplicación

[4 *, c29]
SCRs aprobados se implementan utilizando los

procedimientos de software definidos de
acuerdo con los requisitos de programación
aplicables. Puesto que un número de SCRs
aprobados podría implementarse de forma
simultánea, es necesario proporcionar un
medio para el seguimiento que SCRs se
incorporan en las versiones de software
particulares y líneas de base. Como parte del
cierre del proceso de cambio, cambios pletó
com- pueden someterse a auditorías de
configuración y la calidad del software de
verificación-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) información de aprobación para
el cambio.
Los cambios pueden ser apoyadas por
herramientas de control de código fuente sión
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 código fuente.
Estas herramientas proporcionan un único
repositorio para almacenar el código fuente,
puede evitar más de un ingeniero de software
de la edición del mismo módulo, al mismo
tiempo, y registrar todos los cambios
realizados en el
código fuente. Los ingenieros de software de sistema de información, la información de

verificación módulos del repositorio, hacer estado de configuración para ser administrado
cambios, documentar los cambios, a por los las configuraciones cambiantes deben ser
continuación, guarde los módulos editados en el identificados, recogidos, y mantenido. Diversa
repositorio. Si es necesario, los cambios también información y las mediciones son necesarias
pueden ser descartados, la restauración de una para apoyar el proceso de SMC y para cumplir
línea de base anterior. herramientas más potentes con el estado de con- figuración necesidades de
pueden apoyar el desarrollo paralelo y entornos información de gestión, ingeniería de software, y
distribuidos geográficamente. Estas otras actividades relacionadas. Los tipos de
herramientas se pueden manifestar como información disponibles incluyen la
aplicaciones independientes, especializados bajo identificación de la configuración aprobada, así
el control de un grupo independiente SMC. como la identificación y tus implementación
También pueden aparecer como una parte actual de esta- cambios, desviaciones, y las
integrada del entorno de la ingeniería 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 podría 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 más
amplio e integrado.
Las limitaciones impuestas a un software
Engineer- esfuerzo ing o las especificaciones 4.2. Informes de estado de configuración de
que se producen durante las actividades de software
desarrollo podría contener disposiciones que no [2 *, c10s2.4] [3 *, c1s5, c9s1, c17]
pueden ser satisfechas en el punto designado en
el ciclo de vida. Una desviación es un rización información reportada puede ser utilizado por
autori- escrita, otorgada con anterioridad a la varios elementos, incluyendo los proyectos de
fabricación de un elemento, para apartarse de organización y el equipo de desarrollo, el equipo
una actuación en particular o requisito de diseño de mantenimiento, gestión de proyectos, y la
para un número determinado de unidades o un calidad del software actividades. Informes
período específico de tiempo. Una renuncia es pueden tomar la forma de Que- hoc Ries
un diez autorización ESCRITO para aceptar un anuncios para responder a preguntas específicas
elemento de configuración o de otro elemento o la producción periódica de informes
designado que se encuentra, durante la produc- prediseñados. Algunos infor- mación producida
ción o después de haber sido presentado para su por la actividad contable de estado durante el
inspección, a apartarse de los requisitos curso del ciclo de vida podría convertirse en los
especificados, pero se considera ertheless nev- registros de control de calidad.
adecuado para uso como-es o después de la Además de informar el estado actual de la
reanudación por un método aprobado. En estos configuración, la información obtenida por el
casos, un proceso formal se utiliza para obtener SCSA puede servir como base de diversas
la aprobación de las desviaciones de las mediciones. Los ejemplos incluyen el número 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
configuración 5. Auditoría de configuración de software
[2 *, c10]
gestionar una configuración efectiva.
Software de contabilidad estado de
configuración (SCSA) es un elemento de gestión 4.1. Software de información de estado de
de la configuración sisting con- del registro y la configuración
notificación de la informa- ción necesaria para [2 *, c10s2.1]
Los diseños de actividad SCSA y opera un sis- Configuración del software
[2 *,dec11]
gestión de 6-
19
tema para la captura y presentación de la
información necesaria a medida que avanza el Una auditoría de software es una examina- ción
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
auditorías se llevaron a cabo de acuerdo con un
proceso bien definido que consiste en diversas
funciones y responsabilidades auditor. En
consecuencia, cada auditoría debe ser
cuidadosamente planificado. Una auditoría
puede requerir un nú- mero de personas para
realizar una variedad de tareas durante un
período relativamente corto de tiempo.
Herramientas de apoyo
11
la planificación y realización de una auditoría desarrollo.

pueden facilitar enormemente el proceso.
auditoría de configuración software determina 6. Gestión de la Entrega de Software y
el grado en que un elemento satisface las Entrega
características funcionales y físicas requeridas. [2 *, c14] [3 *, c8s2]
auditorías informal de este tipo puede llevarse a
cabo en puntos clave del ciclo de vida. Hay dos En este contexto, la liberación se refiere a la
tipos de auditorías formales podrían ser distribu- ción de un elemento de configuración de
requeridos por el contrato que rige (por ejem- software fuera
plo, en los contratos que cubren software
crítico): la Auditoría funcional de configuración
(FCA) y la configuración de auditoría física
(PCA). La conclusión con éxito de estas
auditorías puede ser un requisito previo para el
establecimiento de la línea base del producto.
5.1. Software de Auditoría de Configuración

Funcional
[2 *, c11s2.1]
El propósito de la FCA software es para

asegurar que el elemento de software auditado es
consistente con sus especificaciones de
gobierno. La salida de las mercancías de las
actividades de verificación y validación blandos
(véase Verificación y validación en el software
de calidad KA) es un insumo clave para esta
auditoría.
5.2. Auditoría de Configuración física de

software
[2 *, c11s2.2]
El propósito de la auditoría de software guración

física ción (PCA) es asegurar que la
documentación de proyectos y de referencia es
consistente con el producto de software como
incorporado.
5.3. En-Proceso de Auditorías de una línea de

base del software
[2 *, c11s2.3]
Como se mencionó anteriormente, las auditorías

pueden ser llevadas a cabo durante el proceso de
desarrollo para investigar el estado actual de los
elementos específicos de la con- figuración. En
este caso, una auditoría se podría aplicar a los
elementos de línea de base de la muestra para
asegurar que per- formance es consistente con
las especificaciones o para asegurar que la
documentación evolución sigue siendo
compatible con el elemento de referencia en
6-12 Guía SWEBOK® V3.0 software proporcionan esta capacidad. Estas
la actividad de desarrollo; esto incluye
comunicados internos, así como la distribución herramientas varían en complejidad desde que
a los clientes. Cuando diferentes versiones de requiere el ingeniero de software para aprender
un elemento de software están disponibles para un lenguaje de script espe- cializada a los
la entrega (tales como versiones para diferentes enfoques orientados a gráficos que ocultan gran
formas plataformas o versiones con diferentes parte de la complejidad de una instalación de
capacidades), frecuentemente es necesario acumulación “inteligente”.
volver a crear versiones específicas y El proceso de construcción y los productos
empaquetar los materiales adecuados para la son a menudo sub- ject de verificación de la
entrega de la versión. La biblioteca de software calidad del software. Las salidas de
es un elemento clave en la realización de tareas
de liberación y entrega.
6.1. Edificio de software

[4 *,
c29s4]
Software edificio es la actividad de la

combinación de las versiones correctas de los
elementos de configuración de software,
utilizando los datos de configuración
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 actividad de la capacidad del
sistema. Construir instrucciones de asegurar
que las medidas adecuadas de construcción se
toman en la secuencia correcta. Además de la
creación de software para los nuevos
lanzamientos, por lo general es también
necesaria para SMC para tener la capacidad de
reproducir versiones anteriores para la
recuperación, pruebas, mantenimiento, o para
fines de liberación adicionales.
El software se construye a partir de versiones
particulares de herramientas de apoyo, tales
como compiladores (véase Fundamentos Piler
Com- en los Fundamentos de Informática KA).
Puede ser que sea necesario reconstruir una
copia exacta de un elemento de configuración
de software previamente construida. En este
caso, las herramientas de apoyo y las
instrucciones de construcción 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
selección de las versiones rect angulares del
elementos de software para un entorno de
destino dado y para automatizar el proceso de
construcción del software de las versiones
seleccionadas y datos de configuración
apropiados. Para proyectos con ambientes
desarrollo paralelos o distribuidos, esta
capacidad herramienta es necesaria. La
mayoría de los entornos de ingeniería de
13
el proceso de construcción podría 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. Gestión de la Entrega de Cuando se habla de herramientas Ment manage-

Software [4 *, c29s3.2] de configuración de software, es útil para
clasificarlos. herramientas de SCM se pueden
dividir en tres clases en términos
gestión de versiones de software abarca la contenidos de liberación de los SCR que se han
identificación, el empaquetado, y la entrega de recibido. Esta capacidad herramienta también
los elementos de un ejemplo de producto-para, puede mantener información sobre diversas
un programa capaz execut-, documentación, plataformas de destino y en diversos entornos de
notas de la versión, y datos de configuración. clientes.
Teniendo en cuenta que los cambios de producto
pueden producirse de manera continua, una
preocupación por la gestión de la liberación es
determinar cuándo deben emitir un comunicado.
La gravedad de los problemas abordados por la
liberación y la medición de la falla densidades
de las versiones anteriores afectan a esta
decisión. La tarea de envasado debe identificar
qué producto artículos son para ser entregados y
luego seleccione las variantes correctas de esos
elementos, dada la aplica- ción previsto del
producto. La información documento- ing el
contenido físico de un comunicado se conoce
como un documento de descripción de la
versión. Las notas de la versión describen
típicamente nuevas capacidades, problemas
conocidos y requisitos de plataforma necesarios
para el funcionamiento adecuado del producto.
El paquete que se lanzará también contiene
instrucciones de instalación o actualización. Este
último puede ser complicado por el hecho de
que algunos usuarios actuales podrían tener
versiones que son varias las viejas versiones. En
algunos casos, la administración de liberación
puede ser necesario con el fin de realizar un
seguimiento de la distribución 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 recién denunciados. Por último, un
mecanismo para asegurar la integridad del
artículo publicado se puede implementar, por
ejemplo mediante la liberación de una firma
digital con él.
Se necesita una capacidad de herramienta
para apoyar estas funciones de gestión de
versiones. Se uso-ful tener una relación con la
capacidad de herramienta de apoyo al proceso de
solicitud de cambio con el fin de asignar los
6-14 Guía SWEBOK®
del ámbito V3.0 a
de aplicación la que proporcionan
apoyo: el apoyo vidual indicación, 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
pequeñas 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 configuración individuales como el
código fuente y la documentación externa.
• Construir herramientas de manipulación:
en su forma más simple, este tipo de
herramientas de compilación y enlace para
una versión ejecutable del software. Más
herramientas avanzadas de construcción
extracto de la última versión del software
de control de versiones, realizar
comprobaciones de calidad, ejecutar
pruebas de regresión, 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- ficación (por
ejemplo, cambios en el estado de solicitud
de cambio, los hitos alcanzados).
herramientas de apoyo relacionados con el

proyecto principal respaldar la gestión 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 certificación.
herramientas de apoyo en procesos de toda
la compañía puede Tıpicamente automatizar
partes de un proceso de toda la compañía,
proporcionando soporte para mentos de flujo
de trabajo manage-, roles y responsabilidades.
Ellos son capaces de manejar muchos artículos,
datos y ciclos de vida. Estas herramientas se
suman el apoyo relacionados con el proyecto
mediante el apoyo a un proceso de desarrollo
más formal, incluyendo los requisitos de
certificación.
15
2011 [4 *]
2012 [2
2006 [5
Hass 2003
SommervilLe
yoEEE 828-
[3 *]
Mugirre
*]
*]
1. Gestión del Proceso de SMC
1.1. Contexto de organización de

c6, ann.D Introducción c29
SMC
1.2. Limitaciones y c6, ann.D,
c2 c19s2.2 introducción
orientación para el proceso Ana
c29
SMC c6, ann.D,
1.3. La planificación de SMC c23 c29
Ana
1.3.1. Organización y SMC
ann.Ds5-6 c10-11 introducción
Responsabilidades
c29
1.3.2. Recursos y SCM
ann.Ds8 c23
horarios
1.3.3. Selección de
c26s2; s6 c29s5
herramientas y
Implementación
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
Gestión de la configuración
1.5.1. Medidas SCMy c9s2;
Medición c25s2-s3
1.5.2. En-Proceso de
C1S1
Auditorías de SMC
Identificación 2.
c29s1.1
Configuración del
software
2.1. La identificación de
c8s2.2 c29s1.1
elementos que se van
Revisado
2.1.1. Configuración del
software
2.1.2. SoftwareElemento de
c29s1.1
configuración
2.1.3. SoftwareRelaciones
c7s4
entre los elementos de
configuración
2.1.4. Versión del software c29s3
2011 [4 *]
2012 [2
2006 [5
Hass 2003
SommervilLe
yoEEE 828-
[3 *]
Mugirre
*]
*]
2.1.5. Base
2.1.6. Software de
c18
adquisición de
Elementos
2.2. softwarede configuración
Library c1s3 c29s1.2
3. Configuración del software
C9 c29s2
Controlar
3.1. Solicitar, evaluar,Los
c9s2.4 c29s2
cambios que aprueba y
Software
3.1.1. Configuración del
c9s2.2 c11s1 c29s2
software
Tabla de control
3.1.2. Software Proceso
c1s4, c8s4
de Solicitud de Cambio
3.2. La implementación de
c29
software
cambios
3.3. Desviaciones y renuncias
4. Configuración de Software
c10
Determinación del estado de
4.1. SoftwareInformación de
c10s2.1
estado de configuración
4.2. Configuración del c1s5, c9s1,
c10s2.4
software c17
5. Informes de estado
Configuración del software
c11
Revisión de cuentas
5.1. software funcional
c11s2.1
Auditoría de configuración
5.2. software física
c11s2.2
Auditoría de configuración
5.3. En-Proceso de auditorías
c11s2.3
de una
6. Línea de basededel software
El software
c14 c8s2 c29s3
administración de
lanzamientos
6.1. EdificioydeEntrega
software c29s4
6.2. Lanzamiento de software
c29s3.2
administración
7. Configuración del software
c26s1
Herramientas administrativas
17
Stephen P. Berczuk y Brad Appleton, Patrones [1] ISO / IEC / IEEE 24765: 2010 Sistemas y de
de Gestión de la Configuración de Ingeniería de Software-Vocabulario, ISO /
Software: El trabajo en equipo eficaz, IEC / IEEE 2010.
práctica Integración [6].
[2 *] IEEE Std. 828-2012, Norma para Sistemas
Este libro expresa prácticas de SCM y de Gestión de la Configuración de Software
estrategias útiles como patrones. Los patrones e Ingeniería, IEEE 2012.
pueden ser implementado utilizando diversas
herramientas, sino que se expresa de una manera [3 *] AMJ Hass, Principios y Prácticas de
independiente del instrumento. gestión de configuración, 1st ed., Addison-
Wesley, 2003.
“CMMI para el Desarrollo”, versión 1.3, pp.
137-147 [7]. [4 *] I. Sommerville, Ingeniería de Software, 9ª
Este modelo presenta una recopilación de las
mejores ticas ticas para ayudar a las [5 *] JW Moore, La Hoja de Ruta de Ingeniería
organizaciones de desarrollo de software a de Software: Una guía basada en
mejorar sus procesos. En el nivel de madurez 2, estándares, Wiley-IEEE Computer Society
sugiere actividades de gestión de configuración. Press, 2006.
[6] SP Berczuk y B. Appleton, Patrones de

Gestión de la Configuración del Software:
El trabajo en equipo, la integración
práctica, Addison-Wesley Professional,
2003.
[7] CMMI equipo de productos, “CMMI para

el Desarrollo, Versión 1.3,” Software
Engineering Institute, 2010; http: //
resources.sei.cmu.edu/library/asset-view.
cfm? assetId = 9661.
CAPÍTULO 7
GESTIÓN DE INGENIERÍA DE SOFTWARE

SWX.
SIGLAS
PMBOK® Guía para la Dirección de Proyectos

Guía del Conocimiento
SDLC Ciclo de vida del desarrollo de
SEM programas
Extensión de software para el
SWX
PMBOK®
WBS Guía
Estructura de desglose del trabajo
INTRODUCCIÓN
la gestión de la ingeniería de software se puede

definir como la aplicación de gestión de las
actividades de planificación, coordinación,
medición, monitoreo, pesca de arrastre con- y
informes1-para asegurar que los productos de
software y servicios de ingeniería de software se
entregan de manera eficiente, efectiva y en
beneficio de grupos de interés. La disciplina
relacionada tienen una gestión es un elemento
importante de todas las áreas de conocimiento
(KAS), pero por supuesto es más relevante para
este KA que a otros KAs. La medición es
también un aspecto importante de todos los
KAs; el tema de los programas La medición se
presenta en este KA.
En un sentido, debería ser posible para
gestionar un proyecto de ingeniería de software
de la misma manera se gestionan otras
actividades complejas. Sin embargo, hay
aspectos específicos de los proyectos de
software y procesos del ciclo de vida del
software que complican la gestión eficaz,
incluyendo los siguientes:
1 Los términos inicio, planificación, ejecución,

seguimiento y control, y de cierre se utiliza para
describir grupos de proceso en el PMBOK® Guía y
• A menudo hay una rápida tasa de cambio en
• Los clientes a menudo no saben lo que se la tecnología subyacente.
necesita o lo que es factible.
• Los clientes a menudo carecen de actividades de gestión de la ingeniería de
reconocimiento por las complejidades software se producen en tres niveles: gestión de
inherentes a la ingeniería de software, en la organización y estructura de infraestructura,
particular sobre el impacto de los gestión de proyectos y gestión del programa de
requisitos de ING cambios. medición. Los dos últimos se tratan en detalle en
• Es probable que el aumento de la esta descripción KA. Sin embargo, esto no es
comprensión y las condiciones cambiantes para disminuir la importancia de los problemas
generarán requisitos nuevos o modificados de gestión de la organización y de
de software. infraestructura. En general se acepta que los
• Como resultado de cambios en los gerentes de ingeniería de software de
requisitos, software se construye a organización deben estar familiarizados con el
menudo usando un proceso iterativo en proyecto management conocimiento y la
lugar de como una secuencia de tareas medición del software descrito en este KA.
cerradas. También deben poseer algunos conocimientos de
• La ingeniería de software incorpora dominio de destino. Del mismo modo, también
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 difícil. conscientes de las diferencias que los procesos
• El grado de novedad y complejidad es a de software introducen en la gestión de
menudo alta. proyectos y la medición del proyecto.
7-1
Figura 7.1. Desglose de temas para la Ingeniería de Software de Gestión de KA
Otros aspectos de la gestión de las analizar los resultados anteriores proyecto e
organizaciones ejercen un impacto en la implementar mejoras).
ingeniería de software (por ejemplo, políticas de
la organización y los procedimientos que
constituyen el marco en el que se llevan a cabo
proyectos de ingeniería de software). Estas
normativas y procedimientos de pueden
necesitar ser ajustado por los requisitos de
software eficaz Desa-, crear y mantener.
Además, una serie de políticas específicas para
la ingeniería de software puede necesitar estar en
su lugar o establecido para la gestión eficaz de la
ingeniería de software a nivel nizational or-. Por
ejemplo, las políticas son generalmente
necesarios para establecer procesos de toda la
organización o procedimientos específicos para
tareas de ingeniería de software, tales como
diseño de software, software de construc- ción,
la estimación, el seguimiento y la presentación
de informes. Este tipo de políticas son
importantes para la gestión efectiva a largo plazo
de los proyectos de ingeniería de software en
toda la organización (por ejemplo, el
establecimiento de una base constante por el que
Ingeniería de Software de Gestión de 7-3
Otro aspecto importante de la gestión de la
organización son las políticas y procedimientos
de gestión de personal para la contratación,
capacitación y mentor personal ing para el
desarrollo profesional, no sólo a nivel de
proyecto, sino también a la Cess Suc a más
largo plazo de una organización. el personal de
ingeniería de software pueden presentar retos
de formación o gestión de personal único (por
ejemplo, el mantenimiento de la moneda en un
contexto donde la tecno- logía subyacente sufre
un cambio rápido y continuo).
gestión de la comunicación también 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
comprensión precisa de las necesidades del
usuario, requisitos de software y diseños de
software. Por otra parte, la gestión de carteras,
que proporciona una visión de conjunto, no
sólo de software actualmente en fase de
desarrollo en diversos proyectos y programas
(proyectos integrados), sino también de
software previstas y actualmente en uso en una
organiza- ción, se deseable. Además, la
reutilización de software es la clave
factor en el mantenimiento y la mejora de la Por desgracia, una percepción común de la

productividad y la competitividad. reutilización industria del software es que los productos de
efectiva requiere una visión estratégica que software se Ered deliv- tarde, por encima del
refleja las ventajas y desventajas de presupuesto, de mala calidad y con una
reutilización. funcionalidad incompleta. La medición-informada
Además de comprender los aspectos de
gestión que son influenciados de forma única
por los proyectos de software, ingenieros de
software deben tener algún conocimiento de los
aspectos más generales de gestión que se tratan
en este KA (incluso en los primeros años
después de la graduación).
Los atributos de la cultura organizacional y el
comportamiento, además de la gestión de otras
áreas funcionales de la empresa, tienen una
influencia, aunque sea indirectamente, en los
procesos de ingeniería de software de una
organización.
Extensa información relativa a la gestión de
proyectos de software se puede encontrar en la
Guía para la Dirección de Proyectos del
Conocimiento (Guía del PMBOK®) y el
software de la extensión de la Guía PMBOK
(SWX) [1] [2]. Cada una de estas guías incluye
KAs diez proyectos de gestión: gestión de la
integración de proyectos, gestión del alcance del
proyecto, gestión del tiempo, gestión de
proyectos, el costo del proyecto de gestión de
calidad de proyectos, gestión de recursos
humanos, gestión de proyectos comunicaciones
del proyecto, la gestión de riesgos de proyectos,
gestión de proyectos y adquisiciones gestión de
los interesados del proyecto. Cada KA tiene
relación directa con esta Ingeniería de Software
de Gestión de KA.
La información adicional también se
proporciona en las otras referencias y otras
lecturas de este KA. Este Ingeniería de Software
de Gestión de KA se compone de los cesos de
gestión de proyectos de software pro en los
primeros cinco temas en la Figura 7.1 (Initiative
ción y definición del alcance, Software Proyecto
planificación, proyecto de software
promulgación, revisión y evaluación, de cierre),
además de Ingeniería de Software medición en el
sexto tema y herramientas de software de gestión
de ingeniería en el séptimo tema. Si bien la
gestión de proyectos y gestión de medi- ción a
menudo se considera una unidad independiente, y
de hecho cada sí posee muchos atributos únicos,
la estrecha relación que ha dado lugar a
tratamiento combinado en este KA.
-gestión de un principio básico de cualquier
verdadera disciplina inge- niería (ver Medición
de las fundaciones inge- niería KA) -pueden
ayudar a mejorar la percepción y la realidad.
En esencia, la gestión sin medición (cualitativa
y cuantitativa) sugiere una falta de disciplina, y
la medición sin gestión sugiere una falta de
propósito o contexto. La gestión eficaz requiere
una combinación de ambos medición y
experiencia.
Las siguientes definiciones de trabajo se
adoptan aquí:
• administración es un sistema de procesos y

controles necesarios para lograr los
objetivos estratégicos fijados por la
organización.
• Medición se refiere a la asignación de los
UE Val- y etiquetas a los productos de
trabajo de ingeniería de software, los
procesos y los recursos más los modelos
que se derivan de ellos, si estos modelos
son desarrollados usando técnicas
estadísticas u otras [3 *, C7, C8].
Las secciones de gestión de proyectos de

ingeniería de software en este KA hacen un
amplio uso de la sección de medición de la
ingeniería de software.
Esta KA está estrechamente relacionado con
otros en la Guía SWEBOK, y la lectura de las
siguientes descripciones KA en conjunción con
éste será particularmente útil:
• El Fundamentos de Ingeniería KA describe

algunos conceptos generales de medición
que son aplicables directamente a la
sección de ingeniería de software de
medición de este KA. Además, los
conceptos y técnicas presentados en la
sección Análisis estadístico de los
Fundamentos de Ingeniería 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- ción Iniciación y del
proyecto.
• El software de configuración de
administración de KA se ocupa de la
identificación, el control, el registro del
estado, y la auditoría de software de con-
figuraciones junto con la administración de
la versión de software y herramientas de
administración y gestión de software de
configu- ración.
• El Proceso de Ingeniería 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. • Ingeniería de Software de medición, el cual
• La calidad del software KA hace hincapié se ocupa del desarrollo eficaz y
en calidad como un objetivo de la gestión
y como un objetivo de muchas actividades
de ingeniería de software.
• La Ingeniería de Software Economía KA
discute cómo tomar decisiones relacionadas
con el software en un contexto empresarial.
DISTRIBUCIÓN DE TEMAS PARA LA

GESTIÓN DE INGENIERÍA DE
SOFTWARE
Debido a que la mayoría de los modelos de ciclo

de vida del software de desarrollo requieren
actividades similares que puedan ser ejecuta 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 Ingeniería de
Software proceso KA) que ha sido elegido para
un proyecto específico. No hay intención en esta
averiado para recomendar un modelo específico
del ciclo de vida. El desglose implica sólo lo que
sucede y no implica cuándo, cómo, o cuántas
veces se produce cada actividad. Los siete temas
son:
• Iniciación y definición del alcance, que se

refieren a la decisión de embarcarse en un
proyecto de ingeniería de software;
• Software de planificación, que se ocupa de
las actividades llevadas a cabo para preparar
un proyecto de ingeniería de software
exitoso desde el punto de vista de gestión;
• Proyecto de software Promulgación, que se
ocupa de las actividades de gestión de la
ingeniería de software generalmente
aceptados que se producen durante la
ejecución de un proyecto de ingeniería de
software;
• Revisión y evaluación, que tratan de
garantizar que, horario, costo, y las
actividades de ingeniería técnica de calidad
Ingeniería
estimaciones aproximadas de de Softwarey de
esfuerzo el Gestión
coste de 7-7
implementación de programas de medición en
organizaciones de ingeniería de software; sobre la base de métodos apropiados (véase la
• Herramientas de software de gestión de sección 2.3, Esfuerzo, Schedule, y el coste de
ingeniería, que describe la selección y el estimación).
uso de herramientas para la gestión de un
proyecto de ingeniería de software.
1. Iniciación y Definición del Alcance
El objetivo de estas actividades es de

determinación eficaz de los requisitos de
software utilizando métodos de obtención
variabilidad ous y la evaluación 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 sección son los ficación
speci- de los requisitos y selección de los pro-
cesos de revisión y revisión de requisitos.
1.1. La determinación y la
negociación de los requisitos
[3 *, c3]
Determinar y está llevando a cabo los

requisitos establecidos de negociación de los
límites visibles para el conjunto de tareas (ver
los requisitos de software KA). Las actividades
incluyen la obtención de requisitos, análi- sis,
especificación y validación. Métodos y
técnicas deben ser seleccionadas y aplicadas,
teniendo en cuenta las diversas perspectivas de
los interesados. Esto lleva a la determinación
del alcance del proyecto con el fin de cumplir
con los objetivos y satisfacer las restricciones.
1.2. Análisis de viabilidad

[4 *, c4]
El propósito del análisis de viabilidad es el

desarrollo de una descripción 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 tecnología, los
recursos, las finanzas, y las consideraciones
políticas sociales /. Un proyecto inicial y la
declaración del alcance del producto, los
entregables del proyecto, las limitaciones de
duración del proyecto, y una estimación de los
recursos necesarios deben estar preparados.
Los recursos incluyen un número suficiente
de personas que tienen las habilidades
necesarias, las instalaciones, la infraestructura
y el apoyo (ya sea interna o externamente).
Análisis de viabilidad a menudo requiere
1.3. Proceso para el examen y revisión de 2.1. Planificación de

los requisitos procesos [3 *, c3, c4, c5] [5 *,
[3 *, c3] c1]
del software, verificación y validación, opiniones
Dada la inevitabilidad del cambio, las partes y auditorías (ver la calidad KA software ).
interesadas deben ponerse de acuerdo sobre los Procesos y responsabilidades para la revisión en
medios por los cuales los requisitos y alcance curso y la revisión del plan de proyecto y los
han de ser examinado y revisado (por ejemplo, planes relacionados también deben estar
procedimientos de gestión del cambio, claramente establecidos y acordados.
retrospectivas ciclo tivos iteraciones). Esto
implica claramente que el alcance y requisitos
no serán “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 algún tipo de
análisis de trazabilidad y análisis de riesgos se
debe utilizar para determinar el impacto de esos
cambios (véase la sección 2.5, Gestión de
Riesgos y Control de Configuración de Software
en el KA Software Configuration Management).
Un enfoque de cambio administrado también
puede formar la base para la evaluación 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 (véase el
tema 5, Cierre).
2. Planificación de proyectos de software
El primer paso en la planificación de proyectos

de software debe ser la selección de un modelo
de desarrollo ciclo de vida del software
apropiado y quizá adaptándola basado en el
alcance del proyecto, los requisitos de software,
y una evaluación de riesgos. Otros factores que
deben consi- Ered incluir la naturaleza del
dominio de aplicación, complejidad funcional y
técnica, y los requisitos de calidad blandos Ware
(ver Requisitos de calidad de software en la
calidad del software KA).
En todos los SDLCs, evaluación de riesgos
debe ser un elemento de la planificación inicial
del proyecto, y el “perfil de riesgo” del proyecto
deben ser discutidos y aceptados por todos los
interesados. procesos de gestión de la calidad del
software (ver Gestión de la Calidad de Software
Procesos en la calidad KA software) deben
determinarse como parte del proceso de
planificación y dan lugar a procedimientos y
responsabilidades para la garantía de la calidad
Software de ciclo de vida de desarrollo inspección, elIngeniería de Software
software de Gestión
probado) debede 7-9
ser
(SDLC) els mo- abarcan un continuo que va identificado y caracterizado. Oportunidades para
desde predictivo para adaptable (consulte el la reutilización de componentes de software de
software del ciclo de vida Los modelos de la proyectos anteriores o para utilizar los
Ingeniería de Procesos de Software KA). productos de software off-the-shelf
SDLCs predictivos se caracterizan por el
desarrollo de los requisitos de software
detalladas, la planificación detallada del
proyecto, y planificación mínima para la
iteración entre fases de desarrollo. SDLCs
adaptativos están diseñados 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 sólo cuando sea necesario. SDLCs
tivos adaptaciones se caracterizan por ciclos
desarrollo iterativos. SDLCs en la gama
media de los incrementos SDLC continuum
producto de funcionalidad ya sea en un
horario planificada de antemano (en el lado
predictivo del continuo) o como los productos
de los ciclos de desarrollo frecuentemente
actualizadas (en el lado de adaptación del
continuo) .
SDLCs bien conocidos incluyen los modelos
de cascada, incremental y espiral más diversas
formas de desarrollo ágil de software [2] [3 *,
c2].
métodos pertinentes (véase la Engineer-
Software ing modelos y métodos KA) y las
herramientas debe ser seleccionado como parte
de la planificación. Las herramientas
automatizadas que se utilizarán a lo largo del
proyecto también se deben planificar y
adquiridas. Las herramientas pueden incluir
herramientas para la programación de
proyectos, los requisitos de software, diseño de
software, la construcción de software,
mantenimiento de software, gestión de
configuración de software, proceso de
ingeniería de software, la calidad del software,
y otros. Si bien muchas de estas herramientas
debe seleccionarse con base principalmente en
las consideraciones técnicas discutidas en otros
Kas, algunos de ellos están estrechamente
relacionados con las consideraciones Ment
manage- discutidos en este capítulo.
2.2. determinar entregables

[3 *, c4, c5,
c6]
El producto (s) de trabajo de cada actividad de

proyecto (por ejemplo, la arquitectura software
documentos de diseño, informes de
deben ser evaluados. Adquisición de software y así como por las cuestiones relativas al personal
el uso de terceros para desarrollar las (por ejemplo, la productividad de las personas
prestaciones debe ser planeada y proveedores y los equipos, la dinámica del equipo, y
seleccionados (ver sección 3.2, Software de estructuras de equipo).
Adquisición y Gestión de Proveedores de
contrato). 2.5. Gestión de riesgos
[3 *, c9] [5 *, c5]
2.3. Esfuerzo, Calendario, y Estimación de
Costos Riesgo e incertidumbre están relacionados pero
[3 *, c6] distintos conceptos. La incertidumbre resulta de
la falta de informa- ción. 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 además de una
determinar utilizando un modelo de estimación caracterización de los efectos negativos sobre un
calibrada en base al tamaño y esfuerzo datos proyec- ect. El riesgo es a menudo el resultado
históricos (cuando esté disponible) y otros de la incertidumbre. Lo contrario de riesgo es la
métodos pertinentes, tales como el juicio de oportunidad, que se caracterizarse por la
expertos y la analogía. dependencias de tareas se probabilidad de que un evento que tenga se
pueden establecer y oportunidades potenciales puede producir un resultado positivo.
para la realización de tareas al mismo tiempo y La gestión del riesgo implica la identificación
de forma secuencial pueden ser identificados y de factores de riesgo y análisis de la
documentados mediante un diagrama de Gantt, probabilidad y el impacto potencial de cada
por ejemplo. Para proyectos SDLC predictivos, factor de riesgo, la priorización 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 mitigación de riesgos para reducir la
de los tiempos se produce normalmente durante probabilidad y minimizar el impacto negativo si
la planificación. Para proyectos SDLC de un factor de riesgo se convierte en un problema.
adaptación, una estimación general de esfuerzo y métodos de evaluación de riesgos (por ejemplo,
el horario típicamente se desarrolló a partir de la la opinión de expertos, datos históricos, árboles
comprensión inicial de los requisitos, o, de decisión, 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
estimación inicial de la nú- mero ciclos y también se pueden determinar en este punto de
estimaciones del esfuerzo de iterativos y otros la discusión 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 añadir
herramientas) pueden traducirse en estimaciones características que no sean necesarios, o los
de costos. la estimación 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- ción
interesadas afectadas hasta que se alcanza particular, se debe prestar a la gestión de los
consenso sobre los recursos y el tiempo riesgos relacionados con los requisitos de
disponible para la finalización del proyecto. calidad de software, tales como la seguridad o la
seguridad (ver la calidad KA Software). La
2.4. Asignación de recursos gestión del riesgo debe hacerse no sólo en el
[3 *, c5, c10, c11] comienzo de un proyecto, sino también a
intervalos periódicos a lo largo del ciclo de vida
del proyecto.
Equipos, instalaciones y personas deben incluyendo el catión alo variabilidad

asignarse los que las tareas identificadas, de responsabilidades
para la realización de
Ingeniería de Software de Gestión de 7-
2.6. Gestión 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 quién es identificado, tal vez en términos 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 asignación 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
y expectativas. Procedimientos relacionados con Las actividades del proyecto deben llevarse a cabo
el software en curso Garantía 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 verificación y validación tecnología y financiación) son utilizados y
del producto software entregable, también deben productos de trabajo (por
especificarse durante la planificación de la
calidad (por ejemplo, las revisiones e
inspecciones técnicas o demostraciones de
completado funcionalidad, véase la calidad del
software KA).
2.7. Gestión del plan

[3 *, c4]
Para proyectos de software, donde el cambio es

un tación 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 sistemática,
revisados, informaron, y, en su caso, revisada.
Planes asociados a los procesos de apoyo (por
ejemplo, la documentación, configuración de
software agement hombre- y resolución de
problemas) también deberían 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 serán
utilizados para la edad causados por el hombre
del proyecto.
3. La promulgación del proyecto de software
Durante software del proyecto promulgación

(también conocidos como la ejecución 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 adhesión dará lugar a la
exitosa satisfacción de los requisitos de las
partes interesadas y el logro de los objetivos
del proyecto. Fundamental para la incorporación
son las actividades de gestión en curso de
supervisión, control-ling, y generación de
informes.
3.1. Implementación de Planes

[4 *, c2]
Ingeniería
relacionados debe de Software de Gestión
ser continuamente de 7- y
evaluado
ejemplo, diseño de software, código de 13
software y pruebas de software de los casos) se al
generan.
3.2. Software de Adquisición y Gestión de

Proveedores Contrato
[3 *, c3, c4]
adquisición de software y contrato de

abastecimiento agement hombre- se ocupa de
los aspectos que intervienen en la contratación
con clientes del software desarrollo
organización que adquieren los productos de
trabajo y entregables con los proveedores que
suministran productos o servicios a la
organización de ingeniería de software.
Esto puede implicar la selección de los tipos
apropiados de contratos, como el precio fijo, el
tiempo y mate- als, de costo más una cuota fija,
o el costo más gasto de incentivo. Acuerdos
con clientes y proveedores normalmente, un
especifican camente el alcance del trabajo y los
Ables deliver- e incluyen cláusulas tales como
las sanciones de entrega o de no entrega tardía
y acuerdos de propiedad intelectual que
especifican lo que el proveedor o proveedores
están ofreciendo y lo que el adquirente es pagar
- ing para, además de lo que será entregado y
propiedad del adquirente. Para el software está
siendo desarrollado por los proveedores
(internos o externos a la organización de
desarrollo de software), los acuerdos com-
comúnmente indican los requisitos de calidad
de software para la aceptación del software
entregado.
Después de que el acuerdo se ha puesto en
marcha, cution eje- del proyecto de acuerdo
con los términos del acuerdo debe gestionarse
(véase el capítulo 12 de SWX, Gestión de
adquisición de software, para más información
sobre este tema [2]).
3.3. Implementación de Proceso de medida

[3 *, c7]
El proceso de medición 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
medición, y 6.3, realizar el proceso de
medición).
3.4. Process monitor

[3 *, c8]
La adhesión al plan del proyecto y planes

intervalos predeterminados. Además, se deben proyecto (por ejemplo, los requisitos de software
evaluar los productos y los criterios pletion com- especifi- cación) para dar cabida a eventos no
para cada tarea. Entregables deben ser evaluados previstos y sus implicaciones.
en términos de sus características requeridas En algunos casos, el proceso de control puede
(por ejemplo, a través de las inspecciones o llevar al abandono del proyecto. En todos los
mediante la demostración 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 sección 2.5,
gestión de riesgos) debe ser revisada, y la
adhesión a los requisitos de calidad de software
eva- uated (ver Requisitos de calidad de
software en la calidad del software KA).
Los datos de medición deben ser analizados
(véase Sta- Análisis Statistical en los
Fundamentos de Ingeniería KA). El análisis de
varianza basado en la desviación de real de los
resultados y valores esperados debe ser
determinado. Esto puede incluir los excesos de
costes, cronograma deslizamiento, u otras
medidas similares. identificación y análisis de
los datos de calidad y otra de medición de
valores atípicos se deben realizar (por ejemplo,
análisis de defectos; ver Software Medición de
la Calidad en el Software Quality KA).
exposiciones de riesgo deben ser recalculados
(ver sección 2.5, Gestión de Riesgos). Estas
actividades pueden permitir la detección del
problema e identificación excepción basada en
umbrales que se han superado. Los resultados
deben ser reportados cuando se han superado los
umbrales, o según 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 acción correctiva (por ejemplo,
volver a probar ciertos componentes de
software); que puede implicar calificación
incorpora acciones adicionales (por ejemplo, la
decisión de utilizar la creación de prototipos
para ayudar en software de validación de los
requisitos; ver Prototipos en los requisitos de
software KA); y / o puede implicar la revisión
del plan del proyecto y otros documentos del
Ingeniería de
Como en la actividad Software
proceso dedecontrol
Gestión de 7-
procedimientos de gestión de control de 15
configuración de software y configuración de anteriormente (véase sec- ción 3.5, Process
software deben ser atendidas (ver el software Control), configuración de software
de configuración 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 ( véase la sección 6.3, Per- formar
el proceso de medición).
3.6. informes
[3 *, c11]
En especificado y acordado veces, el progreso

hasta la fecha se debe informar, tanto dentro de
la organiza- ción (por ejemplo, a un co- mité de
dirección del proyecto) y para los
colaboradores externos (por ejemplo, clientes o
usuarios). Los informes deben centrarse en las
necesidades de información del público
objetivo en comparación con el estado
detallado de informes dentro del equipo del
proyecto.
4. Revisión y Evaluación
En tiempos pre-especificados y según sea

necesario, reso general prog- hacia el logro de
los objetivos planteados y la satisfacción 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 métodos empleados también
deben llevarse a cabo larmente REG y como
determinados por las circunstancias.
4.1. La determinación de satisfacción de los

requisitos
[4 *, c8]
Debido a lograr la satisfacción de las partes

interesadas es un objetivo principal de la
gerente de ingeniería de software, el progreso
hacia este objetivo debe evaluarse
periódicamente. El progreso debe ser evaluado
en el logro de los principales hitos del proyecto
(por ejemplo, la finalización de la arquitectura
de diseño de software o la finalización de una
revisión técnica de software), oa la conclusión
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.
procedimientos de gestión de configuración de 5.2. Actividades de

software de control y se deben seguir (véase 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 (véase la sección 6.3, realizar el
proceso de medición).
4.2. Revisión y Evaluación del desempeño

[3 *, c8, c10]
evaluaciones de desempeño periódicas para el

proyecto sonal per- pueden proporcionar
información 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
métodos, herramientas y técnicas empleadas
deben ser evaluados para su eficacia y
conveniencia, y el proceso siendo utilizados por
el proyecto también deben ser evaluados
sistemática y periódicamente 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 iteración deberían 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 determinación

[1, s3.7, S4.6]
El cierre se produce cuando las tareas

especificadas para un proyecto, una fase, o una
iteración 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 consecución de los
objetivos se pueden determinar. procesos de
cierre deben involucrar a las partes interesadas y
el resultado en la documentación de aceptación
Tras el cierre se haya confirmado, el archivo de Ingeniería de Software de Gestión de 7-
17
los materiales del proyecto debe llevarse a
cabo de acuerdo con los grupos de interés
acordada ods met, la ubicación y la duración,
posiblemente incluyendo la destrucción de la
información sensible, el software y el medio en
el que las copias son residentes. base de datos
de medición de la organización debe
actualizarse con los datos relevantes del
proyecto. Un proyecto, la fase o análisis
retrospectivo iteración deben llevarse a cabo
para que los temas, problemas, riesgos y
oportunidades encontradas pueden ser
analizados (ver tema 4, Revisión y
Evaluación). Las lecciones aprendidas deben
extraerse del proyecto y se introducen en el
aprendizaje y la mejora de los esfuerzos de
organización.
6. Medición de Ingeniería de Software
La importancia de la medición y su papel en

mejores prácticas de gestión y de ingeniería es
ampliamente reconocido (véase Medición de
los Fundamentos de Ingeniería KA). surement
medi- efectiva se ha convertido en una de las
piedras angulares de la madurez de la
organización. La medida puede ser aplicada a
las organizaciones, proyectos, procesos y
productos de trabajo. En esta sección se centra
en la aplicación de la medida a nivel de
proyectos, procesos y productos de trabajo.
Esta sección sigue el estándar IEEE 15939:
2008 [6], que describe un proceso para definir
las actividades y tareas necesarias para
implementar un proceso de medición de
software. El estándar también incluye un
modelo de información de medición.
6.1. Establecer y mantener el

compromiso de Medición
[7 *, c1, c2] 2
• Requisitos para la medición. Cada

esfuerzo de medición debe ser guiada por
objetivos de la organización y accionado
por un conjunto de requisitos de medición
establecidos por
2 Tenga en cuenta que estos dos capítulos se

pueden descargar de forma gratuita desde
www.psmsc.com/ PSMBook.asp.
la organización y el proyecto (por ejemplo, se pueden derivar de negocio, objetivos de

un objetivo de la organización podrían ser la organización, regulación y / o de
“los primeros en el mercado con nuevos productos. Ellos deben ser identificados y
productos”).
• Ámbito de aplicación de la medición. La
unidad organizativa a la que cada requisito
de medición 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
medición de esfuerzo también debe ser
considerado porque puede ser necesario
series de tiempo de algunas mediciones; por
ejemplo, para calibrar los modelos esti-
mación (ver sección 2.3, Esfuerzo, ULE
Sched-, y estimación de costos).
• el compromiso del equipo de medición. El
compromiso debe establecerse formalmente,
comunica, y apoyado por los recursos (ver
siguiente punto).
• Recursos para la medición. El compromiso
de una organiza- ción de medición es un
factor esencial para el éxito, como lo
demuestra la asignación de recursos para
implement- ing el proceso de medición.
Asignación de recursos incluye la
asignación de responsabilidad para las
diversas tareas del proceso de medición
(tales como el analista y bibliotecario). ade-
cuada financiación, formación, herramientas
y apoyo para llevar a cabo el proceso
también deben asignarse.
6.2. Planificar el proceso de medición

[7 *, c1, c2]
• Caracterizar la unidad organizativa. La

unidad de organización proporciona el
contexto para la medición, por lo que el
contexto de la organización debe ser
explícita, incluyendo los straints confirma
que la organización impone en el proceso de
medición. La caracterización se puede
afirmar en términos de procesos de
organización, dominios de aplicación, la
tecnología, las interfaces de organización y
estructura organizativa.
• Identificar las necesidades de información.
Las necesidades de información se basan en
los objetivos, limitaciones, riesgos y
problemas de la unidad organizativa. Ellos
Ingeniería de Software de Gestión de 7-
proceso de medición.
priorizado. A continuación, un subconjunto 19
de los objetivos que se abordarán se puede • Identificar recursos para poner a disposición
seleccionar, documentado, com- municated, de
y revisado por los interesados. la aplicación de los previsto y aprobado
• Optar por medidas. medidas candidatos
deben ser seleccionados, con claros vínculos
con las necesidades de informa- ción. Las
medidas deben ser seleccionados en base a
las prioridades de las necesidades de
información y otros criterios tales como
coste de la recogida, el grado de interrupción
del proceso durante la recogida, la facilidad
de obtención, los datos Consistente precisa, y
la facilidad de análisis y ing informe-.
Debido a las características de calidad
interna (ver modelos y características 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, análisis y
procedimientos de ING informe-. Esto
abarca procedimientos de recogida y
horarios, almacenamiento, verifica- ción,
análisis, informes y gestión de la
configuración de datos.
• Seleccione los criterios de evaluación de los
productos de información. Criterios para la
evaluación están influidos por los tantes
objeciones técnicas y comerciales de la
unidad organizativa. Los productos de
información 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
medición. El plan de medición debe ser
revisado y aprobado por los interesados
apropiados para incluir todos los
procedimientos de recolección de datos;
procedimientos de almacenamiento, análisis
y presentación de informes; criterios de
evaluación; horarios; y responsabilidades.
criterios para la revisión de estos artefactos
deberían 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.
Aprobación demuestra el compromiso con el
tareas de medición. La disponibilidad de Fundamentos de ingeniería 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. organización (que puede ser formal o
Deberán tener en cuenta a los recursos informal). Los proveedores de datos y
necesarios para la implementación exitosa usuarios de medida deben participar en la
de nuevos procedimientos o medidas. revisión de los datos para asegurarse de que
• Adquirir y desplegar tecnologías de apoyo. son significativos y precisos y que puedan
Esto incluye la evaluacióntecnologías de dar lugar a acciones razonables.
soporte disponibles de, la selección de las • Comunicar los resultados. Los productos de
tecnologías más adecuadas, de adquisición información deben ser documentados y
de esas tecnologías, y el despliegue de esas comunicados a los usuarios y grupos de
tecnologías. interés.
6.3. Realizar el proceso de medición 6.4. evaluar Medición

[7 *, c1, c2] [7 *, c1, c2]
• Integrar los procedimientos de medición con apropiado a la naturaleza de los datos y las
los procesos de software Evant rel. Los necesidades de información. Los resultados de
procedimientos de medición, tales como la este análisis son típicamente indicadores tales
recopilación de datos, deben integrarse en como gráficos, números u otras indicaciones
los procesos de software que se está que serán 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 Análisis
acomodar la recopilación de datos de fecha estadístico en el
o actividades de generación. También puede
implicar el análisis de los procesos de soft-
ware actuales para reducir al mínimo
esfuerzo adicional y la evaluación del efecto
de los empleados para asegurar que se
aceptarán los procedimientos de medición.
problemas de moral y otros factores
humanos deben ser considerados. Además,
los procedimientos de medición deben ser
comu- nicated a los que proporcionan los
datos. También puede ser necesario
proporcionar formación y apoyo.
procedimientos de análisis de datos y de
información están típicamente integrados en
los procesos de organización y / o proyecto
de manera similar.
• Recolectar datos. Los datos deben
recogerse, que ha comprobado, y se
almacenan. Colección veces se puede
automatizar mediante el uso de software de
Engineer- herramientas de gestión de ING
(véase el tema 7, la Cesión de Software de
Gestión de Herramientas de ingeniería) para
analizar los datos y elaborar informes. Los
datos pueden ser agregados, transformadas,
o recodificados como parte del proceso de
análisis, utilizando un grado de rigor
• Evaluar productos de información y el
proceso surement medi- contra
especificado Evaluation criterios ación y
determinar las fortalezas y debilidades de
los productos de información o proceso,
respectivamente. La evaluación puede ser
realizada por un proceso interno o una
auditoría nal externamente; que debe
incluir la retroalimentación de los
usuarios de medición. 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 reclasificación de
categorías de medición. 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 medición y
ERS stakehold- para su revisión y
aprobación. Además, la falta de mejoras
potenciales debe comuni- nicated si el
análisis no identifica ninguna mejora.
7. Herramientas de Gestión de Ingeniería de

Software
[3 *, c5, c6,
c7]
herramientas de gestión de la ingeniería de

software a menudo se utilizan para
proporcionar visibilidad y control de los
procesos de gestión de ingeniería de software.
Algunas herramientas son automatizados,
mientras que otros son manualmente
implementado. Ha habido una tendencia
reciente hacia el uso de suites integradas de
ingeniería de software herramientas que se
utilizan en un proyecto para planificar,
recopilar y registrar, monitorear y controlar, y
proyecto de informe e información del producto. y estimaciones subjetivas de las probabilidades

Las herramientas pueden de los eventos de riesgo. herramientas de
puede dividir en las siguientes categorías: simulación Monte Carlo se pueden utilizar para
Planificación de proyectos y herramientas de producir distribuciones de probabilidad de
seguimiento. planificación de proyectos y esfuerzo, horario, y el riesgo mediante la
herramientas de seguimiento se pueden utilizar combinación de múltiples distribuciones de
para estimar el esfuerzo y el coste del proyecto probabilidad de entrada de una manera
compañero y preparar los programas del algorítmica.
proyecto. Algunos proyectos utilizan Herramientas de comunicación. Las
herramientas automatizadas esti- mación que herramientas de comunicación pueden ayudar a
aceptan como entrada el tamaño estimado y proporcionar información oportuna y consistente
otras características 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
planificación también incluyen herramientas de electrónico y transmisiones de los miembros del
programación que analizan las tareas dentro de equipo y las partes interesadas. También
una estructura de desglose de trabajo incluyen comu- nicación de las actas de las
automatizado, su estimación acoplado reuniones regulares del proyecto, reuniones
duraciones, sus relaciones de precedencia, y los diarias de stand-up, además de gráficos que
recursos asignados a cada tarea para producir 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 medición. Herramientas de
utilizar para realizar un seguimiento de los hitos medición SUP- actividades portuarias
del proyecto, reuniones de estado del proyecto relacionadas con el programa de medición ción
programadas regularmente, ciclos de iteración (véase el tema 6, Software Engineer- Medición
programadas, demostraciones de productos y / o ing) de software. Hay pocas herramientas
elementos de acción. completamente automatizadas en esta categoría.
Herramientas de gestión de riesgos. instrumentos de medición utilizados para reunir,
herramientas de gestión del riesgo (ver sección analizar y reportar los datos de medición de
2.5, gestión de riesgos) se pueden utilizar para proyecto pueden estar basados en hojas de
realizar un seguimiento de la identificación del cálculo desarrollados por los miembros del
riesgo, estimación y supervisión. Estas equipo de proyecto o empleados organizativas.
herramientas incluyen el uso de enfoques como
la simulación o de árboles de decisión para
analizar el efecto de los costos versus beneficios
BoEHM y Turner 2003
mcGarry et al. 2001

2011 [4 *]
2009 [3
JustaLey de
SommervilLe
[5 *]
[7 *]
*]
1. Iniciación y Alcance
Definición
1.1. La determinación y la
c3
negociación de los
requisitos
1.2. Análisis de viabilidad c4
1.3. proceso parael examen y
c3
revisión de los requisitos
2. software de planificación
2.1. Planificación de c2, c3, c4, c5 c1
procesos
2.2. determinar entregables c4, c5, c6
2.3. Esfuerzo, Planificar,y
c6
Estimación de Costos
2.4. Asignación de recursos C5, C10,
2.5. Gestión de riesgos C11
C9 c5
2.6. Gestión de la calidad c4 c24
2.7. Gestión del plan c4
La promulgación 3. Proyecto de
Software
3.1. Implementación de Planes c2
3.2. Software de Adquisición y
C3, C4
Proveedor Gestión de contratos
3.3. Implementación de
c7
Proceso de medida
3.4. Process monitor c8
3.5. Control de procesos C7, C8
3.6. informes c11
4. Revisión y Evaluación
4.1. La determinación de
satisfacción de los requisitos
4.2. revisandoy la evaluación del
c8, c10
desempeño
BoEHM y Turner 2003
mcGarry et al. 2001

2011 [4 *]
2009 [3
JustaLey de
SommervilLe
[5 *]
[7 *]
*]
5. Cierre
5.1. Cierre la determinación
5.2. Actividades de cierre
6. Software de
Ingeniería de medición
6.1. Establecer y mantener
c1, c2
Compromiso de medición
6.2. Planificar la Medición
c1, c2
Proceso
6.3. Realizar la medición
c1, c2
Proceso
6.4. evaluar Medición c1, c2
7. Herramientas de
C5, C6, C7
Gestión de Ingeniería
de Software
LECTURAS software complejo, y sistemas de hardware, así

como los resultados de la inspección y las
Una guía para la Dirección de Proyectos métricas de prueba para monitorear el estado del
(PMBOK® Guía) [1]. proyecto Tor.
La Guía PMBOK ® proporciona directrices para

la gestión de proyectos individuales y define los
conceptos relacionados con la gestión de
proyectos. También describe el ciclo de vida de
gestión de proyectos y sus procesos
relacionados, así como el ciclo de vida del
proyecto. Es una guía reconocida a nivel
mundial para la profesión agement el proyecto
hombre-.
Software de Extensión a la Guía de los

Fundamentos de la Dirección de
Proyectos (Guía del PMBOK®) [2].
SWX ofrece adaptaciones y ampliaciones de las

prácticas genéricas de gestión de proyectos
documentados en la Guía PMBOK ® para
proyectos de software ing manag-. La principal
contribución de esta extensión de la Guía
PMBOK ® es una descripción de los procesos
que son aplicables para la gestión de proyectos
de software de ciclo de vida de adaptación.
La adopción de la norma IEEE ISO / IEC 15939

[6].
Esta norma internacional identifica un proceso

que es compatible con la definición de un
conjunto adecuado de medidas para hacer frente
a las necesidades específicas de información. Se
identidades FIES las actividades y tareas que son
necesarias para identificar con éxito, definir,
seleccionar, aplicar y mejorar la medición dentro
de un proyecto global o la estructura
organizativa de medición.
J. McDonald, gestión del desarrollo de software

de sistemas intensivos, Wiley, 2010 [8].
Este libro de texto proporciona una introducción

a la gestión de proyectos para el comienzo de los
desarrolladores de software y hardware más
avanzado material único para los
administradores de proyectos experimentados.
Los estudios de casos se incluyen la
planificación y la gestión de verifica- ción y
validación para grandes proyectos de software,
Referencias
[1] Instituto de Gestión de Proyectos, una guía

para la Dirección de Proyectos del
Conocimiento (PMBOK (R) Guía), 5ª ed.,
Project Management Institute, 2013.
[2] Instituto de Gestión de Proyectos y IEEE

Computer Society, software de la
extensión de la Guía del PMBOK®
quinta edición, Project Management
Institute, 2013.
[3 *] RE Fairley, gestionar y liderar proyectos

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

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

agilidad y disciplina: una guía para los
perplejos, Addison-Wesley, 2003.
[6] IEEE Std. 15939-2008 La adopción del

estándar ISO / IEC 15939: 2007 Sistemas
y Procesos de Ingeniería de Software de
Mediciones, IEEE 2008.
[7 *] J. McGarry et al, Practical Software

de medición:. Información Objetivo
para los decisores, Addison-Wesley
Professional, 2001.
[8] J. McDonald, gestión del desarrollo de

software de sistemas intensivos, John
Wiley and Sons, Inc., 2010.
CAPÍTULO 8
SOFTWARE INGENIERÍA DE PROCESOS
de software. Para facilitar la lectura “, la

SIGLAS ingeniería de software
Business Process Modeling

BPMN
Notación
Software Asistida por Ordenador
CASO
Ingenieria
CM Gestión de la configuración
Capability Maturity Model
CMMI
Integration
GQM Meta-pregunta-Metric
IDEF0 integración Definición
LOE Nivel de esfuerzo
ODC Clasificación de defectos ortogonal
SPLC programas
Software del ciclo de vida del
UML producto
Lenguaje de Modelado Unificado
INTRODUCCIÓN
Un proceso de ingeniería consiste en un

conjunto de actividades interrelacionadas que
transforman una o más entradas en salidas,
mientras que consume recursos cumpla
cabalmente la transformación. Muchos de los
procesos de disciplinas de ingeniería
tradicionales (por ejemplo, eléctrica, mecánica,
civil, químicos) se refieren a la transformación
de la energía y las entidades físicas de una forma
a otra, como en una presa hidroeléctrica que
transforma la energía potencial en energía
eléctrica o una refinería de petróleo que utiliza
procesos químicos para transformar el petróleo
crudo en gasolina.
En esta área de conocimiento (KA), ingeniería
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, diseño, construcción, pruebas, gestión
de con- figuración, y otra procesos de ingeniería
la adaptaciónIngeniería de Software de Gestión
y la implementación de 7-19
de procesos
proceso”se denomina‘proceso de software’en de software para un proyecto de software
este KA. Además, tenga en cuenta que “el específico (ver Proceso de Planificación en el
proceso de software” se refiere a las KA Software Engineering Management). Els y
actividades de trabajo, no el proceso de ejecu- métodos mo- apoyan un enfoque sistemático
ción para el software implementado. para el desarrollo de software y modificación.
procesos de software se especifican para un La calidad KA software se ocupa de la
número de razones: para facilitar la planificación, aseguramiento y control de
comprensión humana, la comunicación y la procesos para el proyecto y la calidad del
coordinación; para ayudar agement-hombre de producto. Medición y medición de los resultados
los proyectos de software; para medir y en la Ingeniería Foundation ciones KA son
mejorar la calidad de los productos de software esenciales para la evaluación de los procesos de
de una manera eficiente; para apoyar proceso software y control- ling.
de mejora ción; y para proporcionar una base
para el puerto SUP- automatizado de ejecución DISTRIBUCIÓN DE TEMAS DE
del proceso. INGENIERÍA DE PROCESOS DE
SWEBOK KAs estrechamente relacionados SOFTWARE
con este proceso de Ingeniería de Software KA
incluyen el software de gestión de ingeniería, Como se ilustra en la Figura 8.1, este KA tiene
modelos de ingeniería de software y Métodos, que ver con la definición de procesos de
y Calidad de Software; el tema Análisis Causa software, los ciclos de vida del software,
Raíz Medición y que se encuentra en los evaluación de procesos de software y la mejora,
Fundamentos de Ingeniería KA también está la medición del software, el software y
estrechamente relacionado. Software de herramientas de proceso de inge- niería.
gestión de ingeniería se ocupa de la adaptación,
8-1
Figura 8.1. Desglose de los temas para el Proceso de Ingeniería de Software KA
1. Proceso de definición 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 definición de

proceso de software, gestión 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 mínimo, la descripción
de un proceso 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 también puede incluir su
entrada y criterios de salida y la descomposición
de las actividades de trabajo en tareas, que son
las unidades más pequeñas de trabajo sujetas a la
responsabilidad de gestión. 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 Ingeniería de Procesos
concluido, incluyendo los criterios de 8-3
aceptación para el producto del trabajo de salida
o productos de trabajo.
Un proceso de software puede incluir
subprocesos. Por ejemplo, la validación de los
requisitos de software es un proceso utilizado
para determinar si los requisitos
proporcionarán una base adecuada para el
desarrollo de software; es un subproceso del
proceso de requisitos de software. Las entradas
para la validación de requisitos son típicamente
unos requisitos de software valor especificado
y los recursos necesarios para realizar la
validación (personal, herramientas de
validación, tiempo suficiente). Las tareas de la
actividad de validación requisitos podrían
incluir requisitos de los comentarios,
prototipado y validación del modelo. Estas
tareas incluyen las asignaciones de trabajo para
las personas y equipos. La salida de validación
de requisitos suele ser una especificación de
requisitos de software validado que
proporciona entradas para el diseño de
software y el software de Exámenes procesos
ing. validación de requisitos y otros
subprocesos del proceso de requisitos de
software son a menudo intercalada y reiterada
en varias formas;
Figura 8.2. Elementos de un proceso de software
el proceso de requisitos de software y sus 454]

subprogramas, cesos pueden entraba y salía
varias veces durante el desarrollo de software o Dos objetivos de la gestión de procesos de
modificación. software
definición completa de un proceso de software son para darse cuenta de la eficiencia y eficacia
también puede incluir las funciones y que
competencias, TI SUP- puerto, técnicas de
ingeniería 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
realización del proceso.
Además, un proceso de software puede incluir
actividades tivas técnicas, colaborativas y
administraciones intercalados.
Notaciones para la definición 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;
gráficos de estado; BPMN; IDEF0; redes de
Petri; y los diagramas de actividad UML. Las
tareas de transformación dentro de un proceso
pueden definirse como procedimientos; 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 realización de una tarea.
Se debe enfatizar que no hay mejor proceso de
software o conjunto de procesos de software.
procesos de software deben ser seleccionados,
adaptados, y se aplican según sea apropiado para
cada proyecto y cada contexto de la
organización. No hay proceso ideal, o un
conjunto de procesos, existe.
1.1. Gestión de procesos de software

[3 *, s26.1] [4 *, p453-
resultado de un enfoque sistemático 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
(inserción de la tecnología o los cambios de
herramientas) están estrechamente
relacionados, ya que todos están 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 sólo para el producto de
software; que a menudo conducen al cambio
organizativo. El cambio de un proceso o la
introducción de un nuevo proceso puede tener
efectos de la ondulación a lo largo de un orga-
nización. Por ejemplo, los cambios en las
herramientas informáticas infraestructura y la
tecnología 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
introducción de una actividad de inspección
dentro de un proyecto de desarrollo de
software probablemente tendrá un impacto en
las pruebas de software proceso- ver revisiones
y auditorías de la calidad de software y KA en
las pruebas de software KA). Estas situa-
ciones también pueden ser denominados
“evolución del proceso.” Si las modificaciones
son extensas, a continuación, los cambios en la
cultura y la empresa modelo de organización es
probable que sea necesario para acomodar los
cambios en el proceso.
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, implementación y gestión 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 categorías de procesos de
los proyectos de software individuales. Sin software, modelos de ciclo de vida del software,
embargo, la aplicación sistemática de los software
procesos de software y de ciclo de vida del
software els mo- través de una organización
puede proporcionar beneficios a todos los
trabajos de software dentro de la organización, a
pesar de que requiere un compromiso a nivel
orga- zational. Una infraestructura de proceso de
software puede proporcionar definiciones de los
procesos, las políticas de preting inter y la
aplicación de los procesos, y las descripciones
de los procedimientos que se utilizarán para
implementar los procesos. Además, una
infraestructura de proceso de software puede
proporcionar financiación, 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 varía,
Dependiendo del tamaño y la complejidad de la
organización y los proyectos llevados a cabo
dentro de la organización. , organizaciones y
proyectos sencillos pequeños tienen necesidades
de infraestructura pequeños y sencillos. Grandes,
organizaciones y proyectos complejos, por sidad
nece-, tienen infraestructuras de procesos de
software más grandes y complejos. En el último
caso, se pueden establecer diferentes unidades
organizativas (tal como un grupo de procesos de
ingeniería de software o un comité ing steer-)
para supervisar la aplicación y mejora de los
procesos de software.
Un error común es que el establecimiento de
una infraestructura de proceso de software e
implementación de procesos de software
repetibles añadirá tiempo y costo para el
desarrollo y mantenimiento de software. Hay un
costo asociado con la introducción o la mejora
de un proceso de software; Sin embargo, expe-
riencia ha demostrado que la aplicación de la
mejora sistemática de los procesos de software
tiende a dar lugar a menor costo mediante la
mejora de la eficiencia, Ance Evitar- de
repetición del trabajo, y el software más fiable y
asequible. por lo tanto el rendimiento del
adaptación de procesos, y consideraciones considerados como menosSoftware de aIngeniería
efectivo menos quede Procesos
8-7
prácticas. 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, planificación de
software utilizados para especificar y prueba de software durante el análisis 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 más procesos adicionales que
proporcionan para el despliegue,
mantenimiento, soporte, la evolución, la
jubilación, y todos los demás procesos
inception--a la jubilación para un producto de
software, incluyendo la gestión de
configuración de software y los procesos de
garantía 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 múltiples para desarrollar y
mejorar el software.
procesos de software individuales no tienen
ningún 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 lógicas. 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.
Además de transmitir las relaciones
temporales y lógicas entre los procesos de
software, el modelo de desarrollo de software
de ciclo de vida (o modelos usan dentro de una
organización) incluye los mecanismos de
control para la aplicación 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 diseño arquitectónico software y los
cesos de construcción de software y pruebas de
software pro). ejecución 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 múltiples componentes de
software desarrollados por diferentes equipos).
Algunos procesos de software pueden ser
2.1. Categorías 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 software también
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, operación 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 gestión de
la configuración, Ance assur- calidad, y la
verificación y validación.
3. procesos de organización proporcionar
puerto SUP- para la ingeniería de software;
que incluyen capacitación, análisis de
medición de procesos, gestión de
infraestructuras, gestión de cartera y
reutilización, mejora de procesos de
organización y gestión de los modelos del
ciclo de vida del software.
4. procesos entre proyectos, tales como la
reutilización, la línea de productos soft-
ware, y la ingeniería de dominio; que
involucran a más de un proyecto de
software solo en una organización.
procesos de software, además de los

mencionados anteriormente incluyen los
siguientes.
los procesos de gestión de proyectos incluyen
procesos para la planificación y la estimación,
gestión de recursos, medición y control, lo que
lleva, la gestión de riesgos, la gestión de las
partes interesadas, y que coordinara la primaria,
el apoyo, la organización, y entre proyectos de
procesos de software Desa-, crear y mantener
proyectos.
procesos de software también se han
desarrollado para necesidades particulares, tales
como las actividades del proceso que se ocupan
de las características de calidad de software (ver
la calidad KA Software). Por ejemplo, los
problemas de seguridad durante el desarrollo de
software pueden requerir uno o más procesos de
2.2. Modelos de Ciclo de vida del software implementados en Software
cada unode de
Ingeniería 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 revisión 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
retroalimentación y iteración, según sea
necesario, seguido de la integración, 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 pequeños 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 predicción del ciclo de
vida de desarrollo de software, mientras que
SDLCs iterativos y ágiles se conocen como
modelos de adaptación del ciclo de vida de
desarrollo de software. Cabe señalar que
variabilidad actividades de mantenimiento OU
durante una SPLC puede llevarse a cabo
utilizando diferentes modelos SDLC, según sea
apropiado para las actividades de
mantenimiento.
Una característica 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 oído Lin- desarrollan típicamente por un
juego completo de los requisitos de software,
en la medida en que sea posible, durante la
iniciación y planificación 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 (véase la
Solicitud, la evaluación y aprobación de
software Cambios en el Consejo de Control de
Cambios en el Software de Gestión de Con-
figuración KA). Un modelo incremental
produce incrementos sucesivos de trabajando,
software entregable basado en la partición de
los requisitos de software para ser
modelos están diseñados para facilitar la adaptarse para reflejar las realidades del
evolución de los requisitos de software durante desarrollo y mantenimiento de software dentro del
el proyecto. contexto de la organización y ambiente de
Se debe enfatizar que el continuo de SDLCs negocios.
de lineal a ágil no es una línea delgada, recta. Otra consideración práctica: procesos de
Elementos de diferentes enfoques pueden ser software (como la gestión de la configuración,
incorporados en un modelo específico; por ejem-
plo, un software de modelo de ciclo de vida de
desarrollo incremental puede incorporar
requisitos de software secuenciales y fases de
diseño, pero permitir una gran flexibilidad en la
revisión de los requisitos de software y la
arquitectura durante la construcción de software.
2.3. La adaptación 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 organizacional,
las innovaciones en la tecnología, el tamaño del
proyecto, la criticidad del producto, los
requisitos normativos, prácticas de la industria, y
la cultura corporativa pueden determinar las
adaptaciones necesarias. La adaptación de los
procesos de software individuales y los modelos
del ciclo de vida del software (desarrollo de
productos) y puede consistir en añadir más
detalles a los procesos de software, actividades,
tareas y procedimientos para abordar los
problemas críticos. Puede consistir en el uso de
un conjunto alter- nar de las actividades que
logra el propósito y los resultados del proceso de
software. La adaptación también puede incluir la
omisión 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 prácticas

[2 *, p188-190]
En la práctica, 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 límites e interfaces prescritas, deben ser
reconocidos como idealizaciones que deben
Software
se lleva a cabo utilizando tanto de
unIngeniería
modelodedeProcesos
construcción y pruebas) se pueden adaptar para 8-11
facilitar su manejo Tate, soporte, evaluación y un método de evaluación. El
mantenimiento, migración, y el retiro del modelo puede proporcionar una norma para una
software. evaluación comparativa
Otros factores a tener en cuenta en la
definición y la adaptación de un modelo de
ciclo de vida del software incluyen la
conformidad requerida a las normas, las
Directivas y políticas; demandas de los
clientes; criticidad del producto de software; y
organizativo ridad maduración y competencias.
Otros factores incluyen la naturaleza del
trabajo (por ejemplo, modificación del
software existentes contra nuevo desarrollo) y
el dominio de aplicación (por ejemplo, el
espacio aéreo frente a la gestión del hotel).
3. Software de evaluación y
mejora de procesos
[2 *, P188, P194] [3 *, c26] [4 *, P397,
c15]
Este proceso de modelos de evaluación de

software direcciones tema, ods met evaluación
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 términos “evaluación de proceso” y
“capacidad de evaluación” se utilizan en lugar
de la evaluación del proceso. evaluaciones de
capacidad se realizan típicamente 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 desempeño se
realizan normalmente dentro de una organiza-
ción 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
niveles de organizaciones enteras, unidades
organizativas dentro de las organizaciones y
proyectos individuales. La evaluación puede
incluir temas como evalua- ción si se están
cumpliendo de entrada de proceso de software
y terios salida teria, para revisar los factores de
riesgo y la gestión del riesgo, o para identificar
las lecciones aprendidas. evaluación de proceso
la comparación entre los proyectos dentro de una objetivas que indica la consecución de los
organiza- ción y entre organizaciones. objetivos y resultados de un proceso de software
Una auditoría de proceso difiere de un proceso definido. Por ejemplo, una evaluación cuantitativa
de Assessment. Las evaluaciones se realizaron del proceso de inspección software puede ser
para determinar niveles de capacidad o madurez realizada por
y para identificar los procesos de software que
ser mejorado. Las auditorías se realizan
normalmente para verificar el cumplimiento con
las políticas y normas. Auditorías proporcionan
visibilidad ción manage- en las operaciones
reales que se lleva a cabo en la organización
para que las decisiones precisas y significativas
se pueden hacer cuestiones ING concern- que
están afectando a una actividad de
mantenimiento de desarrollo proyecto, o un
tema relacionado con el software.
factores de éxito de los procesos de software
evalua- ción y mejora dentro del software
Engineer- organizaciones ing incluyen buque
gestión patrocinio, la planificación, la
formación, los líderes experimentados y capaces,
el compromiso del equipo, gestión de las
expectativas, el uso de agentes de cambio,
además de proyectos piloto y experimentación
con herramientas. factores adicionales incluyen
la independencia del evaluador y la oportunidad
de la evaluación.
3.1. Modelos de evaluación de procesos de

software
[2 *, S4.5, S4.6] [3 *, s26.5] [4 *, p44-
48]
los modelos de evaluación de procesos de

software suelen incluir criterios de evaluación de
los procesos de software que son consideradas
como buenas prácticas. Estas prácticas pueden
hacer frente a los procesos de software Desa-
Ment solamente, o también pueden incluir temas
tales como el mantenimiento de software,
gestión de proyectos de software, ingeniería de
sistemas, o la gestión de recursos humanos.
3.2. Proceso de Software Métodos de evaluación

[1 *, p322-331] [3 *, s26.3]
[4 *, p44-48, s16.4] [6]
Un método de evaluación de procesos de

software puede ser cualitativa o cuantitativa. Las
valoraciones cualitativas se basan en el juicio de
expertos; evaluaciones cuantitativas asignar
puntuaciones numéricas a los procesos de
software basados en el análisis de pruebas
Software de mejoras
identificar y priorizar Ingeniería dedeseadas
Procesos
examinar los pasos del procedimiento seguido 8-13
y los resultados obtenidos, además de los datos (planificación); la introducción de una mejora,
relativos a los defectos encontrados y el tiempo incluyendo la gestión y la formación (hacer) el
requerido para encontrar y corregir los defectos cambio; evaluación de la mejora
en comparación con las pruebas de software.
Un método típico de proceso de software
evalua- ción incluye la planificación,
determinación de los hechos (por collect-
pruebas ing a través de cuestionarios,
entrevistas y observación de las prácticas de
trabajo), la recopilación y validación de los
datos del proceso, y el análisis y generación 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
evaluación de procesos de software y la
distribución del esfuerzo de las actividades de
evaluación son diferentes dependiendo del
propósito de la evaluación 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 calificación de madurez de los procesos
con el fin de calificar para un contrato o
premio.
La calidad de los resultados de la evaluación
depende del método de evaluación de procesos
de software, la integridad y la calidad de los
datos obtenidos, la capacidad y la objetividad
del equipo de evaluación, y las pruebas
examinadas durante la evaluación. El objetivo
de un proceso de evaluación 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 realización de una evaluación de
procesos de software siguiendo una lista de
comprobación 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 tamaño ciclos iterativos de mejora
continua. Un ciclo de mejora de procesos de
software general afecta a los subprocesos de
medición, 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
en comparación 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 (valoración capacidad) o los procesos en el nivel
Plan-Do-Check-Act modelo de mejora de de madurez 2 están siendo per- forman de una
procesos se puede aplicar, por ejemplo, para manera que proporciona una gestión
mejorar los procesos de software que mejoran la
prevención 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
organización.
Un sistema de evaluación continua implica la
asignación de una calificación a cada una de
procesos de software de interés; una por etapas
se establece sistema de clasificación por la
asignación de una calificación por edades de la
misma a todos los procesos de software dentro
de un nivel de proceso especificado. A re-
presentación de continua y el proceso de levels
se proporciona en la Tabla 8.1 puesta en escena.
modelos continuos suelen utilizar un nivel 0
opinión; por etapas modelos Tıpicamente no lo
hacen.
Tabla 8.1. Niveles de software proceso de

calificación
La La
representación representación
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
Optimización
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
(valoración capacidad), o se están realizando los
procesos de software en un grupo de madurez
visibilidad de los productos de trabajo inspección se introduce, Software de Ingeniería
el esfuerzo combinadode Procesos
8-15
intermedios y puede ejercer algún control sobre de la inspección
las transiciones entre procesos. En el nivel 3,
un único proceso de software o los procesos en
un nivel 3 grupo de madurez más el proceso o
los procesos en el nivel de madurez 2 están
bien definidas (tal vez en las políticas y
procedimientos de organización) y se repiten a
través de diferentes proyectos. Nivel 3 de la
capacidad del proceso o madurez proporciona
la base para el proceso de mejora ment través
de una organización porque el proceso es (o
procesos están) llevó a cabo en un ner Hombre-
similar. Esto permite la recogida de datos de
rendimiento de manera uniforme a través de
múltiples proyectos. En el nivel de madurez 4,
las medidas cuantitativas pueden ser aplicados
y utilizados para la evaluación de procesos;
análisis tical estadís- 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 representación continua, los diferentes
niveles de capacidad para diferentes procesos
de software proporcionan una guía para
determinar el orden en que serán mejorados
procesos de software. En la repre- sentación
por etapas, la satisfacción 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. Medición de software
[3 *, s26.2] [4 *,
s18.1.1]
Este proceso de software direcciones tema y

medición producto, la calidad de los
resultados de medición, modelos de
información, software y técnicas de medición
de procesos de software (ver Medición en los
Fundamentos de Ingeniería KA).
Antes de que un nuevo proceso se ejecute o
un proceso actual es modificado, los resultados
de medición de la situación actual deben
obtenerse a proporcionar una línea de base
para la comparación entre la situación actual y
la nueva situación. Para exami- plo, antes de
introducir el proceso de inspección de
software, el esfuerzo necesario para reparar
defectos descubiertos por las pruebas deben ser
medidos. Después de un período de puesta en
marcha inicial después de que el proceso de
además de las pruebas puede ser comparada con arriba recién introducido se ha reducido el número
la cantidad anterior de esfuerzo requerido para restante de defectos en el software.
probar solo. consideraciones similar se aplican medidas de productos que pueden ser
si se cambia un proceso. importantes en la determinación de la eficacia de
los procesos de software incluyen la complejidad
4.1. Proceso de Software y Medición 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 medición del producto

tienen que ver con la determinación 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
relación 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 (véase la eficiencia en el
software de Economía Ingeniería KA). Esfuerzo
(o el costo equivalente) es la principal medida de
los recursos para la mayoría de los procesos de
software, las actividades y tareas; que se mide en
unidades tales como horas-persona-persona,
días, semanas, o entre el personal y persona-
meses de esfuerzo o en unidades monetarias
equivalentes-tales como euros o dólares.
Eficacia es la relación de salida real a la salida
esperado producido por un proceso de software,
la actividad, o tarea; por ejemplo, el número real
de los defectos detectados y corregidos durante
las pruebas de software para el número esperado
de defectos para ser detectados y corregidos,
quizá basada en los datos his- tórica para
proyectos similares (véase la Eficacia en el
software de Economía Ingeniería KA). Tenga en
cuenta que la medición de los procesos de
software effec- tividad requiere la medición de
los atributos de productos de referencia; por
ejemplo, la medición de los defectos de software
descubierto y corregido durante pruebas de
software.
Hay que tener cuidado en la medición de los
atributos del producto con el fin de determinar la
efectividad del proceso. Por ejemplo, el número
de defectos detectados y corregidos por la
prueba no puede alcanzar el número esperado de
defectos y por lo tanto proporcionar una medida
engañosamente baja efectividad, ya sea porque
el software que está siendo probado es de mejor-
que la habitual calidad o quizás debido a la
introducción de un proceso de inspección aguas
Software de Ingeniería
los defectos que encuentran, como en de laProcesos
unidad
documentación de diseño, y otros productos de 8-17
trabajo relacionados. de pruebas por los desarrolladores de software o
También tenga en cuenta que la eficiencia y en un equipo ágil de funciones cruzadas. O el
la eficacia son conceptos independientes. Un cálculo de la productividad puede incluir ya sea
proceso de software eficaz puede ser ineficaz el esfuerzo del software
en la consecución de un resultado de procesos
de software deseado; por ejemplo, la cantidad
de esfuerzo realizado para encontrar defectos
de software y solución podría ser muy alto y
resultar en una baja eficiencia, en comparación
con las expectativas.
Un proceso eficiente puede ser ineficaz en
acompa- plishing la transformación deseada de
los productos de trabajo de entrada en los
productos de trabajo de salida; por ejemplo, el
hecho de encontrar y corregir un número
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 podría
incluir uno o más de los siguientes problemas:
trabajo de entrada productos 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
ejecución de procesos de software también 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 política organizativa.
En la ingeniería de software, la
productividad en per- que forman un proceso,
actividad o la tarea es la relación de salida
producida dividida por recursos consumidos;
por ejemplo, el número de defectos de software
dis- cubierto y corregida dividida por horas-
hombre de esfuerzo (véase la productividad en
el Engineer- Software ing Economía KA). La
medición precisa de la productividad debe
incluir el esfuerzo total usado para satisfa- isfy
los criterios de salida de un proceso de
software, actividad o la tarea; por ejemplo, el
esfuerzo requerido para corregir defectos
descubiertos durante el software de Exámenes
deben ser incluidos en la productividad del
desarrollo de software.
El cálculo 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- culación productividad de un equipo de
software si los miembros del equipo de corregir
desarrolladores o el esfuerzo de un equipo ING de la Ingeniería de Software de Gestión de KA

Ensayos independientes, dependiendo de quién describe un proceso para la implementación de un
fija los defectos encontrados por los probadores programa de medición 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
engañoso 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 medición de los procesos de
software y productos de trabajo son necesarias
para proporcionar resultados de medición
estandarizados a través de proyectos dentro de
una organización, para rellenar un depósito de
datos cal históricamente 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, serían
necesarias las definiciones de defectos de
software y personal-horas de pruebas esfuerzo
más contando reglas para defectos y esfuerzo
para obtener resultados de medición
satisfactorios.
La medida en que se institucionaliza el
proceso de software es importante; insuficiencia
ins- titucionalización 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 adopción
dentro de la unidad organizativa local oa través
de unidades más grandes de una empresa.
4.2. Calidad de los resultados de medición

[4 *, s3.4-3.7]
La calidad del proceso y medición 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
erróneas y las iniciativas de mejora de procesos
de software defectuoso. Otras propiedades
deseables de mediciones de software incluyen la
facilidad de recolección, análisis, y previa
presentación más una fuerte correlación entre la
causa y efecto.
El tema de ingeniería de software de medición
datos diferente varíanSoftware de Ingeniería
ampliamente de de
losProcesos
4.3. Información 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 información permiten el aplicable para establecer los nuevos datos y
modelado, análisis y predicción 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 validación y el
perfeccionamiento de los modelos de
información de software se producen durante
los proyectos de software y después de la
conclusión de los proyectos para asegurar que
el nivel de precisión es suficiente y que sus
limitaciones son conocidas y comprendidas.
modelos de información de software también
pueden ser desarrolladas para contextos
distintos proyectos de software; por ejemplo,
un modelo de información de software podría
ser desarrollado para los procesos que se
aplican en toda la organización, tales como los
procesos de garantía de calidad del software
software de gestión de configu- ración o en el
nivel de organización.
edificio de información de software modelo
de análisis impulsado implica el desarrollo, la
calibración y evaluación de un modelo. Un
software de infor- mación modelo se desarrolla
mediante el establecimiento de una
transformación planteado la hipótesis de
variables de entrada en resultados deseados;
por ejemplo, el tamaño y la complejidad de los
productos pueden ser transformados en
estimación acoplado esfuerzo necesario para
desarrollar un producto de software utilizando
una ecuación de regresión desarrollado a partir
de los datos observados de proyectos
anteriores. Un modelo se calibra mediante el
ajuste de los parámetros en el modelo para que
coincida con los resultados observados de
proyectos anteriores; Por ejemplo, el exponente
en un modelo de regresión no lineal puede ser
cambiado mediante la aplicación de la ecuación
de regresión a un conjunto diferente de
proyectos anteriores distintos de los proyectos
utilizados para desarrollar el modelo. Un
modelo se evalúa mediante la comparación de
los resultados calculados con los resultados
reales para un conjunto diferente de datos
similares. Hay tres posibles Evaluación
resultados:
1. resultados calculados para un conjunto de

8-11
2. Los resultados calculados para un nuevo Técnicas de medición de proceso también

conjunto de datos se encuentran cerca de los proporcionan la información 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. técnicas surement medi- proceso
a los parámetros 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. Técnicas de medición de procesos
posteriores están muy cerca y no se cuantitativa
necesitan ajustes en el modelo.
4.4. Técnicas de medición de procesos de
La evaluación continua del modelo puede software
Cate indicación de una necesidad de adaptación [1 *, c8]
en el tiempo como el contexto en el que se
aplica el modelo de cambios. técnicas de medición de procesos de software se
Las Metas / Preguntas / Métrica método utilizan para recopilar datos de proceso y producto
(GQM) fue pensado originalmente para el de trabajo, transformar los datos en información
establecimiento de actividades La medición, pero útil, y analizar la información para identificar las
también se pueden utilizar para guiar el análisis 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 construcción de información de nuevos procesos de software.
software modelo de análisis impulsada;
resultados obtenidos del modelo de información
de software se pueden utilizar
para guiar la mejora del proceso.
El siguiente ejemplo ilustra la aplicación
del método GQM:
• Objetivo: Reducir la solicitud de cambio

promedio
tiempo de procesamiento en un 10% dentro
de los seis meses.
• Pregunta 1-1: ¿Cuál es el tiempo de
procesamiento de solicitud de cambio de
línea de base?
• Métricas 1-1-1: Promedio de solicitud de
cambio
los tiempos de procesamiento en la fecha de
inicio
• Métricas 1-1-2: La desviación estándar del
cambio
tiempos de procesamiento de petición a la fecha
de inicio
• Pregunta 1-2: ¿Cuál es la hora actual de
procesamiento de solicitud de cambio?
• Métricas 1-2-1: Promedio de solicitud de
cambio
tiempos procesando en ese momento
• Métricas 1-2-2: La desviación estándar del
cambio
los tiempos de procesamiento de solicitudes
actualmente
8-12 Guía SWEBOK® V3.0 [4 *, S5.1, S5.7,
s9.8]
El propósito de las técnicas de medición de

procesos cuantitativos es recoger, transformar
y analizar los datos de proceso cuantitativo y
producto de trabajo que se puede utilizar para
indicar dónde se necesitan mejoras de proceso
y para evaluar los resultados de las iniciativas
de mejora de procesos. Técnicas de medición
de proceso cuantitativo se utilizan para COL-
lect y analizar los datos en forma numérica a la
que técnicas matemáticas y estadísticas se
pueden aplicar.
datos de proceso cuantitativos se pueden
recoger como un subproducto de los procesos
de software. Por ejemplo, el número de
defectos detectados durante las pruebas de
software y las horas de personal gastados
pueden debe desechar por por medición
directa, y la productividad de descubrimiento
defecto se pueden derivar por calculat-
defectos ing descubiertos por personal horas.
Herramientas básicas para el control de
calidad se pueden utilizar para analizar los
datos de medición de procesos cuantitativos
(por ejemplo, hojas de verificación, diagramas
de Pareto, histogramas, diagramas de
dispersión, gráficos de series, gráficos de
control y diagramas de causa y efecto) (véase
el análisis de causa raíz en la Ingeniería
fundamentos KA). Además, diversas técnicas
estadísticas se pueden usar de ese rango de
cálculo de las medianas y los medios para
métodos de análisis multivariante (ver Análisis
estadístico en los Fundamentos de Ingeniería
KA).
Los datos recogidos usando proceso
cuantitativo medi- técnicas surement también
se pueden utilizar como entradas a los modelos
de simulación (ver Modelando, Prototyp- Ing,
y Simulación en la Ingeniería Foundation
ciones KA); estos modelos se pueden utilizar
para evaluar el impacto de diferentes enfoques
para la mejora de procesos de software.
Clasificación de defectos ortogonal (ODC)
se puede utilizar para analizar los datos Ment
medición cuantitativa del proceso. ODC se
puede utilizar para los defectos de grupo
detectado en categorías y vincular los defectos
en
8-13
cada categoría para los procesos del proceso de Además, las herramientas de negocio de
software o software, donde un grupo de defectos propósito general, tal como una hoja de cálculo,
origi- NATed (ver Defecto Caracterización en la puede ser útil.
Soft mercancías Quality KA). defectos interfaz Ingeniería 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 ejecución de
de diseño de software; mejorar el proceso de las definiciones de procesos defi-, y
diseño de software reducirá el número de proporcionar orientación a los seres humanos en
defectos de la interfaz de software. ODC puede la formación de per- procesos bien definidos.
proporcionar datos cuantitativos para la herramientas simples, tales como procesadores
aplicación de análisis de causa raíz. Control de texto y hojas de cálculo se pueden utilizar
Estadístico 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, también SUP- puerto de trazabilidad entre las
el uso de gráficos de control. entradas y salidas de múltiples procesos de
software (como el análisis de las necesidades de
4.4.2. Técnicas de medición de procesos los interesados, los requisitos de software ción
cualitativos especificaciones, arquitectura de software, y el
[1 *, s6.4] diseño detallado de software), así como los
resultados de los procesos de software como la
Cualitativa técnicas- medición de procesos que documentación , componentes de software,
incluyen entrevistas, cuestionarios y la opinión casos de prueba, y la información de errores.
de expertos, se puede utilizar para aumentar las La mayor parte de las áreas de conocimiento
técnicas de medición de procesos cuantitativos. en esta guía se describen las herramientas
técnicas de consenso del grupo, incluyendo la especializadas que pueden ser utilizados para
técnica Delphi, se pueden utilizar para obtener gestionar los procesos dentro de ese KA. En
un consenso entre los grupos de interesados. particular, véase la Gestión de la Configuración
de Software KA para una discusión de las
5. Herramientas de Ingeniería de Software herramientas de gestión de configuración de
Process software que pueden ser utilizados para
[1 *, s8.7] gestionar la construcción, integración y procesos
para liberar los productos de software. Otras
herramientas de proceso de software soportan herramientas, como los de gestión 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 geográficamente equipos dispersos (virtuales).
anotaciones tales como diagramas de flujo de Cada vez más, las herramientas de proceso de
datos, gráficos de estado, BPMN, diagramas software están disponibles a través de las
IDEF0, redes de Petri, y los diagramas de instalaciones de computación en la nube, así
actividad UML. En algunos casos, las como a través de infraestructuras dedicadas.
herramientas de proceso de software permiten Un panel de control de proyectos o en el
diferentes tipos de análisis y simulaciones (por salpicadero pueden dis- proceso seleccionado el
ejemplo, de simulación de eventos discretos). En juego y los atributos del producto para proyectos
de software e indicar las medidas que están
dentro de los límites de control y aquellos que
necesitan una acción correctiva.
2011 [3 *]
2009 [1
2009 [2
JustaLey de
Kan 2003
SommervilLe
[4 *]
Mugirre
*]
*]
p28-29,
1. Definición del proceso de software P177 P295 p36,
c5
1.1. Gestión 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. Categorías 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 adaptación de procesos de s2.7 p51
software
2.4. Consideraciones prácticas p188-190
3. Software de Evaluación y
P188, P194 c26 P397, c15
Mejora de Procesos
S4.5,
3.1. Modelos de evaluación de procesos de s26.5 p44-48
S4.6
software
3.2. Evaluación de Procesos de Software p44-48,
p322-331 s26.3
métodos 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
Medición de Software s26.2 s18.1.1
4.1. Proceso de software y de productos S6.3, s26.2,
Medición P273 P638
S3.4,
S3.5,
4.2. Calidad de los resultados de
S3.6,
medición
s3.7
4.3. Información de software Modelos p310-311 pag. 712- s19.2
713 S5.1,
4.4. Medición de Procesos de Software s6.4,
S5.7,
técnicas c8
s9.8
5. Proceso de Ingeniería de Software s8.7
Herramientas
8-15
LECTURAS forman las evaluaciones de proceso.
Software de la extensión de la Guía para la

Dirección de Proyectos de Knowledge®
(SWX) [5].
SWX ofrece adaptaciones y ampliaciones de las

prácticas genéricas de gestión de proyectos
documentado en la Guía PMBOK ® para la
gestión de proyectos de software. La principal
contribución de esta extensión de la Guía del
PMBOK® es descrip- ción de los procesos que
son aplicables para la gestión de proyectos de
software de ciclo de vida de adaptación.
D. Gibson, D. Goldenson, y K. Kost,

“Rendimiento de resultados de mejora
de proceso basado en CMMI” [6].
Este informe técnico resume públicamente

dispo- evidencia empírica 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 colaboración de representantes
de 10 organizaciones que han logrado notables
resultados de rendimiento cuantitativo a través
de sus esfuerzos de mejora basados en CMMI.
CMMI® para el Desarrollo, versión 1.3 [7].
CMMI® para el Desarrollo, versión 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 prácticas para el desarrollo y mejora
de productos y servicios para satisfacer las
necesidades de los clientes y usuarios finales.
ISO / IEC 15504-1: 2004 Información

tecnologıa-Proceso de evaluación-Parte 1:
Conceptos y vocabulario [8].
Este estándar, conocido comúnmente como

SPICE (Software Mejora de Procesos y
determinación de la capacidad), incluye
múltiples partes. Parte 1 proporciona conceptos
y vocabulario para los procesos de desarrollo de
software y funciones de gestión de negocio-
relacionados. Otras partes de 15504 definen los
requisitos y procedimientos para per- que
Referencias

de software, Wiley-IEEE Computer
[2 *] JW Moore, La Hoja de Ruta de Ingeniería

de Software: Una guía basada en
estándares, Wiley-IEEE Computer Society
Press, 2006.

[4 *] SH Kan, métricas y modelos en Ingeniería

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

quinta edición, 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, Versión 1.3,”
Software Engineering Institute, 2010;
http: //
resources.sei.cmu.edu/library/asset-
view. cfm? assetId = 9661.
[8] ISO / IEC 15504-1: 2004, Información

Tecnología-Proceso de Evaluación-Parte
1: Conceptos y Vocabulario, ISO / IEC
2004.
8-17
CAPÍTULO 9
Modelos y métodos de software de

ingeniería
SIGLAS DISTRIBUCIÓN DE TEMAS PARA

MODELOS Y MÉTODOS DE
3GL Idioma tercera generación INGENIERÍA DE SOFTWARE
BNF Backus-Naur Form
FDD Desarrollo de funciones-Driven Este capítulo sobre modelos de ingeniería de
software y
Desarrollo integrado
IDE métodos se divide en cuatro áreas temáticas
Ambiente
principales:
PBI Producto Cartera de artículos
RAD Desarrollo rápido de aplicaciones • Modelado: Se analiza la práctica general de
UML Lenguaje de Modelado Unificado la modelización y presenta temas en los
principios de modelado; propiedades y
XP Programación extrema
expresión de los modelos; modelado de
sintaxis, la semántica y la pragmática; y las
INTRODUCCIÓN condiciones previas, postcondiciones, e
invariantes.
modelos y métodos de ingeniería de software • Tipos de modelos: Brevemente discute
imponen estructura en la ingeniería de software modelos y agregación de submodelos y
con el objetivo de hacer que la actividad proporciona algunas características
sistemática y repetible, y en definitiva más generales de los tipos de modelo
éxito-orientado. El uso de modelos proporciona comúnmente encontradas en la práctica de
un enfoque para la resolución de problemas, una la ingeniería de software.
notación, y los procedimientos para la • Análisis de Modelos: Presenta algunas de las
construcción y análisis de modelo. Métodos técnicas de análisis comunes utilizados en
proporcionan una aproximación a la ing modelo- para verificar la integridad, la
especificación sistemática, diseño, construcción, consistencia, rectness cor-, trazabilidad, y la
pruebas y verificación del software de punto interacción.
final y los productos de trabajo asociados. • Métodos de ingeniería de software: Presenta
modelos y métodos de ingeniería de software un breve resumen de los métodos de
varían ampliamente en su alcance-de abordar ingeniería de software de uso común. La
una sola fase del ciclo de vida del software de discusión se guía al lector a través de un
cubrir el ciclo de vida del software pleta com-. resumen de los métodos heurísticos,
El énfasis en esta área de conocimiento (KA) métodos formales, la creación de prototipos,
está en ingeniería de software modelos y y los métodos ágiles.
métodos que abarcan múltiples fases del ciclo de
vida del software, ya que los métodos El desglose de los temas para los modelos de
específicos para las fases individuales del ciclo ingeniería de software y métodos KA se muestra
de vida están cubiertas por otra KAs. en la Figura 9.1.
1. Modelado
Modelización de software se está convirtiendo técnica para ayudar a los ingenieros de software a
en un omnipresente entender,
9-1
Figura 9.1. Desglose de los temas de los modelos de ingeniería de software y métodos 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 comunicación de los
partes interesadas son aquellas personas o partes
que tienen un interés explícitas o implícitas en el
software (por ejemplo, usuario, comprador,
proveedor, arquitecto, certificando autoridad,
evaluador, desarrollador, ingeniero de software,
y tal vez otros).
Si bien hay muchos lenguajes de modelado,
notaciones, técnicas y herramientas en la
literatura y en la práctica, 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 sistemático de los
aspectos significativos tando sentantes de
software en estudio, facilitando la toma de
Modelos de Ingeniería de Software y Métodos 9-
decisiones importantes a otros en las 3
comunidades interesadas. Hay tres principios
generales que guían este tipo de actividades de
modelado:
• Modelar los Fundamentos: Buenos

modelos no suelen representan cada
aspecto o característica del software bajo
todas las condiciones posibles. Modelado
por lo general implica el desarrollo de sólo
aquellos aspectos o características del
software que necesitan respuestas
específicas, abstraerse de cualquier
información 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 expresión 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 organización de la
información en vistas centra los esfuerzos
de modelado de software en concreto
preocupaciones pertinentes a la vista aseveraciones, restricciones, funciones o

mediante las apropiadas notación, el descripciones de componentes.
vocabulario, métodos y herramientas. • Exactitud: El grado en que el modelo
• Permitir comunicaciones efectivas: satisface sus necesidades y cationes de diseño
Modelado emplea el dominio de aplicación especificación y está libre de defectos.
del vocabulario del software, un lenguaje de
modelado, y la expresión semántica (en
otras palabras, tras tanto dentro del contexto
ing). Cuando se utiliza de manera rigurosa y
sistemática, esta modelado resultado en un
enfoque de informes que facilita la
comunicación eficaz de la información de
software para interesados en el proyecto.
Un modelo es una abstracción o

simplificación de un componente de software.
Una consecuencia del uso de la abstracción es
que hay una única abstracción completamente
describe un componente de software. Por el
contrario, el modelo del software se representa
como una agregación de abstracciones, que,
cuando se toman juntos-describir aspectos
seleccionados, perspectivas o puntos de vista,
sólo aquellos que son necesarios para tomar
decisiones informadas y responder a las razones
de la creación de la modelo en el primer lugar.
Esta simplificación conduce a un conjunto de
supuestos sobre el contexto en el que se coloca
el modelo que también 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 Expresión 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 notación 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
Los modelos se construyen para representar 5
objetos del mundo real y sus comportamientos Los modelos pueden ser sorprendentemente
para responder a preguntas específicas acerca engañoso. El hecho de que un modelo es una
de cómo se espera que el software para operar. abstracción con la falta de informa- ción puede
Interrogar a los modelos, ya sea a través de la conducir a uno en un falso sentido de completa-
exploración, simulación, o revisión-puede mente la comprensión 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, diseño y / o
implementación pueden ser manejados de
manera apropiada.
El elemento de expresión primaria de un
modelo es una entidad. Una entidad puede
representar artefactos de hormigón (por
ejemplo, procesadores, sensores, o robots) o
artefactos abstractas (por ejemplo, módu- los
de software o protocolos de comunicación).
entidades modelo se conectan a otras entidades
que utilizan relaciones (en otras palabras,
líneas o los operadores textuales en las
entidades de destino). Expresión de las
entidades modelo se puede realizar usando
textuales o gráficas lenguajes de modelado;
Ambos tipos de lenguaje de modelado se
conectan a través de entidades del modelo de
construcciones del lenguaje específicos. El
significado de una entidad puede ser
representado por su forma, atributos de texto, o
ambos. En general, la información textual se
adhiere a la estructura sintáctica 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 diseño aplicado al
esfuerzo de modelado, la vista específica está
construyendo, y la entidad a la que el elemento
notación específica puede estar unido.
Múltiples vistas del modelo pueden ser
necesarios para capturar la semántica
necesarios del software.
Al usar los modelos soportados con
automatización ción, los modelos se pueden
comprobará la integridad y consistencia. La
utilidad de estas comprobaciones depende en
gran medida del nivel de rigor táctica
semántica y sin- aplicada al esfuerzo de
modelado en adi- ción al soporte de
herramientas explícita. La corrección es
Tıpicamente comprobado a través de la
simulación y / o revisión.
1.3. Sintaxis, la semántica y la pragmática

[2 * c2s2.2.2p6] [3 *,
c5s0]
en relación con el esfuerzo de modelado) puede entorno de modelado; esto puede no ser obvia. El
haber una unión de varios submodelos y modelo debe ser revisado para supuestos
cualquiera de los modelos de función especiales. documentados. Mientras que la sintaxis de
El examen y la relación tivo de toma de modelado puede ser idéntico, el modelo puede
decisiones a un modelo único dentro de esta significar algo muy diferente en el nuevo entorno,
colección de submodelos pueden ser que es un contexto diferente. Además, consideran
problemáticos. que como software madura y se realizan cambios,
La comprensión de los significados precisos de la discordia semántica
constructos ELING MOD- también puede ser
difícil. lenguajes de modelado se definen por
reglas sintácticas y semánticas. Para lenguajes
textuales, la sintaxis se define utilizando una
gramática notación que define construcciones
lenguaje válidos (por ejemplo, la Forma
Backus-Naur (BNF)). Para lenguajes gráficos, la
sintaxis se define usando modelos gráficos
llamados els metamod-. Al igual que con BNF,
metamodelos definen las construcciones
sintácticas válidas de un lenguaje de modelado
gráfico; metamodelo define cómo estos
constructos se pueden componer para producir
modelos válidos. La semántica 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 línea 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 interpretación de este
modelo.
Como cuestión práctica, por lo general hay un
buen entendimiento de la semántica de un
modelo de software específico debido al
lenguaje de modelado elegido, cómo 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 través del modelo incluso en
presencia de información incompleta a través de
abstracción; pragmática explica cómo el
significado se materializa en el modelo y su
contexto y comunicarse efectivamente a otros
ingenieros de software.
Todavía hay casos, sin embargo, donde se
necesita cautela ción en relación con el
modelado y la semántica. Por ejemplo, las piezas
modelo importado de otro modelo o de la
biblioteca deben ser examinados para supuestos
semánticos que entran en conflicto en el nuevo
puede ser introducido, lo que conduce a específico; queModelos
puededeestar
Ingeniería de Software
compuesta y Métodos
de uno o 9-
7
errores. Con muchos ingenieros de software más diagramas. La colección de submodelos
que trabajan en una parte del modelo con el puede emplear múltiples
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 intención 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 métodos, el

ingeniero de software suele comenzar con un
conjunto de suposiciones sobre el estado del
software antes de, durante y después de la
función o método cutis eje-. Estos supuestos
son esenciales para el funcionamiento rect
angular de la función o método y se agrupan,
para la discusión, como un conjunto de
condiciones previas, postcondiciones, e
invariantes.
• Condiciones previas: Un conjunto de

condiciones que deben ser satisfechas
antes de la ejecución de la función o
método. Si estas condiciones previas no se
sostienen antes de la ejecución de la
función o método, la función o método
pueden producir resultados involuntaria de
OU.
• poscondiciones: Un conjunto de
condiciones que se garantiza que sea cierto
después de la función o método ha
ejecutado con éxito. Por lo general, las
condiciones posteriores representan cómo
el estado del software ha cambiado, cómo
pará- metros pasados a la función o
método han cambiado, cómo los valores
de datos han cambiado, o cómo 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
después de la ejecución de la función o
método. Estas invariantes son pertinentes
y necesarios para el software y el correcto
funcionamiento de la función o método.
2. tipos Modelos de
Un modelo típico consiste en una agregación

de submodelos. Cada submodelo es una
descripción parcial y se crea para un propósito
lenguajes de modelado o una sola modelado evento de activación guardado o descuido que se
LANGUAGE. El Lenguaje de Modelado produce en el entorno de modelado. modelos de
Unificado (UML) reconoce una rica colección flujo de control representan cómo 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 común: los pasos donde los datos se mueve a través de
modelos de información, modelos de procesos hacia almacenes de datos o sumideros de
comportamiento, y los modelos de estructura datos.
(ver sección 1.1).
2.1. Modelado de información

[1 *, c7s2.2] [3 *, c8s1]
modelos de información proporcionan un foco

central en datos e información. Un modelo de
información es una representación abstracta que
identifica y define un conjunto de conceptos,
propiedades, relaciones y con- straints en
entidades de datos. El modelo de información
semántica o tual concepción 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 cómo este modelo es en realidad
asignado a la implementación del software. El
modelo de información semántica o conceptual
es una abstracción y, como tal, incluye sólo los
conceptos, propiedades, relaciones y
restricciones necesarias para conceptualizar el
punto de vista del mundo real de la información.
transformaciones posteriores del modelo de
información semántica o conceptual conducen a
la elaboración de modelos de datos, entonces
Physicians cal lógico 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 funciones del software que está
siendo modelado. Tamiento modelos ioral
generalmente tomar tres formas básicas:
máquinas de estado, los modelos de flujo de
control, y Data- modelos de flujo. Las máquinas
de estado proporcionan un modelo de software
como una colección 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 Ingeniería
de estado de Software
se alcanzan y Métodos
por un 9-
conjunto
9
[1 *, c7s2.5, c7s3.1, c7s3.2] [3 *, c5s3] [4 *, c4] de entradas correctas); modelos también se
pueden examinar para Ness COMPLETE-
modelos de estructura ilustran la composición manualmente mediante inspecciones u otras
física o lógica de software a partir de sus técnicas de revisión (ver la calidad KA
diversas partes componente. modelado de Software). errores
estructuras establece el límite definido entre el
software en ejecución 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 composición, la descomposición, la
generalización y especialización de entidades;
identificación de las relaciones Evant rel- y
cardinalidad entre entidades; y la definición 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. Análisis de Modelos
El desarrollo de modelos permite el ingeniero

de software la oportunidad de estudiar, razonar
sobre, y comprender la estructura, función, uso
funcional, y las consideraciones de montaje
se asocia a los programas. Es necesario un
análisis de los modelos construidos para
asegurar que estos modelos son completos,
coherentes, y lo suficientemente correcta para
servir a su propósito previsto para las partes
interesadas.
Las secciones siguientes describen
brevemente las técnicas de análisis 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 análisis

[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 crítico del proceso de
obtención de requisitos para codificar
mentación 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
técnicas tales como el análisis estructural y
análisis de espacio de estado de accesibilidad
(que aseguran que todos los caminos en los
y avisos generados por estas herramientas de

análisis y demostrado en una inspección o El desarrollo de software normalmente implica el
revisión indican las acciones correctivas uso, creación y modificación de muchos
necesarias probables para garantizar la productos de trabajo, tales como documentos de
integridad de los modelos. planificación, especificación ciones de proceso,
requisitos de software, diagramas, diseños
3.2. La consistencia para analizar
[3 *, c4s1.1p7, c4s6] [5 *, P8-11]
La consistencia es el grado en que los modelos

contienen no hay requisitos en conflicto,
afirmaciones, straints con-, funciones o
descripciones de componentes. Típicamente, la
comprobación de consistencia se logra con la
herramienta de modelado utilizando una función
de análisis automatizado; modelos también se
pueden examinar para consistencia de forma
manual mediante inspecciones u otras técnicas
de revisión (ver la calidad KA Software). Al
igual que con integridad, errores y avisos
generados por estas herramientas de análisis y
demostrado en una inspección o revisión indican
la necesidad de una acción correctiva.
3.3. El análisis de la corrección

[5 *, P8-11]
La corrección es el grado en que un modelo sat-

isfies sus requisitos de software y las
especificaciones de diseño de software, está libre
de defectos, y, en última instancia, cumple las
necesidades de los interesados. El análisis de la
corrección incluye la verificación de corrección
sintáctica del modelo (es decir, el uso correcto
de la gramática lenguaje de modelado y
construcciones) y la verificación de la
corrección semántica 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 corrección sintáctica y semántica, se
analiza que, ya sea de forma automática (por
ejemplo, usando la herramienta de modelado
para comprobar modelo corrección sintáctica) o
manualmente (mediante inspecciones u otras
técnicas de revisión) -searching para posibles
defectos y luego retirar o la reparación de los
defectos confirmados antes de que el software
está liberado para su uso.
3.4. trazabilidad
[3 *, c4s7.1, c4s7.2]
y pseudo-código, código escrito a mano y análisis para Modelos de Ingeniería
el ingeniero de de Software ypara
software Métodos 9-
11
generado herramienta, casos manuales y revisar el diseño de interacción 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 través 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 management
de productos de trabajo de software y software
de calidad proceso; sino que también
proporciona garantías a los titulares de stake-
que todos los requisitos se han cumplido. La
trazabilidad permite cambiar el análisis una vez
que el software es desarrollado y puesto en
libertad, ya que las relaciones a los productos
de trabajo de software fácilmente 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, diseño,
código y / o entidades de prueba que puedan
ser representados en los modelos y otros
productos de trabajo de software. (Para obtener
más información sobre la trazabilidad, ver el
KA Software Configuration Management).
3.5. Análisis de interacción

[2 *, c10, c11] [3 *, c29s1.1, c29s5] [4 *,
c5]
Interacción análisis se centra en las relaciones

de las comunicaciones o de control de flujo
entre entidades utilizadas para llevar a cabo
una tarea o función específica dentro del
modelo de software. Este análisis plos ines el
comportamiento dinámico de las interacciones
entre las diferentes porciones del modelo de
software, incluyendo otras capas de software
(tal como el sistema operating, middleware, y
aplicaciones). También puede ser importante
para algunas aplicaciones de software para
examinar las interacciones entre la aplicación
de software ordenador y el software de
interfaz de usuario. Algunos entornos de
modelado de software proporcionan
instalaciones de simulación para estudiar
aspectos del comportamiento dinámico de
software de modelado. de ping paso- a través
de la simulación proporciona una opción de
4. Métodos de ingeniería de software modelo de datos se construye desde el punto

de vista de los datos o informaciones
Software métodos de ingeniería proporcionan un utilizados. Las tablas de datos y barcos
enfoque sistemático y nizado oral desarrollo de PARENTESCO definen los modelos de
software para un equipo de destino. Existen datos. Este método mo- datos eling se utiliza
numerosos métodos 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 método o métodos para la tarea de
desarrollo de software a la mano apropiada; esta
elección puede tener un efecto dramático en el
éxito del proyecto de software. El uso de estos
métodos de ingeniería 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 representación en
un conjunto de trabajo de código y datos.
métodos de ingeniería de software
seleccionados se dis- cussed a continuación. Las
áreas temáticas se organizan en las discusiones
de los métodos heurísticos, Métodos formales,
métodos de prototipos, y los métodos ágiles.
4.1. Los métodos heurísticos

[1 *, c13, c15, c16] [3 *, c2s2.2, c5s4.1,
c7s1,]
Los métodos heurísticos son aquellos métodos

de ingeniería de software basados en la
experiencia que han sido y son bastante
ampliamente practicados en el software indus-
tria. Esta área temática contiene tres grandes
categorías: Discusión del análisis estructurado y
métodos de diseño, métodos de modelado de
datos y métodos de análisis y diseño orientados
a objetos.
• Análisis estructurado y métodos de diseño:

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 través de
increas- diseños vez más detalladas . El
diseño detallado finalmente converge a los
detalles o especificaciones del software que
deben codificarse muy específicos (con la
mano, generado automáticamente, o
ambos), construido, probado y verificado.
• Los métodos de modelado de datos: El
Modelos
análisis dederequerimientos,
y / oy Métodos 9-
etapas de
diseños de bases de datos o datos de 13
repositorios Tıpicamente encuentran en diseño específico para describir la entrada /
software de negocios, donde los datos se salida comportamiento. lenguajes de
gestiona activamente como un recurso especificación son idiomas no directamente
sistemas de negocio o activo. ejecutables; son
• ods Análisis y Diseño Orientado a Objetos
met-: El modelo orientado a objetos se
representa como una colección de objetos
que encapsulan datos y las relaciones e
interactuar con otros objetos a través de
métodos. 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 modelos conduce
a un diseño detallado. El diseño detallado
se luego se convirtió bien a través de
iteración sucesiva o transformada
(utilizando algún mecanismo) en la vista
de la implementación del modelo, donde el
código y Envoltorios enfoque para el
lanzamiento eventual producto de software
y el despliegue ing se expresa.
4.2. Métodos formales

[1 *, c18] [3 *, c27] [5 *, p8-
24]
Los métodos formales son los métodos de

ingeniería de software utilizadas para
especificar, desarrollar y verificar el software
mediante la aplicación de un riguroso notación
y lenguaje basado camente mathemat-. A
través del uso de un lenguaje de especificación,
el modelo de software se puede comprobar la
consistencia (en otras palabras, la falta de
ambigüedad), integridad, y la corrección de
forma sistemática y automatizada o la moda
semi-automatizado. Este tema está relacionado
con la sección de análi- sis formal de los
requisitos de software KA.
Esta sección se ocupa de los lenguajes de
especificación, el refinamiento de programas y
de derivación, cationes verificables formal, y la
inferencia lógica.
• especificación de Idiomas: Lenguajes de

especificación proporcionan la base
matemática de un método formal;
lenguajes de especificación son formales,
los lenguajes de programación de alto
nivel (en otras palabras, no es un lenguaje
clásico de tercera generación (3GL)
programa- lenguaje ming) utilizado
durante la especificación de software,
típicamente compuesto de una notación y predecir el comportamiento del software sin

sintaxis, la semántica para el uso de la tener que ejecutar el software. Algunos
notación, 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 diseño o código.
Derivación: Pro- gram refinamiento es el
proceso de creación de un nivel más bajo (o
más detallada) especificación utilizando una
serie de transformaciones. Es a través de
sucesivas transformaciones que el ingeniero
de software se deriva una representación
ejecutable de un programa. Las
especificaciones pueden ser refinados,
añadiendo detalles hasta que el modelo se
puede formu- lated en un lenguaje de
programación 3GL o en una parte ejecutable
de la lengua especifica- ción elegida. Este
refinamiento especificación se hace posible
mediante la definición de las
especificaciones con propiedades
semánticas precisas; las especificaciones
deben establecer no sólo las relaciones entre
las entidades, sino también los significados
de tiempo de ejecución exactos de esas
relaciones y operaciones.
• La verificación formal: Modelo de cheques
es un método de verificación formal; que
por lo general implica la realización de
análisis ción o de alcanzabilidad un
exploratorios espacio de estado para
demostrar que el diseño de software
representado tiene o conserva ciertas
propiedades modelo de inter- est. Un
ejemplo de comprobación de modelo es un
análisis 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
máquina de estados finitos u otro autómata
formalmente definido.
• La inferencia lógica: La inferencia lógica es
un método de diseño de software que
implica especificar las condiciones previas y
condiciones posteriores alrededor de cada
bloque importante del diseño, y el uso de la
lógica del desarrollo de la prueba de que las
condiciones previas y condiciones
posteriores deben tener en todas las entradas
matemática. Esto proporciona una manera
para que el ingeniero de software para
Modelos
interesados en deelIngeniería de Software
proyecto, y Métodos 9-
impulsado
4.3. Los métodos 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-
creación 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 mínimamente funcionales de
una aplicación de software, por lo general
para prueba- ing nuevas características,
solicitando información sobre los requisitos
de software o interfaces de usuario, fur- Ther
explorar requisitos de software, diseño de
software, o opciones de implementación, y / o
la obtención de alguna otra información útil
sobre el software. El ingeniero de software
selecciona un método de creación de
prototipos para entender el menos aspectos o
componentes del software primero entiende;
este enfoque es en contraste con otros
métodos de ingeniería de software que
normalmente comienzan desarrollo con las
porciones más entendidos primeros.
Típicamente, el producto proto-
mecanografiada no se convierta en el
producto de software final sin extensa
retrabajo desarrollo o la refactorización.
En esta sección se analiza estilos de creación
de prototipos, Tar recibe, y técnicas de
evaluación en breve.
• Estilo de prototipos: Esto se refiere a los

diversos enfoques para desarrollar
prototipos. prototipos pueden
desarrollarse como código o productos de
papel de usar y tirar, como una evolución
de un diseño trabajando, o como una
especificación 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 prototipo es el producto
específico que se está servido por el
esfuerzo de creación de prototipos. Los
ejemplos de objetivos de creación de
prototipos incluyen una especificación de
requisitos, un elemento de diseño
arquitectónico o componente, un
algoritmo, o una interfaz de usuario
hombre-máquina.
• Técnicas de Evaluación de prototipos:
Un prototipo puede ser usado o
evaluado en un nú- mero de maneras por
el ingeniero de software u otros
un objetivo conjunto de requisitos (por ensayaron. Cada ment incre- de software se

ejemplo, un prototipo requisitos); el prueba con pruebas automatizados y
prototipo también puede servir como manuales; un incremento puede ser liberado
modelo para un futuro esfuerzo de con frecuencia, como cada dos semanas más
desarrollo de software (por ejemplo, como o menos.
en una especificación de interfaz de
usuario).
4.4. Los métodos ágiles

[3 *, c3] [6 *, c7s3p7] [7 *, c6, App.
UN]
Los métodos ágiles nacieron en la década de

1990 a partir de la necesidad de reducir la gran
sobrecarga aparente asociados con el peso
pesado, los métodos basados en planes utilizados
en los proyectos de desarrollo de software a gran
escala. Los métodos ágiles son considerados
métodos ligeros en cuanto a que se caracterizan
por ciclos cortos, iteraciones de desarrollo tiva,
equipos auto-organizados, los diseños más
simples, la refactorización de código, desarrollo
basado en pruebas, la participación de cliente
frecuente, y un énfasis en la creación de un
trabajo demostrable producto con cada ciclo de
desarrollo.
Muchos métodos ágiles están disponibles en la
literatura; algunos de los enfoques más
populares, que se discuten aquí en breve,
incluyen desarrollo rápido de aplicaciones
(RAD), eXtreme Pro- gramación (XP), Scrum, y
el desarrollo de funciones-Driven (FDD).
• RAD: métodos rápidos de desarrollo de

software se utilizan principalmente en el
desarrollo de aplicaciones sistemas de
negocios-intensivo de datos. El método
RAD está habilitado con fines especiales
herramientas de desarrollo Base de datos se
utilizan los ingenieros de software para
desarrollar rápidamente, probar e
implementar aplicaciones nuevas o
modificadas de negocio.
• XP: Este método utiliza historias o
escenarios para las necesidades, desarrolla
pruebas en primer lugar, tiene implicación
directa con el cliente en el equipo (por lo
general la definición de las pruebas de
aceptación), utiliza la programación en
parejas, y prevé continua- refactorización
código ous e integración. Historias se
descomponen en tareas, priorizado,
estimación aparearon, desarrollados, y se
software.
• MeléEste enfoque ágil gestión es más 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
más de 30 días. Se desarrolla una lista de
reserva de pedidos de productos de
artículos (PBI) a partir del cual se
identifican las tareas, definidas, prioridad,
y estima. Una versión trabajando 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
características, (3 ) construir el plan de
desarrollo de funciones, (4) el desarrollo
de diseños para funciones de iteración
específica, y
(5) de código, prueba, y luego integrar las
funciones. FDD es similar a un enfoque
incremental de desarrollo de software;
También es similar a XP, excepto que la
propiedad del código es asignado a
individuos más que el equipo. FDD hace
hincapié en un enfoque de arquitectura
global para el software, que promueve la
creación de la función correctamente la
primera vez en lugar de enfatizar
refactorización continua.
Hay muchas más variaciones de ods met

ágiles en la literatura y en la práctica. Tenga en
cuenta que siempre habrá un lugar para los
pesos pesados, métodos de ingeniería de
software basados en plan, así como los lugares
donde brillan los métodos ágiles. Hay nuevos
métodos derivados de combinaciones de los
métodos ágiles y basadas en el plan donde los
practicantes están definiendo nuevos métodos
que equilibren las características necesarias en
ambos métodos 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 elección en
el uso de método de ingeniería de software una
sobre otra o en la construcción de un nuevo
método de las mejores características de una
combinación de métodos de ingeniería de
BoEHM y Turner 2003

Brookshear 2008
1999 [4 *]
2011 [3 *]
Budgen 2003
Página-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 Expresión de c4s6p3,
c5s3
Modelos c5s0p3
1.3. Sintaxis, la
c2s2.2.2
semántica y la c5s0
P6
pragmática
1.4. Condiciones c10s4p2,
previas, c4s4 c10s5
postConditions, e p2p4
2. invariantes
Tipos de Modelos
2.1. Modelado
c7s2.2 c8s1
de información
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. Análisis de
Modelos
3.1. Para c4s1.1p7,
pp8-11
completar el c4s6
análisis
3.2. La c4s1.1p7,
pp8-11
consistencia para c4s6
analizar
3.3. El análisis de
pp8-11
la corrección
c4s7.1,
3.4. trazabilidad
c4s7.2
3.5. Interacción c29s1.1,
c10, c11 c5
Análisis c29s5
11
BoEHM y Turner 2003

Brookshear 2008
1999 [4 *]
2011 [3 *]
Budgen 2003
Página-Jones
SommervilLe
Ala 1990
[1 *]
[6 *]
[5 *]
[7 *]
*]
4. Métodos de
ingeniería de
software c2s2.2,
4.1. Los c13, c15,
c7s1,
métodos c16
c5s4.1
heurísticos
4.2. Métodos c18 c27 pp8-24
formales
4.3. prototipado
c12s2 c2s3.1 c7s3p5
métodos
c6, app.
4.4. Los métodos c3 c7s3p7
UN
ágiles
Referencias
[1 *] D. Budgen, Diseño de software, 2ª ed., [5 *] JM Wing, “Introducción de un
Addison-Wesley, 2003. especificador de métodos formales,”
Computer, vol. 23, no. 9, 1990, pp. 8, 10-23.
[2 *] SJ Mellor y MJ Balcer, ejecutable UML:.
Una Fundación para el Model-Driven [6 *] JG Brookshear, Ciencias de la
Architecture, 1st ed, Addison-Wesley, Computación:. Una visión general, 10ª ed,
2002. Addison-Wesley, 2008.
[3 *] I. Sommerville, Ingeniería de Software, 9ª [7 *] B. Boehm y R. Turner, Equilibrio de la

ed., Addison-Wesley, 2011. agilidad y disciplina: una guía para los
perplejos, Addison-Wesley, 2003.
[4 *] M. Página-Jones, Fundamentos del Diseño
orientado a objetos en UML, 1st ed.,
13
CAPÍTULO 10 CALIDAD
DEL SOFTWARE
SIGLAS calidad “, donde el‘cliente es el árbitro final’[3 *,

P8].
Capability Maturity Model Más 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 implícitas, 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 Análisis de
embargo, la calidad depende del grado en que
TLC Efectos
Análisis 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 función 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 característica).
SQC Control de Calidad de Software Significativamente, sin embargo, estas
definiciones hacen hincapié en que la calidad
SQM Gestión de la calidad del software
depende de los requisitos.
TQM Total Quality Management Estas definiciones se ilustran también otra
V&V Verificación y validación razón de la prevalencia de la calidad del software
largo de esta guía: una ambigüedad frecuente de
la calidad del software frente a los requisitos de
INTRODUCCIÓN calidad de software ( “los -ilities” es una
abreviatura común). los requisitos de calidad de
¿Cuál es la calidad del software, y por qué es tan software son en realidad los atributos de (o
importante que se incluye en muchas áreas de limitaciones) sobre los requisitos funcionales (lo
conocimiento (KAS) de la guía SWEBOK? que hace el sistema). Requisitos de software
Una de las razones es que la calidad del también pueden especificar el uso de recursos,
software término está sobrecargado. La calidad un protocolo de comunicación, o muchas otras
del software puede referirse: a deseable características. Esta KA intenta claridad
características capaces de productos de software, mediante el uso de la calidad del software en el
en la medida en que un determinado posi- sentido más amplio de las definiciones anteriores
producto de software sess esas características, y y mediante el uso de los requisitos de calidad de
para procesos, herramientas y técnicas utilizadas software como con- straints sobre los requisitos
para lograr esas características. Con los años, los funcionales. La calidad del software se logra
autores y organizaciones han definido el término 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 característico manera especificada o cómo se
Humphrey refiere a él como “lograr excelentes agrupan o se nombra requisitos.
niveles de‘aptitud para el uso’[2]. Entre tanto, La calidad del software también se considera
IBM acuñó la frase “impulsada por el mercado en muchos de los SWEBOK KAs porque es un
eter param básica de un esfuerzo de ingeniería
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
máximo de las partes interesadas, mientras que caracteriza como “aptitud para
10-1
Figura 10.1. Desglose de los temas de la calidad del software KA
utilizar.”valor de los grupos de interés se ingenieros de software que requieren

expresa en los requisitos. Para productos de
software, los interesados podrían 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 visión general de las prácticas, herramientas
y técnicas para la definición 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.

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 interés y la
comunicación 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 calidad, las características, valores
y su aplicación 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 métodos de
medición y los criterios de acep- tación para
evaluar el grado en que el software y la
documentación relacionada a alcanzar los
niveles de calidad deseados.
1.1. Software de Ingeniería 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 ingeniería de software saludable incluye
muchas características, incluyendo el
entendimiento de que los equilibrios entre
costes, plazos y calidad son un principio básico
de la ingeniería de cualquier producto. Una
ética fuerte de ingeniería de software asume
que los ingenieros informan con precisión la software producto al cliente. costos ure Fail
información, condiciones, y los resultados externos incluyen actividades para responder a
relacionados con la calidad. problemas de software descubiertas después de
La ética también 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 métodos 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 también deben ser capaces de presentar
código de ética y la práctica profesional (ver alternativas de calidad y sus costos para que las
Códigos de Ética y Conducta Profesional de la compensaciones entre costo, horario, y la
Ingeniería de Software KA Práctica entrega de valor para los accionistas
Profesional). Puede ser hecho.
1.2. Valor y los costos de 1.3. Modelos y características de calidad

Calidad [7 *, c17, [3 *, c24s1] [7 *, c2s4] [8 *,
c22] c17]
Definir y luego la consecución de la calidad del de software, pruebas de nivel de sistema, pruebas
software no es simple. Las características de de aceptación); los costos de evaluación se
calidad pueden o pueden no ser necesarios, o se extenderían 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 evaluación y descubrió
software, es decir, el logro de valor para los antes de la entrega de la
accionistas, esta sección presenta coste de la
calidad del software (cosq): un conjunto de
medidas derivadas de la evaluación económica
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- terísticas 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
implícitas” o Hay cuatro categorías de calidad
coste de “estable- ció requisitos.”: prevención,
evaluación, fallo interno y externo fracaso.
Prevención costos incluyen las inversiones en
los esfuerzos de mejora de procesos de software,
infraestructura de calidad, herramientas de
calidad, formación, auditorías y revisiones Ment
manage-. Estos costos son por lo general no es
específico de un proyecto; que abarcan la
organización. surgen los costos de evaluación de
las actividades del proyecto que encuentran
defectos. Estas actividades de evaluación se
pueden clasificar en los costos de los exámenes
(diseño, pares) y los costos de las pruebas
(pruebas software de la unidad, de integración
Terminología para características de calidad de 5
software difiere de una taxonomía (o modelo
de la calidad del software) a otro, cada modelo
tal vez tener un número diferente de niveles
jerárquicos y un número total diferente de
características. Varios autores han producido
modelos de características de calidad de
software o atributos que pueden ser útiles para
la discusión, la planificación, y la calificación
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. Apéndice B de la Guía
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
gestión de la calidad del software y la calidad

de los procesos niería de software niería tienen
una influencia directa en la calidad del
producto de software.
Modelos y criterios que evalúan los lazos
capabili- de organizaciones de software son
principalmente proyecto organización y
consideraciones de gestión y, como tales, están
cubiertos en el Proceso de Gestión de
Ingeniería de Software e Ingeniería 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 determinación de si un proceso
tiene la capacidad de productos Duce
consistentemente pro de la calidad deseada no
es simple.
El proceso de ingeniería de software,
discutido en el proceso de ingeniería de
software KA, las influencias de las
características de calidad de software pro-
ductos, que a su vez afectan a la calidad
percibida por los interesados.
1.3.2. Calidad del producto de software fallos / defecto, la eliminación, y pre- vención, y
(3) el proceso de mejora de la calidad.
El ingeniero de software, en primer lugar, debe La teoría y los conceptos detrás de la mejora de
determinar el verdadero propósito del software. la calidad, tales como la construcción de la
En este sentido, requisitos de los interesados son calidad a través de la detección temprana y la
de suma importancia, y que incluyen los prevención de defectos, la mejora continua de las
requisitos de calidad, además de los requisitos partes interesadas, y enfoque son pertinentes para
funcionales. Por lo tanto, los ingenieros de la ingeniería 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 explícita
al principio y al Deben conocerse su
importancia, así como el nivel de dificultad en
el logro de ellos. Todos los procesos de
desarrollo de software (por ejemplo, la
obtención de requisitos, diseño, construcción,
construcción, control, mejora de la calidad)
están diseñados 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 desarrollo
adicionales ayudan a asegurar que la calidad
obtenida puede canjearse por los beneficios
anticipados.
El término 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 especificación de
sistema / subsistema, una especificación de
requisitos de software para un componente de
software de un sistema, una descripción de
diseño de software, código fuente, prueba de
software documen- tación, o informes. Aunque
se describen algunos tratamientos de calidad en
términos de rendimiento del software y el
sistema final, buenas prácticas de ingeniería
requiere que se evalúen productos de trabajo
intermedios correspondientes a la calidad
durante todo el proceso de ingeniería 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 través de procesos preventivas o un
proceso iterativo tiva de la mejora continua, que
requiere control de la gestión, coordinación, y la
retroalimentación de muchos procesos
concurrentes: (1) los procesos del ciclo de vida
del software, (2) el proceso de detección de
en la calidad que han declarado que la calidad para desarrollar software críticoCalidad 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 ingeniería 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 función de calidad (QFD)
ofrecen técnicas para especificar los objetivos
de calidad y determinar si se cumplen. El ideal
del Instituto de Ingeniería de Software es otro
método [7 *]. gestión de calidad ahora es
reconocido por la Guía SWE- BOK como una
disciplina importante.
patrocinio de gestión de procesos y
productos apoya las evaluaciones y las
conclusiones resultantes. A continuación, un
programa de mejora se desarrolla la
identificación de acciones detalladas y
proyectos de mejora que deben abordarse en un
plazo de tiempo posible. apoyo a la gestión
implica que cada proyecto mejoría tiene
suficientes recursos para lograr el objetivo
definido para ello. patrocinio de gestión se
solicita con frecuencia mediante la
implementación de actividades de
comunicación proactivas.
1.5. software de Seguridad

[9 *,
c11s3]
sistemas de seguridad críticos son aquellos en

los que un fallo de sistema podría dañar la
vida humana, los demás seres vivos, las
estructuras físicas, o el medio ambiente. El
software en estos sistemas es crítico para la
seguridad. Hay un número creciente de
aplicaciones de software crítico en un número
creciente de industrias. Ejemplos de sistemas
con software crítico seguridad- incluyen
sistemas de transporte masivo, plantas de
fabricación de productos químicos, y
dispositivos médicos. El fracaso de software en
estos sistemas podría tener efectos
catastróficos. Existen normas industria, como
DO-178C [11], y emerg- procesos ing,
herramientas y técnicas para el Desa- software
safetycritical ing. La intención de estas normas,
instrumentos y técnicas es reducir el riesgo de
defectos de inyección en el software y por lo
tanto mejorar la fiabilidad del software.
software crítico puede ser categorizado como
directo o indirecto. Directa es que el software
embed- ded en un sistema crítico para la
seguridad, como por ejemplo el ordenador de
control de vuelo de una aeronave. Indirecta
incluye aplicaciones de software utilizadas
Tres técnicas complementarias para reducción utilizados. dades SQA activi- definir y evaluar la
ing el riesgo de fallo son la evitación, detección adecuación de los procesos de software para
y eliminación, y la limitación del daño. Estos proporcionar evidencia que establezca la
software técnicas 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- técnicas artefactos específicos del proyecto (documentos
ANCE y control tales como las inspecciones. y ejecutables) para determinar si
Los niveles más altos de riesgo pueden requerir
una revisión más detallada de los requisitos, el
diseño y el código o el uso de técnicas analíticas
más formales. Otra técnica para la gestión de
riesgos y control- software Ling es la
construcción de casos de aseguramiento. Un
caso de aseguramiento es un artefacto razonada,
auditable creado para apoyar la afirmación de
que su demanda o demandas son satisfechas.
Contiene las siguientes acciones y sus
relaciones: una o más afirmaciones sobre
propiedades; argumentos que enlazan
lógicamente parte, las pruebas y las posibles
hipótesis a las reclamaciones; y un conjunto de
pruebas y los supuestos que apoyan estos
argumentos [12].
2. Procesos de software de gestión de calidad
gestión de la calidad del software es el conjunto

de todos los procesos que garanticen que los
productos de software, servicios y la
implementación de procesos de ciclo de vida
cumplen los objetivos de calidad de software de
organización y lograr la satisfacción de las
partes interesadas [13, 14]. SQM define los
procesos, los dueños del proceso, los requisitos
para los procesos, mediciones de los procesos y
sus salidas y retroalimentación Nels Chan
durante todo el ciclo de vida del software.
SQM comprende cuatro subcategorías:
software de planificación 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
planificación de la calidad del software incluye
la determinación de cuáles estándares de calidad
se van a utilizar, la definición de objetivos de
calidad específicos, y estimar el esfuerzo y el
calendario de actividades de calidad de software.
En algunos casos, la planificación de la calidad
del software también incluye la definición de los
procesos de calidad de software para ser
la función SQA con respecto Calidad de Software La
al proyecto. 10-
cumplir con las normas establecidas para el 9
proyecto (incluyendo los requisitos, función SQA también puede ser
limitaciones, diseños, contratos y planes). SQC organizativamente independiente de la proyec-
evalúa intermedio productos, así como los ect; es decir, libre de técnica, de gestión y
productos finales.
La cuarta categoría SQM se trata de la
mejora tiene varios nombres en el software
industria, incluyendo SPI, la mejora de la
calidad del software y el software de acciones
correctivas y preventivas. Las actividades en
esta categoría buscan mejorar la eficacia del
proceso, la eficiencia, y otras carac- terísticas
con el objetivo último de mejorar la calidad del
software. Aunque SPI podría incluirse en
cualquiera de las tres primeras categorías, un
número creciente de organizaciones de
organizar SPI en una cate- goría separada que
puede extenderse a través de muchos proyectos
(ver el Proceso de Ingeniería de Software KA).
los procesos de calidad de software consisten
en tareas y técnicas para indicar cómo se están
implementando planes de software (por
ejemplo, gestión de software, desarrollo,
gestión de la calidad, o los planes de gestión de
configuración) y qué tan bien los productos
intermedios y finales están cumpliendo con sus
requisitos especificados. Los resultados de
estas tareas se montan en los informes de
gestión antes de que se tomen medidas
correctivas. La gestión de un proceso de SQM
tiene la tarea de garantizar que los resultados
de estos informes son exactos.
La gestión del riesgo también puede jugar un
papel importante en la entrega de software de
calidad. La incorporación de análisis de riesgos
y la gestión gías nicas disciplinados en los
procesos del ciclo de vida del software puede
ayudar a mejorar la calidad del producto (véase
la Ingeniería de Software de Gestión de KA
para material relacionado en la gestión de
riesgos).
2.1. Calidad de Software

[7 *, C4-C6, c11, c12, c26-
27]
Para sofocar un malentendido generalizado,

chorro suave de garantía de calidad cerámica
no está probando. aseguramiento de la calidad
del software (SQA) es un conjunto de
actividades que definen y evaluar la
adecuación 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
las presiones financieras del proyecto [5]. SQA

tiene dos aspectos: de garantía de producto y de El propósito de V & V es ayudar a la
garantía de proceso, que se explican en la calidad de construcción organización desa-
sección 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 evaluación 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 específico 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 están claramente definidos y entendidos.
actividades y tareas de calidad del plan SQA
se especifican con sus costos, necesidades de
recursos, objetivos y calendario en relación con
los objetivos relacionados con la ingeniería de
software Ment manage-, desarrollo de software,
software y planes de man- tenance. El plan SQA
debe ser consistentes con el plan de gestión de
configuración de software (ver el software de
configuración Manage- ment KA). El plan SQA
identifica documentos, normas, prácticas y
convenciones que rigen el proyecto y cómo estos
artículos son revisados y monitoreados para
asegurar la adecuación y cumplimiento. El plan
SQA también medidas; técnicas estadísticas; los
procedimientos para la presentación de informes
de problemas y acciones correctivas; recursos
tales como herramientas, técnicas y
metodologías; la seguridad de los medios
físicos; formación; y SQA informes y docu-
mentación. 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 adquisición de software de
proveedores para el proyecto, el software off-
the-shelf comercial (COTS) de instalación, y
servicio después de la entrega de El software.
También puede contener la aceptación criteria,
así como la presentación de informes y la
gestión de activi- lazos que son críticos para la
calidad del software.
2.2. Verificación validación

[9 *, c2s2.3, c8, c15s1.1,
c21s3.3]
Como se indica en [15],

garantía de producto y auditorías Calidad de Software
de 10-
ciclo vital. Esta evaluación demuestra si 11
los requisitos son correctos, completa, aseguramiento de proceso son normalmente
precisa, coherente y comprobable. Los llevadas a cabo por la garantía 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 verificación 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 especificaciones
que se les imponen en las actividades
anteriores. La validación es un intento de
asegurar que el producto adecuado está
construido, es decir, el producto cumple con su
finalidad específica. Tanto el proceso de
verificación y validación del proceso
comienzan temprano en la fase de desarrollo o
mantenimiento. Proporcionan un examen de las
características clave del producto en relación
tanto con predecesora inmediata del producto y
las especificaciones que deben cumplirse.
El propósito de la planificación 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 técnicas y
herramientas que se utilizarán. La comprensión
de los diferentes efectos de cada actividad V y
V ayuda en la planificación cuidadosa de las
técnicas y los recursos necesarios para el
cumplimiento de sus fines. El plan también se
ocupa de la ment manage-, la comunicación,
las políticas y procedimientos de las
actividades de V & V y su interacción, así
como los requisitos de información y
documentación defecto.
2.3. Revisiones y auditorías

[9 *, c24s3] [16
*]
Los comentarios y los procesos de auditoría se

definen ampliamente como la electricidad
estática sentido de que no hay programas o
modelos de software son artefactos de
ingeniería de software ejecutados examen, con
respecto a las normas que han sido establecidas
por la organización o proyecto para esos
artefactos. Los diferentes tipos de revisiones y
auditorías se distinguen por su finalidad, nive-
les de la Independencia, herramientas y
técnicas, roles, y por el tema de la actividad. la
equipos. revisiones por la dirección están a incluir informes de auditoría, informes, V & V
cargo de la gestión de la organización o informes y planes de muchos tipos, incluyendo la
proyecto. El personal de inge- niería lleva a cabo gestión de riesgos, gestión de proyectos, gestión
revisiones técnicas. de configuración de software, la seguridad de
software, y Assessment riesgo, entre otros
• revisiones por la dirección evalúan proyecto progresar. (Consulte el software de gestión de
real Inge- niería y el software de configu- ración de
resultados con respecto a los planes. Gestión KAs para el material relacionado).
• Revisiones técnicas (incluidas las
inspecciones, paso a paso, y la
comprobación de escritorio) examinar
productos de trabajo de ingeniería.
• auditorías 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].
• auditorías de garantía de producto.
actividades de garantía de producto SQA se
aseguran para proporcionar evidencia de
que los productos de software y la
documentación 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 gestión
Como se indica en [16 *],
El propósito de una revisión por la

dirección es monitorear el progreso,
determinar el estado de los planes y
programas, y evaluar la eficacia de los
procesos de gestión, herramientas y
técnicas. revisiones por la dirección
compárense resultados efectivos contra
los planes para determinar el estado de los
proyectos o esfuerzos de mantenimiento.
Los principales parámetros de revisión-
hombre agement son los costos del
proyecto, el calendario, el alcance y la
calidad. revisiones por la dirección
evalúan las decisiones sobre las acciones
correctivas, cambios en la asignación de
los recursos, o cambios en el alcance del
proyecto.
Las entradas a exámenes de gestión pueden

2.3.2. Técnico Comentarios adhesión a la codificación Calidad
de lasdenormas,
Software 10-
la
13
estructura y
El propósito de una revisión técnica 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 administración evidencia
para confirmar el estado técnico del
proyecto.
Aunque cualquier producto de trabajo puede

ser revisada, revisiones técnicas se realizan en
los principales productos de trabajo de
ingeniería de software de los requisitos de
software y diseño de software.
Propósito, funciones, actividades, y lo más
importante es el nivel de formalidad distinguen
diferentes tipos de exámenes técnicos. Las
inspecciones son los más formales, Tutoriales
menos, y las revisiones de pares o controles
documentales son los menos formal.
Ejemplos de roles específicos incluyen un
tomador de decisiones (es decir, el plomo de
software), un líder de opinión, una grabadora, y
damas (miembros del personal técnico que
examinan los productos de trabajo). Las
revisiones también se distinguen por si las
reuniones (cara a cara o electrónico) están
incluidos en el proceso. En algunos métodos de
revisión de damas solitario exami- productos
de trabajo ine y enviar sus resultados a un
coordinador. En otros métodos de damas
trabajan cooperativamente en las reuniones.
Una revisión técnica puede requerir que las
aportaciones obligatorias estar en su lugar a fin
de proceder:
• Declaración de objetivos
• producto de software específico
• plan específico de gestión de proyectos
• lista de temas relacionados con este
producto
• procedimiento de revisión técnica.
El equipo sigue el procedi- opinión pro-

documentado. La revisión técnica se completa
una vez que todas las actividades enumeradas
en el examen se han completado.
Revisiones técnicas de código fuente pueden
incluir una amplia variedad de problemas tales
como el análisis de algoritmos de, la utilización
de los recursos críticos de ordenador, la
organización de código para la capacidad de grabadora, un lector, y algunos (de dos a cinco)
prueba, y Seguridad- Damas (inspectores). Los miembros de un equipo
consideraciones críticas. de inspec- ción pueden poseer diferentes
Tenga en cuenta que las revisiones técnicas de conocimientos, tales como experiencia en el
los modelos de código fuente o el diseño tales campo, experiencia en métodos de diseño de
como UML también se denominan análisis software, o la experiencia lenguaje de
estático (véase el tema 3, Consideraciones programación. las inspecciones se realizan
prácticas). normalmente en un relativamente
2.3.3. inspecciones
“El propósito de la inspección es detectar e

identificar anomalías de productos de software”
[16 *]. Algunos diferenciadores importantes de
las inspecciones en comparación con otros tipos
de revisiones técnicas 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 organización.
Conjuntos de reglas pueden ser definidos
para diferentes tipos de workproducts (por
ejemplo, reglas para los requerimientos, las
descripciones de la arquitectura, el código
fuente).
2. Muestreo. Más bien que intento de
examinar cada palabra y figura en un
documento, el proceso de inspección
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 gestión sobre los miembros
del grupo de inspección no participan en la
inspección. Esta es una distinción clave
entre revisión y revisión por la dirección.
4. LED. Un mediador imparcial que está
entrenado en técnicas de inspección
conduce reuniones de inspección.
5. Reunión. El proceso de inspección incluye
reuniones (cara a cara o electrónico) con-
canalizado por un moderador de acuerdo
con un procedimiento formal en el que los
equipos de inspección miembros informan
las anomalías 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
también incluyen un líder de inspección, una
pequeña sección del producto a la vez 15
(muestras). Cada miembro del equipo examina
el producto de software y otros insumos de
revisión antes de la reunión de revisión, tal vez
mediante la aplicación de una téc- nica
analítica (ver sección 3.3.3) a una pequeña
sección del producto o de la totalidad del
producto con un enfoque en sólo un aspecto-
por ejemplo, interfaces. Durante la inspección,
el moderador lleva a cabo la sesión y verifica
que todo el mundo ha preparado para la
inspección y lleva a cabo la sesión. Las
inspecciones grabadora ción documentos
anomalías encontradas. Un conjunto de reglas,
con criterios y preguntas pertinentes a los
temas de interés, es una herramienta común
utilizada en las inspecciones. La lista resultante
a menudo clasifica las anomalías (ver sección
3.2, defecto caracterización ción) y es revisada
para su integridad y picante Accu por el
equipo. La decisión de salida de inspección
corresponde a una de las siguientes opciones:
1. Encaja con ninguna o, a lo sumo,

reelaboración de menor importancia
2. Aceptar con la verificación de retrabajo
3. Volver a inspeccionar.
2.3.4. Tutoriales
El propósito de un recorrido sistemática

es evaluar un producto de software. A
través de pie- puede llevarse a cabo con
el propósito de educar a una audiencia
con respecto a un producto software.
Tutoriales se distinguen de las inspecciones.

La diferencia principal es que los Ents autor
Las presiones para el trabajo de productos a los
demás participantes en una reunión (cara a cara
o electrónico). A diferencia de una inspección,
los participantes de la reunión pueden no haber
visto necesariamente el material antes de la
reunión. 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 retroalimentación. Al
igual que las inspecciones, tutoriales puede
llevarse a cabo en cualquier tipo de trabajo-
producto, incluyendo plan de proyecto,
requisitos, diseño, código fuente, y los
informes de las pruebas.
2.3.5. Proceso de aseguramiento y funcional (lo que hace el sistema) y calidad

Aseguramiento de auditorías • los componentes comerciales (externos) o
estándar (inter- nal) para ser utilizados en el
Como se indica en [16 *], sistema de
El propósito de una auditoría de software

consiste en proporcionar una evaluación
independiente de la con- Formance de
productos de software y pro cesos a los
reglamentos aplicables, normas,
directrices, planes y procedimientos.
Proceso auditorías de aseguramiento de

determinar la idoneidad de los planes, los
programas y los requisitos para lograr los
objetivos del proyecto [5]. La auditoría 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 organización auditada.
Auditorías 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 auditorías, tales como los
identificados en el estándar [16 *], el punto
importante es que pueden ocurrir en casi
cualquier producto en cualquier etapa del
proceso de desarrollo o mantenimiento.
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

planificación, gestión y selección de actividades
SQM y técnicas, incluyendo
• el dominio del sistema en el que reside el

software; las funciones del sistema podría
ser crítico para la seguridad, de misión
crítica, negocio-crítica, la seguridad críticos
• el entorno físico en el que reside el sistema
de software
• (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 específicas de ingeniería de 17
software complejidad del software, la criticidad,
aplicable riesgo, nivel de seguridad, nivel de
• los métodos y herramientas de software seguridad,
para ser utilizados para el desarrollo y
mantenimiento y para la evaluación y
mejora de calidad
• el presupuesto, el personal, la organización
del proyecto, planes, y la programación de
todos los procesos
• los usuarios previstos y el uso del sistema
• el nivel de integridad del sistema.
La información sobre estos factores influye

en cómo se organizan y documentada, la forma
específica se seleccionan las actividades de
SQM, qué recursos son necesarios, y cuáles de
esos recursos imponen límites 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
más allá de la funcionalidad básica. Este es el
caso por las siguientes razones: las fallas del
sistema afectan a un gran número 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 pérdida de información. Sistema y
fiabilidad software incluyen características
tales como la disponibilidad, fiabilidad,
seguridad, y la seguridad. Cuando en desarrollo
de software fiable, herramientas y técnicas se
pueden aplicar para reducir el riesgo de
inyección de fallos en los entregables
intermedios o el producto de software final.
Verificación, validación ción, y pruebas de
procesos, técnicas, métodos 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
Definición de los niveles de integridad es un

método de riesgo
administración.
los niveles de integridad de software son

rendimiento deseado, fiabilidad, u otras lenguas evolucionan, junto con los avances en el
características únicas en proyectos que software en general tecnolo- gías, 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
características utilizadas para determinar definidas anteriormente. Cuando el seguimiento
el nivel de integridad puede variar de defectos, el ingeniero de software está
dependiendo de la aplicación prevista y el interesado no sólo en el número de defectos, sino
uso del sistema. El software es una parte también los tipos. Información por sí sola, sin un
del sistema, y su nivel de integridad se ha poco de clasificación, 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. Diseño, codificación
procesal, y la tecnología de características
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 determinación 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
verificación y validación adicionales a los
componentes de alta integridad.”
3.2. Caracterización de defectos

[3 *, c3s3, c8s8,
c10s2]
Software de evaluación de la calidad (es decir, el

control de calidad de software) Técnicas de
encontrar defectos, fallas y fracasos. La
caracterización de estas técnicas conduce a una
comprensión del producto, facilita las
correcciones en el proceso o el producto, e
informa a la gestión y otras partes interesadas de
la tus esta- del proceso o producto. Existen
muchas taxonomías y, si bien se han hecho
intentos de obtener el consenso, la literatura
indica que hay un buen número en uso.
Caracterización defecto también se utiliza en
auditorías y revisiones, con el líder de opinión a
menudo se presenta una lista de problemas
proporcionados por los miembros del equipo
para su examen en una reunión de revisión.
A medida que nuevos métodos de diseño y las
Los tipos específicos 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 taxonomía probabilidad de fallos futuros y para ayudar en
de defectos que sea significativo para la las decisiones sobre cuándo detener la prueba.
organiza- ción y para los ingenieros de Una probable acción 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- mación en todas las etapas de errores, crear nueva construcción). Otras
desarrollo de software y mantenimiento. En actividades intentan eliminar
algunos casos, la palabra defecto está
sobrecargado para referirse a diferentes tipos
de anomalías. Sin embargo, diferentes cultivos
de ingeniería y Standards pueden utilizar algo
diferentes significados para estos términos. La
variedad de términos solicita esta sec- ción
para proporcionar un conjunto ampliamente
utilizado de las definiciones [19]:
• Error de cálculo: “La diferencia entre un

valor calculado, observado o medido o
condición y el verdadero, especificado, o
el valor o condición teóricamente
correcto”
• Error: “Una acción humana que produce
un resultado incorrecto.” Un resbalón o un
error que hace que persona. También
llamado error humano.
• Defecto: Un “imperfección 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 código fuente. Un
“paso, proceso o definición incorrecta de
datos en el programa de ordenador”. La
codificación de un error humano en el
código fuente. Culpa es el nombre formal
de un error.
• Fracaso: Un “evento en el cual un sistema
o componente de sistema no realiza una
función requerida dentro de los límites
especificados.” Un fallo se produce
cuando una falla se encuentra por el
procesador en condiciones especificadas.
Usando estas definiciones tres mediciones de

calidad de software ampliamente utilizados
son la densidad de defectos (número de
defectos por unidad de tamaño de documentos),
la densidad de fallo (número de fallos por 1K
líneas de código), 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
11
las causas de los defectos, por ejemplo, análisis Se utilizan sobre todo para verificar los requisitos
de la causa raíz (RCA). RCA actividades de software y diseños. En su mayoría se han
incluyen analizar y resumir los resultados para utilizado en la veri ficación de partes cruciales de
encontrar las causas de raíz y el uso de técnicas los sistemas críticos, como los requisitos de
de medición para mejorar el producto y el seguridad y protección específicas. (Ver
proceso, así como para realizar un seguimiento
de los defectos y su eliminación. La mejora de
procesos se discute principalmente en el proceso
de software Engineer- ing KA, con el proceso de
SQM ser una fuente de información.
Los datos sobre las insuficiencias y defectos
encontrados por las técnicas de control de
calidad de software se pueden perder a menos
que se graban. Para algunas técnicas (por
ejemplo, revisiones técnicas, auditorías,
inspecciones), grabadoras están presentes para
establecer ción tales informa-, junto con las
cuestiones y decisiones. Cuando se utilizan
herramientas automatiza apareadas (ver tema 4,
Software calidad Herramientas), la salida de la
herramienta puede proporcionar la información
de defectos. Los informes sobre defectos se
proporcionan a la gestión de la organización.
3.3. Técnicas de gestión de calidad de software

[7 *, c7s3] [8 *, c17] [9 *, c12s5, c15s1, P417]
[dieciséis*]
técnicas de control de calidad de software se

pueden cat- egorized de muchas maneras, pero
un enfoque sencillo utiliza sólo dos categorías:
estáticas y dinámicas. técnicas dinámicas
implican la ejecución del software; técnicas
estáticas implican documentos de análisis y el
código fuente, pero no ejecutar el software.
3.3.1. Técnicas estáticas
técnicas estáticas examinan software de

documentación ción (incluidos los requisitos de
interfaz, ciones especificación, diseños y
modelos) y el código fuente del software sin
ejecutar el código. Hay muchas herramientas y
técnicas para el examen de forma estática
productos de trabajo software (véase la sección
2.3.2). En adi- ción, herramientas que analizan
fuente de flujo de control de código y la
búsqueda de código muerto se considera que son
herramientas de análisis estático, ya que no
implican la ejecución del código de software.
Otros, más formales, los tipos de técnicas de
análisis son conocidos como métodos formales.
También Métodos formales en la Engineer-
Software ing modelos y métodos KA).
3.3.2. Las técnicas dinámicas
técnicas dinámicas implican la ejecución del

código de software. Diferentes tipos de
técnicas dinámicas se realizan durante todo el
desarrollo y mantenimiento de software.
técnicas Generalmente, estos son pruebas, pero
técnicas tales como La simulación y análisis
del modelo pueden considerarse dinámica (ver
los modelos ingeniería de software y Métodos
KA). La lectura de códigos se considera una
técnica estática, pero el software de inge-
nieros pueden ejecutar el código a medida que
leen a través de él experimentó. La lectura de
códigos puede utilizar técnicas dinámicas. Esta
discrepancia en la categorización indica que las
personas con diferentes roles y experiencia en
la organización pueden considerar y aplicar
estas técnicas de forma diferente.
Diferentes grupos pueden realizar pruebas
durante el desarrollo de software, incluidos los
grupos independiente 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 materiales utilizados en el proyecto:
• Evaluación y pruebas de herramientas que

se utilizarán en el proyecto
• pruebas de conformidad (o revisión 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 organización 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í: adecuación de los
planes, procesos y procedimientos, y la
adecuación y la precisión 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
algún organismo de la autoridad. Su propósito
es poner a prueba un producto para la
conformidad con un conjunto específico de
requisitos (véase la Prueba KA Software).
13
3.4. Medición de la Calidad de Software • análisis de tendencia (por ejemplo, gráficos

[3 *, c4] [8 *, c17] [9 *, de control; ver La caja de herramientas de
p90] calidad en la lista de lecturas adicionales)
• la predicción (por ejemplo, modelos de
mediciones de calidad de software se utilizan fiabilidad).
para apoyar la toma de decisiones. Con la
creciente sofisticación de software, las técnicas basadas en la estadística descriptiva y
cuestiones de calidad van más allá de si es o no pruebas a menudo proporcionan una instantánea
el software funciona a lo bien que logra los de la más
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 gestión sobre el
esfuerzo, costo y cronograma; determinar
cuándo parar de Exámenes y liberar un producto
(ver terminación en la sección 5.1, las
consideraciones prácticas, 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 decisión de
cómo se deben organizar un proyecto o un grupo
de desarrollo y mantenimiento de las mercancías
blandas. A menudo, se utilizan modelos
genéricos de costo, que se basan en cuando se
encuentra un defecto y la cantidad de esfuerzo
que se necesita para corregir el defecto relación
tivo a encontrar el defecto más temprano en el
proceso de desarrollo. los datos de medición de
la calidad de software recopilados internamente
pueden dar una mejor idea de costo dentro de
este proyecto u organización.
Mientras que los datos de medición de la
calidad del software puede ser útil en sí mismo
(por ejemplo, el número de requisitos
defectuosos o la proporción de los requisitos
defectuosos), las técnicas matemáticas y gráficas
se pueden aplicar para ayudar en la
interpretación de las medidas (véase la
Ingeniería fundamentos KA). Estas técnicas
incluyen
• estadística descriptiva base (por ejemplo,

análisis de Pareto, diagramas de
funcionamiento, diagramas de dispersión,
distribución normal)
• pruebas estadísticas (por ejemplo, la prueba
binomial, chi-
squared test)
10-14 Guía SWEBOK® V3.0 semántico sin ejecutar el código, y presentar los
áreas problemáticas del producto de software
bajo examen. Las tablas y gráficos resultantes resultados a los usuarios. Hay una gran variedad
son ayudas de visualización, que la decisión en la profundidad, THOR oughness, y el alcance
MAK- ERS puede utilizar para enfocar los de herramientas de análisis estático que
recursos y llevar a cabo mejoras pro Cess en el
que parecen estar más se necesita. Los
resultados de análisis 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 más probable que
ocurra a menos que se tome alguna acción
correctiva en el desarrollo. Las técnicas de
predicción facilitar la estimación de esfuerzo
de pruebas y el horario y en la predicción de
fallos. Más discusión sobre la medición en
general aparece en el Proceso de Ingeniería de
Software Ingeniería de Software y Gestión de
Kas. información más específica sobre la
medición de la prueba se presenta en la Prueba
de Software KA.
Software de medición de la calidad incluye
medi- suring ocurrencias de defectos y la
aplicación de métodos estadísticos para
comprender los tipos de defectos que se
producen con mayor frecuencia. Esta
información puede ser utilizada por la mejora
de procesos de software para los métodos de
minería determinantes para prevenir, reducir, o
eliminar su recurrencia. También ayudan en la
comprensión de las tendencias, lo bien que la
detección y contención técni- cas están
trabajando, y qué tan bien los procesos, crear y
mantener desarrollos están progresando. A
partir de estos métodos de medición, los
perfiles de defectos se pueden desarrollar para
un dominio apli- cación específica. Entonces,
para el siguiente proyecto de software dentro
de esa organización, los perfiles se pueden
utilizar para guiar los procesos que SQM es,
hacer el esfuerzo donde los problemas son más
probable que ocurra. Del mismo modo, puntos
de referencia, o recuentos de defectos típicos
de ese dominio, pueden servir como una ayuda
en la determinación cuando el producto está
listo para la entrega. Discusión del sobre con
los datos de SQM para mejorar los procesos
rrollo y mantenimiento desa- aparece en la
Gestión de Ingeniería de Software y Software
Ingeniería de Procesos de Kas.
4. Herramientas de Calidad de Software
herramientas de calidad de software incluyen

herramientas de análisis estático y dinámico. El
análisis estático de código fuente de entrada de
herramientas, realizar el análisis sintáctico y
15
se puede aplicar a los artefactos incluyendo • Herramientas que apoyan el seguimiento de

modelos, además de código fuente. (Véase el los problemas más software para
trucción Software Con-, pruebas de software, y proporcionar una entrada de anomalías
manteni- Software Principal- KAs para las descu- Ered durante las pruebas de software
descripciones de las herramientas de análisis y análisis posterior, disposición y
dinámicos.) resolución. Algunas herramientas incluyen
Categorías de herramientas de análisis estático soporte para flujo de trabajo y para el
incluyen la seguimiento del estado de resolución de
siguiendo: problemas.
• Herramientas que analizan los datos
• Las herramientas que facilitan y capturados a partir de entornos de ingeniería
automatizan parcialmente las revisiones e software y entornos de prueba Ware soft-
inspecciones de documentos y código. Estas y producen pantallas visuales de datos
herramientas pueden trabajar ruta a cuantificados en forma de gráficos, tablas, y
diferencias ent participantes con el fin de tablas. Estas herramientas incluyen algu-
automatizar y controlar un proceso de veces la funcionalidad para realizar un
revisión parcial. Permiten a los usuarios análisis estadístico de los conjuntos de datos
introducir defectos encontrados durante las (por El propósito de las tendencias más
inspecciones y revisiones para su posterior exigentes y hacer extremidades anteriores
eliminación. de los contenedores). Algunas de estas
• Algunas herramientas ayudan a las herramientas proporcionan tasas de defectos
organizaciones realizar análisis de riesgo y de inyección de extracción; densidades de
para la seguridad software. Estas defecto; los rendimientos; distribución de
herramientas proporcionan, por ejemplo, inyección de defectos y con cada una de las
soporte automatizado para el análisis de fases del ciclo de vida.
modo de fallo y efectos (FMEA) y el
análisis de árbol de fallos (FTA).
2008 [16 *]
2011 [9 *]
yoAEE Std. 1028-

moscard
ónt et al.
Wiegers 2003
2006 [17
[6
Voland 2003
2004
Kan 2002
SommervilLe
[10 *]
[18 *]
2000
[3 *]
*] *]
Mugirre
Larva del
*]
[7
Galin
*]
1. Fundamentos
de Calidad de
Software
1.1. Software
de Ingeniería
c1s4 c2s3.5
de la Cultura
y Ética
1.2. valor y c17,
Costo de la c22
Calidad
1.3. modelosy
características c24s1 c2s4 c17
de calidad
1.4. Mejora de
c11
la Calidad de c1s4 c24
S2.4
Software
1.5. software
c11s3
de Seguridad
2. Procesos de
Gestión de
Calidad de
Software
2.1. Calidad C4-C6,
de Software C11,
c26-27
c2
S2.3,
2.2. Verificación c8, c15
y Validación S1.1,
c21
S3.3
2.3.
c24s3 *
Revisiones y
auditorías
17
2008 [16 *]
2011 [9 *]
yoAEE Std. 1028-

moscard
ónt et al.
Wiegers 2003
2006 [17
[6
Voland 2003
2004
Kan 2002
SommervilLe
[10 *]
[18 *]
2000
[3 *]
*]
Mugirre
Larva del
*]
*]
[7
Galin
*]
3.
Consideraciones
prácticas de la
calidad del s3.2.
software 2 c15,
3.1. Requisitos
s3.3.1
de calidad de c11s1 c12
c15,
software
s9.10
c16
c3s3,
3.2.
c8s8,
Caracterización
c10s
de defectos
2 c12s5,
3.3. SQM
c7s3 c17 c15s1 *
técnicas
, P417
3.4. Medición
de la Calidad de c4 c17 p90
Software
4.
Herramienta
s de software
de calidad
LECTURAS
N. Leveson, Safeware: Sistema de seguridad e KE Wiegers, Peer Reviews en software: Una guía
Informática [20]. práctica [23].
Este libro describe la importancia de las Este libro ofrece explicaciones claras y concisas
prácticas de seguridad de software y cómo estas de los diferentes métodos de revisión por pares
prácticas se pueden incorporar en los proyectos que se distinguen por el nivel de formalidad y
de desarrollo de software. eficacia. orientación pragmática para la
aplicación de los métodos y cómo seleccionar
T. Gilb, Principios de software de gestión de qué métodos son apropiados para determinadas
ingeniería [21]. circunstancias se proporciona.
Este es uno de los primeros libros sobre técnicas NR Tague, La Caja de Herramientas de Calidad,
de desarrollo iterativo e incremental. El Método 2ª ed., [24].
Evo define objetivos cuantificados, frecuentes
iteraciones en caja tiempo-, las mediciones de Proporciona una pragmática de cómo hacerlo
progreso hacia las metas, y la adaptación de los explicación de un amplio conjunto de métodos,
planes en base a los resultados reales. herramientas y técnicas para la resolución de
problemas de mejora de calidad. Incluye las
T. Gilb y D. Graham, Software de Inspección siete herramientas básicas de control de calidad
[22]. y muchos otros.
Este libro presenta el muestreo y medición de IEEE Std. P730-2013 Proyecto de Norma para
cal estadísticamente para las revisiones y los procesos de software de garantía de
defectos. Presenta técnicas que producen calidad [5].
resultados cuantificados para reducir los
defectos, la mejora de la productividad, la pista- Este proyecto de norma expande los procesos
ing proyectos y la creación de documentación. SQA identificados en IEEE / ISO / IEC 12207 a
2008. P730 establece normas para iniciar,
planificar, controlar y ejecutar los procesos de
garantía de calidad del software de desarrollo de
software o proyecto de mantenimiento. Se
espera que la aprobación de este proyecto de
norma en 2014.
19
Assurance-Parte 1: Conceptos y
Referencias Vocabulario, IEEE 2011.
[1] PB Crosby, la calidad es gratuito, McGraw-
Hill, 1979.
[2] W. Humphrey, Gestión del proceso de

software, Addison-Wesley, 1989.
[3 *] SH Kan, métricas y modelos en Ingeniería

Wesley, 2002.
[4] ISO / IEC 25010: 2011 Sistemas y de

Ingeniería de Software-Systems y
requisitos de calidad de software y
Evaluación (cuadrado) -Sistemas y
modelos de calidad del software, ISO / IEC
2011.
[5] IEEE P730 ™ / D8 Proyecto de Norma para

los procesos de software de garantía de
calidad, IEEE 2012.
[6 *] F. Bott et al., Cuestiones profesional en

Ingeniería de Software, 3ª ed., Taylor &
Francis, 2000.
[7 *] D. Galin, Calidad de Software: de la teoría

a la implementación, Pearson Educación,
SA, 2004.
[8 *] S. Naik y P. Tripathy, pruebas de software

y aseguramiento de la calidad: Teoría y
Práctica, Wiley-Spektrum, 2008.
[9 *] P. Clements et al, el software de

documentación: Arquitecturas. Vistas y
más allá, 2ª ed, Pearson Education, 2010..
[10 *] G. Voland, Ingeniería de Diseño,

segundo
ed., Prentice Hall, 2003.
[11] RTCA DO-178C, Consideraciones sobre el

software en sistemas de vuelo y
Certificación de Equipos, Comisión
Técnica de Radio para la Aeronáutica,
2011.
[12] IEEE Std. 15.026,1-2011 Trial-Uso

Adopción estándar de la norma ISO / IEC
TR 15026-1: 2010 Sistemas y Software
INGENIERÍA-Sistemas y de Software

como ISO / IEC
software de ingeniería en software
procesos de ciclo de vida, IEEE 2008.
[14] ISO 9000: 2005 de calidad de gestión de

sistemas Fundamentos y Vocabulario, ISO
2005.
[15] IEEE Std. 1012-2012 estándar para el

sistema y la verificación y validación
de software, IEEE 2012.
[16 *] IEEE Std. 1028-2008, software

comentarios y auditorías, IEEE 2008.
[17 *] JW Moore, La Hoja de Ruta de

Ingeniería de Software: Una guía basada
en estándares, Wiley-IEEE Computer
[18 *] KE Wiegers, requisitos de software,

segundo
ed., Microsoft Press, 2003.

[20] N. Leveson, Safeware: Sistema de

seguridad e Informática, Addison-
Wesley Professional, 1995.
[21] T. Gilb, Principios de Ingeniería de

Software de Gestión, Addison-Wesley
Professional, 1988.
[22] T. Gilb y D. Graham, Software de

inspección, Addison-Wesley
Professional, 1993.
[23] K. Wiegers, Peer Reviews en Software:

Una Guía Práctica, Addison-Wesley
Professional, 2001.
[24] NR Tague, La Caja de Herramientas de

Calidad, 2ª ed.,
ASQ Quality Press, 2010.
CAPÍTULO 11
INGENIERÍA DE SOFTWARE LA
PRÁCTICA PROFESIONAL
SIGLAS de software con las características conocidas y

fiabilidad. Este requisito exige ingenieros de
Association for Computing software que poseen un conjunto adecuado de
ACM
Maquinaria conocimientos, habilidades, capacitación y
BCS British Computer Society experiencia en la práctica profesional. El
Desarrollo de software certificada término “práctica profesional” se refiere a una
CSDA forma de realización de los servicios a fin de
Asociar
lograr los estándares o criterios determinados,
Desarrollo de software certificada
PCSD tanto en el proceso de realización de un servicio
Profesional
y el producto final RESULTEN del servicio.
Electrotécnica Internacional Estas normas y criterios pueden incluir tanto
IEC
Comisión los aspectos técnicos y no técnicos. El concepto
IEEE CS IEEE Computer Society de la práctica profesional puede ser visto como
Internacional. Federación de más aplicable dentro de aquellas profesiones que
IFIP tienen un cuerpo generalmente aceptada de
Procesamiento de la Información
conocimiento; códigos de ética y conducta
IP Propiedad intelectual
profesional con sanciones por violaciónes;
Organización Internacional para las aceptadas para los procesos de acreditación,
ISO
Normalización certificación y concesión de licencias; y las
NDA Acuerdo de Confidencialidad sociedades profesionales para proporcionar y
Organización Mundial de la administrar todos estos. La admisión a estas
OMPI sociedades profesionales a menudo se basa en
Propiedad Intelectual
una combinación prescribirse de educación y
OMC Organización de Comercio Mundial
experiencia. Un ingeniero de software mantiene
una práctica profesional mediante la realización
INTRODUCCIÓN de todo el trabajo de conformidad con las
prácticas generalmente aceptadas, las normas y
El área de conocimiento Tice ticas Profesional directrices establecidas en particular
de Ingeniería de Software (KA) tiene que ver sucesivamente por la sociedad profesional
con los conocimientos, habilidades y actitudes aplicable. Por ejemplo, la Association for
que los ingenieros de software deben poseer para Computing Machinery (ACM) y la Sociedad
practicar software de inge- niería de manera cal IEEE Com- puter (IEEE CS) han establecido un
profesional, responsable, y ethi-. Debido a las Código Ingeniería Cesión de Software de Ética y
aplicaciones generalizadas de los productos de Práctica Profesional. Tanto la British Computer
software en la vida social y personal, la calidad Society (BCS) y la Federación Internacional
de los productos de software puede tener un para el Tratamiento de la Información (IFIP) han
profundo impacto en nuestro bienestar personal establecido normas de la práctica profesional
y la armonía social. Los ingenieros de software similares. ISO / IEC e IEEE han proporcionado
deben manejar los problemas de ingeniería aún más los estándares de ingeniería de software
únicas, produciendo internacionalmente aceptadas (véase el Apéndice
B de esta Guía). IEEE CS ha establecido dos
10-22 Guía SWEBOK®
programasV3.0
internacionalesde certificación Conocimiento (Guía SWEBOK). Todos estos
(CSDA, PCSD) y una guía correspondientes a son
la Ingeniería de Software de Administración de
11-1
Figura 11.1. Desglose de temas para la Ingeniería de Software Profesional Práctica KA
elementos que sientan las bases para la práctica 11.1. Las subáreas presentados en este KA son
profesional de la ingeniería de software. el profesionalismo, la dinámica de grupo y la
psicología, y habilidades de comunicación.
PRÁCTICA PROFESIONAL DE 1. Profesionalismo
INGENIERÍA DE SOFTWARE
Un ingeniero de software muestra el
desglose de los temas de la Ingeniería de profesionalismo en particular mediante la
Software Profesional Práctica de KA se muestra adhesión a códigos de ética y conducta
en la figura profesional y las normas y
Ingeniería de Software Práctica Profesional 11-3
prácticas que son establecidos por la comunidad

profesional del ingeniero. 1.1.2. Proceso de dar un título
La comunidad profesional es a menudo
representada por una o varias sociedades Certificación se refiere a la confirmación de una
profesionales; aquellas sociedades publican per-
códigos de ética y conducta profesional, así características particulares del hijo. Un tipo
como los criterios para la admisión a la común
comunidad. Estos criterios son la base para las
actividades de acreditación y concesión de
licencias y pueden ser utilizados como una
medida para determinar la competencia de
ingeniería o negligencia.
1.1. Acreditación, Certificación y Licencias

[1 *, c1s4.1, c1s5.1-c1s5.4]
1.1.1. acreditación
Acreditación es un proceso para certificar la

tencia tencia, autoridad, o la credibilidad de una
organización. escuelas o programas acreditados
están asegurados a que se adhieran a las normas
particulares y mantener cualidades determi-
nados. En muchos países, los medios básicos por
los cuales los ingenieros adquieren
conocimientos es a través de la finalización de
un curso acreditado de estudio. A menudo, la
acreditación de ingeniería se lleva a cabo por
una organización gubernamental, tales como el
Ministerio de Educación. Tales países con
acreditaciones gubernamentales incluyen China,
Francia, Alemania, Israel, Italia y Rusia.
En otros países, sin embargo, el proceso de
acredi- ción es independiente del gobierno y
realizado por las asociaciones de miembros
privados. Por ejemplo, en los Estados Unidos,
Engineer- acreditación ción se lleva a cabo por
una organiza- ción conocida como ABET. Una
organización conocida como CSAB que actúa
como un órgano de participación de la sociedad
ABET es el plomo dentro de ABET para la
acredi- ción de los programas de grado en
ingeniería de software. Si bien el proceso de
acreditación pueden diferir de país y para cada
jurisdicción, el significado general es la misma.
Por supuesto, de una institución de estudio para
ser acreditado significa que “el cuerpo ción
acredi- reconoce una institución educativa como
el mantenimiento de las normas que califican a
los graduados para la admisión a más alto o más
especializado insti-
tuciones o para el ejercicio profesional”[2].
11-4 Guía SWEBOK® V3.0 profesional a través de su carrera, las habilidades
de la certificación es la certificación
profesional, cuando una persona está y capacidades requeridas cambiar y evolucionar.
certificado como ser capaz de completar una En general, los ingenieros tienen licencia
actividad en una cierta disciplina en un nivel como un medio de proteger al público de
determinado de competencias. certificación personas no cualificadas. En algunos países, no
profesional también puede verificar la se puede ejercer como ingeniero de profesional
capacidad del titular para cumplir con las menos que esté autorizado; o más, sin
normas profesionales y aplicar el juicio
profesional en la solución o la solución de los
problemas. La certificación profesional
también puede implicar la verificación del
conocimiento establecido, la de masterización
de las mejores prácticas y metodologías
comprobadas, y la cantidad de experiencia
profesional.
Un ingeniero usualmente obtiene la
certificación superando un examen en
conjunción con otros criterios basados en la
experiencia. Estos exámenes son a menudo
administrados por organizaciones no
gubernamentales, como las asociaciones
profesionales.
En la ingeniería de software, certificación
monio con inversión extranjera a la calificación
de una persona como ingeniero de software.
Por ejemplo, el IEEE CS ha promulgado dos
programas de identifi- cier- (CSDA y PCSD)
diseñados para confirmar los conocimientos de
un ingeniero de software de las prácticas de
ingeniería de software estándar y para avanzar
en la carrera de uno. La falta de certificación
no excluye al individuo de trabajar como
ingeniero de software. Actualmente la
certificación en ingeniería de software es
completamente voluntaria. De hecho, la
mayoría de los ingenieros de software no están
certificados bajo cualquier programa.
1.1.3. la concesión de licencias
“Las licencias” es la acción de dar a una

persona la autorización para realizar ciertos
tipos de actividades y asumir la
responsabilidad de los productos resultantes de
ING Engineer-. El sustantivo “licencia” se
refiere tanto a la autorización y el documento
de grabación que la autorización. Las
autoridades gubernamentales u organismos
reglamentarios por lo general otorgan licencias.
La obtención de una licencia para la práctica
requiere no sólo que una persona cumple un
cierto nivel, sino que también lo hacen con una
cierta capacidad de practicar u operar. A veces
hay un requisito de nivel de entrada que
establece las habilidades y capacidades
mínimas para la práctica, pero a medida que el
empresa puede ofrecer “servicios de ingeniería” con- cerning el público, clientes y

a menos empresarios, el producto, el juicio, la
al menos un ingeniero con licencia se emplea gestión, profe- sión, colegas, y el auto,
allí. respectivamente .
1.2. Códigos de Ética y Conducta Profesional

[1 *, c1s6-c1s9] [3 *, c8] [4 *, c1s2] [5 *, c33]
[6 *]
Los códigos de ética y conducta premio com-

profesional de los valores y el comportamiento y
las decisiones que la práctica profesional de un
ingeniero debe encarnar.
La comunidad profesional establece códigos
de ética y conducta profesional. Existen en el
contexto de, y se ajustan de acuerdo con las
normas sociales, y las leyes locales. Por lo tanto,
los códigos de ética y conducta profesional
presente Ance guid- en la cara de los
imperativos contradictorios.
Una vez que se han establecido códigos de
ética y conducta profesional son impuestas por
la profesión, según lo representado por las
asociaciones profesionales o por un organismo
de derecho público.
Violaciónes pueden ser actos de comisión,
como la ocultación de trabajo inadecuado, la
revelación de información con- Fidential,
falsificar información, o desvirtuar las
habilidades de uno. También pueden ocurrir a
través de la omisión, incluyendo la falta de dis-
cercanos riesgos o para proporcionar
información importante, el hecho de dar crédito
o reconocer las referencias, y el fracaso para
representar EST cliente inter. Violaciónes de los
códigos de ética y conducta profesional pueden
dar lugar a sanciones y posible la expulsión del
estatus profesional.
Un código de ética y conducta profesional de
la ingeniería de software fue aprobado por el
Consejo de la ACM y la Junta de Gobernadores
CS IEEE en 1999 [6 *]. De acuerdo con la
versión corta de este código:
Los ingenieros de software deberán

comprometerse ellos mismos a hacer el
análisis, especifica- ción, diseño,
desarrollo, prueba y mantenimiento de
software una profesión beneficiosa y
respetada. De acuerdo con su compromiso
con la salud, la seguridad y el bienestar
del público, los ingenieros de software
deberán cumplir con los ocho principios
11-6 Guía SWEBOK® V3.0 apoyan las áreas de conocimiento de esta Guía.
Dado que se pueden introducir normas y
códigos de ética y conducta profesional, Los beneficios de las normas de ingeniería de
modificado o reemplazado en cualquier software
momento, inge- niería de software individuales son muchas e incluyen la mejora de la calidad del
tienen la responsabilidad de su propio estudio software,
tinuing con- para mantenerse al día en su
práctica profesional.
1.3. La naturaleza y la función de las

Sociedades Profesionales
[1 *, C1S1-c1s2] [4 *, c1s2] [5 *,
c35s1]
Las sociedades profesionales se componen de

una mezcla de profesionales y académicos.
Estas sociedades sirven para definir, impulsar y
regular sus profesiones correspondientes. Las
sociedades profesionales ayudan a establecer
estándares profesionales, así como códigos de
ética y conducta profesional. Por esta razón,
también se dedican a actividades relacionadas,
que incluyen
• establecer y promulgar un cuerpo de

conocimiento generalmente aceptado;
• acreditación, certificación, y la concesión de
licencias;
• dispensación de medidas disciplinarias;
• el avance de la profesión a través de las
conferencias, capacitación y
publicaciones.
La participación en sociedades profesionales

asiste al ingeniero individuo en el
mantenimiento y la nitidez ening sus
conocimientos profesionales y la relevancia y
en la ampliación y el mantenimiento de su red
profesional.
1.4. La naturaleza y la función de las

normas de ingeniería de software
[1 *, c5s3.2, c10s2.1] [5 *, c32s6] [7 *,
c1s2]
Software normas de ingeniería cubren una

remark- capaces variedad de temas. Ellos
proporcionan directrices para la práctica de la
ingeniería de software y procesos para ser
utilizados durante el desarrollo, mantenimiento
y soporte de software. Mediante el
establecimiento de un cuerpo consensuada de
conocimientos y experiencias, software de
inge- niería normas establecen una base sobre
la cual fur- directrices ther puede ser
desarrollado. Apéndice B de esta Guía
proporciona orientación sobre las normas de
ingeniería de software IEEE e ISO / IEC que
ayudar a evitar errores, la protección de los suministrador de empresa a cliente, Engineer-

productores y los usuarios de software, el asesoramiento a cliente, contratación directa, o
aumento de disciplina profesional, y ayudar a incluso como voluntario. En todas estas
la transición de la tecnología. situaciones, el al cliente central y proveedor de
acuerdo en que un producto o servicio será
1.5. Impacto económico de Software proporcionado a cambio de algún tipo de
[3 *, c10s8] [4 *, c1s1.1] [8 *, c1]
El software tiene efectos económicos a nivel

individual, negocio, y los niveles de la sociedad.
Software “éxito” puede ser determinado por la
idoneidad de un producto para un problema
reconocido, así como por su efectividad cuando
se aplica a ese problema.
A nivel individual, el empleo continua- ción
de un ingeniero puede depender de su capacidad
y disposición para interpretar y ejecutar tareas en
el cumplimiento de las necesidades y
expectativas de los clientes o empleadores. El
cliente o situación finan- cial del empleador
pueden a su vez ser positiva o negativamente
afectados por la compra de software.
A nivel empresarial, el software aplica
correctamente a un problema puede eliminar
meses de trabajo y traducirse en ganancias
elevadas u organizaciones tivos más effec-. Por
otra parte, las organizaciones que adquieren o
proporcionan software con éxito pueden ser de
gran ayuda a la sociedad en la que operan por
Viding pro del empleo y de mejora de los
servicios. Sin embargo, los costes de desarrollo
o adquisición de software también pueden
equiparar a las de cualquier adquisición
importante.
En el ámbito social, los impactos directos del
éxito o el fracaso de software incluyen o
excluyen los accidentes, interrupciones y
pérdida de servicio. Los impactos indirectos
incluyen el éxito o el fracaso de la organización
que adquiere o se produce el software, aumento
o disminución de la productividad de la
sociedad, el orden social armónico o perjudicial,
e incluso el ahorro o la pérdida de la propiedad y
la vida.
1.6. Contratos de trabajo

[1 *, c7]
servicios de ingeniería de software se pueden

proporcionar en una variedad de relaciones
cliente-ingeniero. El trabajo de ingeniería de
software puede ser solic- ited como
11-8 Guía SWEBOK® V3.0 para poseer el conocimiento de estas cuestiones
consideración. En este caso, estamos más
preocupados con el arreglo de ingeniero a los y su aplicabilidad.
clientes y sus acompañantes acuerdos o cuestiones legales se basan
contratos, si son de la variedad contratación jurisdiccionalmente; suave-
directa o consultor, y los problemas que suelen Los ingenieros de mercancías deben consultar a
abordar. los abogados que
Una preocupación común en contratos de
ingeniería de software es la confidencialidad.
Los empleadores obtienen ventajas comerciales
de la propiedad intelectual, por lo que se
esfuerzan proteger dicha propiedad de cierre
dis-. Por lo tanto, los ingenieros de software a
menudo tienen que firmar acuerdos de
propiedad intelectual (IP) no divulgación
(NDA) o como una condición previa para
trabajar. Estos acuerdos se aplican
normalmente a la información del ingeniero de
software sólo puede ganar a través de la
asociación con el cliente. Los términos de estos
acuerdos pueden extenderse más allá de la
nación terminología de la asociación.
Otra preocupación es la propiedad
intelectual. Los derechos sobre los activos de
software de ingeniería subproductos,
innovaciones, inventos, descubrimientos e
ideas pueden residir con el empleador o cliente,
ya sea en virtud de los términos del contrato
explícitas o leyes pertinentes, si se obtienen
dichos activos durante el plazo del ingeniero de
software de relación con ese empleador o
cliente. Contratos difieren en la propiedad de
los activos creados usando ción o información
equip- propiedad no por el empleador.
Finalmente, contratos también pueden
especificar, entre otros elementos la ubicación
en la que el trabajo se va a realizar; normas a
las que se llevará a cabo ese trabajo; la
configuración del sistema que se utiliza para el
desarrollo; limitaciones del software nieros
Neer y responsabilidad del empleador; una
matriz de comunicación y / o plan de escalada;
y detalles administrativos tales como los tipos,
la frecuencia de compensación, horas de
trabajo, y las condiciones de trabajo.
1.7. Asuntos legales

[1 *, c6, c11] [3 *, c5s3-c5s4] [9 *,
c1s10]
cuestiones legales que rodean la práctica

profesional de la ingeniería de software
incluyen en particular las cuestiones
relacionadas con las normas, marcas, patentes,
derechos de autor, secretos comerciales,
responsabilidad profesional, requisitos legales,
de cumplimiento comercial, y la
ciberdelincuencia. Por tanto, es beneficioso
especializarse en el tipo y la jurisdicción de cantes tura y vender una idea. Una patente
cualquier problema legal tificado iden-. consiste en un conjunto de derechos exclusivos
concedidos por una ernment gobier- soberano a un
1.7.1. normas individuo, grupo de individuos, o de la
organización durante un periodo limitado de
normas de ingeniería de software establecen tiempo. patentes
líneas directrices para las prácticas generalmente
aceptadas y el mini-requisitos mamá de
productos y servicios RESPETA por un
ingeniero de software. Apéndice B de esta Guía
proporciona orientación sobre ingeniería de
software estándares que se aplican a cada KA.
Los estándares son fuentes valiosas de los
requisitos y asistencia durante la conducción
cotidiana de las actividades de ingeniería de
software. La adhesión a las normas facilita la
disciplina mediante la enumeración de las
características mínimas de productos y
aplicaciones prácticas. Que la disciplina ayuda a
mitigar los supuestos subconscientes o exceso de
confianza en un diseño. Por estas razones, las
organizaciones que realizan actividades de
ingeniería de software a menudo incluyen la
conformidad con las normas, como parte de sus
polí- cias organizativas. Además, la adhesión a
las normas es un componente importante en la
defensa de la acción legal o de las acusaciones
de negligencia.
1.7.2. Marcas comerciales
Una marca se relaciona con cualquier palabra,

nombre, símbolo o dispositivo que se utiliza en
las transacciones comerciales. Se utiliza “para
indicar la fuente o el origen de las mercancías”
[2].
Marca protección protege a los nombres,
logotipos, imágenes y embalaje. Sin embargo, si
un nombre, imagen, u otro activo de marca
registrada se convierte en un término genérico, a
continuación, se anula la protección de marcas.
La Organización Mundial de la Propiedad
Intelectual (OMPI) es la autoridad que defina las
normas y reglamentos en materia de marcas. La
OMPI es la agencia de Naciones Unidas
dedicada al uso de la propiedad intelectual
como medio de estimular la in- novación y la
creatividad.
1.7.3. patentes
Las patentes protegen el derecho del inventor a

11-10 Guía SWEBOK® V3.0 Es común que los ingenieros de software para ser
son una forma antigua de la protección idea de
la propiedad y se remontan al siglo 15. con-
Solicitud de patente implica un registro cerned con cuestiones de responsabilidad
cuidadoso del proceso que condujo a la profesional. Como
invención. Los abogados de patentes son útiles
para escribir las reclamaciones de divulgación
de patentes de una manera más probable para
proteger los derechos del ingeniero software.
Tenga en cuenta que, si las invenciones se
realizan durante el curso de un contrato de
ingeniería de software, propietario-buque
puede pertenecer al empleador o cliente o ser
realizada en forma conjunta, en lugar de
pertenecer al ingeniero de software.
Existen normas relativas a lo que es y no es
patentable. En muchos países, el código de
software no es patentable, aunque los
algoritmos de software pueden ser. solicitudes
de patentes presentadas existentes y se pueden
buscar en la OMPI.
1.7.4. Derechos de autor
La mayoría de los gobiernos en el mundo

otorgan derechos exclusivos de una obra
original de su creador, por lo general por un
tiempo limitado, promulgada como los
derechos de autor. los derechos de autor
protegen la forma en que se presenta, no una
idea de la idea en sí misma. Por ejemplo,
pueden proteger la formulación particular de
una cuenta de un evento histórico, mientras que
el evento en sí no está protegido. Los derechos
de autor son a largo plazo y renovable; que
datan del siglo 17.
1.7.5. Comercio Misterios
En muchos países, un activo intelectual, tales

como una fórmula, algoritmo, proceso, diseño,
método, patrón, instrumento o recopilación de
informa- ción puede ser considerado como un
“secreto comercial”, a condición de que estos
activos no son generalmente conocidos y
pueden proporcionar una empresa alguna
ventaja económica. La designación de “secreto
comercial” proporciona protección legal si el
activo es robado. Esta protección no está sujeta
a un límite de tiempo. Sin embargo, si la otra
parte se deriva o descubre el mismo bien
jurídico, entonces el activo ya no está
protegido y la otra parte será también poseen
todos los derechos de uso de la misma.
1.7.6. Responsabilidad profesional

un individuo presta servicios a un cliente o internacional se puede acceder desde la

empleador, es vital para cumplir con las normas Organización Mundial del Comercio (OMC).
y prácticas generalmente aceptadas, protegiendo
así contra las acusaciones o procedimientos de o
relacionados con negligencia, negligencia o
incompetencia.
Para los ingenieros, incluyendo ingenieros de
software, responsabilidad profesional está
relacionada con la responsabilidad del producto.
En virtud de las leyes y normas que rigen en su
jurisdicción, los ingenieros pueden ser obligados
a rendir cuentas por no seguir totalmente y con
plena conciencia práctica recomendada; esto se
conoce como “negligencia”. También pueden
estar sujetos a las leyes gobiernos ing
“responsabilidad objetiva” y ya sea implícita o
garantía expresa, en donde, por la venta del
producto, se lleva a cabo la Neer niería a
garantiza que el producto es tanto adecuado y
seguro para su uso. En algunos países (por
ejemplo, en los EE.UU.), “connivencia” (la idea
de que sólo se podría demandar a la persona que
vende el producto) ya no es una defensa contra
la acción de responsabilidad.
Procesos judiciales por responsabilidad
pueden ser sometidos en derecho de daños en los
EE.UU. permitiendo que cualquier persona que
esté dañado para recuperar su pérdida, incluso si
no se hicieron garantías. Debido a que es difícil
medir la capacidad o la seguridad de software de
traje-, el hecho de tener el debido cuidado se
puede utilizar para probar la negligencia por
parte de los ingenieros de software. Una defensa
contra tal acusación es demostrar que las normas
y prácticas generalmente aceptadas fueron
seguidos en el desarrollo del producto.
1.7.7. Requerimientos legales
Los ingenieros de software deben operar dentro

de los confines de los marcos jurídicos locales,
nacionales e internacionales. Por lo tanto, los
ingenieros de software deben estar al tanto de
los requisitos legales para
• registro y autorización, incluyendo nación

exami-, la educación, la experiencia y las
necesidades de formación;
• acuerdos contractuales;
• legalidades no contractuales, como los
gobier- responsabilidad Erning;
• Información básica sobre el marco jurídico
11-12 Guía SWEBOK® V3.0 [1 *, c10s5.8] [3 *, c1s5] [5 *, c32]
1.7.8. Comercio Conformidad
Todos los profesionales de software deben Proporcionar clara, completa y precisa docu-
estar al tanto de las restricciones legales a la mentación es la responsabilidad de cada
importación, exportación o reexportación de ingeniero de software. La idoneidad de la
mercancías, servicios y tecnología en las documentación es
jurisdicciones en las que trabajan. Las
consideraciones incluyen controles de
exportación y clasificación, transferencia de
bienes, adquisición de licencias
gubernamentales necesarias para el uso
exterior de hardware y software, servicios y
tecnología por país sancionado, empresa o
entidades individuales, y las restricciones de
importación y deberes. Los expertos en
comercio debe ser consultado para una guía
detallada cumplimiento.
1.7.9. los delitos informáticos
La delincuencia informática se refiere a

cualquier crimen, que involucra una
computadora, software de ordenador,
ordenador NETWORKS, o software
incorporado el control de un sistema. El
ordenador o el software pueden haber sido
utilizados en la comisión de un delito o que
pueden haber sido el blanco. Esta categoría
incluye los delitos de fraude, acceso no
autorizado, spam, contenido obsceno u
ofensivo, amenazas, acoso, robo de datos
personales o secretos comerciales sensibles, y
el uso de una computadora para dañar o
infiltrarse en otros ordenadores conectados en
red y controles automatizados del sistema.
Los usuarios de ordenadores y software
cometer fraude mediante la alteración de los
datos electrónicos para facilitar su actividad
ilegal. Formas de acceso no autorizado
incluyen ing cortar metal, una interceptación, y
el uso de los sistemas informáticos de una
manera que se oculta de sus dueños.
Muchos países tienen leyes separadas para
cubrir los delitos cibernéticos, pero a veces ha
sido difícil de procesar a los delitos
cibernéticos, debido a la falta de estatutos pre
precisamente enmarcadas. El ingeniero de
software tiene la obligación profesional de
considerar la amenaza de la delincuencia
informática y para entender cómo el sistema de
software protegerá o poner en peligro el
software y la información de usuario de acceso
accidental o malintencionada, uso,
modificación, destrucción, o de la divulgación.
1.8. Documentación
juzgado por diferentes criterios basados en las desempeño de otras funciones por varios grupos
necesidades de los diversos públicos interesados. de usuarios y personal de apoyo. Si el cliente
Una buena documentación cumple con las adquirirá la propiedad
normas y directrices aceptadas. En particular, los
ingenieros de software deben documentar
• hechos relevantes,
• los riesgos y las ventajas y desventajas
significativas, y
• advertencias de consecuencias indeseables o
peligrosos de uso o mal uso del software.
Los ingenieros de software deben evitar
• certificar o aprobar productos inaceptables,

• revelar información confidencial, o
• falsificación de hechos o datos.
Además, los ingenieros de software y sus Los

directivos deberían proporcionar importantes
son los siguientes docu- mentación para su uso
por otros elementos de la organización de
desarrollo de software:
• requisitos de software especificaciones,

documentos de diseño de software, los
detalles sobre las herramientas de ingeniería
de software, de las especificaciones de
prueba de software y los resultados, y
detalles sobre los métodos de ingeniería de
software adoptados;
• problemas encontrados durante el proceso
de desarrollo.
Para los interesados externos (clientes,

usuarios, otros) documentación del software
debe proporcionar particular
• información necesaria para determinar si es

probable que para satisfacer las necesidades
de los usuarios de los clientes y el soft-
ware,
• Descripción de la caja fuerte, y poco seguro,
el uso del software,
• Descripción de la protección de la
información sensible almacenada o creado
por el uso del software, y
• identificación clara de advertencias y crítico
procedimientos.
El uso de software puede incluir la instalación,

funcionamiento, la administración y el
11-14 Guía SWEBOK® V3.0 costo contra el riesgo, especialmente donde la
del código fuente del software o el derecho a
modificar el código, el ingeniero de software producción primaria y los costos basados en el
debe proporcionar documentación de las riesgo ary de segunda deben comercializarse uno
especificaciones funcionales, el diseño del contra el otro.
software, el conjunto de pruebas, y el entorno
operativo es preciso proceder para el software.
La longitud mínima de los documentos de
tiempo se debe mantener es la duración del
ciclo de vida de los productos de software o el
tiempo requerido por los requisitos pertinentes
orga- zational o reglamentarias.
1.9. Análisis compensación

[3 *, c1s2, c10] [9 *,
c9s5.10]
Dentro de la práctica de la ingeniería de

software, un ingeniero de software a menudo
tiene que elegir entre soluciones alternativas
problemas. El resultado de estas opciones es
determinado por la evaluación profesional del
software niería de Neer de los riesgos, los
costos y beneficios de las alternativas, en
cooperación con las partes interesadas.
Evaluación del ingeniero de software se llama
“análisis de equilibrio”. El análisis de
relaciones de intercambio permite sobre todo la
identificación de compe- ING y requisitos de
software complementarios con el fin de dar
prioridad a la última serie de requisitos que
definen el software que se construirá (consulte
Requisitos de Negociación de los requisitos de
software KA y determinación y negocia- ción
de los requisitos en el KA Software de Gestión
de inge- niería).
En el caso de un proyecto de Desa- ción de
software en curso que se retrasa o por encima
del presupuesto, análisis de compensación se
realiza a menudo para decidir qué requisitos de
software pueden estar relajado o se ha caído
debido a los efectos de la misma.
Un primer paso en un análisis de equilibrio
está establecimientos ing objetivos de diseño
(ver diseño de ingeniería en el Fundamentos de
Ingeniería KA) y establecer la importancia
relativa de estos objetivos. Esto permite la
identificación de la solución que más se
aproxime a esos objetivos; esto significa que la
forma en que los objetivos se expresan es de
importancia crítica.
Los objetivos de diseño pueden incluir la
reducción al mínimo de los costos monetarios
y la maximización de la fiabilidad,
rendimiento, o algún otro criterio sobre una
amplia gama de dimensiones. Sin embargo, es
difícil formular un análisis de equilibrio de
Un ingeniero de software debe realizar un calidad del software KA). Esto permite que todos
análisis de equilibrio de una manera ética de los miembros que persiguen un ciclo de mejora
manera -en particular por ser objetiva e continua y el crecimiento sin riesgo personal. En
imparcial la hora de seleccionar los criterios para general, los miembros de equipos cohesivos
la comparación de soluciones a los problemas demuestran respeto por los demás y su líder.
alternativos y en la asignación de pesos o
importancia a estos criterios. Cualquier conflicto
de intereses debe ser revelada en la delantera.
2. Grupo de Dinámica y Psicología
trabajos de ingeniería se llevó a cabo muy a

menudo en el contexto del trabajo en equipo. Un
ingeniero de software debe ser capaz de
interactuar de manera cooperativa y construc-
tivamente con otros para determinar en primer
lugar y luego satisfacer tanto las necesidades y
expectativas. El conocimiento de la dinámica de
grupo y la psicología es un activo en la
interacción con los clientes, compañeros de
trabajo, proveedores y subordinados para
resolver problemas de ingeniería de software.
2.1. Dinámica de trabajo en equipos / grupos

[3 *, c1s6] [9 *, c1s3.5, c10]
Los ingenieros de software deben trabajar con

los demás. Por un lado, trabajan internamente en
los equipos de ingeniería; por el contrario,
trabajan con tomers cliente central, los
miembros del público, reguladores y otras partes
interesadas. Realización de los equipos de los
que demuestran una calidad constante del
trabajo y el progreso hacia las metas-son
cohesivas y poseen una atmósfera de
cooperación, honesta y enfocada. objetivos
individuales y de equipo están alineados de tal
manera que los miembros de forma natural se
comprometan y se sientan dueños de resultados
compartidos.
Equipo miembros facilitan esta atmósfera por
ser intelectualmente honesto, haciendo uso del
pensamiento de grupo, admitiendo la ignorancia,
y acknowledg- errores ing. Ellos comparten la
responsabilidad, recompensas, y la carga de
trabajo de manera justa. Ellos se encargan de
comunicarse con claridad, directamente entre sí
y en el documentos, así como en código fuente,
por lo que informa- ción es accesible a todos.
Peer comentarios sobre los productos de trabajo
se enmarcan en una forma constructiva y no
personal (ver revisiones y auditorías de la
11-16 Guía SWEBOK® V3.0 KA). El desglose de los problemas y les
Un punto a destacar es que el software de
ingenieros deben ser capaces de trabajar en resolución de una sola pieza a la vez reduce la
entornos multidisciplinares y en variados sobrecarga cognitiva. Aprovechando la
campos de aplicación. Dado que el software de curiosidad profesional y la búsqueda del
hoy está en todas partes, desde un teléfono a un desarrollo profesional continuo
coche, el software está afectando a la vida de
las personas más allá del concepto más
tradicional de software hecho para la gestión
de la información en un entorno empresarial.
2.2. cognición individual

[3 *, c1s6.5] [5 *,
c33]
Ingenieros deseo de resolver los problemas. La

capacidad de resolver problemas con eficacia y
eficiencia es lo que se esfuerza para todos los
ingenieros. Sin embargo, los límites y los
procesos de la cognición individual afectan la
resolución de problema. En la ingeniería de
software, sobre todo debido a la naturaleza
altamente abstracta de software en sí, la
cognición individual juega un papel muy
importante en la resolución de problemas.
En general, de un individuo (en particular, )
La capacidad de un ingeniero de software para
descomponer un problema con creatividad y
desarrollar una solución puede ser inhibida por
• la necesidad de un mayor conocimiento,

• supuestos subconscientes,
• volumen de datos,
• miedo al fracaso o la consecuencia de la
falta,
• cultura, eitherapplicationdomainor
organizacional,
• la falta de capacidad de expresar el

problema,
• percibida ambiente de trabajo, y
• el estado emocional del individuo.
El impacto de estos factores inhibidores se

puede reducir mediante el cultivo de buenos
hábitos de resolución de problemas que
minimicen el impacto de suposiciones
erróneas. La capacidad de concentrarse es de
vital importancia, ya que es la humildad
intelectual: ambos permiten un Neer niería de
software para suspender las consideraciones
personales y consultado con los demás
libremente, lo que es especialmente impor-
tante cuando se trabaja en equipo.
Hay una serie de métodos básicos ingenieros
utilizan para facilitar la resolución de
problemas (véase el problema Solv- ing
técnicas en los Fundamentos de Informática
mediante la formación y estudio añadir Por lo tanto, es vital para mantener abierta la
habilidades y El conocimiento de la cartera del comunicación y pro- ductiva con las partes
ingeniero de software; la lectura, la creación de interesadas para la duración de la vida útil del
redes, y experimentando con nuevas producto de software.
herramientas, técnicas y métodos son válidos
todos los medios de desarrollo profesional. 2.5. Superación de la incertidumbre y la
ambigüedad
2.3. Tratar con el problema Complejidad [4 *, c24s4, c26s2] [9 *, c9s4]
[3 *, c3s2] [5 *,
c33] Al igual que con los ingenieros de otros campos,
los ingenieros de software a menudo deben
Muchos, si no la mayoría, blemas de ingeniería atender y resolver la incertidumbre y la
de software blemas son demasiado complejos y ambigüedad, mientras que la prestación de
difíciles de abordar en su conjunto o para ser servicios y el desarrollo de productos. El
abordado por los ingenieros de software ingeniero de software debe atacar y reducir o
individuales. Cuando surgen tales eliminar cualquier falta de claridad que es un
circunstancias, los medios habituales para obstáculo para la realización de trabajos.
adoptar es el trabajo en equipo y el problema de A menudo, la incertidumbre es simplemente
la descomposición (véase el problema técnicas un reflejo de la falta de conocimiento. En este
de resolución en los Fundamentos de caso, la investigación mediante el recurso a
Informática KA). fuentes formales tales como libros de texto y
equipos trabajar juntos para resolver los revistas profesionales, entrevistas con ERS
problemas más complejos y grandes mediante el stakehold-, o consulta con los compañeros y
intercambio de cargas y N ° de dibujo en el compañeros puede superarla.
conocimiento y la creatividad de cada uno. Cuando la incertidumbre o ambigüedad no
Cuando los ingenieros de software trabajan en pueden ser excesivamente sido fácil, los
equipos, puntos de vista diferentes y ingenieros de software u organizaciones pueden
habilidades de los ingenieros individuales se optar por considerar como un riesgo del
complementan entre sí y ayudar a construir una proyecto. En este caso, las estimaciones de
solución que sea de otro modo difícil de trabajo o de precios se ajustan para mitigar el
conseguir. Algunos ejemplos de trabajo en costo anticipado de hacer frente a ella (véase
equipo espe- CIFIC a la ingeniería de software Gestión de Riesgos en el KA Software
son la programación en parejas (ver Métodos Engineering Management).
ágiles en los modelos de ingeniería de software
y métodos KA) y la revisión de código (ver 2.6. Tratar con entornos multiculturales
revisiones y auditorías de la calidad del software [9 *, c10s7]
KA).
2.4. La interacción con las partes interesadas

[9 *, c2s3.1] Durante el desarrollo, los interesados pueden
pro- vide retroalimentación sobre las
El éxito de una empresa de ingeniería de especificaciones y / o las primeras versiones del
software depende de las interacciones positivas software, cambio de prioridad, así como la
con los titulares de stake-. Deben proporcionar clarificación de requisitos detallados o nuevo
apoyo, informa- ción, y la retroalimentación en software. Por último, durante el mantenimiento de
todas las etapas del proceso del ciclo de vida del software y hasta el final de su vida útil, los
software. Por ejemplo, durante las primeras interesados Pro- retroalimentación vide en
etapas, es fundamental para identificar todas las evolución o nuevos requisitos que los informes de
partes interesadas y descubrir cómo el producto problemas así para que el software puede ser
les afecta, por lo que la definición suficiente de ampliado y mejorado.
la parte interesada los requisitos puede ser
adecuada y completamente capturado.
11-18 Guíamulticulturales
entornos SWEBOK® V3.0 pueden tener un
impacto en la dinámica de un grupo. Esto es
especialmente cierto cuando el grupo está
separado geográficamente o comunicación es
poco frecuente, ya que tales ración sepa- eleva
la importancia de cada contacto. La
comunicación intercultural es aún más dife-
ficult si la diferencia de husos horarios que la
comunicación oral de menos frecuentes.
ambientes multiculturales son bastante
frecuentes en la ingeniería de software, quizás
más que en otros campos de la ingeniería,
debido a la fuerte tendencia a la
externalización internacional y el envío fácil de
componentes de software de forma instantánea
en todo el mundo. Por ejemplo, es bastante
común para un proyecto de software que se
dividirá en pedazos través de las fronteras
nacionales y culturales, y también es bastante
común para un equipo de proyecto de software
a constan de personas de diversos orígenes
culturales.
Para un proyecto de software sea un éxito,
los miembros del equipo deben alcanzar un
nivel de tolerancia,
reconociendo que algunas reglas dependen de para ellos, lo que simplifica o explicarla de
las normas etal ciedades y que no todas las manera que puedan tomar la decisión final entre
sociedades derivan las mismas soluciones y soluciones de la competencia.
expectativas. La lectura y la comprensión de código fuente es
Esta tolerancia y comprensión ing también un componente de recopilación de
acompañante pueden ser facilitadas por el apoyo información y resolución de problemas. Al
de la dirección y gestión. comunicaciones más modificar, extender,
frecuentes, incluyendo las reuniones cara a cara,
puede ayudar a puerta mitiga las divisiones
geográficas y culturales, promover la cohesión,
y aumentar la productividad. Además, al ser
capaz de comunicarse con sus compañeros en su
lengua materna podría ser muy beneficioso.
3. Habilidades de comunicación
Es vital que un ingeniero de software se

comunican bien, tanto de forma oral como la
lectura y escritura. Suc logro cessful de los
requisitos de software y plazos depende del
desarrollo de sub clara de pie entre el ingeniero
de software y clientes, supervisores, compañeros
de trabajo, y abastecedores ERS. la resolución
de problemas óptima es posible gracias a la
capacidad de investigar, comprender y resumir
la información. la aceptación del producto del
cliente y el uso de productos seguros dependen
de la provisión de capacitación y la
documentación pertinente. De ello se desprende
que el propio éxito de la carrera del ingeniero de
software se ve afectada por la capacidad para
proporcionar de forma coherente la
comunicación oral y escrita de forma efectiva ya
tiempo.
3.1. Leer, comprender y resumir

[5 *, c33s3]
Los ingenieros de software son capaces de leer y

entienda material técnico. material técnico
incluye libros de referencia, manuales,
documentos de investigación, y el código fuente
del programa.
La lectura es no sólo una forma primaria de
las habilidades de ING improv-, sino también
una manera de reunir informa- ción necesaria
para la realización de los objetivos de ingeniería.
Un ingeniero de software tamiza a través acu-
mulada información, filtrando las piezas que
serán más útiles. Los clientes pueden solicitar
que un ingeniero de software se resumen los
resultados de dicha recopilación de información
11-12 Guía SWEBOK® V3.0 útil, no siempre es suficiente; También, si uno
o software de reescritura, es fundamental para
comprender tanto su implementación derivado envía demasiados mensajes, se hace difícil
directamente del código presentado y su identificar la información importante. Cada vez
diseño, que a menudo se debe inferirse. más, las organizaciones están utilizando la
empresa
3.2. Escritura
[3 *,
c1s5]
Los ingenieros de software son capaces de

producir productos escritos como es requerido
por las peticiones del cliente o la práctica gene-
ralmente aceptado. Estos productos escritos
pueden incluir código fuente, los planes de
proyectos de software, documentos de
requerimientos de software, análisis de riesgos,
documentos de diseño de software, planes de
pruebas de software, manuales de usuario,
informes técnicos y evaluaciones, las
justificaciones, diagramas y gráficos, y así
sucesivamente.
Escritura clara y concisa es muy importante
porque a menudo es el principal método de co-
municación entre las partes pertinentes. En
todos los casos, los productos de ingeniería de
software escrito deben ser escritos para que
sean accesibles, comprensibles y relevantes
para su público (s) previsto.
3.3. Equipo y Comunicación Grupo

[3 *, c1s6.8] [4 *, c22s3] [5 *,
c27s1]
[9 *,
c10s4]
La comunicación efectiva entre los miembros

del equipo y de grupo es esencial para un
esfuerzo de ingeniería de software de
colaboración. Los interesados deben ser
consultados, se deben tomar decisiones, y
deben ser generados planes. Cuanto mayor sea
el número de miembros del equipo y de grupo,
mayor es la necesidad de comunicar.
El número de vías de comunicación, SIN
EMBARGO, crece cuadráticamente con la
adición de cada miembro del equipo. Además,
los miembros del equipo no es probable que
comunicarse con cualquier per- recibi- do que
ser eliminado de ellos por más de dos grados
(niveles). Este problema puede ser más grave
cuando se esfuerza u organizaciones de
ingeniería de software se distribuyen a través
de fronteras nacionales y con- tinental.
Algún tipo de comunicación puede llevarse a
cabo por escrito. documentación de software es
un sustituto común para la interacción directa.
El correo electrónico es otra pero, aunque es
herramientas de colaboración para compartir fase, los ingenieros de software puede caminar a
información. Otras medidas, además, el uso de los clientes y compañeros de equipo a través de
almacenes de información electrónicos, los requisitos de software y llevar a cabo los
accesibles a todos los miembros del equipo, para requisitos formales reseñas (véanse los
las políticas organizacionales, normas, requisitos críticas en el software de los requisitos
procedimientos comunes de la ingeniería, y la KA). Durante y después del diseño de software,
información específica del proyecto, puede ser la construcción de software y mantenimiento de
más beneficioso. software, ingenieros de software llevan los
Algunos equipos de ingeniería de software se comentarios, walk-through de productos (véase
centran en la interacción cara a cara y promover comprobación y actuaciones en la calidad del
dicha interacción por el arreglo de oficinas. software KA), y la formación. Todo esto
Aunque las oficinas privadas mejoran la requiere la capacidad de presentar información
productividad individual, implantación común técnica a los grupos y solicitar ideas o
de los miembros del equipo en formas físicas o comentarios.
virtuales y proporcionar áreas de trabajo La capacidad del ingeniero de software para
comunal que es importante para los esfuerzos de transmitir conceptos de manera efectiva en una
colaboración. presentación, por lo tanto influye en la
aceptación del producto, gestión y atención al
3.4. Habilidades de presentación cliente; sino que también influye en la abil- dad
[3 *, c1s5] [4 *, c22] [9 *, c10s7-c10s8] de las partes interesadas a comprender y ayudar
en los esfuerzos de producto. Este conocimiento
Los ingenieros de software confían en sus tiene que ser archivados en forma de
habilidades de presentación durante los procesos diapositivas, el conocimiento contra escritura
del ciclo de vida del software. Por ejemplo, hasta, white papers técnicos, y cualquier otro
durante los requisitos de software material utilizado para la creación de
conocimiento.
2011 [4 *]
yoAEE-CS / ACM
1999 [6 *]
McConnell 2004
moscard
ónt et al.
[1
2003
2006 [7
2009 [9
JustaLey de
točkey 2004
SommervilLe
2000
*] *]
[5 *]
[8 *]
Mugirre
Larva del
*]
[3
Voland
*]
1. Profesionalismo
1.1. Acreditación, c1s4.1,
certificación,y c1s5.1-
Licencias c1s5.4
1.2. Códigos de
c1s9
Ética y Conducta c8 c1s2 c33 *
c1s6-
Profesional
1.3. La naturaleza y
c1s1-
la función de las c1s2 c35s1
c1s2
Sociedades
Profesionales
1.4. La
naturaleza y la c5s3.2,
c32s6 c1s2
función de las c10s2.1
normas de
ingeniería de
1.5. Económico
software c10s8 c1s1.1 c1
Impacto de Software
1.6. Contratos de
c7
trabajo
c5s4
1.7. Asuntos C6, C11 c1s10
c5s3-
legales
1.8. Documentación c10s5.8 c1s5 c32
1.9. Análisis c1s2,
c9s5.10
compensació c10
2. nGrupo de
Dinámica y
Psicología
2.1. Dinámica de
c1s3.5,
trabajo en equipos / c1s6
c10
grupos
2.2. Individual
c1s6.5 c33
Cognición
2.3. 2.3 Tratar con
c3s2 c33
problema
Complejidad
2.4. Interactuando
c2s3.1
con
Las partes
interesadas
2011 [4 *]
yoAEE-CS / ACM
1999 [6 *]
McConnell 2004
moscard
ónt et al.
[1
2003
2006 [7
2009 [9
JustaLey de
točkey 2004
SommervilLe
2000
[3 *]
[5 *]
[8 *]
Mugirre
Larva del
*]
*]
Voland
*]
2.5. Superación
c24s4,
de la c9s4
c26s2
incertidumbre y
la ambigüedad
2.6. Tratar con
entornos c10s7
multiculturales
3. Habilidades de
Comunicación
3.1. Leer,
comprender y c33s3
resumir
3.2. Escritura c1s5
3.3. Equipoy el Grupo
c1s6.8 c22s3 c27s1 c10s4
Comunicación
3.4. Habilidades c10s7-
c1s5 c22
de presentación c10s8
Gerald M. Weinberg, La psicología de [1 *] F. Bott et al., Cuestiones profesional en

Programación [10]. Ingeniería de Software, 3ª ed., Taylor &
Francis, 2000.
Este fue el primer libro importante para hacer
frente programa- ción como un esfuerzo [2] Diccionario Colegiado de Merriam-Webster,
individual y de equipo y se convirtió en un ed 11., 2003.
clásico en el fielre.
[3 *] G. Voland, Ingeniería de Diseño, 2ª ed.,
Kinney y Lange, PA, Ley de Propiedad Prentice Hall, 2003.
Intelectual para el negocio Abogados [11].
Este libro cubre las leyes de propiedad ed., Addison-Wesley, 2011.
intelectual en los EE.UU.. No sólo habla de lo
que el derecho de propiedad intelectual es; [5 *] S. McConnell, código completo, 2ª ed.,
También explica por qué se ve la forma en que Microsoft Press, 2004.
lo hace.
[6 *] IEEE / ACM Fuerza de Tarea Conjunta de
CS Software Ética de ingeniería y prácticas
profesionales, “Software Ingeniería Código
de Ética y Práctica Profesional (Versión
5.2),” 1999;
www.acm.org/serving/se/code.htm.
[7 *] JW Moore, La Hoja de Ruta de Ingeniería

Press, 2006.
[8 *] S. Tockey, Retorno de software: maximizar

el retorno de su inversión en software,
[9 *] RE Fairley, gestionar y liderar proyectos de

software, Wiley-IEEE Computer Society
Press, 2009.
[10] GM Weinberg, La Psicología de la

Programación: Plata
Edición de aniversario, Dorset House, 1998.
[11] Kinney y Lange, PA, Ley de la

Propiedad Intelectual de negocio
Abogados, Thomson West, 2013.
CAPÍTULO 12
ECONOMÍA INGENIERÍA DE SOFTWARE
producción o adquisición de negocios.

SIGLAS la economía de ingeniería de software se ocupa
de la alineación de las decisiones técnicas de
EVM Gestion del valor ganado software con
TIR Tasa interna de retorno
Tasa aceptable mínimo de
TREMA
Regreso
SPLC programasdel ciclo de vida del
Software
ROI producto
Retorno de la Inversión
ROCE Rendimiento del capital invertido
TCO Costo total de la propiedad
INTRODUCCIÓN
la economía de ingeniería de software se trata de

decisiones de ING MAK- relacionados con la
ingeniería de software en un contexto
empresarial. El éxito de un software
PRODUCIRSE UCT, el servicio, y la solución
depende de una buena gestión de Em- presas.
Sin embargo, en muchas empresas y
organizaciones, las relaciones comerciales de
software para el desarrollo de software e
ingeniería siguen siendo vagos. Esta área de
conocimiento (KA) proporciona una visión
general sobre la economía de ingeniería de
software.
La economía es el estudio de los valores,
costos, recursos, y su relación en un contexto o
situación dada. En la disciplina de la niería de
software niería, actividades tienen costos, pero
el software resultante tiene atributos
económicos. la economía de ingeniería de
software proporciona una manera de estudiar los
atributos de los procesos de software y software
de una manera sistemática que los relaciona con
las medidas económicas. Estas medidas
económicas pueden ser pesados y analizados al
tomar las decisiones que están dentro del alcance
de un software de orga- nización y los que están
dentro del alcance integral de toda una
las decisiones tanto técnicamente como desde un
los objetivos de negocio de la organización. En punto de vista comercial. El contenido de esta
todos los tipos de organizaciones-sea “con área de conocimiento son importantes ics de alta
fines de lucro”, “sin fines de lucro,” o para los ingenieros de software a tener en
gubernamental, esto se traduce en forma cuenta, incluso si nunca realmente están
sostenible permanecer en el negocio. En las involucrados en concreto de Em- presas de
organizaciones con fines de lucro “” Esto, decisiones; van a tener una visión cabal de las
además, se relaciona con achiev- ing un retorno cuestiones de negocios y el papel racio técnicos
tangible de los invertidos en capital los activos consideraciones juegan en la toma de decisiones
y el capital empleado. Esta KA ha sido de negocio. Muchas de las propuestas de
formulado de una manera para hacer frente a ingeniería y decisiones, tales como hacer frente
todo tipo de organizaciones independientes de a comprar, tienen profundos impactos
foco, cartera de productos y servicios, o la económicos intrínsecos que deben ser
propiedad del capital y las restricciones de la considerados de manera explícita.
tributación. Esta KA cubre primero las fundaciones,
Decisiones como “¿Hay que utilizar un minology clave ter-, conceptos básicos y las
componente específico?” Puede parecer fácil prácticas comunes de la economía de ingeniería
desde el punto de vista técnico, pero pueden de software para indicar la forma en la toma de
tener graves consecuencias sobre la viabilidad decisiones en ingeniería de software incluye o
empresarial de un proyecto de software y el debe incluir un negocio perspectiva. A
producto resultante. A menudo, los ingenieros continuación, proporciona una perspectiva del
se preguntan si estas preocupaciones se aplican ciclo de vida, destaca la gestión del riesgo y la
en absoluto, ya que son “sólo los ingenieros.” incertidumbre, y muestra cómo se utilizan los
Análisis económico y la toma de decisiones métodos de análisis económico. Algunas
son importantes consideraciones de ingeniería consideraciones prácticas terminar el área El
porque los ingenieros son capaces de evaluar conocimiento.
12-1
Figura 12.1. Desglose de temas para la Ingeniería de Software Economía KA

Software Economía Ingeniería 12-3
DISTRIBUCIÓN DE TEMAS PARA

ECONOMÍA INGENIERÍA DE 1.2. Contabilidad
SOFTWARE [1 *, c15]
El desglose de temas para el Software Inge- La contabilidad es parte de las finanzas. Permite a
niería Economía KA se muestra en la figura las personas
12.1. cuyo dinero está siendo utilizado para dirigir una
organización
1. Fundamentos de Ingeniería de
Software Economía
1.1. Financiar
[1 *, c2]
Finanzas es la rama de la economía que se

ocupan de cuestiones tales como la asignación,
administración, adquisición, y la inversión de los
recursos. La financiación es un elemento de
todas las organizaciones, incluidas las
organizaciones de ingeniería de software.
El campo de las finanzas se ocupa de los
conceptos de tiempo, dinero, riesgo, y cómo se
relacionan entre sí. También se ocupa de cómo
se gasta el dinero y geted presu-. finanzas
corporativas se ocupa de pro- Viding los fondos
para las actividades de una organización. En
general, se trata de equilibrar el riesgo y la
capacidad de utilidades, al intentar maximizar la
riqueza de una organiza- ción y el valor de sus
acciones. Esto es válido sobre todo para las
organizaciones “con fines de lucro”, pero
también se aplica a los “sin fines de lucro”
organizaciones. Este último necesita recursos
financieros para garantizar la sostenibilidad,
aunque no es la orientación de beneficio
tangible. Para ello, una organización debe
• identificar los objetivos de la organización,

los horizontes de tiempo, factores de riesgo,
consideraciones de impuestos, y las
limitaciones financieras;
• identificar e implementar la estrategia de
Ness Busi- apropiado, como el que las
decisiones de cartera y de inversión a tomar,
cómo gestionar el flujo de caja, y dónde
obtener los fondos;
• medir el desempeño financiero, tales como
el flujo de caja y el retorno de la inversión
(véase la sección 4.3, Retorno de la
Inversión), y tomar acciones correctivas en
caso de desviación de los objetivos y la
estrategia.
12-4 Guía SWEBOK® V3.0 que ser gastado para llevar a cabo esa propuesta
para conocer los resultados de su inversión:
sacaron los beneficios que se esperaban? En las dinero. Los ingresos por ventas de producto X
organizaciones “con fines de lucro”, esto se en el mes 11 después de su lanzamiento al
relaciona con el retorno de la inversión mercado es un ejemplo de un flujo de caja
tangible (ver sección 4.3, Retorno de la entrante
Inversión), mientras que en “sin fines de lucro”
y las organizaciones gubernamentales, así
como organizaciones “con fines de lucro”, que
se traduce en forma sostenible permanecer en
el negocio. La función principal de la
contabilidad es medir el rendimiento financiero
real de la organiza- ción y para com- municar
información financiera sobre una entidad de
negocio para las partes interesadas, como los
accionistas, auditores financieros e inversores.
La comunicación es generalmente en la forma
de estados financieros que muestran en
términos monetarios los recursos económicos
que deben ser controlados. Es importante
seleccionar la información adecuada que sea
relevante y fiable para el usuario. La
información y su distribución están
parcialmente rigen por las políticas de gestión
de riesgos y de gobierno. Los sistemas de
contabilidad son también una rica fuente de
datos históricos para estimar.
1.3. Controlador
[1 *, c15]
El control es un elemento de las finanzas y una

contabilidad. Controladora implica medir y
correcta- ing el desempeño de las finanzas y la
contabilidad. Se asegura de que los objetivos y
planes de la organización se llevan a cabo. El
control de costos es una rama especia- espe- de
controlar utilizado para detectar varianzas de
los costes reales de los costes previstos.
1.4. Flujo de fondos

[1 *, c3]
El flujo de caja es el movimiento de dinero que

entra o sale de un negocio, proyecto o producto
financiero durante un período determinado.
Los conceptos de instancias de flujo de caja y
las corrientes de flujo de efectivo se utilizan
para describir la perspectiva de negocio de una
propuesta. Para tomar una decisión de negocios
significativa sobre cualquier propuesta
específica, tendrá que ser evaluado desde una
perspectiva empresarial dicha propuesta. En
una propuesta para desarrollar y poner en
marcha el producto X, el pago por nuevas
licencias de software es un ejemplo de una
instancia de flujo de caja ing outgo-. tendría
Figura 12.2. Un Diagrama de Flujo de Caja
ejemplo. El dinero iba a venir a causa de igualmente bien, ¿por qué se elige el cuidado
llevar a cabo la propuesta. organización cuál? La respuesta es que por lo
La corriente de flujo de efectivo término se general hay una gran diferencia en los costes e
refiere al conjunto de instancias de flujo de ingresos de los diferentes
efectivo con el tiempo que son causados por la
realización de alguna propuesta dada. El flujo de
caja es, en efecto, el cuadro financiero completo
de esa propuesta. ¿Cuánto dinero se apaga?
¿Cuándo se apaga? ¿Cuánto dinero entra?
¿Cuándo se presenta? Simplemente, si la
corriente de flujo de efectivo de Propuesta A es
más deseable que la corriente de flujo de caja
para la Propuesta B, entonces todas las demás
cosas son iguales, la organización es ter BET de
la realización de la propuesta A de la Propuesta
B. Por lo tanto, el flujo de efectivo stream es un
insumo importante para las decisiones de
inversión. Un ejemplo de flujo de efectivo es
una cantidad específica de dinero que fluye
hacia dentro o fuera de la organización en un
momento específico, como consecuencia directa
de alguna actividad.
Un diagrama de flujo de caja es una imagen de
una corriente de flujo de efectivo. Se le da al
lector una visión general de la situación
financiera de la organización tema o proyecto.
La figura 12.2 muestra un ejemplo de un
diagrama de flujo de caja para una propuesta.
1.5. Proceso de toma de decisiones

[1 *, c2,
c4]
Si asumimos que las soluciones candidatas a

resolver un problema técnico determinado
soluciones. A,, producto intermediario
comercial off-the-shelf objeto- petición puede
costar varios miles de dólares, pero el esfuerzo
para desarrollar un servicio de cosecha propia
que da la misma funcionalidad fácilmente
podría costar varios cientos de veces esa
cantidad.
Si las soluciones candidatas resolver todos
adecuadamente el problema desde un punto de
vista técnico, la selección de la alternativa más
adecuada debe basarse en factores comerciales
tales como la optimización de coste total de
propiedad (TCO) o maximizar el rendimiento a
corto plazo de la inversión (ROI) . los costos
del ciclo de vida tales como la corrección de
defectos, servicio de campo, y la duración de
apoyo son también consideraciones Evant rel.
Estos costos deben ser fac- reada en la hora de
elegir entre los enfoques Nical gías aceptables,
ya que son parte del retorno de la inversión de
por vida (ver sección 4.3, Retorno de la
Inversión).
Un proceso sistemático para la toma de
decisiones será lograr la transparencia y
permitir ción posterior justificación. criterios
de gobierno en muchas organizaciones exigen
la selección de al menos dos alternativas. Un
proceso sistemático se muestra en la figura
12.3. Se inicia con un desafío de negocios a la
mano y se describen los pasos para identificar
soluciones alternativas, definir los criterios de
selección, evaluar las soluciones,
implementar una solución seleccionada, y
monitor el desempeño de esa solución.
La figura 12.3 muestra el proceso como en
su mayoría paso- sabia y serie. El proceso real
es más fluido. A veces, los pasos se pueden
realizar en un orden diferente y con frecuencia
varios de los pasos se pueden realizar en
paralelo. Lo importante es estar seguro de que
Figura 12.3. El proceso de toma de decisiones de negocio básico
ninguno de los pasos se omiten o reducirse. 1.6. Valuació

También es importante entender que este mismo n [1 *, C5,
proceso se aplica a todos los niveles de toma de C8]
decisiones: de una
decisión tan grande como la determinación de si diversas interrelaciones, en un conjunto de
un proyecto de software se debe hacer en alternativas sive excluyen mutuamente. La
absoluto, a una decisión sobre una estructura de elección puede hacerse entonces entre estas
algoritmo o de datos a utilizar en un módulo de alternativas.
software. La diferencia es la forma
económicamente sig- sig- es la decisión y, por lo
tanto, la cantidad de esfuerzo debe ser invertido
en la toma de esa decisión. La decisión a nivel
de proyecto es económicamente sig- SIG-y
probablemente justifica un nivel relativamente
alto de esfuerzo para tomar la decisión. La
selección de un algoritmo es a menudo mucho
menos financieramente no puede signifi- y
garantiza un nivel mucho más bajo de lo posible
para tomar la decisión, a pesar de que el mismo
proceso de toma de decisiones básica está siendo
utilizado.
Más a menudo que no, una organización
puede llevar a cabo más de una propuesta si así
lo quisiera, y por lo general no son relaciones
importantes entre las propuestas. Tal vez
Propuesta Y sólo puede llevarse a cabo si la
propuesta X también se lleva a cabo. O tal vez
Propuesta P no puede llevarse a cabo si
Propuesta Q se lleva a cabo, ni podía Q llevarse
a cabo si P fuera. Las opciones son mucho más
fáciles de hacer cuando hay caminos -por
ejemplo que se excluyen mutuamente, ya sea A
o B o C o lo que sea que se elija. En decisiones
previas pelado, se recomienda convertir
cualquier conjunto de propuestas, junto con sus
12-8 Guía SWEBOK®
En un V3.0
sentido abstracto,el Cess -sea decisiones
financieras pro de toma de toma de decisiones
o de otro- se trata de maximizar el valor. La
alternativa que maximiza el valor total siempre
debe ser elegido. Una base financiera para la
comparación basada en valores se comparan
dos o más flujos de efectivo. Varias bases de
comparación están disponibles, incluyendo
• valor actual
• valor futuro
• anual equivalente
• tasa interna de retorno
• (Descuento) periodo de recuperación.
Basado en el tiempo-valor del dinero, dos o

más flujos de caja son equivalentes sólo
cuando son iguales a la misma cantidad de
dinero en un punto común en el tiempo. La
comparación de los flujos de caja sólo tiene
sentido cuando se expresan en el mismo
período de tiempo. Tenga en cuenta que el
valor no siempre se puede expresar en términos
de dinero. Por ejemplo, si un elemento es un
nombre de marca o no puedan alterar
significativamente su valor percibido. Los
valores relevantes que no se pueden expresar
en términos de dinero todavía tienen que ser
expresado en términos similares para que
puedan ser
evaluado objetivamente.
1.7. Inflació 1.10. Valor temporal del

n [1 *, dinero [1 *, c5,
c13] c11]
La inflación se describen las tendencias a largo utilidad bruta de una corporación. Un análisis de
plazo de los precios. La inflación significa que decisión que no tiene en cuenta los impuestos
las mismas cosas cuestan más que antes. Si el puede conducir a una mala elección. Una
horizonte de planificación de una decisión de propuesta con una alta ganancia antes de
negocios es más de unos pocos años, o si la tasa impuestos no se parecerá casi tan rentable en
de inflación es más de un par de puntos términos posttax. Sin tener en cuenta los
porcentuales por año, puede causar cambios impuestos también puede conducir a unre-
notables en el valor de una propuesta. Por lo alistically altas expectativas sobre la rentabilidad
tanto, el valor del tiempo actual necesita ser podría ser un producto propuesto.
ajustado por inflación y las tasas también para
las fluctuaciones del tipo de cambio.
1.8. Depreciación
[1 *, c14]
La depreciación implica la difusión del costo de

un activo tangible a través de una serie de
períodos de tiempo; que se utiliza para
determinar cómo las inversiones en activos
talized capi- se cargan contra los ingresos
durante varios años. La depreciación es una
parte importante de la determinación después de
impuestos de flujo de caja, que es criti- cal para
abordar con precisión los beneficios y los
impuestos. Si un producto de software se va a
vender después de que los costes de desarrollo
se incurren, los costos deben ser activadas y
depreciadas durante períodos de tiempo
posteriores. El gasto de depreciación para cada
período de tiempo es el costo capitalizado de
desarrollar el software dividida a través del
número de periodos en los que se venderá el
software. Una propuesta de proyecto de software
puede ser comparado con otro software y
propuestas nonsoftware o para opciones
alternativas de inversión, por lo que es
importante para determinar cómo esas otras
propuestas serían ciados depre- y cómo se
calcula ganancias.
1.9. Impuestos
[1 *, c16, c17]
Los gobiernos cobran impuestos para financiar

los gastos que la sociedad necesita, pero que
ninguna organiza- ción invertiría en. Las
empresas tienen que pagar impuestos sobre la
renta, que puede tomar una parte sustancial de la
Uno de los conceptos más fundamentales en
las finanzas y, por tanto, en los negocios
decisiones- es que el dinero tiene valor
temporal: su valor cambia con el tiempo. Una
cantidad específica de dinero en este momento
casi siempre tiene un valor diferente que la
misma cantidad de dinero en algún otro
momento. Este concepto ha estado presente
desde la historia humana registrada más
temprana y es comúnmente conocida como
valor tiempo-. Con el fin de comparar las
propuestas o elementos lio portfo-, deben ser
normalizados en el costo, valor, y el riesgo
para el valor actual neto. variaciones de cambio
de divisas a través del tiempo hay que tener en
cuenta sobre la base de los datos históricos.
Esto es Particularmente importante en la
evolución transfronteriza de todo tipo.
1.11. Eficiencia
[2 *, c1]
La eficiencia económica de un proceso,

actividad o tarea que es la relación entre los
recursos consumidos efectivamente a los
recursos previstos para ser consumidos o
deseado para ser consumidos en el
cumplimiento del proceso, actividad o tarea.
Eficiencia significa “hacer las cosas bien.” Un
comportamiento eficiente, como un
comportamiento efectivo, entrega resultados,
pero mantiene el esfuerzo necesario a un
mínimo. Los factores que pueden afectar la
eficiencia en ingeniería de software incluyen
dad producto complejidad, requisitos de
calidad, la presión del tiempo, la capacidad del
proceso, la distribución de equipo,
interrupciones, la rotación característica, las
herramientas y lenguaje de programación.
1.12. Eficacia
[2 *, c1]
La eficacia es acerca de tener impacto. Es la

relación entre los objetivos alcanzados a
objetivos definidos. Eficacia significa “hacer
las cosas bien.” La eficacia sólo se fija en si se
alcanzan los objetivos definidos, y no en la
forma en que se alcanzan.
1.13. Productividad
[2 *, c23]
La productividad es la relación de la salida sobre

la entrada de
una perspectiva económica. La salida es el valor
entregado. Entrada abarca todos los recursos desde la gestión de ellos individualmente.”2 Los
(por ejemplo, esfuerzo) pasaron a generar la programas se utilizan a menudo para identificar
salida. Productividad com- eficiencia y eficacia y gestionar las diferentes entregas a un solo
combina desde una perspectiva orientada de cliente o mercado en un horizonte de tiempo de
valor: la maximización de la productividad es varios años.
sobre la generación de mayor valor con menor
consumo de recursos. 2.4. portafolio
2. Ciclo de Vida Los portafolios son “proyectos, programas,

Economía subcarteras y operaciones gestionadas como un
grupo para alcanzar los objetivos estratégicos.” 3
2.1. Producto [2 *, c22] [3 *, carteras se utilizan para agrupar y gestionar
c6] simultáneamente todos los activos dentro de una
línea de negocio o de la organización. Mirando a
una
Un producto es un bien económico (o de salida) totalidad de la cartera se asegura de que los
que se crea en un proceso que transforma fac- impactos de las decisiones son consideradas,
tores de productos (o entradas) a una salida. tales como la asignación de recursos a un
Cuando se vende, un producto es un entregable proyecto específico, lo cual significa que los
que crea un valor y una experiencia para sus mismos recursos no están disponibles para otros
usuarios. Un producto puede ser una proyectos.
combinación de sistemas, soluciones, materiales,
y servicios entregados internamente (por 2.5. Ciclo de vida del producto
ejemplo, en casa de la solución IT) o [2 *, c2] [3 *, c2]
externamente (por ejemplo, software
aplicabilidad ción), ya sea tal cual o como un Un ciclo de vida del producto de software
componente para otro producto (por ejemplo, , (SPLC) incluye todas las actividades necesarias
software embebido). para definir, construir, operar, mantener y retirar
un producto de software o servicio y sus
2.2. Proyecto variantes. Las actividades de SPLC “oper-
[2 *, c22] [3 *, c1] comió”, “mantener” y “retirarse” suelen ocurrir
en un período de tiempo mucho más largo que el
Un proyecto es “un esfuerzo temporal desarrollo de software inicial (el software de
emprendido para crear un producto único, vida de desarrollo del ciclo de SDLC-ver els
servicio o resultado” .1 En la ingeniería de Software del ciclo de vida en el mo- Ingeniería
software, diferentes tipos de proyectos se de Software proceso KA). También las
distinguen (por ejemplo, el desarrollo de actividades de operación y mantenimiento-
productos, servicios externalizados, retirarse de un SPLC consumen típicamente más
mantenimiento de software, creación de esfuerzo total y otros recursos de las actividades
servicios, etc. ). Durante su ciclo de vida, un SDLC (ver La mayoría de los costos de
producto de software puede requerir muchos mantenimiento en el KA Mantenimiento de
proyectos. Por ejemplo, durante la fase de Software). El valor aportado por un producto de
concepción del producto, un proyecto podría software o servicios asociados puede
llevarse a cabo para determinar los requisitos de determinarse objetivamente durante el marco de
necesidad del cliente y del mercado; durante el “operar y mantener” tiempo. ingeniería de
mantenimiento, un proyecto podría llevarse a software Economics deben preocuparse por
cabo para producir una próxima versión de un todas las actividades SPLC, incluyendo las
producto. actividades después de la liberación inicial del
producto.
2.3. Programa
Un programa es “un grupo de proyectos relacionados, actividades del

subprogramas y programa
gestionado V3.0
de manera coordinada para obtener 2.6. Ciclo de Vida del
beneficios que no están disponibles Proyecto [2 *, c2] [3 *,
c2]
las actividades del ciclo de vida del proyecto
implican típicamente cinco grupos de iniciación
1 Project Management Institute, Inc., PMI Lexicon de procesos, planificación, Execut- ción,
seguimiento y control, y cierre [4]
del Proyecto Términos de gestión, 2012, www.pmi.org/
PMBOK-Guía-y-Normas / ~ / media / registro / 2 Ibídem.
PMI_Lexicon_Final.ashx. 3 Ibídem.
(Ver el KA Software Engineering Management). 2.9. Planeando el

Las actividades dentro de un ciclo de vida del horizonte [1 *,
proyecto de software a menudo se entrelazan, se c11]
superponen, y iterada
de diversas maneras [3 *, c2] [5] (ver el Proceso Cuando una organización decide invertir en una
de Ingeniería de Software KA). Por ejemplo, el propuesta cular par-, el dinero se hace atar en esa
desarrollo de productos ágil dentro de un SPLC propuesta, los llamados “activos congelados.” El
implica múltiples iteraciones que producen impacto económico de los bienes congelados
incrementos de software entregable. Un SPLC tiende a comenzar y disminuye con el tiempo.
debe incluir la gestión del riesgo y la Por otra parte, ING y mantenimiento operat-
sincronización con los proveedores diferentes costes de los elementos asociados con la
(si los hay), al tiempo que proporciona propuesta tienden a empezar con poco, pero
información audit- poder de toma de decisiones aumentará con el tiempo. El costo total de la
(por ejemplo, comply- ing con las necesidades propuesta, es decir, poseer y operar un producto
de responsabilidad por productos o las reglas de es la suma de estos dos costos. Al principio, los
gobierno). El ciclo de vida del proyecto de costos de los activos congelados dominan; más
software y el software de ciclo de vida del tarde, los costos de operación y mantenimiento
producto están relacionados entre sí; un SPLC dominan. Hay un punto en el tiempo que se
puede incluir varios SDLCs. minimiza la suma de los costos; esto se llama el
tiempo de vida de costo mínimo.
2.7. propuestas A comparar adecuadamente una propuesta con
[1 *, c3] una vida útil de cuatro años a una propuesta con
una vida útil de seis años, los efectos
De tomar una decisión de negocios comienza económicos de la propuesta, ya sea de corte de
con la noción de una propuesta. Propuestas se seis años por dos años o invertir los beneficios
refieren a alcanzar un objetivo de negocio, en el de la propuesta de cuatro años por otros dos años
proyecto, producto o nivel de cartera. Una deben abordarse. El horizonte de planificación, a
propuesta es una opción única, separada que se veces conocido como el período de estudio, es el
está considerando, como llevar a cabo un marco de tiempo constante durante los cuales se
proyecto de desarrollo de software en particular consideran propuestas. tendrán que tenerse en
o no. Otra propuesta podría ser para mejorar un cuenta en el establecimiento de un horizonte de
componente de software existentes, y todavía planificación efectos tales como el software vida
podría ser otra que volver a desarrollar mismo tiempo. Una vez establecido el horizonte de
software desde cero. Cada propuesta representa planificación, varias técnicas están disponibles
una unidad de elección, ya sea que usted puede para presentar propuestas de vida diferentes
elegir para llevar a cabo esa propuesta o puede períodos en que el horizonte de planificación.
optar por no hacerlo. Todo el propósito de la
toma de decisiones de negocio es averiguar, 2.10. Precio y precios
dadas las circunstancias actuales de negocios, [1 *, c13]
que las propuestas deben llevarse a cabo y
cuáles no.
2.8. Decisiones de Un precio es lo que se paga a cambio de un bien

inversión [1 *, o servicio. El precio es un aspecto fundamental
c4] de la modelización financiera y es una de las
cuatro P de la comercialización
Los inversores a tomar decisiones de inversión algunos criterios económicos, tales como el logro
para gastar dinero y recursos en la consecución de un alto retorno de la inversión, el
de un objetivo objetivo. Los inversores están fortalecimiento de las capacidades de la
ya sea en el interior (por ejemplo, las finanzas, la organización, o de mejorar el valor de la empresa.
placa) o fuera (por ejemplo, bancos) de la aspectos Intangi- bles tales como la buena
organización. El objetivo se relaciona con voluntad, la cultura y competencias deben ser
considerados. mezcla. Los otros tres son Sal producto,
promoción y lugar. El precio es el elemento
única generadora de ingresos entre las cuatro P;
el resto son costes.
El precio es un elemento de finanzas y
marketing. Es el proceso de determinar lo que es
una empresa recibirá a cambio de sus productos.
factores de fijación de precios incluyen el coste
de fabricación, colo- cación mercado, la
competencia, las condiciones del mercado, y la
calidad del producto. La fijación de precios se
aplica a los precios de productos y servicios
basados en factores tales como cantidad fija,
ruptura cantidad, promoción o campaña de
ventas,
cotización específica del proveedor, embarque o parámetros utilizados para determinar si los
factura fecha, combinación de varios pedidos, programas, inversiones y adquisiciones están
ofertas de servicios, y muchos otros. Las logrando los resultados deseados. Se utiliza para
necesidades del consumidor se pueden convertir evaluar si realmente se logran los objetivos de
en la demanda sólo si el consumidor tiene la rendimiento; para controlar los presupuestos, los
voluntad y la capacidad para comprar el pro- recursos, el progreso y las decisiones; y para
ducto. Por lo tanto, el precio es muy importante mejorar el rendimiento.
en la comercialización. La fijación de precios se
realiza inicialmente durante la fase ción 2.13. Gestion del valor ganado
iniciativa del proyecto y es una parte de la toma
de decisiones “ir”.
[3 *, c8]
2.11. Costo y costeo
[1 *, Gestión del Valor Ganado (EVM) es un proyecto
c15] técnica de gestión para medir el progreso
Un coste es el valor del dinero que se ha de decisiones económicas.
utilizado para producir algo y, por lo tanto, no
está disponible para su uso más. En economía, 2.12. Medición del desempeño
un coste es una alternativa que se da como [3 *, C7, C8]
resultado de una decisión.
Un costo hundido es los gastos antes de un La medición del desempeño es el proceso
cierto tiempo, normalmente se utiliza para mediante el cual una organización establece y
decisiones abstractas de los gastos en el pasado, mide la
lo que puede causar obstáculos emocionales en
el futuro. Desde un punto de vista económico
tradicional, los costos hundidos no deben ser
considerados en la toma de decisiones. El costo
de oportunidad es el costo de una alternativa que
debe ser ido lucro con el fin de seguir otra
alternativa.
Cálculo del coste forma parte de las finanzas y
management producto. Es el proceso para
determinar el costo basado en los gastos (por
ejemplo, producción, ingeniería de software,
distribución, retrabajo) y sobre el costo objetivo
de ser competitivos y exitosos en un mercado. El
costo de destino puede estar por debajo del costo
estimado real. La planificación y el control de
estos costos (llamada de gestión de costes) es
importante y siempre deben ser incluidos en los
costos.
Un concepto importante en el costeo es el
coste total de propiedad (TCO). Esto es válido
especialmente para el software, ya que hay
muchos costos no tan obvias relacionadas con
las actividades SPLC después del desarrollo de
producto inicial. TCO para un producto de
software se define como el costo total de la
adquisición, activar y mantener ese producto en
funcionamiento. Estos costos se pueden agrupar
como los costes directos e indirectos. TCO es un
método de contabilidad que es crucial en la toma
basado V3.0
en el valor creado. En un momento
dado, los resultados obtenidos hasta la fecha en
un proyecto se Comparado con el presupuesto
proyectado y el progreso calendario previsto
para esa fecha. El progreso se refiere recursos
consumidos ya-y ha logrado resultados en un
punto dado en el tiempo con los valores
planificados respectivos de la misma fecha.
Ayuda a identificar los posibles problemas de
rendimiento en una etapa temprana. Un
principio clave en EVM es el seguimiento de
las variaciones de costos y programas a través
de la comparación de horario programado
versus real y el presupuesto frente a los costos
reales. EVM da seguimiento mucho más
temprano vis bilidad a las desviaciones y por lo
tanto permite correcciones antes de lo clásico y
el costo de seguimiento horario que sólo se
basa en documentos y productos entregados.
2.14. Las decisiones de terminación

[1 *, c11, c12] [2 *,
c9]
El cese significa poner fin a un proyecto o

producto. La terminación puede ser planificada
de antemano para el final de un curso de la
vida del producto largo (por ejemplo, cuando
previendo que un producto alcanzará su vida) o
puede venir en lugar espontáneamente durante
el desarrollo de productos (por ejemplo,
cuando no se consiguen los objetivos de
rendimiento del proyecto). En ambos casos, la
decisión debe ser cuidadosamente preparado,
teniendo en cuenta siempre las alternativas de
continuidad versus terminación. Los costos de
las diferentes alternativas deben ser temas de
ING como el reemplazo, la información
lección COL-, los proveedores, las alternativas,
los activos y recursos de ING utiliz- para otras
oportunidades cubierta- estima. Los costos
hundidos no deben ser considerados en dicha
toma de decisiones, ya que se han gastado y no
Reap, pera como un valor.
Figura 12.4. Metas, estimaciones, y Planes
2.15. Las decisiones de reemplazo y jubilación en su mayoría los objetivos de negocio (u

[1 *, c12] [2 *, c9] objetivos de negocio).
Una decisión de reemplazo se hace cuando una

organiza- ción ya tiene un activo en particular y
que están considerando reemplazar con otra
cosa; por ejemplo, decidir entre el
mantenimiento de y apoyar un producto de
software heredado o volver a desarrollar desde el
principio. las decisiones de reemplazo utilizan el
mismo proceso de decisión de negocios como se
describió anteriormente, pero hay retos
adicionales: costo hundido y valor de rescate. las
decisiones de retiro son también de salir de una
actividad por completo, como cuando una
compañía de software no considera la venta de
un producto de software más o un fabricante de
hardware no considera la construcción y venta
de un determinado modelo de ordenador por más
tiempo. jubi- lación decisión puede estar
influenciada por factores lock-in, tales como la
dependencia de la tecnología y los altos costos
de salida.
3. Riesgo e Incertidumbre
3.1. Metas, estimaciones, y Planes

[3 *, c6]
Goles en la economía de ingeniería de software

son
Uno de los objetivos de negocio se relaciona
necesidades empresariales (como el aumento
de la rentabilidad) a los recursos de inversión
(tales como iniciar un proyecto o el
lanzamiento de un producto con un
presupuesto dado, contenido y el tiempo).
Objetivos se aplican a la planificación
operativa (por ejemplo, para llegar a un
determinado hito en una fecha determinada o
para ampliar las pruebas de software por un
cierto tiempo para lograr un nivel de calidad
deseado, ver cuestiones clave de la Prueba KA
Cesión de Software) y al nivel estratégico (
tales como alcanzar una cierta rentabilidad o
cuota de mercado en un período de tiempo
establecido).
Una estimación es una evaluación fundada
de recursos y el tiempo que se necesita para
lograr los objetivos planteados (ver Esfuerzo,
Calendario, y Estimación de Costos de la
Ingeniería de Software de Gestión de KA y
Estimación de Costos de Mantenimiento en el
KA Mantenimiento de Software). Una
estimación de software se utiliza para
determinar si los objetivos del proyecto se
puede lograr dentro de las restricciones sobre
los atributos programación, presupuesto,
características y calidad. Las estimaciones son
típicamente generados internamente y no son
necesariamente visibles externamente. Las
estimaciones no deben ser conducidos
exclusivamente por los objetivos del proyecto,
ya que esto podría hacer una estimación
excesivamente opti- mista. La estimación es
una actividad periódica; estimaciones deben
ser revisados continuamente durante un
proyecto.
Un plan describe las actividades e hitos que
son necesarias para alcanzar los objetivos de
un proyecto (véase el software de planificación 3.3. La incertidumbre

en el KA Software Engineering Management). abordar [3 *, c6]
El plan debe estar en consonancia con la meta y
la estimación
compañero, que no es necesariamente fácil y Debido a los muchos factores desconocidos
obvi- ous-por ejemplo, cuando un proyecto de durante la iniciación y planificación de
software con los requisitos dados tomaría más proyectos, las estimaciones son inciertas; que la
tiempo que la fecha límite prevista por el cliente. incertidumbre debe tratarse de decisiones de
En tales casos, los planes exigen una revisión de negocio. Las técnicas para hacer frente a la
los objetivos iniciales, así como Las incertidumbre incluyen
estimaciones y las incertidumbres subyacentes y
las inexactitudes. soluciones creativas con los • considerar rangos de estimaciones
fundamentos del sistema de alcanzar una • analizar la sensibilidad a los cambios de las
posición de ganar-ganar se aplican para resolver hipótesis
conflictos. • retrasar las decisiones finales.
A ser de valor, la planificación debe
involucrar consideración con- de las 3.4. priorización
restricciones del proyecto y los compromisos a [3 *, c6]
los interesados. La figura 12.4 muestra cómo se
definen inicialmente objetivos. Los cálculos se Priorización implica alternativas clasificación
realizan sobre la base de los objetivos iniciales. basada en criterios comunes para ofrecer el
El plan intenta hacer coincidir los objetivos y las mejor valor posible. En los proyectos de
estimaciones. Este es un proceso iterativo, ingeniería de software, requisitos de software a
debido a una estimación inicial normalmente no menudo se priorizan con el fin de ofrecer el
cumple con los objetivos iniciales. mayor valor al cliente dentro de straints con- de
programación, presupuesto, recursos y tecno-
3.2. Las técnicas de estimación logía, o para proporcionar para la construcción
[3 *, c6] de incrementos de productos, donde los primeros
incrementos proporcionar el mayor valor para el
Las estimaciones se utilizan para analizar y cliente (ver requisitos de clasificación y
prever los recursos o el tiempo necesarios para requisitos de la Negociación en los requisitos de
implementar los requisitos (ver Esfuerzo, software KA y del ciclo de vida del software los
Calendario, y Estimación de Costos de la modelos de la Ingeniería de procesos de
Ingeniería de Software de Gestión de KA y Software KA).
Estimación de Costos de Mantenimiento en el
KA Mantenimiento de Software). Existen cinco 3.5. Las decisiones en riesgo
familias de técnicas de estimación:
factores que causaron la propagación y luego
• Juicio experto volver a estimar de nuevo para producir
• Analogía resultados que convergen podría conducir a una
• Estimación por piezas mejor estimación.
• métodos paramétricos
• Métodos de estadística.
Sin sola técnica de estimación es perfecto, por

lo que el uso de la técnica de estimación
múltiple es útil. La convergencia entre las
estimaciones producidas por diferentes técnicas
indica que las estimaciones son probablemente
exacta. Difundir entre los compañeros
estimación indica que ciertos factores podrían
haber sido pasados por alto. La búsqueda de los
12-12 Guía SWEBOK® V3.0 [1 *, c24] [3 *,
c9]
Las decisiones técnicas de bajo riesgo se

utilizan cuando el tomador de decisiones puede
asignar probabilidades a los diferentes
resultados posibles (véase Gestión de Riesgos
en el KA Software Engineering Management).
Las técnicas específicas incluyen
• la toma de decisiones valor esperado

• varianza expectativa y la toma de decisiones
• El análisis de Monte Carlo
• árboles de decisión
• valor esperado de la información perfecta.
Figura 12.5. El proceso de toma de decisiones con fines de lucro
3.6. Las decisiones bajo incertidumbre 4. Métodos de análisis

[1 *, c25] [3 *, c9] económicos
Las decisiones bajo incertidumbre técnicas se 4.1. Con fines de lucro Análisis [1 *, c10]
utilizan cuando el tomador de decisiones no de Decisiones
puede asignar probabi-
vínculos con los diferentes resultados posibles Figura 12.5 se describe un procedimiento para la
porque la información necesaria no está identificación de la mejor alternativa de un
disponible (véase Gestión de Riesgos en el KA conjunto de alternativas sivos mutuamente
Software Engineering Management). Las exclusiones. Los criterios de decisión dependen
técnicas específicas incluyen de los objetivos de negocio y por lo general
incluyen retorno de la inversión (véase la
• Regla de Laplace sección 4.3, Retorno de la Inversión) o Retorno
• Regla Maximin sobre el capital empleado (ROCE) (ver sección
• Regla maximax 4.4, rendimiento del capital invertido).
• Regla Hurwicz Para fines de lucro técnicas de toma no se
• Regla arrepentimiento minimax. aplican a las organizaciones gubernamentales y
sin fines de lucro. En estos casos, las
organizaciones tienen diferentes objetivos, lo
que significa que se necesita un conjunto
diferente de las técnicas de toma, como el coste-
beneficio o el análisis coste-efectividad Ness.
4.2. Tasa de retorno mínima aceptable 4.5. Análisis coste-

[1 *, beneficio [1 *, c18]
c10]
La tasa mínima aceptable de rendimiento Análisis coste-beneficio es uno de los métodos

(TREMA) es la más baja tasa interna de retorno más utilizados para la evaluación de ALS
de la organiza- ción consideraría como una propues- individuales. Cualquier propuesta con
buena inversión. En términos generales, no sería una relación beneficio-costo de menos de 1,0 por
inteligente para invertir en una actividad con un lo general puede ser rechazada sin análisis
rendimiento del 10% cuando no hay otra adicional porque costaría más que el beneficio.
actividad que se sabe que devolver el 20%. La Las propuestas con una necesidad mayor
TREMA es una declaración de que una proporción de con- Sider el riesgo asociado de
organización confía en que puede lograr al una inversión y comparar los beneficios con la
menos que la tasa de rendimiento. La TREMA opción de invertir el dinero a una tasa de interés
representa el costo de oportunidad de la garantizada (ver sec- ción 4.2, aceptable tasa de
organización para las inversiones. Al elegir a retorno mínima).
invertir en algún tipo de actividad, la
organización está decidiendo explícitamente a 4.6. Análisis coste-efectividad
no invertir ese mismo dinero en otro lugar. Si la [1 *, c18]
organización es ya confía en que puede
conseguir un poco de velocidad conocida de Análisis coste-efectividad es similar al análisis
retorno, otras alternativas deben elegirse sólo si de coste-beneficio. Hay dos versiones de análisis
su tasa de rendimiento es al menos tan alto. Una coste-eficacia: la versión de costos fijos
manera sencilla para dar cuenta de que el coste maximiza el beneficio dado alguna cota superior
de oportunidad es utilizar la TREMA como la en el precio; la versión de la eficacia fijo
tasa de interés en las decisiones empresariales. minimiza el costo necesario para lograr un
valor actual de una alternativa evaluada en la objetivo fijo.
TREMA muestra cuánto más o menos (en
términos de caja actuales) que vale la pena 4.7. Punto de equilibrio de analisis
alternativa es que la inversión en el Marr.
[1 *, c19]
4.3. Retorno de la
Inversión [1 *, análisis de equilibrio identifica el punto donde
c10] los costos de desarrollo de un producto y los
ingresos
Retorno de la inversión (ROI) es una medida de a generarse son iguales. Tal análisis se puede
la rentabilidad de una empresa o unidad de utilizar para elegir entre diferentes propuestas a
negocio. Se define como la relación entre el diferentes costos estimados y los ingresos.
dinero ganado o perdido (realizadas o no estimación dada acoplado costes e ingresos de
realizadas) en una inversión con respecto a la dos o más ALS propues-, análisis de equilibrio
cantidad de dinero invertido. El propósito de ayuda a la hora de elegir entre ellos.
retorno de la inversión varía e incluye, por
ejemplo, proporcionando una base para futuras 4.8. Business Case
inversiones y decisiones de adquisición.
describe el rendimiento del capital utilizado.
4.4. Rendimiento del capital invertido
El retorno sobre el capital empleado (ROCE) es

un seguro de medi- de la rentabilidad de una
unidad de empresa o negocio. Se define como la
relación de un beneficio bruto antes de
impuestos e intereses (EBIT) para el total de
activos menos pasivos corrientes. En él se
[1 *, c3] Software Economía Ingeniería 12-15
El modelo de negocio es la información

consolidada resumir y explicar una propuesta
de negocio desde diferentes perspectivas para
un tomador de decisiones (costo, beneficios,
riesgos, y así sucesivamente). A menudo se
utiliza para evaluar el valor potencial de un
producto, que puede ser utilizado como base en
la inversión proceso de decisión. A diferencia
de un simple cálculo de la pérdida de
utilidades, el modelo de negocio es un “caso”
de los planes y análisis que es propiedad del
producto
gerente y utilizada en apoyo de la consecución estudio de una función de coste en un rango de

de los objetivos de negocio. valores para
4.9. Evaluación Atributo múltiple

[1 *, c26]
Los temas tratados hasta ahora se utilizan para

hacer las decisiones sobre la base de un único
criterio de decisión: el dinero. La alternativa con
el mejor valor actual, la mejor ROI, y así
sucesivamente es la seleccionada. Aparte de
viabilidad técnica, el dinero es casi siempre el
criterio de decisión más importante, pero no es
siempre el único. Muy a menudo hay otros
criterios, otros “atributos”, que deben tenerse en
cuenta, y esos atributos no se pueden colar en
términos de dinero. de toma de atributos
múltiples técnicas permiten otros criterios no
financieros, que sean fac- reada en la decisión.
Hay dos familias de múltiples técnicas de
toma de atributos que difieren en cómo utilizan
los atributos en la decisión. Una familia es la
“compensación”, o, técnicas-dimensionada
individuales. Esta familia se derrumba todos los
atributos en un único factor de mérito. La
familia está llamada compensatoria, ya que, para
cualquier alternativa dada, una puntuación más
baja en un atributo puede ser compensada por-o-
objeto de comercio frente una puntuación más
alta en otros atributos. Las técnicas de
compensación incluyen
• escala adimensional
• de ponderación aditiva
• proceso analítico jerárquico.
Por el contrario, la otra familia es la

“compensatorio no transmisibles”, o totalmente
dimensionada, técnicas. Esta familia no permite
concesiones entre los atributos. Cada atributo es
tratada como una entidad separada en el proceso
de decisión. Las técnicas tory noncompensa-
incluyen
• dominio
• satisficing
• lexicografía.
4.10. Análisis de optimización

[1 *, c20]
El uso típico de análisis de optimización es el

encontrar el punto en el rendimiento general es insuficiente calidad oSoftware
cantidadEconomía Ingeniería
insuficiente no es12-17
mejor. clásica disyuntiva espacio-tiempo de lo suficientemente bueno.

software es un ejemplo de optimización; un Los métodos ágiles son ejemplos de
algoritmo que se ejecuta más rápido con “suficientemente bueno” que tratan de optimizar
frecuencia utiliza más memoria. Optimización el valor mediante la reducción de la cabeza
equilibra el valor del tiempo de ejecución más excesiva de retrabajo retrasado y el chapado de
rápida contra el costo de la memoria adicional. oro que
El análisis de opciones reales se puede usar
para cuantificar el valor de opciones de
proyectos, incluyendo el valor de retrasar una
decisión. Estas opciones son difíciles de
calcular con precisión. Sin embargo, la
conciencia de que las opciones tienen un valor
monetario proporciona la penetración en el
calendario de las decisiones tales como el
personal del proyecto ING increas- o alargando
el tiempo de comercialización para mejorar la
calidad.
5.1. El “suficientemente bueno” Principio

[1 *, c21]
A menudo los proyectos de ingeniería de

software y productos no son precisos acerca de
los objetivos que deben alcanzarse. Requisitos
de software se expresan, pero el valor marginal
de agregar un poco más de funcionalidad no
se pueden medir. El resultado podría ser la
entrega tarde o demasiado-alto costo. El
“suficientemente bueno” principio se relaciona
valor marginal al coste marginal y proporciona
orientación para determinar los criterios
cuando un entregable es “suficientemente
bueno” para ser entregados. Estos criterios
dependen de los objetivos del negocio y en la
priorización de las distintas alternativas, tales
como la clasificación de los requisitos de
software, atributos medibles calidad, o
relativas a la programación contenido y coste
del producto.
El principio RACE (reducir los accidentes y
la esencia de control) es un gobierno popular
hacia un buen software suficiente. Los
accidentes implican gastos generales
innecesarios tales como la sobrerregulación y
retrabajo debido a la eliminación de defectos
tarde o demasiado muchos cambios requisitos.
Esencia es lo que pagan los clientes por. Soft-
economía de ingeniería cerámica ofrece los
mecanismos para definir los criterios que
determinan cuándo un entregable es
“suficientemente bueno” para ser entregados.
También destaca que ambas palabras son
relevantes: “suficiente” “bueno” y la
resulta de la adición de características que tienen Un ecosistema es un entorno compuesto por todas
valor marginales bajos para los usuarios (ver las partes mutuamente dependientes, unidades de
Métodos ágiles en los modelos de ingeniería de negocio y empresas que trabajan en un área
software y métodos KA y Vida Software particular.
Modelos de Ciclo de la Ingeniería de Procesos
de Software KA). En ods met ágiles,
planificación detallada y las largas fases de
desarrollo se sustituyen por la planificación
incrementales y entrega frecuente de pequeños
incrementos de un producto erable deliv- que se
prueba y evaluadas por representantes de los
usuarios.
5.2. Economía-Friction Free
la fricción económica es todo lo que mantiene

mercados de tener la competencia perfecta. Se
trata de distancia, el costo de la entrega, las
regulaciones restrictivas, y / o información
imperfecta. En los mercados de alta fricción, los
clientes no tienen muchos proveedores entre los
que elegir. Después de haber sido en un negocio
por un tiempo o ser propietario de una tienda en
una buena ubicación determina la posición
económica. Es difícil para los nuevos
competidores para iniciar negocios y competir.
El mercado se mueve lentamente y de manera
previsible. mercados libres de fricción son justo
lo contrario. Surgen nuevos competidores y los
clientes son rápidos en responder. El mercado es
cualquier cosa menos capaces predecible. En
teoría, el software y TI son rozamientos. Las
nuevas empresas pueden crear fácilmente los
productos y a menudo lo hacen a un costo
mucho más bajo que blecimientos empresas
cado, ya que no tendrá que considerar cualquier
legado. Marketing y ventas se pueden hacer a
través de Internet y las redes sociales, y los
mecanismos de distribución bási- camente libres
pueden permitir una rampa hasta un negocio
global. Software Engineer- economía ing tiene
como objetivo proporcionar bases para juzgar
cómo un negocio de software lleva a cabo y
cómo libre de fricción un mercado que
realmente es. Por ejemplo, la competencia entre
los desarrolladores de aplicaciones de software
se inhibe cuando las aplicaciones deben ser
vendidos a través de una tienda de aplicaciones
y cumplen con las normas de esa tienda.
5.3. ecosistemas
En un ecosistema típico, hay productores y
consumidores, en los que los consumidores
agregan valor a los recursos consumidos.
Tenga en cuenta que un consumidor no es el
usuario final, sino una organización que utiliza
el producto para mejorarla. Un ecosistema de
software es, por ejemplo, un proveedor de una
aplicación trabajando con las empresas que
hacen la instalación y el puerto SUP- en
diferentes regiones. Ninguno de los dos puede
existir sin el otro. Los ecosistemas pueden ser
permanentes o temporales. la economía de
ingeniería de software proporciona los
mecanismos para evaluar alternativas en el
establecimiento o la ampliación de una
instancia ecosistema para, evaluar si trabajar
con un distribuidor espe- CIFIC o tiene la
distribución realizada por una empresa que
realiza el servicio en un área.
5.4. La deslocalización y la externalización
La deslocalización significa la ejecución de

una actividad de negocio más allá de ventas y
comercialización fuera del país de origen de
una empresa. Las empresas típicamente tienen
sus ramas de deslocalización en países de bajos
costes o que piden las empresas especializadas
en el extranjero para ejecutar la actividad
respectiva. ING Offshor- tanto, no debe
confundirse con la externalización. La
deslocalización dentro de una empresa se llama
deslocalización cautiva. La subcontratación es
la relación entados resultado-ori- con un
proveedor que ejecuta actividades de negocio
para una empresa cuando, tradicionalmente,
esas actividades fueron ejecutadas dentro de la
empresa. La externalización es un sitio
independiente. El proveedor puede residir en la
vecindad de la empresa o en alta mar
(subcontratado offshoring). la economía de
ingeniería de software proporciona los criterios
básicos y herramientas de negocio para evaluar
diferentes mecanismos de aprovisionamiento y
controlar su rendimiento. Por ejemplo, el uso
de un proveedor de externalización de
desarrollo de software y el mantenimiento
podría reducir el coste por hora de desarrollo
de software, pero aumentar el número de horas
y los gastos de capital debido a una mayor
necesidad de seguimiento y comunicación.
(Para más infor- mación sobre la
deslocalización y la externalización, consulte
“externalización” en cuestiones de gestión en
el mantenimiento del software KA).
2011 [2 *]
2009 [3
JustaLey de
točkey 2005
SommervilLe
[1 *]
*]
1. Fundamentos de Ingeniería de
Software Economía
1.1. Financiar c2
1.2. Contabilidad c15
1.3. Controlador c15
1.4. Flujo de fondos c3
1.5. Proceso de toma de decisiones c2, c4
1.6. Valuación C5, C8
1.7. Inflación c13
1.8. Depreciación c14
1.9. Impuestos c16, c17
1.10. Valor temporal del dinero C5, C11
1.11. Eficiencia c1
1.12. Eficacia c1
1.13. Productividad c23
2. La vida de ciclo Economía
2.1. Producto c22 c6
2.2. Proyecto c22 c1
2.3. Programa
2.4. portafolio
2.5. Ciclo de vida del producto c2 c2
2.6. Ciclo de Vida del Proyecto c2 c2
2.7. propuestas c3
2.8. Decisiones de inversión c4
2.9. Planeando el horizonte c11
2.10. Precio y precios c13
2.11. Costo y costeo c15
2.12. Medición del desempeño C7,
2.13. Gestion del valor ganado C8
c8
2.14. Las decisiones de terminación c11, c12 C9
2.15. Las decisiones de reemplazo y jubilación c12 C9
2011 [2 *]
2009 [3
JustaLey de
točkey 2005
SommervilLe
[1 *]
*]
3. Riesgo e Incertidumbre
3.1. Metas, estimaciones, y Planes c6
3.2. Las técnicas de estimación c6
3.3. La incertidumbre abordar c6
3.4. priorización c6
3.5. Las decisiones en riesgo c24 C9
3.6. Las decisiones bajo incertidumbre c25 C9
4. Métodos de Análisis Económico
4.1. Con fines de lucro Análisis de Decisiones c10
4.2. Tasa de retorno mínima aceptable c10
4.3. Retorno de la Inversión c10
4.4. Rendimiento del capital invertido
4.5. Análisis coste-beneficio c18
4.6. Análisis coste-efectividad c18
4.7. Punto de equilibrio de analisis c19
4.8. Business Case c3
4.9. Evaluación Atributo múltiple c26
4.10. Análisis de optimización c20
5.1. El “suficientemente bueno” Principio c21
5.2. Economía-Friction Free
5.3. ecosistemas
5.4. La deslocalización y la externalización
LECTURAS de un caso Ness Busi- en el software y las

empresas. Muchos ejemplos útiles ilustran cómo
Una guía para la Dirección de Proyectos (Guía el caso de negocio se formula y se cuantificó.
del PMBOK®) [4].
La Guía PMBOK ® proporciona directrices para

la gestión de proyectos individuales y define
conceptos relacionados con la gestión de
proyectos. También describe el ciclo de vida de
gestión de proyectos y sus procesos
relacionados, así como el ciclo de vida del
proyecto. Es una guía reconocida a nivel
mundial para la profesión agement el proyecto
hombre-.
Software de la extensión a la Guía de los

Fundamentos de la Dirección de Proyectos
(SWX) [5].
SWX proporciona adaptaciones y ampliaciones

de las prácticas genéricas de gestión de
proyectos documentado en la Guía PMBOK ®
para la gestión de proyectos de software. La
principal contribución de esta extensión de la
Guía del PMBOK® es descrip- ción de los
procesos que son aplicables para la gestión de
proyectos de software de ciclo de vida de
adaptación.
BW Boehm, Software Economía Ingeniería

[6].
Este libro es la lectura clásica en la economía de

ingeniería de software. Proporciona una visión
general del pensamiento empresarial en
ingeniería de software. Aunque los ejemplos y
figuras son anticuadas, todavía vale la pena leer.
C. Ebert y R. Dumke, Medición Software

[7].
Este libro ofrece una visión general sobre los

métodos cuantitativas en la ingeniería de
software, comenzando con la teoría de la
medición y procediendo a la gestión del
rendimiento y la toma de decisiones
empresariales.
DJ Reifer, Haciendo el caso Business Software:

Mejora por los números [8].
Este libro es una lectura clásica en la fabricación

Referencias
[1 *] S. Tockey, Retorno de software:

maximizar el retorno de su inversión en
[2 *] JH Allen et al, software de

seguridad Ingeniería:. Guía para
los gerentes de proyecto,

de software, Wiley-IEEE Computer Society
Press, 2009.
[4] Project Management Institute, Guía para

la Dirección de Proyectos del
Conocimiento (PMBOK (R) Guía), 5ª
ed., Project Management Institute,
2013.

quinta edición, ed: Project Management
Institute, 2013.
[6] BW Boehm, Software Economía

Ingeniería, Prentice-Hall, 1981.
[7] C. y R. Ebert Dumke, software de

medición, Springer, 2007.
[8] DJ Reifer, Haciendo el caso Business

Software: Mejora de los números,
Addison Wesley, 2002.
CAPÍTULO 13
FUNDAMENTOS DE
INFORMATICA
SIGLAS
AOP Programación Orientada a Aspectos SCSI Small Computer System Interface

ALU Unidad aritmética lógica SQL lenguaje de consulta estructurado
de programación de aplicaciones TCP Protocolo de control de transporte
API
Interfaz UDP User Datagram Protocol
Cajero Modo de Transferencia Asíncrona VPN Red Privada Virtual
automátic
B/S Navegador-Servidor PÁLIDO Red de área amplia
o
Equipo de Respuesta a Emergencias
CERT
Informáticas
COTS Commercial Off-The-Shelf INTRODUCCIÓN
CRUD Crear, leer, actualizar, eliminar
El alcance de los Fundamentos Informática
C/S Servidor de cliente knowl- área de borde (KA) abarca el desarrollo y
CS Ciencias de la Computación el medio ambiente operacional en el que
DBMS Sistema de administración de base evoluciona de software y se ejecuta. Debido a
de datos que ningún software puede existir en un vacío o
FPU Flotar unidad de coma
correr sin un ordenador, el núcleo de un entorno
I/O Entrada y salida de este tipo es el ordenador y sus diversos
ES UN Set de instrucciones arquitectura componentes. El conocimiento acerca de la
Organización Internacional para las computadora y sus principios subyacentes de las
ISO mercancías de hardware y software sirve como
Normalización
un marco en el que se ancla la ingeniería de
ISP Proveedor de servicios de Internet
software. Por lo tanto, todos los ingenieros de
LAN Red de área local software deben tener una buena comprensión de
MUX multiplexor los ing Fundamentos de Informática KA.
NIC Tarjeta de interfaz de red En general se acepta que el software de inge-
niería se acumula en la parte superior de la
POO Programación orientada a objetos
informática. Por ejemplo, “Ingeniería de
OS Sistema operativo Software 2004: Directrices riculum mentos para
OSI Sistemas abiertos de interconexión los programas de licenciatura en Ingeniería de
ordenado Computadora personal Software” [1] establece claramente, “Un aspecto
rPDA
personal Asistente personal digital particularmente importante es que la ingeniería
de software se basa en la informática y las
PPP Punto-a-Punto Protocolo matemáticas” (la cursiva es nuestra).
RFID Identificación de frecuencia de radio Steve Tockey escribió en su libro Retorno de
RAM Memoria de acceso aleatorio software:
ROM Memoria de sólo lectura
Tanto la informática y el software de

inge- niería acuerdo con ordenadores,
computación y software. La ciencia de la
computación, como un conjunto de
conocimientos, está en el centro de
ambos.
13-1
Figura 13.1. Desglose de los temas de los Fundamentos de Informática KA
... Ingeniería de software se ocupa de la de los temas que de otra forma estarían cubiertos
aplicación de las computadoras, en un curso de informática no están cubiertos en
computación y software para propósitos este
prácticos, específica- mente el diseño, la
construcción y funcionamiento de los
sistemas de software eficientes y
económicos.
Por lo tanto, en el centro de ingeniería de

software es una comprensión de la informática.
Aunque pocas personas negarán las obras de
informática papel en el desarrollo de la
ingeniería de software, tanto como disciplina y
como un conjunto de conocimientos, la
importancia de la informática a la ingeniería de
software no puede ser demasiado hincapié
tamaño; Por lo tanto, esta Fundamentos de
Informática KA está siendo escrito.
La mayoría de los temas tratados en los
Fundamentos Com- Puting KA también son
temas de dis- cusión en los cursos básicos que
figuran en los programas de grado y posgrado de
la informática. Dichos cursos incluyen la
programación, estructura de datos, algoritmos,
organización de computadores, sistemas
operativos, compiladores, bases de datos, redes,
sistemas de distribuido, y así sucesivamente.
Por lo tanto, cuando Break-ing por temas, puede
ser tentador para descomponer el Fundamentos
de Informática KA acuerdo con estas divisiones
a menudo se encuentran en-cursos pertinentes.
Sin embargo, una división basada curso de
temas puramente sufre graves inconvenientes.
Por un lado, no todos los cursos de informática
están relacionados o igualmente importante para
la ingeniería de software. Por lo tanto, algunos
KA. Por ejemplo, los gráficos de ordenador, 13-3
mientras que un curso importante en un
programa de grado de la informática, no está
incluido en este KA.
En segundo lugar, algunos de los temas
tratados en esta línea guía- no existen como
cursos independientes de programas
informáticos graduados o graduados
insuficientemente. Por consiguiente, tales
temas pueden no estar cubiertos
adecuadamente en un desglose basado curso-
puramente. Por ejemplo, la abstracción es un
tema incorporado en varios cursos de
informática diferentes; no está claro qué
abstracción curso deben pertenecer a una
avería basada en el transcurso de los temas.
Los fundamentos de computación KA se
divide en diecisiete temas diferentes. Ness útil-
directa de un tema a los ingenieros de software
es el criterio utilizado para la selección de
temas para su inclusión en este KA (véase la
figura 13.1). La ventaja de esta distribución
basada en el tema es su fundamento en la
creencia de que si daciones-Computing Fun- es
para ser agarrado firmemente-deben conside-
rarse como una colección de temas
relacionados lógicamente ciñendo la ingeniería
de software en la construcción general y el
software, en particular .
Los fundamentos de computación KA se
relaciona estrechamente con el Diseño de
Software, Software Con- trucción, pruebas de
software, software Principal- manteni-, Calidad
de Software y fundaciones KAs matemáticas.
DISTRIBUCIÓN DE TEMAS PARA

FUNDAMENTOS DE INFORMATICA
El desglose de los temas para la Informática

Fundamentos KA se muestra en la figura 13.1.
1. Técnicas de resolución de problemas para ayudar a uno formular el problema real

[2 *, S3.2, c4] [3 *, incluyen la declaración-reexpresión, determinar el
c5] origen y la causa, la revisión de la declaración,
analizando el estado actual y el deseado, y
La conceptos, nociones y terminología utilizando el enfoque del ojo fresco.
introducida aquí forman una base subyacente
para la comprensión de la función y el alcance
de las técnicas de resolución de problemas.
1.1. Definición de la resolución de problemas
La resolución de problemas se refiere a los lazos

de pensamiento y activi- realizados para
responder o derivar una solución a un problema.
Hay muchas maneras de abordar un problema, y
cada camino emplea diferentes herramientas y
utiliza procesos diferentes. Estas diferentes
formas de abordar los problemas se expanden
gradualmente y definen a sí mismos y,
finalmente, dan lugar a diferentes disciplinas.
Por ejemplo, el software de inge- niería se centra
en la resolución de problemas utilizando com-
putadoras y software.
Si bien los distintos problemas garantizan
soluciones diferentes y pueden requerir
diferentes herramientas y procesos, la
metodología y las técnicas utilizadas en la
solución de problemas hacen seguir algunas
directrices y, a menudo se pueden generalizar
como las técnicas de resolución de problemas.
Por ejemplo, una pauta general para la
resolución de un problema de ingeniería
genérica es utilizar el proceso de tres pasos dada
a continuación [2 *].
• Formular el problema real.

• Analizar el problema.
• Diseñar una estrategia de búsqueda de
solución.
1.2. Formular el problema real
Gerard Voland escribe: “Es importante

reconocer que un problema específico debe ser
formulada si uno va a desarrollar una solución
específica” [2 *]. Esta formulación se llama el
planteamiento del problema, que especifica
explícitamente lo tanto el problema y el
resultado deseado son.
Aunque no hay forma universal de stat- ing un
problema, en general, un problema debe
expresarse de tal manera que se facilite el desa-
rrollo de soluciones. Algunas técnicas generales
1.3. Analizar el problema 13-5resolver un problema
La primera tarea de
Una vez que el planteamiento del problema se utilizando una computadora es determinar qué
encuentra disponible, el siguiente paso es decirle a la computadora para hacer. Puede
analizar el planteamiento del problema o la haber muchas maneras de contar la historia, pero
situa- ción para ayudar a estructurar nuestra todos deben tener la perspectiva de una
búsqueda de una solución. Cuatro tipos de computadora tales
análisis incluyen análisis de la situación, en la
que se identifican primero los aspectos más
urgentes o críticos de una situación; análisis de
problemas, en el que la causa del problema
debe ser extraído deter-; análisis de decisión,
en el que necesita la acción (s) para corregir el
problema o eliminar su causa se debe
determinar; y análisis problema potencial, en el
que necesita la acción (s) para prevenir
cualquier recurrencia del problema o el desa-
rrollo de nuevos problemas debe ser
determinado.
1.4. Diseñar una estrategia de búsqueda de

soluciones
Una vez que el análisis de los problemas es

completa, podemos centrarnos en la
estructuración de una estrategia de búsqueda
para encontrar la solución. Con el fin de
encontrar la “mejor” solución (en este caso,
“mejor” puede significar cosas diferentes para
personas diferentes, tales como rápido, más
barato, más usables diferentes capacidades,
etc.), necesitamos eliminar caminos que no
conducen a soluciones viables, las tareas de
diseño de una manera que proporciona la
mayor orientación en la búsqueda de una
solución, y utilizan diversos atributos del
estado de solución final para guiar nuestras
decisiones en el proceso de resolución de
problemas.
1.5. La resolución de problemas Utilización de

programas
La singularidad de los programas informáticos

da la resolución de problemas un sabor que es
distinta de la ingeniería general, la resolución
de problemas. Para resolver un problema
utilizando las computadoras, hay que responder
a las siguientes preguntas.
• ¿Cómo podemos averiguar qué decirle al

ordenador a hacer?
• ¿Cómo podemos convertir el
planteamiento del problema en un
algoritmo?
• ¿Cómo podemos convertir el algoritmo en
instrucciones de máquina?
de que el equipo con el tiempo puede resolver el generalización mediante la reducción de la

problema. En general, un problema debe información de un concepto, un problema o un
expresarse de tal manera que se facilite el fenómeno observable de manera que uno puede
desarrollo de algoritmos y estructuras de datos centrarse en el “cuadro grande”. Una de las
para resolverlo. habilidades más importantes en cualquier empresa
El resultado de la primera tarea es ment un de ingeniería que se enmarca la niveles de
problema por el estado. El siguiente paso es abstracción adecuadamente.
convertir el problema ción estatal en los
algoritmos que resuelven el problema. Una vez
que se encuentra un algoritmo, el paso final
convierte el algoritmo en instrucciones de
máquina que forman la solución final: software
que resuelve el problema.
Hablando en abstracto, la resolución de
problemas utilizando un ordenador puede ser
considerado como un proceso de transformación
problema, en otras palabras, la etapa de
transformación a paso de un planteamiento del
problema en una solución de un problema. Para
la disciplina de la ingeniería de software, el
objetivo último de la resolución de problemas es
transformar un problema expresado en lenguaje
natural en electrones que se ejecutan en un
circuito. En general, esta transformación se
puede dividir en tres fases:
a) Desarrollo de algoritmos de la declaración

problema.
b) La aplicación de algoritmos para el
problema.
c) Transformación de algoritmos para el
código del programa.
La conversión de un planteamiento del

problema en los algoritmos y algoritmos en
códigos de programa generalmente sigue un
“refinamiento paso a paso” (descomposición aka
sistemática) en el que empezamos con un
planteamiento del problema, reescribir como una
tarea, y de forma recursiva descomponer la tarea
en unos sub-tareas más simples hasta que la
tarea es tan sencilla que las soluciones a que son
sencillas. Hay tres formas básicas de
descomposición: secuenciales, condicionales, e
iterativos.
2. Abstracción
[3 *, s5.2-5.4]
La abstracción es una técnica indispensable

asociados con la resolución de problemas. Se
refiere tanto al proceso y el resultado de la
“A través de la abstracción”, según Voland, problema y la solución de Fundamentos
formulaciónde computación
ción,
13-7
“vemos el problema y sus posibles vías de podemos utilizar diferentes abstracciones
solución a partir de un mayor nivel de
comprensión conceptual. Como resultado,
podemos llegar a ser mejores pre recortaron
para reconocer posibles relaciones entre los
diferentes aspectos del problema y de ese
modo erate ge- soluciones de diseño más
creativas”[2 *]. Esto es particularmente cierto
en informática en general (tales como hardware
vs software) y en ingeniería de software en
particular (estructura de datos vs flujo de datos,
y así sucesivamente).
2.1. Los niveles de abstracción
Cuando la abstracción, nos concentramos en un

“nivel” de la gran imagen a la vez con la
confianza de que podemos conectar
eficazmente con niveles por encima y por
debajo. Aunque nos centramos en una sola
planta, abstracción no significa saber nada
acerca de los niveles vecinos. niveles de
abstracción no necesariamente corresponden a
componentes discretos en la realidad o en el
dominio del problema, pero para bien definido
de interfaces estándar como API de
programación. Las ventajas que proporcionan
interfaces estándar incluyen la portabilidad, el
software más fácil / integración de hardware y
utensilios de uso más amplio.
2.2. La encapsulación
La encapsulación es un mecanismo utilizado

para implementar la abstracción ción. Cuando
se trata de un nivel de abstracción, la
información relativa a los niveles por debajo y
por encima de ese nivel se lated encapsulada.
Esta información puede ser el concepto,
problema, o fenómeno observable; o puede
ser las operaciones permitidas en estas
entidades pertinentes. La encapsulación por lo
general viene con un cierto grado de ocultación
de información en los que algunos o todos los
detalles subyacentes están ocultas desde el
nivel por encima de la interfaz proporcionada
por la abstracción. A un objeto, la ocultación
de información significa que no necesitamos
conocer los detalles de cómo el objeto es repre-
sentadas o cómo se implementan las
operaciones sobre dichos objetos.
2.3. Jerarquía
Cuando usamos la abstracción en nuestro

en diferentes momentos, en otras palabras, se [3 *, C6-19]

trabaja en diferentes niveles de abstracción
como la situación lo requiere. La mayoría de las La programación se compone de las metodologías
veces, estos diferentes niveles de abstracción se o actividades para la creación de programas
organizan en una jerarquía. Hay muchas informáticos que
maneras de estructurar una jerarquía particular y
los criterios utilizados para determinar el
contenido específico de cada capa en la jerarquía
varía dependiendo de los individuos que realizan
el trabajo.
A veces, una jerarquía de abstracción es
secuencial, lo que significa que cada capa tiene
una y sólo una predecesor capa (inferior) y uno y
sólo un sucesor (superior) capa excepto la capa
upmost (que no tiene un sucesor) y la capa más
inferior ( que no tiene predecesor). A veces, sin
embargo, la jerarquía está organizada en una
estructura de árbol, lo que significa que cada
capa puede tener más de una capa predecesor,
pero sólo una capa sucesor. Ocasionalmente, una
jerarquía puede tener un muchos- estructura a
varios, en el que cada capa puede tener múltiples
predecesores y sucesores. En ningún momento,
habrá ninguna bucle en una jerarquía.
Una jerarquía a menudo forma natural en la
posición tarea descomposición. A menudo, un
análisis de tareas se puede descomponer de
forma jerárquica, empezando por las tareas y
objetivos de la organización más grande y
romper cada uno de ellos hacia abajo en
subtareas más pequeñas que una vez más se
pueden subdividir Esta divi- sión continua de
tareas en otros más pequeños produciría una
estructura jerárquica de las tareas de subtareas.
2.4. Las abstracciones alternativos
A veces es útil tener múltiples abstracciones

alternativas para el mismo problema, de modo
que uno puede mantener diferentes perspectivas
en mente. Por ejemplo, podemos tener un
diagrama de clases, una tabla de estado, y un
diagrama de secuencia para el mismo software
en el mismo nivel de abstracción. Estas
abstracciones alternativas no forman una
jerarquía, sino que se complementan entre sí
para ayudar a la comprensión del problema y su
solución. Aunque beneficiosos, es como tiempos
difíciles para mantener abstracciones
alternativas en sincronía.
3. Fundamentos de programación
estructurado
realizar una función deseada. Es una parte 13-9
indispensable en la construcción de software. programación, programador sigue a su / su
En general, programa- ción puede considerarse
como el proceso de diseñar, escribir, probar,
depurar y man- TaiNing el código fuente. Este
código fuente es escriben normalmente con un
lenguaje de programación.
El proceso de escribir código fuente a
menudo requiere experiencia en muchas áreas,
incluyendo sujetos diferentes conocimientos
del dominio de aplicación, estructuras de datos
apropiadas, algoritmos izadas especial-, varias
construcciones del lenguaje, buenas técnicas de
programación, e ingeniería de software.
3.1. El proceso de programación
La programación implica el diseño, la

escritura, pruebas, depuración y
mantenimiento. El diseño es la concepción o la
invención de un esquema para convertir un
requisito de cliente para el software de la
computadora en el software operativo. Es la
actividad que une a los requisitos de aplicación
a la codificación y debug- ging. La escritura es
la codificación real del diseño en un lenguaje
de programación adecuado. La prueba es la
actividad para verificar que el código se
escribe en realidad hace lo que se supone que
debe hacer. Depuración ging es la actividad de
encontrar y corregir errores (fallos) en el
código fuente (o diseño). El mantenimiento es
la actividad de actualizar, corregir y mejorar
los programas existentes. Cada una de estas
actividades es un tema enorme y, a menudo
garantiza que la explicación de toda una KA en
la Guía SWEBOK y muchos libros.
3.2. Los paradigmas de programación
La programación es muy creativo y por lo tanto

lo que algu- personal. Diferentes personas
suelen escribir programas diferentes para los
mismos requisitos. Esta diversidad de la
programación provoca mucha dificultad en la
construcción y mantenimiento de software
complejo grande. digmas Varios programación
para- se han desarrollado a lo largo de los años
para poner un poco de normalización en esta
actividad altamente creativa y personal.
Cuando uno los programas, él o ella puede usar
uno de varios paradigmas de programación
para escribir el código. Los principales tipos de
paradigmas de programación se discuten a
continuación.
La programación no estructurada: en
presentimiento a escribir el código de la manera asociado con la programación orientada a objetos,

que él / ella le gusta, siempre y cuando la en el que las interacciones entre los objetos se
función está operativa. A menudo, la práctica es convierten en muy compleja. La esencia de AOP
escribir código para cumplir una utilidad es la separación en gran medida enfatizado de
específica sin tener en cuenta cualquier otra preocupaciones, que separa las preocupaciones
cosa. Los programas escritos de esta manera, no funcionales no esenciales o lógica en varios
exhiben estructura- particular, de ahí el nombre aspectos.
de “programación estructurada.” Programación Programación funcional: Aunque menos pobla-
no estructurada también a veces se llama la lar, la programación funcional es tan viables como
programación ad hoc. los otros paradigmas de programación en la
Estructurada / Procedimientos / Imperativo solución de
programa- ción: Una característica distintiva de
la programación estructurada es el uso de
estructuras de control bien definidas,
procedimientos INCLUYENDO (y / o
funciones) con cada procedimiento (o función)
realizar una tarea específica. Existen interfaces
entre los procedimientos para facilitar las
operaciones de llamada correcta y adecuada de
los programas. En virtud de la programación
estructurada, los programadores a menudo
siguen los protocolos y reglas generales
establecidas al escribir código. Estos protocolos
y normas pueden ser numerosas y cubrir casi
todo el ámbito de programación que van desde
el tema más simple (por ejemplo, cómo nombrar
variables, funciones, procedimientos, etc.) a
cuestiones complejas más com- (tales como la
forma de estructurar una interfaz, cómo manejar
excepciones, etc.).
Programación orientada a objetos: Mientras
dimientos de programación dural organiza
programas en torno a los procedimientos,
programación orientada a objetos (POO)
organizar un programa alrededor de los objetos,
que son estructuras de datos abstractos que
combinan tanto los datos y métodos utilizados
para acceder o manipular los datos. Las
características primarias de la OOP son que los
objetos que representan diversas entidades
abstractas y concretas son creados y estos
objetos interactúan entre sí para cumplir
colectivamente las funciones deseadas.
Programación Orientada a Aspectos:
Aspecto-ori- programación entados (AOP) es un
paradigma de programación que se construye en
la parte superior de la programación orientada a
objetos. AOP pretende aislar funciones
secundarias o de apoyo de la lógica de negocio
del programa principal, centrándose en las
secciones transversales (preocupaciones) de los
objetos. La principal motivación para AOP es
resolver el enredo objeto y de dispersión
Fundamentos
4.2. Sintaxis y semántica de lenguajes de de computación
problemas. En la programación funcional, 13-11
todas las computaciones son tratados como la programación
evaluación de las funciones ematical
Matemáticas-. En contraste con la Al igual que los lenguajes naturales, muchos
programación imperativo que enfatiza los lenguajes de programación tienen alguna forma
cambios de estado, la programación funcional de especifica- ción por escrito de su sintaxis
hace hincapié en la apli- cación de las (forma) y semántica (Entretanto ing). Tales
funciones, evita los datos del estado y especificaciones incluyen, por ejemplo,
mutables, y proporciona transparencia
referencial.
4. Conceptos básicos del lenguaje de

programación
[4 *, c6]
El uso de ordenadores para resolver problemas

implica programación que está escribiendo y
organiz- ing instrucciones que le indican a la
computadora qué hacer en cada paso. Los
programas deben ser escritos en algún lenguaje
de programación con el cual ya través del cual
se describen los cálculos necesarios. En otras
palabras, usamos las facilidades
proporcionadas por un lenguaje de
programación para describir los problemas, el
desarrollo de algoritmos, y la razón acerca de
las soluciones de problemas. Para escribir
cualquier programa, uno debe soportar sub al
menos un lenguaje de programación.
4.1. Lenguaje de Programación general
Un lenguaje de programación está diseñado

para expresar computaciones que pueden ser
realizadas por un ordenador. En un sentido
práctico, un lenguaje de programación es una
notación para escribir programas y por lo tanto
debe ser capaz de expresar la mayoría de las
estructuras de datos y algoritmos. Algunas,
pero no todas, las personas restringen el
término “lenguaje de programación” a aquellas
lenguas que pueden expresar todos los
algoritmos posibles.
No todos los idiomas tienen la misma
importancia y popularidad. Los más populares
son a menudo definidos por un documento de
especificación establecida por una
organización bien conocida y respetada. Por
ejemplo, el lenguaje de programación C se
manera especificada por una norma ISO
denominado ISO / IEC 9899. Otros lenguajes,
como Perl y Python, no disfrutan de dicho
tratamiento y con frecuencia tienen una
aplicación dominante que se utiliza como
referencia.
requisitos específicos para la definición de Ables tipos de lenguaje es su estrecha asociación con las
variabilidad y constantes (en otras palabras, características específicas de un tipo de
declara- ción y tipos) y requisitos de formato arquitectura del ordenador Conjunto de
para las mismas instrucciones. instrucciones (ISA).
En general, un lenguaje de programación
compatible con construcciones tales como
variables, tipos de datos, con- stants, literales,
instrucciones de asignación, las sentencias de
control, procedimientos, funciones y
comentarios. La sintaxis y la semántica de cada
construcción deben estar claramente
especificado.
4.3. Bajo Programación y Lenguajes
lenguaje de programación se pueden clasificar

en dos clases: los lenguajes de bajo nivel y
lenguajes de alto nivel. lenguajes de bajo nivel
pueden ser entendidos por un ordenador sin o
con un mínimo de ayuda y por lo general
incluyen lenguajes de máquina y lenguajes Bly
bleas. Un lenguaje de máquina utiliza unos y
ceros para representar instrucciones y variables,
y es directamente comprensible por un
ordenador. Un lenguaje ensamblador contiene
las mismas instrucciones como un lenguaje
máquina, pero las instrucciones y variables
tienen nombres simbólicos que son más fáciles
para los seres humanos a tener en cuenta.
Los lenguajes ensambladores no pueden ser
directamente Adjunto se pusieron junto a un
ordenador y deben ser traducidos a un lenguaje
de máquina por un programa de utilidad llamada
un ensamblador. A menudo existe una
correspondencia entre las instrucciones de un
lenguaje ensamblador y un lenguaje de máquina,
y la traducción del código ensamblador a código
máquina es la sala straightfor-. Por ejemplo,
“añadir R1, R2, R3” es una instrucción Bly
Asam- para añadir el contenido del registro R2 y
R3 y almacenar la suma en registro r1. Esta
instrucción puede ser fácilmente traducido a
código de máquina “0001 0001 0010 0011.”
(Suponga el código funcionamiento para la
adición es 0001, véase la figura 13.2).
añadir r1, r2, R3

0001 0001 0010 0011
Figura 13.2. Asamblea-a-binario Traducciones
Un rasgo común compartido por estos dos

Java. Fundamentos de computación
4.4. -Programación y Lenguajes 13-13
Un lenguaje de programación de alto nivel

tiene una fuerte abstracción de los detalles de
ISA de la computadora. En comparación con
los lenguajes de programación de bajo nivel, a
menudo se utiliza elementos de lenguaje
natural y por lo tanto mucho más fácil de
entender para los humanos. Tales lenguajes
permiten ing nam- simbólica de variables,
proporcionan expresividad, y permitir que la
abstracción del hardware subyacente. Por
ejemplo, mientras que cada uno tiene su propio
microprocesador ISA, el código escrito en un
lenguaje de programa- ming alto nivel suele ser
portable entre muchas plataformas de hardware
diferentes. Por estas razones, la mayoría de los
programadores utilizar y la mayoría del
software están escritos en lenguajes de
programación de alto nivel. Ejemplos de
lenguajes de programación de alto nivel
incluyen C, C ++, C #, y Java.
4.5. vs. declarativa de programación

imperativo Idiomas
La mayoría de los lenguajes de programación

(de alto nivel o de bajo nivel) permiten a los
programadores especificar las instrucciones
individuales que una computadora es
ejecutar. Tales lenguajes de programación son
llamados lenguajes de programación
imperativo porque uno tiene que especificar
claramente cada paso a la computadora. Sin
embargo, algunos lenguajes de programación
permiten que los programadores sólo para
describir la función que se formaron per- sin
especificar las secuencias de instrucciones
exactas para ser ejecutados. Tales lenguajes de
programación son llamados lenguajes de
programación declarativos. lenguajes
declarativos son lenguajes de alto nivel. La
implementación real de la computación escrito
en un lenguaje tal está oculto a los
programadores y por lo tanto no es una
preocupación para ellos.
El punto clave a tener en cuenta es que la
programa- ción declarativa sólo describe lo que
el programa debe lograr sin describir cómo
lograrlo. Por esta razón, muchas personas creen
que la programación declarativa facilita el
desarrollo de software más fácil. lenguajes de
programación declarativos incluyen Lisp
(también un lenguaje de programación fun-
cional) y Prolog, mientras que los lenguajes de
programación imperativos incluyen C, C ++ y
5. Las herramientas y técnicas de 5.2. Las técnicas de depuración

depuración [3 *,
c23] Depuración implica muchas actividades y puede
ser
Una vez que un programa se codifica y se rastreo de la ejecución del programa (damas
compila (ción compilación será discutido en la estáticos modernos hacen identificar algunos de
sección 10), el siguiente paso es la depuración, estos errores. Sin embargo, el punto es que estos
que es un proceso metódico de encontrar y no son verificables máquina en general). errores
reducir el número de errores o fallos en un en los datos de entrada son los errores que
programa. El propósito de la depuración es resultan ya sea en los datos de entrada que es
averiguar por qué un programa no funciona o diferente de lo que el programa
produce un resultado o salida equivocada. espera o en el tratamiento de los datos erróneos.
Excepto en los programas muy simples, la
depuración es siempre necesario.
5.1. Tipos de error
Cuando un programa no funciona, a menudo es

debido a que el programa contiene errores o
errores que pueden ser o errores sintácticos,
errores lógicos o errores en los datos. Los
errores lógicos y de datos de errores también se
conocen como dos categorías de “fallos” en la
terminología de ingeniería de software (véase el
tema 1.1, Ter-Testing relacionada minology, en
el KA de Pruebas de Software).
Los errores de sintaxis son simplemente
cualquier error que, impediría el traductor
(compilador / intérprete) de analizar con éxito el
comunicado. Cada ment estatal en un programa
debe analizar-poder antes de su significado
puede ser entendido e interpretado (y, por lo
tanto, ejecuta). En los lenguajes de
programación de alto nivel, los errores de
sintaxis son capturados durante la compilación o
la traducción del lenguaje de alto nivel en
código máquina. Por ejemplo, en el lenguaje de
programación C C / ++, la instrucción “123 =
constante;” contiene un error de sintaxis que será
capturado por el compilador durante la
compilación.
Los errores lógicos son los errores semánticos
que resultan en cálculos incorrectos o
comportamientos del programa. Su programa es
legal, pero mal! Por lo que los resultados no
coinciden con el planteamiento del problema o
expectativas de usuario. Por ejemplo, en el
lenguaje de programación C / C ++, la función
en línea “int f (int x) {return f (x-1);}” para el
cálculo de x factorial! es legal, pero lógicamente
incorrecto. Este tipo de error no puede ser
atrapado por un compilador durante la
compilación y, a menudo se descubre a través de
estático, dinámico o postmortem. depuración Fundamentos de computación
13-15
estático por lo general toma la forma de
revisión de código, mientras que la depuración
dinámico generalmente toma la forma de
rastreo y está estrechamente asociada con la
prueba. depuración Postmortem es el acto de la
depuración de la volcado de memoria (volcado
de memoria) de un proceso. Los vaciados de
memoria se generan a menudo después de un
proceso ha le ponga fin debido a una excepción
no controlada. Las tres técnicas se utilizan en
diversas etapas del desarrollo del programa.
La principal actividad de depuración
dinámica está trazando, que está ejecutando el
programa de una pieza a la vez, el examen de
los contenidos de los registros y la memoria,
con el fin de examinar los resultados en cada
paso. Hay tres modos de buscar un programa.
• Solo paso a paso: ejecutar una instrucción

a la hora de asegurarse de que cada
instrucción se ejecutados correctamente.
Este método es tedioso, pero útil para
verificar cada paso de un programa.
• Los puntos de interrupción: decir que el
programa deje ing execut- cuando llega a
una instrucción específica. Esta técnica
permite una rápida ejecutar secuencias de
código seleccionado para obtener una
visión general de alto nivel del
comportamiento de ejecución.
• Ver puntos: decirle al programa que parar
cuando un registro o memoria ubicación
cambia o cuando es igual a un valor
específico. Esta técnica es útil cuando uno
no sabe dónde o cuando se cambia un
valor y cuando este cambio de valor de las
posibles causas del error.
5.3. Herramientas de depuración
La depuración puede ser complejo, difícil y

tedioso. Como la programación, depuración
también es muy creativo (a veces más creativa
que la programación). De este modo la ayuda
de herramientas está en orden. Para la
depuración dinámica, depuradores son
ampliamente utilizados y permiten al
programador para controlar la ejecución de un
programa, detienen la ejecución, reiniciar la
ejecución, establecer puntos de interrupción,
los valores de cambio en la memoria, e
incluso, en algunos casos, se remontan en hora.
Para la depuración estática, hay muchas
herramientas de análisis de código estático, que
buscan un conjunto específico de problemas
conocidos dentro del código fuente.
Existen dos herramientas comerciales y gratuitas perspectiva de ordenamiento cal física y logi-, una
en varios idiomas. Estas herramientas pueden ser estructura de datos es ya sea lineal o no lineal.
extremadamente útil para comprobar muy Otras perspectivas dan lugar a diferentes
grandes árboles de origen, donde no es práctico clasificaciones que incluyen homogénea vs.
hacer tutoriales de código. El programa de heterogénea, estático vs. dinámico, persistente vs.
pelusa UNIX es un ejemplo temprano. transitoria, externo vs. interna, primitivo vs.
agregado, recursiva vs. no recursiva; vs pasiva
6. Estructura de datos y representación activo; y estructuras con estado vs sin estado.
[5 *, s2.1-2.6]
Los programas funcionan en los datos. Pero los

datos se expresan y organizan dentro de los
ordenadores antes de ser procesados por los
programas. Esta organización y expresión de
datos para su uso programas es el tema de la
estructura de datos y la representación. Sim-
poner capas, una estructura de datos intenta
almacenar y organizar los datos en un ordenador
de una manera tal que los datos pueden ser
utilizados de manera eficiente. Hay muchos
tipos de estructuras de datos y cada tipo de
estructura es adecuada para algunos tipos de
aplicaciones. Por ejemplo, B / B + árboles son
muy adecuadas para la implementación de
sistemas de archivos maestras sivos y bases de
datos.
6.1. Presentación de la estructura de datos
Las estructuras de datos son representaciones

informáticas de datos. Las estructuras de datos
se utilizan en casi todas las programa. En un
sentido, ningún programa significativo puede ser
construido sin el uso de algún tipo de estructura
de datos. Algunos métodos de diseño y
lenguajes de progra- ming incluso organizan
todo un sistema de software alrededor de las
estructuras de datos. Fundamentalmente, las
estructuras de datos son abstracciones definidas
en una lection COL- de datos y sus operaciones
asociadas.
A menudo, las estructuras de datos están
diseñados para el programa de ING improv- o la
eficiencia del algoritmo. Ejemplos de tales
estructuras de datos incluyen pilas, colas y
montones. En otras ocasiones, las estructuras de
datos se utilizan para la unidad conceptual
(resumen tipo de datos), tales como el nombre y
dirección de una persona. A menudo, una tura de
datos estruc- puede determinar si un programa se
ejecuta en unos pocos segundos o en unas pocas
horas o incluso unos pocos días. Desde la
estructura. Fundamentos de computación
6.2. tipos de Estructura de Datos 13-17
Como se mencionó anteriormente, diferentes Algunas estructuras de datos también apoyan

perspectivas se pueden utilizar para clasificar adicional
las estructuras de datos. Sin embargo, la operaciones:
perspectiva predominante usado en la
clasificación se centra en orden físico y lógico
entre los elementos de datos. Esta clasificación
divide estructuras de datos en las estructuras
lineales y no lineales. estructuras lineales
organizan los elementos de datos en una única
dimensión en la que cada entrada de datos tiene
una (físico o lógico) predecesor y sucesor uno
con la excepción de la primera y última
entrada. La primera entrada no tiene
predecesor y la última entrada no tiene sucesor.
estructuras no lineales organizan los elementos
de datos en dos o más dimensiones, en cuyo
caso, una entrada puede tener varios
predecesores y sucesores. Ejemplos de
estructuras lineales incluyen listas, pilas y
colas. Ejemplos de estructuras no lineales
incluyen montones, tablas hash, y los árboles
(tales como árboles binarios, árboles de
equilibrio, los árboles B, y así sucesivamente).
Otro tipo de estructura de datos que se
encuentra a menudo en la programación es la
estructura del compuesto. Una estructura de
datos compuesto se acumula en la parte
superior de otros (más primitivos) estructuras
de datos y, de alguna manera, se puede ver
como la misma estructura que la estructura
subyacente. Ejemplos de estructuras com-
puesto incluyen conjuntos, gráficos y ciones
culas. Por ejemplo, una partición puede ser
vista como un conjunto de conjuntos.
6.3. Las operaciones en Estructuras de Datos
Todas las estructuras de datos soportan algunas

operaciones que producen una estructura y un
orden específico, o recuperar los datos
relevantes de la estructura, almacenar datos en
la estructura, o borrar los datos de la estructura.
Operaciones básicas con el apoyo de todas las
estructuras de datos incluyen crear, leer,
actualizar y eliminar (ABM).
• Crear: Inserte una nueva entrada de datos en

el
estructura.
• Lea: Recuperar una entrada de datos de la
estructura.
• Actualización: modificar una entrada de
datos existente.
• Eliminar: Eliminar una entrada de datos de
la
• Buscar un elemento en particular en la existe una definición universalmente aceptada de

estructura. Sally, existe cierto acuerdo en que un algoritmo
• Ordenar todos los elementos de acuerdo con tiene que ser correcta, finita (en otras palabras,
algún orden. terminan con el tiempo o uno debe ser capaz de
• Recorrer todos los elementos en un orden escribir en un número finito de pasos), y sin
específico. ambigüedades.
• Reorganizar o reequilibrar la estructura.
Diferentes estructuras de apoyo diferentes

operaciones con diferentes eficiencias. La
diferencia entre la eficiencia de la operación
puede ser significativo. Por ejemplo, es fácil de
recuperar el último elemento insertado en una
pila, pero encontrar un elemento particular
dentro de una pila es bastante lento y tedioso.
7. Algoritmos y Complejidad
[5 *, s1.1-1.3, s3.3-3.6, s4.1-4.8, s5.1-5.7,
s6.1-6.3, s7.1-7.6, s11.1,
S12.1]
Los programas no son al azar piezas de código:

están escritos meticulosamente para realizar
acciones a la esperada por el usuario. La guía
uno utiliza para componer programas son
algoritmos, que organizan diversas funciones en
una serie de pasos y tienen en cuenta el dominio
de aplicación, la estrategia de solución, y las
estructuras de datos que se utiliza. Un algoritmo
puede ser muy simple o muy compleja.
7.1. Descripción general de Algoritmos
Hablando en abstracto, algoritmos guían las

operaciones de ordenadores y consisten en una
secuencia de acciones compuestas para resolver
un problema. Definiciones alternativas incluyen,
pero no se limitan a:
• Un algoritmo es cualquier procedimiento

computacional bien definido que lleva algún
valor o conjunto de valores como entrada y
produce un cierto valor o conjunto de
valores como salida.
• Un algoritmo es una secuencia de pasos de
cálculo que transforman la entrada en la
salida.
• Un algoritmo es una herramienta para la
resolución de un problema de cálculo
especificada bien.
Por supuesto, las diferentes definiciones son

favorecidos por diferentes personas. Aunque no
7.2. Atributos de Algoritmos 13-19
Los atributos de algoritmos son muchos y a

menudo incluyen la modularidad, la
corrección, dad maintainabil-, funcionalidad,
robustez, facilidad de uso (es decir, fácil de ser
entendido por personas), el tiempo mer
programa-, simplicidad y extensibilidad. Un
atributo comúnmente enfatizado com- es
“rendimiento” o “eficiencia” por lo que
entendemos tanto tiempo y eficiencia de los
recursos en el uso, mientras que por lo general
haciendo hincapié en el eje del tiempo. Hasta
cierto punto, la deficiencia efi- determina si un
algoritmo es factible o práctico. Por ejemplo,
un algoritmo que toma cien años para terminar
es prácticamente uso- menos y se considera
incluso incorrecta.
7.3. Análisis algorítmico
Análisis de algoritmos es el estudio teórico de

rendimiento programa de ordenador y el uso de
recursos; en cierta medida, que determina la
bondad de un algoritmo. Tal análisis
generalmente abstrae los detalles particulares
de un equipo específico y se centra en el
análisis dent asintótica, máquina-indepen-.
Hay tres tipos básicos de análisis. En el
análisis del peor caso, se determina el tiempo
de mamá maxi- o los recursos requeridos por el
algoritmo en cualquier entrada de tamaño n. En
el análisis de caso promedio, se determina el
tiempo esperado o los recursos requeridos por
el algoritmo sobre todas las entradas de tamaño
n; en la realización de análisis en el caso
promedio, a menudo se tiene que hacer
suposiciones sobre la dis- tribución estadística
de los insumos. El tercer tipo de análisis es el
análisis mejor de los casos, en los que se
determina el tiempo mínimo o los recursos
requeridos por el algoritmo en cualquier
entrada de tamaño n. Entre los tres tipos de
análisis, análisis de caso promedio es el más
relevante pero también el más difícil de
realizar.
Además de los métodos de análisis básicos,
también hay el análisis amortizado, en el que
uno determina el tiempo máximo requerido
por un Rithm algo- sobre una secuencia de las
operaciones; y el análisis competitivo, en el
que se determina el mérito relativo rendimiento
de un algoritmo contra el algoritmo óptimo
(que no puede ser conocido) de la misma
categoría (por las mismas operaciones).
13-11
7.4. Estrategias de diseño algorítmico algoritmo toma para completa su tarea; análisis
probabilístico, en el que se hace uso de las
El diseño de algoritmos sigue generalmente una probabilidades en el análisis del rendimiento
de las siguientes estrategias: la fuerza bruta, medio de un algoritmo; amor- análisis Tized, en el
divide y vencerás, programación dinámica, y la que uno utiliza los métodos de
selección codiciosos. La estrategia de la fuerza
bruta es en realidad una estrategia no. Se trata de
manera exhaustiva todos los medios posibles
para hacer frente a un problema. Si un problema
tiene una solu- ción, esta estrategia está
garantizada para encontrarlo; Sin embargo, el
gasto de tiempo puede ser demasiado alto. La
estrategia de divide y vencerás mejora en la
estrategia de la fuerza bruta dividiendo un gran
problema en problemas más pequeños y
homogéneos. Se resuelve el gran problema por
resolver de forma recursiva los problemas más
pequeños y peinado de las soluciones a los
problemas más pequeños para formar la solución
al gran problema. El supuesto subyacente de
divide y vencerás es que los problemas más
pequeños son más fáciles de resolver.
La estrategia de programación dinámica
mejora en la estrategia de divide y vencerás por
ING reconocibles que algunos de los sub-
problemas producidos por la división puede ser
el mismo y por lo tanto evita la solución de los
mismos problemas una y otra vez. Este ción de
elimina- subproblemas redundantes puede
mejorar dramáticamente la eficiencia.
La estrategia de selección codiciosos mejora
aún más en programación dinámica mediante el
reconocimiento de que no todos los sub-
problemas contribuyen a la solu- ción de la gran
problema. Al eliminar todas menos una sub-
problema, la estrategia de selección codiciosos
logra la más alta eficiencia entre todas las
estrategias de diseño rithm algo-. A veces, el uso
de la aleatorización puede mejorar en la
estrategia de selec- ción codiciosos al eliminar la
complejidad en la determinación de la elección
codicioso a través de monedas de ping flip o
aleatorización.
7.5. Estrategias de análisis algorítmico
Las estrategias de análisis de algoritmos

incluyen el análisis de contar en forma básica, en
la que uno realmente cuenta el número de pasos
de un algoritmo tarda en completar su tarea;
análisis asintótico, en el que uno sólo considera
el orden de magnitud del número de pasos de un
13-12 Guía SWEBOK® V3.0 seguridad, etc.
agregación, potencial, y la contabilidad para
ana- Lyze el peor rendimiento de un algoritmo
en una secuencia de operaciones; y análisis de
la competencia, en el que uno utiliza métodos
tales como el potencial y la contabilidad para
analizar el rendimiento relativo de un
algoritmo para el algoritmo óptimo.
Para problemas complejos y algoritmos, uno
puede necesitar usar una combinación de las
estrategias de análisis cionado aforemen-.
8. Concepto básico de un sistema de

[6 *, c10]
Ian Sommerville escribe, “un sistema es una

colección propósito de componentes
interrelacionados que trabajan en conjunto para
lograr algún objetivo” [6 *]. Un sistema
puede ser muy simple e incluir sólo unos pocos
componentes, como una pluma de tinta, o más
bien complejo, como un avión. Dependiendo
de si los seres humanos son parte del sistema,
los sistemas se pueden dividir en sistemas
basados en computadoras técnicas y sistemas
sociotécnicos. Un técnico funciones del
sistema basado en computadora sin
intervención humana, tales como televisores,
teléfonos móviles, termostato, y algún tipo de
software; un sistema socio-técnico no
funcionará sin la intervención humana.
Ejemplos de tal sistema incluyen vehículos
tripulados espaciales, chips embebidos dentro
de un ser humano, y así sucesivamente.
8.1. Propiedades del sistema emergente
Un sistema es más que la simple suma de sus

partes. Por lo tanto, las propiedades de un
sistema no son simplemente la suma de las
propiedades de sus componentes. En cambio,
un sistema a menudo exhibe propiedades que
son propiedades del sistema como un todo.
Estas propiedades se denominan propiedades
emergentes porque se desarrollan sólo después
de la integración de las partes constituyentes en
el sistema. las propiedades del sistema
Emergentes pueden ser funcional o no
funcional. propiedades funcionales describen
las cosas que hace un sistema. Por ejemplo, las
propiedades funcionales de un avión incluyen
la flotación en el aire, llevando a las personas o
carga, y su uso como arma de destrucción
masiva. propiedades no funcionales describen
cómo se comporta el sistema en su entorno
operativo. Estos pueden incluir cualidades tales
como consistencia, dad capaci-, el peso, la
13-13
Figura 13.3. Los componentes básicos de un sistema informático basado en el modelo de von Neumann
8.2. Ingeniería de Sistemas Una computadora es una máquina que ejecuta

programas o software. Se compone de una
“La ingeniería de sistemas es el enfoque colección con propósito de mecánica, eléctrica,
interdisciplinario que rige el esfuerzo gerial
técnica y Mana- total que se requiere para
transformar un conjunto de necesidades de
cliente central Tomer, expectativas y
limitaciones en una solución y para apoyar esa
solución pasantes a cabo su vida.” [7]. Las
etapas del ciclo de vida de la ingeniería de
sistemas varían en función del sistema que se
está construyendo, pero, en general, incluyen
requisitos del sistema de definición, el diseño
del sistema, subsistema de Desa- ción,
integración de sistemas, las pruebas del sistema,
la instalación del sistema, la evolución del
sistema, y el sistema de desmantelamiento.
Muchas directrices prácticas se han producido
en el pasado para ayudar a las personas en la
realización de las actividades de cada fase. Por
ejemplo, el diseño del sistema se puede dividir
en tareas más pequeñas de identificación de
subsistemas, la asignación de sistema
REQUISITOS DE a los subsistemas, la
especificación de la funcionalidad del
subsistema, la definición de interfaces del
subsistema, y así sucesivamente.
8.3. Visión general de un sistema informático
Entre todos los sistemas, uno que es,

obviamente, rel- Evant a la comunidad de
ingeniería de software es el sistema informático.
y componentes electrónicos con cada
componente realiza una función de preajuste.
Conjuntamente, estos componentes son
capaces de ejecutar las instrucciones que se
dan por el programa.
Hablando en abstracto, un ordenador recibe
alguna entrada, almacena y manipula algunos
datos, y proporciona una cierta salida. La
característica más distintiva de un ordenador es
su capacidad para almacenar y ejecutar
secuencias de instrucciones llamadas
programas. Un fenómeno interesante en relación
con el ordenador es la equivalencia universal en
funcionalidad. De acuerdo con Turing, todos los
ordenadores con una cierta capacidad mínima
son equivalentes en su abil- dad para realizar
tareas de cálculo. En otras palabras, dado el
tiempo suficiente y la memoria, todos
Computadoras- que van desde un netbook a un
superordenador-son capaces de calcular
exactamente las mismas cosas,
independientemente de la velocidad, tamaño,
costo, o cualquier otra cosa. La mayoría de los
sistemas informáticos tienen una estructura que
se conoce como el “modelo de von Neumann,”
que consta de cinco componentes: una memoria
para almacenar instrucciones y datos, una
unidad central de procesamiento para realizar
operaciones aritméticas y lógicas, una unidad de
control para la secuenciación y la interpretación
de instrucciones , entrada para conseguir
informa- ción externa en la memoria, y la salida
para la producción de resultados para el usuario.
Los componentes básicos de un sistema
informático basado en el Von Neumann
modelo se representan en la figura 13.3.
13-15
9. Organización de la ISA, que especifica las cosas tales como el

computadoras [8 *, c1-c4] nativo de tipos de datos, instrucciones, registros,
modos de direccionamiento, la arquitectura de
memoria, interrumpir y
Desde la perspectiva de un ordenador, existe una
gran diferencia semántica entre su intención Cada nivel proporciona una abstracción al nivel
comportamiento y el funcionamiento de los superior y es dependiente en el nivel inferior. Para
dispositivos electrónicos subyacentes que un programador, el más importante es la
realmente hacen el trabajo dentro del equipo. abstracción
Esta brecha se puentea a través del ordenador
orga- nización, que engrana Various, Tronic
elec- eléctrica, y dispositivos mecánicos en un
solo dispositivo que forma un ordenador. Los
objetos que se ocupa de la organización de
ordenador son los dispositivos, las conexiones y
controles. La abstracción construida en la
organización del equipo es el equipo.
9.1. Organización general del ordenador
Un equipo consiste generalmente en una CPU,

memoria, dispositivos de entrada y dispositivos
de salida. Hablando en abstracto, la organización
de un ordenador se puede dividir en cuatro
niveles (Figura 13.4). El nivel de arquitectura
macro es la especificación formal de todas las
funciones de una máquina en particular se puede
llevar a cabo y se conoce como la arquitectura
del conjunto de instrucciones (ISA). El nivel de
arquitectura micro es la actividad mental en
práctica de la ISA en un específico CPU-en otras
palabras, la manera en que las especificaciones
del ISA se llevan a cabo realmente. El nivel de
los circuitos lógicos es el nivel en el que cada
componente funcional de la micro arquitectura
se construye de circuitos que toman decisiones
basadas en reglas simples. El nivel de los
dispositivos es el nivel donde, finalmente, cada
circuito lógico está construido de dispositivos
electrónicos tales como semiconductores
complementarios de óxido metálico (CMOS), n
de canal-semiconductores de óxido de metal
(NMOS), o arseniuro de galio (GaAs)
transistores, y por lo tanto adelante.
Macro Arquitectura Nivel (ISA)

Micro Arquitectura Nivel
Circuitos lógicos Nivel
Nivel dispositivos
Figura 13.4. Niveles arquitectura de la máquina

manejo V3.0
de excepciones, y las E / S. En general,
el ISA especifica la capacidad de un ordenador
y qué se puede hacer en el equipo con la
programación.
9.2. Sistemas digitales
En el nivel más bajo, los cálculos se llevan a

cabo por los dispositivos eléctricos y
electrónicos dentro de un ordenador. El equipo
utiliza circuitos y memoria para sostener los
cargos que representa la presencia o ausencia
de tensión. La presencia de tensión es igual a
un 1 mientras que la ausencia de tensión es un
cero. En el disco de la polaridad de la tensión
está representada por 0 y 1 que a su vez
representa los datos almacenados. Todo,
incluyendo la instrucción y los datos se expresa
o se codifica mediante ceros digitales y unos.
En este sentido, un ordenador se convierte en
un sistema digital. Por ejemplo, el valor
decimal 6 puede ser codificada como 110, la
instrucción de adición puede ser codificado
como 0001, y así sucesivamente. El
componente del ordenador, tales como la
unidad de control, ALU, la memoria y E / S
usa la información para calcular las
instrucciones.
9.3. lógica digital
Obviamente, se necesitan lógicas para

manipular los datos y para controlar el
funcionamiento de los ordenadores. Esta
lógica, que está detrás ción fun- adecuada de
un ordenador, se llama la lógica digital, ya que
se ocupa de las operaciones de ceros digitales y
unos. lógica digital especifica las reglas tanto
para la construcción de diversos dispositivos
digitales de los elementos más simples (tales
como transistores) y para gobernar el
funcionamiento de los dispositivos digitales.
Por ejemplo, la lógica digital detalla cuál será
el valor si un cero y uno es un AND, un OR o
un OR exclusivo juntos. También especifica
cómo construir decodificadores, multiplexores
ERS (MUX), memoria y sumadores que se
utilizan para montar el equipo.
9.4. Expresión de datos del ordenador
Como se mencionó antes, un ordenador

expresa los datos con las señales eléctricas
digitales o ceros y unos. Puesto que hay sólo
dos dígitos utilizados en diferentes
13-17
expresión de datos, un sistema de este tipo se • Las células de memoria y chips

llama un sistema de expresión binario. Debido a • placas y módulos de memoria
la naturaleza inherente de un sistema binario, el • jerarquía de memoria y la memoria caché
valor numérico máximo expresable por un • La memoria como un subsistema del equipo.
código binario de n bits es 2n - 1.
En concreto, el número binario aa aa ... pondiente
norte n-11 0
ponde a unan  2norte + a n-1 + ... + a 1 + Las células de memoria y chips tratar con un
o
r n-1 1
solo digitales
u0  20. Por lo tanto, el valor numérico de la
t
e
La memoria es la unidad de almacenamiento de
n un ordenador. It preocupaciones con- el montaje
de un sistema de memoria a gran escala a partir de
 1 = 11. Expresar un valor no numérico, unidades más pequeñas y de almacenamiento de
necesitamos para decidir el número de ceros y un solo dígito. Los principales temas tratados en
unos de usar y el orden en que están dispuestos la arquitectura de memoria tem sis- incluyen los
los ceros y unos. siguientes:
Por supuesto, hay diferentes maneras de hacer
la codificación, y esto da lugar a diferentes
esquemas de expresión de datos y subsistemas.
Por ejemplo, los números enteros se pueden
expresar en forma de, complemento de uno o
complemento sin firmar de dos. Para los
personajes, hay ASCII, Unicode y normas
EBCDIC de IBM. Para los números de punto
flotante, hay IEEE-754 FP 1, 2 y 3 estándares.
9.5. La Unidad Central de Procesamiento

(CPU)
La unidad central de procesamiento es el lugar

en el que las instrucciones (o programas) son
realmente ejecutados. La ejecución por lo
general toma varias medidas, ING
INCLUYENDO ir a buscar la instrucción de
programa, la decodificación de la instrucción, ir
a buscar operandos, que realizan operaciones
aritméticas y lógicas de los operandos, y
almacenar el resultado. Los principales
componentes de una CPU constan de registros
donde instrucciones y los datos son a menudo
leer y escribir a, la unidad aritmética y lógica
(ALU) que realiza la aritmética real (tales como
la adición, ción subtrac-, multiplicación y
división) y lógicas (tales como y, O, las
operaciones de cambio, y así sucesivamente), la
unidad de control que es responsable de producir
las señales apropiadas para controlar las
operaciones, y varios estandares (datos,
dirección y control) autobuses que enlazan la
componentes juntos y los datos de transporte
hacia y desde estos componentes.
9.6. Organización del Sistema de memoria

el almacenamiento y elV3.0
montaje de unidades de
un solo dígito en matrices de memoria
unidimensionales, así como el montaje de
matrices de almacenamiento unidimensionales
en chips de memoria de almacenamiento multi-
dimensionales. placas y módulos de memoria
se refieren al montaje de chips de memoria en
la memoria TEMS sis-, con el foco que está en
la organización, el funcionamiento y la gestión
de los chips individuales en el sistema.
jerarquía de memoria y la memoria caché se
utilizan para apoyar las operaciones de
memoria eficientes. La memoria como un sub-
sistema se ocupa de la interfaz entre el sistema
de memoria y otras partes de la computadora.
9.7. Entrada y salida (I / O)
Un ordenador es inútil sin I / O. dispositivos de

entrada comunes incluyen el teclado y ratón;
dispositivos de salida comunes incluyen el
disco, la pantalla, la impresora y altavoces.
Diferentes dispositivos de E / S funcionan a
diferentes velocidades de datos y capacidades
reli-. ¿Cómo se conectan los ordenadores y
administrar varios dispositivos de entrada y
salida para facilitar la interacción entre
computadoras y seres humanos (u otros
equipos) es el foco de los temas de E / S. Los
principales problemas que deben ser resueltos
en la entrada y la salida son las formas de E / S
pueden y deben llevarse a cabo.
En general, I / O se lleva a cabo tanto a nivel
Ware y software duro. Hardware I / O se puede
realizar en cualquiera de tres maneras.
Dedicado I / O dedica a la CPU para las
operaciones de entrada y salida reales durante I
/ O; trata de E / S mapeada en memoria de E /
S de operaciones como operaciones de
memoria; y híbrido I / O combina dedicado I /
O y la memoria-E / S mapeada en un solo
modo de operación de E / S holística.
Coincidentemente, el software de E / S
puede estar formada también per- en una de
tres maneras. E / S programada permite la
espera de la CPU mientras que el dispositivo
de E / S está haciendo E / S; interrumpir
impulsada I / O deja para el manejo de la CPU
de I / O ser accionado por el dispositivo de I /
O; y acceso directo a memoria (DMA) permite
I / O ser manejado por un CPU secundaria
incrustado en un dispositivo DMA (o
13-19
canal). (Excepto durante la configuración inicial, imagen ejecutable para ejecutar el programa. La
la CPU principal no se altera durante una mayoría del software aplica- ción se vende en esta
operación de DMA I / O). forma.
Independientemente de los tipos de esquema Mientras tanto la compilación e interpretación
de E / S que se utilizan, las principales con- vert código de lenguaje de alto nivel en
cuestiones relacionadas con la E / S incluyen E / código máquina,
S de direccionamiento (que se ocupa de la
cuestión de cómo identificar el dispositivo de E /
S para un específico de E / S opera- ción) ,
sincronización (que se ocupa de la cuestión de
cómo hacer que la CPU y I / O dispositivo
funcione en armonía durante I / O), y la
detección y corrección de errores (que trata de la
ocurrencia de errores de transmisión).
10. Fundamentos del compilador

[4 *, s6.4] [8 *,
S8.4]
10.1. Compilador / intérprete general
Los programadores suelen escribir programas en

código de lenguaje de alto nivel, que la CPU no
puede eje- linda; por lo que este código fuente
tiene que ser convertido en código de máquina
para ser entendido por un ordenador. Debido a
las diferencias entre los diferentes NIA, la
traducción debe hacerse para cada ISA o espe-
lenguaje de máquina CIFIC bajo consideración.
La traducción se realiza generalmente por una
pieza de software llamado un compilador o un
intérprete. Este proceso de traducción de un
lenguaje de alto nivel a un lenguaje máquina se
llama compilación ción, o, a veces, la
interpretación.
10.2. Interpretación y compilación
Hay dos formas de traducir un programa

escriben normalmente con un lenguaje de alto
nivel en código de máquina: interpretación y
compilación. Interpretación traduce el código
fuente de una instrucción a la vez en lenguaje de
máquina, lo ejecuta en el lugar, y luego regresa
para otro comunicado. Tanto el código fuente de
nivel de lengua alto y el intérprete se requieren
cada vez que se ejecuta el programa.
Compilacion traduce el código de nivel de
lengua fuente alta en todo un programa en
lenguaje de máquina (una imagen ejecutable)
por un programa que se llama un compilador.
Después de la compilación, sólo se necesita la
13-20 Guía SWEBOK® V3.0 ajusta a un formato esperado. ¿Es esta una
hay algunas diferencias importantes entre los
dos métodos. En primer lugar, un compilador correcta programa aliado textu- C ++? o ¿Es esta
hace que la conver- sión sólo una vez, mientras entrada tex- tualmente correcta? son preguntas
que un intérprete normalmente con- verts cada típicas que pueden ser
vez que se ejecuta un programa. En segundo
lugar, la interpretación de código es más lenta
que la ejecución del código compilado, ya que
el intérprete debe analizar cada declaración en
el programa cuando se ejecuta y luego realizar
la acción deseada, mientras que el código
compilado solo realiza la acción dentro de un
contexto fijo determinado por el Compilacion.
En tercer lugar, el acceso a las variables
también es más lento en un intérprete porque la
asignación de identificadores a los lugares de
almacenamiento debe realizarse varias veces
en tiempo de ejecución en lugar de en tiempo
de compilación.
Las tareas principales de un compilador
pueden incluir preprocesamiento, análisis
léxico, análisis sintáctico, análisis semántico,
generación de código, y el código de
optimización ción. averías causadas por el
comportamiento del programa compilador
incorrecto pueden ser muy difíciles de
localizar. Por esta razón, los ejecutores del
compilador invierten mucho tiempo, garantizar
la exactitud de su software.
10.3. El proceso de compilación
La compilación es una tarea compleja. La

mayoría de los compiladores dividen el
proceso de compilación en muchas fases. Una
composición típica es la siguiente:
• Análisis léxico
• Análisis de sintaxis o de análisis
• Análisis semántico
• Codigo de GENERACION
Análisis léxico divide el texto de entrada (el

código fuente), que es una secuencia de
caracteres, en observaciones separadas, que
son para ser ignorado en acciones posteriores,
y los símbolos básicos, que tienen significados
léxicos. Estos símbolos básicos deben
corresponder a algunos símbolos terminales de
la gramática de la lenguaje de programación
en particular. Aquí símbolos terminales se
refieren a los símbolos ele- mentarios (o
fichas) en la gramática que no se pueden
cambiar.
análisis sintáctico se basa en los resultados
del análisis de léxico y descubre la estructura
en el programa y determina si o no un texto se
13-21
respondida por análisis de sintaxis. análisis su propio hombre-ager para la gestión de los
sintáctico determina si el código fuente de un recursos y actividades que tienen lugar en él. Que
programa es rect cor- y la convierte en una re- el gerente se llama un sistema de explota- ción
presentación (árbol de análisis sintáctico) más (OS).
estructurado para el análisis o la transformación
semántica.
El análisis semántico agrega la información
semántica al árbol de análisis sintáctico
construido durante el análisis sintáctico y
construye la tabla de símbolos. Se realiza
variabilidad comprobaciones semánticas OU que
incluyen la comprobación de tipos, objeto de
enlace (asociación de variables y funciones
referencias con sus definiciones), y la asignación
definitiva (que requieren todas las variables
locales a ser inicializado antes de su uso). Si se
encuentran errores, las sentencias de programa
semánticamente incorrectos son rechazados y
marcados como errores.
Una vez que el análisis semántico es
completa, la fase de generación de código
comienza y transforma el código intermedio
producido en las fases anteriores en el lenguaje
de máquina nativo de la computadora bajo
consideración. Esto implica recursos y
almacenamiento de decisiones-tales como
decidir qué variables para encajar en los
registros y la memoria y la selección y
programación de instrucciones de la máquina
apropiados, junto con sus modos de
direccionamiento asociados.
A menudo es posible combinar múltiples fases
en un solo pase el código en un compilador
imple- mentación. Algunos compiladores
también tienen una fase de preprocesado en el
comienzo o después del análisis léxico que hace
el trabajo de limpieza es necesario, tales como el
procesamiento de las instrucciones de programa
para el compilador (directivas). Algunos
compiladores proporcionar una fase de
optimización opcional al final de la compilación
completa para optimizar el código (como el
reordenamiento de la secuencia de instrucciones)
para la eficiencia y otros objetivos deseables
solicitados por los usuarios.
11. Sistemas operativos Fundamentos

[4 *, c3]
Cada sistema de complejidad significativa debe

ser gestionado. Un ordenador, como un sistema
eléctrico-mecánicos más bien compleja, necesita
13-22 Guía SWEBOK® V3.0 usuarios y su abstracción principal es el sistema
11.1. Operativo general Sistemas
de archivos. Yo dispositivo de E / S manage-
sistemas operativos es una colección de ofertas de unificación con la asignación y
software y firmware, que controla la ejecución liberación de varios dispositivos de E / S entre
de programas de ordenador y proporciona los procesos que compiten.
servicios tales como la asignación de recursos
del ordenador, control de trabajo, entrada /
salida de control y gestión de archivos en un
sistema informático. Conceptualmente, un
sistema operativo es un programa informático
que gestiona los recursos de hardware y hace
que sea más fácil de utilizar por aplicaciones
mediante abstracciones agradables tando
previas. Esta abstracción agradable a menudo
se llama la máquina virtual e incluye cosas
tales como procesos, memoria virtual y
sistemas de archivos. Un sistema operativo
oculta la complejidad del hardware subyacente
y se encuentra en todos los equipos modernos.
Las principales funciones desempeñadas por
los sistemas operativos son ment manage- y la
ilusión. Gestión se refiere a la gestión del
sistema operativo (asignación y recuperación)
de los recursos físi- cas entre múltiples
usuarios / aplicaciones / tareas que compiten.
La ilusión se refiere a las buenas abstracciones
del sistema operativo proporciona.
11.2. Tareas de un sistema operativo
Las tareas de un sistema operativo difieren

significativamente dependiendo de la máquina
y el tiempo de su invención. Sin embargo, los
sistemas operativos modernos han llegado a un
acuerdo en cuanto a las tareas que deben ser
realizadas por un sistema operativo. Estas
tareas incluyen la gestión de la CPU, la gestión
de memoria, gestión de disco (sistema de
archivos), I / O de gestión de dispositivos, y la
seguridad y protección. Cada tarea OS hombre-
edades un tipo de recurso físico.
Específicamente, ofertas de gestión de la
CPU con la asignación y liberación de la CPU
entre los programas que compiten entre sí
(llamados procesos / hilos en la jerga OS),
incluyendo el propio sistema operativo. La
abstracción principal proporcionada por la
administración de la CPU es el modelo de
proceso / hilo. ofertas de gestión de memoria
con la asignación y liberación de espacio de
memoria entre procesos competitivos, y la
principal abstracción proporcionada por la
gestión de memoria es la memoria virtual.
Gestión del disco se refiere a la puesta en
común de los discos de estado magnéticos u
ópticos o sólidos entre varios programas /
13-23
Seguridad y acuerdo de protección con la puede ser clasificado como uno de los siguientes.
protección de los recursos informáticos de uso
ilegal. • OS procesamiento por lotes: organiza y
procesos de trabajo en lotes. Ejemplos de
11.3. Las abstracciones del sistema operativo tales sistemas operativos incluyen FMS de
IBM, IBSYS, y Universidad de UMES de
El arsenal de sistemas operativos es la Michigan.
abstracción. Correspondiente a las cinco tareas
físicas, sistemas operativos utilizan cinco
abstracciones: proceso / hilo, memoria virtual,
sistemas de archivos, de entrada / salida, y
dominios de protección. La abstracción general
OS es la máquina virtual.
Para cada área de tareas de sistema operativo,
no es tanto una realidad Physicians cal y una
abstracción conceptual. La realidad ical phys- se
refiere al recurso de hardware, en la gestión; la
abstracción conceptual se refiere a la interfaz del
sistema operativo presenta a los usuarios / pro-
gramas anteriores. Por ejemplo, en el modelo de
rosca del sistema operativo, la realidad física es
la CPU y la abstracción es varias CPU. De este
modo, el usuario no tiene que preocuparse
acerca de compartir la CPU con los demás
cuando trabajan en la abstracción proporcionada
por un sistema operativo. En la abstracción de la
memoria virtual de un sistema operativo, la
realidad física es la memoria RAM física o
ROM (lo que sea), la abstracción es el espacio
de memoria ITED unlim- múltiple. De este
modo, el usuario no tiene que preocuparse
acerca de compartir la memoria física con otros
o sobre el tamaño de la memoria física limitada.
Las abstracciones pueden ser virtual o
transparente; en este contexto virtual se aplica a
algo que parece estar allí, pero no es (como
memoria utilizable más allá física), mientras
transparente se aplica a algo que está ahí, pero
parece no estar allí (como ir a buscar contenido
de la memoria desde el disco o la memoria física
).
11.4. Sistemas para realizar la clasificación
Los diferentes sistemas operativos pueden tener

una implementación diferente funcionalidad. En
los primeros días de la era de los ordenadores,
sistemas operativos fueron relativamente
simple. A medida que pasa el tiempo, la
complejidad y sofisticación de los sistemas
operativos aumenta significativamente. Desde
una perspectiva histórica, un sistema operativo
13-24 Guía SWEBOK® V3.0 colección organizada de datos para uno o más
• Multiprogramado OS procesamiento por
lotes: añade la capacidad de multi- titask usos. En un sentido, una base de datos es una
en principios simples de procesamiento generalización y expansión de estructuras de
por lotes sistemas operativos. Un ejemplo datos. Pero la diferencia es que una base de
de un sistema operativo como es de IBM datos suele ser externa a programas individuales
OS / 360. y permanente en existencia en comparación con
• Tiempo compartido OS: agrega multi-tarea las estructuras de datos. Las bases de datos se
y las capacidades activas inter en el utilizan cuando el volumen de datos es grande o
sistema operativo. Ejemplos de tales lógico
sistemas operativos incluyen UNIX, Linux
y NT.
• Sistema operativo en tiempo real: añade
sincronización la previsibilidad en el
sistema operativo mediante la
programación de las tareas individuales de
acuerdo con los plazos de realización de
cada tarea. Ejemplos de tales OS incluyen
VxWorks (WindRiver) y DART (EMC).
• OS distribuido: Agrega la capacidad del
hombre: el envejecimiento de una red de
computadoras en el sistema operativo.
• OS incrustado: tiene una funcionalidad
limitada y se utiliza para sistemas
embebidos, tales como automóviles y
PDAs. Ejemplos de tales sistemas
operativos como Palm OS, Windows CE,
y PRIMERO.
Alternativamente, un OS se puede clasificar

por su aplicable objetivo de la máquina / medio
ambiente en lo siguiente.
• OS unidad central: Se ejecuta en el com-

putadoras centrales e incluyen OS / 360,
OS / 390, AS / 400, MVS y VM.
• Sistema operativo del servidor: se ejecuta
en estaciones de trabajo o servidores e
incluye sistemas como UNIX, Win- dows,
Linux y VMS.
• OS multicomputer: se ejecuta en múltiples
ordenadores com- e incluyen ejemplos
tales como Novell Netware.
• ordenadores personales OS: se ejecuta en
computadoras personales, e incluyen
ejemplos tales como DOS, Windows, Mac
OS y Linux.
• OS dispositivo móvil: se ejecuta en
dispositivos personales como teléfonos
móviles, iPad e incluyen ejemplos de este
tipo de iOS, Android, Symbian, etc.
12. Fundamentos de bases de datos y gestión

de datos
[4 *, c9]
Una base de datos se compone de una

13-25
las relaciones entre los elementos de datos son base de datos relacional (RDBMS) implementa
importantes. Los factores considerados en el las distintas prestaciones del modelo relacional.
diseño de la base de datos incluyen Formance Un sistema de gestión de base de datos de objeto
per-, concurrencia, la integridad, y la (ODBMS) implementa las distintas prestaciones
recuperación de fallos de hardware. del modelo de objetos.
12.1. Entidad y de esquema
Las cosas una base de datos intenta modelar y

almacenar se denominan entidades. Las
entidades pueden ser objetos del mundo real,
como las personas, coches, casas, etc., o pueden
ser conceptos abstractos tales como las personas,
salario, nombres, y así sucesivamente. Una
entidad puede ser primitiva, tales como un
nombre o compuesto tal como un empleado que
consiste en un nombre, número de
identificación, el salario, dirección, y así
sucesivamente.
El concepto más importante en una base de
datos es el esquema, que es una descripción de
toda la estructura de la base de la cual se
construyen todas las demás actividades de base
de datos. Un esquema define los barcos relación
entre las diversas entidades que componen una
base de datos. Por ejemplo, un esquema de un
sistema de nómina de la compañía consistiría en
cosas tales como la identificación de empleado,
nombre, tipo de salario, dirección, y así
sucesivamente. software de base de datos
mantiene la base de datos de acuerdo con el
esquema.
Otro concepto importante en la base de datos
es el modelo de base de datos que describe el
tipo de tionship relación entre las diversas
entidades. Los modelos utilizados comúnmente
incluyen relacional, la red y modelos de objetos.
12.2. Sistemas de Gestión de Bases de Datos

(DBMS)
Sistema de gestión de base de datos (DBMS)

componentes incluyen aplicaciones de bases de
datos para el almacenamiento de los datos
estructurados y no estructurados y las funciones
de gestión de base de datos necesarios
necesarios para visualizar, recoger, almacenar y
recuperar datos de las bases de datos. Un DBMS
controla la creación, mantenimiento, y el uso
de la base de datos y por lo general se clasifica
de acuerdo con el modelo de base de datos que
soporta tales como el, la red o modelo de objeto
relacional. Por ejemplo, un sistema de gestión de
13-26 Guía SWEBOK® V3.0 aplicación escrita a máquina proto. También
12.3. Lenguaje de consulta de base de datos
se refiere al uso de cuarto de idioma o
Usuarios / aplicaciones interactúan con una aplicación de generación de erators
base de datos a través de un lenguaje de generaciones para desarrollar o generar
consulta de base de datos, que es un lenguaje código de programa.
de programación cializada espe- adaptados a la
utilización de bases de datos. El modelo de
base de datos tiende a determinar los lenguajes
de consulta que están disponibles para acceder
a la base de datos. Un lenguaje de consulta de
uso general para la base de datos relacional es
el lenguaje de consulta estructurado, más
comúnmente abreviado como SQL. Un
lenguaje de consulta común para bases Data-
de objetos es el lenguaje de consulta de objeto
(abreviado como OQL). Hay tres componentes
de SQL: Lenguaje de definición de datos
(DDL), Lenguaje de manipulación de datos
(DML) y el Lenguaje de control de datos
(DCL). Un ejemplo de una consulta DML
puede ser similar al siguiente:
SELECT Component_No,
Cantidad de Component
DONDE Item_No = 100
La consulta anterior selecciona todos los

Component_No y su cantidad correspondiente
de un componente de tabla de base de datos
llamada, donde el Item_No es igual a 100.
12.4. Tareas Los paquetes de DBMS
Un sistema DBMS proporciona las siguientes

capacidades:
• Las bases de datos se utiliza para definir y

organizar el contenido, las relaciones, y la
estructura de los datos necesarios para
construir una base de datos.
• la interrogación de bases de datos se
utiliza para acceder a los datos en una base
de datos para la recuperación de
información y generación de informes.
Los usuarios finales pueden recuperar de
forma selectiva y mostrar información y
producir informes impresos. Esta es la
operación que la mayoría de los usuarios
saben acerca de las bases de datos.
• Mantenimiento de base de datos se utiliza
para agregar, eliminar, actualizar y
corregir los datos en una base de datos.
• Desarrollo de aplicaciones se utiliza para
desarrollar prototipos de pantallas de
entrada de datos, consultas, formularios,
informes, tablas y etiquetas para una
13-27
12.5. Gestión de datos comunicaciones entre todos los ordenadores

conectados y puede dar la ilusión de un único
Una base de datos debe gestionar los datos equipo, omnipresente. Cada dispositivo puter o
almacenados en ella. Esta gestión incluye tanto com- conectado a una red se llama un nodo de
la organización y almacenamiento. red.
La organización de los datos reales en una Anumber de los paradigmas de computación han
base de datos depende del modelo de base de surgido
datos. En un modelo relacional, los datos se para beneficiarse de las funciones y capacidades
organizan en forma de tablas con diferentes
tablas que representan entidades o relaciones
diferentes entre un conjunto de entidades. El
almacenamiento de datos se refiere a la
conservación de estas tablas de bases de datos en
discos. Las formas más comunes para lograr esto
es utilizar los archivos. Secuencial, indexada, y
los archivos de hash se utiliza en toda esta
finalidad con diferentes estructuras de archivos
que proporcionan un rendimiento diferente
acceso y comodidad.
12.6. La minería de datos
A menudo se tiene que saber qué buscar antes de

consultar una base de datos. Este tipo de
“localización de” acceso no hace un uso
completo de la gran cantidad de información
almacenada en la base de datos, y de hecho
reduce la base de datos en una colección de
registros discretos. Para sacar el máximo
provecho de una base de datos, se puede llevar a
cabo el análisis estadístico y el patrón de dis-
covery sobre el contenido de una base de datos
utilizando una tecno- minería de datos llamados
nique. Tales operaciones se pueden utilizar para
apoyar una serie de actividades comerciales que
incluyen, pero no se limitan a, la
comercialización, la detección de fraudes y
análisis de tendencias.
Numerosas formas de realización de la
minería de datos se han inventado en la década
pasada e incluyen técnicas comunes tales como
descripción de la clase, la discriminación de
clase, análisis de conglomerados, análisis de
asociación, y el análisis de valores atípicos.
13. Conexión de red básica de comunicación

[8 *, c12]
Una red de ordenadores se conecta un conjunto

de equipos y permite a los usuarios de los
diferentes ordenadores compartir recursos con
otros usuarios. Una red facilita las
13-28 Guía SWEBOK® V3.0 componentes básicos hardware, incluyendo las
proporcionada por las redes de ordenadores.
Estos paradigmas incluyen computación computadoras, la red
distribuida, grid computing, computación
Internet, y la nube.
13.1. tipos de la Red
Las redes de ordenadores no todos son iguales

y pueden clasificarse de acuerdo a una amplia
variedad de características, incluyendo el
método de la red de conexiones ción,
tecnologías alámbricas, las tecnologías
inalámbricas, la escala, la topología de red,
funciones y velocidad. Sin embargo, la
clasificación que es familiar a la mayoría se
basa en la escala de las redes.
• Red de área personal / red doméstica es

una red de ordenador utilizado para la
comunicación entre la computadora (s) y
diferentes dispositivos tecnológicos infor-
mación cerca de una persona. Los
dispositivos conectados a una obra tal
NET pueden incluir ordenadores, faxes,
PDAs, y televisores. Esta es la base sobre
la que se construye el Internet de las cosas.
• Red de área local (LAN) conecta com-
putadoras y dispositivos en un área
geográfica limitada, como un campus de la
escuela, la oratoria en laboratorio
informático, edificio de oficinas, o grupo
de cerca posicionado de edificios.
• campus Red es una red de ordenadores
compuesto por una interconexión de redes
de área local (LAN) dentro de un área
geográfica limitada.
• Red de área amplia (WAN) es una red de
computadoras que cubre una gran área
geográfica, como una ciudad o país o
incluso a través de distancias
intercontinentales. Una WAN limitado a
una ciudad a veces se llama una Red de
Área Metropolitana.
• Internet es la red mundial que conecta los
ordenadores ubicados en muchos (tal vez
todos) los países.
Otras clasificaciones pueden dividir las redes

en las redes de control, redes de
almacenamiento, redes pri- vado virtuales
(VPN), redes inalámbricas, redes punto-a-
punto, e Internet de las Cosas.
13.2. Componentes de la Red Básica
Todas las redes se componen de los mismos

13-29
tarjetas de interfaz (NIC), puentes, la capa de red IP, pro Viding de mejor esfuerzo, el
concentradores, conmutadores y routers. Todos transporte no fiable (UDP) vs. función de
estos componentes se denominan nodos en la transporte confiable (TCP). protocolos de capa
jerga de las redes. Cada componente per- forma física incluyen token ring, Ethernet, Fast Ethernet,
una función distintiva que es esencial para el Gigabit Ethernet, y Ethernet inalámbrico. Datos
embalaje, la conexión, la transmisión, catión
amplifi-, controlando, desembalaje, y la
interpretación de los datos. Por ejemplo, un
repetidor amplifica las señales, un interruptor
realiza muchos-a-muchos conexiones, un
concentrador realiza uno-a-muchas conexiones,
una tarjeta de interfaz está conectado al
ordenador y realiza el embalaje de datos y de
transmisión, un puente conecta uno red con otro,
y un router es un ordenador en sí y realiza el
análisis de datos y control de flujo para regular
los datos de la red. Las funciones realizadas por
diversos componentes de la red corresponden a
las funciones especificadas por uno o más
niveles de la interconexión de sistemas abiertos
(OSI) modelo de red de siete capas,
que se discute a continuación.
13.3. Protocolos de red y Estándares
Las computadoras se comunican entre sí a través

de protocolos, que especifican las ciones de
formato y reglamentos utilizados para empacar y
datos no-carga. Para facilitar más fácil la
comunicación y la mejor estructura, protocolos
de trabajo Net- se dividen en diferentes capas y
cada capa se trata de un aspecto de la
comunicación. Por ejemplo, el ERS lay- físicos
se refieren a la conexión física entre las partes
que se han de comunicar, las ofertas de la capa
de enlace de datos con la transmisión de datos en
bruto y el control de flujo, y las ofertas de la
capa de red con el embalaje y un-
empaquetamiento de datos en un formato
particular que sea comprensible por los lazos
par- pertinentes. El modelo de red OSI más
comúnmente utilizado organiza protocolos de
red en siete capas, como se representa en la
figura 13.5.
Una cosa a tener en cuenta es que no todos los
cols de red proto implementan todas las capas
del modelo OSI. Por ejemplo, el protocolo TCP /
IP implementa ni la capa de presentación ni la
capa de sesión.
No puede haber más de un protocolo para
cada capa. Por ejemplo, UDP y TCP ambos
trabajan en la capa de transporte por encima de
13-30 Guía SWEBOK® V3.0 de amplia difusión.
protocolos de capa de enlace incluyen frame
relay, modo de transferencia asíncrona (ATM),
y el Protocolo de punto a punto (PPP). Los
protocolos de capa de aplicación incluyen
canal de fibra, Small Computer System
Interface (SCSI) y Bluetooth. Para cada capa o
incluso cada protocolo individual, puede haber
normas establecidas por las organizaciones
nacionales o internacionales para orientar el
diseño y desarrollo de los protocolos
correspondientes.
Capa de aplicación
Capa de
presentación
capa de sesión
Capa de transporte
Capa de red
Capa de enlace de
datos
Capa fisica
Figura 13.5. El modelo OSI de siete capas de redes
13.4. La Internet
El Internet es un sistema mundial de

interconectados gubernamental, académico,
empresarial, público y redes de ordenadores
privados. En el acceso al dominio público a
Internet es a través de las organizaciones
conocidas como proveedores de servicios de
Internet (ISP). La ISP mantiene uno o más
centros de conmutación llamado un punto de
presencia, que en realidad con- nects los
usuarios a Internet.
13.5. Internet de las Cosas
La Internet de las cosas se refiere al

establecimiento de una red de objetos
cotidianos-tales como automóviles, teléfonos
celulares, PDAs, televisores, refrigeradores, e
incluso edificios: el uso de las tecnologías de
redes cableadas o inalámbricas. La función y el
propósito de la Internet de las cosas es
interconectar todas las cosas para facilitar la
vida autó- MOU y mejor. Las tecnologías
utilizadas en el Internet de las cosas incluyen
RFID, inalámbricas y redes cableadas,
tecnología de sensores, software y mucho, por
supuesto. A medida que el paradigma de
Internet de las cosas todavía está tomando
forma, se necesita mucho trabajo para la
Internet de las cosas para ganar la aceptación
13-31
13.6. Virtual Private Network (VPN) computación distribuida estudia las formas de
dividir un problema en muchas tareas y la
Una red privada virtual es una conexión virtual asignación de estas tareas a varios equipos
planificada de antemano entre los nodos de una implicados en el cálculo.
red LAN / WAN o Internet. Permite al
administrador de red para separar el tráfico de
red en grupos de usuarios que tienen una
afinidad común por los demás, como todos los
usuarios de la misma organización o grupo de
trabajo. Este tipo de circuito puede mejorar el
rendimiento y la seguridad entre los nodos y
permite el mantenimiento de los circuitos fácil-
IER para solucionar problemas.
14. Computación Paralela y Distribuida

[8 *, c9]
La computación paralela es un paradigma de

computación que surge con el desarrollo de
unidades multi-cionales fun- dentro de un
ordenador. La principal tiva obje- de
computación en paralelo es para ejecutar varias
tareas simultáneamente en diferentes unidades
funcionales y por lo tanto mejorar el rendimiento
o la respuesta o ambos. La computación
distribuida, por el contrario, es un paradigma de
computación que surge con el desarrollo de las
redes informáticas. Su principal objetivo es o
bien hacer uso de varios ordenadores en la red
para llevar a cabo las cosas de otra manera no
posible en un único ordenador o mejorar la
eficiencia com- putation aprovechando el poder
de varios equipos.
14.1. Computación paralela y distribuida

general
Tradicionalmente, la computación paralela

investiga formas de maximizar la concurrencia
(la ejecución simultánea de múltiples tareas)
dentro del aria obligados- de un ordenador.
estudios de sistemas de computación distribuida,
que consiste en varios equipos autónomos que se
comunican a través de una red de ordenadores
distribuidos. Alternativamente, la informática
distribuida también puede referirse a la
utilización de sistemas distribuidos para resolver
problemas de cálculo o transaccionales. En la
definición anterior, la computación distribuida
investiga los protocolos, mecanismos y
estrategias que constituyen la base para el
cálculo distribuido; en esta última definición, la
13-32 Guía SWEBOK® V3.0 distribuida / paralelo, una cierta coordinación
Fundamentalmente, la informática
distribuida es otra forma de computación en entre las partes involucradas es nece- Essary
paralelo, aunque en una escala más grande. En para garantizar un comportamiento correcto del
computación distribuida, las unidades funcio- sistema.
nales no son ALU, FPU, o núcleos separados,
pero los ordenadores individuales. Por esta
razón, algunas personas consideran que el
cálculo distribuido por ser la misma que la
computación paralela. Debido a que tanto
distribuido la computación y en paralelo
implican algún tipo de concurrencia, que son a
la vez también llamado alquiler de
computación concurrente.
14.2. Diferencia entre la Computación

Paralela y distribuido
A pesar de la computación paralela y

distribuida resem- ble entre sí en la superficie,
hay una distinción sutil pero real entre ellos: la
computación en paralelo no se refiere
necesariamente a la ejecución de programas en
diferentes Computadoras- lugar, que se pueden
ejecutar en diferentes procesadores en un único
ordenador. De hecho, el consenso entre los
profesionales de computación limita el alcance
de la computación paralela al caso en que una
memoria compartida es utilizada por todos los
procesadores implicados en la computación,
mientras que la computación distribuida se
refiere a cálculos donde existe memoria
privada para cada procesador implicados en los
cálculos.
Otra diferencia sutil entre la computación
paralela y distribuida es que la computación
paralela hace necesario la ejecución simultánea
de varias tareas mientras computación
distribuida no tiene esta necesidad.
Basándose en la discusión anterior, es
posible clasificar sistemas concurrentes como
“paralelo” o “distribuido” en base a la
existencia o tencia nonex- de memoria
compartida entre todos los sor procesiones:
ofertas de computación en paralelo con los
cálculos dentro de una sola computadora;
distribuido ofertas de computación con
cálculos dentro de un conjunto de res computa-
. De acuerdo con este punto de vista, de
múltiples núcleos de computación es una forma
de computación paralelo.
14.3. Modelos de Computación

Paralela y Distribuida
Desde múltiples ordenadores / procesadores /

núcleos están involucrados en la computación
13-33
Las diferentes formas de coordinación dan lugar 15. Los factores humanos
a diferencias ent modelos de computación. Los básicos de los usuarios [3 *, c8] [9 *,
els mo- más comunes en este sentido son la c5]
memoria compartida (paralelismos
lel) modelo y el paso de mensajes (distribuido) memoria y el consenso entre todos los equipos
modelo. son los más ficult rencias. Muchos paradigmas de
En un modelo de memoria compartida computación se han inventado para resolver estos
(paralelo), todas las computadoras tienen problemas y son los principales puntos de
acceso a una memoria central compartida donde discusión en la computación distribuida / paralela.
se utilizan cachés locales para acelerar la
capacidad de procesamiento. Estas cachés
utilizan un protocolo para asegurar los datos
localizada es fresco y hasta la fecha, típicamente
el protocolo MESI. El diseñador algoritmo elige
el programa para su ejecución por cada equipo.
El acceso a la memoria central puede ser
síncrono o asíncrono, y debe ser coordinada de
tal manera que se mantiene la coherencia.
modelos de acceso diferentes se han inventado
para tal fin.
En un modelo de paso de mensajes
(distribuido), todos los equipos que ejecutan
algunos programas que permitan alcanzar
colectivamente algún propósito. El sistema debe
funcionar correctamente, independientemente de
la estructura de la obra NET. Este modelo se
puede clasificar además en cliente-servidor (C /
S), el navegador-servidor (B / S), los modelos y
de n niveles. En el modelo C / S, el pro servicios
y las solicitudes de los clientes de servicios
desde el servidor Vides servidor. En el B / S
modelo, el servidor de servicios de Vides pro y
el cliente es el navegador. En el modelo de n
niveles, cada nivel (es decir, capa) proporciona
servicios a la capa inmediatamente por encima
de ella y solicitudes de servicios desde el nivel
inmediatamente por debajo de ella. De hecho, el
modelo de n niveles puede ser visto como una
cadena de modelos cliente-servidor. A menudo,
los niveles entre el nivel más inferior y el nivel
superior se llaman middleware, que es un objeto
independiente de estudio por derecho propio.
14.4. Problemas principales en Distributed

Computing
La coordinación entre todos los componentes en

un entorno informático buido dis- es a menudo
complejo y requiere mucho tiempo. Como el
número de núcleos / CPUs / ordenadores
aumenta, la complejidad de la computación
distribuida también aumenta. Entre los muchos
problemas que enfrentan, la coherencia de la
El software V3.0para
se desarrolla satisfacer deseos
o necesidades humanas. Por lo tanto, todo el
diseño de software y desarrollo deben tener
en cuenta factores-usuario humano
consideración por ejemplo, cómo las personas
utilizan software, software de cómo la gente
ve, y lo que los humanos esperan de software.
Hay numerosos factores en la interacción
hombre-máquina, y 9241 serie ISO docu-
mento definen todas las normas detalladas de
tales interacciones. [10] Pero los factores
básicos para el usuario humano considerados
aquí incluyen entrada / salida, el manejo de los
mensajes de error y la robustez del software en
general.
15.1. Entrada y salida
La entrada y salida son las interfaces entre los

usuarios y el software. El software es inútil sin
entrada y salida. Seres humanos software de
diseño para procesar algunos de entrada y
producir una salida deseable. Todos los
ingenieros de software deben tener en cuenta la
entrada y OUT- poner como una parte integral
del producto de software que ingeniero o
desarrollan. Los temas considerados para la
entrada incluyen (pero no se limitan a):
• Lo que de entrada se requiere?

• ¿Cómo se pasa de la entrada de los
usuarios a las computadoras?
• ¿Cuál es el modo más conveniente para los
usuarios
introducciones?
• ¿Qué formato requiere el equipo de
los datos de entrada?
El diseñador debe solicitar los datos mínimos

de la intervención humana, sólo cuando los
datos aún no está guardada en el sistema. El
diseñador debe formatear y editar los datos en
el momento de la entrada para reducir los
errores derivados de la introducción de datos
incorrectos o maliciosos.
Para la salida, debemos tener en cuenta lo que
los usuarios
desear ver:
• ¿En qué formato se desea ver los usuarios

de salida?
• ¿Cuál es el modo más agradable a mostrar
¿salida?
13-35
Si la parte que interactúa con el software no es Sin embargo, los mensajes relacionados con
humana sino otro software o equipo o sistema de errores de acceso de seguridad no deben
control, entonces tenemos que considerar el proporcionar información adicional que ayude a
tipo de entrada / salida y el formato que el las personas no autorizadas minan.
software debe producir para garantizar el
intercambio de datos entre sistemas adecuada.
Hay muchas reglas de oro para los
desarrolladores a seguir para producir el bien de
entrada / salida para un software. Estas reglas
generales incluyen diálogo sencillo y natural,
hablando el lenguaje de los usuarios,
minimizando la carga de usuarios de la
memoria, la coherencia, la mínima sorpresa, la
conformidad con las normas (si lo acordado o
no: por ejemplo, los automóviles tienen una
interfaz Dard Están- de acelerador, el freno ,
dirección).
15.2. Error de mensajes
Es comprensible que la mayoría de software

contiene defectos y no de vez en cuando. Sin
embargo, los usuarios deben ser notificados si
hay algo que impide la correcta ejecución del
programa. Nada es más frustrante que una
terminación inesperada o desviación del
comportamiento del software sin ningún aviso o
explicación. Para ser fácil de usar, el software
debe informar de todos los condiciones de
error a los usuarios o aplicaciones de nivel
superior, de manera que hasta cierto punto se
puede tomar para rectificar la situación o para
salir con gracia. Existen varias pautas que
definen lo que constituye un buen mensaje de
error: mensajes de error deben ser claros, hasta
el punto, y oportuna.
En primer lugar, los mensajes de error deben
explicar claramente lo que está sucediendo para
que los usuarios sepan lo que está pasando en el
software. En segundo lugar, los sabios de error
men- deben determinar la causa del error, si es
posible, por lo que las acciones adecuadas se
pueden tomar. En tercer lugar, los mensajes de
error deben mostrarse justo cuando se produce la
condición de error. De acuerdo con Jakob
Nielsen, “Los buenos mensajes de error deben
expresarse en un lenguaje sencillo (sin códigos),
indican precisamente el problema y sugerir una
solución constructiva” [9 *]. En cuarto lugar, los
mensajes de error no deben sobrecargar los
usuarios con informa- ción demasiado y hacer
que se ignoran los mensajes de todos juntos.
13-36 Guía SWEBOK® V3.0 (documentación).
15.3. La robustez del software
robustez del software se refiere a la capacidad

de software para tolerar las entradas erróneas.
Software se dice que es robusta si sigue
funcionando incluso cuando se dan las entradas
erróneas. Por lo tanto, es inaceptable para el
software se bloquee simplemente cuando
encuen- tering un problema de entrada ya que
esto puede provocar consecuencias
inesperadas, como la pérdida de datos valiosos.
El software que exhibe tal comportamiento es
sidered con- carecer de robustez.
Nielsen da una descripción más simple de la
robustez del software: “El software debe tener
una baja tasa de error, por lo que los usuarios
hacen algunos errores durante el uso del
sistema y por lo que si lo hacen cometer
errores que pueden recuperarse fácilmente de
ellos. Además, los errores catastróficos no
deben ocurrir”[9 *].
Hay muchas maneras de evaluar la robustez
del software y al igual que muchas maneras de
hacer el software más robusto. Por ejemplo,
para mejorar la robustez, uno debe siempre
comprobar la validez de las entradas y valores
de retorno antes de progreso- ing aún más; uno
siempre debe lanzar una excepción cuando
ocurre algo inesperado, y uno nunca debe salir
de un programa sin antes dar a los usuarios /
aplicaciones la oportunidad de corregir la
condición.
16. Desarrollador básica factores humanos

[3 *, c31-32]
factores humanos desarrolladores se refieren a

las consideraciones de factores humanos
tomadas en el desarrollo de software. El
software se desarrolla por los seres humanos,
leídos por los seres humanos, y mantenido por
los seres humanos. Si Any-lo que está mal, los
seres humanos son responsables de Cor-
recting esos males. Por lo tanto, es esencial
para escribir software de una manera que sea
fácilmente comprensible por el ser humano o,
por lo menos, por otros desarrolladores de
software. Un programa que es fácil de leer y
entender la legibilidad exposiciones.
Los medios para garantizar que el software
de cumplir este objetivo son numerosas y van
desde la arquitectura adecuada a nivel macro al
estilo de codificación particular y el uso
variable en el nivel micro. Pero los dos factores
importantes son la estructura (o programa) y
los diseños de los comentarios
13-37
16.1. Estructura • Los comentarios deben ser coherentes en todo

el programa.
programas bien estructurados son más fáciles de • Cada función debe estar asociado con los
entender y modificar. Si un programa no está comentarios que explican el propósito de la
bien estructurado, entonces ninguna cantidad de función y su papel en el programa general.
explicación o comentarios es suficiente para que
sea comprensible. Las formas de organizar un
programa son numerosas y van desde el uso
adecuado de los espacios en blanco, la sangría, y
los paréntesis de buenos arreglos de
agrupaciones, las líneas en blanco, y los apoyos.
Sea cual sea el estilo que se elija, debe ser
consistente a través de todo el programa.
16.2. comentarios
Para la mayoría de la gente, la programación es

la codificación. Estas personas no se dan cuenta
que la programación también incluye
comentarios que escriben y que los comentarios
son una parte integral de la programación. Es
cierto que los comentarios no son utilizados por
el equipo y, desde luego, no constituyen las
últimas instrucciones para el ordenador, pero
mejoran la legibilidad de los programas,
explicando el significado y la lógica de los
estados o secciones de código. Debe recordarse
que los programas no sólo son para los
ordenadores, sino que también se leen, escriben,
y modificados por los seres humanos.
Los tipos de comentarios incluyen la
repetición del código, explicación del código,
marcador del código, resumen del código,
descripción de la intención del código, y la
información que no pueda ser posiblemente
expresada por el propio código. Algunos comen-
tarios son buenos, algunos no lo son. Los buenos
son los que explican la intención del código y
justificar por qué este código es la forma en que
lo hace. Los malos son repetición del código y la
información que indica Evant irrel-. Los mejores
comentarios son de código auto-documentación.
Si el código está escrito de manera clara y
precisa que su significado es proclamado uno
mismo, entonces no se necesita ningún
comentario. Pero esto es más fácil decirlo que
hacerlo. La mayoría de los programas no son
fáciles de entender y son a menudo difíciles de
leer y entender si no se dan los comentarios.
Aquí hay algunas pautas generales para la
escritura de comentarios:
13-38 Guía SWEBOK® V3.0 política y objetivos de seguridad en los
• Dentro de una función, los comentarios se
deben dar por cada sección lógica de requisitos de software, los cuales
codificación para explicar el significado y
propósito (intención) de la sección.
• Los comentarios deben estipular lo que
hace la libertad (o no) los programadores
de mantenimiento tienen con respecto a
realizar cambios en el código.
• Los comentarios son rara vez necesarios
para las declaraciones individuales. Si
necesita una declaración comentarios, se
debe reconsiderar el comunicado.
17. Asegurar el desarrollo y

mantenimiento de software
[11 *, c29]
Debido al aumento de las actividades

maliciosas dirigidas a los sistemas
informáticos, la seguridad se ha convertido en
un problema sig- sig- en el desarrollo de
software. Además de la exactitud y fiabilidad
de costumbre, los desarrolladores de software
también deben prestar atención a la seguridad
del software que desarrollan. desarrollo de
software seguro se basa en el software de
seguridad, siguiendo una serie de reglas y
prácticas establecidas reparados y / o daciones
en desarrollo de software. mantenimiento de
software seguro complementa el desarrollo de
software seguro asegurando se introducen los
problemas de seguridad durante el
mantenimiento del software.
Una vista en relación con la seguridad del
software generalmente aceptada es que es
mucho mejor para el diseño de seguridad en el
software de parchear que después se desarrolló
el software. Diseñar la seguridad en el
software, hay que tener en cuenta todas las
etapas del ciclo de vida de desarrollo de
software. En particular, el desarrollo de
software seguro implica software de seguridad
de los requisitos, la seguridad de diseño de
software, la seguridad de construcción de
software, la seguridad y pruebas de software.
Además, la seguridad también debe tenerse en
cuenta cuando se realiza el mantenimiento de
software como fallas de seguridad y lagunas
pueden ser ya menudo se introducen durante el
mantenimiento.
17.1. Requisitos de software de seguridad
Requisitos de software ofertas de seguridad

con la clarificación y la especificación de la
13-39
sienta las bases para consideraciones de construcción de software de seguridad en su

seguridad en el desarrollo de software. Los estado actual de refiere existencia-principalmente
factores a considerar en esta fase incluyen los con el segundo aspecto mencionado
requisitos de software y amenazas / riesgos. El anteriormente: la codificación de seguridad en el
primero se refiere a las funciones específicas que software.
se requieren para el bien de seguridad; Este La codificación de la seguridad en el software
último se refiere a las posibles formas en que se se puede lograr siguiendo las normas
ve amenazada la seguridad del software. recomendadas. Unos dichas reglas a continuación:
17.2. Diseño de Software de Seguridad
Ofertas de software de seguridad de diseño con

el diseño de módulos de software que encajan
entre sí para cumplir con los objetivos de
seguridad especificadas en los requisitos de
seguridad. Este paso aclara los detalles de las
consideraciones de seguridad y desarrolla los
pasos específicos para su implementación. Los
factores considerados pueden incluir marcos y
modos de acceso que se instalan las estrategias
de seguridad de supervisión / aplicación general,
así como los mecanismos de aplicación de
políticas individuales.
17.3. El software de seguridad de construcción
Software la seguridad de la construcción se

refiere a la cues- ción de cómo escribir código
de programación real para situaciones
específicas tales que las consideraciones de
seguridad son atendidos. El término
“Construcción de Software de Seguridad” puede
significar cosas diferentes para diferentes
personas. Puede significar la forma en que una
función específica está codificada, de manera
que la codificación en sí es seguro, o puede
significar la codificación de seguridad en el
software.
La mayoría de las personas se enredan los dos
juntos sin distinción. Una de las razones para tal
enredo es que no está claro cómo se puede
garantizar que una codificación específica es
seguro. Por ejemplo, en lenguaje C programa-
ción, la expresión de i << 1 (cambio de la
representación binaria del valor i de a la
izquierda de un bit) y 2 * i (multiplicar el valor
de la variable i por la constante 2) significa la
misma lo semánticamente, pero no tienen la
misma ramificación de seguridad? La respuesta
podría ser diferente para diferentes
combinaciones de las NIA y compiladores.
Debido a esta falta de entendimiento, la
13-40 Guía SWEBOK® V3.0 el desarrollo de software seguro, existen algunas
• Estructurar el proceso para que todas las
secciones que requieren privilegios pautas generales que se pueden utilizar para
adicionales son módulos. Los módulos ayudar a tales esfuerzos. Estas
deben ser lo más pequeña posible y se
deben realizar sólo aquellas tareas que
requieren esos privilegios.
• Asegúrese de que los supuestos en el
programa son validados. Si esto no es
posible, documento ellos para los
instaladores y mantenedores para que
sepan que los supuestos atacantes tratarán
de invalidar.
• Asegúrese de que el programa no
comparte objetos en la memoria con
cualquier otro programa.
• El estado de error de cada función debe ser
comprobado. No trate de recuperar a
menos que ni la causa del error ni sus
efectos afectan a las consideraciones de
seguridad. El programa debe restaurar el
estado del software al estado que tenía
antes de que comenzara el proceso, y
luego terminar.
17.4. El software de seguridad de Pruebas
Las pruebas de software de seguridad

determina que software protege los datos y
mantiene la seguridad ficación speci- como
algo dado. Para obtener más información,
consulte la Prueba de Software KA.
17.5. Construir Seguridad en Ingeniería de

Procesos de Software
El software es tan segura como su proceso de

desarrollo va. Para garantizar la seguridad del
software, la seguridad debe ser incorporado en
el software Engineer- proceso ing. Una
tendencia que surge en este sentido es la CEPT
asegurar el desarrollo del ciclo de vida (SDL)
con-, que es un modelo en espiral clásica que
tiene una visión integral de la seguridad desde
la perspectiva del ciclo de vida del software y
asegura que la seguridad es inherente en el
diseño y desarrollo de software, no es una idea
de último momento después de la producción.
El proceso SDL se demanda para reducir los
costes de mantenimiento de software y
aumentar la fiabilidad del software de concern-
ing fallos relacionados con la seguridad de
software.
17.6. Guía de seguridad de software
Aunque no hay maneras a prueba de balas para

13-41
directrices abarcan todas las fases del ciclo de 1. Validar entrada.

vida de desarrollo de software. Algunas líneas 2. Cuidado con las advertencias del
directrices de buena reputación son publicados compilador.
por el Equipo de Respuesta a Emergencias 3. El arquitecto y el diseño de las políticas de
Informáticas (CERT) y por debajo son las 10 seguridad.
mejores prácticas de seguridad de software (los 4. Mantenlo simple.
detalles se pueden encontrar en [12]: 5. Por defecto negar.
6. Observar el principio de privilegios
mínimos.
7. Desinfectar los datos enviados a otro
software.
8. la práctica de defensa en profundidad.
9. Utilizar técnicas eficaces de aseguramiento
de la calidad.
10. Adoptar un estándar de seguridad de
construcción de software.
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
1. Técnicas de S3.2
Resolución de ,
Problemas
1.1. Definicion S4.2
S3.2
de
La resolución
1.2. de
Formular el
problemas S3.2
problema real
1.3. Analizar el
S3.2
problema
1.4. Diseñar
una estrategia S4.2
de búsqueda de
soluciones
1.5. La resolución de
c5
problemas
Utilización de 5.4
2. programas
Abstracción
s5.2
2.1. Niveles de -
5.3
Abstracción s5.2
2.2. La -
S5.3
encapsulación
2.3. Jerarquía S5.2
3. Fundamentos
C6-19
de programación
3.1. El proceso
de programación C6-C19
3.2. Los paradigmas

C6-C19
de programación
3.3. La
c8
programación
4. defensiva
Principios
c6
básicos del
lenguaje de
4.1. Programación
programación S6.1
idioma general
4.2. Sintaxis y
semántica del
S6.2
lenguaje de
programación
13-43
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
4.3. Bajo nivel
s6.5-
de lenguaje de
6,7
programación
4.4. Alto Nivel
s6.5-
de
6,7
Programación
Lenguaje
4.5. frente a
declarativa s6.5-
lenguaje de 6,7
programación
5. imperativo
Herramientas de
c23
depuración y
Técnicas
5.1. Tipos de error s23.1
5.2. depuración
s23.2
técnicas:
5.3.
s23.5
Herramientas
6. de depuración
Estructura de 2.6
datos y s2.1-
representación
6.1. Estructura de 2.6
datos s2.1-
Visión de de
6.2. Tipos 2.6
conjunto
Estructuras de s2.1-
Datos
6.3. Las operaciones 2.6
en s2.1-
Estructuras de s1.1-
datos 1.3,
s3.3-
3.6,
s4.1-
4,8,
7. Algoritmos y s5.1-
Complejidad 5,7,
s6.1-
6.3,
s7.1-
7,6,
s11.1,
S12.1
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
7.1. Visión
s1.1-1.2
general de
algoritmos
7.2. Atributos de
S1.3
Algoritmos
7.3. Análisis
S1.3
algorítmico
s3.3-
3.6,
s4.1-
4,8,
s5.1-
7.4. Estrategias 5,7,
de diseño s6.1-
algorítmico 6.3,
s7.1-
7,6,
s11.1,
S12.1
s3.3-
3.6,
s4.1-
4,8,
s5.1-
7.5. Estrategias de 5,7,
análisis s6.1-
algorítmico 6.3,
s7.1-
7,6,
s11.1,
S12.1
8. Concepto básico
c10
de un sistema de
8.1. Propiedades
s10.1
del sistema
emergente
8.2. Ingeniería de
s10.2
sistemas
8.3. Descripción de
una
Sistema informático
13-45
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
9. Organización
C1-4
del ordenador
9.1.
Organización s1.1-1.2
general del
ordenador
9.2. Sistemas c3
digitales
9.3. lógica digital c3
9.4. Expresión de
c2
datos del
ordenador
9.5. La Unidad
4.2
Central de
s4.1-
Procesamiento
(CPU)
9.6. Organización
S4.6
del Sistema de
memoria
9.7. Entraday salida (I
S4.5
/ O)
10. Fundamentos del s6.4 S8.4
compilador
10.1. Compilador
S8.4
Visión de
conjunto
10.2. Interpretación
S8.4
y compilación
10.3. El proceso de
s6.4 S8.4
compilación
11. Fundamentos
c3
de Sistemas
Operativos
11.1. Operativo
S3.2
general Sistemas
11.2. tareas de
S3.3
Sistema operativo
11.3. Operando
S3.2
sistema
Abstracciones
11.4. Sistemas
para realizar la S3.1
clasificación
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
12. Conceptos
básicos de bases C9
de datos y
gestión de datosy
12.1. Entidad
S9.1
de esquema
12.2. Sistemas de
Gestión de Bases S9.1
de Datos
(DBMS)
12.3. Base de
S9.2
datos
Lenguaje dede
12.4. tareas
consulta S9.2
Los paquetes de
DBMS
12.5. Datos
s9.5
administración
12.6. La minería de s9.6
13.datos
Conexión de
red básica de c12
comunicación
13.1. Tipos de 12.3
Red s12.2-
13.2. Componentes
S12.6
de la Red Básica
13.3. Protocolos
s12.4-
de red y
12.5
Estándares
13.4. La Internet
13.5. Internet de
s12.8
las
Cosas
13.6. Red Privada
Virtual
14.
Computación C9
Paralela y
Distribuida
14.1.
Computación 9.4.3
paralela y s9.4.1-
distribuida
general
13-47
nully Lobur 2006 [8

Brookshear 2008
2011 [6 *]
2007 [5 *]
McConnell 2004
*] 2002
Voland 2003
Nielsen
1993 [9
HoRowitz et al.
SommervilLe
[11 *]
[2 *]
[4 *]
[3 *]
Bishop
nortea
*]
14.2. Las
diferencias entre 9.4.5
Computación s9.4.4-
Paralela y
Distribuida
14.3. Paralela y
9.4.5
Distribuida
s9.4.4-
Los modelos
informáticos
14.4. Problemas
principales en
Distributed
15.Computing
Los factores
c8 c5
humanos
básicos de los y
15.1. Entrada S5.1,
usuarios
salida S5.3
S5.2
15.2. Error de
,
mensajes
15.3. La s5.8
5.6
robustez del s5.5
16.software
Developer -
c31-32
básico Factores
Humanos
16.1. Estructura c31
16.2. comentarios c32
17. asegurar el
desarrollo y c29
mantenimiento de
software
17.1. DosAspectos de
s29.1
codificación segura
17.2.
Codificació s29.4
n de
Seguridad
17.3.
en Software s29.2
RequisitoSegurida
d17.4.
s29.3
Seguridad
diseño
17.5. Implementación
s29.5
Seguridad
Referencias
[1] Grupo de Trabajo Conjunto sobre [7] ISO / IEC / IEEE 24765: 2010 Sistemas y de
Computación planes de estudio, IEEE Ingeniería de Software-Vocabulario, ISO /
Computer Society y la Association for IEC / IEEE 2010.
Computing Machinery, Ingeniería de
Software 2004: Directrices Curriculares [8 *] L. y J. nulo Lobur, Lo Esencial de la
para Pregrado Programas de Grado en Organización de Computadores y
Ingeniería de Software, 2004; http: // sites. Arquitectura, 2ª ed., Jones and Bartlett
computer.org/ccse/SE2004Volume.pdf. Publishers, 2006.
[2 *] G. Voland, Ingeniería de Diseño, 2ª ed., [9 *] J. Nielsen, Ingeniería de usabilidad, Morgan

Prentice Hall, 2003. Kaufmann, 1993.
[3 *] S. McConnell, código completo, 2ª ed., [10] ISO 9241 a 420: 2011 ergonomía de la
Microsoft Press, 2004. interacción del sistema Human-, ISO, 2011.
[4 *] JG Brookshear, Ciencias de la [11 *] M. Bishop, Computer Security: Arte y

Computación:. Una visión general, 10ª ed, Ciencia, Addison-Wesley, 2002.
[12] RC Seacord, el CERT c Fije codificación
[5 *] E. Horowitz et al., Algoritmos de estándar, Addison-Wesley Professional,
ordenador, 2008.
2ª ed., Silicon Press, 2007.

Capítulo 14 fundamentos
matemáticos
ematical Matemáticas- para deducir de forma

INTRODUCCIÓN concluyente la verdad absoluta de ciertos
conceptos más allá de los números. En
profesionales de software en vivo con los
programas. En un lenguaje muy simple, se puede
programar sólo para algo que sigue una lógica
ambigua no bien entendida. El área de
Fundamentos del conocimiento matemático
(KA) ayuda a los ingenieros de software
comprender esta lógica, que a su vez se traduce
en código de lenguaje de programación. El ICS
mathemat- que es el objetivo principal en este
KA es muy diferente de la aritmética típica,
donde los números son tratados y discutidos. La
lógica y razonable ING son la esencia de las
matemáticas que un ingeniero de software debe
abordar.
Matemáticas, en cierto sentido, es el estudio
de los sistemas formales. La palabra “formal” se
asocia con precisión, por lo que no puede ser
cualquier interpretación ambigua o errónea de la
realidad. Por lo tanto, ics Mathemat- es el
estudio de todos y cada uno ciertas verdades
sobre cualquier concepto. Este concepto puede
ser acerca de los números, así como sobre los
símbolos, imágenes, sonidos, vídeo-casi
cualquier cosa. En resumen, no sólo números y
ecuaciones numéricas están sujetas a posibles
precisión. Por el contrario, un ingeniero de
software debe tener una abstracción precisa en
un dominio de aplicación diversa.
Guía del SWEBOK Matemática Foundation
ciones KA abarca las técnicas básicas para
identificar un conjunto de reglas para el
razonamiento en el contexto del sistema en
estudio. Cualquier cosa que se puede deducir
siguientes estas reglas es una certeza absoluta
en el contexto de dicho sistema. En este KA,
técnicas que se pueden representar y llevar
adelante el razonamiento y el juicio de un
ingeniero de software de una manera precisa (y
por lo tanto matemática) se definen y discutidos.
El lenguaje y los métodos de la lógica que se
discute aquí nos permiten describir pruebas
13-50 Guía SWEBOK® V3.0 palabras, es una
resumen, se puede escribir un programa para miembro del conjunto. Su negación está
un problema sólo si se sigue una cierta lógica. representado por
El objetivo de este KA es ayudar a desarrollar ∉, por ejemplo, 1 ∈ S, pero 4 ∉ S.
la habilidad de identificar y describir tal lógica. En una representación más compacta del
El énfasis está en ayudar a entender los conjunto usando la notación establecer
conceptos básicos más que en desafiar sus constructor, {x | P (x)} es el conjunto de todos
habilidades aritméticas. los x tales que P (x) para cualquier proposición P
(x) sobre cualquier universo de discurso.
DISTRIBUCIÓN DE TEMAS Ejemplos de algunos conjuntos importantes
PARA fundamentos matemáticos incluyen los siguientes:
El desglose de temas para los fundamentos N = {0, 1, 2, 3, ...} = el conjunto de no negativo

matemáticos KA se muestra en la figura 14.1. enteros.
Z = {..., -3, -2, -1, 0, 1, 2, 3, ...} = el conjunto de
1. Set, relaciones, funciones enteros.
[1 *, c2]
Conjunto finito e infinito. Un conjunto con un
Conjunto. Un conjunto es una colección de nú- mero finito de elementos se denomina un
objetos, llamado elementos del conjunto. Un conjunto finito. Por el contrario, cualquier
conjunto puede ser representado por listar sus conjunto que no tiene un número finito de ele-
elementos entre aparatos ortopédicos, por mentos en que es un conjunto infinito. El
ejemplo, S = {1, 2, 3}. conjunto de los números naturales, por ejemplo,
El símbolo ∈ se usa para expresar que un ele- es un conjunto infinito.
ción pertenece a un conjunto, o, en otras
14-1
Figura 14.1. Desglose de los temas de los fundamentos matemáticos KA
Cardinalidad. La cardinalidad de un conjunto denota

finito S es como X ⊄ Y.
el número de elementos en S. Esto se representa
| S |, por ejemplo, si S = {1, 2, 3}, entonces | S | Superconjunto. Si X es un subconjunto de Y,
= 3. entonces Y se llama
Conjunto universal. En general S = {x ∈ U | p un superconjunto de X. Esto se denota por Y ⊇ X,
(x)}, donde T es el universo de discurso en el que es decir, Y
debe interpretarse el predicado P (x). El “verso ⊇ X si y sólo si X ⊆ Y.
uniforme del discurso” de un predicado dado se Por ejemplo, si X = {1, 2, 3} y Y = {1, 2, 3,
refiere a menudo como el conjunto universal. 4, 5}, entonces Y ⊇ X.
Alternativamente, uno puede definir conjunto
universal como el conjunto de todos los
elementos.
Establecer la igualdad. Dos conjuntos son
iguales si y sólo si
tienen los mismos elementos, es
decir: X = Y ≡ ∀ p (p ∈ X ↔ p
∈ Y).
Subconjunto. X es un subconjunto del

conjunto Y, o X está contenido en Y, si todos los
elementos de X se incluyen en Y. Esto se denota
por X ⊆ Y. En otras palabras, X ⊆ Y si y
sólo si ∀ p (p ∈ X → p ∈ Y).
Por ejemplo, si X = {1, 2, 3} y Y = {1, 2, 3,
4, 5}, entonces X ⊆ Y.
Si X no es un subconjunto de Y, que se denota
como X Y.
Apropiado Subconjunto. X es un subconjunto
propio de Y (denotado por X ⊂ Y) si X es un
subconjunto de Y, pero no es igual a Y, es decir,
hay algún elemento en Y que no está en X.
En otras palabras, X ⊂ Y si (X ⊆ Y) ∧ (X ≠
Y). Por ejemplo, si X = {1, 2, 3}, Y = {1, 2, 3,
4}, y Z = {1, 2, 3}, entonces X ⊂ Y, pero X no
es un
adecuada subconjunto de Z. Establece X y Z son
conjuntos iguales.
Si X no es un subconjunto propio de Y, se
Fundamentos matemáticos 14-3
Conjunto vacio. Un conjunto sin elementos
se llama un conjunto vacío. Un conjunto vacío,
denotado por ∅ , también se conoce como un
conjunto nula o ineficaz.
Set de poder. El conjunto de todos los
subconjuntos de un conjunto X se llama el
conjunto potencia de X. Se representa como
℘ (X).
Por ejemplo, si X = {a, b, c}, entonces ℘ (X)
= {∅ ,
{A}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}}.
Si
| X | = N, entonces | ℘ (X) | = 2n.
Venn Diagramas. Venn diagramas son
resentations tantes gráficas de conjuntos como
áreas cerradas en el plano. Por ejemplo, en la
figura 14.2, el repre- rectángulo resiente el
conjunto universal y la región sombreada
representa un conjunto X.
Figura 14.2. Diagrama de Venn para el conjunto X
1.1. las operaciones Set
Intersección. La intersección de dos conjuntos

X e Y, denotado por X ∩ Y, es el conjunto de
elementos comunes tanto en X como Y.
En otras palabras, X ∩ Y = {p | (P ∈ X) ∧ (p
∈ Y)}. Como, por ejemplo, {1, 2, 3} ∩ {3, 4,
6} = {3}
Si X ∩ Y = f, entonces los dos conjuntos X e
Y se dijo
ser un par disjunta de conjuntos.
Un diagrama de Venn para intersección de La parte sombreada del diagrama de Venn en

conjuntos se muestra en la figura 14.3. La parte Fig- ure 14.5 representa el complemento
común de los dos conjuntos representa la conjunto de X.
intersección de conjuntos. Establecer diferencia o complemento relativa.
El conjunto de elementos que pertenecen a X del
sistema, pero no para establecer Y construye la
diferencia conjunto de Y de X. Esto se repre-
resentido por X - Y.
En otras palabras, X - Y = {p | (P ∈ X) ∧ (p ∉
Y)}.
Como, por ejemplo, {1, 2, 3} - {3, 4, 6} = {1,
2}. Puede probarse que X - Y = X ∩ Y'.
Figura 14.3. Intersección de conjuntos X e Y Conjunto diferencia X - Y se ilustra por la
región sombreada en la figura 14.6 el uso de un
Unión. La unión de dos conjuntos X e Y, diagrama de Venn.
denotado por X ∪ Y, es el conjunto de todos los
elementos, ya sea en X, o en Y, o en ambos.
En otras palabras, X ∪ Y = {p | (P ∈ X) ∨ (p
∈ Y)}. Como, por ejemplo, {1, 2, 3} ∪ {3, 4,
6} = {1, 2,
3, 4, 6}.
Figura 14.6. Diagrama de Venn para X - Y

Figura 14.4. Unión de conjuntos X e Y
Producto cartesiano. Un par ordinario {p, q}
Cabe señalar que | X ∪ Y | = | X | + | Y | - | X es un conjunto con dos elementos. En un
∩ Y |. conjunto, el orden de los elementos es
Un diagrama de Venn que ilustra la unión de irrelevante, por lo que {p, q} = {q, p}.
dos conjuntos se representa por la región En un par ordenado (p, q), el orden de
sombreada en la figura 14.4. ocurrencias de los elementos es relevante. Por lo
Complemento. El conjunto de elementos en el tanto, (p, q) ≠ (q, p) a menos que p = q. En
conjunto universal que no pertenecen a un general (p, q) = (s, t) si y sólo si p = s y q = t.
conjunto dado X se llama su conjunto Dados dos conjuntos X e Y, su producto
complemento X'. cartesiano X × Y es el conjunto de todos los
pares ordenados (p, q) tal que p ∈ X y q ∈ Y.
En otras palabras, X'= {p | (P ∈ U) ∧ (p ∉ X)}.
En otras palabras, X × Y = {(p, q) | (P ∈ X) ∧
(q
∈ Y)}.
Como por ejemplo, {a, b} x {1, 2} = {(a, 1), (a,
2),
(B, 1), (b, 2)}
1.2. Propiedades del Conjunto
Algunas de las propiedades y leyes de conjuntos

importantes se mencionan a continuación.
Figura 14.5. Diagrama de Venn para el complemento
Conjunto de X
1. Leyes asociativas: Fundamentos matemáticos 14-5
X ∪ (Y ∪ Z) = (X ∪ Y) ∪ Z
X ∩ (Y ∩ Z) = (X ∩ Y) Z ∩
2. La ley conmutativa: es una función. Sin embargo, si dibujamos una

X ∪ Y = Y ∪ XX ∩Y=Y∩X relación entre los nombres de los residentes y su
fecha de nacimiento con el nombre establecido
3. La ley distributiva: como dominio,
X ∪ (Y ∩ Z) = (X ∪ Y) ∩ (X ∪ Z)
X ∩ (Y ∪ Z) = (X ∩ Y) ∪ (X ∩ Z)
4. La ley de identidad:
X ∪ ∅ = XX ∩ U = X
5. Complementar Leyes:
X ∪ X'= UX ∩ X'= ∅
6. La ley Idempotent:
X ∪ X = XX ∩ X = X
7. La ley Bound:
X ∪ U = UX ∩ ∅ = ∅
8. La ley de absorción:
X ∪ (X ∩ Y) = XX ∩ (X ∪ Y) = X
9. La ley de De Morgan:
(X ∪ Y) '= X' ∩ Y '(X ∩ Y) '= X' ∪ Y'
1.3. Relación y función
Una relación es una asociación entre dos

conjuntos de información. Por ejemplo,
consideremos un conjunto de residentes de una
ciudad y sus números de teléfono. El
emparejamiento de los nombres con números de
teléfono correspondientes es una relación. Este
emparejamiento se ordena para toda la relación.
En el ejemplo ser conveniente examinar para
cada par, ya sea el nombre viene primero,
seguido del número de teléfono o a la inversa. El
conjunto de la que se extrae el primer elemento
se denomina dominio conjunto y el otro
conjunto se llama el conjunto rango. El dominio
es lo que empezar y es el rango de lo que se
termina con.
Una función es una relación de buen
comportamiento. Un R con relación (X, Y) se
comporta bien si la función de los mapas de cada
elemento del conjunto X de dominio a un solo
elemento del conjunto rango Y. Consideremos
conjunto de dominio X como un conjunto de
personas y dejar un margen establecido Y
almacenar sus números de teléfono. Suponiendo
que una persona puede tener más de un número
de teléfono, la relación que se considera que no
esto se convierte en una relación de buen
comportamiento y por lo tanto una función.
Esto significa que, mientras que todas las
funciones son las relaciones, no todas las
relaciones son funciones. En caso de una
función dada una x, se obtiene uno y
exactamente uno y para cada par ordenado (x,
y).
Por ejemplo, consideremos las dos relaciones
siguientes.
A: {(3, -9), (5, 8), (7, -6), (3, 9), (6, 3)}.
B: {(5, 8), (7, 8), (3, 8), (6, 8)}.
Son estas funciones, así?

En el caso de la relación A, el dominio es
todos los valores de x, es decir, {3, 5, 6, 7}, y
el rango es todo el
y-valores, es decir, {-9, -6, 3, 8, 9}.
Relación A no es una función, ya que hay
dos valores de rango diferentes, -9 y 9, para el
mismo valor de x de 3.
En el caso de la relación B, el dominio es
mismo que el de A, es decir, {3, 5, 6, 7}. Sin
embargo, el intervalo es de un solo elemento
{8}. Esto califica como un ejemplo de una
función incluso si todos los valores de x se
asignan a la misma-valor y. Aquí, cada valor
de x es distinto y, por tanto, la función se
comporta bien. Relación B puede ser
representada por la ecuación y = 8.
La característica de una función puede ser
verificada utilizando una prueba de la línea
vertical, que aparece a continuación:
Dada la gráfica de una relación, si se puede
dibujar una línea vertical que atraviesa el
gráfico en más de un lugar, entonces la
relación no es una función.
Figura 14.7. Prueba de la recta vertical para la

Función
En este ejemplo, las dos líneas L1 y L2

cortan el gráfico para la relación tres veces.
Esto significa que para el mismo valor de x,
hay tres valores de y diferentes para cada uno
de caso. Por lo tanto, la relación no es una
función.
2. La lógica leyes Idempotent:

básica [1 *, p ∨ p ≡ páginas ∧p≡p
c1]
2.1. Lógica proposicional

leyes de dominación:
Una proposición es una afirmación que es p ∨ T ≡ tp ∧F≡F
verdadera o falsa, pero no ambas. Vamos a
considerar frases declarativas de los que es
significativa para asignar cualquiera de los dos
valores de estado: verdadero o falso. Algunos
ejemplos de proposiciones se dan a
continuación.
1. El sol es una estrella

2. Los elefantes son mamíferos.
3. 2 + 3 = 5.
Sin embargo, a + 3 = b no es una propuesta,

ya que es ni verdadero ni falso. Depende de los
valores de las variables a y b.
La ley del medio excluido: Por cada sición
propues- p, o bien p es verdadera o falsa p es.
La ley de la contradicción: Por cada
proposición p ción, no es el caso de que p es
verdadera y falsa. La lógica proposicional es el
área de la lógica que se ocupa de proposiciones.
Una tabla de verdad muestra las relaciones entre
los valores de verdad de
proposiciones.
Una variable booleana es uno cuyo valor es
verdadero o falso. operaciones de bits equipo
corresponden a operaciones lógicas de variables
booleanas.
Los operadores lógicos básicos, incluyendo la
negación (¬ p), conjuntamente (p ∧ q),
disyunción (p ∨ q), exclusiva o (p q ⊕), e
implicación (p → q) son para ser estudiado.
proposiciones compuestas se pueden formar
usando diversos operadores lógicos.
Una proposición compuesto que es siempre
verdad es una tautología. Una proposición
compuesta que siempre es falsa es una
contradicción. Una proposición compuesta que
no es ni una tautología ni una contradicción es
una contingencia.
proposiciones compuestas que siempre tienen
el mismo valor de verdad se llaman lógicamente
equivalente (denotado por ≡). Algunos de los
Lences equivalencias comunes son:
leyes de identidad:
p ∧ t ≡ páginas ∨ F ≡ p
Ley doble negación:
¬ (¬ p) ≡ p
conmutativa:
p ∨ q ≡ q ∨ páginas ∧q≡q∧p
leyes asociativas:
(P ∨ q) ∨ r ≡ p ∨ (q
∨ r) (p ∧ q) ∧ r ≡ p
∧ (q ∧ r)
leyes distributivas:
p ∨ (q ∧ r) ≡ (p ∨ q) ∧ (p ∨ r)
p ∧ (q ∨ r) ≡ (p ∧ q) ∨ (p ∧ r)
las leyes de De Morgan:

¬ (p ∧ q) ≡ ¬ p ∨ ¬ q¬ (P ∨ q) ≡ ¬ p ∧ ¬ q
2.2. La lógica de predicados
Un predicado es una plantilla frase verbal que

describe una propiedad de los objetos o una
relación entre los objetos representados por las
variables. Por ejemplo, en la oración, la flor es
de color rojo, la plantilla es de color rojo es un
predicado. En él se describe la propiedad de
una flor. El mismo predicado puede ser
utilizado en otras oraciones también.
Los predicados se dan a menudo un nombre,
por ejemplo, “Red” o simplemente “R” pueden
ser usados para representar la cate predi- es de
color rojo. Suponiendo R como el nombre para
la cate predi- es rojo, frases que afirman un
objeto es del color rojo se puede representar
como R (x), donde x representa un objeto
arbitrario. R (x) es el x es de color rojo.
Cuantificadores permiten afirmaciones sobre
Lections COL- enteros de objetos en lugar de
tener que enumer-
comió los objetos por su nombre.
El cuantificador universal ∀ x afirma que
una sentencia es cierto para todos los valores
de la variable x.
Por ejemplo, ∀ X Tiger (x) → Mamífero (x)
significa todos los tigres son mamíferos.
El cuantificador existencial ∃ x afirma que
una tence sen- es cierto para al menos un valor
de la variable x.
Por ejemplo, ∃ x Tiger (x) → Man-Eater (x)
significa que existe al menos un tigre que es un
devorador de hombres.
Por lo tanto, mientras que la cuantificación
universal utiliza implicación, rally de la
cuantificación existencial natu- utiliza
conjuntamente.
Una variable x que se introduce en una [1 *, c1]

expresión lógica por un cuantificador está unido
al cuantificador de encerramiento más cercano. Una prueba de ello es un argumento que establece
Una variable se dice que es una variable libre si rigurosamente la verdad de un enunciado. Las
no es pruebas pueden estar a su vez representadas
unido a un cuantificador. formalmente como estructuras discretas.
Del mismo modo, en un lenguaje de
programación de bloques estructurados, una
variable en una expresión lógica se refiere al
cuantificador más cercano dentro de cuyo
ámbito aparece.
Por ejemplo, en ∃ x (Cat (x) ∧ ∀ x (Negro
(x))), x
en Negro (x) es universalmente cuantificados.
La expre- sión implica que existen gatos y todo
es negro.
La lógica proposicional se queda corto en la
representación de muchas afirmaciones que se
utilizan en ENCE y matemáticas equipo cien-.
También falla para comparar la equivalencia y
otros tipos de relación entre las proposiciones.
Por ejemplo, la afirmación de a es mayor que
1 no es una proposición porque uno no puede
deducir si es verdadero o falso sin conocer el
valor de a. Por lo tanto, la lógica de
proposiciones no puede hacer frente a este tipo
de frases. Sin embargo, estas afirmaciones
parecen bastante a menudo en las matemáticas y
queremos inferir en esas afirmaciones. Además,
el patrón involucrado en las siguientes dos
Lences equivalencias lógicas no puede ser
capturado por la lógica proposicional: “No todos
los hombres son fumadores” y cada una de estas
dos proposiciones se trata de forma
independiente en la lógica proposicional
“Algunos hombres no fuman.”. No hay ningún
mecanismo en la lógica de proposiciones para
averiguar si los dos son equivalentes entre sí.
Por lo tanto, en la lógica de proposiciones, cada
proposición equivalente es tratado
individualmente en lugar de tratar con una
fórmula general que cubre todas las
equivalencias colectivamente.
la lógica de predicados se supone que es una
lógica roso más pow- que aborde estos temas.
En un sentido, la lógica de predicados (también
conocido como lógica de primer orden o cálculo
de predicados) es una extensión de la lógica
sitional propues- a las fórmulas que implican
términos y predicados.
3. Técnicas de prueba
Fundamentos
Demostración por inducción. matemáticos 14-11
Demostración
Declaraciones utilizados en una prueba
incluyen axiomas y postulados que son por inducción se realiza en dos fases. En primer
esencialmente los supuestos subyacentes sobre lugar, la proposición se establecido para ser
estructuras matemáticas, las hipótesis del verdad para una base de caso-típicamente para la
teorema de ser probadas, y pre viamente
teoremas probadas.
Un teorema es una declaración que puede ser
mostrado para ser verdad.
Un lema es un teorema simple que se usa en
la prueba de otros teoremas.
Un corolario es una proposición que puede
ser establecido directamente de un teorema
que ha sido demostrado.
Una conjetura es una declaración, cuyo valor
de verdad es desconocida.
Cuando se encuentra una prueba de una
conjetura, la conjetura se convierte en un
teorema. Muchas veces las conjeturas se
muestran para ser falsa y, por lo tanto, no son
teoremas.
3.1. Métodos de demostración de teoremas
La prueba directa. prueba directa es una

técnica para establecer que la implicación p
→ q es cierto, mostrando que q debe ser
verdadera cuando p es verdadera.
Por ejemplo, para demostrar que si n es
entonces extraño n2-1 es aún, supongamos que
n es impar, es decir, n = 2k + 1 para algún
entero k:
∴ n2 = (2k + 1) 2 = 4K2 + 4k + 1.
A medida que los dos primeros términos de

la mano del lado derecho (RHS) son números
pares, independientemente del valor de k, de la
mano del lado izquierdo (LHS) (es decir, n2)
es un número impar. Por lo tanto, es aún N2-1.
Prueba por la contradicción. Una
proposición p es verdadera por la contradicción
de ser probadas sobre la base de la verdad de la
implicación ¬ p → q, donde q es una
contradicción. Por ejemplo, para mostrar que la
suma de 2x + 1 y 2y - 1 es par, considerar que
la suma de 2x + 1 y 2y - 1 es impar. En otras
palabras, 2 (x + y), que es un múltiplo de 2, es
impar. Esta es una contradicción.
Por lo tanto, la suma de 2x + 1 y 2y - 1 es par.
Una regla de inferencia es un patrón que se
establece que si un conjunto de premisas son
ciertas, entonces se puede deducir que una
determinada declaración conclusión es
verdadera. Las normas de referencia de
adición, la simplificación, y conjuntamente
necesitan ser estudiadas.
entero positivo 1. En la segunda fase, es estab-formas,

n2 y cuando estas actividades no pueden realizarse
en o el
cado que si la proposición es válida para un r mismo tiempo, entonces hay n + n maneras de
t hacerlo, ya12 sea
arbitrario número entero positivo k, entonces e
debe también mantener durante el próximo tarea.
número entero mayor, k + 1. En otras palabras,
demostración por inducción se basa en la regla • Si A y B son conjuntos disjuntos, entonces |
de inferencia que nos dice que la verdad de una A∪ B|=|A|
+ | B |.
secuencia infinita de proposiciones P (n), ∀ n ∈
• En general, si A1, A2, .... , An son disjuntos
[1 ... ∞] se establece si P (1) es verdadero, y en
conjuntos, entonces | A1 A2 ∪ ∪ ... ∪ An | =
segundo lugar, ∀ k ∈ [2 ... n] si P (k)
→ P (k + 1). | A1 | + | A2 |
Cabe señalar aquí que, para una demostración + ... + | An |.
por inducción ematical Matemáticas-, no se
supone que P (k) es verdadera para todos los Por ejemplo, si hay 200 atletas que realizan
números enteros positivos k. Probar una rem teo pruebas de velocidad y 30 atletas que participan
o proposición sólo nos requiere para establecer en el evento de salto de longitud, entonces
que si se supone P (k) es cierto para cualquier cuántas formas hay que elegir un atleta que es o
arbitraria entero positivo k, entonces P (k + 1) bien un velocista o un largo puente?
también es cierto. La corrección de la inducción Usando la regla de la suma, la respuesta sería
matemática como una técnica de prueba válida 200
está más allá de la discusión del texto Cur- + 30 = 230.
alquiler. Probemos el siguiente proposición La regla del producto establece que si una 1
tarea
1
puede ser t 2
usando hecho en maneras y una segunda tarea t se puede
inducción. n 2 hacer
Proposición: La suma de los primeros n Pos maneras después de la primera tarea que se
positivo impar ada ha hecho, a continuación,
números enteros P (n) es n2. hay n * n maneras de hacer el
Paso base: La proposición es verdadera para n 1 2
procedimiento.
= 1 como
P (1) = 12 = 1. La etapa de base es completa. • Si A y B son conjuntos disjuntos, entonces |
Paso inductivo: la hipótesis de inducción (IH) A×B|=
es que la proposición es verdadera para n = k, | A | * | B |.
siendo k una • En general, si A1, A2, ..., An son conjuntos
arbitraria entero positivo k. disjuntos, entonces | A1 A2 × × × ... Un | = |
A1 | * | A2 | * ....
∴ 1 + 3 + 5 + ... + (2k - 1) = k2 * | An |.
Ahora, es necesario demostrar que P (k) → P Por ejemplo, si hay 200 atletas que realizan
pruebas de velocidad y 30 atletas que participan
(k + 1). P (k + 1) = 1 + 3 + 5 + ... + (2k - 1) + en el evento de salto de longitud, entonces
¿Cuántas maneras hay para recoger dos atletas
(2k + 1) por lo que uno es un velocista y el otro es un
= P (k) + (2k + 1) saltador de longitud?
= K2 + (2k + 1) [usando IH] Usando la regla del producto, la respuesta
= K2 + 2k + 1 sería de 200 x 30 = 6000.
= (K + 1) 2 El principio de estados de inclusión-exclusión
que
si una tarea
1
t puede hacerse de
1
n maneras y una
segunda
2 2
Por lo tanto, se demuestra que si la T se puede hacer en maneras al mismo
proposición es verdadera tarea n tiempo
para n = k, entonces también es cierto para n = k con t, a continuación,Fundamentos matemáticos
para encontrar 14-13
el número
+ 1. total de
1
maneras las
El paso de base junto con el paso inductivo dos tareas se puede hacer, restar el número de
la prueba de que P (1) es verdadera y el maneras de hacer ambas 1
+ N.2
condicional tareas de n
declaración P (k) → P (k + 1) es verdadera para
todos positivos
K enteros. Por lo tanto, la proposición se • Si A y B no son disjuntos, | A ∪ B | = | A | +
prueba. | B | - | A ∩ B |.
4. Fundamentos de Conteo
[1 * En otras palabras, el principio de inclusión-
c6] exclusión tiene por objeto asegurar que los
objetos en la intersección de dos conjuntos no se
La regla de la suma indica que si una
1
tarea t se cuentan más de
puede hacer
Posa1 maneras y una segunda 2 se puede hacer una vez.
da tarea t de
recursividad es el término general para la 5. Los gráficos y los

práctica de la definición de un objeto en árboles [1 *, c10,
términos de sí mismo. Hay algoritmos c11]
recursivos, funciones definidas recursivamente,
relaciones, juegos, etc. 5.1. Los gráficos
Una función recursiva es una función que
llama
sí mismo. Por ejemplo, definimos f (n) = 3 * f (n Un gráfico G = (V, E) donde V es el conjunto de
- 1) vértices (nodos) y E es el conjunto de bordes.
para todo n ∈ N y n ≠ 0 y f (0) = 5. Los bordes también se conocen como arcos o
Un algoritmo es recursivo si se soluciona un enlaces.
problema reduciéndolo a una instancia de la
mismo problema con una entrada más pequeña.
Un fenómeno se dice que es al azar, si los
resultados individuales son inciertos, pero el
largo plazo golondrina Pat- de los muchos
resultados individuales es predecible.
La probabilidad de cualquier resultado de un
fenómeno dom ran- es la proporción de veces
que el resultado sería posible en un tiempo muy
larga serie de repeticiones.
La probabilidad P (A) de cualquier evento a
satisface 0
≤ P (A) ≤ 1. Cualquier probabilidad es un
número entre 0 y 1. Si S es el espacio de la Figura 14.8. Ejemplo de un gráfico
muestra en un modelo de probabilidad, el P (S)
= 1. Todos los posibles resultados F es una función que mapea el conjunto de
conjuntamente, deben tienen probabilidad de 1. aristas E a un conjunto de pares ordenados o no
Dos sucesos A y B son disjuntos si no tienen ordenados de elementos de V. Por ejemplo, en la
resultados en común y por lo tanto nunca pueden figura 14.8, G = (V, E) donde V
ocurrir juntos. Si A y B son dos sucesos = {A, B, C}, E = {e1, e2, e3}, y F = {(e1, (A,
disjuntos, P (A o B) = P (A) + P (B). Esto se C)), (e2, (C, B)), (e3, (B, A))}.
conoce como la regla ción adiciones para El gráfico de la figura 14.8 es un gráfico
eventos disjuntos. simple que consiste en un conjunto de vértices o
Si dos eventos no tienen resultados en común, nodos y un conjunto de aristas que conectan
la probabilidad de que uno u otro se produce es pares no ordenadas.
la suma de sus probabilidades individuales. Los bordes en gráficos simples no son
Permutación es un arreglo de objetos en los dirigidas. Tales gráficos también se conocen
que el orden es importante, sin repetición. Uno como no dirigida
puede elegir r elementos en un orden gráficos.
determinado a partir de una
total de n objetos mediante el uso de formas NP,
donde, np =
rr
¡norte! / (N - r) !. Varios notaciones como
r
NP y combinación. Uno puede elegir r objetos en
P (n, r) cualquier orden de un total de n objetos mediante
se utilizan para representar el número de el uso de formas NC, donde, NC = n! / [R! * (N -
permutaciones de un conjunto de n objetos r)]!.
tomados r a la vez.
La combinación es una selección de objetos en
los que el orden no importa sin repetición. Esto
es diferente de una permutación porque el orden
no es importante. Si el pedido sólo se cambia (y
no los miembros), entonces no se forma nueva
Por ejemplo, en la figura 14.8, (e1, (A, C)) Fundamentos matemáticos 14-15
puede
ser reemplazado por (e1, (C, A)) como el par
entre los vértices A y C es desordenada. Esto
vale para los otros dos bordes también.
En una multigrafo, más de un borde puede
con- Nect los mismos dos vértices. Dos o más
Connect- bordes ING entre el mismo par de
vértices pueden reflejar múltiples asociaciones
entre los mismos dos vértices. Tales bordes se
llaman paralelo o múltiples bordes.
Por ejemplo, en la figura 14.9, los bordes E3
y E4 son ambos entre A y B. La figura 14.9 es
una multigrafo donde los bordes E3 y E4 son
múltiples bordes.
Un grafo dirigido G = (V, E) se compone de

un conjunto de vértices V y un conjunto de
bordes E que son pares ordenados de elementos
de V. Un grafo dirigido puede con- bucles tain.
Por ejemplo, en la figura 14.11, G = (V, E),
donde V = {A, B, C}, E = {e1, e2, e3}, y F =
{(e1, (A,
C)), (e2, (B, C)), (e3, (B, A))}.
Figura 14.9. Ejemplo de un Multigraph
En una pseudógrafo, cantos conexión de un

nodo a sí mismo están permitidos. Tales bordes
son llamados bucles.
Figura 14.12. Ejemplo de un grafo ponderado
En un gráfico ponderado G = (V, E), cada

borde tiene un peso asociado a él. El peso de un
borde típicamente representa el valor numérico
asociado a la relación entre los correspondientes
dos vértices.
Por ejemplo, en la figura 14.12, se toman los
pesos para los bordes E1, E2, y E3 a ser 76, 93,
Figura 14.10. Ejemplo de un pseudógrafo y 15 respectivamente. Si los vértices A, B y C
representan tres ciudades en un estado, los
Por ejemplo, en la figura 14.10, el borde E4 pesos, por ejemplo, podrían ser las distancias en
ambos comienza y termina en B. Figura 14.10 es millas entre estas ciudades.
un gráfico en el que pseudo- e4 es un bucle. Sea G = (V, E) sea un grafo no dirigido con
borde conjunto E. A continuación, para un borde
∈ e E donde = {u, v}, a menudo se utilizan e los
siguientes terminologías:
• u, v se dice que son adyacentes o vecinos o

conectado.
• arista e es incidente con vértices u y v.
• arista e conecta uy v.
• vértices u y v son los puntos finales de la
arista e.
Si vértice v ∈ V, el conjunto de vértices en el

gráfico rected Gastos no dis-G (V, E), entonces:
Figura 14.11. Ejemplo de un grafo dirigido
• el grado de v, deg (v), es su número de
bordes incidente, excepto que cualquier
auto-bucles se cuentan dos veces.
• un vértice con grado 0 se denomina vértice

aislado.
• un vértice de grado 1 se llama un vértice
colgante.
Sea G (V, E) un grafo dirigido. Si e (u, v) es

un borde de G, a continuación, a menudo se
utilizan las siguientes terminologías:
Figura 14.13. Ejemplo de ciclos C34 y C
• u es adyacente a v, y v es adyacente de u.
• e trata de u y va a v. Una lista de adyacencia es una tabla con una
• E U se conecta a V, o correo va de u a v. fila por cada vértice, enumerando sus vértices
• el vértice inicial de e es u. adyacentes. La adyacencia listado para un grafo
• el vértice terminal de la e es v. dirigido mantiene una lista de los nodos
terminales para cada uno de los vértices en el
Si vértice v está en el conjunto de vértices para gráfico.
el grafo dirigido G (V, E), entonces Lista de
Vértic
adyacen
• en grados de v, deg-(V), es el número de e
cia
aristas que van a v, es decir, para el que v es UN ANTES
el vértice borne. DE
segundo ABC
CRIST
• grado de salida de v, deg+(V), es el número
de aristas que vienen de v, es decir, para el O
do A, B
que v es el vértice inicial.
• la licenciatura de v, deg (v) = deg-(V) + Figura 14.14. Listas de adyacencia para los gráficos de las
deg+(V), es el Figuras 14.10 y 14.11
vs suma de los grados de entrada y salida
grados. Por ejemplo, la figura 14.14 ilustra las listas
• un bucle en un vértice contribuye 1 a tanto decencia adja- para la pseudógrafo en la figura
grado dentro y fuera de grado de este 14.10 y el gráfico dirigido en la figura 14.11. A
vértice. medida que el cabo-grado de vértice C en la
figura 14.11 es cero, no hay ninguna entrada en
Se puede observar que, después de las contra de C en la lista de adyacencia.
definiciones anteriores, el grado de un nodo es sin Diferentes representaciones para una matriz
cambios si tenemos en cuenta sus bordes para ser gráfica similar de adyacencia, matriz de
dirigidos o no dirigidos. incidencia, y adyacencia listas-necesidad de ser
En un grafo no dirigido, un camino de estudiados.
longitud n de u a v es una secuencia de n bordes
adyacentes de vértice u al vértice v. 5.2. árboles
• Un camino es un circuito si u = v. Un árbol T (N, E) es una estructura de datos

• Un camino atraviesa los vértices a lo largo jerárquica de n
de ella. = | N | nodos con un nodo raíz especialmente
• Un camino es simple si no contiene ningún designado R mientras que los restantes n - 1
borde más de una vez. forman nodos subárboles en virtud de la R. nodo
raíz el número de bordes | E | en un árbol
Un ciclo en n vértices Cn para cualquier n ≥ 3 siempre sería igual a | N | - 1.
es un gráfico que PLE sim- o donde V = {v, v, ..., El subárbol en el nodo X es el subgrafo de la
r
v} y E = {{v, t
1 e2n1
v}, {v, v}, ..., {v, v}, {v, v}}. árbol que consiste en nodo X y sus descendientes
y
22 3n-1 nn 1
Por ejemplo, la figura 14.13 ilustra dos todos los bordes incidente a los descendientes.
ciclos de longitud 3 y 4. Como
14-18 Guía aSWEBOK®
alternativa V3.0
esta definición
recursiva, un árbol
se puede definir como un grafo no dirigido
conectado sin circuitos simples.
términos de número de saltos que se llama su

nivel. Los nodos en un árbol se encuentran en
diferentes niveles. El nodo raíz es
Figura 14.15. Ejemplo de un árbol de
Sin embargo, hay que recordar que un árbol es

estrictamente de naturaleza jerárquica, en
comparación con un gráfico, que es plana. En
caso de un árbol, un par ordenado se construye
entre dos nodos como padre e hijo. Cada nodo
hijo en un árbol está asociado con un único nodo
padre, mientras que esta restric- ción deja de
tener sentido para un gráfico donde no existe
asociación entre padres e hijos.
Un grafo no dirigido es un árbol si y sólo si
existe una trayectoria simple única entre
cualesquiera dos de sus vértices.
La figura 14.15 presenta un árbol T (N, E),
donde el conjunto de nodos N = {A, B, C, D, E,
F, G, H, I, J, K}.
El conjunto de aristas E es {(A, B), (A, C), (A,
D), (B, E),
(B, F), (B, G), (C, H), (C, I), (D, J), (D, K)}.
El padre de un nodo no raíz v es el único nodo
U con un borde dirigido de u a v. Cada nodo del
árbol tiene un nodo padre única excepción de la
raíz del árbol.
Por ejemplo, en la figura 14.15, nodo raíz A es
el nodo padre de los nodos B, C y D. De manera
similar, B es la matriz de E, F, G, y así
sucesivamente. El nodo raíz A no tiene ningún
padre.
Un nodo que tiene los niños se llama un nodo
interno.
Por ejemplo, en la figura 14.15, el nodo A o el
nodo B
son ejemplos de nodos internos.
El grado de un nodo en un árbol es el mismo
que el número de sus hijos.
Por ejemplo, en la figura 14.15, nodo raíz A y
su hijo B son ambos de grado 3. Los nodos C y
D tienen grado 2.
La distancia de un nodo desde el nodo raíz en
en el nivel 0. Alternativamente, el nivel de un
nodo X es la longitud de la trayectoria única de
la raíz del árbol al nodo X.
Por ejemplo, el nodo raíz A es en el nivel 0 en
Fig- ure 14,15. Los nodos B, C, y D son en el
nivel 1. Los nodos restantes en la figura 14.15
son todas en el nivel 2. La altura de un árbol es
el máximo de la lev-
els de nodos en el árbol.
Por ejemplo, en la figura 14.15, la altura de la
árbol es 2.
Un nodo se llama una hoja si no tiene hijos.
El grado de un nodo hoja es 0.
Por ejemplo, en la figura 14.15, los nodos E a
través
K son todos nodos de hoja con grado 0.
Los antepasados o predecesores de un nodo
no raíz X son todos los nodos en el camino
desde la raíz hasta el nodo X.
Por ejemplo, en la figura 14.15, los nodos A y
D
formar el conjunto de ancestros por J.
Los sucesores o descendientes de un nodo X
son todos los nodos que tienen X como su
antepasado. Para un árbol con n nodos, todos
los restantes n - 1 nodos son sucesores del
nodo raíz.
Por ejemplo, en la figura 14.15, el nodo B
tiene sucesores en E, F y G.
Si el nodo X es un antepasado del nodo Y, a
continuación, el nodo Y es un sucesor de X.
Dos o más nodos que comparten el mismo
nodo padre se llaman nodos hermanos.
Por ejemplo, en la figura 14.15, los nodos E
y G son hermanos. Sin embargo, los nodos E y
J, aunque desde el mismo nivel, no son
hermanos nodos.
Dos nodos hermanos son del mismo nivel,
pero dos nodos en el mismo nivel no son
necesariamente hermanos.
Un árbol se llama un árbol ordenado si la
posición relativa de las ocurrencias de los
nodos hijos es significativo.
Por ejemplo, un árbol es un árbol ordenado
si, por regla general, el nombre de un hermano
mayor siempre aparece antes (es decir, a la
izquierda de) el hermano más joven.
En un árbol desordenada, la posición relativa
de las ocurrencias entre los hermanos no
guarda ninguna importancia y puede ser
alterado de manera arbitraria.
Un árbol binario está formado con cero o
más nodos en los que hay una raíz nodo R y
todos los nodos restantes forman un par de
subárboles ordenados bajo el nodo raíz.
En un árbol binario, ningún nodo interno

puede tener más de dos hijos. Sin embargo, hay
que considerar que, además de este criterio en
términos del grado de los nodos internos, un
árbol binario es siempre ordenado. Si se
intercambian las posiciones de los subárboles
izquierdo y derecho para cualquier nodo en el
árbol, a continuación, un nuevo árbol se deriva.
Figura 14.18. Ejemplo de árboles binarios completos
Curiosamente, a raíz de las definiciones

Figura 14.16. Ejemplos de árboles binarios anteriores, el árbol de la figura 14.18 (b) es un
árbol binario completo, pero no completo como
Por ejemplo, en la figura 14.16, los dos nodo B ha sólo un niño en D. Por el contrario, el
árboles binarios son diferentes como las árbol de la figura 14.17 es un completo
posiciones de las apariciones de los niños de A -pero no completar binario árbol, como los hijos
son diferentes en los dos árboles. de B se producen en el árbol, mientras que los
hijos de C no aparecen en el último nivel.
Un árbol binario de la altura H está
equilibrado si todos sus nodos hoja ocurrir a
niveles H o H - 1.
Por ejemplo, los tres árboles binarios de las
Figuras
14,17 y 14,18 son árboles binarios equilibrados.
Hay a lo sumo 2H hojas en un árbol binario de
la altura H. En otras palabras, si un árbol binario
con hojas L es completa y equilibrada, a
continuación, su altura es H =
⎡log2L⎤.
Figura 14.17. Ejemplo de un árbol binario completo Por ejemplo, esta afirmación es cierta para el
dos árboles en las figuras 14,17 y 14,18 (a) ya
De acuerdo con [1 *], un árbol binario se que ambos árboles son completa y equilibrada.
llama un árbol binario completo si cada nodo Sin embargo, la expre- sión anterior no coincide
interno tiene exactamente dos hijos. con el árbol de la figura 14.18 (b) ya que no es
Por ejemplo, el árbol binario en la figura un árbol binario completo.
14.17 es un árbol binario completo, ya que Un árbol de búsqueda binaria (BST) es un tipo
ambos de los dos nodos internos A y B son de especial de árbol binario en el que cada nodo
grado 2. contiene un valor de clave distinta, y el valor de
Un árbol binario completo después de la la clave de cada nodo del árbol es menos de
definición todos los valores clave en su subárbol derecho y
anteriormente también se conoce como un árbol mayor que todos los valores clave en su subárbol
estrictamente binario. izquierdo. Un algoritmo de recorrido es un
Por ejemplo, ambos árboles binarios en la procedimiento para visitar de forma sistemática
figura 14.18 son árboles binarios completos. El todos los nodos de un árbol binario.
árbol de la figura 14.18 (a) es un un binario recorrido de árboles pueden definirse de forma
completo completa, así como recursiva.
Si T es un árbol binario con raíz R y el restante
nodos ing forman un par ordenado de izquierda no
nulo L R
árbol. Un árbol binario completo tiene todos sus niveles, subárbol T y no nulo
14-14 Guía
subárbol SWEBOK®
derecho de T V3.0 por debajo
de R,
con la posible excepción de la última, se llenó entonces el orden previo función preorder
hasta los topes. En caso de que el último nivel de traversal (T) se define como:
un árbol binario completo no está lleno, los
nodos se producen desde las posiciones más a la PREORDER (t) = R, PREORDER (T),
PREORDER (T)
izquierda disponibles. L R
... la ecuación. 1
El proceso recursivo de encontrar el recorrido aleatoriedad se ha definido en la sección 4 de

en preorden de los subárboles continúa hasta que este KA. A continuación, vamos a empezar con
los subárboles se encuentran para ser nulo. Aquí, los conceptos detrás de la distribución de
las comas se han utilizado como delimitadores probabilidad y la probabilidad discreta.
en aras de mejorar la legibilidad. Un modelo de probabilidad es una descripción
El orden posterior y en orden pueden ser matemática de un fenómeno aleatorio que consta
definidos de forma similar usando la ecuación. 2 de dos partes: un espacio de muestra S y una
y la ecuación. 3 respectivamente. forma de asignar probabilidades a los eventos. El
espacio de muestra define el conjunto de todos
Postorden (T) = postorden (T), postorden (T), los posibles resultados, mientras que un evento
es un subconjunto de un espacio muestral que
representa una posi-
LR
R ... la resultado ble o un conjunto de resultados.
ecuación 2
Finde (T) = finde (T), R, a finde (T ) …UN variable aleatoria es una función o regla que
LR
la asigna un número a cada resultado. Básicamente, se
ecuac es sólo un símbolo que representa el resultado de
ión 3 un experimento.
Por ejemplo, sea X el número de cabezas
cuando el experimento se lanzar una moneda n
veces. Del mismo modo, sea S la velocidad de
un coche, ya registrado en un detector de radar.
Los valores para una variable aleatoria podrían
ser Crete dis- o continua dependiendo del
experimento. Una variable aleatoria discreta
puede contener todos los resultados posible sin
perder ninguna, aunque
podría tener una cantidad infinita de tiempo.
Una variable aleatoria continua se utiliza para
asegurarse de medi- un incontable número de
valores, incluso si se le da una cantidad infinita
de tiempo.
Figura 14.19. Un árbol de búsqueda binaria
6. Probabilidad discreta
Por ejemplo, el árbol de la figura 14.19 es un [1 *, c7]
árbol binario de búsqueda (BST). Las salidas de
recorrido preorden, postorden, y en orden para la La probabilidad es la descripción matemática de
BST se dan a continuación en su orden aleatoriedad. definición básica de la probabilidad
respectivo. y
PREORDER salida: 9, 5, 2, 1, 4, 7, 6, 8, 13, 11,

10, 15
Postorden de salida: 1, 4, 2, 6, 8, 7, 5, 10, 11,
15,
13, 9
Dentro de la orden de salida: 1, 2, 4, 5, 6, 7, 8, 9,
10, 11,
13, 15
Más discusión en los árboles y su uso se ha

incluido en la sección 6, Estructura de Datos y
de re- presentación, de los Fundamentos de
Informática KA.
14-16 Guía
PorSWEBOK®
ejemplo,V3.0
si una variable aleatoria X
representa un resultado que es un número real
entre 1 y 100, entonces X puede tener un
número infinito de ues Val-. Uno nunca puede
enumerar todos los posibles resultados para X
incluso si se permite que una cantidad infinita
de tiempo. Aquí, X es una variable aleatoria
continua. Por el contrario, para el mismo
intervalo de 1 a 100, otro Y variable aleatoria
se puede utilizar para listar todos los valores de
número entero de la gama. Aquí, Y es una
variable aleatoria Creta dis-.
Una letra mayúscula, digamos X,
representará el nombre de la variable aleatoria.
Su contraparte minúscula, x, representará el
valor de la variable dom ran-.
La probabilidad de que la variable aleatoria X
se
igual x es:
P (X = x) o, más simplemente, P (x).
Una función de distribución de probabilidad

(densidad) es una tabla, fórmula, o un gráfico
que describe los valores de una variable
aleatoria y la probabilidad asociados con
estos valores.
Probabilidades asociadas con aleatoria discreta Estos números de hecho apuntan a derivar el
variables tienen las siguientes propiedades: valor de edad promedios a partir de
experimentos repetidos. Esto se basa en el único
i. 0 ≤ P (x) ≤ 1 para todo x fenómeno más importante de la probabilidad, es
ii. ΣP (x) = 1 decir, el valor promedio de los experimentos
repetidos es probable que sea próximo al valor
Una distribución de probabilidad discreta esperado de un experimento. Por otra parte, el
puede repre- tantes como una variable aleatoria valor medio es más probable que sea más
discreta. próximo al valor esperado de cualquier un
experimento como el número de experimentos
aumenta.
x 1 2 3 4 5 6
7. Máquinas de estados finitos
P 1/6 1/6 1/6 1/6 1/6 1/6 [1 *, c13]
(x)
Figura 14.20. Una función de probabilidad discreta para una Un sistema informático puede ser abstraído como
herramienta de laminación un mapeo de de estado a estado impulsado por
insumos. En otras palabras, un sistema puede ser
La media μ de un modelo de distribución de considerado como una función T transición: S × I
probabilidad es la suma de los términos de → S × O, donde S es el conjunto de estados y I, O
productos para eventos individuales y su son las funciones de entrada y de salida. Si el
probabilidad de resultado. En otras palabras, por estado conjunto S es finito (no infinita), el sis-
los posibles resultados x, x, ..., x tem se denomina una máquina de estados finitos
12n
(FSM).
en un espacio de k
es la probabilidad de Alternativamente, una máquina de estado finito
muestra S si p OUT- (FSM) es una
x llegado,
k
la media de la probabilidad sería abstracción μmathematical compuesto por una
finito
= XP11
+ XP22
+ ... + XP.
nn
número de estados y las transiciones entre las
Por ejemplo, la media de la densidad de estados. Si el dominio S × I es razonablemente
probabilidad para la distribución en la figura pequeño, entonces se puede especificar T
14.20 sería explícitamente usando diagramas similares a un
gráfico de flujo para ilustrar el
1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5 caminológicafluye para diferentes entradas. Sin
* (1/6) + 6 * (1/6) embargo, esto es prác- tica sólo para máquinas
= 21 * (1/6) = 3,5 que tienen una capacidad muy pequeña
información.
Aquí, el espacio de muestra se refiere al Un FSM tiene una memoria finita interna, una
conjunto de todos característica de entrada que lee símbolos en una
posibles resultados. secuencia y de una en una, y una entidad de
El s2 varianza de un modelo de probabilidad salida.
discreta El funcionamiento de una MEF inicia desde un
comienzo
es: s2 = 1 – μ)2p + (X – μ)2p + ... + (x - estado, pasa a través de transiciones en función de
(x ag ag μ)2pag entrada
1 2 2 k
. k
Las desviaciones estándar es la raíz cuadrada de 2 * (1/6) +
la varianza. (3 - 3.5) 2 * (1/6) + (4 - 3.5) 2 * (1/6) + (5 -
Por ejemplo, para la distribución de 3.5) 2 * (1/6) + (6 - 3,5) 2 * (1/6)]
probabilidad en = (6,25 + 2,25 + 0,25 + 0,5 + 2,25 + 6,25) *
Figura 14.20, el σ2 variación sería (1/6)
= 17,5 * (1/6)
s2 = [Resultados (1 - 3.5) 2 * (1/6) + (2 - 3.5) = 2.90
14-18 Guía SWEBOK® V3.0 a diferentes estados, y puede terminar en
∴ = desviación estándar s cualquier estado válido. Sin embargo, sólo unos
pocos de todos los estados marcan un flujo
exitoso de la operación. Estos se llaman aceptar
estados.
La capacidad de información de una MEF es
C = log | P |. Por lo tanto, si representamos una
máquina que tiene una capacidad de información
de bits C como un FSM, entonces su gráfica de
transición de estado tendrá | S | = Nodos 2C.
Una máquina de estado finito se define
formalmente como M
= (S, I, O, f, g, s).
0
S es el conjunto de estado;
yo es el conjunto de símbolos de entrada;
O es el conjunto de símbolos de salida;
F es la función de transición de estado;
gramo es la función de salida; La valores de transición y de salida de estado para

diferen-
y s 0 es el estado entradas ent en diferentes estados pueden ser
inicial. representados
utilizando una tabla de estados. La tabla de estado
para el FSM:
Dado un x de entrada ∈ I en estado Sk, la Figura 14.21 se muestra en la figura 14.22. Cada
FSM pareja
hace una transición al m
después de tran- en contra de un símbolo de entrada representa el
estado S a Estado
r
nuevo estado
función sición f y produce una
i
d
salida y ∈ O y el símbolo de salida.
usando la función de salida og. Por ejemplo, las Figuras 14.22 (a) y 14.22 (b)
son dos representaciones alternativas de la FSM
en Fig- ure 14,21.
8. gramáticas
[1 *, c13]
La gramática de una lengua natural nos dice si

una combinación de las palabras hace una
sentencia válida. A diferencia de los lenguajes
naturales, un lenguaje formal, se especifica
mediante un conjunto bien definido de reglas de
sintaxis. Las frases válidas de un lenguaje
formal puede ser descrito por una gramática con
Figura 14.21. Ejemplo de una FSM la ayuda de estas reglas, conocidas como reglas
de producción.
Por ejemplo, la figura 14.21 ilustra una FSM Un lenguaje formal es un conjunto de palabras
de longitud finita o cuerdas sobre algún alfabeto
finito, y una gramática especifica las reglas para
la formación de
con S 0 como el estado de como el estado estas palabras o cadenas. Todo el conjunto de
inicio y S 1
final. palabras
Aquí, S = {S, S, S}; I = {0, 1}; O = {2, 3}; f (S, Que son válidos para una gramática constituye el
len-
0120
0) = S, f (S, 1) = S, f (S, 0) = S, f (S, 1) = S, f (S , Indicador de la gramática. Por lo tanto, la gramática
G es
20112122
0) = S, f (S, 1) = S; g (S, 0) = 3, g (S, 1) = 2, G (S,alguna compacto, definición matemática
precisa de una
220001
0) = 3, g (S, 1) = 2, G (S, 0) = 2, G (S, 1) = actual 0 1 0 1
3.
122
S 3 2 S S
0 2 1
Estado Entrada S 3 2 S S
1 2 2
actual 0 1 S 2 3 S S
2 2 0
S S S
0 2 1
(segundo)
S S S
1 2 2
S S S Figura 14.22. Representación tabular de una MEF
2 2 0
(un)
Salida Estado
Estado
Entrada Entrada
lenguaje
14-20 Guía L en lugar
SWEBOK® V3.0 desólo una lista sin
procesar de todos
de frases o ejemplos de esas frases legales
de la lengua.
Una gramática implica un algoritmo que
genere todas las sentencias legales de la
lengua. Hay diferentes tipos de gramáticas.
A-estructura de la frase o de tipo 0
gramática G = (V, T, S, P) es un 4-tupla en
los que:
• V es el vocabulario, es decir, conjunto

de palabras.
• T ⊆ V es un conjunto de palabras
llamadas terminales.
• S ∈ N es una palabra especial llamado
el inicio
símbolo.
• P es el conjunto de reglas
producciones para sustituyéndolo por
un fragmento de frase para otra.
Existe otro conjunto N = V - T de

palabras llamado no terminales. Los no
terminales representan conceptos como
sustantivo. Las reglas de producción se
aplican en las cadenas que contienen no
terminales hasta que no haya más
símbolos no terminales están presentes en
la cadena. El símbolo inicial S es un no
terminal.
El lenguaje generado por una gramática 3. Cada CSG es una gramática-estructura de la

formal G, denotado por L (G), es el conjunto de frase (PSG).
todas las cadenas sobre el conjunto de alfabetos
V que se puede generar, puesta en ing con el Gramáticas sensibles al contexto: Todos los
símbolo de inicio, mediante la aplicación de fragmentos en el RHS son o bien más largo que
normas de pro- ducción hasta que todo el los fragmentos correspondientes en el LHS o
símbolos no terminales son sustituidos en la vacío, es decir, si b → a, entonces
cadena. | B | <| A | o a = ∅ .
Por ejemplo, sea G = ({S, A, a, b}, {a, b}, S, S Un lenguaje formal es sensible al contexto, si
{ una gramática sensible al contexto genera.
→ aA, S → b, A → aa}). En este caso, el Gramática de contextos libre: Todos los
conjunto de termina- nales son N = {S, A}, fragmentos en el LHS son de longitud 1, es
donde S es el símbolo inicial. Las tres reglas de decir, si A → a, entonces | A | = 1 para todos A
producción de la gramática se dan como P1: S ∈ N.
→ aA; P2: S → b; P3: A → AA. El término deriva libres de contexto desde el
La aplicación de las normas de producción en hecho de que A siempre puede ser sustituido por
todas las formas posibles, las siguientes palabras una, independientemente del contexto en el que
pueden ser generados a partir del símbolo de ocurre.
inicio. Un lenguaje formal es independiente del
contexto, si una gramática libre del contexto
S → aA (utilizando el símbolo de inicio P1) genera. lenguajes libres de contexto son la base
teórica para la sintaxis de los lenguajes de
→ aaa (usando P3) programación.
S → b (P2 utilizando el símbolo de inicio) La gramática regular. Todos los fragmentos
en el RHS son o bien terminales individuales o
un par construido por un terminal y un no
Nada más se puede derivar para G. Por lo terminal; es decir, si A → a, entonces o bien a ∈
tanto, el lenguaje de la gramática G consta de T, o a = CD, o a = Dc para c ∈ T, D ∈ N. Si a =
sólo dos palabras: L (g) = {aaa, b}. cD, entonces la gramática se llama una
gramática lineal derecha. Por otra parte, si a =
8.1. Reconocimiento idioma Dc, a continuación, la gramática se llama una
gramática lineal izquierda. Ambos
gramáticas formales pueden ser clasificados de la derecha y gramáticas lineales lineales
acuerdo a los tipos de producciones que se izquierda son regular la gramática o el Tipo-3.
permiten. La jerarquía de Chomsky (introducido El lenguaje L (G) generado por una gramática
por Noam Chomsky en 1956) describe un regular G se denomina un lenguaje regular.
esquema de dicha clasificación. Una expresión A regular es una cadena (o
patrón) formado a partir de los siguientes seis
piezas de informa- ción: a ∈ S, el conjunto de
alfabetos, E, 0 y las operaciones, o (+),
PRODUCTO, concatenación (.)
NACIÓN (*). El lenguaje de G, L (G) es igual a
todas aquellas cadenas que coinciden con G, L
(G) = {x ∈ S * | x} G partidos.
Para cualquier a ∈ S, L (A) = a; L (e) = {ε}; L

(0) = 0.
+ funciona como un o, L (A + B) = L (A) ∪ L
Figura 14.23. Jerarquía de Chomsky de (B).
gramáticas . crea una estructura de producto, L (AB) =
L (A). L (B).
Como se ilustra en la figura 14.23, inferimos * Denota la concatenación, L (A *) = {x xx ... |
la si-
14-22 Guía SWEBOK® V3.0 1 2n
lowing en diferentes tipos de xi L (A) ∈ y n ³ 0}
gramáticas:
1. Cada gramática regular es una gramática Por ejemplo, la expresión regular (ab) *
libre de contexto (CFG). coincide con el conjunto de cadenas: {e, ab,
2. Cada CFG es una gramática sensible al ABAB, ababab, ABABABAB, ...}.
contexto (CSG).
Por ejemplo, la expresión regular (aa) * 1N <x ≤ 2-n-1N. Los números reales que se
coincide con el conjunto de cadenas en una carta encuentran entre los huecos están representados
que tienen una longitud uniforme. por cualquiera de ING redonda (es decir, el
Por ejemplo, la expresión regular (aaa) * + representante más cercano exacta)
(aaaaa) * coincide con el conjunto de cadenas de
longitud igual a un múltiplo de 3 o 5.
9. Numéricos precisión, exactitud y errores

[2 *, c2]
El objetivo principal del análisis numérico es

desarrollar algoritmos eficientes para calcular
los valores numéricos de las funciones pre-Cise,
soluciones de ecuaciones algebraicas y
diferenciales, problemas de optimización, etc.
Una cuestión de hecho es que todos los
equipos digitales sólo pueden almacenar
números finitos. En otras palabras, no hay
manera de que una computadora puede
representar un gran número infinitamente-ya sea
un número entero, número racional, o cualquier
real o todos los números complejos (véase la
sección 10, Teoría de Números). Así las
matemáticas de aproximación es muy crítica
para manejar todos los números en el rango
finito que un ordenador puede manejar.
Cada número en un ordenador se le asigna un
ción PAR- o palabra, que consta de un número
especificado de dígitos binarios o bits. Una
palabra k de bits puede almacenar un total de N
= 2k números diferentes.
Por ejemplo, un equipo que utiliza 32 bits
aritmética puede almacenar un total de N = 232
≈ 4,3 × 109 números diferentes, mientras que
otro que utiliza 64 bits puede manejar N'= 264 ≈
1,84 × 1019 números diferentes. La cuestión es
cómo distribuir estas N números sobre la recta
real para la eficiencia máxima efi- y precisión en
los cálculos prácticos.
Una opción evidente es la de distribuir de
manera uniforme, dando lugar a aritmética de
coma fija. En este sistema, el primer bit en una
palabra se utiliza para representar un signo y los
bits restantes son tratados para ues enteros Val-.
Esto permite la representación de los números
enteros de 1 - ½N, es decir, = 1 - 2k-1 a 1. Como
un método de apareamiento aproximada, esto no
es bueno para los números no enteros.
Otra opción es el espacio de los números
estrechamente-dicen con una separación
uniforme de 2-n-y así distribuir el número total
N de manera uniforme sobre el intervalo -2-n-
14-24 Guía SWEBOK® V3.0 una regla de 15,5 mm con ± 0,5 mm máximo
o cortar (es decir, el representante exacto
inmediatamente debajo -OR anteriormente, si
es negativo-el número).
Los números que están más allá del rango
deben estar representados por el mayor número
(o más grande negativo) que puede ser
representado. Esto se convierte en un símbolo
de desbordamiento. Desbordamiento se
produce cuando un ción computacional
produce un valor mayor que el valor máximo
de la gama.
Cuando la velocidad de procesamiento es un
cuello de botella importante, el uso de las
representaciones de punto fijo es una
alternativa atractiva y más rápido que el de
punto flotante más engorroso aritmética más
comúnmente utilizado en la práctica.
Vamos definir un par de términos muy
importantes: la exactitud y precisión como
asociados con el análisis ical numer-.
Exactitud es la cercanía con la que un valor
calculado o Sured medi- está de acuerdo con el
valor real. Precision, por otro lado, es la
cercanía con la que dos o más medidos o
calculados valores para la misma sustancia
física de acuerdo entre sí. En otras palabras, la
precisión es la Cerrar-dad con la que un
número representa una exacta
valor.
Sea x un número real y sea x * sea una
aproximación. El error absoluto en la
aproximación x * x ≈ se define como | x * - x |.
El error relativo se define como la relación
entre el error absoluto con el tamaño de x, es
decir, | x * - x | / | x |, que asume x ¹ 0; de lo
contrario, no se define error relativo.
Por ejemplo, 1000000 es una aproximación a
1.000.001 con un error absoluto de 1 y un error
relativo de 10-6, mientras que 10 es una
aproximación de 11 con un error absoluto de 1
y un error relativo de
0.1. Típicamente, error relativo es más
intuitivo y el determinador preferida del
tamaño del error. La presente Convención es
que los errores son siempre
Geq 0, y son = 0 si y sólo si la aproximación
es exacta.
Una aproximación x * tiene k dígitos
significativos mal decisi su error relativo es
<5 × 10-k-1. Esto significa que los primeros k
dígitos de x * siguientes su primer dígito
distinto de cero son los mismos que los de x.
dígitos significativos son los dígitos de un
número que se sabe que ser correcta. En una
medición, se incluye un dígito incierto.
Por ejemplo, la medición de longitud con
error permisible tiene 2 dígitos significativos, que se pueden expresar como un cociente de dos
mientras que una medición de la misma longitud números enteros. El símbolo común para el
usando un calibrador y se registrará como 15,47 conjunto de todas las fibras No. de orden racional
mm con ± 0,01 mm error permisible mamá es Q.
maxi- tiene 3 dígitos significativos. Los números racionales pueden clasificarse en
tres tipos, en función de cómo actúan los
10. Teoría de los números decimales. los
[1 *, c4]
la teoría de números es una de las ramas más

antiguas de las matemáticas puras y uno de los
más grandes. Por supuesto, se trata de preguntas
acerca de los números, por lo general significa
números enteros y números fraccionarios o
racionales. Los diferentes tipos de números
incluyen número entero, el número real, número
natural, número complejo, número racional, etc.
10.1. Divisibilidad
Vamos a empezar esta sección con una breve

descripción de cada uno de los tipos anteriores
de los números, empezando por los números
naturales.
Números naturales. Este grupo de números
comienza en 1 y sigue: 1, 2, 3, 4, 5, y así
sucesivamente. Cero no es en este grupo. No hay
números negativos o fracciones cionales en el
grupo de los números naturales. El símbolo
matemático común para el conjunto de los
números naturales es N.
Números enteros. Este grupo tiene todos los
números natural en él más el número 0.
Por desgracia, no todo el mundo acepta las
definiciones anteriores de los números naturales
y enteros. No parece haber un acuerdo general
sobre si se debe incluir 0 en el conjunto de los
números naturales.
Muchos matemáticos consideran que, en
Europa, la secuencia de números naturales que
tradicionalmente se inició con 1 (0 ni siquiera
fue considerado para ser un número por los
griegos). En el siglo 19, situado teóricos y otros
matemáticos comenzaron la convención de
incluir a 0 en el conjunto de los números
naturales.
Enteros. Este grupo tiene todos los números
enteros en ella y sus negativos. El símbolo cal
matemáticamente común para el conjunto de
todos los números enteros es Z, es decir, Z =
{..., -3, -2, -1, 0, 1, 2, 3, ...}.
Numeros racionales. Estos son los números
decimales o no existen, por ejemplo, 15, o, d) por: a - d * ⎣ a / d⎦ , donde ⎣ a / d⎦ representa
cuando existen decimales, pueden terminar, la
como en 15.6, o pueden repetir con un patrón, piso del número real.
como en 1,666 ..., (que es 5/3). Sea Z+ = {N ∈ Z | n> 0} y a, b ∈ Z, m ∈ Z+,
Numeros irracionales. Estos son números Entonces a es congruente con b módulo m,
que no se pueden expresar como un número escrito como a ≡ b (mod m), si y sólo si m | a-b.
entero dividido por un número entero. Estos
números tienen decimales que nunca se
terminan y nunca se repiten con un patrón, por
ejemplo, PI o √2.
Numeros reales. Este grupo está formado por
todos los números racionales e irracionales.
Los números que se encuentran en el estudio
de álgebra son números reales. El símbolo
matemático común para el conjunto de todos
los números reales es R.
Los números imaginarios. Estos se basan en
el número imaginario i. Este número
imaginario es igual a la raíz cuadrada de -1.
Cualquier verdadero múltiple número de i es
un número imaginario, por ejemplo, i, 5i, 3.2i,
-2.6i, etc.
Números complejos. Un número complejo es
una combinación de un número real y un
número imaginario en la forma a + bi. La parte
real es una, y b se llama la parte imaginaria. El
símbolo ematical Matemáticas- común para el
conjunto de todas las fibras No. de orden
complejos es C.
Por ejemplo, 2 + 3i, 3-5i, 7,3 + 0i, y 0 + 5i.
Tenga en cuenta los dos últimos ejemplos:
7.3 + 0i es el mismo que el número real 7.3.
De este modo, todos los números reales son
números complejos con cero para la parte
imaginaria.
Del mismo modo, 0 + 5i es sólo el 5i número
imaginario. De este modo, todos los números
imaginarios son números complejos con cero
para la parte real.
La teoría de números elemental implica la
divisibilidad entre números enteros. Sean a, b
∈ Z con a ≠ 0. El expre- sión a | b, es decir,
que se divide una b si ∃ c ∈ Z: b = ac, es decir,
no es un número entero c tal que c veces a es
igual a b.
Por ejemplo, 3 | -12 es cierto, pero 3 | 7 es
falsa.
Si se divide una b, entonces se dice que a es
un factor de
segundo o a es un divisor de b, y b es un
múltiplo de a. b es par si y sólo si 2 | b.
Sean a, d ∈ Z con d> 1. A continuación, un
mod d denota
que el resto r desde el algoritmo de la división
con dividendo a y divisor d, es decir, el resto
cuando una se divide por d. Podemos calcular
(un mod
Alternativamente, a es congruente con b 11.1. Grupo

módulo m si y sólo si (a-b) m mod = 0.
Un conjunto S cerrado bajo una operación
10.2. Número primo, GCD binaria • forma un grupo si la operación binaria
satisface el seguimiento ing cuatro criterios:
Un número entero p> 1 es primo si y sólo si no
es el producto de dos números enteros mayores • Asociativa: ∀ a, b, c ∈ S, la ecuación (a • b)
que 1, es decir, p es primo si p> 1 ∧ ∃ ¬ a, b ∈ • c = a • (b • c) se mantiene.
N: a> 1, b> 1, a * b = p. • Identidad: Existe un elemento de identidad I
Los únicos factores positivos de un primo p es ∈
1 yp sí. Por ejemplo, los números 2, 13, 29, 61, S tal que para todo a ∈ S, I • a = a • I = a.
etc., son números primos. nonprime números • Inverse: Cada elemento a ∈ S, tiene una
enteros mayores que 1 se llaman números inversa a '∈ S con respecto a la operación
compuestos. Un número compuesto puede estar binaria, es decir, un • a' = I; Por ejemplo, el
compuesto por plying multi- dos números conjunto de los enteros Z con respecto a la
enteros mayores que 1. operación de suma es un grupo. El elemento
Hay muchas aplicaciones interesantes de de identidad del conjunto es 0 para la
números primos; entre ellos se encuentran el operación de adición. ∀ x ∈ Z, la inversa de
esquema de criptografía de clave pública, lo que x sería -x, que también se incluye en Z.
implica el intercambio de claves públicas que • propiedad Cierre: ∀ a, b ∈ S, el resultado de
contienen el producto p * q de dos números la
primos grandes aleatoria p y q (una clave • operación de un b ∈ S.
privada) que debe mantenerse en secreto por un • Un grupo que es conmutativa, es decir, un • b
partido determinado. b = • a,
El gcd máximo común divisor (a, b) de Gers que se conoce como una grupo conmutativo o
inte- a, b es el mayor número entero d que es un abeliano.
divisor tanto de A y de B, es decir,
El conjunto de números naturales N (con el
d = gcd (a, b) para max (d: d | a ∧ d | b) funcionamiento de adición) no es un grupo, ya
que no hay inversa para cualquier x> 0 en el
Por ejemplo, gcd (24, 36) = 12. conjunto de números naturales. Por lo tanto, se
Números enteros a y b se llaman primos entre viola la tercera regla (de inversa) para nuestra
sí o operación. Sin embargo, el conjunto de los
primos entre sí, si y sólo si su MCD es 1. números naturales tiene alguna estructura.
Por ejemplo, ni 35 ni 6 son primos, pero son Sets con una operación asociativa (la primera
primos entre sí, ya que estos dos números no condición anterior) se llaman semigroups; si
tienen factores comunes mayor que 1, por lo que también tienen un elemento de identidad (el
su MCD es 1. Un conjunto de números enteros X segundo ción condi-), entonces se les llama
= {i, i, ...} es relativamente monoides.
Nuestro conjunto de los números naturales es
bajo la adición
a continuación, un ejemplo de un monoide, una
12
estructura que
primo si todos los pares posibles i, i, h ≠ k dibujan No Fromis un grupo bastante porque falta el
HK
el conjunto X son primos entre sí. ningunos.
Por ejemplo, grupo, monoid, anillo, y celosía
11. Estructuras algebraicas son ejemplos de estructuras algebraicas. Cada una
de ellas se define en esta sección.
En esta sección se presenta un par de
representaciones utilizadas en álgebra superior.
Una estructura algebraica consiste en uno o dos
conjuntos cerrados bajo algunas operaciones y
que satisfacen una serie de axiomas, incluyendo
requisito
14-28 Guía de queV3.0
SWEBOK® cada elemento tiene una inversa
bajo la operación.
A monoid es un conjunto S que está cerrado
en una sola operación binaria asociativa • y
tiene un elemento de identidad I ∈ S tal que
para todo a ∈ S, I • a = a • I
= A. A monoid debe contener al menos un
elemento. Por ejemplo, el conjunto de números
naturales N forma un monoide conmutativo
bajo la adición con el elemento de identidad 0.
El mismo conjunto de números naturales N
también forma un monoide bajo la
multiplicación con el elemento de identidad 1.
El conjunto de Gers inte- positivos P forma una
monoide conmutativo bajo múltiples
plicatura con elemento de identidad 1.
Cabe señalar que, a diferencia de los de una
grupo,
elementos de un monoide no necesitan tener
inversas. UN
monoid también puede ser pensado como una 11.2. anillos

semigrupo con un elemento de identidad.
Un subgrupo es un grupo H contenida dentro Si tomamos un grupo abeliano y definimos un
de uno más grande, G, de tal manera que el segundo
elemento de identidad de 2
operación con dicho elemento, una nueva
estructura se encuentra que es
GRAMO está contenido en H, y 1
yh so diferente de sólo un grupo. Si esta segunda opera-
cuando h n
-1.
en H, entonces también1 2
yh Por lo tanto, el ción es asociativa y es distributiva sobre la
lo son h • h ele- 1
mentos de H, equipadas con la operación del En primer lugar, entonces tenemos un anillo.
grupo en Un anillo es un triple de la forma (S, +, •), donde
GRAMO restringido a H, en efecto formar un (S,
grupo. +) Es un grupo abeliano, (S, •) es un semigrupo, y
Dado cualquier subconjunto S de un grupo G, • es distributiva sobre +; es decir, “a, b, c ∈ S, la
el subgrupo generado por S se compone de ecuación ción a • (b + c) = (a • b) + (a • c)
productos de elementos de S y sus inversos. Es sostiene. Además, si
el subgrupo más pequeño de G que contiene S. • es conmutativo, entonces el anillo se dice que
Por ejemplo, sea G el grupo abeliano cuyos es conmutativa. Si hay un elemento de identidad
elementos son G = {0, 2, 4, 6, 1, 3, 5, 7} y cuya para el • funcionamiento, entonces el anillo se
operación de grupo es suma de módulo 8. Este dice que tiene una identidad. Por ejemplo, (Z, +,
grupo tiene un par de subgrupos no triviales: J = *), es decir, el conjunto de los enteros Z, con la
{0, 4} y H = {0, 2, 4, 6}, donde J es también un adición usual y multiplicación operaciones, es
subgrupo de H. en la teoría de grupos, un grupo un anillo. Como (Z, *) es conmutativo, este
cíclico es un grupo que puede ser generada por anillo es un anillo conmutativo o abeliano. El
un solo elemento, en el sentido que el grupo anillo tiene 1
tiene un elemento un (llamado el generador del como elemento de identidad.
grupo) de tal manera que, cuando se escribe Vamos en cuenta que la segunda operación no
multiplicativa, cada elemento del grupo es una puede tener un elemento de identidad, ni
poder de una. tenemos que encontrar un inverso para cada
Un grupo G es cíclico si G = {an para elemento con respecto a esta segunda operación.
cualquier número entero n}. Puesto que En cuanto a lo que significa la distribución, de
cualquier grupo generado por un elemento en un manera intuitiva que es lo que hacemos en
grupo es un subgrupo de dicho grupo, mostrando matemá- ticas elementales al realizar el siguiente
que el único subgrupo de un grupo G que cambio: una
contiene una es * (B + c) = (a * b) + (a * c).
en sí G es suficiente para mostrar que G es Un campo es un anillo para el que los
cíclico. elementos del conjunto, con exclusión de 0,
Por ejemplo, el grupo G = {0, 2, 4, 6, 1, 3, 5, forman un grupo abeliano con la segunda
7}, con respecto a la operación de adición operación.
módulo 8, es cíclico. El subgrupos J = {0, 4} y Un ejemplo simple de un campo es el campo
H = {0, 2, de los números gestionar racionalmente (R, +, *)
4, 6} también son cíclicos. con las operaciones de suma y multiplicación
habituales. Los números del formato a / b ∈ R,
donde a, b son números enteros y b ≠ 0. El
inverso aditivo de una fracción tal es
simplemente -a / b, y el inverso multiplicativo es
b / a condición de que a ≠ 0.
cheney y Kincaid 2007 [2

rosen 2011
[1 *]
*]
1. conjuntos, relaciones, funciones c2
2. Lógica Básica c1
3. Técnicas de prueba c1
4. Recuento básico c6
5. Los gráficos y los árboles c10, c11
6. probabilidad discreta c7
7. máquinas de estados finitos c13
8. gramáticas c13
9. numérica precisión, exactitud y errores c2
10. Teoría de Números c4
11. Estructuras algebraicas
Referencias EXPRESIONES DE GRATITUD
[1 *] K. Rosen, Matemática Discreta y sus El autor reconoce por suerte la contribución del
Aplicaciones, 7ª ed., McGraw-Hill, 2011. profesor Arun Kumar Chatterjee, Ex-Jefe del
Departamento de Matemáticas de la Universidad
[2 *] EW Cheney y DR Kincaid, Numéricos de Manipur, India, y el Prof. Devadata Sinha,
Matemáticas y Computación, 6 ª ed., Ex-Jefe del Departamento de Ciencias de la
Brooks / Cole, 2007. Computación y Engineer- ing, Universidad de
Calcuta, India, en la preparación de este capítulo
sobre Fundamentos matemáticos.
FUNDAMENTOS DE
INGENIERÍA Capítulo 15
SIGLAS efectivamente es un objetivo de todos los

ingenieros en todas las disciplinas de inge- niería.
CANALL Diseño asistido por ordenador
A Capability Maturity Model DISTRIBUCIÓN DE TEMAS PARA
CMMI
Integration FUNDAMENTOS DE INGENIERÍA
pdf Función de densidad de
probabilidad El desglose de los temas para la Ingeniería
PMF Función de probabilidad
Fundamentos KA se muestra en la figura
RCA Análisis Causa Raíz 15.1.
programas 1. Métodos empíricos y técnicas
experimentales
de manera eficiente y de ingeniería
INTRODUCCIÓN
IEEE define la ingeniería como “la aplicación de

un enfoque sistemático, disciplinado,
cuantificable a las estructuras, máquinas,
productos, sistemas o procesos” [1]. En este
capítulo se describen algunas de las habilidades
básicas de ingeniería y técnicas que son útiles
para un ingeniero de software. La atención se
centra en los temas que apoyan otros KAs
mientras minimizando la duplicación de los
temas tratados en otra parte de este documento.
A medida que la teoría y la práctica de la
ingeniería de software madura, es cada vez más
evidente que la ingeniería de software es una
disciplina de ingeniería que se basa en el
conocimiento y las habilidades common a
todas las disciplinas de ingeniería. Esta área de
conocimiento Fundamentos inge- niería (KA) se
ocupa de los fundamentos técnicos que se
apliquen a la ingeniería de software y otras
disciplinas de ingeniería. Temas de esta KA
incluyen métodos empíricos y técnicas
experimentales; análisis estadístico; medición;
diseño de ingeniería; modelado, prototipado y la
simulación; normas; y análisis de la causa raíz.
La aplicación de este conocimiento, en su caso,
permitirá a los ingenieros de software para
desarrollar y mantener el software de manera
más eficiente y efectiva. Com- pletar su trabajo
[2 *, c1] en los esfuerzos de ingeniería están diseñados,
estudios observacionales y estudios
Un método de ingeniería para la resolución de retrospectivos. Breves descripciones de los com-
problemas implica proponer soluciones o métodos utilizados comúnmente se dan a
modelos de soluciones y luego la realización continuación.
de experimentos o ensayos para estudiar las
soluciones o modelos propuestos. Por lo tanto, 1.1. experimento diseñado
los ingenieros deben entender cómo crear un
iment exper- y luego analizar los resultados del Un experimento diseñado o controlada es un
experimento con el fin de evaluar la solución investiga- ción de una hipótesis comprobable
propuesta. Los métodos empíricos y técnicas donde una o más variables independientes son
experimentales ayudan al ingeniero para manipuladas para medir su efecto sobre una o
describir y entender la variabilidad en sus más variables dependientes. Una condición
observaciones, para identificar las fuentes de previa para la realización de un experimento es
variabilidad, y para tomar decisiones. la existencia de una hipótesis clara. Es
experimentos tres tipos diferentes de importante para un ingeniero para entender
estudios empíricos com- utilizan comúnmente cómo formular hipótesis claras.
15-1
Figura 15.1. Desglose de los temas de los Fundamentos de Ingeniería KA
experimentos diseñados permiten a los 2. Análisis

ingenieros para determinar de forma precisa estadístico [2 *, c9s1, C2S1] [3 *,
cómo se relacionan las variables y, en concreto, c10s3]
si una causa-efecto
existe relación entre ellos. Cada combinación de eventos futuros, o para identificar tendencias. La
valores de las variables independientes es un calidad de los resultados del análisis dependerá de
tratamiento. Los experimentos simples tienen la calidad de la información contenida en los
sólo dos tratamientos que representan dos datos archivados. Los datos históricos pueden ser
niveles de una variable independiente GLE incompleta, inconsistente medido, o incorrecta.
pecado (por ejemplo, usando una herramienta
frente a no usar una herramienta). surgen Más
diseños experimentales complejas cuando se
utilizan más de dos niveles, más de una variable
independiente, o cualquier variables
dependientes.
1.2. Estudio observacional
Un estudio observacional o caso es una

investigación empírica que hace observaciones
de los procesos o fenómenos dentro de un
contexto de la vida real. Mientras que un
experimento ignora deliberadamente contexto,
un estudio de observación o caso incluye
contexto como parte de la observación. Un
estudio de caso es más uso- ful cuando el foco
del estudio está en cómo y por qué preguntas,
cuando el comportamiento de los participantes
en el estudio no puede ser manipulada, y cuando
las condiciones contextual son relevantes y los
límites entre el fenómeno y el contexto no son
claras.
1.3. Estudio retrospectivo
Un estudio retrospectivo implica el análisis de

his- datos tórica. Los estudios retrospectivos son
también conocidos como los estudios históricos.
Este tipo de estudio utiliza datos (en relación
con algún fenómeno) que se ha archivado en el
tiempo. Estos datos archivados se ana-
continuación lisó en un intento de encontrar una
relación entre las variables, para predecir
Con el fin de llevar a cabo sus Fundamentos de ingeniería 15-3
responsabilidades, ingenieros deben entender
cómo las diferentes características del producto
y de proceso varían. Los ingenieros a menudo
se encuentran con situaciones en las que la
relación entre las diferentes variables debe ser
estudiado. Un punto importante a destacar es
que la mayoría de los estudios se llevan a cabo
sobre la base de muestras y por lo que los
resultados observados necesita ser entendido
con respecto a la población completa. Los
ingenieros deben, por lo tanto, desarrollar una
comprensión adecuada de ING técnicas
estadísticas para la recogida de datos fiables en
cuanto a la toma de muestras y análisis para
llegar a resultados que pueden generalizarse.
Estas técnicas se discuten a continuación.
2.1. Unidad de análisis (unidades de

muestreo), Población y Muestra
Unidad de Análisis. Mientras lleva a cabo

cualquier estudio cal empíricamente, las
observaciones deben hacerse en unidades sen
CHO- llamados las unidades de análisis o las
unidades de muestreo. La unidad de análisis
debe ser identificado y debe ser apropiado para
el análisis. Por ejemplo, cuando una empresa
de productos de software quiere encontrar la
utilidad percibida de un producto de software,
el usuario o la función de software pueden ser
la unidad de análisis.
Población. El conjunto de todos los
encuestados o artículos (posibles unidades de
muestreo) para ser estudiado formas la
población. Como ejemplo, considere el caso de
estudio de la usabilidad percibida de un
producto de software. En este caso, el conjunto
de todos los posibles usuarios forma la
población.
Si bien la definición de la población, se debe
tener cuidado para comprender la población de
estudio y objetivo. Hay casos en que la
población estudiada y la población para la cual
el
resultados están siendo generalizadas pueden ser una variable aleatoria se llama un evento.
diferentes. Por ejemplo, cuando la población de Supongamos que X denota algún variable
estudio consta de sólo el pasado observaciones y aleatoria; entonces, por ejemplo, podemos definir
generalizaciones son necesarios para el futuro, la diferentes eventos tales como X ³ X <x x o y así
población estudiada y la población objetivo sucesivamente.
puede no ser la misma.
Muestra. Una muestra es un subconjunto de la
población. La cuestión más crucial para la
selección de una muestra es su representatividad,
incluyendo el tamaño. Las muestras deben
extraerse de una manera a fin de asegurar que
los sorteos son independientes, y las reglas de
dibujo de las muestras deben ser definidos pre-
de modo que la probabilidad de seleccionar una
unidad de muestreo ticular par- se conoce de
antemano. Este método de selección de las
muestras se llama muestreo probabilístico.
Variable aleatoria. En la terminología
estadística, el proceso de hacer las observaciones
o las mediciones en las unidades de muestreo
que se estudian se conoce como la realización
del experimento. Por ejemplo, si el experimento
es lanzar una moneda 10 veces y luego contar el
número de veces que la moneda cae en cabezas,
cada 10 lanzamientos de la moneda es una
unidad de muestreo y el número de cabezas de
una muestra dada es la observación o el
resultado para el experimento. El resultado de un
experimento se obtiene en términos de números
reales y define la variable aleatoria en estudio.
Por lo tanto, el atributo de los artículos que se
mide en el resultado del experimento representa
la variable aleatoria que se está estudiando; la
observación obtenido a partir de una unidad de
muestreo particular es una realización particular
de la variable aleatoria. En el ejemplo de la
sacudida de la moneda, la variable aleatoria es el
número de cabezas observados para cada
experimento. En estudios estadísticos, se hacen
intentos para entender características de la
población sobre la base de muestras.
El conjunto de posibles valores de una
variable aleatoria puede ser finito o infinito pero
numerable (por ejemplo, el conjunto de todos los
números enteros o el conjunto de todos los
números impares). En tal caso, la variable
aleatoria se llama una variable aleatoria Creta
dis-. En otros casos, la variable aleatoria bajo
consideración puede tomar valores en una escala
continua y que se llama una variable aleatoria
continua.
Evento. Un subconjunto de valores posibles de
Fundamentos
densidad y tiene que integrarse endeuningeniería 15-5
rango para
Distribución de una variable aleatoria. La
gama y el patrón de variación de una variable obtener la probabilidad de que los continuos
aleatoria está dada por su distribución. Cuando variabilidad aleatoria capaces mentiras entre
se conoce la distribución de una variable ciertos valores. Por lo tanto, si el pdf
aleatoria, es posible calcular la probabilidad de
cualquier evento. Algunos las distribuciones se
encuentran a ocurrir comúnmente y se utilizan
para modelar muchas variables aleatorias que
se producen en la práctica en el contexto de la
ingeniería. Algunas de las distribuciones que se
producen más comúnmente se dan a
continuación.
• distribución Binomial: utilizado para

modelar variables aleatorias que cuentan el
número de éxitos en n ensayos llevados a
cabo independientemente una de otra,
donde cada ensayo resultados en el éxito o
fracaso. Hacemos una suposición de que la
posibilidad de obtener un éxito permanece
constante [2 *, c3s6].
• distribución de Poisson: se utiliza para
modelar el conteo de ocurrencia de un
evento con el tiempo o en el espacio [2 *,
c3s9].
• La distribución normal: se utiliza para
modelar variables aleatorias OU
continuidades o variables aleatorias
discretas mediante la adopción de un
número muy grande de valores [2 *, c4s6].
Concepto de parámetros. Una distribución

estadística se caracteriza por algunos
parámetros. Por ejemplo, la proporción de
éxito en cualquier ensayo dado es el único
parámetro que caracteriza una distribución
binomial. Del mismo modo, la distribución de
Poisson se caracteriza por una tasa de
ocurrencia. Una distribución normal se
caracteriza por dos parámetros: a saber, su
media y la desviación estándar.
Una vez que se conocen los valores de los
parámetros, la distribución de la variable
aleatoria es completamente conocido y la
posibilidad (probabilidad) de cualquier evento
puede ser calculado. Las probabilidades para
una variable aleatoria discreta se pueden
calcular a través de la función de masa de
probabilidad, llamado el PMF. El PMF se
define en puntos discretos y le da al punto de
masa, es decir, la probabilidad de que la
variable aleatoria se llevará a ese valor
particular. Del mismo modo, para una
variabilidad aleatoria continua capaz, tenemos
la función de densidad de probabilidad,
llamado el pdf. El pdf es muy parecido a la
o PMF se conoce, las posibilidades de la posible tamaño del error o propiedades

variabilidad aleatoria capaz teniendo cierto estadísticas del compañero de estimación punto.
conjunto de valores pueden ser calculadas Por lo tanto, necesitan un suplemento de una
teóricamente. estimación puntual con el tamaño de la muestra,
Concepto de estimación [2 *, c6s2, c7s1, así como la varianza de la estimación. Como
c7s3]. Los verdaderos valores de los parámetros alternativa, podríamos utilizar una estimación de
de una distribución son generalmente intervalo. Una estimación de intervalo es un
desconocidas y necesitan ser estimada a partir de intervalo aleatorio con el li- inferior y superior del
las observaciones de la muestra. Las intervalo de sus siendo funciones de la muestra
estimaciones son funciones de los valores de la
muestra y se llaman estadísti- cas. Por ejemplo,
la media de la muestra es una estadística y puede
ser utilizado para estimar la media poblacional.
Del mismo modo, la tasa de aparición de
defectos de estimación se aparearon de la
muestra (tasa de defectos por línea de código) es
una estadística y sirve como la estimación de la
tasa de población de tasa de defectos por línea
de código. El estadístico utilizado para estimar
algún parámetro pobla- ción se refiere a menudo
como el estimador del parámetro.
Un punto muy importante a tener en cuenta es
que los resultados de los mismos estimadores
son aleatorios. Si tomamos una muestra
diferente, es probable que obtener una
estimación diferente del parámetro de la
población. En la teoría de estimación, es
necesario entender las diferentes propiedades de
los estimadores -en particular, la cantidad de las
estimaciones pueden variar a través de muestras
y cómo elegir entre diferentes modos
alternativos para obtener las estimaciones. Por
ejemplo, si deseamos estimar la media de una
población, podríamos utilizar como nuestro
estimador de la media de una muestra, una
mediana de la muestra, un modo de muestra, o la
gama media de la muestra. Cada uno de estos
estimadores tiene diferentes propiedades
estadísticas que pueden impactar el error
estándar de la estimación.
tipos de las estimaciones [2 *, c7s3, c8s1]
.Hay dos tipos de estimaciones: a saber, las
estimaciones puntuales y las estimaciones de
intervalo. Cuando se utiliza el valor de una
estadística para estimar un parámetro de la
población, se obtiene una estimación puntual.
Como su nombre indica, una estimación puntual
da un valor en puntos de la param eter está
estimando.
Aunque a menudo se utilizan las estimaciones
puntuales, que dan cabida a muchas preguntas.
Por ejemplo, no se nos dice nada acerca de la
Fundamentos de ingeniería 15-7
observaciones, así como el tamaño de la
muestra. Los límites se calculan sobre la base
de algunas suposiciones con respecto a la
distribución de muestreo de la estimación
puntual en que se basan los límites.
Propiedades de los estimadores. Varias
propiedades estadísticas de los estimadores se
utilizan para decidir sobre la conveniencia de
un estimador en una situación dada. Las
propiedades más importantes son que es un
estimador imparcial, eficiente y coherente con
respecto a la población.
pruebas de hipótesis [2 *, c9s1] .A hipótesis
es una declaración acerca de los posibles
valores de un eter param. Por ejemplo,
supongamos que se afirma que un nuevo
método de desarrollo de software reduce la
aparición de defectos. En este caso, la hipó-
tesis es que la tasa de aparición de defectos se
ha reducido. En las pruebas de hipótesis,
decidimos-sobre la base de las observaciones
de la muestra, ya sea un propuesto hipótesis
debe ser aceptada o rechazada. Para la prueba
de hipótesis, se forman las hipótesis nula y 0
alternativa. La hipótesis nula es la hipótesis de 1
no cambio y se denota como H. La hipótesis
alternativa se escribe como H. Es importante
tener en cuenta que la hipótesis alternativa
puede ser unilateral o bilateral. Por ejemplo, si
tenemos la hipótesis nula de que la media
poblacional no es menor que un cierto valor
dado, la hipótesis alternativa sería que es
inferior a ese valor y que tendría una prueba
unilateral. Sin embargo, si tenemos la hipótesis
nula de que la media poblacional es igual a un
valor determinado, la hipótesis alternativa sería
que no es igual y que tendría una prueba
bilateral (debido a que el valor real podría ser
menor que o mayor que el valor dado). Con el
fin de probar alguna hipótesis, primero se com-
pute alguna estadística. Junto con el cálculo de
la estadística, una región se define de tal
manera que en caso de que el valor calculado
de la estadística cae en esa región, se rechaza la
hipótesis nula. Esta región es llamada la región
crítica (también conocido como el intervalo de
confianza). En las pruebas de hipótesis,
tenemos que aceptar o rechazar la hipótesis
nula sobre la base de las pruebas obtenidas.
Observamos que, en general, la hipótesis
alternativa es la hipótesis de interés. Si el valor
calculado de la estadística no cae dentro de la
región crítica, entonces no podemos rechazar la
hipótesis nula. Esto indica que no hay
suficiente evidencia para
cree que la hipótesis alternativa es verdadera.
A medida que se toma la decisión sobre la entre las variables es perfecto, es decir,
base de las observaciones de la muestra, los
errores son posibles; los tipos de tales errores se
resumen en la tabla siguientes.
Decisión estadística
Natural
eza aceptar H rechazar H
0 0
Su error tipo I
0
DE
ciert (probabilidad =
AC
o
Su errorUE
tipo II a)
0
DE
falso (probabilidad
RD =
AC
b) O UE
En la prueba de hipótesis, nuestro RD objetivo es
maximizar la potencia de la prueba (el O valor de
1-b), mientras que fin de • asegurar que la
probabilidad de un error de tipo I (el valor de a)
se mantiene dentro de una de valor particular,
típicamente de 5 por ciento .
Es de notar que la construcción de una prueba
de hipótesis estadística incluye la identificación
(s) para estimar el parámetro (s) y que define
una región crítica de tal manera que si el valor
calculado de la estadística cae en la región
crítica, el hypoth nula - se rechaza ESIS.
2.2. Conceptos de correlación y regresión

[2 *, c11s2,
c11s8]
Un objetivo principal de muchas investiga-

ciones estadísticos es establecer relaciones que
hacen que sea posible para predecir una o más
variables en función de otras. Aunque es
deseable para predecir una cantidad exactamente
en términos de otra cantidad, es posible dom
SEL- y, en muchos casos, tenemos que estar
satisfechos con la estimación de los valores
medios o esperados.
La relación entre dos variables se IED estu-
utilizando los métodos de correlación y de
regresión. Estos dos conceptos se explican
brevemente en los siguientes párrafos.
Correlación. La fuerza de la nave
PARENTESCO lineal entre dos variables se
mide utilizando el coeficiente de correlación. Si
bien el cálculo del coeficiente de correlación
entre dos variables, se supone que estas
variables miden dos atributos diferentes de la
misma entidad. El coeficiente de correlación
toma un valor entre -1 a +1. Los valores -1 y 1
indican una situación en la que la asociación
dado el valor de una variable, la otra puede
estimarse sin error. Un coeficiente de
correlación positivo indica una relación que
positiva es, si una variable aumenta, también lo
hace la otra. Por otro lado, cuando las variables
tienen una correlación negativa, un aumento de
un conduce a una disminución de la otra.
Es importante recordar que la correlación no
implica causalidad. Por lo tanto, si se
correlacionan dos variables, no podemos
concluir que uno causa el otro.
Regresión. El análisis de correlación sólo
mide el grado de relación entre dos variables.
El análisis para encontrar la relación entre dos
variables se denomina análisis de regresión. La
fuerza de la relación entre dos variables se
mide utilizando el coeficiente de
determinación. Este es un valor entre 0 y 1.
Cuanto más cerca el coeficiente es de 1, mayor
es la relación entre las variables. Un valor de 1
indica una relación perfecta.
3. Medición
[4 *, c3s1, c3s2] [5 *, c4s4] [6 *, c7s5]
[7 *, p442-447]
Saber qué medir y qué método de medición

ción a utilizar es crítica en los esfuerzos de
ingeniería. Es importante que todos los
involucrados en un proyecto de ingeniería
entender los métodos de medición y los
resultados de la medición que se utilizarán.
Las medidas pueden ser, tal ambien- física,
económica, operacional, o algún otro tipo de
medida que sea significativo para el proyecto
en particular. Esta sección explora la teoría de
la medi- surement y la forma en que es
fundamental para Engineer- ing. La medición
se inicia como una conceptualización entonces
se mueve de conceptos abstractos a las
definiciones del método de medición para la
aplica- ción real de que el método para obtener
un resultado de la medición. Cada uno de estos
pasos debe entenderse, comunicado, y
adecuadamente empleados a fin de generar
datos utilizables. En inge- niería tradicional, a
menudo se utilizan medidas directas. En la
ingeniería de software, una combinación de
ambas medidas directas y derivadas es
necesaria [6 *, P273].
La teoría de la medida establece que la
medida es un intento de describir un
subyacente
sistema empírico real. Métodos de medición que la altura de los individuos varían a través de
definen actividades que asignan un valor o un varios puntos de tiempo del día), cómo la
símbolo a un atributo de una entidad. variabilidad debida al cabello lo que se ocuparon
Los atributos deben entonces ser definidos en de, si la medición será con o sin zapatos, ¿qué
términos de las operaciones utilizadas para clase de precisión que se espera (corregir hasta
identificar y medir ellos- es decir, los métodos una pulgada, 1/2 pulgada, centímetro, etc.) -,
de medición. En este enfoque, se define un incluso
método de medición para ser una operación
especificada precisamente que produce un nú-
mero (llamado el resultado de la medición)
cuando medi- suring un atributo. De ello se
deduce que, para ser útil, el método de medición
tiene que estar bien definida. La arbitrariedad en
el método se reflejará en la ambigüedad en los
resultados de medición.
En algunos casos, particularmente en el
mundo de los atributos físicos que deseamos
medir son fáciles de entender; Sin embargo, en
un mundo artificial como la ingeniería de
software, la definición de los atributos puede no
ser tan simple. Por ejemplo, los atributos de
altura, peso, distancia, etc. son fácil y uniforme
comprendido formemente (aunque pueden no ser
muy fácil de medir en todas las circunstancias),
mientras que los atributos como el tamaño o la
complejidad del software requieren definiciones
claras.
Definiciones operacionales. La definición de
atribuye, para empezar, es a menudo bastante
abstracto. Tales definiciones no facilitan
mediciones. Por ejemplo, podemos definir un
círculo como una línea que forma un bucle
cerrado de tal manera que la distancia entre
cualquier punto en esta línea y un punto interior
fijo llamado centro es constante. Podemos decir,
además, que la distancia fija desde el centro a
cualquier punto en el bucle cerrado da el radio
del círculo. Cabe señalar que aunque el concepto
se ha definido, se ha propuesto ningún medio de
la medición de la radio. La definición
operacional especifica los pasos exactos o el
método utilizado para llevar a cabo una medi-
ción específica. Esto también puede ser llamado
el método de medición; a veces un
procedimiento de medición puede ser necesaria
para ser aún más preciso.
La importancia de las definiciones
operacionales difícilmente puede ser exagerada.
Tomemos el caso de la aparentemente simple
medición de la talla de los individuos. A menos
que especifiquemos varios factores como el
momento en el que se medirá la altura (se sabe
esta simple medida dará lugar a una variación • Capability Maturity Fundamentos de ingeniería 15-
Model Integration
11
sustancial. Los ingenieros deben apreciar la (CMMI) niveles de madurez de software de
necesidad de definir medidas desde una desarrollo organizaciones
perspectiva operacional.
3.1. Niveles (Scales) de Medición

[4 *, c3s2] [6 *,
c7s5]
Una vez que se determinan las definiciones

operacionales, las medidas reales deben
llevarse a cabo. Es de notar que la medición
puede ser car- ried a cabo en cuatro escalas
diferentes: a saber, nominal, ordinal, intervalo,
y la relación. Breves descripciones de cada uno
se dan a continuación.
Escala nominal: Este es el nivel más bajo de
surement medi- y representa la asignación más
sin restricciones de numerales. Los números
sólo sirven como etiquetas y palabras o letras
servirían también. La escala nominal de la
medición sólo implica la clasificación y las
unidades de muestreo observados se ponen en
una cualquiera de las categorías mutuamente
excluyentes y colectivamente exhaustivos
(clases). Algunos ejemplos de escalas
nominales son:
• Los puestos de trabajo en una empresa

• El ciclo de vida de desarrollo de software
(SDLC) modelo (como cascada, iterativa,
ágil, etc.) seguido de diferentes proyectos
de software
En escala nominal, los nombres de las

diferentes catego- rías son sólo etiquetas y no
se asume ninguna relación entre ellos. Las
únicas operaciones que se pueden llevar a cabo
en la escala nominal es la de contar el número
de ocurrencias en las diferentes clases y
determinar si dos sucesos tienen el mismo
valor nominal. Sin embargo, los análisis
estadísticos se pueden llevar a cabo para
entender cómo las entidades pertenencias ing a
diferentes clases realizan con respecto a alguna
otra variable de respuesta.
Escala ordinal: Se refiere a la escala de
medición donde los diferentes valores
obtenidos a través del proceso de la medición
tienen una ing orden- implícita. Los intervalos
entre los valores no son manera especificada y
no hay objetivamente definido elemento cero.
Ejemplos típicos de las mediciones en escalas
ordinales son:
• Los niveles de habilidad (bajo, medio, alto)

• Nivel de adherencia a procesar tal como se medido en escala de intervalo, ya que no es

mide en una escala de 5 puntos de preciso proceder a definir lo que significaría
excelente, encima de la media, media, por cero inteligencia.
debajo de la media, y pobre, lo que indica el
intervalo de adhesión total a no adherencia Si una variable se mide en escala de
en absoluto intervalos, la mayoría de los análisis estadísticos
habituales, como media, Normaliza- dard
La medición en escala ordinal satisface la desviación, correlación y regresión pueden
propiedad sibilidad tran- en el sentido de que si llevarse a cabo sobre los valores medidos.
A> B y B Escala de proporción: Estos son muy
> C, entonces A> C. Sin embargo, las comúnmente encon- trada en la ciencia física.
operaciones aritméticas no puede llevarse a cabo Estas escalas de medidas se caracterizan por el
en variables medidas en escalas ordinales. Por lo hecho de que existen operaciones para la
tanto, si se mide la satisfacción del cliente en determinación de los 4 relaciones: igualdad,
una escala ordinal de 5 puntos de 5 lo que orden de rango, la igualdad de los intervalos, y
implica un alto nivel de satisfacción y 1 lo que la igualdad de las proporciones. Una vez que tal
implica un alto nivel de insatisfacción, no escala está disponible, sus ues Val- numérico se
podemos decir que una puntuación de cuatro es pueden transformar de una unidad a otra con
dos veces mejor que una puntuación de dos. Por sólo multiplicar por una constante, por ejemplo,
lo tanto, es mejor utilizar terminología como la conversión de pulgadas a pies o centímetros.
excelente, encima de la media, media, por Cuando las mediciones se realizan en escala de
debajo de la media, y pobres que los números razón, la existencia de un cero no arbitrario es
ordinales con el fin de evitar el error de obligatorio. Todas las medidas estadísticas son
tratamiento de una escala ordinal como una aplicables a escala de razón; uso logaritmo sólo
escala de proporción. Es importante tener en es válido cuando se utilizan estas escalas, como
cuenta que las medidas ordinales escala son en el caso de decibelios. Algunos ejemplos de
comúnmente mal y el mal uso puede llevar a medidas de razón son
conclusiones erróneas [6 *, P274]. Un mal uso
común de medidas escala ordinal es presentar • el número de declaraciones en un programa
una media y la desviación estándar para el de software
conjunto de datos, los cuales son de sentido. Sin • temperatura medida en la escala Kelvin (K)
embargo, podemos encontrar la mediana, como o en Fahrenheit (F).
el cálculo de la mediana consiste en el conteo
solamente. Una escala de medición adicional, la escala
escalas de intervalo: Con la escala de absoluta, es una escala de proporción con
intervalos, llegamos a una forma que es singularidad del seguro de medi-; es decir, una
cuantitativa en el sentido ordinario de la palabra. medida para la cual no es posible la
Casi todas las medidas habituales Statistical Sta transformación (por ejemplo, el número de los
son aplicables aquí, a menos que requieran el programadores trabajando en un proyecto).
conocimiento de un verdadero punto cero. El
punto cero en una escala de intervalo es una 3.2. Medidas directos y derivados
cuestión de con- vención. Proporciones no [6 *, c7s5]
tienen sentido, pero la diferencia entre los
niveles de atributos se pueden calcular y es Las medidas pueden ser directa o derivado (algu-
significativo. Algunos ejemplos de escala de tiempos de llamada medidas indirectas). Un
intervalo de seguimiento de medición: ejemplo de
• Medición de la temperatura en diferentes

escalas, tales como grados Celsius y
Fahrenheit. Cenar-
plantea1 y T se miden temperaturas una medida directa sería una cuenta de cuántas
rT 2
en alguna escala. Observamos que el hecho 1de queTtimes ocurrió un evento, tal como el número
de Fundamentos de ingeniería 15-
13
es el doble2 no quiere decir que un objeto es defectos encontrados en un producto de software.
T Un derivado
dos veces tan caliente como otra. También medida es el que combina medidas directas de
observamos que los puntos cero son alguna manera que sea consistente con el
arbitrarias. método de medición. Un ejemplo de una medida
• Las fechas del calendario. Mientras que la derivada sería el cálculo de la productividad de
diferencia entre las fechas para medir el un equipo como el número de líneas de código
tiempo transcurrido es un concepto ingful desarrolladas por mes Developer-. En ambos
Entretanto, la relación no tiene sentido. casos, el método de medición determina cómo
• Muchas mediciones psicológicas aspiran a hacer la medición.
crear escalas de intervalo. La inteligencia es
a menudo
3.3. Fiabilidad y Validez El diseño de un producto de software es guiada

[4 *, c3s4, por las características que deben incluirse y los
c3s5] atribuye calidad que deben presentar. Es
importante observar que
Una cuestión fundamental que se plantea para ingenieros de software usan el término “diseño”
cualquier método de medi- ción es si el método en su propio contexto; si bien hay algunas
de medi- ción propuesta es realmente medir el lidades de common, también hay muchas
concepto de buena calidad. Fiabilidad y validez diferencias entre el diseño de ingeniería como se
son los dos criterios más importantes para explica en esta sección y software de diseño de
abordar esta cuestión. ingeniería como se discutió en el software de
La fiabilidad de un método de medición es el diseño KA. El alcance del diseño de inge- niería
grado en el que la aplicación del método de es generalmente visto como mucho más amplio
medición proporciona resultados de medición que el de diseño de software. El objetivo
consistentes. Esencialmente, la fiabilidad se principal de esta sección es identificar los
refiere a la consistencia de los valores obtenidos conceptos necesarios para desarrollar una
cuando el mismo artículo se mide un número de comprensión clara con respecto a la proceso de
veces. Cuando los resultados están de acuerdo diseño de ingeniería.
entre sí, se dice que el método de medición Muchas disciplinas participan en la solución
fiables. Fiabilidad por lo general depende de la de problemas actividades donde hay una única
definición operativa. Se puede cuantificarse solu- ción correcta. En ingeniería, la mayoría de
utilizando el índice de variación, que se los problemas tienen muchas soluciones y la
computadas como la relación entre la desviación atención se centra en la búsqueda de una
estándar y la media. Cuanto menor sea el índice, solución factible (entre las muchas alternativas)
más fiables serán los resultados de la medición. que mejor se adapte a las necesidades
Validez se refiere a si el método de medición planteadas. El conjunto de soluciones posible
mide realmente lo que pretendemos medi- es a menudo limitada por explic- limitaciones
seguro. Validez de un método de medición impuestas tamente como el coste, recursos
puede ser visto desde tres perspectivas disponibles, y el estado de la disciplina o el
diferentes: a saber, la validez de constructo, dominio del conocimiento. En los problemas de
validez criterios, y validez de contenido. ingeniería, a veces también hay limitaciones
implícitas (como las propiedades físicas de los
3.4. Fiabilidad evaluar materiales o las leyes de ics phys-) que también
restringen el conjunto de soluciones factibles
para un problema dado.
[4 *, los costos del ciclo de vida del producto están
c3s5] muy influenciados por el diseño del producto.
Esto es cierto para los productos manufacturados,
Hay varios métodos para evaluar su así como para productos de software.
confiabilidad; Estos incluyen el método de
ensayo-retest, el método de forma alternativa, el
método split mitades, y el método de
consistencia interna. El est easi- de estos es el
método de ensayo-retest. En el método test-
retest, simplemente aplicamos el método de
medición para los mismos sujetos en dos
ocasiones. El coeficiente de correlación entre el
primer y segundo conjunto de resultados de la
medición da la fiabilidad del método de medida.
4. Diseño de ingeniería
[5 *, c1s2, c1s3, c1s4]
4.1. Diseño de ingeniería en la Fundamentos de ingeniería 15-
15
Educación en Ingeniería
La importancia del diseño de ingeniería en la

formación de ingenieros puede ver claramente
por las altas expectativas de los diferentes IES
DBO de acreditación para la formación de
ingenieros. Tanto la Junta de Acreditación de
Ingeniería dian Cana- y la Junta de
Acreditación de Ingeniería y Tech- nology
(ABET) señalan la importancia de incluir el
diseño de ingeniería en programas de
educación.
El Consejo de Acreditación de Ingeniería de
Canadá incluye los requisitos para la cantidad
de experiencia en el diseño de ingeniería /
cursos que es necesario que los estudiantes de
ingeniería, así como los requisitos para los
miembros de la facultad que enseñan estos
cursos o supervisan los proyectos de diseño.
Sus criterios de acreditación establece lo
siguiente:
Diseño: La capacidad de diseñar implica, esencialmente, de que un problema

soluciones de ingeniería, proble- blemas complejo tiene que ser resuelto de una vez con el
indefinidos complejas y diseñar sistemas, fin de definir con claridad y luego resuelve de
componentes o procesos que satisfagan nuevo para crear una solución que funcione. Esta
las necesidades especificadas con la ha sido una idea importante para los diseñadores
debida atención a los riesgos de salud y de los programas durante varias décadas [10 *,
seguridad, las normas aplicables, y con c5s1].
económico, ambiental, cultural y social -
consideraciones. [8, p12]
De una manera similar, ABET define

ingeniería
el diseño como
el proceso de elaboración de un sistema,

componente o proceso para satisfacer las
necesidades deseadas. Es un proceso de
toma de decisiones (a menudo tivo
iterativo), en el que se aplican las ciencias
básicas, las matemáticas, las ciencias de
la ingeniería y los recursos para convertir
de manera óptima para satisfacer estas
necesidades establecidas. [9, p4]
Por lo tanto, está claro que el diseño de

ingeniería es un componente vital en la
formación y la educación para todos los
ingenieros. El resto de esta sección se centrará
en varios aspectos de diseño de ingeniería.
4.2. El diseño como Solución de problemas

Actividad
[5 *, c1s4, C2S1, c3s3]
Es de notar que el diseño de ingeniería es un

problema primar- ily actividad de resolución.
Los problemas de diseño están abiertas y más
vagamente definidos. Por lo general hay varias
formas alternativas para resolver el mismo
problema. El diseño se considera generalmente
que es un problema de un malvado término
acuñado por Horst Rittel en la década de 1960
cuando los métodos de diseño fueron objeto de
un intenso interés. Rittel buscó una alternativa al
modelo lineal paso a paso del proceso de diseño
siendo explorado por muchos diseñadores y
teóricos del diseño y argumentó que la mayoría
de los problemas abordados por los
diseñadores son problemas malvados. Como se
explica por Steve McConnell, un problema
complejo es uno que podría ser claramente
definido únicamente por su solución o mediante
la resolución de parte de ella. Esta paradoja
conocimiento sobre elFundamentos
problema.de Esta
ingeniería 15-
es una
4.3. Pasos a seguir en Diseño de Ingeniería 17
[7 *, c4] etapa vital, ya menudo no. La recopilación de
información pertinente puede revelar hechos que
la resolución de problemas de ingeniería conducen a una redefinición de la
comienza cuando se reconoce una necesidad y
ninguna solución existente satisfacer esa
necesidad. Como parte de esta resolución de
problemas, se deben identificar los objetivos de
diseño que deben alcanzarse en la solución.
Además, un conjunto de criterios de acep-
tación debe ser definido y se utiliza para deter-
minar qué tan bien una solución propuesta va a
satisfacer la necesidad. Una vez a la necesidad
de una solución a un problema ha sido
identificado, el proceso de diseño de ingeniería
tiene los siguientes pasos genéricos:
a) definir el problema
b) recopilar información pertinente
c) generar múltiples soluciones
d) analizar y seleccionar una solución de
e) implementar la solución
Todas las etapas de diseño de ingeniería son

tivo iterativo, y los conocimientos adquiridos
en cualquier etapa del proceso se puede utilizar
para informar a las tareas anteriores y
desencadenar una iteración en el proceso. Estos
pasos se expandieron en las secciones
subsiguientes.
a. Define el problema. En esta etapa, se reúnen

los requisitos de la er adaptado para el cliente.
informa- ción específica sobre las funciones y
características del producto también se
examina de cerca. Este paso incluye el
perfeccionamiento de la declaración de
problemas para identificar el verdadero
problema que hay que resolver y el
establecimiento de los objetivos de diseño y
criterios de éxito.
La definición del problema es una etapa
crucial en el diseño de ingeniería. Un punto a
tener en cuenta es que este paso es
engañosamente simple. Por lo tanto, la
atención suficiente se debe tomar para llevar a
cabo este paso con criterio. Es importante
identificar las necesidades y vincular los
criterios de éxito con las características de los
productos requeridos. También es una tarea de
ingeniería para limitar el alcance de un
problema y su solución a través de la
negociación entre las partes interesadas.
b. Recopilar información pertinente. En esta

etapa, el diseñador intenta ampliar su / su El
problemas, en particular, los errores y las salidas ser desarrollados inicialmente para probar la
en falso puede ser identificado. Este paso puede solución de diseño propuesto bajo ciertas
implicar también la descomposición del condiciones. Comentarios como resultado de la
problema en subproblemas más pequeños y más prueba de un prototipo puede ser utilizado ya sea
fáciles de resolver. para
En la recogida de información pertinente, se
debe tener cuidado para identificar cómo un
producto puede ser usado como un mal uso.
También es importante entender el valor
percibido del producto / servicio que se ofrece.
Incluida en la información pertinente es una lista
de restricciones que deben ser satisfechas por la
solución o que pueden limitar el conjunto de
soluciones factibles.
c. Generar múltiples soluciones. Durante esta

etapa, las diferentes soluciones al mismo
problema son desarrollados. Ya se ha indicado
que el diseño proble- blemas tienen múltiples
soluciones. El objetivo de este paso es
conceptualizar múltiples soluciones posibles y
refinar a un nivel de detalle suficiente que la
comparación puede hacerse entre ellos.
d. Analizar y seleccionar una solución. Una vez

que se han identificado soluciones alternativas,
es necesario que se ana- lyzed para identificar la
solución que mejor se adapte a la situación Cur-
alquiler. El análisis incluye un análisis funcional
para evaluar si el diseño propuesto cumpliría los
requisitos funcionales. soluciones físicas que
implican usuarios humanos a menudo incluyen
el análisis de la ergonomía o la facilidad de uso
de la solución propuesta. Otros aspectos de la
solución, tales como la seguridad del producto y
la responsabilidad, un análisis nómica o mercado
ecológico para asegurar un retorno (ganancia) en
la solución, predicciones y análisis de
rendimiento para satisfacer las características de
calidad, oportunidades para la entrada de datos
incorrectos o fallos de hardware, y así
sucesivamente-se pueden estudiar. Los tipos y la
cantidad de análisis utilizado en una solución
propuesta son dent depen- del tipo de problema
y las necesidades que la solución debe abordar,
así como las limitaciones impuestas en el diseño.
e. Implementar la solución. La fase final del

proceso de diseño es la implementación. tación
aplica- se refiere al desarrollo y ensayo de la
solución propuesta. A veces una solución
preliminar, parcial llamado un prototipo puede
refinar el diseño o conducir a la selección de físicos, tales como un dibujoFundamentos
CAD de un de diente
ingeniería 15-
19
una solución de diseño alternativa. Una de las o un modelo matemático para un proceso. Los
actividades más importantes en el diseño es la modelos ayudan a los ingenieros a entender la
documentación de la solución de diseño, así razón y los aspectos de
como de las ventajas y desventajas de las
decisiones tomadas en el diseño de la solución.
Este trabajo debe llevarse a cabo de tal manera
que la solución al problema de diseño se puede
com- municated claramente a los demás.
La prueba y verificación nos llevan de vuelta
a los criterios de éxito. El ingeniero tiene que
diseñar pruebas de tal manera que la capacidad
del diseño para cumplir con los criterios de
éxito se demuestra. Mientras diseño- ing las
pruebas, el ingeniero debe pensar a través de
diferentes modos de fallo posibles y luego
diseñar pruebas basadas en los modos de fallo.
El ingeniero puede optar por llevar a cabo los
experimentos diseñados para evaluar la validez
del diseño.
5. Modelado, Simulación y Prototipos

[5 *, c6] [11 *, c13s3] [12 *,
c2s3.1]
El modelado es parte del proceso de

abstracción usado para representar algunos
aspectos de un sistema. ción simulaciones
utiliza un modelo del sistema y proporciona un
medio para la realización de experimentos
diseñados con ese modelo para comprender
mejor el sistema, su comportamiento, y las
relaciones entre los subsistemas, así como para
analizar los aspectos del diseño. Mod eling y
simulación son técnicas que se pueden utilizar
para construir teorías o hipótesis sobre el
comportamiento del sistema; ingenieros luego
usar esas teorías para hacer predicciones sobre
el sistema. Prototyping es otro proceso
abstracción donde se construye una
representación parcial (que captura aspectos de
interés) del producto o sistema. A prototipo
puede ser una versión inicial del sistema, pero
carece de la funcionalidad completa de la
versión final.
5.1. Modelado
Un modelo es siempre una abstracción de

algún artefacto real o imaginario. Los
ingenieros utilizan modelos de muchas
maneras, como parte de sus actividades de
resolución de problemas. Algunos modelos son
físicas, tales como la construcción en miniatura
hecha a escala de un puente o edificio. Otros
modelos pueden ser representaciones no
un problema. También pueden ayudar a los este tipo incluyen entidades, actividades y
ingenieros Deben conocerse lo que saben y lo eventos, recursos, el estado del sistema, un reloj
que no saben sobre el problema en cuestión. de simulación, y un generador de números
Hay tres tipos de modelos: icónicas, la lógica aleatorios. De salida es generada por la
ana- y simbólica. Un modelo icónico es un simulación y debe ser analizada.
equivalente aliado visu- pero incompleta
representación, por ejemplo de 2 dimensiones o
3 dimensiones, mapas, globos, o modelos
construidos a escala de las estructuras tales
como puentes o carreteras. Un modelo icónico
en realidad se asemeja al modelo de artefacto.
Por el contrario, un modelo analógico es una
representación funcionalmente equivalente pero
incompleta. Es decir, el modelo se comporta
como el artefacto físico a pesar de que no puede
parecerse físicamente. Ejemplos de modelos
analógicos incluyen un avión en miniatura para
las pruebas de túnel de viento o una simulación
por ordenador de un proceso de fabricación.
Finalmente, un modelo simbólico es un mayor
nivel de abstracción, donde el modelo se
representa usando símbolos tales como
ecuaciones. El modelo captura los aspectos
relevantes del proceso o sistema en forma
simbólica. Los símbolos pueden ser utilizados
para aumentar la comprensión del ingeniero del
sistema final. Un ejemplo es una ecuación tal
como F = ma. Tales modelos matemáticos se
pueden utilizar para describir y predecir las
propiedades o comportamiento del sistema final
o producto.
5.2. Simulación
Todos los modelos de simulación son una

especificación de la realidad. Un tema central
en la simulación es abstraer y especifique una
adecuada simplificación de la realidad. El
desarrollo de esta abstracción es de vital
importancia, ya que la mala especificación de la
abstracción invalidaría los resultados del
ejercicio de simulación. La simulación puede ser
utilizado para una variedad de propósitos de
prueba.
La simulación se clasifican en función del tipo
de sistema en estudio. Por lo tanto, la simulación
puede ser continua o discreta. En el contexto de
la ingeniería de software, se hará hincapié
principalmente en la simulación discreta.
simulaciones discretas pueden modelar la
programación de eventos o interacción proceso.
Los principales componentes de un modelo de
Un problema importante en el desarrollo de
una simulación discreta es el de inicialización.
Antes de una simulación puede ejecutarse, se
deben proporcionar los valores iniciales de las
variables de estado. Como el diseñador La
simulación puede no saber qué valores iniciales
son apropiados para las variables de estado,
estos valores podrían ser elegidos de manera
algo arbitraria. Por ejemplo, podría decidirse
que una cola debe ser inicializado tan vacío e
inactivo. Tal elección de la condición inicial
puede tener un impacto significativo, pero
ognized unrec- sobre el resultado de la
simulación.
5.3. prototipado
La construcción de un prototipo de un sistema

es otro proceso de abstracción. En este caso,
una versión inicial del sistema se construye, a
menudo mientras que el sistema está siendo
diseñado. Esto ayuda a los diseñadores a
determinar la viabilidad de su diseño.
Hay muchos usos para un prototipo,
INCLUYENDO la elicitación de requisitos, el
diseño y el refinamiento de una interfaz de
usuario al sistema, validados dación de los
requisitos funcionales, y así sucesivamente.
Los objetivos y propósitos para la construcción
del prototipo determinarán su construcción y el
nivel de abstracción usado.
El papel de los prototipos es algo diferente
entre los sistemas físicos y de software. Con
los sistemas físicos, el prototipo puede ser en
realidad la primera versión totalmente
funcional de un sistema o puede ser un modelo
del sistema. En la ingeniería de software,
prototipos son también un modelo abstracto de
una parte del software, pero por lo general no
se construyen con todos los arquitectónicas su
rendimiento óptimo y otras características,
calidad esperados en el producto acabado. En
cualquier caso, la construcción de prototipos
debe tener un propósito claro y ser planificado,
supervisado y controlado por ella es una téc-
nica para estudiar un problema específico
dentro de un contexto limitado [6 *, c2s8].
En conclusión, el modelado, simulación y
totyping pro son técnicas poderosas para el
estudio del comportamiento de un sistema
desde un punto de vista determinado. Todos
pueden ser usados para llevar a cabo los
experimentos diseñados para estudiar diversos
aspectos del sistema. SIN EMBARGO, éstos
son abstracciones y, como tal, no puede
modelar todos los atributos de interés.
6. normas regional y gubernamental reconocida organiza-

[5 *, c9s3.2] [13 *, c1s2] ciones que generan estándares para esa región o
país. Por ejemplo, en los Estados Unidos, hay
Moore afirma que más de 300 organizaciones que desarrollan
una Standards. Estos incluyen organizaciones tales
como la
estándar puede ser; (A) un objeto o Normalización (ISO) reconocidas
medida de comparación que define o internacionalmente. Además, hay
representa la magnitud de una unidad; (B)
una caracterización que establece niveles
de tolerancia admisibles para categorías
de artículos; y (c) un grado o nivel de
excelencia o el logro requerido. Los
estándares son de definición en la
naturaleza, establecido ya sea a más
normas de características o el
comportamiento exhibidos comprensión y
la interacción o reconocer observado (o
deseado). [13 *, p8]
Las normas proporcionan los requisitos, las

especificaciones, directrices o características que
deben ser observadas por los ingenieros para que
los productos, procesos y materiales tienen
niveles aceptables de calidad. Las cualidades
que diversas normas pro-vide pueden ser los de
seguridad, fiabilidad, u otras características del
producto. Las normas se consideran críticos para
los ingenieros y los ingenieros se espera a
conocer y utilizar los Standards apropiadas en su
disciplina.
El cumplimiento o conformidad con una
norma permite a una organización dicen al
público que ellos (o sus productos) cumplen con
los requisitos establecidos en dicha norma. Por
lo tanto, las normas se dividen organizaciones
o de sus productos en los que se ajustan a la
norma y los que no lo hacen. Para una norma sea
útil, conformidad con la norma debe añadir valor
real o percibida al producto, proceso o esfuerzo.
Además de los objetivos de la organización,
las normas se utilizan para una serie de otros
propósitos tales como la protección del
comprador, la protección de la empresa, y una
mejor definición de los métodos y
procedimientos a seguir por la práctica. Las
normas también proporcionan a los usuarios una
terminología común y las expectativas.
Hay muchas organizaciones normativas como
la Unión Internacional de Telecomunicaciones
(UIT), la Comisión Electrotécnica Internacional
(IEC), IEEE, y la Organización Internacional de
15-14 GuíaNational
American SWEBOK® V3.0
Standards Institute (ANSI),
la Sociedad Americana para Pruebas y
Materiales (ASTM), la Sociedad de Ingenieros
Automotrices (SAE) y Underwriters
Laboratories, Inc. (UL), así como el gobierno
de Estados Unidos. Para más detalles sobre los
estándares usados en ingeniería de software,
consulte el Apéndice B en las normas.
Hay una serie de principios de uso común
detrás de los estándares. fabricantes de Normas
de intentar tener un consenso en torno a sus
decisiones. Por lo general hay una apertura
dentro de la comunidad de intereses de modo
que una vez que una norma se ha establecido,
hay una buena probabilidad de que será
ampliamente aceptado. La mayoría de las
organizaciones de normalización tienen
procesos bien definidos por sus esfuerzos y se
adhieren a esos procesos con cuidado. Los
ingenieros deben estar al tanto de las normas
existentes, sino que también deben actualizar
su conocimiento de las normas que las normas
cambian con el tiempo.
En muchos esfuerzos de ingeniería, conocer
y comprender las normas aplicables es crítica y
la ley puede incluso requerir el uso de normas
particulares. En estos casos, las normas
menudo REPRESENTA requisitos mínimos
que se deben cumplir por el esfuerzo y por lo
tanto son un elemento en los straints con-
impuestas a cualquier esfuerzo de diseño. El
Neer niería debe revisar todas las normas
actuales en relación con una tarea dada y
determinar que se deben cumplir. Sus diseños
deben luego incorporar cualquier y todas las
restricciones impuestas por el Dard Están-
aplicable. Normas importantes para los
ingenieros de software se discuten con más
detalle en un apéndice específica- mente sobre
este tema.
7. Análisis Causa Raíz

[4 *, c5, c3s7, c9s8] [5 *, c9s3, c9s4, c9s5]
[13 *, c13s3.4.5]
análisis de la causa raíz (RCA) es un proceso

diseñado para investigar e identificar cómo y
por qué un evento no deseado ha sucedido.
causas fundamentales son causas subyacentes.
El investigador debe intentar identificar las
causas subyacentes específicas del evento que
ha ocurrido. El objetivo primario
de RCA es para prevenir la recurrencia del subfactores y sub-subfactores hasta causas

evento no deseable. Por lo tanto, cuanto más fundamentales pueden ser identificados.
específico sea el tor investiga- puede ser acerca
de por qué se produjo un acontecimiento, más
fácil será para prevenir la recurrencia. Una
forma común de identificar la causa subyacente
específica (s) es hacer una serie de preguntas por
qué.
7.1. Las técnicas para la realización de

análisis de causa raíz
[4 *, c5] [5 *, c3]
Hay muchos enfoques utilizados tanto para el

control de calidad y análisis de la causa raíz. El
primer paso en cualquier esfuerzo de análisis de
causa raíz es identificar el problema real.
Técnicas tales como la declaración-ción restate-,
por qué, por qué diagramas, el método de
revisión, estado actual y diagramas de estado
deseados, y el enfoque de ojos frescos se utilizan
para identificar y perfilar el verdadero problema
que debe ser abordado.
Una vez que el verdadero problema ha sido
identificado, entonces el trabajo puede comenzar
a determinar la causa del problema. Ishikawa es
conocido por los siete herramientas para el
control de calidad que él promovió. Algunas de
estas herramientas son útiles en la identificación
de las causas para un problema dado. Esas
herramientas son hojas de verificación o listas de
control, diagramas de Pareto, histogramas,
diagramas de comportamiento, diagramas de
dispersión, gráficos de control y diagramas de
espina de pescado o causa-efecto. Más
recientemente, han surgido otros enfoques para
la mejoría de la calidad y el análisis de la causa
raíz. Algunos ejemplos de estos métodos más
nuevos son diagramas de afinidad, diagramas de
relaciones, diagramas de árbol, tablas de matriz,
de matriz de gráficos de análisis de datos,
criteria programa de gráficos sion de proceso, y
los diagramas de flecha. Algunas de estas
técnicas se describen brevemente a
continuación.
Un diagrama de espina de pescado o de causa
y efecto es una manera de visualizar los diversos
factores que afectan a alguna característica. La
línea principal en el diagrama representa el
problema y las líneas de conexión representan
los factores que llevaron a o influenciados el
problema. Esos factores se dividen en
Un enfoque muy simple que es útil en el
control de calidad es el uso de una lista de
verificación. Las listas de verificación son una
lista de los puntos clave en un proceso con las
tareas que debe ser completado. A medida que
se completa cada tarea, se comprueba fuera de
la lista. Si se produce un problema, entonces a
veces la lista de verificación puede identificar
rápidamente las tareas que pueden haber sido
omitidos, o sólo parcialmente completados.
Finalmente, diagramas de relaciones son un
medio para dis- relaciones complejas de juego.
Dan apoyo visual a causa y efecto
pensamiento. El diagrama se refiere el
específico a lo general, revelando principales
causas y efectos clave.
Análisis de causa raíz tiene por objeto
prevenir la recurrencia de eventos indeseables.
Reducción de la variación debida a causas
comunes requiere zación utili- de una serie de
técnicas. Un punto importante a destacar es que
estas técnicas se deben utilizar fuera de línea y
no necesariamente en respuesta directa a la
ocurrencia de un evento no deseado. Algunas
de las técnicas que pueden utilizarse para
reducir la variación, debido a causas comunes
se dan a continuación.
1. diagramas de causa y efecto se pueden

utilizar para identificar las causas sub y
sub-sub.
2. El análisis del árbol de fallos es una
técnica que se puede utilizar para entender
las fuentes de fallos.
3. experimentos diseñados se pueden usar
para sub soportar el impacto de diversas
causas de la aparición de acontecimientos
adversos (ver Empir- Métodos iCal y
técnicas experimentales en este KA).
4. Hay varios tipos de análisis de correlación
se pueden utilizar para comprender la
relación entre las diversas causas y sus
efectos. Estas técnicas se pueden utilizar
en los casos en Conducta- experimentos
controlados ING es difícil, pero los datos
se puede reunir (véase el análi- sis
estadístico en este KA).
Montgomery y Runger 2007 [2
cheney y Kincaid 2007

nully Lobur 2006 [3
2011 [12 *]
McConnell 2004
2006 [13
Voland 2003
2009 [6
JustaLey de
Kan 2002
točkey 2004
SommervilLe
[11 *]
[10 *]
[5 *]
[7 *]
Mugirre
[4 *]
*]
*]
*]
*]
1. Métodos
empíricos y
c1
técnicas
experimentales
1.1.
experimento
diseñado
1.2.
De observación
Estudiar
1.3.
Estudio
retrospectivo
2. Análisis c9s1,
c10s3
estadístico C2S1
c3s6,
c3s9,
2.1. Concepto de
c4s6,
unidad de
c6s2,
análisis (unidades
c7s1,
de muestreo),
c7s3,
Muestra,y
c8s1,
Población
c9s1
2.2. Conceptos
c11s2,
de correlacióny
c11s8
regresión
c3s1,
3. Medición c4s4 c7s5
c3s2
3.1. Niveles
P442
(Scales) de c3s2 c7s5
-447
Medición
3.2. Medidas
directos y
derivados
Montgomery y Runger 2007 [2
cheney y Kincaid 2007

nully Lobur 2006 [3
2011 [12 *]
McConnell 2004
2006 [13
Voland 2003
2009 [6
JustaLey de
Kan 2002
točkey 2004
SommervilLe
[11 *]
[10 *]
[5 *]
[7 *]
Mugirre
[4 *]
*]
*]
*]
*]
3.3. Fiabilidad c3s4,
y Validez c3s5
3.4. Fiabilidad
c3s5
evaluar
c1s2,
4. Diseño de
c1s3,
Ingeniería
c1s4
4.1. Diseño
de la
Educación en
Ingeniería
4.2. El c1s4,
diseño como C2S c5s1
un problema 1,
actividad
4.3. Pasosde
a c3s3
resolución
seguir en
c4
Diseño de
Ingeniería
5. Modelado,
c2
creación de c6 c13s3
S3.1
prototipos y
simulación
5.1. Modelado
5.2. Simulación
5.3. prototipado
S3.2
6. Normas c1s2
c9
c5, c9s3,
Análisis s3.4.
c3s7, c9s4,
Causa Raíz 7. 5 c13
c9s8 c9s5
7.1. Las técnicas
para la
c5 c3
realización de
análisis de causa
raíz
LECTURAS
A. Abran, Software Metrics y software de W.G.Vincenti, lo que los ingenieros saber y
metrología. [14] cómo lo saben. [15]
Este libro ofrece muy buena información sobre Este libro ofrece una introducción interesante
el uso correcto de la medida de términos, para bases de ingeniería a través de una serie de
método de medición y los resultados de estudios de casos que muestran muchos de los
medición. Proporciona material de soporte fuerte conceptos fundacionales que se utiliza en
para toda la sección sobre la medición. aplicaciones de ingeniería del mundo real.
Referencias
[1] ISO / IEC / IEEE 24765: 2010 Sistemas y [9] Comisión de Acreditación ABET Ingeniería,
de Ingeniería de Software-Vocabulario, “Criterios para la Acreditación de Programas
ISO / IEC / IEEE 2010. de Ingeniería, 2012-2013”
ABET, 2011; www.abet.org/uploadedFiles/
[2 *] DC Montgomery y GC Runger, Acreditación / Accreditation_Process /
Estadística Aplicada y Probabilidad para Accreditation_Documents / Corriente / eac-
Ingenieros, 4ª ed., Wiley, 2007. criterios-2012-2013.pdf.
[3 *] L. y J. nulo Lobur, Lo Esencial de la [10 *] S. McConnell, código completo, 2ª ed.,

Organización de Computadores y Microsoft Press, 2004.
Arquitectura, 2ª ed., Jones and Bartlett
Publishers, 2006. [11 *] EW Cheney y DR Kincaid, Numéricos
Matemáticas y Computación, 6ª ed., Brooks
[4 *] SH Kan, métricas y modelos en Ingeniería / Cole, 2007.
Wesley, 2002. [12 *] I. Sommerville, Ingeniería de Software, 9ª
[5 *] G. Voland, Ingeniería de Diseño, 2ª ed.,
Prentice Hall, 2003. [13 *] JW Moore, La Hoja de Ruta de Ingeniería
[6 *] RE Fairley, gestionar y liderar proyectos estándares, Wiley-IEEE Computer Society
de software, Wiley-IEEE Computer Press, 2006.
[14] A. Abran, Métricas de software y software
[7 *] S. Tockey, el rendimiento de software: de metrología, Wiley-IEEE Computer
maximizar el retorno de su inversión en Society Press, 2010.
[15] WG Vincenti, lo que los ingenieros
[8] Consejo Canadiense de Acreditación de saber y cómo ellos lo saben, John
Ingeniería, Ingenieros Canadá, “Criterios Hopkins University Press, 1990.
de Acreditación y Procedimientos”,
Consejo Canadiense de Ingenieros, 2011;
www.
engineerscanada.ca/files/w_Accreditation_
Criteria_Procedures_2011.pdf.
APÉNDICE A
Área de conocimiento Descripción

Especificaciones
INTRODUCCIÓN ampliamente reconocido como un documento

fundamental dentro de la comunidad de ingeniería
En este documento se exponen las características de software en
de RESPETA a los editores Área de
Conocimiento (Editores KA) con respecto a las
descripciones Área de Conocimiento (KA)
Descripciones de la edición de la versión 3 (V3)
de la Guía de la Ingeniería de Software de
Administración de Conocimiento (Guía
SWEBOK) . Este documento también permitirá
a los lectores, revisores y los usuarios a entender
claramente lo que las especificaciones fueron
utilizados en el desarrollo de esta versión de la
Guía SWEBOK.
Este documento comienza situando la Guía
SWE- BOK como un documento fundamental
para el conjunto de la IEEE Computer Society
de productos de ingeniería de software y más
ampliamente dentro de la comunidad de
ingeniería de software en general. Se describe a
continuación el papel de la Junta de Control de
la línea de base y el Cambio. Criterios y
requisitos se definen para las averías de los
temas, para la lógica subyacente en las averías y
la descripción sucinta de los temas, y para
materiales Las alusiones. También se identifican
los documentos de entrada importantes, y su
papel dentro del proyecto se explica. También se
discuten los temas NONCONTENT como las
directrices de formato de presentación y estilo.
LA GUÍA SWEBOK ES UN DOCUMENTO

FUNDAMENTAL PARA LA IEEE
Computer Society conjunto de productos de
ingeniería de software
La Guía SWEBOK es un buque insignia de la

IEEE Computer Society y el documento
estructural para el conjunto de la IEEE
Computer Society de ingeniería de software
productos. La Guía SWEBOK es también más
grande en particular mediante el IEEE Computer Society
reconocimiento oficial de la versión 2004 (www.computer.org/portal/web/education/
como Informe Técnico ISO / IEC 19759: 2005. Los planes de estudio).
Se describe la lista de áreas de conocimiento c) La lista de referencias consolidado (ver
(KAS) y la descomposición de los temas Appen- Dix C), es decir, la lista de
dentro de cada KA y se detalla en la materiales de referencia recomendados (a
introducción de esta Guía SWEBOK. nivel de número de sección) que acompaña
En consecuencia, la Guía SWEBOK es a la ruptura de los temas dentro de cada KA
fundacional a otras iniciativas dentro de la también es adoptada por la certificación de
Sociedad IEEE Com- puter: la ingeniería de software y el desarrollo
profesional ciados aso- productos ofrecidos
a) La lista de Kas, y la ruptura de los temas por la IEEE Computer Society.
dentro de cada KA también son adoptados
por la certificación de la ingeniería de soft- Línea de base y JUNTA DE CONTROL DE
ware y productos asociados de desarrollo CAMBIO
profesional ofrecido por el IEEE
Computer Society (ver www. Debido a la naturaleza estructural de la Guía
computer.org/certification). SWEBOK y su adopción por otros productos,
b) La lista de Kas, y la ruptura de ics Top- una línea de base fue desarrollado desde el
también son fundamentales para las pautas principio del proyecto formó parte de la lista de
de los planes de estudio de ingeniería de Kas, en el desglose de
software desarrollado o avalados por la
A-1
UN-2 Guía SWEBOK®
V3.0
temas dentro de cada KA, y la Lista consolidada conocimiento, que son también una parte
rencia Ref-. integral de todo el conocimiento
Una Junta de Control de Cambios (CCB) ha
estado en vigor durante el desarrollo de esta
versión de Han-dle todas las solicitudes de
cambio a esta línea de base procedentes de los
editores KA, que se produce durante el proceso
de revisión, o de otra manera. Las solicitudes de
cambio deben ser aprobadas tanto por los
Editores Guía SWEBOK y por el CCB antes de
su implementación. Este CCB está compuesta
por miembros de las iniciativas enumeradas
arriba y actuando bajo la autoridad del Software
y Sistemas Comité de Ingeniería de la IEEE
Computer Society Profesional activi- ata Junta.
CRITERIOS Y REQUISITOS PARA LA

DISTRIBUCIÓN DE TEMAS EN UN
ÁREA DE CONOCIMIENTO
a) Editores KA son instruidos para adoptar la

ruptura línea de base de temas.
b) Se espera que el desglose de los temas a ser
“Razonable” y no “perfecto”.
c) El desglose de los temas dentro de un KA
debe descomponer el subconjunto del
Software Inge- niería cuerpo de
conocimiento que es “GEN-ralmente
reconocido”. Véase más abajo para una
discusión más detallada de este punto.
d) El desglose de los temas dentro de un KA
no debe suponer dominios específicos de la
aplicación, las necesidades del negocio,
tamaños de organizaciones, estructuras
organiza- zational, filosofías de gestión,
modelos del ciclo de vida del software,
software tecnolo- gías, o métodos de
desarrollo de software.
e) El desglose de los temas debe, en lo posible,
ser compatible con las escuelas variabilidad
ous de pensamiento dentro de la ingeniería
de software.
f) El desglose de los temas dentro de un KA
debe ser compatible con el desglose de la
ingeniería de software que se encuentra
generalmente en industria y en la literatura
y las normas de ingeniería de software.
g) Se espera que el desglose de los temas a ser
lo más inclusivo posible.
h) La Guía SWEBOK adopta la postura de que
a pesar de que los siguientes “temas” son
comunes en todas las áreas de
Las áreas y, por tanto, deben ser un argumento particular). Apéndice A A-3
incorporados en la propuesta de reparto de
los temas de cada área de conocimiento.
Estos temas comunes son la medición, la
calidad (en general), y la seguridad.
i) El desglose de los temas debe ser a lo
sumo dos o tres niveles de profundidad. A
pesar de que hay un límite superior o
inferior se impone sobre el número de
temas dentro de cada KA, se espera que un
número razonable y manejable de temas
que se incluirán en cada KA. También
énfasis debe ser puesto en la selección de
los mismos, más que en su organización
en una adecuada jerarquía temas.
j) nombres de los temas deben ser lo
suficientemente importantes como para ser
significativa incluso cuando fuera de la
citada Guía SWEBOK.
k) La descripción de un KA incluirá un
gráfico (en forma de árbol) que describe la
descomposición conocimiento.
CRITERIOS Y REQUISITOS PARA LA

DESCRIPCIÓN DE TEMAS
Temas sólo necesitan ser descritos

suficientemente para que el lector puede
seleccionar la referencia adecuada de material
de acuerdo con su / sus necesidades. las
descripciones de los temas no deben ser
preceptivo.
CRITERIOS Y REQUISITOS PARA

MATERIAL DE REFERENCIA
a) Editores KA son instruidos para usar los

las referencias (a nivel de número de
sección) asignado a su KA por la Lista
consolidada de referencia como sus
referencias recomendadas.
b) Hay tres categorías de referencia
material:
»Referencias recomendados. El
conjunto de referencias
recomendadas (a nivel de
número de sección) se conoce
colectivamente como la lista
de referencia consolidado.
Otras lecturas ».
»Referencias adicionales citadas
en el KA descripción (por
ejemplo, la fuente de un
material cita o referencia en
apoyo de una razón de ser de
UN-4 Guía SWEBOK®
V3.0
c) La Guía SWEBOK está destinado por recomiendan especialmente

definición ser selectivo en su elección de los puede cubrir por supuesto
temas y material de referencia asociado. La múltiples temas.
lista de material de referencia debe ser Excepcionalmente, un tema
claramente vista como una “selección puede ser auto-descriptivo y no
informada y razonable” y no como una lista cita un artículo de material de
definitiva. referencia (por ejemplo, un tema
d) material de referencia puede ser capítulos de que es una definición o una
libros, artículos en revistas arbitradas, materia competencia de la
artículos técnicos referenciados confe- descripción misma sin ningún
rencia, arbitrado informes técnicos o
industriales, o cualquier otro tipo de
reconocido arti- hecho. También se
permiten referencias a otro KA, subárea, o
tema.
e) material de referencia debe ser
generalmente dispo- capaz y no debe ser de
naturaleza confidencial.
f) material de referencia debe estar en Inglés.
g) Criterios y requisitos para el material de
referencia recomendada o la lista de referen-
cia consolidada:
»En conjunto la lista de referencias

debe ser recomendados
i. completar: que cubre la totalidad

alcance de la Guía SWEBOK
ii. suficiente: proporcionar
suficiente información para
describir “gene- aliado aceptado”
conocimiento
iii. consistente: no proporcionar los
conocimientos contradictorios ni
prácticas conflictivos
iv. creíble: reconocido como
proporcionar
tratamiento experto
v. actual: tratar el tema de una
manera que sea acorde con el
conocimiento generalmente
aceptado actualmente
vi. sucinta: lo más corto posible
(tanto en número de unidades de
referencia y en el número total
de páginas) sin fallar otros
objetivos.
»Material de referencia
recomendados deben ser
identificados para cada tema.
Cada elemento de referencia
completar cuatro Apéndice
añosA A-5de
material de referencia citado es
suficiente para experiencia laboral.
los objetivos de la Guía SWEBOK).
»Cada referencia al material de h) material de referencia adicional puede ser
referencia recomendada debe incluido por el Editor KA en una lista
“Otras lecturas”:
ser tan preciso como sea
posible mediante la
identificación de cuáles
capítulo o sección específica
es relevante.
»Una matriz de material de
referencia (a la
nivel de número de sección) frente a
los temas debe ser proporcionada.
»Una cantidad razonable de
recomendada
material de referencia debe ser
identificado para cada KA. Las
siguientes pautas deben ser utilizados
en la determinación de cuánto es
razonable:
i. Si el material de referencia
recomendada fueron escritas de
manera coheren- que siguió a la
propuesta de reparto de temas y
en un estilo uniforme (por
ejemplo, en un nuevo libro
basado en la descripción
propuesta KA), un promedio
Tar conseguir a través de todos
KAs para el número de páginas
sería 750. sin embargo, este
objetivo no puede ser posible
cuando se selecciona el
material de referencia existente
debido a las diferencias de
estilo y la superposición y la
redundancia entre los
materiales de referencia
seleccionados.
ii. En otras palabras, el objetivo
para el número de páginas para
la colección completa de las
referencias recomendadas de la
Guía SWEBOK está en el
rango de 10.000 a 15.000
páginas.
iii. Otra forma de ver esto es que la
cantidad de material de
referencia recomendada sería
razonable si consistiera en el
material de estudio en este KA
para un examen de licencia de
ingeniería de software que
pasaría un graduado después de
UN-6 Guía SWEBOK®
V3.0
»Estas lecturas adicionales deben estructura:

estar relacionados con los temas
• acrónimos
de la descomposición en lugar
• Introducción
de, por ejemplo, a temas más
• Desglose de los temas de la KA (incluyendo
avanzados. una
»La lista debe ser anotado (a figura que describe la descomposición)
menos de 1
• Matriz de Temas vs. Material de Referencia
párrafo por referencia) de por qué este
• Lista de lecturas recomendadas
material de referencia se incluyó en la
• referencias
lista de lecturas adicionales. Lecturas
adicionales podrían incluir: nuevas
versiones de una referencia existentes
ya incluidos en las referencias
recomendadas, puntos de vista
alternativos sobre una KA, o un trata-
miento seminal de un KA.
»Una pauta general a seguir es 10
o un menor número de lecturas
adicionales por KA.
»No hay matriz de los materiales
de referencia que figuran en
lecturas adicionales y la ruptura
de temas.
i) Criterios y requisitos relativos a las

referencias adicionales citados en el KA
Descripción:
»La Guía SWEBOK no es un

documento de investigación y
su número de lectores será IED
Var-. Por lo tanto, un delicado
equilibrio debe mantenerse
entre la garantía de un alto nivel
de legibilidad dentro del
documento, manteniendo su
lencia tecnológico consolidado.
material de referencia adicional,
por tanto, sólo debe ser traído
por el Editor de KA si es
necesario a la discusión.
Ejemplos de ello son la
identificación de la fuente de
una cita o para citar elemento
de referencia en apoyo de una
lógica detrás de un argumento
en particular e importante.
estructura común
KA descripciones deben utilizar la siguiente

¿QUÉ SIGNIFICA “GENERALMENTE en general”, pero hoy y lo que esperan será A A-7
Apéndice
RECONOCIDAS DE “generalmente reconocido” en un 3 a 5 años

CONOCIMIENTO”? periodo de tiempo.
La Ingeniería de Software de Administración

de Conocimiento es un término inclusivo que
describe la suma de conocimientos dentro de la
profesión de la ingeniería de software. Sin
embargo, la Guía SWEBOK busca identificar y
describir ese subconjunto del conjunto de
conocimientos que generalmente se reconoce
o, en otras palabras, el cuerpo de la base de
conocimientos. Para BET ter ilustrar lo que
“generalmente reconocido” el conocimiento es
en relación con otros tipos de conocimiento, la
figura A.1 propone un esquema de tres
categorías de clasificación de conocimiento.
El Instituto de Gestión de Proyectos en su
Guía de los Fundamentos de la Dirección de
Proyectos define “generalmente reconocido” el
conocimiento de la gestión de proyectos como
ser:
el subconjunto de la Dirección de
Proyectos del conocimiento
generalmente reconocido como buenas
prácticas. “Generalmente reconocido”
significa el conocimiento y las prácticas
descritas son aplicables a la mayoría de
los proyectos, la mayor parte del tiempo,
y no hay consenso sobre su valor y
utilidad. “La buena práctica” significa
que hay acuerdo general en que la
aplicación de estas habilidades,
herramientas y técnicas puede mejorar
las posibilidades de éxito en una amplia
gama de proyectos. “La buena práctica”
no significa que el conocimiento
descrito siempre deben ser aplicadas de
manera uniforme a todos los proyectos;
la nización y / o gestión de proyectos
orga- equipo es responsable de
determinar lo que es apropiado para
cualquier proyecto dado. [1]
“Generalmente aceptados” conocimiento

también se podría ver como el conocimiento
que debe incluirse en el material de estudio de
un examen de licencia de software de
ingeniería (en los EE.UU.) que un graduado
tomaría después de completar cuatro años de
experiencia laboral. Estas dos definiciones
deben ser vistos como complementarios.
También se espera que los editores KA a ser un
poco hacia el futuro en su interpretación por
tak- ing en cuenta no sólo lo que se “reconoce
UN-8 Guía SWEBOK®
V3.0
Generalmente reconocido vida y ha sido adoptado por los dos principales

Establecidas ticas ticas organismos de normalización en la ingeniería de
utiliza sólo para ciertos tradicionales recomendadas software: ISO / IEC JTC 1 / SC7 y la Sociedad
especializado que se
por muchas organizaciones IEEE Computer Software

tipos de software
Prácticas
Avanzada e Investigación
prácticas innovadoras
probados y utilizados
solamente por algunas
organizaciones y conceptos
todavía siendo desarrolladas
y probadas en organizaciones
de investigación
La figura A.1. Categorías de Conocimiento
LONGITUD DE KA DESCRIPCIÓN
Las descripciones son KA ser aproximadamente

de 10 a 20 páginas utilizando la plantilla de
formato para documentos de publicado aún en
actas de la conferencia de la IEEE Computer
Society. Esto incluye texto, las referencias,
apéndices, tablas, etc. Esto, por supuesto, no
incluye los materiales de referencia mismos.
DOCUMENTOS RELACIONADOS
IMPORTANTE
1. Graduado de Ingeniería de Software 2009

(GSwE2009): Lineamientos Curriculares
para los programas de título de grado en
Ingeniería de Software, 2009;
www.gswe2009.org. [2]
Este documento “Proporciona directrices y

recomendaciones” para definir el plan de
estudios del programa de nivel de maestría
profesional en ingeniería de software. La Guía
SWEBOK se identifica como una “referencia
primaria” en el desarrollo del conjunto de
conocimientos que subyace a estas directrices.
Este documento ha sido aprobado oficialmente
por el IEEE Computer Society y patrocinada por
la Association for Computing Machinery.
2. IEEE Std. 12207-2008 (también conocido

como ISO / IEC 12207: 2008) estándar
para los sistemas y software de ingeniería
en software procesos de ciclo de vida,
IEEE, 2008 [3].
Esta norma se considera el estándar clave en

cuanto a la definición de procesos de ciclo de
Apéndice A A-9
y comités de normas de sistemas de ingeniería.
También se ha designado como norma
fundamental por el Comité de software y
sistema de ingeniería Normaliza- ción (S2ESC)
de la IEEE.
A pesar de que no tenemos la intención de
que la Guía de la ingeniería del cuerpo
software del Conocimiento sea plenamente
12207-conformes, esta norma sigue siendo un
insumo clave para la Guía SWEBOK, y un
cuidado especial será tomada a lo largo de la
Guía SWEBOK sobre la compatibilidad de la
Guía de la norma 12207.
3. JW Moore, La Hoja de Ruta de Ingeniería de

Software: Una guía basada en estándares,
Wiley-IEEE Computer Society Press,
2006. [4 *]
Este libro describe el alcance, funciones, usos y

tendencias de desarrollo de las normas de
ingeniería de software más ampliamente
utilizados. Se concentra en las actividades
importantes-calidad de ingeniería de software
y gestión de proyectos, ingeniería de sistemas,
confiabilidad y seguridad. El análisis y la
reagrupación de las colecciones estándar
expone al lector a las relaciones clave entre las
normas. A pesar de que la Guía SWEBOK no es
un estándar de ingeniería software per se, la
atención especial se tendrá en todo el
documento con respecto a la compatibilidad de
la Guía con la corriente IEEE y / Sistemas y
Software ISO IEC Inge-
Normas Colección niería.
4. Ingeniería de Software 2004:

Lineamientos Curriculares para los
programas de licenciatura en Ingeniería
de Software, IEEE Computer Society y
la Association for Computing
Machinery, 2004; http: // sites.
computer.org/ccse/SE2004Volume.pdf.
[5]
Este documento describe las directrices del

plan de estudios para una licenciatura en
ingeniería de software. La Guía SWEBOK se
identifica como “una de las fuentes primarias”
en el desarrollo del conjunto de conocimientos
que subyace a estas directrices.
5. ISO / IEC / IEEE 24765: 2010 Sistemas y

ISO / IEC / IEEE, 2010;
www.computer.org/ sevocab. [6]
UN-10 Guía SWEBOK®
V3.0
La jerarquía de referencia para la terminología la bibliografía. Creemos que este enfoque

es Diccionario Colegiado de Merriam Webster permite al lector a ser mejor expuesta a la fuente
(11 ed.) [7], IEEE / ISO / IEC 24765 [6], y el y el alcance de una norma.
nuevo propuesto definiciones si es necesario. Las figuras y tablas que se acompañan de
texto deben explicarse por sí mismo o tener
6. “Certificación y Capacitación para suficiente texto relacionado. Esto garantizaría
Profesionales de software,” IEEE que el lector sabe lo que las figuras y tablas
Computer Society, 2013; significan.
www.computer.org/certification. [8] A asegúrese de que alguna información en la
Guía de SWEBOK no se convierta rápidamente
Información sobre la certificación y productos lete obso- y debido a su carácter genérico, por
de desarrollo profesional asociados favor evite nombrar directamente herramientas y
desarrollados y ofrecidos por la IEEE Computer productos. En su lugar, tratar de nombrar sus
Society para los profesionales en el campo de la funciones.
ingeniería de software se puede encontrar en este
sitio web. La Guía SWEBOK es fundamental EDICIÓN
para estos productos.
Los editores de la Guía SWEBOK así como
Estilo y las Directrices Técnicas profesiones correctores sionales editarán
Descripción KA. La edición incluye edición de
• Las descripciones KA deben ajustarse a la textos (gramática, tuation pun-, y las
plantilla de Word disponible en mayúsculas), edición de estilo (confor- Mance el
www.computer. org / portal / web / cscps / libro de estilo Computer Society), y la edición
formato. de contenidos (flujo, es decir, la claridad, Ness
• Se espera Descripción KA seguir la guía de directa-, y la organización). La edición final será
estilo IEEE Computer Society (www. un proceso de colaboración en el que los editores
computer.org/portal/web/publications/ guía de la Guía SWEBOK y el KA Editores trabajar
de estilo). juntos para lograr una concisa, bien redactado-y
• Los archivos son para ser presentadas en útil KA Descripción.
Microsoft Word
formato. DIVULGACIÓN DE AUTOR
• Todas las citas de material de referencia han
de ser producido utilizando EndNote Web Todos los derechos de propiedad intelectual
como se indica en las instrucciones asociados con la Guía SWEBOK permanecerán
proporcionadas a los editores KA en este con el estándar IEEE. Editores KA deben firmar
sentido. un formulario de autorización de derechos de
autor.
OTROS directrices detalladas También se entiende que la Guía SWEBOK
seguirá siendo disponible de forma gratuita en el
Al hacer referencia a la Guía para la Ingeniería dominio público en al menos un formato,
de Software de Administración de proporcionado por la IEEE Computer Society
Conocimiento, utilizar el título de “Guía través de la web tecnolo- gía o por otros medios.
SWEBOK.” Para más información, ver
A los efectos de simplicidad, evitar las notas al www.computer.org/ copyright.htm.
pie y tratar de incluir su contenido en el texto
principal.
Utilizar referencias explícitas a las normas, en
contraposición
a la simple introducción de los números que
hacen referencia a los elementos de
Apéndice A A-11
Referencias
[1] Instituto de Gestión de Proyectos, una guía [5] Grupo de Trabajo Conjunto sobre
para la Dirección de Proyectos del Computación planes de estudio, IEEE
Conocimiento (PMBOK (R) Guía), 5ª ed., Computer Society y la Association for
Project Management Institute, 2013. Computing Machinery, Ingeniería de
Software 2004: Directrices Curriculares
[2] Integrado de Software e Ingeniería de para Pregrado Programas de Grado en
Sistemas Curriculum (ISSEC) Proyecto, Ingeniería de Software, 2004; http: // sites.
graduado de Ingeniería de Software 2009 computer.org/ccse/SE2004Volume.pdf.
(GSwE2009): Lineamientos Curriculares
para programas de postgrado en [6] ISO / IEC / IEEE 24765: 2010 Sistemas y de
Ingeniería de Software, Stevens Institute Ingeniería de Software-Vocabulario, ISO /
of Technology, 2009; www.gswe2009.org. IEC / IEEE 2010.
[3] IEEE Std. 12207-2008 (también conocido [7] Diccionario Colegiado de Merriam-Webster,
como ISO / IEC ed 11., 2003.
procesos de ciclo de vida del software [8] IEEE Computer Society, “Certificación y
Ingeniería de Software, IEEE 2008. Capacitación para Profesionales de
software”, 2013;
[4 *] JW Moore, La Hoja de Ruta de Ingeniería www.computer.org/certification.
Press, 2006.
UN-12 Guía SWEBOK®
V3.0
APÉNDICE B
IEEE e ISO / IEC NORMAS soportar el cuerpo

SOFTWARE INGENIERÍA DE CONOCIMIENTO
(SWEBOK)
Algunos podrían decir que el suministro de bases de datos . Como cualquier base de
normas niería de software niería supera con datos, estos contienen a veces errores,
creces la demanda. Rara vez se escucha una sobre todo para los títulos. Así que este
conferencia sobre el tema sin sufrir alguna artículo menudo parafraseará la
broma aparentemente obligatoria que hay
demasiados de ellos. Sin embargo, la existencia
de normas tiene una muy grande (posiblemente
infinita) de espacio comercial de alternativas y
reduce ese espacio para un conjunto más
pequeño de opciones, una gran ventaja para los
usuarios. Sin embargo, todavía puede ser difícil
elegir entre docenas de alternativas, por lo que
una orientación complementaria, como este
apéndice, puede ser útil. Una lista resumida de
las normas citadas en este apéndice aparece al
final.
A reducir el tedio en la lectura, algunas
simplificaciones y compendios se hacen en este
apéndice:
• ISO / IEC JTC 1 / SC 7 mantiene casi

doscientos normas sobre la materia. IEEE
mantiene unos cincuenta años. Las dos
organizaciones están en el décimo año de un
programa sistemático para coordinar e
integrar sus colecciones. En general, este
artículo se centrará en los Standards que son
reconocidos por ambas organizaciones,
teniendo esta condición como prueba de que
se ha obtenido un amplio consenso. Otras
normas serán mencionados brevemente.
• Normas tienden a tener títulos largos,
taxonómicas. Si hubiera un único estándar
para la construcción de un automóvil, el uno
para su Camry probablemente se titula algo
así como “vehículo de combustión interna,
de cuatro ruedas, pasajeros, sedán.”
Además, las organizaciones de estándares
modernos proporcionan a sus estándares de
título de la norma o simplemente utilizar su el IEEE coloca una marca en todas sus
número. En la obtención de un nivel de denominaciones normalizadores.
interés, el lector debe basarse en el número,
no el título, dada en este artículo. Por Hay algunos otros convenios de interés:
razones de coherencia, el artículo va a
utilizar la convención del IEEE para la • En tanto IEEE e ISO / IEC, las normas para
capitalización de títulos sustantivos, la ingeniería de sistemas son mantenidos
pronombres, adjetivos, verbos, adverbios y por el mismo comité que para la ingeniería
primera y última palabra tiene una letra, a de software. Muchas de las normas se
pesar de capital inicial el hecho de que IEEE aplican a ambos. Así, en lugar de hacer
e ISO / IEC uso diferente convenciones. distinciones sutiles, este artículo va a tratar
• Debido a que estas normas están siendo con ambos.
aliado continua- revisarse para tener en • Por otro lado, tanto S2ESC y SC 7 (ver más
cuenta las nuevas tecnolo- gías y patrones de abajo para una descripción de estas
uso, este artículo será obsoleta antes de su organizaciones) son responsables de las
publicación. Por lo tanto, de vez en cuando normas que no califican como “ingeniería”.
discuten las normas que aún no han sido En los EE.UU. y muchos otros países, los
publicados, si existe la posibilidad de asumir servicios de un ingeniero con licencia son
una importancia significativa. requiere cuando un producto puede afectar a
• marcas explícitas se omiten. Baste decir que la seguridad pública, la salud,
B-1
SEGUNDO-2 Guía
SWEBOK® V3.0
y el bienestar en lugar de afectar únicamente (JTC 1) es un niño de la Organización

el bolsillo del cliente. En este apéndice se Internacional para la estandarización (ISO) y la
respetará esa distinción e ignorar Standards Comisión Electrotécnica Internacional (IEC);
que parecen ser meramente económica en tiene el alcance de la “tecnología de informa-
consecuencia. ción” y subdivida su trabajo entre varios
• documentación del usuario se supone que es subcomités; Subcomité 7 (SC
desarrollados de forma similar al software.
Por ejemplo, un estándar en relación con el
diseño de la documentación del usuario se
describe en el software de diseño KA.
• Algunas normas elaboradas conjuntamente
se explic- tamente etiquetados como
desarrollos conjuntos, por ejemplo, ISO /
IEC / IEEE 24765. En otros casos, las
normas tienen diferentes denominaciones en
las dos organizaciones. Ejemplos incluyen
»IEEE Std. 12207: 2008 (también

conocido como ISO / IEC
12207: 2008), donde “alias” ( “también
conocido como”) es abreviatura ción de
este apéndice para señalar la
designación en la otra organización;
»IEEE Std. 15939: 2008 adopción
Estándar
ción de la norma ISO / IEC 15939:
2007, la adop- ción por IEEE de un
estándar desarrollado en la norma ISO /
IEC;
»IEEE Std. 1220: 2005 (también
conocido como ISO / IEC
26702: 2007), una “vía rápida” por la
norma ISO / IEC de un estándar
desarrollado en el estándar IEEE.
En cada uno de estos casos, las normas

son sustancialmente idénticos en las dos
organizaciones, que sólo difieren en la
materia frente y, en ocasiones, agregó
material informativo.
Se proporciona una lista de resumen de todos

los Standards mencionados al final de este
apéndice.
ISO / IEC JTC 1 / SC 7, software y sistemas

INGENIERÍA
ISO / IEC JTC 1 / SC 7 es la principal fuente de

las normas internacionales sobre el software e
ingeniería de sistemas. Su nombre está formado
taxonómicamente. Comité Técnico Conjunto 1
Carolina del Sur 7. Apéndice B B-3
7) es el responsable de software y sistemas
de ingeniería. SC 7, y sus grupos de trabajo, se
reúne dos veces al año, atrayendo delegaciones
represen- tando los organismos nacionales de
normalización de los países participantes.
Cada país sigue su propio procedimientos
para determinar las posiciones nacionales y
cada nación tiene la responsabilidad de
determinar si existe una norma ISO / IEC
debería ser adoptado como norma nacional.
SC 7 crea tres tipos de documentos:
• Normas internacionales: Los documentos,

con tener requisitos que deben cumplirse
con el fin de exigir la conformidad.
• Especificaciones técnicas (anteriormente
llamados informes técnicos, tipo 1 y tipo
2): documentos publicados en forma
preliminar mientras que el trabajo
continúa.
• Informes Técnicos (anteriormente
llamados Informes Técnicos, tipo 3): Los
documentos inherentemente inadecuadas
para ser estándares, por lo general debido a
que son más descriptiva que prescriptiva.
La clave para recordar es que sólo la primera

categoría cuenta como una norma de consenso.
El lector puede reconocer fácilmente a los
demás por el TS sufijo o TR antepone al
número del documento.
IEEE SOFTWARE Y SISTEMAS DE

INGENIERÍA Comité de Normas (S2ESC)
IEEE es la mayor organización mundial de

profesionales gías Nical, con cerca de 400.000
miembros en más de 160 países. La
publicación de normas se lleva a cabo por la
Asociación de Estándares IEEE (IEEE-SA),
pero los comités que redactan y patrocinan las
normas se encuentran en las distintas
sociedades del IEEE; S2ESC es una parte de la
Sociedad IEEE ordenador. IEEE es un
fabricante de normas global porque sus
estándares se utilizan en muchos países dife-
rentes. A pesar de su La membresía
internacional (alrededor del 50% fuera de
Estados Unidos), sin embargo, el IEEE-SA
somete habitualmente a sus estándares de la
American National Standards Institute (ANSI)
para Endorsement como “American National
Standards.” Algunos se desarrollan las normas
S2ESC dentro S2ESC, algunos se elabora
conjuntamente con el SC 7, y algunos son
adoptados después de ser desarrollado por
SEGUNDO-4 Guía
SWEBOK® V3.0
IEEE-SA publica tres tipos de “normas”: para cualquiera de las categorías del IEEE. En la
norma ISO / IEC, se trata de un “informe
• Normas, con una preponderancia del verbo técnico” -definido como un documento
"deberá" inherentemente inadecuado para ser un estándar.
• Métodos recomendados, con una La Guía SWEBOK IEEE 2004 fue adoptado por
preponderancia del verbo “debería” la ISO / IEC con- cabo el cambio.
• Guías, con una preponderancia de la palabra Presumiblemente, la norma ISO / IEC adoptará
“podrá”. Ver- sión 3 de la Guía SWEBOK.
Los tres de estos comparan con Dardos ISO /

IEC Están-. IEEE-SA tiene el concepto de un ISO / IEC TR 19759: 2005 Guía de Ingeniería-
“uso juicio-” estándar, que es más o menos Software para la Ingeniería de Software de
comparable a la norma ISO / IEC Especificación Administración de Conocimiento (SWEBOK)
Técnica. Sin embargo, no tiene nada comparable Se aplica a todos
a un Informe de cal ISO / IEC Técnicamente; se los KAs
buscaría en otro lugar IEEE para los documentos
de esta calaña. ISO / IEC 19759: 2005, una Guía de la
LOS ESTANDARES Conocimiento (SWEBOK), identifica y describe
ese subconjunto del conjunto de conocimientos
El resto de este artículo asigna los estándares que es generalmente aceptado, a pesar de que los
seleccionados a áreas de conocimiento ingenieros de software deben ser capaces no sólo
relevantes (KAS) de la guía SWEBOK. Hay una de conocimientos en ingeniería de software, sino
sección para cada KA. Dentro de cada sección, también, por supuesto, en otras disciplinas
las normas pertinentes son los que se aplican relacionadas. SWEBOK es un término inclusivo
principalmente a la KA, así como otros que se que describe la suma de conocimientos dentro de
aplica principalmente a otra KAs sino que la profesión de la ingeniería de software.
también están relacionados con el alquiler de un
Cur- los enumerados. Después de cada estándar
es un breve resumen. En la mayoría de los El texto de la Guía SWEBOK está dispo-
casos, el resumen es una cita o paráfrasis del libremente al poder www.swebok.org/. La
material introductorio abstracto o otra del texto adopción de ISO / IEC de la Guía está disponible
de la norma. gratuitamente en http: // estándares.
La mayor parte de las normas caber fácilmente iso.org/ittf/PubliclyAvailableStandards/index.
en un solo KA. Algunos encajan en más de uno; html.
en tales casos, se proporciona una referencia ISO / IEC / IEEE 24765 proporciona una
cruzada. Dos normas se aplican a todos los Kas, ulary vocab- compartido para los sistemas y
por lo que se enumeran en una categoría normas de ingeniería de software, tanto de SC 7
y S2ESC.
llamado “General”. Todos los estándares relacionados a
ingeniería (CASE), herramientas y entornos de descripciones de varias otras normas se refieren a

software asistida por ordenador se enumeran en ellos.
los modelos de ingeniería de software y métodos ISO / IEC TR 19759 es la Guía SWEBOK sí.
sección KA. No es un estándar IEEE porque, a falta de verbos
prescriptivos, que no satisface los criterios
GENERAL
Los dos primeros niveles son tan importantes

que podrían ser ranurados en toda la KAS. Dos
más están descritas en el Proceso de Ingeniería
de Software KA, pero se mencionan aquí, ya que
proporcionan un marco útil y porque las
ISO / IEC / IEEE 24765: 2010 Sistemas y de Apéndice B B-5
Ingeniería de Software-Vocabulario
Se aplica a todos
los KAs
ISO / IEC / IEEE 24765: 2010 proporciona un

vocabulario común aplicable a todos los
sistemas y obras de ingeniería de software. Fue
preparado para recoger y apoyar a la
normalización de la terminología. ISO / IEC /
IEEE 24765: 2010 está destinado a servir como
una referencia útil para aquellos en el campo
de la información tecno- logía y para fomentar
el uso de los sistemas y estándares de
ingeniería de software preparados por la ISO y
organizaciones de enlace IEEE Computer
Society y el Instituto de Gestión de Proyectos.
ISO / IEC / IEEE 24765: 2010 incluye
referencias a la
SEGUNDO-6 Guía
SWEBOK® V3.0
normas de origen activos para cada definición de Se define la construcción de un buen requisito,
manera que proporciona atributos y características de los
el uso de la expresión puede ser analizada requisitos, y discute la aplicación iterativa y
más. recursiva de los procesos de requisitos pasantes
a cabo el ciclo de vida. ISO / IEC / IEEE 29148:
2011 proporciona orientación adicional en la
El vocabulario es descriptiva, en lugar de aplicación de los procesos de requisitos de
prescriptivo; que recoge todas las definiciones ingeniería y gestión de las actividades de los
de todas las normas pertinentes, así como requisitos relacionados en la norma ISO / IEC
algunas otras fuentes, en lugar de elegir entre las 12207: 2008 e ISO / IEC 15288: 2008.
definiciones que compiten entre sí. Los elementos de información aplicables a la
El contenido de la norma 24765 es de libre ingeniería de requisitos y su contenido están
acceso en línea en www.computer.org/sevocab. definidos. El contenido de la norma ISO / IEC /
Dos estándares, 12207 y 15288, proporcionan un IEEE 29148: 2011 puede ser añadido al conjunto
conjunto completo de procesos de todo el ciclo existente de los procesos del ciclo de vida
de vida de un sistema o de un producto de relacionada REQUISITOS definidos por la
software. Los dos Standards están alineadas para norma ISO / IEC 12207: 2008 o ISO / IEC
su uso simultáneo en un solo proyecto o en una 15288: 2008, o puede ser utilizado de forma
sola organización. Se mencionan aquí porque se independiente.
utilizan a menudo como un marco para explicar o
localizar el papel de
otras normas en el ciclo de vida. Una norma ISO / IEC multiparte proporciona
principios y métodos para el software
“apresto”, basada en
sus requisitos. El tamaño funcional es a menudo
utilizar-
IEEE Std. 12207-2008 (también conocido como ful en el denominador de las mediciones de cali-
ISO / IEC 12207: 2008) dad y la productividad en el desarrollo de
Estándar para los sistemas y el software software. También puede desempeñar un papel
Ingeniería- Software Procesos del ciclo de vida en la contratación de los acuerdos de nivel de
Consulte Software Ingeniería de servicio.
Procesos KA
IEEE Std. 15288-2008 (también conocido como ISO / IEC15288: 2008)
Estándar para los sistemas y el software ISO / IEC 14143 [seis partes] Información Tech-
Ingeniería- vida del sistema los procesos de ciclo gía-funcional de software de medición-Medida del
Consulte Software Ingeniería de tamaño
Procesos KA
ISO / IEC 14143 describe FSM (medida del
tamaño funcional). Los conceptosde la medición
REQUISITOS DE SOFTWARE de tamaño funcional (FSM) están diseñados para
superar las limitaciones de los métodos
La norma principal para la ingeniería de anteriores de dimensionamiento software
requisitos de software y sistemas es una nueva desplazando el foco lejos de la medición de
que sustituye varios estándares IEEE existentes. cómo el software se implementa para medir el
Se proporciona una visión amplia de la tamaño en términos de las funciones requeridas
ingeniería de requisitos a través de todo el ciclo por el usuario.
de vida.
Ingeniería de Requisitos
/ IEC / IEEE 29148 ISO: 2011 Sistemas y de
Ingeniería de Software-Life Cycle procesos de
ISO / IEC / IEEE 29148: 2011 contiene
disposiciones para los procesos y los productos Apéndice B B-7
FSM es a menudo conocido como “punto de
relacionados con la inge- niería de requisitos la función de cuenta.” Las cuatro normas que
para los sistemas y productos de software y figuran a continuación son métodos alternativas
servicios a lo largo del ciclo de vida. para poder punto de la función de cuenta, todo
cumplir con los requisitos de la norma ISO / IEC
14143. El método dominante, en términos de
cuota de mercado, es el método IFPUG, que se
describe en la norma ISO / IEC 20926. Otros
métodos están destinados variaciones para
mejorar la validez de la cuenta en diversas
circunstancias. Por ejemplo, ISO / IEC 19761-
cósmico es
SEGUNDO-8 Guía
SWEBOK® V3.0
sobre todo destinados a ser utilizados en el DISEÑO DE SOFTWARE

software con una
componente en tiempo real. El diseño del software KA incluye tanto software
diseño arquitectónico (para la determinación del
relación-
ISO / IEC 19761: 2011 Ingeniería de Software- barcos entre los elementos del software y el
COS MIC: Un Tamaño Funcional Método de diseño detallado (para la descripción de los
medición elementos individuales). ISO / IEC / IEEE
42010 se refiere a la descripción de la
ISO / IEC 20926: 2009 Software y Sistemas de arquitectura de sistemas y software.
Inge- niería-Software-Medición IFPUG funcional
Método de Medición del Tamaño
ISO / IEC / IEEE 42010: 2011 Sistemas y Software
ISO IEC 20968/2002: Manual de Prácticas de de Ingeniería-Arquitectura Descripción
Análisis de Puntos de Función de conteo de
Ingeniería de Software-MK II ISO / IEC / IEEE 42010: 2011 se refiere a la
crea- ción, el análisis, y el mantenimiento de
ISO / IEC 24570: 2005 Software Ingeniería- arquitecturas de sistemas mediante el uso de las
NESMA funcional Tamaño sión Método de descripciones de la arquitectura. Se establece un
medición Ver- 2.1-Definiciones y Lineamientos modelo conceptual de la descripción de la
contando para la Aplicación del Análisis de Puntos arquitectura. Los contenidos requeridos de una
de Función descripción de la arquitectura se especifican.
puntos de vista arquitectura, los marcos de
arquitectura y descripción de la arquitectura
A veces requisitos se describen en lenguaje idiomas se introducen para la codificación de
natural, pero a veces se describen en las convenciones y prácticas comunes de la
notaciones formales o semiformales. El objetivo descripción de la arquitectura. El contenido
de Unified Modeling Language (UML) es requerido de puntos de vista de la arquitectura,
proporcionar a los arquitectos de sistemas, la arquitectura marco funciona y descripción de
ingenieros de software y desarrolladores de la arquitectura idiomas se especifica. Anexos
software con herramientas para el análisis, proporcionan la motivación y los antecedentes
diseño e implementación de sistemas basados en de los principales conceptos y terminología gía y
software, así como para el modelado de negocios ejemplos de aplicación de la norma ISO / IEC /
y procesos similares. Las dos partes de la norma IEEE 42010: 2011.
ISO / IEC 19505 definen UML, revisión 2. La
mayor ISO / IEC 19501 es una versión anterior
de UML. Se mencionan aquí porque a menudo Al igual que la norma ISO / IEC / IEEE
se utilizan para modelar los requisitos. 42010, el siguiente Stan- dard trata de software
“diseño” como una abstracción, independiente
de su representación en un documento. En
consecuencia, la norma coloca disposiciones
sobre
la descripción del diseño, en lugar de en diseño
ISO / IEC 19501: 2005 Información Tecnología Ver Modelos de Ingeniería de Software y
distribuido abierto Modeling Language (UML) métodos KA
Versión 1.4.2 Procesamiento-Unificado
Ver Modelos de Ingeniería de Software y
métodos KA
ISO / IEC 19505: 2012 [dos partes] Grupo de

Gestión de la Información Tech- nology-Objeto
Unificado Modelo- ing Language (UML del OMG)
sí mismo. Apéndice B B-9
IEEE Std. 1016-2009 estándar para las

descripciones Diseño Tecnología de la
Información-Sistemas-Diseño de Software
Esta norma describe los diseños de software y

establece el contenido de la información y la
organiza- ción de una descripción de diseño de
software (SDD). Un SDD es una
representación de un diseño de software que se
utiliza para registrar la información de diseño y
com- carse que la información de diseño de
diseño de la llave
SEGUNDO-10 Guía
SWEBOK® V3.0
grupos de interés. Esta norma está destinada norma es aplicable a la documentación del
para su uso en situaciones de cálculo en la que usuario para los sistemas de hardware
una descripción explícita de diseño de software incluyendo también.
es estar preparado. Estas situaciones incluyen
actividades tradicionales de construcción de
software (cuando el diseño conduce a código) y CONSTRUCCIÓN DEL SOFTWARE
situaciones de ingeniería inversa (cuando una
descripción del diseño se recupera de una El término “construcción de software” se refiere
implementación existente). Esta norma se puede a la creación detallada de software de trabajo,
aplicar a, cien- cien- comercial, militar o el significativa a través de una combinación de
software que se ejecuta en los ordenadores codificación, verificación, la unidad de pruebas,
digitales. Aplicabilidad no está limitado por el las pruebas de integración, y la depuración.
tamaño, la complejidad o criticidad del software. Hay pocas normas sobre los detalles de la
Esta norma puede ser aplicado a la descripción codificación de software. Se ha encontrado a
de alto nivel y diseños detallados. Este Dard través de (en su mayoría mala) experiencia de
Están- no prescribe metodologías específicas que las convenciones de codificación no son
para el diseño, gestión de la configuración, o la apropiados para la estandarización, ya que, en la
garantía de calidad. Esta norma no requiere el mayoría de los casos, el beneficio real viene de
uso de cualquier lenguaje de diseño particulares, la consistencia de la aplicación de una
pero esta- lishes requisitos en la selección de convención arbitraria en lugar de la propia
lenguajes de diseño para su uso en un SDD. Esta convención. Así, a pesar de las convenciones de
norma se puede aplicar a la preparación de los codificación son una buena idea, en general se
agentes de valores capturados como documentos deja a la organización o el proyecto para
en papel, bases de datos automatizadas, desarrollar un estándar tales.
herramientas de desarrollo de software, u otros Sin embargo, el tema de la codificación segura
medios de comunicación. ha atraído la atención en los últimos años debido
a que algunos lenguajes de codificación son
inseguros en la cara de ataque. Un informe
Por convención, este apéndice trata usuario técnico preparado por la norma ISO / IEC JTC 1
docu- mentación como parte de un sistema de / SC 22 (lenguajes de programación) describe
software. Por lo tanto, los diversos aspectos de nerabilities vul- en lenguajes de programación y
usuario Documentación- su diseño, su prueba, y cómo se puede evitar.
así sucesivamente-se asignan
a diferentes KAs. Los próximos Norma se ocupe deel
diseño de la documentación ISO / IEC TR 24772: 2013 Tecnología de

del usuario. Información Lenguajes de Programación-
Orientación a Evitar
vulnerabilidades en lenguajes de programación a
través
IEEE Std. 26514-2010 La adopción del estándar usuario y también proporciona una guía
ISO / IEC 26514: 2008 Sistemas y ingeniería de informativa para el estilo de documentación del
software-Requisitos para los diseñadores y usuario. Es independiente de las herramientas de
desarrolladores de documentación del usuario software que pueden ser utilizados para producir
la documentación y se aplica tanto a la
Esta norma establece los requisitos para el documentación impresa y la documentación en
diseño y desarrollo de software de usuario docu- pantalla. Gran parte de esta
mentación como parte de los procesos del ciclo
de vida. Define el proceso de documentación
desde el punto de la promotora documentación
vista- y también cubre el producto
documentación. En él se especifica la estructura,
contenido y formato de los documentos del
Selección de idioma y Uso Apéndice B B-11
ISO / IEC TR 24772: 2013 especifica el

software pro vulnerabilidades idioma
programa- que deben evitarse en el desarrollo
de sistemas en los que se requiere un
comportamiento seguro para la seguridad, la
seguridad, la mis- sion-crítico, y el software
crítico para el negocio. En general, esta guía es
aplicable al software desarrollado, revisado, o
mantenido para cualquier aplicación.
Las vulnerabilidades se describen en un
hombre-ner genérico que se aplica a una
amplia gama de lenguajes de programación.
Anexos se refieren la orientación genérica a
una selección de lenguajes de programación
específicos.
SEGUNDO-12 Guía
SWEBOK® V3.0
El Informe Técnico está disponible PRUEBAS DE SOFTWARE

gratuitamente en http: //
standards.iso.org/ittf/PubliclyAvailableStandards/ Curiosamente, hay pocos estándares para las
index.html. pruebas. IEEE Std. 829 es el más completo.
Dos Se mencionan las normas aquí porque la
unidad de pruebas es a menudo considerado
como una actividad de software
construcción. IEEE e ISO / IEC soncooperar
en el desarrollo de una norma conjunta de cuatro IEEE Std. 829-2008 estándar para el software y Sys
partes, 29119, que proporcionará un trata- tem Documentación de la comprobación
miento integral de la prueba y suplantar IEEE
Std. 1008. procesos de prueba a determinar si el Desa-
Ment productos de una determinada actividad se
ajustan a el
IEEE Std. 1008-1987 estándar para el software de requisitos de esa actividad y si el tem y / o
pruebas unitarias software sis- satisface sus necesidades de uso y
Consulte Software de usuarios previstos. tareas de proceso de
Testing KA pruebas se especifican para diferentes niveles de
integridad. Estas tareas de proceso determinan la
/ / IEEE 29119 [cuatro partes] (Borrador) Software amplitud y la profundidad adecuada de la
ISO IEC y Sistemas de Pruebas de Ingeniería de documentación de prueba. Los elementos de
Software documentación para cada tipo de documentación
Consulte Software de prueba a continuación, pueden ser
Testing KA seleccionados. El alcance de las pruebas abarca
sistemas basados en software, software,
hardware, cerámica y sus interfaces. Esta norma
La siguiente norma prevé la elaboración de la se aplica a los sistemas basados en software a
documentación de usuario durante un proceso de desarrollar, mantener, o reutilizados (herencia,
desarrollo ágil. Se menciona aquí porque el comerciales off-the-shelf, artículos
desarrollo ágil es a veces considerado como la nondevelopmental). El término “software”
construcción. también incluye el firmware, microcódigo, y
documentación. procesos de prueba pueden
incluir
inspección, análisis, demostración, verificación,
ISO / IEC / IEEE 26515: 2012 Sistemas y de y validación de software y software basado en
Ingeniería de Software-El desarrollo de productos del sistema.
documentación del usuario en un entorno ágil
Ver Modelos de Ingeniería de Software y
métodos KA IEEE Std. 1008 se centra en las pruebas
unitarias.
Codificación no es la única manera de crear IEEE Std. 1008-1987 estándar para el software de
un producto de software. A menudo código (así pruebas unitarias
como los requisitos y diseño) se vuelve a utilizar
en proyectos anteriores o Engineers neered para El objetivo principal es especificar un método
su reutilización en proyectos futuros. IEEE Std. estándar para la unidad de pruebas de software
1517 se menciona aquí, ya que proporciona un que puede ser utilizado como base para el
marco común para la ampliación de los procesos software de sonido Engineer- ing práctica. Un
del ciclo de vida del sistema y software de IEEE segundo objetivo es describir los conceptos de
Std. 12207: 2008 para incluir la práctica ingeniería de software y los supuestos de prueba
sistemática de la reutilización. en la que el enfoque estándar es
Apéndice B B-13
basado. Un tercer objetivo es proporcionar
dirección
IEEE Std. 1517-2010 estándar para la tecnología y la información de recursos para ayudar con la
de la información del sistema y del software-Vida puesta en imple- y el uso del enfoque de la
Procesos de reutilización de procesos de ciclo unidad de pruebas estándar.
Consulte Software Ingeniería de
Procesos KA
SEGUNDO-14 Guía
SWEBOK® V3.0
IEEE e ISO / IEC JTC 1 / SC 7 están En él se especifica procesos para su uso en

cooperando en un proyecto para desarrollar una pruebas y revisión de la documentación del
única norma global que cubre todos los aspectos usuario. No se limitadas a la fase de prueba y
de las pruebas. Uno puede esperar la publicación revisión del ciclo de vida, sino que incluye
de la norma de cuatro partes para el año 2014. actividades durante los procesos de gestión de
Las porciones del contenido siendo información y de gestión de la documentación.
controversial. Una cuestión es si taxonómico
“métodos estáticos” -tales como la inspección,
revisión y análisis de estática-deben encontrarse Dos Se mencionan las normas aquí porque
dentro del alcance de la “ing Ensayos” o deben algunas fuentes consideran la verificación y
ser distinguido como “verificación y validación de software que se incluyen en las
validación.” A pesar de que la resolución de la pruebas taxonómicamente.
cuestión es, probablemente, de poca importancia
para los usuarios de la norma, asume una gran
importancia a la
en estándares escritores que deben gestionar una integrado
El conjunto de normas interoperar. IEEE Std. 1012-2012 estándar para el sistema y

Soft-
Artículos de Verificación y Validación
/ / IEEE 29119 [cuatro partes] (Borrador) Ver la calidad del software
Software ISO IEC y Sistemas de Pruebas de KA
IEEE Std. 1044-2009 norma para la clasificación de
El propósito de la norma ISO / IEC 29119 Las anomalías de software
Software Testing es definir un estándar Ver la calidad del software
internacionalmente aceptado para las pruebas de KA
software que puede ser utilizado por cualquier
organiza- ción al realizar cualquier tipo de
pruebas de software. MANTENIMIENTO DEL SOFTWARE
Este estándar el resultado de la armonización de

Las pruebas de la documentación del usuario distintos estándares IEEE e ISO / IEC en el
se describe en el próximo estándar, sujeto-describe un proceso integral para la
proporcionando requisitos para el examen y gestión y ejecución de software de manteni-
revisión de la documentación de usuario del miento. Se expande en lo dispuesto en el proceso
software como parte de los procesos del ciclo de de mantenimiento de software previsto en la
vida. Define el proceso de documentación del norma ISO / IEC / IEEE 12207.
punto de vista del probador de documentación y
revisor. Es relevante
a los roles que participan en pruebas y desarrollo de
software y documentación del usuario, IEEE Std. 14764-2006 (también conocido como ISO
incluyendo proyec- gestores ect, expertos en / IEC 14764: 2006)
usabilidad y desarrolladores de información Estándar de Ciclo de Vida del Software Ingeniería
adicionales a los probadores y colaboradores. de Software-Procesos-Mantenimiento
ISO / IEC14764: 2006describesingreater
IEEE Std. 26513-2010 La adopción del estándar

ISO / IEC 26513: 2009 Sistemas y ingeniería de ISO / IEC 26513 proporciona las exigencias
software-Requisitos para Probadores y revisores mínimas para la comprobación y revisión de
de Documentación usuario docu- mentación, incluyendo tanto
documentos impresos y en pantalla se utilizan en Apéndice
gestión detalle del proceso de mantenimiento se B B-15
el entorno de trabajo de los usuarios del software describe en ISO / IEC 12207, incluyendo tos
de sistemas. Se aplica a los manuales impresos modifica-. También establece las definiciones de
de usuario, ayuda en línea, tutoriales y los tipos ous variabilidad de mantenimiento. ISO
documentación Las alusiones usuario. / IEC 14764: 2006 proporciona orientación que
se aplica a la planificación, eje- cución y control,
revisión y evaluación, y el cierre del proceso de
mantenimiento. El alcance de la norma ISO /
IEC 14764: 2006 incluye el mantenimiento de
múltiples productos de software con los mismos
recursos de mantenimiento. “Mantenimiento” en
la norma ISO / IEC 14764: 2006 significa el
mantenimiento del software a menos que se
indique lo contrario.
SEGUNDO-16 Guía
SWEBOK® V3.0
ISO / IEC 14764: 2006 proporciona el marco en la ISO / IEC / IEEE Std. 24765 y los
dentro del cual se pueden ejecutar los planes de requisitos de elemento de información de IEEE
mantenimiento de software genéricas y Std. 15939.
específicas, evaluados y adaptados al ámbito
mantenimiento y la magnitud de los productos
de software dadas. Proporciona el marco, la ISO / IEC JTC 1 / SC 7 aún no ha
terminología precisa, y procesos para permitir la determinado qué medidas se deben tomar con
aplicación coherente de gía tecnolo- respecto a la nueva norma IEEE Std. 828. Hay
(herramientas, técnicas y métodos) para cuestiones relativas a la medida de la
mantenimiento de software. compatibilidad con la norma ISO / IEC / IEEE
No se refiere a la operación del software y las 12207 y otras normas en la suite SC 7. Cabe
funciones operativas, por ejemplo, copia de señalar, sin embargo, que SC 7 no tiene un
seguridad, recuperación y administración del estándar de competencia.
sistema, que normalmente se lleva a cabo por
aquellos que operan el software. GESTIÓN DE INGENIERÍA DE
ISO / IEC 14764: 2006 está dirigido SOFTWARE
principalmente a los encargados del
mantenimiento de software y, además, para los La mayoría de los lectores interpretar la
responsables del desarrollo y Ance assur- expresión “gestión de la ingeniería de software”
calidad. También puede ser utilizado por los en el sentido de la gestión de un proyecto que se
adquirentes y usuarios de sistemas que contienen refiere el software. Hay al menos dos posibles
software, que pueden proporcionar insumos para extensiones a este eralization ge-, sin embargo.
el plan de mantenimiento. Algunas de las actividades de software se
gestionan de acuerdo con un acuerdo de nivel de
servicio (SLA). SLA no cumplen con los
Software Configuration Management criterios de “proyecto” de acuerdo con algunas
definiciones. También, se ha convertido en un
Thereisonestandardfor acuerdo general de que algunos gestión de
configuración software debe ocurrir en la organización a un
administración. nivel por encima del proyecto, por lo que todos
los proyectos se pueden beneficiar de una
inversión común. Un ejemplo comúnmente
citado es la provisión de pro- software
cesos y herramientas de la organización.
IEEE Std. 828-2012 estándar para la configuración gestión de proyectos de software puede ser
Gestión de Sistemas e Ingeniería de Software considerado como una especialización de
“gestión de proyectos” - a menudo considerado
Esta norma establece las exigencias mínimas como una disciplina distinta. Guía del Instituto
para los procedimientos de gestión de la de Gestión de Proyectos para la Dirección de
configuración (CM) en los sistemas e ingeniería Proyectos (Guía del PMBOK®) es a menudo
de software. La aplicación de esta norma se considerado como la fuente autorizada para este
aplica a cualquier forma, clase o tipo de software conocimiento. De vez en cuando, IEEE adopta la
o sistema. Esta revisión de la norma amplía la versión más reciente de la Guía PMBOK ®
versión anterior para explicar CM, incluyendo la como un estándar IEEE.
identificación y adquisición
los elementos de configuración, el control de cambios, informe-
ing el estado de los elementos de configuración, que CM actividades se van a hacer, cuando están
así como el software construye y liberar la a suceder en el ciclo de vida, y qué planificación y
ingeniería. Su predece- predefinido sólo el se requieren recursos. También se describen las
contenido de un plan de gestión de áreas de contenido para un plan de CM. Los
configuración de software. Esta norma aborda lo puertos SUP- estándar ISO / IEC / IEEE 12207:
2008 e ISO / IEC / IEEE 15288: 2008 y se adhiere
a la terminología Apéndice
IEEE Std. 1490-2011 Guía-Aprobación B B-17
del Project
Management Institute (PMI ®) estándar, Una
Guía para la Gestión de Proyectos El conocimiento
(Guía del PMBOK®) -Cuarto Edición
La Guía del PMBOK® identifica el subconjunto

de la Dirección de Proyectos del conocimiento
generalmente reconocida como buena práctica.
“Generalmente reconocido” significa el
conocimiento y las prácticas descritas son
aplicables a la mayoría de los proyectos de la
mayoría de
SEGUNDO-18 Guía
SWEBOK® V3.0
el tiempo y existe un consenso sobre su valor y Particularmente en aplicaciones de alta

utilidad. “La buena práctica” significa que hay tecnología y proyectos de graves consecuencias,
acuerdo general en que la aplicación de estas la gestión de riesgos es un aspecto importante de
habilidades, herramientas y técnicas puede las responsabilidades de gestión en general pro-
mejorar las posibilidades de éxito en una amplia yecto. Esta norma se ocupa de ese tema.
gama de proyectos. La buena práctica no
significa que el conocimiento descrito siempre
debe
aplicarse de manera uniforme a todos los proyectos; elorganiza-
ción y / o el equipo de gestión de proyectos es IEEE Std. 16085-2006 (también conocido como ISO
responsable para determinar lo que es / IEC 16085: 2006)
apropiado para cualquier proyecto dado. La Guía Estándar para los sistemas y el software
del PMBOK® también proporciona y promueve Ingeniería- vida del software de Procesos-Riesgos
un vocabulario común dentro de la profesión de ciclo de gestión
gestión de proyectos para la discusión, la
escritura y la aplicación de conceptos de gestión ISO / IEC 16085: 2006 define un proceso para la
de proyectos. Tal vocabulario estándar es un gestión del riesgo en el ciclo de vida. Se puede
elemento esencial de una disciplina profesional. añadir al conjunto existente de los procesos del
El Project Management Institute (PMI) ciclo de vida del software del sistema y
considera que esta norma como referencia definidos por la norma ISO / IEC 15288 y ISO /
fundamental la gestión de proyectos para sus IEC 12207, o puede ser utilizado
programas y certificaciones de desarrollo independientemente.
profesional. ISO / IEC 16085: 2006 puede ser aplicado
igualmente a
sistemas y software.
Las revisiones de la norma ISO / IEC / IEEE El propósito de la gestión de riesgos es iden-
2008 12207 y 15288 proporcionan los procesos potenciales problemas de gestión y técnicas
de gestión de proyectos de software y sistemas y tificar antes de que ocurran de manera que se
relacionarlos con los procesos a nivel de pueden tomar medidas que reducen o eliminan la
organización, así como los procesos gías Nical. probabilidad y / o el impacto de estos problemas
El desarrollaron conjuntamente norma 16326, en que puedan producirse. Es una herramienta de
sustitución de dos normas más antiguas, amplía cal criti- para determinar continuamente la viabi-
estas disposiciones con orientación para su lidad de los planes de proyecto, para mejorar la
aplicación. búsqueda e identificación de problemas
potenciales que pueden afectar a las actividades
del ciclo de vida y la calidad y rendimiento de
los productos, y para mejorar la gestión activa de
proyectos .
ISO / IEC / IEEE 16326: 2009 Sistemas y Cesión

de Software Ingeniería de Procesos-Life-Cycle El análisis de riesgos y mitigación de riesgo
Gestión de Proyectos depende crucialmente de medición. Esta norma
internacional proporciona una elaboración del
ISO / IEC / IEEE 16326: 2009 proporciona las proceso de medi- ción de la norma ISO / IEC /
especificaciones de contenido normativo de los IEEE 15288: 2008 e ISO / IEC / IEEE 12207:
planes de gestión de proyectos que abarca 2008.
proyectos de software y software-
proyectos de sistemas intensivos. También proporcionadetallado
discusión y asesoramiento sobre la aplicación de ware y blandas como cubiertos por la norma ISO /
un conjunto de procesos proyecto que son IEC 12207: 2008 (IEEE Std 12207-2008.) e ISO /
comunes tanto para el ciclo de vida del sistema IEC
15288: 2008 (IEEE Std 15.288-2008.), IEEE Std. 15939-2008 La adopción del Apéndice
estándar B B-19
Respectivamente. La discusión y consejos están ISO / IEC 15939: 2007 Sistemas y Procesos
destinados a ayudar en la preparación del ingeniería de software-Medición
contenido normativo de los planes de gestión de
proyectos. ISO / IEC / IEEE 16326: 2009 es el ISO / IEC 15939 define un proceso de medición
resultado de la armonización de la norma ISO / aplicables a sistema y ingeniería de software y
IEC TR 16326: 1999 e IEEE Std. 1058-1998. disciplinas de gestión. El proceso se describe a
través de un modelo que define las actividades
del proceso de medición que se requieren para
especificar adecuadamente lo que se requiere
informa- ción de medición, cómo se pueden
aplicar a las medidas y análi- sis resultados, y
cómo determinar
Apéndice B B-11
si los resultados del análisis son válidos. El para producir o gestionar la documentación, y se
proceso de medición es flexible, tailorable, y aplica tanto a la documentación impresa y la
adaptable a las necesidades de diferentes documentación en pantalla. Gran parte de su
usuarios. orientación es aplicable a la documentación del
ISO / IEC 15939: 2007 identifica un proceso usuario para los sistemas que incluyen utensilios
que es compatible con la definición de un de hardware así como software.
conjunto adecuado de medidas que aborden las
necesidades de información específica. En él se
identifican las actividades y tareas que son A veces, el software o los componentes del
necesarias para éxito- totalmente identificar, sistema se adquieren en lugar de desarrollarse.
definir, seleccionar, aplicar y mejorar la
medición dentro de un proyecto global o la
estructura de medición zational orga-. También
proporciona
definiciones de los términos de medición comúnmente usado
dentro de las industrias de sistemas y IEEE Std. 1062-1998 Práctica Recomendada para
software. la adquisición de software
Se describe un conjunto de prácticas útiles de

proyectos de software a menudo requieren el calidad que pueden ser seleccionados y
desarrollo de la documentación del usuario. aplicados durante uno o más pasos de un proceso
Gestión del proyecto, por lo tanto, incluye la de adquisición de software. Esta práctica
gestión del esfuerzo de documentación. recomendada se puede aplicar al software que se
ejecuta en cualquier sistema informático sin
tener en cuenta
el tamaño, complejidad o criticidad del software,
ISO / IEC / IEEE 26511: 2012 Sistemas y de pero es más adecuado para su uso on-off-the-
Ingeniería de Software-Requisitos para los modificado
gerentes de Documentación del usuario software comercial y software
completamente desarrollado.
ISO / IEC / IEEE 26511: 2012 especifica los
procedimientos para la gestión de la
documentación de usuario en todo el ciclo de A veces, la documentación del usuario se
vida del software. Se aplica a las personas u adquiere con independencia de que el software
organizaciones que producen suites de se describe fue adquirida. Los siguientes Norma
documentación, a los que realizan un único se ocupe de ese tema.
proyecto de documentación,
y la documentación producida internamente, como bien
en cuanto a la documentación contratado para funciones necesarias en un equipo de

las organizaciones de servicios externos. documentación del usuario. Se ocupa de las
Proporciona una visión general de los procesos mediciones y estimaciones necesarias para el
de documentación ware y gestión de la control de la gestión y el uso de procesos tales
información blandos, y también presenta como la gestión del cambio, el horario y el control
aspectos de la planificación de la cartera y de costes, gestión de recursos y gestión de la
gestión de contenidos que los administradores de calidad y el proceso de mejora ción de apoyo.
la documentación de usuario se aplican. Abarca Incluye requisitos para documentos clave
las actividades de gestión en el inicio de un producidos para la gestión de la documentación
proyecto, incluyendo el establecimiento de del usuario, incluyendo los planes de
procedimientos y especificaciones, el documentación y los planes de gestión de
establecimiento de infraestructura y documentación. ISO / IEC / IEEE 26511: 2012 es
construcción de un equipo. Incluye ejemplos de independiente de las herramientas de software que
SEGUNDO-12 Guía
pueden utilizarse ISO / IEC / IEEE 26512: 2011 Sistemas y de
SWEBOK® V3.0
Ingeniería de Software-Requisitos para los
adquirentes y SUP- pinzas de Documentación del
usuario
ISO / IEC / IEEE 26512: 2011 ha sido

desarrollado para ayudar a los usuarios de la
norma ISO / IEC / IEEE 15288: 2008 o ISO /
IEC / IEEE 12207: 2008 para la adquisición o la
documentación de usuario del software de
alimentación como parte de los procesos del
ciclo de vida del software. Define el proceso de
documentación desde el punto de vista de la
entidad adquirente y el punto de vista del
proveedor. ISO / IEC / IEEE 26512: 2011 cubre
los requisitos de los elementos de información
utilizados en la adquisición de productos de
documentación de usuario: el plan de
adquisición, especificación documento, Ment
por el estado de trabajo, solicitud de propuestas,
y propuesta. Proporciona una visión general de
los procesos de documentación de usuario del
software y la gestión de la información que
pueden requerir la adquisición y suministro de
productos y servicios de documentación de
usuario de software. Se ocupa de la preparación
de los requisitos para
Apéndice B B-13
software documentación del usuario. Estos mejora de las prácticas. Por ejemplo, se podría
requisitos son esenciales para la especificación proponer una práctica mejorada para el
de documentos del usuario y declaración de software de análisis de los requisitos. Un
trabajo. Incluye requisitos para salidas de tratamiento ingenuo podría relacionar la
documentos primarios del proceso de descripción a una etapa temprana del modelo del
adquisición y suministro: la solicitud de ciclo de vida. Un enfoque superior es para
propuesta y la propuesta de productos y describir la práctica en el contexto de un proceso
servicios de documentación del usuario. que puede ser aplicado en cualquier etapa del
También se analiza el uso de un plan de gestión ciclo de vida. El proceso de análisis de
de la documentación y la de un plan de requisitos, por ejemplo, es preciso proceder a la
documento a medida que surjan en los procesos etapa de desarrollo, para el mantenimiento, y
de adquisición y suministro. ISO / IEC / IEEE con frecuencia para el retiro, por lo que una
26512: 2011 es independiente de las mejora de la práctica se describe en términos del
herramientas de software que pueden ser proceso de análisis de requisitos se puede aplicar
utilizados para producir la documentación y se a cualquiera de estas etapas.
aplica tanto a la documentación impresa y la Las dos normas principales son la norma ISO /
documentación en pantalla. Gran parte de su IEC / IEEE 12207, los procesos de ciclo de vida
orientación es aplicable a la documentación del del software, e ISO / IEC / IEEE 15288, la vida
usuario para los sistemas que incluyen hardware, del sistema los procesos de ciclo. Las dos
así como el software. normas tienen historias distintas, pero ambos
fueron revisados en 2008 para alinear sus pro-
cesos, lo que permite su uso interoperable a
Se mencionan las siguientes dos normas aquí, través de un amplio espectro de proyectos que
porque proporcionan información utilizada en la van desde un componente de software autónomo
toma de decisiones ción manage-. a un sistema con contenido de software ligible
neg. Ambos están siendo revisados
de nuevo con la intención de que contiene una
idéntico
IEEE Std. 1028-2008 estándar para las revisiones lista de procesos, pero con disposiciones
de software y auditorías especializadas para las respectivas disciplinas.
Ver la calidad del
software KA
IEEE Std. 12207-2008 (también conocido como ISO
IEEE Std. 1061-1998 Estándar de Calidad de / IEC 12207: 2008)
Software Metodología Métrica Estándar para los sistemas y el software
Ver la calidad del Ingeniería- Software Procesos del ciclo de vida
software KA
ISO / IEC 12207: 2008 establece un marco
común para los procesos del ciclo de vida del
La siguiente norma se menciona, ya que software, con la terminología bien definida que
incluye el papel del gerente en el desarrollo de puede ser referenciado por la industria del
documentación de usuario en un proyecto ágil. software.
ISO / IEC 12207: 2008 se aplica a la adquisi-
ción de los sistemas y productos de software y
ser-
ISO / IEC / IEEE 26515: 2012 Sistemas y de SOFTWARE INGENIERÍA DE PROCESOS
Ingeniería de Software-El desarrollo de
documentación del usuario en un entorno ágil procesos de software e ingeniería de sistemas son
Ver Modelos de Ingeniería de fundamentales para la normalización de esas dos
Software y disciplinas, no sólo porque muchos están intere-
métodos KA sadas en la mejora de procesos, sino también
porque los procesos son eficaces para la
descripción de
SEGUNDO-14
vicios y conGuíael suministro, desarrollo,
SWEBOK® V3.0
operación, mantenimiento y eliminación de
productos de software y la parte de software de
un sistema, ya sea interna o externamente a
cabo a una organiza- ción. se incluyen aquellos
aspectos de la definición del sistema necesario
para proporcionar el contexto para los
productos y servicios de software.
ISO / IEC 12207: 2008 proporciona también
un procedimiento que puede ser empleado para
definir, controlar y mejorar los procesos del
ciclo de vida del software.
Los procesos, actividades y tareas de la
norma ISO / IEC 12207: 2008, ya sea solo o en
combinación con la norma ISO / IEC 15288-
también puede ser aplicado durante la
adquisición de un sistema que contiene el
software.
Apéndice B B-15
IEEE Std. 15288-2008 (también conocido como elementos de información (productos de

ISO / IEC 15288: 2008) información, docu- mentación) para ser
Estándar para los sistemas y el software desarrollados y revisados en los sistemas y los
Ingeniería- vida del sistema los procesos de ciclo ciclos de vida del software y procesos de gestión
de servicios. Se especifica el propósito y el
ISO / IEC 15288: 2008 establece un marco contenido de todos los sistemas identificados y
común para describir el ciclo de vida de los los registros de datos de software y elementos de
sistemas creados por los seres humanos. Se información de ciclo de vida, así como los
define un conjunto de procesos y terminología registros y elementos de información para la
asociada. Estos procesos se pueden aplicar en gestión de servicios de tecnología de la
cualquier nivel en la jerarquía de la estructura de información. El contenido elemento de
un sistema. conjuntos seleccionados de estos información se definen de acuerdo con los tipos
procesos se pueden aplicar durante todo el ciclo genéricos de documentos (descripción, plan de,
de vida de la gestión y la realización de las helado Pol, el procedimiento, informe, solicitud,
etapas del ciclo de vida de un sistema. Esta es y en las especificaciones) y el propósito
plished acompa- mediante la participación de específico del documento. Para simplificar la
todas las partes interesadas, con el objetivo referencia, cada elemento de información se
último de lograr la satisfacción al cliente central. describe como si se publicó como documento
ISO / IEC 15288: 2008 también proporciona separado. Sin embargo, los elementos de
procesos que apoyan la definición, el control, y información pueden ser inéditos pero está
la mejora de los procesos del ciclo de vida disponible en un repositorio para referencia,
utilizadas dentro de una organización o de un dividido en documentos separados o volúme-
proyecto. Las organizaciones y los proyectos nes, o en combinación con otros elementos de
pueden utilizar estos procesos de ciclo de vida información en un solo documento. ISO / IEC /
en que la adquisición y el suministro de IEEE 15289: 2011 se basa en los procesos del
sistemas. ciclo de vida que se especifican en la norma ISO
ISO / IEC 15288: 2008 se refiere a los / IEC 12207: 2008 (. IEEE Std 12207-2008)
sistemas que son hechas por el hombre y pueden e ISO / IEC 15288: 2008 (IEEE Std 15288-.
ser configurados con uno o más de los 2008), y la gestión de servicios de procesos
siguientes: hardware, software, datos, los especificados en la norma ISO / IEC 20000-1:
humanos, los procesos (por ejemplo, los 2005 e ISO / IEC 20000-2: 2005.
procedimientos para el servicio a los usuarios
Viding pro), procedimientos ( por ejemplo,
instrucciones de opera- tor), instalaciones, Los siguientes dos guías proporcionan
materiales y entidades de rally que ocurre natu-. complementaria
Cuando un elemento del sistema es el software, información útil en la aplicación de 12207 y
los procesos del ciclo de vida del software docu- 15288.
mentado en la norma ISO / IEC 12207: 2008 se puede utilizar a
aplicar ese elemento del sistema. IEEE Std. 24748,2-2012 Guía de implantación de
ISO / IEC 15288: 2008 e ISO / IEC 12207: la norma ISO / IEC TR 24748-2: 2011 Sistemas y
2008 Software Inge- niería-Life Management-Parte 2
están armonizadas para el uso simultáneo en Ciclo: Guía para la aplicación de la norma ISO /
un solo proyecto o en una sola organización. IEC 15288 (Procesos del ciclo de vida del sistema)
ISO / IEC TR 24748-2 es una guía para la apli-

Estas dos normas especifican que los procesos cación de la norma ISO / IEC 15288: 2008.
pueden producir elementos de información, pero Aborda sistema, ciclo de vida, proceso,
no pre- escriba su contenido o formato. El organización, proyecto, y los conceptos de
siguiente estándar proporciona ayuda con eso. adaptación, principalmente a través de la
referencia a la norma ISO / IEC TR 24748-1 e
ISO / IEC
15288: 2008. A continuación, da orientaciones
SEGUNDO-16 Guía
sobre la aplicación de
SWEBOK® V3.0
ISO / IEC / IEEE 15289: 2011 Sistemas y de ISO / IEC 15288: 2008, de los aspectos de la es-
Ingeniería de Software-contenido del Ciclo de Vida trategia, la planificación, la aplicación en las
de Productos de Información (Documentación) organizaciones, y la aplicación de proyectos.
ISO / IEC / IEEE 15289: 2011 proporciona los IEEE Std. 24.748,3-2012 Guía de implantación de
requisitos para la identificación y planificación la norma ISO / IEC TR 24748-3: 2011 Sistemas y
de la específica Software
Apéndice B B-17
Ingeniería-Life Management-Parte 3 Ciclo: Guía guías de aplicación actualizados para los

para la aplicación de la norma ISO / IEC 12207 estándares internacionales. ISO / IEC TR 24748-
(procesos de ciclo de vida Cesión de Software) 1 es el resultado de la etapa de alineación de la
armonización de la norma ISO / IEC 12207 y
ISO / IEC TR 24748-3 es una guía para la apli- ISO / IEC 15288.
cación de la norma ISO / IEC 12207: 2008.
Aborda sistema, ciclo de vida, proceso,
organización, proyecto, y los conceptos de La siguiente norma amplía las disposiciones
adaptación, principalmente a través de la de la norma ISO / IEC / IEEE 12207 para hacer
referencia a la norma ISO / IEC TR 24748-1 e frente a la reutilización del software sistemática.
ISO / IEC 12207: 2008. Se proporciona
orientación sobre la aplicación de la norma ISO /
IEC 12207: 2008, de los aspectos de estrategia,
la planificación, la aplicación en las IEEE Std. 1517-2010 estándar para la tecnología
organizaciones, y la aplicación de proyectos. de la información del sistema y del software-Vida
Procesos de reutilización de procesos de ciclo
Las normas 12207 y 15288 proporcionan Un marco común para la ampliación de los
cesos pro que cubren el ciclo de vida, pero que procesos del ciclo de vida del sistema y software
no proporcionan un modelo estándar de ciclo de de IEEE Std. 12207: 2008 para incluir se
vida (cascada, la entrega incrementales, proporciona la práctica sistemática de la
prototipo impulsado, etc). La selección de un reutilización. Los procesos, actividades y tareas
modelo de ciclo de vida apropiado para un que deben aplicarse durante cada proceso de
proyecto es una de las principales ciclo de vida para permitir a un sistema y / o
preocupaciones de la norma ISO / IEC 24748-1. producto para ser construido a partir de los
activos reutilizables se especifican.
Los procesos, actividades y tareas a
habilitar
IEEE Std. 24.748,1-2011 Guía de implantación de la identificación, construcción, mantenimiento y
la norma ISO / IEC TR 24748-1: 2010 niería-Life gestión de los bienes suministrados también se
Cycle Management-Parte Sistemas y Software especifican.
Inge- 1: Guía para la Gestión del Ciclo de Vida
ISO / IEC TR 24748-1 proporciona información IEEE Std. 1220 ha sido ampliamente aplicado
sobre los conceptos de ciclo de vida y las como un proceso de ingeniería de sistemas y fue
descripciones de las poses PUR y los resultados adoptado por la norma ISO / IEC 26702. con el
de las etapas del ciclo de vida representativos. número Desafortunadamente, la norma no es
También ilustra el uso de un modelo de ciclo de totalmente compatible con la norma ISO / IEC /
vida para los sistemas en el contexto de la norma IEEE 15288 y está siendo revisada para resolver
ISO / IEC 15288 y proporciona una ilustración ese problema. El resultado será publicado como
correspondiente de la utilización de un modelo ISO / IEC / IEEE 24748-4.
de ciclo de vida para el software en el contexto
de la norma ISO / IEC 12207. ISO / IEC TR
24748- 1
además proporciona una discusión detallada y
asesoramiento sobre la adaptación de un modelo versiones anteriores y actuales de ISO / IEC
de ciclo de vida para su uso en un proyecto 12207 y ISO / IEC 15288, así como consejos
específico y entorno de la organización. Se sobre la transición de antes de las versiones
proporciona orientación adicional sobre el ciclo actuales y sobre el uso de sus guías de aplicación.
de vida modelo de uso de los ámbitos, La dis- cusión y asesoramiento están destinadas a
disciplinas y especialidades. ISO / IEC TR proporcionar un modelo de referencia para los
24748-1 da una comparación detallada entre las modelos de ciclo de vida, facilitar el uso de la
SEGUNDO-18 Guía
versión actualizada de la norma ISO / IEC IEEE Std. 1220-2005 (también conocido como ISO /
SWEBOK® V3.0 IEC 26702: 2007)
15288 e ISO / IEC 12207, y proporcionar un
marco para el desarrollo de Estándar para la aplicación y gestión del proceso
de Ingeniería de Sistemas
ISO / IEC 26702 define las tareas

interdisciplinares que se requieren a lo largo del
ciclo de vida de un sistema para transformar las
necesidades del cliente, requisitos y restricciones
en una solución de sistema. En adi- ción, que
especifica los requisitos para el proceso de
ingeniería de sistemas y su aplicación pasantes a
cabo el ciclo de vida del producto. ISO / IEC
26702: 2007 se centra en las actividades de
ingeniería necesarias para guiar el desarrollo de
productos, garantizando al mismo tiempo
Apéndice B B-19
que el producto está correctamente diseñado A VSE podría obtener una ISO / IEC 29110
para que sea asequible para producir, poseer, certifica- ción. El conjunto de informes técnicos
operar, mantener y eventualmente gastar sin está disponible sin costo alguno en el sitio web
riesgos indebidos para la salud o el medio de la ISO. Muchos ISO 29110 documentos están
ambiente. disponibles en Inglés, Español, tugueses Por-,
japonés y francés.
Desde SC 7 e IEEE han escrito hasta muchos

normas de proceso, uno puede que no se ISO / IEC TR 29110-5-1-2: Perfiles 2011
sorprenda al saber que su modelo para la Ingeniería de Software-ciclo de vida de entidades
descripción del proceso se registra en un informe muy pequeñas (MPE) -Parte 5-1-2: Gestión y Guía
técnico. de Ingeniería: Perfil genérico Grupo: todos los
datos generales
IEEE Std. 24774-2012 Guía de implantación de la ISO / IEC TR 29110-5-1-2: 2011 es aplicable a
norma ISO / IEC TR 24474: 2010 Sistemas y entidades muy pequeñas (MPE). Un VSE se
ingeniería de software-Life Cycle Management- define como una empresa, organización,
Directrices para Pro- ceso Descripción departamento, o proyecto que tiene hasta 25
personas. Un conjunto de normas y guías se ha
Un número cada vez mayor de, y las normas desarrollado de acuerdo con un conjunto de
internacionales, nacionales industria de procesos características y necesidades MPE. Las guías se
modelos describa. Estos modelos son basan en subconjuntos de estándares apropiados
desarrollados para una serie de propósitos, elementos, conocidos como perfiles VSE. El
incluyendo la implementación de procesos y propósito de un perfil VSE es definir un
evaluación. Los términos y las descripciones subconjunto de las normas internacionales ISO /
utilizadas en tales modelos varían en formato, IEC pertinentes al contexto las empresas muy
contenido y nivel de prescripción. ISO / IEC TR pequeñas.
24774: 2010 PRESION ents directrices para los ISO / IEC TR 29110-5-1-2: 2011 proporciona
elementos utilizados más frecuentemente en la la guía de gestión e ingeniería para el perfil VSE
descripción de un proceso: el título, PUR pose, base aplicable a empresas muy pequeñas que no
resultados, actividades, tareas y elemento de desarrollan software crítico. El grupo de perfil
información. Mientras que el propósito primario genérico no implica ningún dominio de
de ISO / IEC TR 24774: 2010 es fomentar la aplicación específica.
coherencia en modelos de referencia proceso
Dard Standards, las directrices que proporciona
se pueden aplicar a cualquier modelo de proceso El siguiente estándar puede ser visto como una
desarrollado para cualquier propósito. alternativa a 12207 para proyectos individuales.
La norma de 1074, explica cómo definir los
procesos para su uso en un proyecto
Una muy pequeña entidad (VSE) es una determinado. Las normas 12207 y 15288, sin
empresa, una organización, un departamento o embargo, se centran en la definición de procesos
un proyecto que tiene hasta 25 personas. La serie para la adopción de la organización y el uso
29110 ISO / IEC “pro” archivos grandes, tales repetido en muchos proyectos. La corriente 1074
como las normas ISO / IEC 12207 para el es la actualización de una norma que fue un
software y la norma ISO / IEC 15288 para precursor de 12207.
sistemas, en otras más pequeñas para las MPE.
ISO 29110 es aplicable a
VSE que no desarrollan sistemas críticos o criti-
software de cal. Perfiles proporcionan una hoja ISO / IEC 29110 serie de normas e informes
de ruta que permite una puesta en marcha a técnicos son el blanco de la audiencia tales como
crecer un paso a la vez usando las guías de las microempresas, los clientes o los auditores.
gestión y de ingeniería ISO 29110. ISO / IEC 29110 no pretende excluir el uso de
SEGUNDO-20 Guíaciclos
diferentes de vida se acerca, como la IEEE Std. 1074-2006 estándar para desarrollar un
SWEBOK® V3.0
cascada, iterativo e incremental, evolutivo, o proceso del ciclo de vida del software del proyecto
ágil.
Esta norma proporciona un proceso para la
creación de un proceso del ciclo de vida del
proyecto de software (SPLCP). Está dirigida
principalmente a los del arquitecto proceso para
un proyecto de software determinado.
Apéndice B B-21
Todas las normas descritas hasta ahora en esta • es aplicable en todos los dominios de
sec- ción proporcionar una base para la aplicación
definición de procesos. Algunos usuarios están y tamaños de organización; y
interesados en la evaluación y la mejora de sus • mayprovideanobjectivebenchmark entre las
procesos después de la implementación. La serie organizaciones.
15504 prevé la evaluación del proceso; que
actualmente es de ser revisado y pasa a ser El conjunto mínimo de requisitos definidos en
330xx. la norma ISO / IEC 15504-2: 2003 asegura que la
evaluación
resultados son objetiva, imparcial, consistente,
repetibilidad
ISO / IEC 15504 [diez partes] Evaluación capaz, y representante de los procesos
Información Tech- gía-Proceso evaluados. Resultados de las evaluaciones de
proceso conformes pueden compararse cuando
ISO / IEC 15504-2: 2003 define los requisitos se consideran los alcances de las evaluaciones a
para realizar la evaluación de proceso como base ser similares; para obtener orientación sobre este
para su uso en la mejora de procesos y la tema, consulte la norma ISO / IEC 15504-4.
determinación de la capacidad.
evaluación de proceso se basa en un modelo
sional de dos dimen- que contiene una Se mencionan varias otras normas aquí porque
dimensión de proceso y una dimensión de están escritos como elaboraciones de los
capacidad. La dimensión proceso es procesos de 12207 o 15288. Están asignados a
proporcionado por un modelo de referencia de otras KAs debido a que cada uno se ocupa de
proceso externo (tal como 12.207 o 15.288), que temas descritos en los otros KAs.
define un conjunto de procesos que se
caracteriza por los estados de proceso
propósito y el proceso resultados. loscapacidad
dimensión consiste en un marco de medición capacidad;
que comprende seis niveles de capacidad del • tiene en cuenta el contexto en el que la
proceso y sus atributos de proceso asociados. proceso evaluado se implementa;
La salida de evaluación consta de un conjunto • produce una calificación de proceso;
de puntuaciones de atributos proceso para cada • aborda la capacidad del proceso para lograr
proceso evaluado, denominado el perfil de su propósito;
proceso, y también puede incluir el nivel de
capacidad alcanzado por ese proceso.
ISO / IEC 15504-2: 2003 define el marco
medi- ción de la capacidad del proceso y los
requisitos para
• realizar una evaluación;

• modelos de referencia proceso;
• modelos de evaluación de proceso;
• la verificación de la conformidad de la
evaluación del proceso.
Los requisitos para la evaluación de procesos

definidos en la norma ISO / IEC 15504-2: 2003
forman una estructura que
• facilita la autoevaluación;
• proporciona una base para uso en el proceso
de mejora ment y determinación de la
SEGUNDO-22 Guía estándar para la configuración
IEEE Std. 828-2012
SWEBOK® V3.0
Gestión de Sistemas e Ingeniería de Software
Consulte Gestión de la Configuración de
Software KA

ISO / IEC 14764: 2006)
Estándar de Ciclo de Vida del Software
Ingeniería de Software-Procesos-Mantenimiento
Ver Mantenimiento de
Software KA
ISO / IEC 15026-4: 2012 Sistemas y Software

Inge- niería-Sistemas y de Software Assurance-
Parte 4: Control de calidad en el ciclo de vida
Ver la calidad del
software KA
IEEE Std. 15939-2008 La adopción del estándar

ISO / IEC 15939: 2007 Sistemas y Procesos
ingeniería de software-Medición
Consulte Software Engineering
Management KA
ISO / IEC 15940: 2006-Tecnologías de la

Información Ingeniería de Software
Environment Services
Ver Modelos de Ingeniería de
Software y
métodos KA

ISO / IEC 16085: 2006)
Estándar para los sistemas y el software
Ingeniería- vida del software de Procesos-Riesgos
ciclo de gestión
Consulte Software Engineering
Management KA
Apéndice B B-23
ISO / IEC / IEEE 16326: 2009 Sistemas y Cesión ejemplo. Ni tampoco S2ESC SC 7 tiene un
de Software Ingeniería de Procesos-Life-Cycle estándar para el desarrollo ágil, pero no existe un
Gestión de Proyectos estándar para el desarrollo de documentación de
Consulte Software Engineering usuario en un proyecto ágil.
Management KA
ISO / IEC / IEEE 29148: 2011 Sistemas y Software

Ingeniería-Life Cycle procesos de Ingeniería de ISO / IEC / IEEE 26515: 2012 Sistemas y de
Requisitos Ingeniería de Software-El desarrollo de
Consulte Requisitos de software documentación del usuario en un entorno ágil
KA
ISO / IEC / IEEE 26515: 2012 especifica la
manera en que la documentación del usuario se
Algunos usuarios desean estándares de puede desarrollar en los proyectos de desarrollo
procesos que pueden utilizarse para operaciones ágil. Está diseñado para su uso en todas las
de TI o la gestión de servicios de TI. La serie organizaciones que están utilizando desarrollo
ISO / IEC 20000 describen la gestión de ágil o están considerando la implementación de
servicios. Los procesos se definen con menos sus proyectos utilizando estas técnicas. Se
rigor que los de las normas antes mencionadas aplica a las personas u organizaciones que
inge- niería, pero pueden ser preferibles para producen suites de documentación, a los que
situaciones donde los riesgos de fracaso realizan un único proyecto de documentación, y
implican dinero o la satisfacción del cliente en la documentación producida internamente, así
lugar de la salud pública, la seguridad y el como a la documentación contratada para las
bienestar. La serie ISO / IEC 20000 se extienden organizaciones de servicios externos. ISO / IEC /
ahora a muchas partes. El fundamento de la IEEE 26515: 2012 se refiere a la relación entre
serie, ISO / IEC 20000-1, se describe el proceso de documentación del usuario y el
brevemente a continuación. proceso de documentación del ciclo de vida de
desarrollo ágil. Eso
describe cómo el desarrollador de información o
proyec-
ISO / IEC 20000-1: 2011 Tecnología de gerente ect puede planificar y gestionar el
Información de Gestión de Servicio-Parte 1: desarrollo de usuario docu- mentación en un
Requisitos del Sistema de Gestión de Servicios entorno ágil. Se pretende ni para alentar ni a
desanimar el uso de cualquier herramienta de
ISO / IEC 20000-1: 2011 es un sistema de desarrollo ágil particulares o métodos.
gestión de servicios (SMS) estándar. Especifica
los requisitos para el proveedor de servicios para
planificar, establecer, implement, operar, Muchas metodologías se basan en
supervisar, revisar, mantener y mejorar un SMS. descripciones semiformales del software que se
Los requisitos incluyen el diseño, la transición, construirá. Estos van desde notaciones
la entrega y la mejora de los servicios para descriptivas simples a los modelos que pueden
satisfacer los requisitos de servicio acordados. ser manipulados y probados y, en algunos casos,
puede generar código. Dos técnicas antiguas
relativamente comienzan la lista; la primera ha
IEEE ha adoptado las dos primeras partes de sido ampliamente aplicado para el modelado de
la serie ISO / IEC 20000. procesos y flujos de trabajo.
SOFTWARE INGENIERIA MODELOS

Y MÉTODOS específicos. “Jefe programador” era uno ejemplo
tradicionales. “El desarrollo ágil” (en realidad un
Algunos enfoques de métodos de ingeniería de ejemplo de entrega incrementales tradicional) es
software de uso que abarcan gran parte de su una corriente
ciclo de vida, en lugar de centrarse en procesos
SEGUNDO-24 Guía 1320,1-1998
IEEE Std. estándar para Mod-
SWEBOK® V3.0
funcional eling Idioma-sintaxis y la semántica de
IDEF0
modelado IDEF0 función está diseñada para

representan las decisiones, acciones y
actividades de una organización o sistema
existente o potencial. IDEF0 gráficos y textos
que acompañan están pre-tantes de una manera
organizada y sistemática para ganar
Apéndice B B-25
comprensión, el análisis de apoyo, proporcionan Las siguientes dos normas proporcionan dos
la lógica de los cambios potenciales, especificar versiones de
necesidades, y el diseño de apoyo a nivel de el lenguaje UML.
sistema y activi- integración
corbatas. IDEF0 se puede usar para modelar una ampliavariedad
de sistemas, compuestos por personas, ISO / IEC 19501: 2005 Información Tecnología
máquinas, materiales, las computadoras y la distribuido abierto Modeling Language (UML)
información de todas las variedades, y Versión 1.4.2 Procesamiento-Unificado
estructuradas por las relaciones entre ellos, tanto
automatizados y no automatizados. Para los ISO / IEC 19501 describe el Modelo- Unificado
nuevos sistemas, IDEF0 puede ser utilizado ing Language (UML), un lenguaje gráfico para
por primera vez para definir los requisitos y visualizar, especificar, construir y documentando
especificar las funciones a realizar por el sistema los artefactos de un sistema intensivos en
futuro. Como base de esta arquitectura, IDEF0 software. El UML ofrece una forma estándar
continuación, se puede utilizar para diseñar una para escribir planos de un sistema, incluyendo
aplicación que cumple con estos requisitos y cosas conceptuales tales como procesos de
realiza estas funciones. Para sistemas negocio y funciones del sistema, así como las
existentes, IDEF0 se puede utilizar para analizar cosas concretas, tales como instrucciones de
las funciones que el sistema funciona y para lenguaje de programación, esquemas de bases de
grabar los medios por los cuales estos se datos y componentes de software capaces Reus-.
realizan.
ISO / IEC 19505: 2012 [dos partes] Grupo de
IEEE Std. 1320,2-1998 estándar para Modelado Gestión de la Información Tech- nology-Objeto
Conceptual Idioma-sintaxis y la semántica de Unificado Modelo- ing Language (UML del OMG)
IDEF1X97 (IDEFobject)
ISO / IEC 19505 define el Unified Modeling
IDEF1X 97 consta de dos lenguajes de Language (UML), revisión 2. El objetivo de
modelado conceptual. El lenguaje de estilo clave UML es proporcionar arquitectos de sistemas,
soporta el modelado de datos / información y es ingenieros de software y desarrolladores de
a la baja COMPATIBLES con el estándar del software con herramientas para el análisis,
gobierno de Estados Unidos 1993, FIPS PUB diseño e implementación de sistemas basados en
184. El lenguaje de estilo identidad se basa en el software, así como para modelado de negocios y
modelo de objetos con las reglas y restricciones procesos similares.
declarativas. IDEF1X 97 estilo identidad incluye
construcciones para los componentes distintos
pero relacionados de abstracción objeto: Dos estándares más construyen sobre la base
interfaz, solicitudes y realización; utiliza de UML para proporcionar capacidades de
gráficos para indicar la interfaz; y define un modelado adicionales:
lenguaje de reglas y la restricción declarativa,
directamente ejecutable para solicitudes y
realiza- ciones. IDEF1X 97 soportes de
modelado conceptual
aplicación por bases de datos relacionales, extendido
bases de datos relacionales, bases de datos de metamodelo de IDEF1X 97 para definir el

objetos y lenguajes de programación de objetos. conjunto válido de IDEF1X 97 modelos.
IDEF1X 97 se define formalmente en términos
de la lógica de primer orden. Un procedimiento
se da por el que cualquier válido modelo En los últimos años, la notación UML se ha
IDEF1X 97 puede ser transformada en una convertido en popular para el modelado de
teoría equivalente en la lógica de primer orden. sistemas intensivos en software.
Este procedimiento se aplica entonces a un
SEGUNDO-26
ISO / IEC Guía
19506: 2012 Tecnología de
SWEBOK® V3.0
Información Objeto-Driven Architecture Group
Gestión de la Modernización (ADM) -
Conocimiento Descubrimiento Meta-Modelo
(KDM)
ISO / IEC 19506: 2012 define un metamodelo

para repre- resentir activos de software
existentes, sus las asociaciones y entornos
operativos, conocido como el metamodelo
descubrimiento de conocimiento (KDM). Este
es el primero de la serie de especificaciones
relacionadas con la garantía de software
(SWA) y las actividades de modernización
(ADM), la arquitectura de motor. KDM facilita
Apéndice B B-27
proyectos que involucran sistemas de software Dentro de los sistemas e ingeniería de software,
existentes asegurando la interoperabilidad y el ingeniería computadora asistido por software
intercambio de datos entre las herramientas (CASE) representan una parte importante de las
proporcionadas por diferentes proveedores. tecnolo- gías de apoyo utilizados para desarrollar
y mantener sistemas de tecnología de informa-
ISO / IEC 19507: 2012 Tecnología de Información ción. Su selección debe llevarse a cabo con una
Object Management Group Object Constraint cuidadosa consideración de tanto los requisitos
LANGUAGE (OCL) técnicos y de gestión.
ISO / IEC 14102: 2008 define tanto un
ISO / IEC 19507: 2012 define el objeto Con- conjunto de cesos pro y un conjunto estructurado
Idioma straint (OCL), versión 2.3.1. OCL de herramienta del caso de carac- terísticas para
versión 2.3.1 es la versión de OCL que está su uso en la evaluación técnica y la selección
alineado con UML 2.3 y 2.0 MOF. final de una herramienta CASE. De ello se sigue
el modelo de evaluación de productos de
software se define en la norma ISO / IEC 14598-
Algunas organizaciones invierten en entornos 5: 1998.
de software niería niería (SEE) para ayudar en la ISO / IEC 14102: 2008 adopta el modelo
construcción de software. Un SEE, per se, no es general de las características de calidad de
un sustituto de los procesos de sonido. Sin producto de software y subcaracterísticas
embargo, un VER adecuada debe ser compatible definidas en la norma ISO / IEC 9126- 1: 2001 y
con los procesos que han sido elegidos por la se extiende estos cuando el producto de software
organización. es una herramienta CASE; que proporciona
carac- terísticas de productos únicos para
herramientas CASE.
herramienta para su uso en la evaluación técnica y

ISO / IEC 15940: 2006-Tecnologías de la la selección final de una herramienta CASE.
Información Ingeniería de Software Environment
Services
ISO / IEC 15940: 2006 define el entorno de

ingeniería de software (SEE) servicios
conceptualmente en un modelo de referencia
que se puede adaptar a cualquier EES a
automática- compañero de una o más
actividades de ingeniería de software. En él se
describen los servicios que apoyan las defini-
ciones de proceso como en la norma ISO / IEC
12207 para que el conjunto de los servicios SEE
es compatible con la norma ISO / IEC 12207.
ISO / IEC 15940: 2006 se puede utilizar ya sea
como referencia general o para definir un
proceso de software automatizado.
La selección de herramientas para un entorno

de ingeniería de software es en sí una tarea
difícil. Dos estándares proporcionan algún tipo
de asistencia. ISO / IEC 14102: 2008 define
tanto un conjunto de procesos y un conjunto
estructurado de la ingeniería de software asistida
por computadora (CASE) características de la
SEGUNDO-28 Guía Proporciona una guía para establecer cesos y
ElV3.0
SWEBOK® siguientedocumento es una guía sobre
cómo adoptar herramientas CASE, una vez actividades que se van a aplicar para la adopción
seleccionado. exitosa de la tecnología CASE pro. El uso de la
norma ISO / IEC TR 14471: 2007 ayudará a
IEEE Std. 14471-2010 Guía de implantación de la maximizar el rendimiento y minimizar el riesgo

norma ISO / IEC TR 14471: 2007 Tecnología de de invertir en la tecnología CASE. Sin embargo,
la Información-Ingeniería de Software- la norma ISO / IEC TR 14471: 2007 no
Directrices para la adopción de las herramientas establece criterios El cumplimiento.
CASE Se utiliza mejor en combinación con la norma
ISO / IEC 14102 para la evaluación herramienta
El propósito de la norma ISO / IEC TR 14471: CASE y selección. Que ni dictados ni defensores
2007 es proporcionar una práctica particular, las normas de desarrollo, los
recomendada para la adop- ción CASO. procesos de software, diseño de met-
ods, metodologías, técnicas, programación
IEEE Std. 14102-2010 La adopción del estándar idiomas, o paradigmas del ciclo de vida.
ISO / IEC 14102: 2008 línea de Tecnología de la
Información-Guía-para la evaluación y selección
de herramientas CASE
Apéndice B B-29
Dentro de un entorno de ingeniería de para la aplicación de la norma ISO 9001: 2000 para
software, es importante para las diversas Programas informáticos
herramientas para interoperar. Las siguientes
normas proporcionan un esquema para la ISO / IEC 90003 proporciona una guía para
interconexión. organizaciones en la aplicación de la norma
ISO 9001: 2000 para la
adquisición, suministro, desarrollo, operación, y
IEEE Std. 1.175,1-2002 Guía para la caja de
herramienta Inter-
conexiones de Clasificación y Descripción
IEEE Std. 1175,2-2.006 Práctica Recomendada

para la caja de herramienta de interconexión-
Caracterización de las interconexiones
IEEE Std. 1.175,3-2004 estándar para la caja de

herramienta Interconexiones-modelo de referencia
para especificar el comportamiento del software
IEEE Std. 1175,4-2008 estándar para la caja de

herramienta Interconexiones-Modelo de
Referencia para su comportamiento Especificación
El propósito de esta familia de normas es espec-

ify un conjunto común de conceptos de
modelado en base a los encontrados en las
herramientas CASE comerciales para describir
el comportamiento operacional de un sistema de
software. Estas normas establecen un uniforme,
modelo integrado de conceptos de software
relacionados con la funcionalidad del software.
También proporcionan una sintaxis tual Tex
para expresar las propiedades comunes
(atributos y relaciones) de esos conceptos, ya
que se han utilizado para modelar el
comportamiento del software.
La calidad del software
Un punto de vista de la calidad del software se

inicia con la norma ISO 9001, Requisitos de
Gestión de Calidad, que trata de la política de
calidad a lo largo de una organiza- ción. La
terminología de la norma que pueden ser
desconocidos para los profesionales de software,
y los auditores de gestión de la calidad puede no
estar familiarizados con la jerga de software. La
siguiente norma describe la relación entre la ISO
9001 y la ISO / IEC 12207. Por desgracia, la
ver- sión actual se refiere a las ediciones
obsoletas de ambos; ción una sustitución en
curso:
SEGUNDO-30
mantenimientoGuía
de software y servicios de mencionadas; otros pueden especializarse en un
SWEBOK® V3.0
apoyo relacionados. ISO / IEC 90003: 2004 no área. Sea cual sea la situación, el sistema de
se suma a cambiar o no los requisitos de la gestión de calidad de la organiza- ción debe
norma ISO 9001: 2000. cubrir todos los aspectos (relacionados con el
Las directrices establecidas en la norma ISO software y nonsoftware relacionado) de la
/ IEC 90003: 2004 no están destinados a ser empresa.
utilizados como criterios de As- sessment en la ISO / IEC 90003: 2004 identifica las
gestión de la calidad del sistema de registro / cuestiones que deben abordarse y es
certificación. independiente de la tecnología de procesos,
La aplicación de la norma ISO / IEC 90003: modelos de ciclo de vida, Desa- Ment, secuencia
2004 es de actividades y estructura organizativa utilizada
apropiado para el software que es por una organiza- ción. orientaciones adicionales
y referencias frecuente a las normas de
• parte de un contrato comercial con otra ingeniería de software 7 1 / SC ISO / IEC JTC se
organización, proporcionan para ayudar en la aplicación de la
• un producto disponible para un sector del norma ISO 9001: 2000: en particular, ISO /
mercado, IEC 12207, ISO / IEC TR 9126, ISO / IEC
• utilizado para apoyar los procesos de una 14598, ISO / IEC 15939 e ISO / IEC TR 15504.
organización,
• incrustado en un producto de hardware, o
• en relación con los servicios de software. El enfoque de la ISO 9001 postula un proceso
de gestión de la calidad organiza- ción de nivel
Algunas organizaciones pueden estar emparejado
involucrados en todas las actividades
con la garantía de calidad a nivel de proyecto
planificación
IEEE Std. 90003-2008 Guía de implantación de la para alcanzar los objetivos de la organización.
norma ISO / IEC 90003: 2004 Ingeniería de IEEE 730 describe la planificación de la calidad
Software-Directrices a nivel de proyecto. Es
Apéndice B B-31
Actualmente alineado con una edición obsoleta cuadrados ofrece

de
12207, pero se está preparando una revisión. • Términos y definiciones,
• modelos de referencia,
• guías
IEEE Std. 730-2002 estándar para los planes de • normas para los requisitos de la
garantía de calidad de software especificación con fines de evaluación,
planificación y gestión, medición y.
El estándar especifica el formato y el contenido
de
software planes de aseguramiento de la
calidad.
El próximo estándar cuadrados proporciona

Otro punto de vista de la calidad del software una Omy taxón de las características de calidad
comienza con la enumeración de las de software que puede ser útil en la selección de
características deseadas de un producto de características relevantes para un proyecto
software y la selección de las medidas u otras específico:
evaluaciones para determinar si el nivel deseado
de
se ha logrado características. los así llamado
Serie cuadrada (requisitos de calidad del contiene una explicación del proceso de tran-
producto y la evaluación del software) de las sición entre la antigua norma ISO / IEC 9126 y la
normas SC 7 cubre este enfoque en gran detalle. serie 14598 y cuadrados, y también presenta
información sobre el uso de la serie ISO / IEC
9126 y 14598 en su forma anterior.
ISO / IEC 25000 25099 a través del software
Engineer--ing de software Requisitos de calidad
del producto y Evaluación (cuadrados)
Algunos de los estándares cuadrados se

seleccionan a continuación para una atención
particular. La primera es la guía general para la
serie.
ISO / IEC 25000: 2005 Software de ingeniería y

software Requisitos de calidad del producto y
Evaluación (cuadrados) -Guía de cuadrar
ISO / IEC 25000: 2005 proporciona orientación

para el uso de la nueva serie de normas
internacionales nombrados software Requisitos
de calidad del producto y Evaluación
(cuadrados). El propósito de esta guía es
proporcionar una visión general de los
contenidos cuadrados, modelos de referencia
comunes, y definiciones, así como la relación
entre los documentos, permitiendo a los
usuarios de esta guía una buena comprensión de
las normas internacionales. Este documento
SEGUNDO-32 Guía 25010: 2011 Sistemas y Software
ISO / IEC
SWEBOK® V3.0
Engineers niería-Sistemas y Calidad de Software
REQUISITOS DE y Evaluación (cuadrados) -
Sistema y modelos de calidad del software
ISO / IEC 25010: 2011 define lo siguiente:
1. A la calidad del modelo en uso compuesto

de cinco características (algunas de las
cuales se subdividen en subcaracterísticas)
que se relacionan con el resultado de la
interacción cuando un producto se utiliza
en un contexto particular de uso. Este
modelo de sistema es aplicable al sistema
hombre-máquina completa, incluyendo
tanto los sistemas informáticos en uso y
productos de software en uso.
2. Un modelo de la calidad del producto
compone de ocho características (que se
subdividen en subcaracterísticas) que se
relacionan con propiedades estáticas de
software y las propiedades dinámicas del
sistema informático. El modelo es
aplicable tanto a los sistemas informáticos
y productos de software.
Las características definidas por ambos

modelos son relevantes para todos los
productos de software y sistemas de orde-
nador. Las características y carac- subchar-
proporcionan terminología coherente para
especificar, medir y sistema y la calidad del
producto software de evaluación. También
proporcionan un conjunto de características de
calidad contra el que declararon los requisitos
de calidad se pueden comparar para la
integridad.
Apéndice B B-33
Aunque el alcance del modelo de calidad del Evaluación del formato (cuadrados) Industria -
producto está destinado a ser software y sistemas Common (CIF) de la Usabilidad
informáticos, muchas de las características
también son Evant rel a los sistemas y servicios Una familia de estándares internacionales,
más amplios. designados con la industria de formatos comunes
ISO / IEC 25012 contiene un modelo para (CIF), documenta la especificación y evaluación
cali- datos de la usabilidad de los sistemas interactivos.
dad que es complementaria a este modelo. Proporciona una visión general general del
El alcance de los modelos excluye marco CIF y contenidos, definiciones, y la
propiedades puramente funcionales, pero incluye relación de mentos el marco ele-. Los usuarios
idoneidad funcional. previstos del marco se identifican, así como las
El ámbito de aplicación de los modelos de situaciones en las que el marco se puede aplicar.
calidad incluye el apoyo a la especificación y Los supuestos y las limitaciones del marco
evaluación de software y de software intensivo también se enumeran. El contenido de marco
Systematic informáticos TEMS desde diferentes incluye lo siguiente:
perspectivas por aquellos que están asociados
con su adquisición, requisitos, desarrollo, uso, • terminología coherente y clasificación de
evaluación, apoyo, mantenimiento, la calidad especificación, evaluación y presentación de
aseguramiento y control y auditoría. Los informes;
modelos pueden ser, por ejemplo, ser usado para • una definición del tipo y alcance de los
operadores desa-, adquirentes, garantía de formatos y la estructura de alto nivel que se
calidad y personal de control, y los evaluadores utilizará para documentar la información
independientes, en particular los responsables de requerida y los resultados de la evaluación.
especificar y evaluar la calidad del producto de
software. Las actividades durante el desarrollo La familia de normas CIF es aplicable a los
de producto que pueden beneficiarse de la productos de software y hardware utilizados para
utilización de los modelos de calidad incluyen la pre- tareas definidas. Los elementos de
información están destinadas a ser utilizado
• la identificación de los requisitos de como parte de la documentación de nivel de
software y del sistema; sistema resultante de los procesos de desarrollo
• la validación de la amplitud de una tales como los que en la norma ISO 9241 a 210
definición de requisitos; y ISO / IEC JTC 1 / SC estándares 7 de proceso.
• la identificación de software y sistema de La familia CIF centra en documentar aquellos
diseño elementos necesarios para el diseño y desarrollo
objetivos; de sistemas utilizables, en lugar de prescribir un
• la identificación de software y sistema de proceso específico. Está destinado a ser utilizado
prueba en conjunción con las normas internacionales
objetivos; existentes, INCLUYENDO ISO 9241, ISO
• la identificación de los criterios de control 20282, ISO / IEC 9126, y
de calidad como parte de la serie cuadrada (ISO / IEC 25000 a ISO / IEC
seguro de calidad; 25099).
• la identificación de los criterios de La familia de normas CIF no prescribe
aceptación para un producto de software y / cualquier tipo de método, ciclo de vida o
o el sistema informático de software proceso.
intensivo;
• el establecimiento de medidas de calidad
tics carac- en apoyo de estas actividades.
algunos documentos en la serie de cuadrados y Tecnología (NIST) de Estados Unidos y se

acuerdo específica- mente con la característica trasladó a la norma ISO / IEC JTC 1 / SC 7 para
de facilidad de uso. El formato de la Industria fines de estandarización.
común (CIF) para ING usabilidad informe-
comenzó en el Instituto Nacional de Estándares
SEGUNDO-34 Guía subfactores de la madurez, disponibilidad,
SWEBOK® V3.0
No todo el mundo está de acuerdo con la tolerancia a fallos, y capacidad de recuperación.
taxonomía de las características de calidad en IEC TC 65, que es responsable de las normas
la norma ISO / IEC 25010. La norma tiene un sobre “dependabil-
factor de calidad llamado “fiabilidad” que tiene
dad” define ese término como com- no
cuantitativo
ISO / IEC 25060 25064 a través del software Posite de fiabilidad, facilidad de mantenimiento y
Engineer--ing de software Requisitos de calidad soporte de mantenimiento. Otros utilizan el
del producto y la término “fiabilidad”
Apéndice B B-35
para denotar una medida definida por una Un enfoque para el logro de la calidad del
ecuación matemática. El desacuerdo sobre el uso software es llevar a cabo un amplio programa de
de estas palabras significa que las normas sobre verificación y validación. IEEE Std. 1012 es
la materia son inherentemente no alineado. Unos probablemente estándar más ampliamente
pocos se verá más adelante, pero las palabras aplicada del mundo en esta sub-Ject. Una
como los mencionados más arriba pueden tener revisión se publicó recientemente.
diferentes significados en diferentes estándares.
IEEE Std. 1012-2012 estándar para el sistema y

Soft-
IEEE Std. 982,1-2.005 estándar para Diccionario Artículos de Verificación y Validación
de Medidas de los aspectos del software de
Fiabilidad Verificación y validación procesos (V & V) se
utilizan para determinar si el desarrollo Pro-
Un diccionario estándar de las medidas de los ductos de una actividad dada ajustarse a las
aspectos del software de fiabilidad para evaluar exigencias de que la actividad y si el producto
y predecir la fiabilidad, facilidad de cumple su uso previsto y las necesidades del
mantenimiento, y la disponibilidad de cualquier usuario. requisitos del proceso de ciclo de vida
sistema de software; en particular, se aplica a los de V & V se especifican para niveles de
sistemas de software de misión crítica. integridad de diferentes. El alcance de los
procesos de V & V abarca sistemas, software y
IEEE Std. 1633-2008 Práctica Recomendada para hardware, e incluye sus interfaces. Esta norma se
la fiabilidad del software aplica a los sistemas, el software y el hardware
se está desarrollando, mantenida o reutilizados
Los métodos para evaluar y predecir su [legacy, comercial plataforma frente-el-(COTS),
confiabilidad de software, basado en un enfoque artículos nondevelopmental]. El término
de ciclo de vida para la ingeniería de la software también incluye el firmware y el
fiabilidad del software, se prescriben en esta microcódigo, y cada uno de los términos del
práctica recomendada. Se proporciona la sistema, software y hardware incluye
información necesaria para la aplicación de la documentación. procesos de V & V incluyen el
fiabilidad del software de medición (SR) a un análisis, evaluación, revisión, inspec- ción,
proyecto, establece una base para la evaluación, y el ensayo de los productos.
construcción de métodos consistentes, y
establece el principio básico para la recogida de
los datos necesarios para evaluar y predecir la Hay otras normas que apoyan los procesos
fiabilidad del software. La práctica recomendada ficación y validación veri. Uno describe las
prescribe cómo cualquier usuario puede técnicas para llevar a cabo revisiones y
participar en las evaluaciones y predicciones SR. auditorías durante un proyecto de software.
IEEE tiene un estándar global para el software

la calidad del producto que tiene un alcance similar al el
serie 250xx ISO / IEC descrito anteriormente. IEEE Std. 1028-2008 estándar para las revisiones
Su terminología difiere de la serie ISO / IEC, de software y auditorías
pero es sustancialmente más compacto.
Cinco tipos de revisiones de software y
auditorías,
junto con los procedimientos necesarios para la
ejecu-
IEEE Std. 1061-1998 Estándar de Calidad de se define una metodología para establecer los
Software Metodología Métrica requisitos de calidad y definición, ejecución,
análisis y validación de las métricas de calidad de
SEGUNDO-36
procesoGuía
y de producto de software. La ción de cada tipo, se definen en esta norma. Esta
SWEBOK® V3.0
metodología abarca todo el ciclo de vida del norma se refiere únicamente a las revisiones y
software. auditorías; procedimientos para la determinación
de la sidad nece- de una revisión o auditoría no
están definidos, y la disposición de los
resultados de la revisión o auditoría no se
especifica. Tipos incluidos son revisiones de la
dirección, revisiones técnicas, inspecciones,
walk-through, y auditorías.
Apéndice B B-37
En muchos casos, una base de datos de utilizar de cada parte y el uso combinado de
software de anoma- reside se utiliza para apoyar múltiples partes. La cobertura de la garantía para
las actividades de verificación y validación. La un servicio que es operado y administrado de
siguiente norma sugiere cómo deben clasificarse forma continua no está cubierto en la norma ISO
anomalías. / IEC 15026.
IEEE Std. 1044-2009 norma para la clasificación La segunda parte de la norma describe la
de estructura de un “caso de aseguramiento”, que
Las anomalías de software pretende ser un argumento estructurado que la
propiedad crítica se ha logrado. Es una
Esta norma proporciona un enfoque uniforme generalización de diversos constructos
para la clasificación de las anomalías de específicos de dominio como “casos de
software, independientemente del momento en seguridad”.
que se originan o cuando se encuen-
cados dentro del proyecto, producto o sistema de vida
ciclo. Los datos de clasificación pueden ser IEEE Std. 15026,2-2.011 adopción del estándar
utilizados para una variedad de propósitos, ISO / IEC 15026-2: 2011 Sistemas y ingeniería de
incluyendo causal defecto análi- sis, gestión de software-Systems y Software Assurance-Parte 2:
proyectos, y la mejora de procesos de software Aseguramiento de la caja
(por ejemplo, para reducir la probabilidad de
inserción de defectos y / o aumentar la ISO / IEC 15026-2: 2011 es adoptada por esta
probabilidad de detección de defectos Dard Están-. ISO / IEC 15026-2: 2011 especifica
temprano). los requisitos mínimos para la estructura y
contenido de un caso de garantía para mejorar la
coherencia y la comparabilidad de los casos de
En algunos sistemas, una propiedad particular aseguramiento y para faci- comunicaciones tate
del software es tan importante que requiere un interesados, las decisiones de ingeniería y otros
tratamiento especial más allá de la usos de los casos de aseguramiento. Un caso de
proporcionada por un programa de verificación aseguramiento incluye un reclamo de primer
y validación convencional. El término nivel para una propiedad de un sistema o
emergente para este tipo de tratamiento es “siste- producto (o un conjunto de reclamaciones), la
mas de garantía de software.” Los ejemplos argumentación sistemática con respecto a esta
incluyen la seguridad, la privacidad, de alta reclamación, y la evidencia y supuestos
seguridad, y ultrareliability. La norma 15026 explícitos que subyacen a esta argumentación.
está en desarrollo para hacer frente a tales Discutiendo a través de múltiples niveles de las
situaciones. La primera parte del estándar de reivindicaciones subordinadas, esta
cuatro partes ofrece la terminología y los argumentación estructurado conecta la
conceptos utilizados en las partes restantes. Fue reclamación de nivel superior para las pruebas y
escrito antes de las otras partes y ahora está supuestos. casos de Aseguramiento
siendo revisada para el acuerdo completa con generalmente se desarrollaron para apoyar las
los otros. reivindicaciones en áreas tales como la
seguridad, la fiabilidad, maintain-
capacidad, factores humanos, operatividad y
seguridad,
IEEE Std. ción 15026,1-2.011 Trial-Uso estándar ISO / IEC TR 15026-1: 2010, que define los
adopción de la norma ISO / IEC TR 15026-1: 2010 términos y esta- lishes un conjunto amplio y
Sistemas y de Software Ingeniería de Software- organizado de los conceptos y sus relaciones para
Systems y aseguramiento de la-Parte 1: Conceptos el software y los sistemas de seguridad,
y Vocabulario estableciendo así una base para la comprensión
común de los conceptos y central principios de
Este estándar de prueba de uso adopta la norma la norma ISO / IEC 15026 a través de sus comu-
SEGUNDO-38 Guía
nidades de usuarios.Proporciona información a Aunque estos casos de garantía son a menudo
SWEBOK® V3.0
los usuarios de las partes subsecuentes de la llamados por los nombres más específicos, por
norma ISO / IEC 15026, incluyendo la ejemplo, el caso de seguridad o la fiabilidad de
dichas y mantenibilidad caso (R & M). ISO /
IEC 15026-2: 2011 no impone requisitos sobre
la calidad de los contenidos de un caso de
garantía y no requiere el uso de una terminología
particular o de representación gráfica. Así
mismo, no impone requisitos sobre los medios
de implementación física de los datos, incluidos
los requisitos para la redundancia o la
colocación.
En muchos sistemas, algunas porciones son

críticos para
el logro de la propiedad deseada, mientras que otros
sólo están
Apéndice B B-39
incidental. Por ejemplo, el sistema de control de TR 15026-1 proporciona información y

vuelo deun avión de pasajeros es fundamental referencias adicionales para ayudar a los usuarios
para la seguridad, pero el horno microondas no de la norma ISO / IEC 15026-3: 2011. ISO / IEC
lo es. Convencionalmente, las diversas partes se 15026-3: 2011 no requiere el uso de los casos de
asignan niveles de criticidad “” para indicar su aseguramiento descritos en la norma ISO / IEC
significación para el logro general de la 15026-2, pero describe cómo los niveles de
propiedad. La tercera parte de la ISO / IEC integridad y de garantía de los casos pueden
15026 describe cómo se hace. Esta parte será trabajar juntos, especialmente en la definición de
revisado para un mejor ajuste con el resto de la las especificaciones de los niveles de integridad o
norma 15026. mediante el uso de la integridad los niveles
dentro de una porción de una
caso de aseguramiento.
ISO / IEC 15026-3: niería-Sistemas y

Aseguramiento de la Parte 3-2011 Software de La parte final de 15026 proporciona
Sistemas y Software Engineers: Niveles de orientación adicional para la ejecución de los
Integridad del sistema procesos del ciclo de vida de 12207 y 15288
cuando se requiere un sistema o software para
ISO / IEC 15026-3: 2011 especifica el concepto conseguir una propiedad importante.
de
niveles de integridad con nivel de integridad
correspondiente
requisitos que se requieren para ser conocido en orden
para demostrar la consecución del nivel de ISO / IEC 15026-4: 2012 Sistemas y Software Inge-
integridad. Se coloca requisitos sobre y niería-Sistemas y de Software Assurance-Parte 4:
recomienda ods met para la definición y el uso Control de calidad en el ciclo de vida
de los niveles de integridad y de sus requisitos
de nivel de integridad, incluyendo la asignación Esta parte de la norma ISO / IEC 15026
de niveles de integridad a los sistemas, proporciona orientación y recomendaciones para
productos de artículos blandos, sus elementos, y la realización de procesos seleccionados,
dependencias externos pertinentes. actividades y tareas para los sistemas y
ISO / IEC 15026-3: 2011 es aplicable a los productos de software que requieren las
sistemas de software y está diseñada para uso reclamaciones de garantía de las propiedades
por: seleccionadas de una atención especial, llamadas
propiedades críticas. Esta parte de la norma ISO
• definidores de los niveles de integridad, / IEC 15026 especifica una lista erty
tales como organizaciones de la industria y independiente prop- de procesos, actividades y
profesionales, organizaciones de estándares tareas para lograr la reclamación y mostrar el
y agencias gubernamentales; logro de la reclamación. Esta parte de la norma
• usuarios de los niveles de integridad como ISO / IEC 15026 establece los procesos,
desarrolladores y mantenedores, actividades, tareas, orientación y
proveedores y compradores, usuarios y recomendaciones en el contexto de un modelo
asesores de sistemas o software, y para el de ciclo de vida definido y un conjunto de
puerto SUP- administrativa y técnica de procesos de ciclo de vida para el sistema y / o
sistemas y / o productos de software. gestión del ciclo de vida del software.
Un uso importante de los niveles de integridad

es mediante pinzas SUP- y adquirentes en los Los estándares siguientes se ocupa de una
acuerdos; por ejemplo, para ayudar a asegurar seguridad que a menudo se identifica como
las características de seguridad, económico, o de propiedad-crítico. Originalmente fue
seguridad de un sistema o producto entregado. desarrollado en cooperación con la industria de
ISO / IEC 15026-3: 2011 no prescribe una la energía nuclear de Estados Unidos.
SEGUNDO-40
conjuntoGuía
específico de niveles de integridad o su integridad
SWEBOK® V3.0
requisitos de nivel. Además, no se pre- escriba la IEEE Std. 1228-1994 estándar para los planes de
forma en que el uso nivel de integridad se inte- seguridad del software
rallado con el conjunto del sistema o software
inge- niería procesos del ciclo de vida. Se establecen los requisitos mínimos aceptables
ISO / IEC 15026-3: 2011 se puede utilizar para el contenido de un plan de seguridad de
solo o con otras partes de la norma ISO / IEC software. Esta norma se aplica al plan de
15026. Se puede utilizar con una variedad de seguridad de software utilizado para el
análisis de riesgos y desarrollo enfoques desarrollo, adquisición, mantenimiento y retirada
técnicos y especializados. ISO / IEC de software crítico.
Apéndice B B-41
Esta norma requiere que el plan se preparará en Conocimiento

el marco del programa de seguridad del (SWEBOK) ver general
sistema. Sólo se incluyen los aspectos de
seguridad del software. Esta norma no contiene
especial
disposiciones necesarias para el software Un estándar de 7 SC proporciona un marco
utilizado en los sistemas de distribuido o en para las comparaciones entre las certificaciones
procesadores paralelos. de profesionales de la ingeniería de software.
Que norma indica que las áreas consideradas en
la certificación debe estar correlacionado con la
tratamientos clásicos sugieren que la Guía SWEBOK.
“verificación”
trata de los métodos de evaluación estática y que
ofertas de “prueba” con la evaluación dinámica met-
ods. tratamientos recientes, incluyendo la norma ISO / IEC 24773: 2008 Ingeniería de Software-certi-
ISO / IEC 29119, proyecto están difuminando ficación de Profesionales de Ingeniería de Software
esta distinción, aunque, por lo que aquí se
mencionan las normas de ensayo. ISO / IEC 24773: 2008 establece un marco para
comparación de los esquemas de certificación
software
IEEE Std. 829-2008 estándar para el software y profesionales de la ingeniería. Un esquema de
Sys tem Documentación de la comprobación certificación es un conjunto de requisitos de
Consulte Software certificación para profesionales de la ingeniería
Testing KA de software. ISO / IEC 24773: 2008 especifica
los artículos que se requiere un esquema para
IEEE Std. 1008-1987 estándar para el software de contener e indica lo que debe ser definida para
pruebas unitarias cada elemento.
Consulte Software ISO / IEC 24773: 2008 facilitará la Porta-
Testing KA bilidad de ingeniería de software tifications cier-
profesionales entre los diferentes países o
IEEE Std. 26513-2010 La adopción del estándar organizaciones. En la actualidad, diferentes
ISO / IEC 26513: 2009 Sistemas y ingeniería de países y organizaciones han adoptado diferentes
software-Requisitos para Probadores y revisores enfoques sobre el tema, que se implementan por
de Documentación medio de reglamentos y estatutos. La intención
Consulte Software de la norma ISO / IEC 24773: 2008 es estar
Testing KA abierto a éstos individual y específico se acerca
al proporcionar un marco para expresarlos en un
/ / IEEE 29119 [cuatro partes] (Borrador) esquema común que puede conducir a la
Software ISO IEC y Sistemas de Pruebas de comprensión.
Consulte Software
Testing KA
INGENIERÍA DE SOFTWARE LA Conocimiento. La Guía SWEBOK ha sido

PRÁCTICA PROFESIONAL adoptado por la norma ISO / IEC como un
esquema de los conocimientos que los ingenieros
IEEE es un proveedor de productos relacionados de software profesionales deben tener.
con el CER tificación de los practicantes
profesionales de la ingeniería de software. La
primera ya se ha descrito, la Guía para la
SEGUNDO-42 Guía No hay normas se asignan a este KA.
SC 7 estáV3.0
SWEBOK® elaborando una guía que
suplementar 24773.
FUNDAMENTOS DE INFORMATICA
ECONOMÍA INGENIERÍA DE
SOFTWARE No hay normas se asignan a este KA.
MATEMÁTICO CIMIENTOS
ISO / IEC TR 19759: 2005 Software Engineer-
ing-Guía de los Fundamentos de Ingeniería de No hay normas se asignan a este KA.
Software
Apéndice B B-43
FUNDAMENTOS DE INGENIERÍA Las definiciones contenidas en la norma ISO /

IEC / IEEE 24765, Sistema y Software
No hay normas se asignan a este KA. Vocabulario, están libremente disponibles en
www.computer.org/sevocab.
ACTUAL STAYING Sin embargo, la gran mayoría de las normas
no son libres. normas ISO / IEC generalmente se
Este artículo era obsoleto el momento en que se compran desde el organismo nacional de
redactó. Algunos lectores necesitan saber cómo normalización del país en que se vive. Por
conseguir designaciones y descripciones de las ejemplo, en los EE.UU., las normas
normas vigentes. En esta sección se describen internacionales se pueden adquirir en el Instituto
algunos recursos útiles. Americano de Estándares Nacionales
enhttp://webstore.ansi.org/. Alternativamente,
DONDE ENCONTRAR NORMAS Standards se pueden comprar directamente de
ISO / IEC enwww.iso.org/iso/store.htm. Cabe
La lista de normas publicadas por ISO / IEC JTC señalar que cada nación es libre de fijar sus
1 / SC 7 se puede encontrar en propios precios, por lo que puede ser útil para
www.iso.org/iso/iso_ Catálogo / catalogue_tc / comprobar ambas fuentes. Los estándares IEEE
catalogue_tc_browse. htm? commid = 45086. pueden estar disponibles para usted de forma
Debido a que la URL puede cambiar, los gratuita si su empleador o la biblioteca tiene una
lectores podrían tener que desplazarse a la lista. suscripción a IEEE
comenzará a laswww.iso.org/ ISO / store.htm, A Xplore:http://ieeexplore.ieee.org/. Algunas
continuación, haga clic en “Catálogo de suscripciones a Xplore proporcionan acceso sólo
estándares de exploración”, luego “navegar por a los resúmenes de las normas; El texto
el TC,” y luego “JTC 1” y luego “SC 7.” completo puede entonces ser adquirido a través
Encontrar la lista actual de normas para de Xplore. Alternativamente, las normas pueden
S2ESC es un poco más difícil. comenzará a ser adquiridos a través de la tienda de los
lashttp: // estándares. ieee.org/. En el cuadro de estándares IEEE
búsqueda en “Buscar Standards,” tipo “S2ESC.” enwww.techstreet.com/ieeegate.html. Cabe
Esto debería producir una lista de normas señalar que la IEEE-SA veces haces normas
publicadas por el cual es responsable S2ESC. en grupos disponibles con un descuento
Tenga en cuenta que las bases de datos considerable.
accesibles son compilaciones. Al igual que Finalmente, el lector debe tener en cuenta que
cualquier base de datos, que pueden contener los estándares IEEE que ha adoptado de ISO /
errores que conducen a resultados de búsqueda IEC, las normas que la norma ISO / IEC tiene
incompletos. “vía rápida” de la IEEE, y las normas que se han
desarrollado o se revisan en conjunto están
DONDE OBTENER LAS NORMAS disponibles de ambas fuentes. Para todas las
normas descritas en este artículo, la versión
Algunos lectores querrán obtener normas IEEE y la versión ISO / IEC son sustancialmente
descritas en este artículo. Lo primero que debe idénticos. Las versiones respectivas pueden tener
saber es que algunas normas internacionales diferentes frontal y la materia de nuevo pero los
están disponibles gratuitamente para su uso cuerpos son idénticos.
individual. La lista actualizada de las normas
ISO / IEC disponible bajo los términos se DONDE VER LA GUÍA SWEBOK
encuentra enhttp://standards.iso.org/ittf/
PubliclyAvailableStandards / index.html. La Guía SWEBOK se publica bajo un derecho
Uno de los estándares disponibles de autor IEEE. La versión actual de la Guía
públicamente es la adopción de ISO / IEC Guía SWEBOK es gratuita para el público enwww.
del SWEBOK, ISO / IEC 19759. swebok.org/. La adopción de ISO / IEC Guía del
SWEBOK, ISO / IEC TR 19759, es una de las
normas de libre disposición.
SEGUNDO-44 Guía
SWEBOK® V3.0
RESUMEN lista de las normas
Número y Título (enumerados en orden de número) Más relevantes KA

IEEE Std. 730-2002 estándar para los planes de garantía de calidad de SW Calidad
software
IEEE Std. 828-2012 Norma para la Gestión de la Configuración de Gestión de la
Sistemas e Ingeniería de Software Configuración
IEEE Std. 829-2008 estándar para el software y la prueba del sistema SW
Prueba de SW
Documentación
IEEE Std. 982,1-2.005 estándar para Diccionario de Medidas de la
SW Calidad
Aspectos de software de Fiabilidad
IEEE Std. 1008-1987 estándar para el software de pruebas unitarias Prueba de SW
IEEE Std. 1012-2012 estándar para el sistema y verificación de software
SW Calidad
y
Validación
IEEE Std. 1016-2009 estándar para la Tecnología de la Información-
SW Diseño
Systems
Las
IEEEdescripciones de diseño
Std. 1028-2008 de para
estándar software de diseñode software y
las revisiones SW Calidad
auditorías
IEEE Std. 1044-2009 norma para la clasificación para el Software
SW Calidad
anomalías
IEEE Std. 1061-1998 Estándar de Calidad de Software
SW Calidad
Metodología Métrica
Ingeniería SW
IEEE Std. 1062-1998 Práctica Recomendada para la adquisición de
administración
software
IEEE Std. 1074-2006 estándar para desarrollar una vida de Proyectos de Proceso de Ingeniería
Software de SW
Proceso del1.175,1-2002
IEEE Std. ciclo Guía para el CASO Clasificación Ingeniería SW
Interconnections- herramienta y Descripción Modelos y Métodos
IEEE Std. 1175,2-2.006 Práctica Recomendada para la caja de Ingeniería SW
herramienta de interconexión-Caracterización de las interconexiones Modelos y Métodos
IEEE Std. 1.175,3-2004 estándar para la caja de herramienta Ingeniería SW
Interconnections- modelo de referencia para especificar el Modelos y Métodos
comportamiento del software
IEEE Std. 1.175,4 a 2.008 estándar para CASE Modelo de Referencia de Ingeniería SW
herramientas Interconnections- para su comportamiento Especificación Modelos y Métodos
IEEE Std. 1220-2005 (también conocido como ISO / IEC 26702: 2007) Proceso de Ingeniería
estándar para la aplicación y gestión del proceso de Ingeniería de de SW
Sistemas
IEEE Std. 1228-1994 estándar para los planes de seguridad del software SW Calidad
IEEE Std. 1320,1-1998 estándar para Modelado funcional Lenguaje- Ingeniería SW
sintaxis y la semántica de IDEF0 Modelos y Métodos
IEEE Std. 1320,2-1998 estándar para Modelado Conceptual Lenguaje- Ingeniería SW
sintaxis y la semántica de IDEF1X97 (IDEFobject) Modelos y Métodos
IEEE Std. 1490-2011 Guía de implantación de la Gestión de Proyectos
Ingeniería SW
Institute (PMI ®) estándar, una guía para la Dirección de Proyectos del
administración
Conocimiento (Guía del PMBOK®) -Cuarto Edición
IEEE Std. 1517-2010 estándar para la tecnología de la información del Proceso de Ingeniería
sistema y del software-Vida Procesos de reutilización de procesos de de SW
ciclo
Apéndice B B-45

IEEE Std. 1633-2008 Práctica Recomendada para la fiabilidad del SW Calidad
software
IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) Proceso de Ingeniería
estándar para de SW
Sistemas
IEEE Std.y14102-2010
de SoftwareLa
Ingeniería
adopcióndedel
Software-procesos de 14102:
estándar ISO / IEC ciclo de2008
vida
Ingeniería SW
Tecnología de la Información-Directrices para la evaluación y selección
Modelos y Métodos
de herramientas CASE
ISO / IEC 14143 [seis partes] Tecnología de la Información-funcional de
Requisitos SW
software de medición-Medida del tamaño
IEEE Std. 14471-2010 Guía de implantación de la norma ISO / IEC TR
Ingeniería SW
14471: 2007 Tecnología de la Información-Ingeniería de Software-
Modelos y Métodos
Directrices para la adopción de las herramientas CASE
IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006)
Mantenimiento SW
estándar para
Software
IEEE Std.del ciclo de vidaTrial-Uso
15.026,1-2011 del software de ingeniería
Adopción y procesos
estándar de
de la norma
mantenimiento
ISO / IEC TR 15026-1: 2010 Sistemas y de Ingeniería de Software- SW Calidad
Sistemas y de Software Assurance-Parte 1: Conceptos y
Vocabulario
IEEE Std. 15026,2-2.011 adopción del estándar ISO / IEC 15026- 2:
2011 Sistemas y de Ingeniería de Software-Systems y Software SW Calidad
Assurance-Parte 2: Aseguramiento de la caja
ISO / IEC 15026-3 Sistemas y de Ingeniería de Software-Sistemas y de
SW Calidad
Software Assurance-Parte 3: Niveles de Integridad del sistema
ISO / IEC 15026-4: 2012 Sistemas y de Ingeniería de Software-
SW Calidad
Sistemas y de Software Assurance-Parte 4: Control de calidad en el
ciclo
IEEEde vida
Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008) Proceso de Ingeniería
estándar para de SW
Sistemas
ISO / IECy/procesos de ciclo
IEEE 15289: 2011deSistemas
vida del ysoftware deIngeniería-
Software ingeniería-Sistema Proceso de Ingeniería
contenido del Ciclo de Vida de Productos de Información de SW
(Documentación)
ISO / IEC 15504 [diez partes] Tecnología de la Información-Proceso Proceso de Ingeniería
Evaluación de SW
IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939: 2007 Ingeniería SW
Sistemas y Procesos de Ingeniería de Software de Mediciones administración
ISO / IEC 15940: 2006 Tecnología de la Información Ingeniería de Ingeniería SW
Software- Modelos y Métodos
Servicios de entorno
IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006)
Ingeniería SW
estándar para
administración
Sistemas y Gestión de Riesgos de Ingeniería de Software-Software Ciclo
de
ISOVida procesos-
/ IEC / IEEE 16326: 2009 de Gestión de Sistemas y de Ingeniería de Ingeniería SW
Software-Life Cycle Procesos-Proyecto administración
ISO / IEC 19501: 2005 Tecnología de la Información-distribuido abierto Ingeniería SW
Modeling Language (UML) Versión 1.4.2 Procesamiento-Unificado Modelos y Métodos
SEGUNDO-46 Guía
SWEBOK® V3.0

ISO / IEC 19505: 2012 [dos partes] a objetos Grupo de Tecnología de Ingeniería SW
Gestión de Información Unified Modeling Language (UML del OMG) Modelos y Métodos
ISO / IEC 19506: 2012 Tecnología de la Información-Object
Ingeniería SW
Management Group arquitectura dirigida Modernización (ADM) -
Modelos y Métodos
Conocimiento Descubrimiento Meta-Modelo (KDM)
ISO / IEC 19507: 2012 Tecnología de la Información-Object Ingeniería SW
Management Group Object Constraint Language (OCL) Modelos y Métodos
ISO / IEC TR 19759: 2005 Ingeniería de Software-Guía de la Ingeniería
[General]
de Software de Administración de Conocimiento (SWEBOK)
ISO / IEC 19761: 2011 Ingeniería de Software-CÓSMICO: Un Tamaño
Requisitos SW
Funcional Método de medición
ISO / IEC 20000-1: 2011 Tecnología de la Información-Servicio Proceso de Ingeniería
de Gestión-Parte 1: Requisitos del sistema de gestión de servicios de SW
ISO / IEC 20926: 2009 Software e Ingeniería de Sistemas-Software-
Requisitos SW
Medición IFPUG funcional Tamaño Método de medición
ISO IEC 20968/2002: Manual de Prácticas de Análisis de Puntos de
Requisitos SW
Función de conteo de Ingeniería de Software-MK II
ISO / IEC 24570: 2005 Ingeniería de Software-NESMA funcional
tamaño de la medida Método Versión 2.1-Definiciones y Requisitos SW
Lineamientos contando para la Aplicación del Análisis de Puntos
de Función
IEEE Std. 24.748,1-2011 Guía de implantación de la norma ISO / IEC
Proceso de Ingeniería
TR 24748-1: 2010
de SW
Ingeniería de Sistemas y Gestión-Life-Cycle Software Parte 1: Guía para
la Gestión
IEEE del Ciclo de Vida
Std. 24748,2-2012 Guía de implantación de la norma ISO / IEC TR
24748-2: 2011 Proceso de Ingeniería
Sistemas y de Ingeniería de Software de Gestión de Vida-Parte 2 de SW
Ciclo: Guía para la aplicación de la norma ISO / IEC 15288
(Procesos
IEEE Std. del ciclo de
24748-3: vidaGuía
2012 del sistema)
de implantación de la norma ISO / IEC
TR 24748-3: 2011 Proceso de Ingeniería
Sistemas y de Ingeniería de Software de Gestión-Life-Cycle Parte 3: de SW
Guía para la aplicación de la norma ISO / IEC 12207 (procesos del
ciclo
ISO / de
IECvida del software)
/ IEEE 24765: 2010 Sistemas y Software
[General]
Ingeniería-Vocabulario
ISO / IEC TR 24772: 2013 Idiomas tecnología de la información de
programación - Orientación para evitar vulnerabilidades en lenguajes de Construcción SW
programación a través de selección de idioma y Uso
ISO / IEC 24773: 2008 Ingeniería de Software-Certificación de Software SW Ingeniería
Los profesionales de ingeniería Práctica Profesional
IEEE Std. 24774: 2012 Guía de implantación de la norma ISO / IEC
Proceso de Ingeniería
TR 24474: 2010 Sistemas y de Ingeniería de Software-Life Cycle
de SW
Directrices para Management- Descripción del Proceso
ISO / IEC 25000: 2005 Software de ingeniería y software Requisitos de
SW Calidad
calidad del producto y Evaluación (cuadrados) -Guía de cuadrar
Apéndice B B-47

ISO / IEC 25000 25099 a través de software de ingeniería y
SW Calidad
software Requisitos de calidad del producto y Evaluación
(cuadrados)
ISO / IEC 25010: 2011 Sistemas y de Ingeniería de Software-Systems
y requisitos de calidad de software y Evaluación (cuadrados) -Sistema SW Calidad
y modelos de calidad del software
Formato ISO / IEC 25060 25064 a través de software de ingeniería y
software Requisitos de calidad del producto y Evaluación (cuadrados) SW Calidad
Industria -Common (CIF) de la Usabilidad
ISO / IEC / IEEE 26511: 2012 Sistemas y Software Ingeniería SW
INGENIERÍA-Requisitos para los gerentes de Documentación administración
del
ISOusuario
/ IEC / IEEE 26512: 2011 Requisitos de Sistemas y Software Ingeniería SW
ingeniería- para adquirentes y proveedores de Documentación del usuario administración
IEEE Std. 26513-2010 La adopción del estándar ISO / IEC 26513: 2009
Sistemas y de Ingeniería de Software-Requisitos para Probadores y Prueba de SW
revisores de Documentación
IEEE Std. 26514-2010 La adopción del estándar ISO / IEC 26514: 2008
Sistemas y de Ingeniería de Software-Requisitos para los diseñadores y SW Diseño
desarrolladores de documentación del usuario
ISO / IEC / IEEE 26515: 2012 Sistemas y Software Ingeniería- Ingeniería SW
desarrollo de la documentación del usuario en un entorno ágil Modelos y Métodos
ISO / IEC 29110 [varias partes] Ingeniería de Software-ciclo de Proceso de Ingeniería
vida de los perfiles de entidades muy pequeñas (VSE) de SW
/ IEC / IEEE 29119 [cuatro partes] (Borrador) Software ISO y Sistemas
Prueba de SW
Las pruebas de ingeniería en software
ISO / IEC / IEEE 29148: 2011 Sistemas y de Ingeniería de Software-Life
Requisitos SW
Ciclo procesos de Ingeniería de Requisitos
ISO / IEC / IEEE 42010: 2011 Sistemas y Software Ingeniería-
SW Diseño
Arquitectura Descripción
IEEE Std. 90003: 2008 Guía de implantación de la norma ISO / IEC
90003: 2004 Ingeniería de Software-Directrices para la aplicación de SW Calidad
la norma ISO 9001: 2000 para Programas informáticos
LISTA DE REFERENCIA
ANEXO C CONSOLIDADO
La lista de referencias consolidado identifica [4 *] F. Bott et al., Cuestiones profesional en

todos los materiales de referencia recomendados Ingeniería de Software, 3ª ed., Taylor &
(a nivel de número de sección) que acompañan a Francis, 2000.
la descomposición de los temas dentro de cada
área de conocimiento (KA). Esta lista de [5 *] JG Brookshear, Ciencias de la
referencias consolidado es adoptada por la Computación:. Una visión general, 10ª ed,
certificación de ingeniería de software y Addison-Wesley, 2008.
productos asociados de desarrollo profesional
ofrecido por el IEEE Computer Society. Editores [6 *] D. Budgen, Diseño de software, 2ª ed.,
KA utilizan las referencias asignadas a su KA Addison-Wesley, 2003.
por la Lista de referencia consolidado como sus
referencias recomendadas. En conjunto esta lista [7 *] EW Cheney y DR Kincaid, Numérica
de referencia es consolidado Matemáticas y Computación, 6 ª ed., Brooks
/ Cole, 2007.
• Completar: Cubriendo todo el ámbito de la
Guía SWEBOK. [8 *] P. Clements et al, el software de
• Suficiente: Proporcionar suficiente documentación: Arquitecturas. Vistas y más
información para describir “generalmente allá, 2ª ed, Pearson Education, 2010..
aceptadas” conocimiento.
• Consistente: No es proporcionar [9 *] RE Fairley, gestionar y liderar proyectos de
conocimientos contradictorios ni prácticas software, Wiley-IEEE Computer Society
conflictivas. Press, 2009.
• Creíble: Reconocido como proporcionar
experto [10 *] D. Galin, Calidad de Software: de la teoría
tratamiento. a la implementación, Pearson Educación,
• Actual: Tratar el tema de una manera que SA, 2004.
sea acorde con los conocimientos
actualmente generalmente aceptada. [11 *] E. Gamma et al, patrones de diseño:..
• Sucinta: Lo más corto posible (tanto en nú- Elementos de software orientado a
mero de elementos de referencia y en el objetos reutilizables, 1st ed, Addison-
número total de páginas) sin fallar otros Wesley Professional, 1994.
objetivos.
[12 *] P. Grubb y AA Takang, Mantenimiento de
[1 *] JH Allen et al, software de seguridad Software: Conceptos y Práctica., 2ª ed,
Ingeniería:. Guía para los gerentes de Editorial Científico Mundial, 2003.
proyecto, Addison-Wesley, 2008.
[13 *] AMJ Hass, Principios y Prácticas de
[2 *] M. Bishop, Computer Security: Arte y gestión de configuración, 1st ed., Addison-
Ciencia, Addison-Wesley, 2002. Wesley, 2003.
[3 *] B. Boehm y R. Turner, Balancing agilidad

y disciplina: Una guía para los perplejos,
Apéndice B B-49
C-1
Guía de C-2 SWEBOK® V3.0
[14 *] E. Horowitz et al., Algoritmos de [25 *] S. Naik y P. Tripathy, pruebas de

ordenador, software y aseguramiento de la calidad:
2ª ed., Silicon Press, 2007. Teoría y Práctica, Wiley-Spektrum, 2008.
[15 *] IEEE / ACM Fuerza de Tarea Conjunta [26 *] J. Nielsen, Ingeniería de usabilidad, 1st
de CS Software Ética de ingeniería y ed., Morgan Kaufmann, 1993.
prácticas profesionales, “Software
Ingeniería Código de Ética y Práctica [27 *] L. y J. nulo Lobur, Lo Esencial de la
Profesional (Versión 5.2),” 1999; Organización de Computadores y
www.acm.org/serving/se/code.htm. Arquitectura, 2ª ed., Jones and Bartlett
Publishers, 2006.
[16 *] IEEE Std. 828-2012, Norma para
Sistemas de Gestión de la Configuración de [28 *] M. Página-Jones, Fundamentos del
Software e Ingeniería, IEEE 2012. Diseño orientado a objetos en UML, 1st ed.,
[17 *] IEEE Std. 1028-2008, software
comentarios y auditorías, IEEE 2008. [29 *] K. Rosen, Matemática Discreta y sus
Aplicaciones, 7ª ed., McGraw-Hill, 2011.
[18 *] ISO / IEC 14764 IEEE Std. 14764-2006,
Software del ciclo de vida del software de [30 *] A. Silberschatz, PB Galvin, y G.
ingeniería y procesos de mantenimiento, Gagne, Operating System Concepts,
IEEE 2006. octava ed., Wiley, 2008.
[19 *] SH Kan, métricas y modelos en Ingeniería [31 *] HM Sneed, “Mantenimiento de Software

de Software de Calidad, 2ª ed., Addison- como un Servicio de Oferta Marino”, Proc.
Wesley, 2002. IEEE Conf Int'l. Mantenimiento de Software
(ICSM 08), IEEE, 2008, pp. 1-5.
[20 *] S. McConnell, código completo, 2ª ed.,
Microsoft Press, 2004. [32 *] I. Sommerville, Ingeniería de Software, 9ª
[21 *] J. McGarry et al, Practical Software
de medición:. Información Objetivo [33 *] S. Tockey, Retorno de software:
para los decisores, Addison-Wesley maximizar el retorno de su inversión en
Professional, 2001. software, 1st ed, Addison-Wesley, 2004..
[22 *] SJ Mellor y MJ Balcer, ejecutable UML:. [34 *] G. Voland, Ingeniería de Diseño, segundo
Una Fundación para el Model-Driven ed., Prentice Hall, 2003.
Architecture, 1st ed, Addison-Wesley,
2002. [35 *] KE Wiegers, requisitos de software,
segundo
[23 *] DC Montgomery y GC Runger, ed., Microsoft Press, 2003.
Estadística Aplicada y Probabilidad
para Ingenieros, 4ª ed., Wiley, 2007. [36 *] JM Wing, “Introducción de un
especificador de métodos formales,”
[24 *] JW Moore, La Hoja de Ruta de Ingeniería Computer, vol. 23, no. 9, 1990, pp. 8, 10-23.
de Software:. Una guía basada en
estándares, 1st ed, Wiley-IEEE Computer

Swebok v3 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Swebok v3 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Guía de la Ingeniería de Software de

Un proyecto del IEEE Computer Society

Copyright © 2014 IEEE. Todos los derechos

El personal IEEE Computer Society para esta publicación

Capítulo 1: Software requisitos 1-1

Capítulo 2: Software Diseño 2-1

Capítulo 3: Software Construcción 3-1

Capítulo 4: Software Pruebas 4-1

Capítulo 5: Software Mantenimiento 5-1

5. El software de mantenimiento Tools5-11

Capítulo 6: Software Gestión de la configuración 6-1

Capítulo 7: Software Ingenieria administración 7-1

Capítulo 8: Software Ingenieria Proceso 8-1

Capítulo 9: Software Modelos de ingeniería y métodos 9-1

3.3. El análisis de la corrección 9-6

Capítulo 10: Software Quality10-1

Capítulo 11: Software profesional de la ingeniería Práctica 11-1

3.2. Escritura 11-11

Capítulo 12: Software Ingenieria Economics12-1

4.6. Análisis coste-efectividad 12-13

Capítulo 13: Informática Foundations13-1

8.2. Ingeniería de Sistemas 13-12

17.5. Construir Seguridad en Ingeniería de Procesos de Software 13-25

Capítulo 14: Matemático Foundations14-1

Capítulo 15: Ingenieria Foundations15-1

5.2. Simulación 15-11

Apéndice A: Área de Conocimiento Descripción Presupuesto A-1

Apéndice B: IEEE e ISO / IEC Apoyo a la Ingeniería de Software

Apéndice DO: Referencia consolidada Lista C-1

El software de inge- niería cuerpo de

Exámenes, requisitos de software, diseño de

TABLERO DE CONTROL DE CAMBIOS

Mantenimiento del software

Gestión de la Configuración de Software

Gestión de Ingeniería de Software

Proceso de Ingeniería de Software

Modelos de Ingeniería de Software y Métodos

Calidad del software

Economía Ingeniería de Software

Apéndice B: IEEE y normas ISO / IEC SWEBOK Apoyando

DE VERSIONES SWEBOK ANTERIORES

Mantenimiento del software

Gestión de la Configuración de Software

Gestión de Ingeniería de Software

Proceso de Ingeniería de Software

Herramientas de ingeniería de software y métodos

Calidad del software

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

PRESIDENTES IEEE Computer Society

PROFESIONAL actividades a bordo,

MOTIONS sobre la aprobación de SWEBOK

MOCIONES sobre la aprobación de

Tenga en cuenta también que la edición de la Guía de la Ingeniería de Software de Administración

KA Área de conocimiento La Guía no debe confundirse con el Cuerpo de

Publicación de la versión de esta Guía a la

Qué es la ingeniería de software?

ISO / IEC / IEEE Sistemas y de Ingeniería de

¿QUÉ SON LOS OBJETIVOS DE LA

certificación y concesión de licencias, el criterio El desglose de los temas en cada KA consti-

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

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

técnica es un ejemplo. Otro podría ser el uso de y, en su caso, cuantitativamente. Es importante

1.3. Requisitos funcionales y no funcionales