Guía de la Ingeniería de Software

Cuerpo de conocimientos

versión 3.0

SWEBOK ®

Un proyecto del IEEE Computer Society

 Guía de la Ingeniería de Software
Cuerpo de conocimientos

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 su reconocimiento IEEE de cualquier producto de terceros o servicios. 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 o pubs-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 capacidad, la eficiencia de comercialización, 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 puede 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 del Programa de Certificación de Gobierno

Evan M. Butterfield, Director de Productos y Servicios de John Keppler, Gerente Senior de

Educación Profesional Kate Guillemette, Product Development Editor Dorian McClenahan,

Programa de Educación Producto desarrollador Michelle Phon, Educación Profesional y

coordinador Jennie Zhu-Mai, diseñador editorial

Productos IEEE Computer Society y Servicios. El IEEE Computer Society de renombre mundial publica, promueve y distribuye 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 la www.computer.org

para más información.

 TABLA DE CONTENIDO

Prefacio xvii
Prólogo a la edición de 2004 xix
editores xxi
coeditores xxi
Colaboradores de redacción xxi
Tablero de control de cambios xxi
Editores Área de Conocimiento xxiii
Editores Área de Conocimiento de SWEBOK Versiones anteriores xxv
Equipo de revisión xxvii
Expresiones de gratitud xxix
Actividades profesionales Board, 2013 Membresía xxix
Movimientos respecto a la aprobación de la Guía SWEBOK V3.0 xxx
Movimientos respecto a la aprobación de la Guía SWEBOK 2004 Versión xxx
Introducción a la Guía XXXI

Capítulo 1: Requisitos de software 1-1

1. Requisitos de software Fundamentos 1-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 Proceso 1-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. la obtención de requisitos 1-5
3.1. requisitos Fuentes  1-5
3.2. técnicas de obtención  1-6
Análisis 4. Requisitos 1-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 Especificación 1-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 de Validación 1-11
6.1. requisitos críticas  1-11
6.2. prototipado  1-12

v
vi Guía SWEBOK® V3.0

6.3. Modelo de validación  1-12

6.4. Prueba de aceptacion  1-12
7. Consideraciones prácticas 1-12
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 Herramientas 1-14
Matriz de Temas vs. Material de Referencia 1-15

Capítulo 2: Diseño de Software 2-1

1. Fundamentos del Diseño de Software 2-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. Cuestiones clave en el diseño de software 2-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 Arquitectura 2-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. Diseño de Interfaz de Usuario 2-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. Análisis de Calidad de Software de Diseño y Evaluación 2-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. Diseño de Software notaciones 2-8
6.1. Las descripciones estructurales (estático Vista)  2-8
6.2. Las descripciones de comportamiento (vista dinámica)   2-9
7. Diseño de Software estrategias y métodos 2-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
 Tabla de contenidos vii

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. Herramientas de diseño de software 2-11
Matriz de Temas vs. Material de Referencia 2-12

Capítulo 3: Construcción de Software 3-1

1. Fundamentos de construcción de software 3-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. Gestión de la Construcción 3-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. Consideraciones prácticas 3-5
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. Tecnologías de la Construcción 3-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. Herramientas de software de construcción 3-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
Matriz de Temas vs. Material de Referencia 3-13
viii Guía SWEBOK® V3.0

Capítulo 4: Pruebas de Software 4-1

1. Fundamentos de Software Testing 4-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. Niveles de prueba 4-5
2.1. El objetivo de la prueba   4-5
2.2. Objetivos de las Pruebas   4-5
3. Técnicas de Prueba 4-7
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. Las medidas de prueba relacionados 4-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
Proceso 5. Prueba 4-12
5.1. Consideraciones prácticas  4-13
5.2. Las actividades de prueba  4-14
6. Herramientas de prueba de software 4-15
6.1. Herramienta de soporte de pruebas   4-15
6.2. Categorías de Herramientas   4-15
Matriz de Temas vs. Material de Referencia 4-17

Capítulo 5: Mantenimiento de Software 5-1

1. Fundamentos de mantenimiento de software 5-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. Temas clave en el mantenimiento de software 5-4
2.1. Problemas técnicos  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. Proceso de Mantenimiento 5-7
3.1. Los procesos de mantenimiento  5-7
3.2. Actividades de mantenimiento  5-8
4. Técnicas de Mantenimiento 5-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
 Tabla de contenido ix

5. Herramientas de Mantenimiento de Software 5-11

Matriz de Temas vs. Material de Referencia 5-12

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

1. Gestión del Proceso de SMC 6-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
Identificación 2. Configuración del software 6-6
2.1. Los productos que la identificación que deben ser controlados   6-6
2.2. software Library  6-8
3. Control de Configuración de Software 6-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. Configuración de software de contabilidad Estado 6-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
Auditoría 5. Configuración del software 6-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. El software de administración de lanzamientos y Entrega 6-11
6.1. Edificio de software   6-11
6.2. Gestión de la Entrega de Software   6-12
7. herramientas de Software 6-12
Matriz de Temas vs. Material de Referencia 6-13

Capítulo 7: Administración de Ingeniería de Software 7-1

1. Iniciación y Definición del Alcance 7-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. software de planificación 7-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
La promulgación 3. Proyecto de Software 7-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
x Guía SWEBOK® V3.0

4. Revisión y Evaluación 7-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. Cierre 7-9
5.1. Cierre la determinación  7-9
5.2. Actividades de cierre  7-9
6. Software de Ingeniería de medición 7-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. Herramientas de Gestión de Ingeniería de Software 7-11
Matriz de Temas vs. Material de Referencia 7-13

Capítulo 8: Proceso de Ingeniería de Software 8-1

1. Definición del proceso de software 8-2
1.1. Gestión de procesos de software   8-3
1.2. Infraestructura de Procesos de Software  8-4
2. Ciclos de vida del software 8-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. Software de Evaluación y Mejora de Procesos 8-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. Medición de Software 8-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 Herramientas 8-12
Matriz de Temas vs. Material de Referencia 8-13

Capítulo 9: Modelos de Ingeniería de Software y Métodos 9-1

1. Modelado 9-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 Modelos 9-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 Modelos 9-5
3.1. Para completar el análisis  9-5
3.2. La consistencia para analizar  9-6
 Tabla de contenidos xi

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. Métodos de ingeniería de software 9-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
Matriz de Temas vs. Material de Referencia 9-10

Capítulo 10: Calidad del Software 10-1

1. Fundamentos de Calidad de Software 10-2
1.1. Software de Ingeniería de la Cultura y Ética  10-2
1.2. Valor y costos de la 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. Procesos de Gestión de Calidad de Software 10-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. Consideraciones prácticas 10-9
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. Herramientas de software de calidad 10-12
Matriz de Temas vs. Material de Referencia 10-14

Capítulo 11: Ingeniería de Software Práctica Profesional 11-1

1. Profesionalismo 11-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. Grupo de Dinámica y Psicología 11-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. Habilidades de Comunicación 11-11
3.1. Leer, comprender y resumir   11-11
xii Guía SWEBOK® V3.0

3.2. Escritura   11-11

3.3. Equipo y Comunicación Grupo   11-11
3.4. Habilidades de presentación   11-12
Matriz de Temas vs. Material de Referencia 11-13

Capítulo 12: Software de Ingeniería económica 12-1

1. Fundamentos de Ingeniería de Software Economía 12-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 temporal del dinero  12-6
1.11. Eficiencia  12-6
1.12. Eficacia  12-6
1.13. Productividad  12-6
2. La vida de ciclo Economía 12-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 e Incertidumbre 12-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. Métodos de Análisis Económico 12-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
 Tabla de contenidos XIII

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. Consideraciones prácticas 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
Matriz de Temas vs. Material de Referencia 12-16

Capítulo 13: Fundamentos de Informática 13-1

1. Técnicas de Resolución de Problemas 13-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. Abstracción 13-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. Fundamentos de programación 13-5
3.1. El proceso de programación  13-5
3.2. Los paradigmas de programación  13-5
4. Principios básicos del lenguaje de programación 13-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 Técnicas 13-8
5.1. Tipos de error  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 representación 13-9
6.1. Presentación de la estructura de datos  13-9
6.2. Tipos de Estructuras de Datos  13-9
6.3. Las operaciones en Estructuras de Datos  13-9
7. Algoritmos y Complejidad 13-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 sistema de 13-11
8.1. Propiedades del sistema emergente  13-11
xiv Guía SWEBOK® V3.0

8.2. Ingeniería de Sistemas  13-12

8.3. Visión general de un sistema informático  13-12
9. Organización del ordenador 13-13
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. Fundamentos del compilador 13-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. Fundamentos de Sistemas Operativos 13-16
11.1. Operativo general Sistemas  13-16
11.2. Las 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. Conceptos básicos de bases de datos y gestión de datos 13-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 de paquetes de DBMS  13-18
12.5. Gestión de datos  13-19
12.6. La minería de datos  13-19
13. Conexión de red básica de comunicación 13-19
13.1. Tipos de 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. Red Privada Virtual (VPN)   13-21
14. Computación Paralela y Distribuida 13-21
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. Los factores humanos básicos de los usuarios 13-22
15.1. Entrada y salida  13-22
15.2. Error de mensajes  13-23
15.3. La robustez del software  13-23
16. Developer básico Factores Humanos 13-23
16.1. Estructura   13-24
16.2. comentarios  13-24
17. asegurar el desarrollo y mantenimiento de software 13-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
 Tabla de Contenidos xv

17.5. Construir Seguridad en Ingeniería de Procesos de Software  13-25

17.6. Guía de seguridad de software  13-25
Matriz de Temas vs. Material de Referencia 13-27

Capítulo 14: Fundamentos matemáticos 14-1

1. Establecer, relaciones, funciones 14-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. Lógica Básica 14-5
2.1. Lógica proposicional  14-5
2.2. La lógica de predicados   14-5
3. Técnicas de prueba 14-6
3.1. Métodos de demostración de teoremas  14-6
4. Fundamentos de Conteo 14-7
5. Los gráficos y los árboles 14-8
5.1. Los gráficos   14-8
5.2. árboles   14-10
6. probabilidad discreta 14-13
7. máquinas de estados finitos 14-14
8. gramáticas 14-15
8.1. Reconocimiento idioma   14-16
9. numérica precisión, exactitud y errores 14-17
10. Teoría de Números 14-18
10.1. Divisibilidad   14-18
10.2. Número primo, GCD   14-19
11. Estructuras algebraicas 14-19
11.1. Grupo  14-19
11.2. anillos   14-20
Matriz de Temas vs. Material de Referencia 14-21

Capítulo 15: Ingeniería de cimentaciones 15-1

1. Métodos empíricos y técnicas experimentales 15-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. Medición 15-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. Diseño de Ingeniería 15-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 Prototipos 15-10
5.1. Modelado  15-10
xvi Guía SWEBOK® V3.0

5.2. Simulación   15-11

5.3. prototipado  15-11
6. Normas 15-12
Análisis Causa Raíz 7. 15-12
7.1. Las técnicas para la realización de análisis de causa raíz  15-13
Matriz de Temas vs. Material de Referencia 15-14

Apéndice A: Área de Conocimiento Descripción Especificaciones A-1

Apéndice B: IEEE y normas ISO / IEC Apoyo a la swebok (SWEBOK)

B-1

Apéndice C: Lista de referencia consolidado C-1

 PREFACIO
Cada profesión se basa en un conjunto de conocimientos, a pesar de
que el conocimiento no siempre se define de una manera concisa. En
los casos en que no existe ninguna formalidad, el 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 esto Guía de la Ingeniería de
Software de Administración de Conocimiento, las cons- tituye IEEE
Computer Society una versión revisada y actualizada del conjunto de
conocimientos anteriormente documentado como SWEBOK 2004;
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 lo
cual no representa la totalidad del cuerpo de conocimientos de
ingeniería de soft- ware sino que sirve como guía para el conjunto de
conocimientos que se ha desarrollado durante más de cuatro
décadas. El software de inge- niería cuerpo de conocimientos está
constantemente en evolución ing. Sin embargo, esta Guía constituye
una valiosa caracterización poder de la profesión de la ingeniería de
software.
xvii
En 1958, John Tukey, la istician stat- de renombre mundial, acuñó el
término software. ingeniería de cerámica El término blandas se utiliza en
el título de una conferencia de la OTAN celebrada en Alemania en 1968.
El IEEE Computer Society publicó por primera vez su Las transacciones
en Ingeniería de Software en 1972, y una camiseta de compromiso para
el desarrollo de la ingeniería de software Dardos Están- se estableció
dentro de la IEEE Computer Society en 1976.
En 1990, se inició la planificación para una norma interna- cional
para proporcionar una visión global de ingeniería de soft- ware. El
estándar se completó en 1995 con la designación ISO / IEC 12207
y recibió el título de Cesos estándar para Software Ciclo de Vida
Pro-. La versión de IEEE 12207 fue publicada en 1996 y
proporcionó una base importante para el conjunto de
conocimientos capturado en SWEBOK 2004. La versión actual de
12207 se designa como ISO / IEC 12207: 2008 e IEEE 12.207 a
2.008; que proporciona la base para este V3 SWEBOK. Esta Guía
de la Ingeniería de Software de Administración de Conocimiento se
presenta a usted, el lector, como un mecanismo para adquirir los
conocimientos que necesita en su desarrollo de carrera de toda la
vida como un profesional de la ingeniería de software.
Dick Fairley, Presidente
Software y Comité de Ingeniería de Sistemas
IEEE Computer Society
Don Shafer, vicepresidente
Junta actividades profesionales
IEEE Computer Society
 Prólogo a la edición de 2004
En esto Guía, lishes la IEEE Computer Society esta- por primera
vez una línea de base para el conjunto de conocimientos para el
campo de la ingeniería de software, y el trabajo cumple
parcialmente la responsabilidad de la sociedad para promover el
avance de la teoría y la práctica en este 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 guiar al cuerpo de
conocimiento que se ha ido desarrollando y en evolución ing en
las últimas cuatro décadas. Por otra parte, este conjunto de
conocimientos no es estática. los Guía
debe, necesariamente, desarrollar y evolucionar a medida que madura la
ingeniería de software. Sin embargo, constituye un valioso elemento de
la infraestructura de la ingeniería de software.
En 1958, John Tukey, la istician stat- de renombre mundial,
acuñó el término software. El termino Ingeniería de software se
utilizó en el título de una conferencia de la OTAN celebrada en
Alemania en 1968. El IEEE Computer Society publicó por primera
vez su Las transacciones en 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 cali- dad 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 Exámenes,
requisitos de software, diseño de software, y la verificación y
validación de software.
Durante el periodo 1981-1985, la Sociedad IEEE putadora
Com- llevó a cabo una serie de talleres con- cerning la aplicación
de la ingeniería de software
xix
normas. Estos talleres involucrados ners practitio- compartiendo sus
experiencias con los Standards existentes. Los talleres también se
llevaron a cabo sesiones sobre la Planificación de las normas futuras,
incluyendo uno que incluya las medidas y métricas para la ingeniería
de software de productos y procesos. La planificación también resultó
en IEEE Std. 1002, Taxonomía de los Estándares de Ingeniería de
Software ( 1986), que proporciona una nueva visión, holística de
ingeniería de software. La norma describe la forma y el contenido de
las normas de ingeniería de un soft- ware taxonomía. Se explican los
diferentes tipos de Dardos de ingeniería de software Están-, sus
relaciones funcionales y externos, y el papel de las diversas
funciones que participan en el ciclo de vida del software.
En 1990, se inició la planificación para un Dard Están-
internacional con una visión de conjunto. El la Planificación centrada
sobre la conciliación de los puntos de vista del proceso de software
de IEEE Std. 1074 y la norma revisada 2167A de EE.UU.
Departamento de Defensa. La revisión fue publicada como aliado
eventu- DoD Std. 498. La norma internacional se completó en 1995
con la denomina- ción, ISO / IEC 12207, y se le dio el título de Dard
Están- para los procesos de ciclo de vida del software. Std. ISO / IEC
12207 proporciona un importante punto de partida para el conjunto
de conocimientos capturados en este libro. Era la Junta IEEE
Computer Society de Gobernadores la aprobación de la moción
presentada en mayo de 1993 mediante Fletcher Buckley, que dio
lugar a la redacción de este libro. La Association for Computing
Machinery Consejo (ACM) aprobó una moción relacionada en agosto
de 1993. Los dos movimientos condujeron a un comité conjunto bajo
la dirección de Mario Barbacci y Stuart Zweben que sirvió como
copresidentes. La declaración de la misión de la comisión conjunta
era “Establecer los conjuntos apropiados (s) de criterios y normas
para la práctica profesional de la ingeniería de software sobre el cual
siones industriales terio, la certificación profesional, y los programas
de estudio se pueden basar.” El comité directivo grupos de trabajo
organizados en las siguientes áreas:
1. Definir Obligatorio cuerpo de conocimientos y métodos
recomendados.
xx Guía SWEBOK® V3.0

2. Definir Ética y Estándares Profesionales. Se espera que los lectores encontrarán en este libro uso-ful para
3. Definir planes de estudio para la Educación univer- comieron, guiarlos hacia el conocimiento y los recursos que necesitan en su
graduado, y la educación continua. carrera de por vida desa- rrollo como profesionales de ingeniería de
software. El libro está dedicado a Fletcher Buckley en
Este libro suministra el primer componente: se requiere reconocimiento a su compromiso con la promoción de la ingeniería
conjunto de conocimientos y recomendar prácticas. El código de software como una disciplina profesional y su excelencia como
de ética y práctica profesional de la ingeniería de software se Tioner una ingeniería de software prác- en aplicaciones de radar.
completó en 1998 y aprobado tanto por el Consejo de ACM y
la IEEE Computer Society Junta de Gobernadores. Ha sido
adoptado por numerosas empresas y otras organizaciones y
está incluido en varios libros de texto recientes.
Leonard L. Tripp, Fellow de IEEE 2003
Presidente del Comité de Prácticas Profesionales, IEEE 
El plan de estudios para los estudiantes está siendo Computer Society (2001-2003)
completada por un esfuerzo conjunto de la IEEE Computer
Society y de la ACM y se espera que esté terminado en 2004. Presidente del Comité Directivo Conjunto IEEE Computer
Society y ACM para el Establecimiento de Ingeniería de
Cada profesión se basa en un cuerpo de El conocimiento y las Software como Profesión (1998-1999)
prácticas recomendadas, a pesar de que no siempre se definen de
una manera precisa. En muchos casos, éstos se documentan Presidente del Comité de Estándares de Ingeniería de Software, 
formalmente, el aliado no baja en una forma que les permite ser IEEE Computer Society (1992-1998)
utilizado para 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 profe- sional. 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 SWEBOK V3:

Don Shafer Linda
Shafer Mary Jane
Willshire Kate
Guillemette

TABLERO DE CONTROL DE CAMBIOS

Las siguientes personas que se presentan en el Guía SWEBOK V3 Junta de Control de Cambio:
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, Facultad de Tecnología de la 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

xxiii
xxiv Guía SWEBOK® V3.0

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
 Editores de área CONOCIMIENTO DE LAS
VERSIONES ANTERIORES SWEBOK

Las siguientes personas sirvieron como editores asociados, ya sea para la versión de prueba publicado en 2001 o para la versión 2004.

Requisitos de Software
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 de Tecnología Superior, Canadá

Gestión de la Configuración de Software

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

Gestión de Ingeniería de Software

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,
La Universidad de Queensland, Australia

xxv
xxvi Guía SWEBOK® V3.0

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 se indican a continuación participaron en el proceso de revisión pública de 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, EE.UU. Mark Ardis, Istvan Fay, Hungría José L.

EE.UU. Mora-Soto Arturo, España Ohad Fernández-Sánchez, Dennis J. España Frailey,
Barzilay, Israel Gianni Basaglia, Italia Denis EE.UU. Tihana Galinac Grbac, Croacia Colin
J. Bergquist, EE.UU. Alexander Bogush, Garlick, Nueva Zelanda Garth JG Glynn, Reino
Reino Unido Christopher Bohn, EE.UU. Unido Jill Gostin, EE.UU.
Steve Bollweg, EE.UU. Reto Bonderer, Suiza
Alexei Botchkarev, Canadá Pieter Botman,
Canadá Robert Bragner, EE.UU. Kevin Christiane von Gresse Wangenheim, Brasil Thomas
Brune, EE.UU. Ogihara Bryan, EE.UU. Luigi Gust, EE.UU.
Buglione, Italia Rick Cagle, EE.UU. Barbara HN Mok, Singapur Jon D. Hagar,
Canody, EE.UU. Rogerio A. Carvalho, Brasil EE.UU. Anees Ahmed Haidary, India
Daniel Cerys, EE.UU. Philippe Cohard, Duncan Hall, Nueva Zelanda James
Francia Ricardo Colomo-Palacios, Mauricio Hart, EE.UU. Jens HJ Heidrich,
Coria España , Argentina Marek Cruz, Reino Alemania Rich Hilliard, EE.UU. Bob
Unido Stephen Danckert, EE.UU. Bipul K. Hillier, Canadá Norman M. Hines,
Das, Canadá James D. Davidson, EE.UU. EE.UU. Dave Hirst, EE.UU. Theresa L.
Jon Dehn, EE.UU. Lincoln P. Djang, EE.UU. hunt, EE.UU. Kenneth Ingham, EE.UU.
Andreas Doblander, Austria Yi-Ben Doo, Masahiko Ishikawa, Japón Michael A.
EE.UU. Scott J. Dougherty, Reino Unido Jablonski, EE.UU.
Regina DuBord , EE.UU. Fedor Dzerzhinskiy,
Rusia Ann M. Eblen, Australia David M.
Endres, EE.UU. Marilyn Escue, EE.UU.
Varuna Eswer, India
G. Jagadeesh, India Sebastián Justicia,
España Umut Kahramankaptan, Bélgica
Pankaj Kamthan, Canadá Perry Kapadia,
EE.UU. Tarig A. Khalid, Sudán Michael KA
Klaes, Alemania MAGED Koshty, Egipto
Claude C. Laporte, Canadá Dong Li, China
Ben Linders, Países Bajos Claire Lohr,
EE.UU. Vladimir Mandic, Serbia Matt
Mansell, Nueva Zelanda, John Marien,
EE.UU.

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

Los fondos para el desarrollo de Guía SWEBOK
V3 ha sido proporcionada por la IEEE Computer Society. Los
editores y coeditores aprecian el importante trabajo realizado por
los editores Ka y los editores colaboradores, así como por los de
los miem- bros de la Junta de Control de Cambios. El equipo
editorial también debe reconocer la contribución indispensable de
los colaboradores.
El equipo editorial también desea agradecer a las personas
siguien- tes que han contribuido al proyecto en
diversas maneras: Pieter Botman, Evan Butterfield, Carine
Chauny, Pierce Gibbs, Diane Girard, John Keppler, Dorian
McClenahan, Kenza Meridji, Sam-uel Redwine, Annette Reilly, y
Pam Thompson. Por último, seguramente hay otras personas
que han contribuido a este Guía, ya sea directa o indirectamente,
cuyos nombres tenemos omitirse sin querer Ted. Para esas
personas, ofrecemos nuestra apre- ciación tácito y disculpas por
haber omitido el reconocimiento 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
xxx Guía SWEBOK® V3.0

MOCIONES respecto a la aprobación

DE SWEBOK GUÍA V3.0

los 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 este manuscrito de la Guía SWEBOK
V3.0 para ubicarse en el 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 IEEE Computer Society 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 Conocimientos La versión 3.0 ha sido completada 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 respecto a la aprobación

DE GUÍA SWEBOK 2004 VERSIÓN

La siguiente moción fue aprobada por unanimidad por el Consejo Asesor Industrial del 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 2004 Guí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 pro- fesional para continuar con la
impresión.

Tenga en cuenta también que la edición del 2004 Guía de la Ingeniería de Software de Administración de Conocimiento 
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
Software Cuerpo de Ingeniería del
SWEBOK
Conocimiento
Publicación de la versión de este 2004 Guía de la Ingeniería de
Software de Administración de Conocimiento ( SWE- BOK 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 relevantes
para cada KA, y una lista de las referencias citadas en el Guía.
Esta Guía, escrita bajo los auspicios de la Junta de Actividades
Profesionales de la Sociedad IEEE orde- nador, representa un
siguiente paso en la evolu- 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 al software) “. 1
¿QUÉ SON LOS OBJETIVOS DE LA GUÍA
SWEBOK?
los Guía no debe confundirse con el Cuerpo de Conocimiento
mismo, que existe en la publicación
1 Véase www.computer.org/sevocab .
XXXI
literatura. El propósito de Guía es describir la parte del
cuerpo de conocimientos que se gene- ralmente
aceptada, para organizar esa porción, y para
proporcionar acceso tópica a la misma. los Guía de la
swebok (Guía SWEBOK) se estableció con los cinco
objetivos siguientes:
1. Promover una visión consistente de la ingeniería de software en
todo el mundo
2. Para especificar el alcance de, y aclarar el lugar de la
ingeniería de software con respecto a otras disciplinas
como la informática, la gestión del pro- yecto, ingeniería
informática y matemáticas
3. Caracterizar los contenidos de la disciplina de la ingeniería
de software
4. Proporcionar un acceso tópica en la Ingeniería de Software de
Administración de Conocimiento
5. Proporcionar una base para el desarrollo curricular y
para la certificación individual y material de licencias
El primero de estos objetivos, una amplia visión del mundo
coherente de ingeniería de software, fue apoyada por un proceso de
desarrollo que dedica aproximada- mente 150 los colaboradores de
33 países. Más información sobre el proceso de desarrollo se puede
encontrar en la página web ( www.swebok.org ). Se estableció
contacto con las agencias fesionales y las sociedades científicas y
públicas pro involucrados en la ingeniería de software, conscientes de
este proyecto para actualizar SWEBOK, e invitados a participar en el
proceso de revisión. tores KA edi- fueron reclutados de América del
Norte, la cuenca del Pacífico, y Europa. Las presentaciones sobre el
proyecto se hicieron en varios lugares internacionales. El segundo de
los objetivos, el deseo de especificar el ámbito de la ingeniería de
software, moti- VATES la organización fundamental de la Guía. El
material que se reconoce como estar dentro de esta disciplina se
organiza en los quince KAs enumerados en la Tabla I.1. Cada uno de
estos Kas es tratado en un capítulo de esta Guía.
xxxii Guía SWEBOK® V3.0

Tabla I.1. El 15 SWEBOK KAs La organización jerárquica

Requisitos de software de
La organización de los capítulos KA es compatible con el tercero de
mantenimiento de software de
los objetivos de una caracterización del proyecto de los contenidos de
diseño de construcción de
la ingeniería de software. Las especificaciones detalladas
pruebas de software Software proporcionadas por el equipo de redacción del proyecto para los
editores asociados en relación con los contenidos de las descripciones
KA se pueden encontrar en el Apéndice A. El Guía utiliza una
Proceso de Gestión de la Configuración de
organización jerárquica para descomponer cada KA en un conjunto de
Software Software de Gestión de Ingeniería de
temas con etiquetas tificables daciones. Un desglose de nivel dos (a
Software Ingeniería veces tres) proporciona una forma razonable para buscar temas de

Software Engineering Modelos y Métodos de Calidad de
Software
Fundamentos de Ingeniería de Software Práctica Profesional
de Ingeniería de Software de Computación Economía
interés. los Guía trata los temas seleccionados de una manera
compatible con las principales escuelas de pensamiento y con las
averías que se encuentran generalmente en la industria y en la
literatura de ingeniería de software y estándares. Las averías de los
temas no presumen dominios particulares de aplicación, usos

fundamentos matemáticos Fundamentos de Ingeniería
Al especificar el alcance, también es importante adoptar la definición de
las disciplinas que se cruzan con la ingeniería de software. Con este fin,
comerciales, filosofías de gestión, métodos de desarrollo, y así
sucesivamente. La extensión de la descripción de cada tema es sólo
eso necesitaba comprender la naturaleza generalmente aceptada de
los temas y para que el lector encuentre éxito material de referencia; el
Cuerpo de Conocimiento se encuentra en los materiales de referencia
a sí mismos, no en el Guía.

SWEBOK V3 también reco- ognizes siete disciplinas relacionadas, que se

enumeran en la tabla

I.2. Los ingenieros de software deben, por supuesto, tener

conocimiento de material a partir de estas disciplinas (y las
descripciones en este KA Guía puede hacer referencia a ellos). No
es, sin embargo, un obje- tivo de la Guía SWEBOK para
caracterizar el conocimiento de las disciplinas relacionadas.
Tabla I.2. Disciplinas relacionadas
MATERIAL DE REFERENCIA Y MATRIZ
Para proporcionar acceso tópica en el conocimiento de la cuarta
parte de los objetivos del proyecto, el Guía
identifica material de referencia autorizada para cada KA.
Apéndice C proporciona una lista de referencia consolidado

Matemáticas gestión de la
del Guía. Cada KA incluye referencias relevante de la lista
consolidada de referen- cia y también incluye una matriz que
ciencia de computadoras en
relaciona el material de referencia para los temas incluidos.
general Ingeniería Informática Cabe señalar que la Guía no pretende ser exhaustivo en sus
citas. Mucho material que es a la vez conveniente y excelente

Ingeniería de Sistemas de no se hace referencia. Material incluido en la lista de

referencias Consolidated proporciona cobertura de los temas
Gestión de Calidad Gestión
descritos.
de Proyectos

Los elementos pertinentes de la informática y las

matemáticas se presentan en los Fundamentos de la Profundidad del tratamiento
Computación e Fundamentos matemáticos de la KAs guía ( Los
capítulos 13 y 14). Para lograr el quinto objetivo pro-SWEBOK Viding una
base para el desarrollo curricular,

certificación y concesión de licencias, el criterio de generalmente
aceptado el conocimiento se ha aplicado, que se distingue de un
conocimiento avanzado y la investigación (sobre la base de la
madurez) y de conocimiento especializado (por motivos de
generalidad de la solicitud). El término equivalente generalmente
reconocido 
proviene del Instituto de Gestión de Proyectos: “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.” 2
Sin embargo, los términos “generalmente aceptados” o
“generalmente reconocido” no implican que el des- conocimiento
ignated debe aplicarse de manera uniforme a todos los esfuerzos de
ingeniería de software, cada una de las necesidades pro- yecto
determinan que-pero sí implica que, ingenieros de software capaces
competentes deberían estar equipados con este conocimiento para su
aplicación potencial. Más precisamente, el conocimiento generalmente
aceptado debe ser incluido en el estudio de mate- rial para la ingeniería
de licencias de software exami- nación que los graduados tomarían
después de ganar cuatro años de experiencia laboral. Aunque este cri-
terio es específico para el estilo de los EEUU de la educación y no
necesariamente se aplica a otros países, consideramos que es útil.
ESTRUCTURA DE LAS DESCRIPCIONES KA
Las descripciones KA se estructuran como sigue. En la
introducción, se presentan una breve definición de la KA y una
visión general de su alcance y de su nave PARENTESCO con
otros KAs.
2 Una guía para la Dirección de Proyectos del Conocimiento, 5 ed,
el Project Management Institute, 2013.; www.pmi.org .
Introducción xxxiii
El desglose de los temas en cada KA consti- tuye el
núcleo la descripción KA, que describen la descomposición
de la KA en subáreas, temas y subtemas. Para cada tema
o subtema, se da una breve descripción, junto con una o
más referencias.
El material de referencia fue elegido porque se considera que
constituye la mejor presentación de los conocimientos en relación
con el tema. Una matriz vincula los temas que el material de
referencia. La última parte de la descripción de cada KA es la lista
de referencias recomendadas y (opcionalmente) las lecturas ther de
pieles. normas pertinentes para cada KA se presentan en el
Apéndice B de la Guía.
APÉNDICE A. KA Descripción
Especificaciones
Apéndice A describe las especificaciones proporcionadas por el
equipo editorial de los editores asociados de los contenidos,
referencias, formato y estilo de las descripciones KA
recomendado.
APÉNDICE B. ASIGNACIÓN DE Normaliza- ción
A KAS
Apéndice B es una lista comentada de las normas pertinentes,
sobre todo del IEEE y de la ISO, para cada una de la KAS de la Guía
SWEBOK.
LISTA DE REFERENCIA APÉNDICE C.
CONSOLIDADO
Apéndice C contiene la lista consolidada de las referencias
citadas en reco- mienda la KAS (estas referencias están
marcados con un asterisco (*) en el texto).
 CAPÍTULO 1
REQUISITOS DE SOFTWARE
SIGLAS
Confidencialidad, integridad y
CIA
disponibilidad de DAG
Dirigido acíclicos Gráfico FSM
Tamaño funcional Medición Consejo
Internacional sobre Sistemas INCOSE
ingeniería
UML Lenguaje Unificado de Modelado de
Sistemas SysML Lenguaje de Modelado
INTRODUCCIÓN
El área de conocimiento Requisitos de software (KA) se ocupa de
la obtención, análisis, speci- ficación, y la validación de los
requisitos de software, así como la gestión de los requisitos
Duran- todo el ciclo de vida del producto de software. Es
ampliamente reconocido entre los investigadores y profesionales
de la industria que los proyectos de software son críticamente
vulnerables cuando están mal realizan las actividades
relacionadas REQUISITOS. Requisitos de software expresan las
necesidades y limitaciones impuestas a un producto de software
que contribuyen a la solución de algunos problemas del mundo
real.
La “ingeniería de requisitos” plazo es ampliamente utilizado en
el campo para indicar la manipulación sistemática de requisitos.
Por razones de coherencia, el término “ingeniería” no se utiliza
en este KA excepto para la ingeniería de software en sí. Por la
misma razón, “ingeniero de requisitos”, un término que aparece
en la parte de la literatura, no se utilizará tampoco. En cambio, el
término “ingeniero de software” o, en algunos casos específicos,
“los requisitos especialista” se utilizará, este último donde el
papel en cuestión se realiza generalmente por una persona que
no sea un ingeniero de software. Esta
1-1
, No implica, sin embargo, que un ingeniero de software no pudo
realizar la función. Un riesgo inherente en la descomposición
propuesta es que un proceso de cascada-como puede deducirse.
Para evitar esto, el tema 2, los requisitos del proceso, está diseñado
para proporcionar una visión general de alto nivel del proceso de
requisitos mediante el establecimiento de los recursos y las
limitaciones con las que opera el proceso y que actúan para
configurarlo. Una descomposición alternativa podría utilizar una
estructura a base de pro- ducto (requisitos del sistema, los requisitos
de soft- ware, prototipos, casos de uso, y así sucesivamente). La
composición basada en el proceso refleja el hecho de que el proceso
de requisitos, si ha de tener éxito, debe ser considerada como un
proceso que implica actividades complejas, fuertemente acoplados
(tanto secuenciales y simultáneas), en lugar de como una discreta,
de una sola vez la actividad realizada al inicio de un proyecto de
desarrollo de software. Los requisitos de software KA se relaciona
estrechamente con el diseño de software, pruebas de software,
mantenimiento de software, Software Configuration Management,
Gestión de Ingeniería de Software, Software de Ingeniería de
Procesos, Ingeniería de Software y Modelos Métodos y Calidad de
Software de Kas.
DISTRIBUCIÓN DE TEMAS PARA
REQUISITOS DEL SOFTWARE
El desglose de los temas de los requisitos de software KA
se muestra en la Figura 1.1.
1. Requisitos de software Fundamentos
[1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6, c12]
1.1. Definición de un requisito de software
En su forma más básica, un requisito de software es una
propiedad que debe ser exhibido por algo en
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. Se puede tratar
de automatizar parte de una tarea para alguien para apoyar los
procesos de negocio de una organiza- ción, para corregir
defectos de software existente, o para controlar un nombre de
dispositivo a sólo algunos de los muchos problemas para los que
son posibles soluciones de software . Las formas en que los
usuarios, pro- cesos de negocio, y dispositivos de función suelen
ser complejas. Por extensión, por lo tanto, los requisitos de
software de par- ticular son típicamente una compleja
combinación de varias personas en diferentes niveles de una
organización, y que están en una u otra manera involucrados o
relacionados con esta función del entorno en el que el software
operará. Una propiedad esencial de todos los requisitos de
software es que sean verificables como una característica
individual como requisito funcional o a nivel del sistema como un
requisito no funcional. Puede ser difícil o costoso para verificar
ciertos requisitos de soft- ware. Por ejemplo, la verificación del
requisito de caudal en un centro de llamadas puede hacer
necesario el desarrollo de software de simulación. Requisitos de
software, ING Ensayos software y personal de calidad debe
asegurar que el
requisitos pueden ser verificados dentro de las limitaciones de recursos
disponibles.
Requisitos tienen otros atributos en adi- ción a las propiedades de
comportamiento. Los ejemplos más comunes incluyen una clasificación
de prioridad para permitir compensaciones en la cara de los recursos
finitos y un valor de estado para permitir el avance del proyecto a
vigilar. Tıpicamente, los requisitos de software son singularmente
identificadas con los de modo que puedan ser objeto de software de
gestión de con- figuración durante todo el ciclo de vida de la entidad y
del software.
1.2. Requisitos del producto y de proceso
Un requisito de un producto es una necesidad o restricción en el
software que se desarrollarán (por ejemplo, “El software verificará
que un estudiante cumple con todos los requisitos previos antes de
que él o ella se registre en un curso”). Un requisito proceso es
esencialmente un con- straint en el desarrollo del software (por
ejemplo, “El software se desarrolla utilizando un proceso RUP”).
Algunos de los requisitos de software generan los requisitos del
proceso implícitos. La elección de la verificación

técnica es un ejemplo. Otro podría ser el uso de técnicas de análisis
particularmente rigurosas (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, facilidad de mantenimiento
requisitos,
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 calidad en el KA Calidad del Software).
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, y, en su caso,
cuantitativamente. Es importante evitar los requisitos de
vagas y no verificables que
Requisitos de software 1-3
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
hardware, software, firmware,
las personas, los elementos de información, técnicas,
instalaciones, servicios, y otra de apoyo,
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 unos componentes de software del sistema que
contienen, software requisitos se derivan de requisitos del sistema.
Esta KA define “las necesidades del usuario” en forma restringida,
como los requisitos de los clientes del sis- tema o usuarios finales.
Los requisitos del sistema, por el contrario, abarcan necesidades de
los usuarios, los requisitos de otras partes interesadas (tales como
las autoridades miento de 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 software.
1-4 Guía SWEBOK® V3.0
2.1. Los modelos de proceso
El objetivo de este tema es el de proporcionar un entendimiento de
que el proceso de requisitos
• no es una actividad discreta front-end del ciclo de vida soft-
ware, sino más bien un 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 pro- ceso es
fundamentalmente interdisciplinario, y el especialista requisitos
necesita para mediar entre el dominio de la parte interesada y la de
ingeniería de soft- ware. 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 incluyen
(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 que han
encargado el software o que REPRESENTA mercado
objetivo del software.
• Los analistas de mercado: Un producto de mercado masivo no
tendrán un cliente puesta en marcha, por lo
la gente de marketing son a menudo necesarios para esta- blecer
las necesidades del mercado y para actuar como clientes de proxy.
• 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 particu- lar
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 particular-
mente, pueden tener un impacto importante en el precio o la
entrega del proyecto, ya sea porque se ajustan bien o mal con
el conjunto de habilidades de los ingenieros. ventajas y
desventajas importantes entre estos requisitos deben ser
identificados.
No será posible satisfacer perfectamente las necesidades de
todas las partes interesadas, y es el trabajo del ingeniero de software
para negociar compensaciones que sean aceptables para los
principales grupos de 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 prin- cipal es hacer que el vínculo entre las actividades
pro- ceso 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 calidad y la mejora
del proceso de requisitos. Su propósito es hacer hincapié en el
papel clave que desempeña el proceso de requerimientos en
términos de la

costo y puntualidad de un producto de software y de la satisfacción
del cliente con él. Esto ayudará a orientar el proceso de requisitos de
calidad con Dardos Están- y modelos de mejora de procesos para las
mercancías y los sistemas blandas. La calidad del proceso y la
mejora está estrechamente relacionado tanto a la calidad del
software y KA KA Proceso de Ingeniería de Software, que
comprende
• requisitos de cobertura proceso de normas y modelos
de mejora de procesos;
• requisitos las medidas de proceso y 3.1. requisitos Fuentes
la evaluación comparativa;
• planificación de la mejora e implementación;
• seguridad / mejora de la CIA / planificación y
ejecució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 los usuarios de software / titulares stake- e ingenieros de
software.
Un elemento crítico de la obtención de requisitos está informando
al alcance del proyecto. Esto implica proporcio- nando una
descripción del software que se especifica y su propósito y dar
prioridad a los entregables
Requisitos de software 1-5
para garantizar las necesidades de negocios más importantes del
cliente son las primeras en cubrirse. Esto minimiza el riesgo de
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.
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 fac- tor”) se refiere a los objeti-
vos 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. relacio- nes 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 políticas de la organización al cliente
central. El ingeniero de software tiene que identificar,
representar y administrar
1-6 Guía SWEBOK® V3.0
los “puntos de vista” de muchos tipos diferentes de grupos de
interés.
• Reglas del negocio. Estas son declaraciones que definen o
limitan algún aspecto de la estruc- tura o el comportamiento de
la 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 uni- versidad.
• El entorno operativo. Requisitos se derivan del entorno en
el que se ejecutará el programa. Estos pueden ser, por
ejemplo, las limitaciones de tiempo en las restricciones
del software o de rendimiento en tiempo real en un
entorno empresarial. Estos deben ser buscados
activamente, ya que pueden afectar en gran medida la
viabilidad y el costo de software así como restringir las
opciones de 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 iden- tificado, 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, incluso
si las cooperativas interesadas y articulados están disponibles, el
ingeniero de software tiene que trabajar duro para obtener la
información correcta. Muchos de los requisitos de negocio o técnicas
son tácito o en la retroalimentación que
aún no se ha obtenido a partir de los usuarios finales. La importancia
de la planificación, verificación y validación en la obtención de
requisitos no puede ser exagerada. Existe un número de técnicas para
los requisitos de elici- tación; las principales son las siguientes:
• 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 escena- rio 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 superficie utilizando entrevistas. Otra ventaja es
que los requisitos conflictivos superficie desde el principio en
una forma que permite a las partes interesadas reconocen
cuando éstos se producen. Cuando funciona bien, esta
técnica

puede resultar en un conjunto más rico y más coherente de los
requisitos que de otro modo podrían ser alcanzables. Sin
embargo, las reuniones deben ser manejados con cuidado (de ahí
la necesidad de un facilitador) para evitar una situación en la que
las habilidades críticas del equipo son erosionadas por la lealtad
al grupo, o en las que los requisitos que reflejan las
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 forma: “Como <función>, quiero <meta / deseo> de
manera que <beneficio>”. 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 determinar si se han cumplido
los objetivos de la historia de usuario.
• Otras técnicas. Una variedad de otras técnicas para el apoyo a
la obtención de información de los requisitos existen y van
desde el análisis de productos de la competencia para aplicar
los datos min-ing técnicas para el uso de fuentes de bases de
datos de conocimiento de dominio o petición del cliente.
Requisitos de software 1-7
Análisis 4. Requisitos
[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
soft- ware.
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.
1-8 Guía SWEBOK® V3.0
• La prioridad requisito. Cuanto mayor sea la priori- dad, más 4.2. Modelado conceptual
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
funda- mental 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 sección 7.3, Requisitos
de atributos).
 
El desarrollo de modelos de un problema del mundo real es clave
para el análi- sis requisitos 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 de Unified Modeling Language (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.
Tenga en cuenta que, en casi todos los casos, es útil comenzar la
construcción de un modelo del contexto del software. El contexto software
proporciona una conexión entre los programas informáticos destinados y
su entorno externo.

Esto es crucial para la comprensión de con- texto del software en su
entorno operativo y para que identifique los valores de sus interfaces
con el medio ambiente. Este subtema no busca “enseñar” a un estilo de
modelado particu- lar o anotación, sino más 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
respon- sable 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 componen- tes 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-
propiedades Gent (tales como el peso del coche) para identificar la
detallada requisitos de software ABS. El diseño arquitectónico está
estrechamente identificada con el modelado conceptual (ver sección
4.2, Modelado Conceptual).
Requisitos de software 1-9
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.
1-10 Guía SWEBOK® V3.0
4.5. Análisis formal
preocupaciones formales de análisis no sólo el tema 4, pero también
las secciones 5.3 y 6.3. En este tema también se relaciona con
métodos formales en los modelos de ingeniería de software y métodos
Área de Conocimiento. Análisis formal ha hecho un impacto en 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 general- mente
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 per- mite la validación estática que el software
especificado por los requisitos sí tiene las pro- piedades (por ejemplo,
ausencia de estancamiento) que el cliente, los usuarios, y el ingeniero
de software de esperar que tenga.
5. Requisitos Especificación
[1 *, c4s2, c4s3, c12s2-5] [2 *, c10]
Para la mayoría de las carreras de ingeniería, el término “memoria
descriptiva” se refiere a la asignación de valores numéricos o los límites a
los objetivos de diseño de un producto. En la ingeniería de software,
“especificación de requisitos de software” típicamente se refiere a la
producción de
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
este Relacionados Guía.
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 com- ponentes se especifican.
Estrictamente hablando, la especificación de los requisitos del
sistema es una actividad sistemas Engineer- ing y cae fuera del
alcance de este
Guía.

5.3. Especificación de Requerimientos de Software
especificación de requisitos de software establece la base para un
acuerdo entre los clientes y los contratistas o proveedores (en proyec-
tos impulsados ​por el mercado, estas funciones pueden ser jugados
por las divisiones de marketing y desarrollo) en lo que el producto de
software es a hacer, así como lo que no es espera que lo haga.
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 for- mal 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 software individuales son imperativos, directivas, frases
débiles, opciones y ANCES continuidades. Indicadores para todo el
documento de especificación de software exigencias incluyen el tamaño,
la capacidad de lectura, la especificación, la profundidad y la estructura
del texto.
Requisitos de software 1-11
6. Requisitos de Validación
[1 *, c4s6] [2 *, c13, 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 docu- ment 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, general- mente 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 orientación sobre lo que debe
buscar en la forma de listas de verificación.
1-12 Guía SWEBOK® V3.0
Los comentarios pueden ser constituidos en la finalización del
documento de definición del sistema, el documento de especificación del
sistema, el documento de especificación de 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 soft- ware 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 análisis. Por ejem plos, en modelos de
objetos, es útil para llevar a cabo un análisis estático para verificar la
existencia de rutas de comunicación entre los objetos que, en las
partes interesadas
dominio, el intercambio de datos. Si se utiliza el análisis formal notación
ciones, es posible 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 com- en 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
empre- sas se expanden, a medida que crece su base de clientes, y
como su producto comienza a evolucionar, descubren que necesitan
para recuperar los requisitos que

producto motivado cuenta con el fin de evaluar el impacto de los
cambios propuestos. Por lo tanto, la documentación y los requisitos
de gestión del cambio son la clave para el éxito de cualquier proceso
de requisitos.
7.1. La naturaleza iterativa del proceso Requisitos
Existe una presión general en el software de indus- tria 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 soft- ware. 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 con el diseño y la construcción de la iteración actual.
Este enfoque proporciona ERS adaptado para el cliente con el valor de
negocio de forma rápida, mientras minimizando ing el costo de reproceso.
En casi todos los casos, los requisitos de conocimiento sigue
evolucionando como el diseño y desarrollo
Requisitos de software 1-13
producto. Esto a menudo conduce a la revisión de los requisitos
finales del ciclo de vida. Tal vez el punto más crucial en la
comprensión de los requisitos de software es que una proporción
significativa de los requisitos será cambio. 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 pro- ceso 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-
ware en fase de desarrollo o mantenimiento evoluciona.
Esto debe incluir los diversos clasificación
1-14 Guía SWEBOK® V3.0
dimensiones de la exigencia (véase la sección 4.1, los requisitos de
clasificación) y el método de verificación o sección del plan de
prueba de aceptación correspondiente. También puede incluir
información adicional, como una justificación de resumen para cada
requisito, la fuente de cada requerimiento, y un historial de cambios.
Los requisitos más importantes atribuyen, SIN EMBARGO, es un
identificador que permite a los requisitos para ser identificadas de
manera única e inequívoca.
7.4. requisitos de rastreo
Requisitos de rastreo tiene que ver con objeto de reembolso ing
la fuente de los requisitos y la predicción de los efectos de los
requisitos. El rastreo es fundamental para la realización de
análisis de impacto cuando los requisitos cambian. Un requisito
debe ser trazable dadas vuelta a los requisitos y las partes
interesadas que la motivaron (de un requisito de software de
nuevo a la exigencia (s) del sistema que ayuda a satisfacer, por
ejemplo). Por el contrario, un requisito debe ser trazable hacia
adelante en los requisitos de diseño y entidades que lo satisfacen
(por ejemplo, de un requisito del sistema en los requisitos de
software que se han elaborado a partir de ella, y en en los
módulos de código que lo implementan, o la casos de prueba
relacionados con ese código, e incluso una sección dada en el
manual de usuario que describe la funcionalidad real) y en el
caso de prueba que verifica.
Los requisitos de seguimiento para un típico proyec- ect
formarán un complejo gráfico dirigido acíclico (DAG) (ver Gráficos
en el 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.
7.5. La medición de Requisitos
Como cuestión práctica, suele ser útil tener algún concepto de
“volumen” de las exigencias para un producto de software en
particular. Este número es útil para evaluar el “tamaño” de un
cambio en los requisitos, al estimar el costo de una tarea de
desarrollo o mantenimiento, o simplemente para su uso como
el denominador en otras mediciones. medida del tamaño
funcional (FSM) es una téc- nica para evaluar el tamaño de un
cuerpo de requisitos funcio- nales.
Información adicional sobre la medición y estándares de
tamaño se encuentra en el Proceso de Software niería Inge- KA.
8. Requisitos de software Herramientas
Herramientas para hacer frente a los requisitos de software se dividen
en dos categorías: herramientas para el modelado y herramientas para
la gestión de requisitos. herramientas de gestión de requisitos
normalmente el puerto SUP- una serie de actividades, incluyendo docu-
mentación, la localización, y la gestión del cambio y han tenido un
impacto significativo en la práctica. De hecho, ing trac- y la gestión del
cambio son realmente sólo prác- ticable si es compatible con una
herramienta. Desde la gestión de requisitos es fundamental para la
buena práctica de los requisitos, muchas organizaciones han invertido
en herramientas de gestión de requisitos, aunque muchos más manejar
sus requisitos en más ad hoc y generalmente menos satisfactorios
maneras (por ejemplo, utilizando hojas de cálculo).
 Requisitos de software 1-15

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Sommerville 2011

Wiegers 2003
[2 *]
[1 *]
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

1-16 Guía SWEBOK® V3.0

Sommerville 2011

Wiegers 2003
[2 *]
[1 *]
7. Consideraciones prácticas

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, El descubrimiento  A. van Lamsweerde, requisitos
requisitos [ 5].
Un libro de fácil digestión y de carácter práctico sobre los requisitos
de software, esto es quizás el mejor de los libros de texto actuales
sobre cómo los diferentes elementos de los requisitos de software
encajan entre sí. Está lleno de consejos prácticos sobre (por
ejemplo) la manera de identificar los distintos actores del sistema y
cómo evaluar soluciones alternativas. Su edad cubierta- es ejemplar
y sirve como una referencia útil para técnicas de clave, tales como
modelado de caso de uso y requisitos de priorización.
C. Potts, K. Takahashi, y A. Antón, “indagación Análisis
Requisitos Basado” [6].
Este documento es una cuenta de fácil digestión de trabajo que ha
demostrado ser muy influyente en el desa- rrollo de las necesidades
de manipulación. En él se describe cómo y por qué la elaboración
de requisitos no puede ser un proceso lineal por el cual el analista
simplemente transcribe y reformula requisitos provocadas por parte
del cliente. El papel de los escenarios se describe de una manera
que ayuda a definir su uso en el descubrimiento y la descripción de
los requisitos.
Requisitos de software 1-17
 
Ingeniería: A partir de los objetivos del sistema de modelos UML
a las especificaciones de software [ 7].
Sirve como una buena introducción a la ingeniería de requisitos,
pero su valor único es como un libro de referencia para los
requisitos orientados a objetivos lenguaje de modelado de KAOS.
Explica por qué el modelado meta es útil y muestra cómo se puede
integrar con técnicas de modelado convencionales usando UML.
O. Gotel y A. Finkelstein, “Un análisis del problema
Requisitos trazabilidad” [8].
Este trabajo es una obra de referencia clásica en un elemento
clave de la gestión de requisitos. Basándose en estudios
empíricos, establece las razones y las barreras para el rastreo
eficaz de los requisitos. Es una lectura esencial para la
comprensión de por qué los requisitos de rastreo es un elemento
esencial de un proceso de software efectivo.
N. Maiden y C. Ncube, “La adquisición de COTS Requisitos
de selección de software” [9].
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.
1-18 Guía SWEBOK® V3.0

Referencias

[1 *] I. Sommerville, Ingeniería de software, noveno [6] C. Potts, K. Takahashi, y AI Antón,

ed., Addison-Wesley, 2011. “Requisitos basada en la indagación Análisis,”
IEEE Software, vol. 11, no. 2, marzo 1994, pp. 21-32.
[2 *] KE Wiegers, Requisitos de Software, segundo
ed., Microsoft Press, 2003.
[7] A. van Lamsweerde, requisitos 
[3] INCOSE, Sistemas Manual de Ingeniería:  Ingeniería: A partir de los objetivos del sistema de modelos UML
Una guía para los procesos y actividades del ciclo de vida del a Especificaciones de software, Wiley,
sistema, la versión 3.2.2, Consejo Internacional de Ingeniería 2009.
de Sistemas, 2012.
[8] O. Gotel y CW Finkelstein, “An Analysis
[4] S. Friedenthal, A. Moore, y R. Steiner, UN  Problema de la Trazabilidad de Requisitos”
Guía Práctica de SysML: El sysml, 2ª ed., Proc. Primero Int'l Conf. Requisitos Eng.,
Morgan Kaufmann, 2012. IEEE, 1994.

[9] NA Maiden y C. Ncube, “La adquisición

[5] I. Alexander y L. Beus-Deukic, Requisitos de selección de software COTS,”
El descubrimiento Requisitos: Cómo especificar los IEEE Software, vol. 15, no. 2, marzo-abril.
productos y servicios, Wiley, 2009. 1998, pp. 46-56.
 CAPITULO 2
DISEÑO DE SOFTWARE
SIGLAS
Arquitectura lenguaje de
ADL
descripción de CDB
Diseño basado en componentes CRC
Responsabilidad clase Colaborador DFD
Diagrama de flujo de datos
ERD Diagrama entidad-relación IDL
Interfaz de lenguaje de descripción de
MVC Modelo Vista Controlador OO
PDL orientada a objetos
Programa de Lenguaje de Diseño
INTRODUCCIÓN
Diseño se define como tanto “el proceso de defin- ing la
arquitectura, componentes, interfaces y otras características de
un sistema o componente” y “el resultado del proceso [que]” [1].
Visto como un proceso, diseño de software es el ing la actividad
del ciclo de vida del software en el que Engineer- mentos de
software requisito se analizan con el fin de producir una
descripción de la estructura interna del software que va a servir
de base para su construcción. Un diseño de software (el
resultado) describe el software de archi- tecture, es decir, cómo
se descompone software y organizado en componentes-y las
caras interrelaciones entre esos componentes. También debe
describir los componentes a un nivel de detalle que permite su
construcción.
El diseño de software juega un papel importante en el
desarrollo de software: durante el diseño de software,
ingenieros de software producen varios modelos que forman
una especie de anteproyecto de la solución a implementar.
Podemos analizar y evaluar estos modelos para determinar si
son o no nos permitirán cumplir con los diversos requisitos.
2-1
También podemos examinar y evaluar soluciones alternativas y
compensaciones. Finalmente, podemos utilizar los modelos resultantes
para planificar actividades de desarrollo posteriores, como la verificación
del sistema y ción validación, además de su uso como entradas y como
el punto de partida de la construcción y prueba. En una lista estándar de
pro- cesos de ciclo de vida del software, tales como que en la norma ISO
/ IEC / IEEE Std. 12207,
Procesos del ciclo de vida del software [ 2], diseño de software consiste en
dos actividades que se ajustan entre el análisis de los requisitos de
software y la construcción de software:
• diseño de la arquitectura de software (a veces llamado
diseño de alto nivel): desarrolla la estructura de alto nivel y
organización del software y se identifican los distintos
componentes.
• Software de diseño detallado: especifica cada componente
en suficiente detalle para facilitar su construcción.
Esta área de conocimiento Diseño de Software (KA) no habla
de todos los temas que incluye la palabra “diseño”. En la
terminología de Tom DeMarco [3], los temas tratados en este
acuerdo KA principalmente con D-diseño (diseño de
descomposición), cuyo objetivo es el mapeo de software en piezas
componentes. Sin embargo, debido a su importancia en el campo
de la arquitectura de software, también vamos a tratar FP-diseño
(diseño del patrón de la familia), cuyo objetivo es establecer
aspectos comunes explotables en una familia de productos de
software. Esta KA no se ocupa de la I-diseño (diseño invención),
que se realiza generalmente durante el proceso de requisitos de
software con el objetivo de alizing conceptualización y la
especificación de software para satisfacer las necesidades y
requerimientos descu- Ered, ya que este tema es considerado
como parte de el proceso de requisitos (ver los requisitos de
software KA). Este software de diseño KA se relaciona
específicamente a un los requisitos de software, Software
2-2 Guía SWEBOK® V3.0

Figura 2.1. Desglose de temas para el Software de Diseño KA

Construcción, Ingeniería de Software Ment Manage-, modelos
de ingeniería de software y met- ods, Calidad de Software y
Computación Fundaciones ciones de Kas.
DISTRIBUCIÓN DE TEMAS PARA EL DISEÑO
DEL SOFTWARE
El desglose de temas para el Software de Diseño KA se muestra
en la Figura 2.1.
1. Fundamentos del Diseño de Software
La conceptos, nociones, y la terminología intro- ducido aquí
forman una base subyacente para la sub pie el papel y el
alcance de diseño de software.
1.1. Conceptos generales de diseño
[4 *, c1]
En sentido general, el diseño puede ser visto como una forma de
resolución de problemas. Por ejemplo, el con- cepto de una
solución de un problema complejo sin solución definitiva, es
la comprensión de los límites del diseño. Un número de otras nociones y
conceptos También son de interés en la comprensión del diseño en su
sentido general: objetivos, las limitaciones, las alternativas, las
representaciones y las soluciones (véase el problema técnicas de
resolución en los Fundamentos de Informática KA).
1.2. Contexto de Diseño de Software
[4 *, c3]
El diseño de software es una parte importante del proceso de
desarrollo de soft- ware. Para entender el papel del diseño de
software, tenemos que ver cómo se integra en el ciclo de vida del
software de desarrollo. Por lo tanto, es importante comprender las
principales caracterís- ticas de análisis de requisitos de software,
diseño de software, la construcción de software, pruebas de software,
y el mantenimiento del software.
1.3. Software de Diseño de Procesos
[4 *, c2]
El diseño del software es generalmente considerado como un proceso de

interesante en términos de dos pasos:


• Diseño arquitectonico (También conocido como el diseño de alto
nivel de diseño y de nivel superior) describe cómo el software está
organizado en componentes.
• El diseño detallado se describe el comporta- miento deseado de
estos componentes.
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 fundamen- tal 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 prin- cipios 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
programa de ordenador”, mientras que la cohesión se define
como “una medida de la fuerza de la asociación de los
elementos dentro de un módulo” [1].
• La descomposición y la modularización. posando descomposición y
la modularización significa que grandes
Diseño de Software 2-3
el software se divide en una serie de componentes nombrados
más pequeños que tienen interfaces bien definidas que describen
las interacciones de los componentes. Por lo general, el objetivo
es 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 7, Software de Diseño Estrategias y Métodos).
Por el contrario, otras cuestiones “trato con algún aspecto del
comportamiento del software que no está en el dominio de la
aplicación, pero que aborda algunas de las apoyando
2-4 Guía SWEBOK® V3.0
dominios”[10]. Estas cuestiones, que a menudo crosscut la
funcionalidad del sistema, se han referido como aspectos, que
“tienden a no ser unidades de descomposición funcional de soft-
ware, sino más bien a ser propiedades que afectan al
rendimiento o tics seman- de los componentes en formas
sistémicas” [11]. Varias de estas cuestiones clave, transversales
se tratan en las secciones siguientes (presentados en orden
alfabético).
2.1. concurrencia
[5 *, c18]
Diseño para la concurrencia tiene que ver con el software de presentación
descomposición en los procesos, tareas y discusiones y hacer frente a
cuestiones relacionadas con la eficiencia, la atomicidad, sincronización y
programación.
2.2. Control y manejo de Eventos
[5 *, c21]
Este problema de diseño se ocupa de la forma de organizar los datos y
flujo de control, así como la forma de manejar los eventos reactivos y
temporales a través de diversos mecanismos como la invocación
implícita y devoluciones de llamadas.
2.3. Persistencia de datos 
[12 *, c9]
Este problema de diseño se ocupa de cómo se manipulan de datos de
larga vida dle.
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]
Este problema de diseño se ocupa de la forma de pre- ventilación,
tolerar, y los errores de proceso y hacer frente a condiciones
excepcionales.
2.6. Interacción y Presentación 
[5 *, c16]
Este problema de diseño se ocupa de cómo es- tructura y organizar las
interacciones con los usuarios, así como la presentación de información
(por ejemplo, la separación de presentación y la lógica de negocio
utilizando el enfoque del Modelo-Vista-Controlador). Tenga en cuenta
que este tema no especifica detalles de la interfaz de usuario, que es la
tarea de diseño de la interfaz de usuario (véase el tema 4, diseño de
interfaz de usuario).
2.7. Seguridad
[5 *, c12, c18] [13 *, c4]
Diseño para la seguridad tiene que ver con la forma de pre ventilar la
divulgación no autorizada, creación, cambio, supresión o negación del
acceso a la información y otros recursos. También tiene que ver con la
forma en que tolerar ataques o violaciónes relacionadas con la seguridad
mediante la limitación de daños, funcionamiento continuo, acelerar la
reparación y recuperación, y en su defecto y recuperar de forma segura.
El control de acceso es un con- cepto fundamental de la seguridad, y
también se debe garantizar el buen uso de la criptografía.
3. Estructura del software y Arquitectura
En su sentido más estricto, una arquitectura de 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 nive- les 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 vista
[14 *, c1]
Las diferentes facetas de alto nivel de un diseño de software pueden ser
descritos y documentados. Estas facetas son a menudo llamados puntos
de vista: “Una vista representa un aspecto parcial de una arquitectura de
software que muestra propiedades especí- espe- de un sistema de
software” [14 *]. Vistas pertenecen a distintos temas relacionados con el
software de diseño, por ejemplo, la vista lógica (satisfaciendo los
requisitos funcionales) frente a la vista de procesos (problemas de
concurrencia) frente a la vista física (problemas de distribu- ción) frente a
la vista de desarrollo (como el el diseño se divide en unidades de
ejecución con representación explícita de las dependencias entre las
unidades). Varios autores utilizan diferentes terminologías-como frente a
la conducta funcional vs. vistas de modelado de datos vs. estructurales.
En resumen, un diseño de software es un artefacto multifacético
producido por el proceso de diseño y generalmente compuesta de
puntos de vista relativamente independientes y ortogonales.
3.2. Estilos arquitectónicos [ 14 *, c1, c2, c3, c4, c5]
Un estilo arquitectónico es “una especialización de tipos Ment y
relación ele-, junto con un conjunto de restricciones sobre la forma en
que se pueden utilizar” [14 *]. Un estilo arquitectónico de este modo
puede ser visto como para simplificar la organización de alto nivel del
software. Varios autores han identificado una serie de grandes estilos
tectural arqui-:
• Las estructuras generales (por ejemplo, capas, tuberías y
filtros, pizarra)
• Los sistemas distribuidos (por ejemplo, cliente-servidor, tres
niveles, broker)
• Los sistemas interactivos (por ejemplo, Model-View-
Controller, Presentación-Abstracción-Control)
• sistemas adaptables (por ejemplo, nel microker-,
reflexión)
• Otros (por ejemplo, por lotes, intérpretes, control pro- ceso,
basado en reglas).
3.3. Patrones de diseño
[15 *, c3, c4, c5]
Sucintamente descrito, un patrón es “una solución común a un
problema común en un contexto dado” [16]. Mientras que los estilos
arquitectónicos pueden ser vistos como
Diseño de Software 2-5
patrones que describen la organización de alto nivel de software,
otros patrones de diseño se pueden utilizar para describir los
detalles en un nivel inferior. Estos patrones de diseño de bajo nivel
son los siguientes:
• patrones de creación (por ejemplo, constructor, fábrica,
prototipo, Singleton)
• patrones estructurales (por ejemplo, adaptador, puente,
compuesto, decorador, fachada, peso FLY-, Proxy)
• Los patrones de comportamiento (por ejemplo, comandos,
intérprete, iterador, mediador, recuerdo,
observador, estado, estrategia, plantilla, visitante).
3.4. Las decisiones Arquitectura Diseño
[5 *, c6]
El diseño arquitectónico es un proceso creativo. Duran- te el proceso de
diseño, los diseñadores de software tienen que tomar una serie de
decisiones fundamentales que afectan profundamente el proceso de
desa- rrollo de software y. Es útil pensar en el proceso de diseño arqui-
tectural desde una perspectiva de toma de decisiones en lugar de
desde una perspectiva actividad. A menudo, el impacto sobre los
atributos de calidad y soluciones de compromiso entre los atributos de
calidad que compiten son la base para las decisiones de diseño.
3.5. Las familias de los programas y marcos 
[5 *, C6, C7, C16]
Un enfoque para proporcionar la reutilización de diseños y componentes
de software es el diseño de las familias de programas, también conocidas
como líneas de productos de software. Esto se puede hacer mediante la
identificación de los puntos en común entre los miembros de estas familias
y mediante el diseño de componentes reutilizables y personalizables para
dar cuenta de la variabilidad entre los miembros de la familia. En la
programación orientada a objetos (OO), una noción relacionada clave es
que de un marco: un sistema de software parcialmente completado que
puede ser extendido por instanciar apropiadamente extensiones
específicas (tales como plug-ins).
4. Diseño de Interfaz de Usuario
diseño de la interfaz de usuario es una parte esencial del proceso de
diseño de software. diseño de interfaz de usuario debe asegurarse de
que la interacción entre el humano y la máquina proporciona para un
funcionamiento eficaz
2-6 Guía SWEBOK® V3.0
y el control de la máquina. Para el software para alcanzar su pleno
potencial, la interfaz de usuario debe ser diseñado para que coincida
con las habilidades, experiencia y expectativas de sus usuarios
previstos.
4.1. Principios generales para el usuario el 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 tra- baja 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 usuario. 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 interacción del
usuario y presentación de la información. diseño de interfaz de
usuario debe considerar un compromiso entre los estilos más
apropiados de interacción
1 Capítulo 29 es un capítulo basado en la web disponible en http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
WebChapters / .
y la presentación del software, los antecedentes y la experiencia
de los usuarios de software y los dispositivos disponibles.
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 siguien- tes:
• 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 soft- ware.
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 sí misma. El enfoque MVC
(Modelo-Vista-Controlador) es una forma efectiva de mantener la
presentación de información se separe de la información que se
presenta.

Los ingenieros de software también tienen en cuenta el tiempo de
respuesta del software y la retroalimentación en el diseño de presentación
de infor- mación. El tiempo de respuesta se mide generalmente desde el
punto en el que un usuario ejecuta una cierta acción de control hasta que
el software responde con una respuesta. Una indicación del progreso es
deseable poder mientras que el software está preparando la respuesta. La
retroalimentación puede ser 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 estado de soft-
ware.
• Use códigos de colores para apoyar la tarea del usuario.
• Use códigos de colores de una manera reflexiva y consis- 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 soft- ware. Este
proceso incluye tres actividades principales:
• análisis usuario. En esta fase, el diseñador ana- lyzes tareas de
los usuarios, la ment ENTORNO trabajo, otro software, y cómo
los usuarios interactúan con otras personas.
• creación de prototipos de software. El desarrollo de prototipos de
software ayudan a los usuarios a guiar la evolución de la interfaz.
• evaluación de la interfaz. Los diseñadores pueden observar las
experiencias de los usuarios con la interfaz de evolución.
Diseño de Software 2-7
4.6. Localización e internacionalización
[17 *, c8, c9]
diseño de interfaz de usuario a menudo necesita considerar la
internacionalización y localización, que son medios para adaptar el
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 soft- ware internacionalizado para una región o idioma mediante
la adición de componentes específicos de localización y traducción
del 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 ejem- plo, 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. Análisis de Calidad de Software de Diseño y
Evaluación
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 diseño de software,
incluyendo varios “-ilities” (mantenibilidad, portabilidad, capacidad de
prueba, la facilidad de uso)
2-8 Guía SWEBOK® V3.0
y “-nesses” (exactitud, robustez). Hay una interesante distinción
entre la calidad buye atri- discernibles en tiempo de ejecución (por
ejemplo, per- formance, seguridad, disponibilidad, funcionalidad,
facilidad de uso), los que no discernible en tiempo de ejecución (por
ejemplo, modificabilidad, portabilidad, reusabilidad, la capacidad de
prueba), y aquellos relacionada con las cualidades intrínsecas de la
arquitectura (por ejemplo, conceptual integri- dad, 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, la arquitectura comentarios, revisiones de diseño,
e inspecciones técnicas basadas en escenarios;
requisitos
rastreo). las revisiones de diseño de software también pueden
evaluar la seguridad. Ayudas para la instalación, fun- cionamiento, 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 los modelos de ingeniería de software y métodos KA).
• Simulación y prototipado: técnicas dinámicas para
evaluar un diseño (por ejemplo, la simulación de
rendimiento o factibilidad
prototipos).
5.3. medidas
[4 *, c4] [5 *, c24]
Las medidas pueden ser utilizados para evaluar 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 fun- cional de descomposición;
generalmente representado mediante un diagrama de estructura
(a veces llamado un diagrama jerárquico) sobre la que se pueden
calcular diversas medi- das.
• 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. Diseño de Software notaciones
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 soft- ware.
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

utilizan para describir los componentes principales y la forma en que están
interconectados (visión estática):
• Descripción de la arquitectura idiomas (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 .
• Clase tarjetas responsabilidad colaboradores (CRC): se
utiliza para denotar los nombres de los componentes (clase), sus
responsabilidades, y los nombres de sus componentes que
colaboran.
• 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 otra
parte, las descripciones del comportamiento pueden incluir una
justificación de la decisión de diseño tales como la forma de un diseño
cumplirá con los requisitos de seguridad.
Diseño de Software 2-9
• diagramas de actividad: se utiliza para 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 proce- dimiento o método.
2-10 Guía SWEBOK® V3.0
7. Diseño de Software estrategias y métodos
Existen varias estrategias generales para ayudar a guiar el proceso de
diseño. En contraste con las estrategias generales, los métodos son
más específicos en cuanto a que proporcionan generalmente un
conjunto de notaciones para ser utilizado con el método, una
descripción del proceso que se utilizará cuando se sigue el método, y
un conjunto de directrices para el uso del método. Tales métodos son
útiles como un marco común para los equipos de ingenieros de
software. (Ver también los modelos niería de Software Engineers y
Métodos KA).
7.1. Estrategias generales [ 4 *, c8, c9, c10] [12 *, c7]
Algunos ejemplos citados con frecuencia de las estrategias generales
útiles en el proceso de diseño incluyen las estrategias de dividir-y-vencerás
y refinamiento paso a paso, de arriba hacia abajo frente a las estrategias
de abajo hacia arriba, y las estrategias que hacen uso de la heurística, el
uso de patrones y lenguajes tern PAT- y el uso de un enfoque iterativo y
mentales incre-.
7.2. Función-Oriented (Estructurado) Diseño
[4 *, c13]
Este es uno de los métodos clásicos de diseño de software, donde los
centros de descomposición en que identifique los valores las principales
funciones del software y luego elab- perorando y refinarlos en una de
arriba hacia abajo de forma jerárquica. Diseño estructurado se utiliza
generalmente después de un análisis estructurado, produciendo de este
modo (entre otras cosas) diagramas de flujo de datos y descripciones de
procesos asociados. Los investigadores han propuesto diversas
estrategias (por ejemplo, el análisis de la transformación, análisis de
transacciones) y heurística (por ejemplo, fan-in / fan-out, el alcance de
efecto vs. alcance de control) para transformar un DFD en una arquitectura
de software en general representado como una diagrama de estructura.
7.3. Diseño Orientado a Objetos
[4 *, c16]
Se han propuesto numerosos métodos de diseño de software
basados ​en objetos. El campo ha evolucionado a partir de la
orientada a objetos temprano (OO)
diseño de mediados de 1980 (sustantivo = objeto; verbo = método;
adjetivo = atributo), donde heren- cia y el polimorfismo juegan un papel
clave, al campo del diseño basado en componentes, donde la formación
de metain- se puede definir y se accede ( a través de la reflexión, por
ejemplo). Aunque las raíces del diseño orientado a objetos provienen
del concepto de abstracción de datos, diseño impulsado por la
responsabilidad ha sido propuesta como un enfoque alternativo al
diseño orientado a objetos.
7.4. Estructura centrada en los datos de diseño [ 4 *, c14, c15]
estructura centrada en los datos de diseño comienza a partir de las
estructuras de datos de un programa manipula más que de la función que
realiza. El ingeniero de software se describen en primer lugar las
estructuras de datos de entrada y salida y luego se desarrolla la estructura
de control del programa en base a estos diagramas de estructura de
datos. Se han propuesto varias heurísticas para hacer frente a ejemplo
especial casos-para, cuando hay una falta de coincidencia entre las
estructuras de entrada y salida.
7.5. Diseño basado en componentes (CDB)
[4 *, c17]
Un componente de software es una unidad independiente, que tiene
interfaces bien definidas y dependen- cias que pueden estar
compuestos y desplegado de forma independiente. aborda cuestiones
de diseño basadas en componentes relacionados con la prestación, el
desarrollo y la integración de estos componentes con el fin de mejorar
la reutilización. Reutilizados y off-the-shelf software com- ponentes
deben cumplir mentos el mismo requisito de seguridad como un nuevo
software. gestión de la confianza es un problema de diseño;
componentes tratados como hav- ing un cierto grado de confiabilidad
no debe depender de componentes o servicios sean menos fiables.
7.6. Otros metodos
[5 *, c19, c21]
También existen otros enfoques interesantes (ver los
modelos de ingeniería de software y métodos KA). Los
métodos iterativos y adaptativas Imple- incrementos de
software Ment y reducir énfasis en el requisito de software
rigurosa y diseño .

diseño orientada a aspectos es un método por el cual el software se
construye utilizando los aspectos a las aplicará las preocupaciones
transversales y extensiones que se identifican durante el proceso de
los requisitos software. arquitectura orientada a servicios es una
manera de construir software distribuido mediante servicios web
ejecutados en ordenadores distribuidos. sistemas de soft- ware se
construyen a menudo mediante el uso de servi- cios de diferentes
proveedores porque protocolos estándar (tales como HTTP, HTTPS,
SOAP) se han diseñado para soportar la comunicación de servicios y
el intercambio de información de servicio.
Diseño de Software 2-11
8. Herramientas de diseño de software [ 14 *, c10, Apéndice A]
Las herramientas de diseño de software se puede utilizar para apoyar la
creación de los artefactos de diseño de software durante el proceso de
desarrollo de software. Pueden apo- parte portuaria o la totalidad de las
siguientes actividades:
• traducir el modelo de requisitos en una representación
de diseño;
• para proporcionar soporte para la representación de los
componentes funcio- nales y su interfaz (s);
• para implementar la heurística refinamiento y la
partición;
• proporcionar directrices para la evaluación de la calidad.
2-12 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Página-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12 *]

[13 *]

[15*]

[17 *]
[14 *]
[5 *]
[4 *]

[6 *]
1. Fundamentos del Diseño
de Software

1.1. Conceptos generales de

c1
diseño

1.2. El contexto de Diseño

c3
de Software

1.3. El Proceso de Diseño

c2
de Software

1.4. Principios de Diseño de C6, C7, C1, C8,

c1
Software C21 C9

2. Cuestiones clave en

el diseño de software

2.1. concurrencia c18

2.2. Control y manejo

c21
de Eventos
2.3. Persistencia de datos C9

2.4. Distribución de
c18
Componentes

2.5. Error y control de

excepciones y la tolerancia c18
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

arquitectónicas y puntos c1
de vista

c1, c2,
3.2. Estilos
c3, c4,
arquitectónicos
c5

c3, c4, c5
3.3. Patrones de diseño
 Diseño de Software 2-13

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Página-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12 *]

[13 *]

[15*]

[17 *]
[14 *]
[5 *]
[4 *]

[6 *]
3.4. Las decisiones
c6
Arquitectura Diseño

3.5. Las familias de

C6, C7,
los programas y
C16
marcos

4. Diseño de Interfaz de

Usuario

4.1. General de la interfaz

web
de usuario Principio de c2
c29-
Diseño

4.2. Interfaz de usuario web

Problemas Diseño c29-

4.3. El diseño de las

web
modalidades de interacción
c29-
del usuario

4.4. El diseño de la
web
información
c29-
Presentación

4.5. Proceso de Interfaz de web

usuario Diseño c29-

4.6. Localización e
C8, C9
internacionalización

4.7. Metáforas y
c5
modelos conceptuales

5. Análisis de Calidad de
Software de Diseño y
Evaluación

5.1. Los atributos

c4
de calidad

5.2. Análisis de
calidad y
c4 c24
técnicas de
evaluación

5.3. medidas c4 c24

2-14 Guía SWEBOK® V3.0

Clements et al. 2010

Gamma et al. 1994

Sommerville 2011

Brookshear 2008
Página-Jones 1999
Budgen 2003

Nielsen 1993
Allen 2008
[12 *]

[13 *]

[15*]

[17 *]
[14 *]
[5 *]
[4 *]

[6 *]
6. Diseño de Software
notaciones

6.1. Las descripciones

estructurales (estático Vista) c7 C6, C7 c4, c5, c7 c7

C6, C7

6.2. Las descripciones

C7, C13,
de comportamiento C6, C7 c4, c5, c8
C18 C6, C7
(vista dinámica)

7. Diseño de Software
estrategias y métodos

7.1. Las C8, C9,

c7
estrategias generales C10

7.2. Orientada
automático- c13
(Estructurado) Diseño

7.3. Diseño Orientado a

c16
Objetos

7.4. Estructura-datos de c14,

diseño centrado en el c15

7.5. Diseño basado

c17
Componente- (CDB)

c19,
7.6. Otros metodos
c21

8. Herramientas de diseño c10,

de software App. UN

LECTURAS
Roger Pressman, Ingeniería de Software: Un  [1] ISO / IEC / IEEE 24765: 2010 Sistemas y
Enfoque del practicante (séptima edición)  Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
[19].
Por cerca de tres décadas, Roger Pressman de
Ingeniería de Software: 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 comple-
mentarios 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, se utilizan
casos o escenarios de uso seleccionadas 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 mejores libros disponibles
en la actualidad en la arquitectura de software.
Diseño de Software 2-15
Referencias
 
2010.
[2] IEEE Std. 12207-2008 (también conocido como ISO / IEC 
12207: 2008) Estándar de Sistemas y Software de
Ingeniería de Software-procesos de ciclo de vida, IEEE
2008.
[3] T. DeMarco, “The Paradox de Software
Arquitectura y diseño,”Conferencia Premio Stevens,
1999.
[4 *] D. Budgen, Diseño de software, 2ª ed.,
Addison-Wesley, 2003.
[5 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[6 *] M. Página-Jones, Fundamentos de objeto-
Diseño orientado en UML, 1ª ed., Addison-Wesley,
1999.
[7] Diccionario Colegiado de Merriam-Webster,
ed 11., 2003.
[8] IEEE Std. 1069-2009 estándar para 
Tecnología de la Información-Sistemas-Diseño de Software
Las descripciones de diseño,
IEEE 2009.
[9] ISO / IEC 42010: 2011 Sistemas y Software 
Ingeniería-Práctica Recomendada 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., “Orientado a Aspectos
Programación," Proc. Conf Europea 11. Programación
orientada a objetos ( ECOOP
97), Springer, 1997.
2-16 Guía SWEBOK® V3.0

[12 *] JG Brookshear, Ciencias de la Computación: Un  [17 *] J. Nielsen, Ingeniería de la Usabilidad, Morgan
Visión de conjunto, 10ª ed., Addison-Wesley, 2008. Kaufmann, 1993.

[13 *] JH Allen et al., software de Seguridad  [18] G. Booch, J. Rumbaugh, y I. Jacobson,

Ingeniería: Guía para los gerentes de La Guía de Lenguaje de Modelado Unificado usuario,
proyecto, Addison-Wesley, 2008. Addison-Wesley, 1999.

[14 *] P. Clements et al., Software de documentación  [19] RS Pressman, Ingeniería de Software: Un 
Vistas: arquitecturas y más allá, 2ª ed., Pearson Enfoque del practicante, 7ª ed., McGraw-Hill, 2010.
Education, 2010.

[15 *] E. Gamma et al., Patrones de diseño:  [20] PB Kruchten, “The 4 + 1 View Modelo de
Elementos de software reutilizables orientada a Arquitectura," IEEE Software, vol. 12, no.
objetos, 1ª ed., Addison-Wesley Professional, 1994. 6, 1995, pp. 42-55.

[21] L. Bass, P. Clements, y R. Kazman,

[16] I. Jacobson, G. Booch, y J. Rumbaugh, Arquitectura de software en la práctica, 3ª ed.,
El proceso de desarrollo de software unificado, Addison-Wesley Addison-Wesley Professional, 2013.
Professional,
1999.
 CAPÍTULO 3

CONSTRUCCIÓN DEL SOFTWARE

SIGLAS Por lo tanto, la construcción del software KA está estrechamente

vinculada a la Prueba de Software KA también. construcción de software
Interfaz de programación de
API normalmente produce el mayor número de elementos de configuración
aplicaciones COTS que necesitan ser administrados en un proyecto de software (archivos de
Off-the-shelf GUI comercial código fuente, documentación, casos de prueba, y así sucesivamente).

IDE Interfaz Gráfica de Usuario Por lo tanto, la construcción del software KA también está estrechamente
ligada a la Gestión de la Configuración de Software KA. Mientras que la
Entorno de desarrollo
calidad del software es importante en todos los Kas, código es la entrega
integrado
definitiva de un proyecto de software, y por lo tanto la calidad del software
OMG de administración de grupos POSIX
KA está estrechamente ligada a la construcción del software KA. Desde
Portable Operating System Object la construcción de software requiere el conocimiento de algoritmos y de
interfaz las prácticas de codificación, que está estrechamente relacionado con las

TDD UML desarrollo basado en pruebas fundaciones Informática KA, que se ocupa de la informática fundaciones
ciones que apoyan el diseño y construcción de productos de software.
Lenguaje de Modelado Unificado
También está relacionada con la gestión de proyectos, en la medida en la
gestión de cons- trucción puede presentar retos considerables.
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. DISTRIBUCIÓN DE TEMAS PARA LA
El área de conocimiento Construcción de Software (KA) está CONSTRUCCIÓN DEL SOFTWARE
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 La figura 3.1 muestra una representación gráfica de la
el proceso de construcción de software consiste en el diseño de software descomposición de nivel superior de la avería para la Construcción
y pruebas significativa. El proceso utiliza la salida de diseño y de Software KA.
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 1. Fundamentos de construcción de software
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. fundamentos de construcción de software incluyen

• minimizando la complejidad
Aunque algunos de diseño detallado se puede realizar antes de la • anticipar el cambio
construcción, tanto el trabajo de diseño se realiza durante la actividad • la construcción para la verificación
de construcción. Por lo tanto, la construcción del software KA está • reutilización

estrechamente vinculado con el software de diseño KA. • normas de construcción.

A lo largo de la construcción, tanto los ingenieros de software de Los primeros cuatro conceptos se aplican al diseño, así como a la
prueba de unidad e integración a prueba su trabajo. construcción. Las siguientes secciones definen

3-1
3-2 Guía SWEBOK® V3.0

Figura 3.1. Desglose de temas para la Construcción de Software KA


estos conceptos y describen cómo se aplican a la construcción.
1.1. Complejidad minimizando
[1 *]
La mayoría de las personas están limitadas en su capacidad de mantener
estructuras complejas e información en sus memorias de trabajo,
especialmente durante un período largo, de tiempo. Esto demuestra ser un
factor importante que influye en cómo las personas transmiten intención
de com- putadoras y conduce a una de las unidades más fuertes en la
construcción de software: minimizando compleji- dad. La necesidad de
reducir la complejidad se aplica esencialmente a todos los aspectos de la
construcción de software y es particularmente crítico para las pruebas de
las construcciones de software.
En la construcción de software, complejidad reducida se logra
a través enfatizando la creación de código que es simple y fácil
de leer en lugar de inteligente. Esto se logra a través de hacer
uso de las normas (véase la sección 1.5, Normas de
Construcción), el diseño modular (ver sección 3.1, Diseño
Construcción), y otras numerosas técnicas específicas (ver
sección 3.3, Coding). También es apoyado por técnicas de
calidad centrado con la construcción (ver sec- ción 3.7,
Construcción de Calidad).
1.2. pronóstico del cambio 
[1 *]
La mayoría del software va a cambiar con el tiempo, y la anticipación
de cambio impulsa muchos aspectos de la construcción de software;
los cambios en los entornos en los que opera el software también
afectan al software de diversas maneras.
Anticipar el cambio ayuda a los ingenieros de software construir
software extensible, lo que significa que pueden mejorar un
producto de software sin interrumpir la estructura subyacente.
cambio Anticipando es apoyado por muchas técnicas especí-
espe- (véase la sección 3.3, Coding).
1.3. La construcción de Verificación
[1 *]
La construcción de medios de verificación de construcción de software de
tal manera que los fallos pueden ser lectura ily encontrados por los
ingenieros de software de escritura del software, así como por los
probadores y usuarios durante
Construcción de Software 3-3
pruebas independientes y las actividades operacionales. Las técnicas
específicas que apoyan la construcción para la verificación incluyen
siguiendo los estándares de codificación para apoyar las revisiones de
código y pruebas de unidad, la organización de código para apoyar
pruebas automatizadas, y restrict- ing el uso de estructuras len- guaje
complejas o difíciles de comprender, entre otros.
1.4. Reutilizar
[2 *]
Reutilización refiere al uso de los activos existentes en la solución de
diferentes problemas. En la construcción de software, los activos ical
typ- que se reutilizan incluyen bibliotecas, módu-, componentes, código
fuente, y off-the-shelf comercial (COTS) activos. La reutilización es mejor
ticas ticed sistemáticamente, de acuerdo con un proceso bien definido y
repetible. reutilización sistemática puede permitir significativo de la
productividad de software, la calidad y mejora de los costes.
Reutilización tiene dos facetas estrechamente relacionados: “la
construcción para la reutilización” y “reutilización construcción con” Los
antiguos medios para crear activos de software reutilizables, mientras que
el segundo medio para la reutilización de activos de software en la
construcción de una nueva 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.5. Normas de construcción 
[1 *]
La aplicación de Dardos desarrollo dares externos o internos durante la
construcción ayuda a lograr los objetivos de un pro- yecto para la
eficiencia, la calidad y el costo. En concreto, las opciones de progra-
permisible subconjuntos del lenguaje Ming y normas de uso de ayudas
son importantes para lograr una mayor seguridad. Normas que afectan
directamente a problemas de 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 len-
guaje 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)
3-4 Guía SWEBOK® V3.0
• herramienta (por ejemplo, normas para anotaciones
esquemáticas como UML (Unified Modeling Language)).
El uso de estándares externos. La construcción depende de la
utilización de 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 corpo- rativa 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. Gestión de la Construcció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
desa- rrollo á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 (incluyendo los requisitos, el
diseño y la planificación) o que los solapamientos. Estos enfoques
tienden a diseño, codificación, y las actividades de prueba mezclar,
y que a menudo tratan la combinación de actividades como la
construcción (ver
el Software de Gestión y Procesos de Software KAs).
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
pro- yecto 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 pro- ceso, 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 Software KA para más información
sobre la medición).

3. Consideraciones prácticas
La construcción es una actividad en la que el ingeniero de software
tiene que hacer frente a las limitaciones del mundo real a veces
caóticos y cambiantes, y él o ella debe hacerlo con precisión. Debido a
la influencia de las 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 activi- dad 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í sucesivamente. Pueden ser graves contribuyentes al
vulnerabilidades de seguridad.
El tipo más simple del lenguaje es una construcción lenguaje de
configuración, en el que los ingenieros de software elegir entre un
conjunto limitado de opciones predefinidas para crear un software
nuevo o personalizado
Construcción de Software 3-5
instalaciones. Los archivos de configuración basados ​en texto que se
utilizan tanto en los sistemas operativos Windows y Unix son ejemplos
de esto, y las listas de selección de estilo de menú de algunos
generadores de programas constituiría, otro ejemplo de un lenguaje de
configuración.
idiomas Toolkit se utilizan para construir aplica- ciones 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 aplica- ciones pueden
simplemente estar implicados por el conjunto de las interfaces de un kit de
herramientas.
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.
Lenguajes de programación 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 parti- cular 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 cadenas de texto y más en las definiciones respaldadas
por definiciones precisas, de forma ambigua unidades organizativas y
formales (o matemáticos). notaciones formales de construcción y ods met
formales están en la base semántica de la mayoría de las formas de
3-6 Guía SWEBOK® V3.0
notaciones de programación del sistema, donde la precisión,
comportamiento en el tiempo, y la capacidad de prueba son más
importantes que la facilidad de mapeo en lenguaje natural. construcciones
mal para- también utilizan formas definidas con precisión de la
combinación de símbolos que evitan la ambigüedad de muchas
construcciones de lenguaje natural.
notaciones visuales 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-mentos,
rutinas, clases, paquetes, u otras estructuras);
• documentación de código;
• Código de sintonía,
3.4. Prueba de la construcción
[1 *]
Construcción implica dos formas de pruebas, que a menudo son
realizadas por el Neer niería de software que escribió el código:
• Examen
unidad de la
• 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 estándares han sido publicados
sobre el tema de las pruebas de la construcción: Norma IEEE
829-1998, IEEE Estándar 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., Unidad de Pruebas, 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 su reutilización durante la codificación y las pruebas son las
siguientes:

• aplicación variabilidad con mecanismos tales como la
parametrización, la compilación condicional, patrones de
diseño, y así sucesivamente.
• encapsulación variabilidad para que los activos soft- ware
fácil de configurar y personalizar.
• Prueba de la variabilidad proporcionada por los activos de software
capaces Reus-.
• Descripción y publicación de soft- ware activos
reutilizables.
3.6. Construcción con reutilización
[2 *]
Construcción con reutilización significa crear un nuevo software con la
reutilización de activos de software existentes. El método más popular
de reutilización es la reutilización de código de las bibliotecas
proporcionadas por el len- guaje, la plataforma, las herramientas que
se utiliza, o un repositorio organizativa. Los apartes de estos, las
aplica- ciones desarrolladas ampliamente hoy hacen uso de muchas
bibliotecas de código abierto. Reutilizados y off-the-shelf software a
menudo tienen la misma o mejor calidad requisitos como nuevo
desarrollo de software (por ejemplo, nivel de seguridad).
Las tareas relacionadas con la construcción de software con la
reutilización durante la codificación y las pruebas son las siguientes:
• La selección de las unidades reutilizables, Data- bases,
procedimientos de prueba, o datos de prueba.
• La evaluación de código o prueba de reutilización.
• La integración de los activos de software reutilizables en el
software actual.
• La presentación de la información reutilización de código nuevo, los
procedimientos de prueba o datos de prueba.
3.7. construcción de Calidad
[1 *]
Además de los fallos que resultan de los requisitos y de diseño, defectos
introducidos durante la construcción pueden dar lugar a problemas
graves de calidad -por ejem- plo, las vulnerabilidades de seguridad. Esto
incluye no sólo los fallos en la funcionalidad de seguridad, sino también
fallos en otras zonas que permiten la anulación de esta funcionalidad y
otras debilidades de seguridad o violaciónes. Existen numerosas
técnicas para asegurar la cali- dad de código como se construye. Las
técnicas primarios utilizados para la calidad de la construcción incluyen
Construcción de Software 3-7
• pruebas unitarias y pruebas de integración (ver sec- ción 3.4,
Pruebas de construcción)
• prueba de primer desarrollo (ver sección 2.2 en el KA de Pruebas
de Software)
• uso de afirmaciones y programación defensiva
• depuración
• inspecciones
• revisiones técnicas, incluyendo comentarios enteder-ori-
seguridad (ver sección 2.3.2 en la calidad KA Cesión de
Software)
• el análisis estático (véase la sección 2.3 de la Calidad KA
Soft- Ware)
La técnica o técnicas específicas seleccionadas dependen de la
naturaleza del software que se con- structed, así como en el conjunto de
habilidades de los ingenieros de software que realizan la construcción
activi- lazos. Los programadores deben conocer las buenas prácticas y
comunes ejemplo vulnerabilidades-para, a partir de listas ampliamente
reconocidos acerca de las vulnerabilidades comunes. análisis estático
automatizado de código para las debilidades de seguridad está
disponible para varios lenguajes de programación mon com- y se puede
utilizar en proyectos críticos para la seguridad.
actividades de construcción de calidad diferenciada se ated de otras
actividades de calidad por su enfoque. actividades de calidad de la
construcción se centran en código y artefactos que están estrechamente
relacionados con código como el diseño, a diferencia de otros artefactos
que están conectados directamente al menos el código, como los
requisitos, diseños de alto nivel, y los planes detallados.
3.8. Integración
[1 *]
Una actividad clave durante la construcción es el ción integración
de rutinas construidos individualmente, clases, componentes y
subsistemas en un único sis- tema. Además, puede necesitar ser
integrado con otros sistemas de software o hardware de un 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
3-8 Guía SWEBOK® V3.0
la determinación de puntos en el proyecto en el que se prueban versiones
provisionales del software.
Los programas pueden estar integrados por medio de cualquiera de los
gradual o el enfoque incremental. la integración por etapas, también
llamada integración “big bang”, implica retrasar la integración de las partes
componentes de software hasta que todas las partes destinados a la
liberación de una versión se han completado. la integración incremental se
cree que ofrecen muchas ventajas sobre el tra- dicional por fases de
integración, por ejemplo, la ubicación de error más fácil, un mejor
seguimiento de los avances, a principios de la entrega del producto, y la
mejora de relaciones con los clientes. En la integración gradual, el ERS
desarrollos escribir y probar un programa en pequeños trozos y luego se
combinan las piezas una a la vez. infraestructura de pruebas adicionales,
tales como talones, los controladores y los objetos de imitación, por lo
general se necesita para permitir la integración incrementales. Con la
construcción y la integración de una unidad a la vez (por ejemplo, una
clase o compo- nente), el proceso de construcción pueden proporcionar
información temprana a los desarrolladores y clientes. Otras ventajas de la
integración incrementales incluyen la ubicación más fácil error, la mejora
de progreso Monitor-ing, unidades probado más completamente, y así
sucesivamente.
4. Tecnologías de la Construcción
4.1. Diseño y Uso de la API
[3 *]
Una interfaz de programación de aplicaciones (API) es el conjunto de
firmas que se exportan y disponibles para los usuarios de una
biblioteca o un marco para escribir sus aplicaciones. Además de las
firmas, una API siempre debe incluir declaraciones sobre efectos y / o
comportamientos (es decir, su semántica) del programa. diseño de la
API debe tratar de hacer la API fácil de aprender y memorizar, dar
lugar a un código legible, ser difícil de mal uso, fácil de extender, ser
completa, y mantener la compatibilidad con versiones anteriores.
Como las API generalmente duran más que sus implementaciones
para una biblioteca o un marco ampliamente utilizado, se desea que
la API sea sencillo y se mantiene estable para facilitar el desarrollo y
mantenimiento de las aplicaciones cliente.
uso API implica los procesos de ING Seleccionar-, el aprendizaje, las
pruebas, la integración, y posiblemente se extiende API proporcionadas
por una biblioteca o trabajo marco (véase la sección 3.6, de la construcción
con la reutilización).
4.2. Orientado a Objetos Problemas de tiempo de ejecución 
[1 *]
lenguajes orientados a objetos soportan una serie de mecanismos de
ejecución que incluye el polimorfismo y la reflexión. Estos mecanismos
de ejecución aumentan la flexibilidad y adaptabilidad de los programas
orientados a objetos. El polimorfismo es la capacidad de un lenguaje
para apoyar las operaciones generales con- sin saber hasta que el
tiempo de ejecución qué tipo de objetos concretos del software incluirá.
Debido a que el programa no conoce el tipo exacto de los objetos de
antemano, el comportamiento exacto está determinado en tiempo de
ejecución (unión llamada dinámica). La reflexión es la capacidad de un
programa para observar y modificar su propia estructura y el
comportamiento en tiempo de ejecución. La reflexión permite la
inspección de las clases, interfaces, campos y métodos en tiempo de
ejecución con- sin saber sus nombres en tiempo de compilación.
También permite la instanciación en tiempo de ejecución de nuevos
objetos y invocación de métodos que usan nombres de clase y método
con parámetros.
4.3. Parametrización y Genéricos
[4 *]
tipos parametrizados, también conocidos como genéricos (ADA, Eiffel)
y plantillas (C ++), permiten la definición de un tipo o clase sin
especificar todos los otros tipos que utiliza. Los tipos no especificados
se suministran 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 la 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
progra- mas 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.

Diseño de contrato es un enfoque de desarrollo en los que las
condiciones previas y condiciones posteriores se incluyen para cada
rutina. Cuando se utilizan condiciones previas y condiciones
posteriores, se dice que cada clase de rutina o para formar un
contrato con el resto del programa. Por otra parte, un contrato
proporciona una especificación precisa de la 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 atri- buye 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 lanzar para lanzar una excepción detectada y una
excepción manipu- manipulan de bloque captura la excepción en una trata
de atraparlo
bloquear. 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 excepciones al código de la
biblioteca lanza, tal vez la construcción de un reportero de excepción
centralizada, y la normalización de la el uso del programa de
excepciones. tolerancia a fallos es una colección de técnicas que
aumentan la fiabilidad del software mediante la detección de errores y,
a continuación se recupera de ellos si es posible
Construcción de Software 3-9
o que contiene sus efectos si la recuperación no es posi- ble. Las
estrategias de tolerancia a 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) inicia- tiva del Object Management Group (OMG).
Un modelo ejecutable es una forma de especificar completamente
un modelo independiente de la plataforma (PIM); un PIM es un
modelo de una 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 desa- rrollo 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 de procesos tecnológicos. la programación basada en el
estado se suele combinar
3-10 Guía SWEBOK® V3.0
con la programación orientada a objetos, formando un nuevo enfoque
compuesto llamado , Programación orientada a objetos basado en el
estado.
Un método de la tabla impulsado es un esquema que utiliza tablas
para buscar información en lugar de utilizar sentencias lógicas (por
ejemplo, Si y caso). Se utiliza en las circunstancias apropiadas,
claves basadas en tablas
es más simple que la lógica complicada y más fácil de modificar. Al
utilizar métodos 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 efi- ciente 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 activi- dad técnica de la preparación de un
programa, generalmente software interactivo, para soportar múltiples
lugares. La actividad correspon- diente, 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. Gramática-Basado procesamiento de entrada [ dieciséis*]
procesamiento de entrada basado en la gramática implica el análisis de
sintaxis, o análisis, de la corriente de token de entrada. Se trata de la
creación de una estructura de datos (llamada
árbol de análisis sintáctico o árbol de sintaxis) representa los datos de
entrada. El recorrido en orden de aliado del árbol de análisis no baja da la
expresión se acaba de analizar. El analizador comprueba la tabla de
símbolos para la presencia de
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 un solo proceso o hilo a la vez.
4.11. middleware
[3 *] [6 *]
Middleware es una amplia clasificación de soft- ware 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 soft- ware interacción
orientada al servicio.

4.12. Métodos de construcción de software distribuido
[7 *]
Un sistema distribuido es una colección de siste- mas informáticos
físicamente separados, posiblemente heterogéneos que están
conectados en red para proporcionar a los usuarios el acceso a los
diversos recursos que mantiene el sistema. Construcción de
software distribuido se distingue de software tradicional trucción
ción por cuestiones tales como paralelismo, comu- nicación, y
tolerancia a fallos.
programación distribuida normalmente cae en una de varias
categorías arquitectónicos básicos: cliente-servidor, arquitectura de 3
capas, de n niveles de arquitectura, 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 el programa de
diseño 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 circui- tos integrados de aplicación específica (ASIC).
La parte de software se traduce en un lenguaje de programación
de bajo nivel.
4.14. Análisis de Rendimiento y ajuste
[1 *]
eficiencia-determinado código en la arquitectura, las decisiones de
diseño detallado, y la estructura de datos y
Construcción de Software 3-11
algoritmo de selección-influye en una velocidad y el tamaño ejecución.
Análisis de rendimiento es la investiga- ción de la conducta de un
programa utilizando informa- ción recopilada como se ejecuta el
programa, con el objetivo de identificar posibles puntos calientes en el
programa para 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 eje- cuta 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
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 desa- rrollo 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.
3-12 Guía SWEBOK® V3.0

5. Herramientas de software de construcción 5.3. Herramientas de prueba de unidad

[1 *] [2 *]
5.1. Entornos de desarrollo Prueba de la unidad verifica el funcionamiento de los módulos de

[1 *] software en forma aislada de otros elementos de software que son

separadamente contrastables (por ejemplo, clases, rutinas, componentes).

Un entorno de desarrollo o entorno de desarrollo integrado (IDE), Prueba de la unidad es a menudo auto-acoplado. Los desarrolladores

proporciona Comprehensive instalaciones hensive a los pueden utilizar herramientas de prueba de unidad y los marcos para

programadores de software para la construcción mediante la extender y crear ambiente de prueba automatizado. Con las herramientas

integración de un conjunto de herramientas de desarrollo. Las opciones de pruebas unitarias y marcos, el desarrollador puede codificar criterios en

de los entornos de desarrollo pueden afectar la eficiencia y la calidad la prueba para verificar la exactitud de la unidad bajo variabilidad conjuntos

de construcción de software. de datos ous. Cada prueba individual se implementa como un objeto, y un

corredor de prueba se ejecuta todas las pruebas. Durante la ejecución de

En adicional a las funciones básicas de edición de código, entornos de la prueba, los casos de prueba fallidos serán marcados e informaron de

desarrollo modernos a menudo ofrecen otras características como la forma automática.

compila- ción y detección de errores desde dentro del edi- tor, la

integración con el control de código fuente, construir herramientas de

depuración / test /, comprimido o delinear puntos de vista de los 5.4. Perfilado, análisis de rendimiento, y cortar
programas, código automatizado transforma y soporte para la Herramientas
refactorización. [1 *]

5.2. Constructores GUI herramientas de análisis de rendimiento se utilizan generalmente para

[1 *] apoyar la sintonización código. Las herramientas de análisis per- formance

más comunes son herramientas de perfiles. Una herramienta de ejecución

Un constructor de GUI (Graphical User Interface) es una herramienta de de perfiles supervisa el código mientras se ejecuta y registra el número de

desarrollo de software que permite el fun desa- para crear y mantener veces que se ejecuta cada instrucción o cuánto tiempo el programa pasa

interfaces gráficas de usuario en un WYSI- WYG (lo que ves es lo que en cada ruta declaración o ejecución. Pro-presentación del código

obtienes) de modo. Un constructor de interfaz gráfica de usuario por lo mientras se está ejecutando da una idea de cómo funciona el programa,

general incluye un editor visual para el desarrollador para diseñar formas y donde están los puntos calientes, y donde los desarrolladores deben

ventanas y gestionar la distribución de los widgets por Arrastrando, goteo centrarse los esfuerzos de optimización de código.

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 rebanar programa implica el cálculo del conjunto de instrucciones de

si- bajo el estilo orientado a eventos (en la que el flujo del programa es programa (es decir, el programa de rebanada) que pueden afectar a los

determinado por eventos y manejo de eventos), las herramientas de valores de las variables especificadas en algún punto de interés, que se

desarrollo GUI suelen proporcionar asistentes de generación de código, conoce como un criterio de fragmentación. rebanar programa puede ser

que automatizan las tareas más repetitivas requeridas para el manejo de utilizado para la localización de la fuente de errores, programa de

eventos. El código de soporte se conecta widgets con los eventos comprensión, y análisis de optimización. herramientas de corte en lonchas

salientes y entrantes que activan las funciones que proporcionan la lógica programa computan las rebanadas de programas para varios lenguajes de

de la aplicación. Algunos entornos de desarrollo modernos proporcionan programación que utilizan métodos de análisis estáticos o dinámicos.

constructores GUI integradas o constructor GUI plug-ins. También hay

muchos constructores GUI independientes.
 Construcción de Software 3-13

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Silberschatz et al. 2008

Clements et al. 2010

Mellor y Balcer 2002

Gamma et al. 1994

Nula y Lobur 2006

Sommerville 2011
McConnell 2004

[2 *]

[7 *]
[5 *]
[3 *]

[4 *]

[6 *]
[1 *]

1. Fundamentos de
construcción de
software

c2, c3,
C7-C9, C24,
1.1. Complejidad
C27, C28,
minimizando
C31, C32,
C34

C3-C5,
1.2. pronóstico del
C24, C31,
cambio
C32, C34

c8, c23
1.3. La construcción de C20, C31,
Verificación
c34

1.4. Reutilizar c16

1.5. Normas de
c4
construcción
2. Gestión de la
Construcción

2.1. Construcción de Modelos C2, C3,

de Ciclo de Vida C27, C29

C3, C4,
2.2. Ordenación de la
C21,
Edificación
C27-C29

2.3. Medición de la
c25, c28
construcción

3. Consideraciones
prácticas

3.1. Diseño de la C3, C5,

construcción C24

3.2. Idiomas de
c4
construcción

C5-C19,
3.3. Codificación
C25-C26
3-14 Guía SWEBOK® V3.0

Silberschatz et al. 2008

Clements et al. 2010

Mellor y Balcer 2002

Gamma et al. 1994

Nula y Lobur 2006

Sommerville 2011
McConnell 2004

[2 *]

[7 *]
[5 *]
[3 *]

[4 *]

[6 *]
[1 *]

3.4. Prueba de la
c22, c23
construcción

3.5. Construcción de
c16
Reutilización

3.6. Construcción con

c16
reutilización

3.7. construcción de c8,

Calidad c20-c25
3.8. Integración c29

4. Tecnologías de la

Construcción

4.1. Diseño y Uso de la API

c7

4.2. Orientado a Objetos

C6, C7
Problemas de tiempo de ejecución

4.3.
Parametrización y c1
Genéricos

4.4. Afirmaciones, Diseño

por contrato, y la
C8, C9
programación defensiva

4.5. Control de errores, control

de excepciones, y la C3, C8
tolerancia a fallos

4.6. ejecutable
c1
modelos

4.7. Las técnicas de

construcción basadas en
c18
tablas de base estatal y

4.8. Configuración de tiempo

de ejecución y la C3, C10

internacionalización

4.9. Procesamiento de la
c5 c8
entrada Gramática-Basado
 Construcción de Software 3-15

Silberschatz et al. 2008

Clements et al. 2010

Mellor y Balcer 2002

Gamma et al. 1994

Nula y Lobur 2006

Sommerville 2011
McConnell 2004

[2 *]

[7 *]
[5 *]
[3 *]

[4 *]

[6 *]
4.10. Las primitivas de [1 *]
c6
concurrencia

4.11. middleware c1 c8

4.12. Métodos de
construcción para c2
El software distribuido

4.13. La construcción de
sistemas heterogéneos C9

4.14. Actuación
Análisis y c25 Tuning, c26
4.15. Normas de
c10 c1
plataforma

4.16. Programación
c22
Test-First

5. Instrumento de construcción

5.1. Entornos de
c30
desarrollo
5.2. Constructores GUI c30

5.3. Herramientas de
c22 c8
prueba de unidad

5.4. Perfilado,
análisis de
c25, c26
rendimiento, y
cortar Herramientas
3-16 Guía SWEBOK® V3.0

LECTURAS Referencias

IEEE Std. 1517-2010 Norma de Información  [1 *] S. McConnell, Código completo, 2ª ed.,

Tecnología de sistema y software de procesos de reutilización Microsoft Press, 2004.
Procesos del Ciclo de Vida, IEEE, 2010 [8].
[2 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
Esta norma especifica los procesos, actividades y tareas que deben
aplicarse durante cada fase del ciclo de vida del software para permitir [3 *] P. Clements et al., Software de documentación 
que un producto de software para ser construido a partir de los activos Vistas: arquitecturas y más allá, 2ª ed., Pearson
reutilizables. Cubre el concepto de desarrollo basado en la reutilización y Education, 2010.
los procesos de construcción de reutilización y la construcción con la
reutilización. [4 *] E. Gamma et al., Patrones de diseño: Elementos 
de software reutilizables orientada a objetos, 1ª ed.,
Addison-Wesley Professional, 1994.
IEEE Std. 12207-2008 (también conocido como ISO / IEC 
12207: 2008) Estándar de Sistemas y Software de [5 *] SJ Mellor y MJ Balcer, Ejecutable 
Ingeniería de Software-procesos de ciclo de vida, IEEE UML: La Base para Model-Driven
2008 [9]. Architecture, 1ª ed., Addison-Wesley,
2002.
Este estándar define una serie de software los procesos de desa- rrollo,
incluyendo el software de construc- ción proceso, el proceso de [6 *] L. Null y J. Lobur, Lo Esencial de la 
integración de software, y el software de proceso de reutilización. Organización ordenador y Arquitectura,
2ª ed., Jones and Bartlett Publishers,
2006.

[7 *] A. Silberschatz, PB Galvin, y G. Gagne,

Conceptos del sistema operativo, Octava ed., Wiley,
2008.

[8] IEEE Std. 1517-2010 estándar para 

Tecnología de la Información-Sistema y el Software
procesos vitales de reutilización de ciclo Procesos, IEEE
2010.

[9] IEEE Std. 12207-2008 (también conocido como ISO / IEC 

12207: 2008) Estándar de Sistemas y Software de

Ingeniería de Software-procesos de ciclo de vida, IEEE
2008.
 CAPÍTULO 4
PRUEBAS DE SOFTWARE
SIGLAS
API Application Program Interface TDD
Test-Driven Development TTCN3 pruebas y de
control de pruebas de notación
La versión 3
XP Programación extrema
INTRODUCCIÓN
Las pruebas de software consiste en la dinámica verifica- ción que ofrece
un programa de esperado comportamientos en una finito un conjunto de
casos de prueba, adecuadamente seleccionado 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 KA. Vale la
pena señalar que la terminología gía no es uniforme entre las
diferentes co- munidades y algunos utilizan el término “prueba”
también en referencia a las técnicas estáticas.
• Finito: Incluso en los programas simples, por lo que muchos casos
de prueba son teóricamente posible que las pruebas tivo tamiento
podría requerir meses o años
4-1
ejecutar. Es por esto que, en la práctica, un conjunto completo de
pruebas puede considerarse generalmente infi- nita, y la prueba
se lleva a cabo en un subconjunto de todas las pruebas posibles,
que está determinada por criterios de riesgo y priorización. Las
pruebas siempre implica un equilibrio entre los recursos y los
horarios, por un lado limitados y los requisitos de prueba
inherentemente ilimitadas, por el otro.
• Seleccionado: Las muchas técnicas de prueba propuestos
difieren esencialmente en cómo se selecciona el equipo de
prueba, y los ingenieros de software deben ser conscientes de
que los diferentes criterios de selección pueden producir muy
diferentes grados de efectividad. Cómo identificar el criterio de
selección más adecuado bajo condiciones dadas es un
problema complejo; en la práctica, se aplican técnicas de
análisis de riesgos y la ingeniería de software tise exper-.
• Esperado: Debe ser posible, aunque no siempre es fácil, para
decidir si los resultados observados de las pruebas del
programa son aceptables o no; de lo contrario, el esfuerzo de
prueba se uso- menos. El comportamiento observado puede
ser contrastada con las necesidades del usuario
(comúnmente conocidas como pruebas de validación), contra
un ficación speci- (prueba para la verificación), o, haps per-,
contra el comportamiento esperado de los requisitos implícitos
o expectativas (ver pruebas de aceptación en el software de
los requisitos KA).
En los últimos años, la vista de las pruebas de software ha
madurado hasta convertirse en una constructiva. Testing ya no se ve
como una actividad que se inicia sólo después de la fase de
codificación se completa con el propósito limitado de fallos de
detección. Las pruebas de software es, o debería ser, omnipresente en
todo el ciclo de desarrollo y mantenimiento de la vida. De hecho, la
planificación de las pruebas de software debe comenzar con las
primeras etapas del proceso de requisitos de software,
4-2 Guía SWEBOK® V3.0
Figura 4.1. Desglose de temas para las Pruebas de Software KA
y los planes y procedimientos de prueba deben ser System- que avanza el
desarrollo de software 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 soft- ware
es una de prevención: es, obviamente, mucho mejor para prevenir los
problemas que corregirlos. Las pruebas pueden verse, entonces,
como un medio para proporcionar información acerca de la
funcionalidad
y los atributos de calidad del software y 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). Tanto catego- rías
son útiles. Esta KA se centra en técnicas dinámicas.
Las pruebas de software también está relacionado con la construcción
de software (vea Pruebas de construcción en el KA Construcción de
Software). En particular, la unidad y pruebas de integración están
íntimamente relacionados con la construcción de software, si no es parte
de ella.
DISTRIBUCIÓN DE TEMAS PARA LAS
PRUEBAS DE SOFTWARE
El desglose de temas para el Software de Exámenes KA se
muestra en la Figura 4.1. Un desglose más detallado se
proporciona en la Matriz de Temas vs. Material de referencia al
final de este KA. El primer tema se describe damentals Software
Testing FUn-. Cubre las definiciones básicas en el campo de
pruebas de software, la terminología básica y las cuestiones clave,
y el buque PARENTESCO de pruebas de software con otras
actividades.
El segundo tema, los niveles de prueba, se 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 propie- dades y se conoce como objetivos
de la prueba. No todos los tipos de pruebas se aplican a todos los
productos de software, ni ha sido incluido todos los tipos posibles. El
objetivo blanco de prueba y la prueba en conjunto determinan cómo
se identifica el equipo de prueba, tanto en cuanto a su consistencia, la defecto puede ser utilizado para hacer referencia a un fallo o un
cantidad de pruebas es suficiente para lograr el objetivo declarado -y
a su composición- que los casos de prueba deben seleccionarse para
lograr el objetivo declarado
(Aunque por lo general “para lograr el obje- tivo 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 denominan
adecuación de la prueba criterios, mientras que los relativos a la segunda
pregunta son la prueba Criteria de selección.
Varias técnicas de prueba se han desarrollado en las últimas
décadas, y todavía se están proponiendo nuevas. técnicas
generalmente aceptadas están cubiertos en el tercer tema.
Las medidas de prueba relacionados se tratan en el cuarto tema,
mientras que las cuestiones relativas a la prueba Pro- ceso están cubiertos
en el quinto. Finalmente, herramientas de prueba de software se presentan
en el tema seis.
Pruebas de Software 4-3
1. Fundamentos de Software Testing
1.1. Terminología de pruebas relacionados
1.1.1. Definiciones de Pruebas y terminología
relacionada 
[1 *, c1, c2] [2 *, c8]
Definiciones de pruebas y terminología relacionados con las pruebas
se proporcionan en las referencias citadas y se resumen como sigue.
1.1.2. Las fallas fallas vs. 
[1 *, c1s5] [2 *, c11]
Muchos términos se utilizan en la literatura de ingeniería de
software para describir un mal funcionamiento: en particular, avería,
fallo, y error, entre otros. Este gía terminología se define
precisamente en [3, c2]. Es esencial distinguir claramente entre el porque
de un mal funcionamiento (para el que se utilizará el fallo término
aquí) y un efecto no deseado observado en servicio entregado del
sis- tema (que será llamado un fracaso). 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 término más genérico
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
entradas de fallo causante en lugar de los fallos, es decir, aquellos
conjuntos de entradas que hacen que aparezca un fallo.
1.2. Cuestiones clave
1.2.1. Criterios de selección de las pruebas / 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
4-4 Guía SWEBOK® V3.0
es suficiente para un propósito determinado. Prueba criterios
quacy ade- se pueden utilizar para decidir cuando la prueba sufi-
sufi- será, o se ha logrado [4] (ver terminación en la sección 5.1,
las consideraciones prácticas).
1.2.2. Los tests de efectividad / Objetivos para las pruebas 
[1 *, c11s4, c13s11]
Ensayos sobre la eficacia se determina mediante el análisis de un
conjunto de ejecuciones del programa. Selección de las pruebas que se
ejecutarán puede ser guiado por diferentes objetivos: es sólo a la luz del
objetivo perseguido que la eficacia del equipo de prueba se puede
evaluar.
1.2.3. Las pruebas para detectar defectos Descubrimiento [ 1 *, c1s14]
En las pruebas para la detección de defectos, una prueba exitosa es
aquella que hace que el sistema falle. Esto es bastante diferente de las
pruebas para demostrar que el software cumple sus especificaciones o
otras propiedades deseadas, en los que las pruebas de caso tiene éxito
si no se observan fallos en virtud de casos de prueba realistas y
entornos de prueba.
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 dife- rentes 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  Técnicas agement (Ver Técnicas de Gestión de la Calidad
[1 *, c2s7]
la teoría de las pruebas advierte contra atribuir un nivel cado
injustificado de confianza a una serie de pruebas con éxito.
Desafortunadamente, los resultados más establecidos de la teoría de
las pruebas son negativas, ya que afirman que la prueba nunca puede
alcanzar a diferencia de lo que se consigue en realidad. La cita más
famosa
en este sentido es el aforismo Dijkstra que “las pruebas pro- grama se
puede utilizar para mostrar la presencia de insectos, pero nunca para
mostrar su ausencia” [5]. La razón obvia de esto es que la prueba
completa no es viable en el software realista. Debido a esto, la prueba
se debe conducir basado en el riesgo [6, parte 1] y puede ser visto
como una estrategia de gestión de riesgos.
1.2.6. El problema de no factibles Caminos 
[1 *, c4s7]
caminos no factibles son trayectorias de flujo de control que no pueden ser
ejercidos por cualquier dato de entrada. Ellos son un problema no puede
signifi- en pruebas basadas en el camino, sobre todo en la derivación
automática de entradas de prueba para ejercer trayectorias de flujo de
control.
1.2.7. la capacidad de prueba 
[1 *, c17s2]
El término “capacidad de prueba de software” 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 otro lado, se define como la probabilidad, posiblemente mide
estadísticamente, que un conjunto de casos de prueba expondrá 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-
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 pruebas de la
construcción en la construcción del software KA [1 *, c3s2]).
2. Niveles de prueba
Las pruebas de software se realiza generalmente en dife- rentes niveles
preferido no baja de poner todos los componentes juntos en las
a lo largo de los procesos de manteni- miento y desarrollo. Los
niveles pueden distinguirse basándose en el objeto de la prueba,
que se llama el objetivo, o en la finalidad, que se llama el
objetivo ( del nivel de prueba).
2.1. El objetivo de la prueba 
[1 *, c1s13] [2 *, c8s1]
El objetivo de la prueba puede variar: un módulo individual, un grupo de
tales módulos (relacionadas por finalidad, uso, comportamiento, o
estructura), o todo un sistema. Tres etapas de la prueba se pueden
distinguir: unidad, inte- gración, y el sistema. Estas tres etapas de
prueba no implican ningún 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  generalmente evaluados en este nivel.
[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  La prueba puede ser dirigido a la verificación de diferentes pro-
[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 menudo con el software quía chically estructurado.
, estrategias de integración sistemáticas modernas son
típicamente arquitectura dirigida, que consiste en integrar
progresivamente los componentes o subsistemas de software
basado en com- identificado
Pruebas de Software 4-5
hilos funcionales. Las pruebas de integración es a menudo una
actividad continua en cada etapa de desarrollo durante el cual los
ingenieros de software abstractos perspectivas de distancia de nivel
inferior y se concentran en las perspectivas del nivel en el que están
inte- grando. Para que no sea el software pequeño, sencillo,
estrategias de pruebas de integración incrementales son el aliado
pruebas una vez que está a menudo llamado “big bang”.
2.1.3. Prueba del sistema 
[1 *, c8] [2 *, c8]
Las pruebas del sistema se ocupa de probar el comportamiento
de todo un sistema. unidad efectiva y pruebas de integración se
han identificado muchos de los defectos de software. Las
pruebas del sistema se considera generalmente adecuado para
evaluar los requisitos del sistema, tales como no funcionales
seguri- dad, velocidad, precisión y fiabilidad (ver requisitos
funcionales y no funcionales en los requisitos de software y
software KA cali- dad en el Requisitos La calidad del software
KA). interfaces externas a otras aplicaciones, utilidades,
dispositivos de hardware, o los entornos operativos también son
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.
piedades. 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 las pruebas incluyen
pero no se limitan a la seguridad de medición,
4-6 Guía SWEBOK® V3.0
identificación de las vulnerabilidades de seguridad, evaluación de la
usabilidad y la aceptación de software, por lo que sería tomado diferentes
enfoques. Tenga en cuenta que, en general, los objetivos de la prueba
varían según el destino de la prueba; propósitos diferentes se dirigen a
diferentes niveles de pruebas.
Los subtemas que figuran a continuación son los más frecuentemente
citado en la literatura. Tenga en cuenta que algunos tipos de pruebas son
más apropiados para las pruebas de software paquetes de instalación a
medida, para
ejemplo- y otros productos de consumo, como el beta pruebas.
2.2.1. La prueba de aceptación / Calificación 
[1 *, c1s7] [2 *, c8s4]
Las pruebas de aceptación / calificación determina si un sistema
cumple con sus criterios de aceptación, por lo general mediante la
comprobación de los comportamientos deseados del sistema contra
los requerimientos del cliente. El cliente o representativos fies por lo
tanto speci- de un cliente o directamente realiza actividades para
comprobar que se han cumplido sus requisitos, o en el caso de un
producto de consumo, que la organización ha cumplido con los
requisitos establecidos para el mercado de Tar conseguir. Esta
actividad pruebas pueden o no implicar los desarrolladores del
sistema.
2.2.2. Prueba de la instalación  garantía dada por regresión probando cada vez que se realiza un cambio
[1 *, c12s2]
A menudo, después de la finalización del sistema y pruebas de
aceptación, el software se verifica después de la instalación en el entorno
de destino. las pruebas de instalación se puede ver como las pruebas del
sistema llevado a cabo en el entorno operativo de configuraciones de
hardware ciones y otras limitaciones operacionales. procedimientos de
instala- ción también pueden ser verificados.
2.2.3. Alfa y Beta Testing 
[1 *, c13s7, c16s6] [2 *, c8s4]
Antes se libera el software, se da a veces a un pequeño y selecto
grupo de usuarios potenciales para su uso ensayo ( alfa pruebas) y / o
a un conjunto mayor de usuarios representativos ( beta pruebas).
Estos usuarios reportan problemas con el producto. Alfa y beta testing
a menudo no están controlados y no siempre se hace referencia en
un plan de pruebas.
2.2.4. Logro fiabilidad y Evaluación 
[1 *, c15] [2 *, c15s2]
Las pruebas mejora la fiabilidad mediante la identificación y corrección
de fallos. Además, las medidas estadísticas de fiabilidad se pueden
derivar por casos de prueba ing generat- aleatoria de acuerdo con el
perfil de funcionamiento del software (ver perfil operativo en la sección
3.5, Técnicas de uso-base). Este último enfoque se denomina las
pruebas de funcionamiento. Usando modelos de crecimiento fiabilidad,
ambos objetivos pueden perseguirse juntos [3] (ver L Prueba ife,
Evaluación de confiabilidad en el apartado
4.1, Evaluación del Programa bajo prueba).
2.2.5. Pruebas de regresión 
[1 *, c8s11, c13s3]
De acuerdo con [7], pruebas de regresión es la “repetición de pruebas
tiva selec- de un sistema o componente para verificar que las
modificaciones no han causado efectos no deseados y que el sistema o
componente sigue cumpliendo con sus requisitos especificados.” En la
práctica, el enfoque es demostrar que las pruebas de software sigue
pasando pasado previamente en un conjunto de pruebas (de hecho,
también se refiere a las pruebas de progresión como nonre- veces). Para
el desarrollo incremental, el propósito de las pruebas de regresión es
mostrar que el comportamiento del software no se ha modificado por los
cambios graduales en el software, excepto en la medida en que debería.
En algunos casos, una solución de compromiso debe hacerse entre la
y los recursos necesarios para llevar a cabo las pruebas de regresión,
que puede ser bastante tiempo, debido al gran número de pruebas que
pueden ser ejecutados. Las pruebas de regresión consiste en
seleccionar, minimizar y / o dar prioridad a un subconjunto de los casos
de prueba en un conjunto de pruebas exis- tentes [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.
2.2.6. Pruebas de rendimiento 
[1 *, c8s6]
Las pruebas de rendimiento verifica que el software cumple con los
requisitos de funcionamiento específicos y evalúa características
de rendimiento-por ejemplo, la capacidad y el tiempo de respuesta.

2.2.7. Pruebas de seguridad  2.2.12. Prueba de configuración
[1 *, c8s3] [2 *, c11s4]
Las pruebas de seguridad se centra en la verificación de que el software
está protegido de ataques externos. En particular, las pruebas de
seguridad verifica la confidenciales cialidad, integridad y disponibilidad
de los sistemas y sus datos. Por lo general, las pruebas de seguridad
incluye la verificación contra el mal uso y el abuso de la cerámica o el
sistema (pruebas negativas) blandas.
2.2.8. Pruebas de estrés  La tarea principal de la usabilidad y las pruebas interacción
[1 *, c8s8]
Las pruebas de estrés ejerce de software en la carga máxima de diseño,
así como más allá de ella, con el objetivo de determinar los límites de
comportamiento, y para poner a prueba los mecanismos de defensa en
sistemas críticos.
2.2.9. Back-to-Back Testing 
[7]
IEEE / ISO / IEC Standard 24765 define las pruebas de espalda de
Regreso a como “prueba en el que dos o más variantes de un
programa se 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  de entrada, los escenarios, los estados, y los flujos de datos. La
[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 siste- mas complejas. pruebas de
la interfaz tiene como objetivo verificar si la interfaz componentes
correctamente para proporcionar el intercambio correcto de datos y
control de informa- 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 para simular el uso de las API de
aplicaciones de usuario final. Esto implica la genera- ción de los
parámetros de las llamadas a la API, el ajuste de las condiciones del
entorno externo, y a la definición de los datos interna que afecta a la
API.
Pruebas de Software 4-7
 
[1 *, c8s5]
En los casos donde el software se construye para servir a diferentes
usuarios, pruebas de configuración verifica el software bajo diferentes
configuraciones especificadas.
2.2.13. Usabilidad e inter-Ordenador prueba de la
acción 
[10 *, c6]
persona-ordenador es evaluar lo fácil que es para los usuarios finales para
aprender y utilizar el software. En general, puede implicar pruebas del
software fun- ciones que soporta las tareas del usuario, la documentación
que ayuda a los usuarios, y la capacidad del sistema para recuperarse de
los errores del usuario (ver diseño de la interfaz de usuario en el software
de diseño de KA).
3. Técnicas de Prueba
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
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 expe- riencia, 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
caja blanca ( también llamado 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 recuadro negro si los casos de prueba se basan
únicamente en el comportamiento de la entrada / salida 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.
4-8 Guía SWEBOK® V3.0
3.1. Sobre la base de la intuición y la experiencia del ingeniero de
software  Pairwise pertenece a combinatoria pruebas, que en general
3.1.1. Ad hoc
Tal vez la técnica que más se practica es la prueba ad-hoc: las
pruebas se derivan depender de la habilidad del ingeniero de
software, la intuición y ex- periencia 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 po- sible, 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  han propuesto formas mejoradas de pruebas al azar en los que pling la
[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.
3.2.2. Las pruebas por parejas  criterios basados ​Flow Control es la prueba de ruta, cuyo objetivo es
[1 *, c9s3]
Los casos de prueba se derivan mediante la combinación de valores
interesantes para cada par de un conjunto de variables de entrada
en lugar de considerar todas las combinaciones posibles. pruebas
también incluye combinaciones de más alto nivel que los pares:
estas técnicas se denominan t-sabia, por lo que cada combinación
posible de t variables de entrada se considera.
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 fun- cional, 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
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
ejecutar todas las trayectorias de flujo de control de entrada-salida-a en el
gráfico de flujo de control de un programa. Dado que las pruebas de ruta
exhaustiva por lo general no es factible debido a

bucles, otros criterios menos estrictos se centran en la cobertura de
los caminos que limitan iteraciones del bucle, tales como la cobertura
de sentencias, cobertura de sucursales, y las pruebas DICIÓN / con-
decisión. La adecuación de estas pruebas se mide en porcentajes; por
ejemplo, cuando todas las ramas se han ejecutado al menos una vez
por los ensayos, se ha logrado 100% de cobertura de rama.
3.3.2. Criterios basados ​en el flujo de datos 
[1 *, c5]
En las pruebas basadas en el flujo de datos, el gráfico de flujo de
control está anotado con información acerca de cómo se definen las
variables del programa, utilizados, y mataron (indefinido). El criterio
más fuerte, todos los caminos definición de uso, requiere que, para
cada variable, se ejecuta cada segmento de trayectoria de flujo de
control de una definición de esa variable a un uso de esa definición.
Con el fin de reducir el número de caminos necesarios, se emplean
estrategias más débiles tales como todo-definiciones y todos los usos.
3.3.3. Modelos de referencia de las pruebas basadas en el
Código
[1 *, c4]
Aunque no es una técnica en sí misma, la estructura de control de
un programa puede ser gráficamente repre- sentadas usando un
gráfico de flujo para visualizar técnicas de ensayo basadas código-.
Un gráfico de flujo es un grafo dirigido, los nodos y arcos de los
cuales corresponderse a elementos (ver gráficos y los árboles en los
fundamentos matemáticos KA) programar. Por ejemplo, los nodos
pueden representar declaraciones o secuencias ininterrumpidas de
estados, y los arcos pueden representar la transferencia de control
entre los nodos.
3.4. Técnicas basada en la culpa 
[1 *, c1s14]
Con diferentes grados de formalización, técnicas de ensayo basadas
culpa- diseñar casos de prueba específica- mente destinados a revelar
categorías de fallos probables o predefinidas. Para enfocar mejor la
está en uso real. Para ello, las entradas se asignan probabilidades,
generación de casos de prueba o de selección, una modelo de fallo pueden
ser introducidos que clasifica los diferentes tipos de faltas.
Pruebas de Software 4-9
3.4.1. error de adivinanzas 
[1 *, c9s8]
En adivinar de error, los casos de prueba están diseñados
específicamente por los ingenieros de software que intentan anticipan las
fallas más plausibles en un programa dado. Una buena fuente de
información es la historia de los fallos detectados en los proyectos
anteriores, así como la experiencia del ingeniero de software.
3.4.2. Las pruebas de mutación 
[1 *, c3s5]
Un mutante es una versión ligeramente modificada del programa bajo
prueba, que difiere de ella por un pequeño cambio sintáctico. Cada
caso de prueba ejerce tanto el programa original y todos los mutantes
generados: si un caso de prueba tiene éxito en la identificación de la
dife- rencia entre el programa y un mutante, se dice que este último
sea concebido originalmente como una técnica para evaluar la prueba
“muerto”. conjuntos (véase la sección
4.2. Evaluación de las pruebas realizadas), pruebas ción mutatis es
también un criterio de prueba en sí mismo: o bien pruebas se generan
aleatoriamente hasta que suficientes mutantes han muerto, o pruebas
están diseñadas específicamente para matar mutantes supervivientes.
En este último caso, las pruebas de mutación también puede ser
categorizado como una técnica basada en el código. La suposición
subyacente de pruebas de mutación, el efecto de acoplamiento, es que
mediante la búsqueda de fallos sintácticos simples, se encontraron
defectos más complejos pero reales. Para que la técnica sea eficaz, un
gran número de mutantes debe ser generado y ejecutado de forma
sistemática [12] automáticamente.
3.5. Técnicas de uso-Basado
3.5.1. Perfil operativa 
[1 *, c15s5]
En las pruebas para la evaluación de la fiabilidad (llamada también
pruebas de funcionamiento), el entorno de prueba repro- duce el
entorno operativo de la soft- ware, o la perfil operativo, lo mas
cercano posible. El objetivo es inferir a partir de los resultados de
las pruebas observadas el futuro fiabilidad del software cuando
o perfiles, en función de su frecuencia de ocurrencia en la
operación real. perfiles fun- cional se pueden utilizar durante la
prueba del sistema
4-10 Guía SWEBOK® V3.0
para guiar derivación de casos de prueba que evaluarán la
consecución de los objetivos de fiabilidad y ejercer uso
relativo y importancia de las distintas funciones similares a
lo que se encontró en el entorno operativo [3].
3.5.2. La heurística de observación del usuario  3.6.2. Las máquinas de estados finitos
[10 *, C5, C7]
principios de usabilidad pueden proporcionar directrices para los
problemas de los descubrimientos confirma en el diseño de la cara 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
deter- minar 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 siguientes.
3.6.1. Las tablas de decisión 
[1 *, c9s6]
Las tablas de decisión representan las relaciones lógicas entre las
condiciones (aproximadamente, insumos) y acciones
(Más o menos, las salidas). Los casos de prueba se derivan
sistemáticamente por considerar cada posible combinación de
condiciones y sus acciones resul- tantes correspondientes. Una
técnica relacionada es causa-efecto gráfica [ 1 *, c13s6].
 
[1 *, c10]
Al modelar un programa como una máquina de estados finitos, las pruebas
pueden ser seleccionados con el fin de cubrir los estados y transiciones.
3.6.3. Las especificaciones formales 
[1 *, c10s11] [2 *, c15]
Indicando las especificaciones en un lenguaje formal (ver Métodos
Formales en la ingeniería de software Modelos y Métodos KA)
permite la derivación automática de casos de prueba funcionales, y,
al mismo tiempo, proporciona un oráculo para comprobar los
resultados de pruebas.
TTCN3 (Pruebas y control de pruebas notación de la versión 3) es un
lenguaje desarrollado para escribir casos de prueba. La notación fue
concebida para las necesidades específicas de los sistemas de prueba de
telecomunicaciones, por lo que es particularmente adecuado para probar
protocolos de comuni- cación complejos.
3.6.4. Modelos de flujo de trabajo 
[2 *, c8s3.2, c19s3.1]
modelos de flujo de trabajo especifican una secuencia de activi- lazos
realizadas por los seres humanos y / o software aplica- ciones,
generalmente representados a través de notaciones gráficas. Cada
secuencia de acciones constituye un flujo de trabajo (también llamado un
escenario). Tanto cal normalmente, un y flujos de trabajo alternativos
deben ser probados [6, parte 4]. Un enfoque especial en los papeles en
una especificación de flujo de obra está dirigida en las pruebas de
procesos de negocio.
3.7. Las técnicas basadas en la naturaleza de la
aplicación
Las técnicas anteriores se aplican a todo tipo de soft- ware.
Técnicas adicionales para la derivación y ejecución de pruebas se
basan en la naturaleza de la soft- ware siendo probado; por
ejemplo,

• software orientado a objetos
• software basado en componentes
• software basado en web
• programas concurrentes
• software basado en el protocolo
• sistemas de tiempo real
• sistemas de seguridad críticos
• software orientada a servicios
• software de código abierto
• software embebido
3.8. La selección y la combinación de técnicas 
3.8.1. La combinación funcional y estructural  análisis de calidad. La medición también se puede utilizar para optimizar
[1 *, c9]
Basado en modelos y técnicas de ensayo basadas en código son a
menudo contrastan tan funcional frente a las pruebas estructurales.
Estos dos enfoques para la selección de la prueba no deben ser vistos
como alternativas sino como complementos; de hecho, se utilizan
diferentes fuentes de información y se ha demostrado que diferentes
tipos de alta luz de los problemas. Pueden ser utilizados en
combinación, dependiendo de consideraciones presupuestarias.
3.8.2. Determinista vs aleatoria 
[1 *, c9s6]
Los casos de prueba pueden seleccionarse de una manera
determinista, de acuerdo con una de muchas técnicas, o
aleatoriamente extraídas de alguna distribución de insumos, tal
como se suele hacer en las pruebas de fiabilidad. comparaciones
analíticas y empíricas erales SeV han llevado a cabo para analizar
las condiciones que hacen que un enfoque más eficaz que el 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 prueba [6, Parte 4].
Por ejemplo, la cobertura de la rama es una técnica de prueba
popular. El logro de una cobertura rama medida especificada (por
ejemplo, 95% de cobertura de sucursales) no debe ser el objetivo de
las pruebas per se: es una forma de improv- ing las posibilidades de
encontrar fallos por intentar ejercer sistemáticamente todas las ramas
del programa
Software de Pruebas 4-11
en cada punto de decisión. Para evitar este tipo de malentendidos,
una clara distinción debe hacerse entre las medidas relacionadas
con las pruebas que proporcionan una evaluación del programa que
se está probando, a partir de las salidas de prueba observadas y las
medidas que evalúan la minuciosidad de la prueba. (Véase la
Ingeniería de Software de medición en la Gestión KA Ingeniería de
Software para obtener información sobre los programas de
medición. Ver Proceso de Software y Medición del producto en el
Proceso de Ingeniería de Software KA para obtener información
sobre las medidas).
La medición se considera generalmente como funda- mental para el
la planificación y ejecución de las pruebas. Gestión de pruebas puede
utilizar varias medidas de diferencias ent proceso para monitorear el
progreso. (Véase la sección 5.1, las consideraciones prácticas, para una
dis- cusión de las medidas del proceso de pruebas útiles para fines de
gestión).
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]
Las medidas basadas en el tamaño del software (por ejemplo, líneas
de código fuente o tamaño funcional; ver Requisitos Suring medi- en
los requisitos de software KA) o sobre la estructura del programa
puede ser utilizado 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).
4-12 Guía SWEBOK® V3.0
4.1.3. Densidad de fallos
[1 *, c13s4] [9 *, c4]
Un programa bajo prueba se puede evaluar por recuento fallos
descubiertos como la relación entre el número de fallos encontrados y
el tamaño del programa.
4.1.4. Prueba de vida, Evaluación Fiabilidad  dependiendo de cuáles y cuántos de los defectos artificiales se presen-
[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 gene- ral, que cuando las
fallas que causaron las fallas observadas se han fijado (aunque
algunos modelos también aceptan correcciones imperfectas),
exposiciones de fiabilidad del pro- ducto estimado, en promedio, una
tendencia creciente. Hay muchos modelos de crecimiento fiabilidad
publicados. En particular, estos modelos se dividen en
el fracaso de conteo y tiempo entre fallos modelos.
4.2. La evaluación de las pruebas realizadas
4.2.1. Medidas de cobertura / Minuciosidad  de las diferentes técnicas de prueba. Es importante ser preciso en
[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 flujo del
programa o el porcentaje de requisitos funcionales ejercidas entre los
enumerados en el documento de especificaciones. criterios de
adecuación basados ​en códigos requieren instrumentación apropiada
del programa que se está probando.
4.2.2. Siembra de fallos 
[1 *, c2s5] [9 *, c6]
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,
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
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 fiabili- dad 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.
Proceso 5. Prueba
conceptos de pruebas, estrategias, técnicas, y medi- das
deben integrarse en un definido y
 Software de Pruebas 4-13

proceso controlado. El proceso de prueba es compatible con las el elemento de prueba. la documentación de prueba debe hay que producir

actividades de ensayo y proporciona orientación a los probadores y y actualizada continuamente para el mismo nivel de calidad que los demás

equipos de prueba, desde la planificación de prueba para probar la tipos de documentación en la ingeniería de software. documentación de

evaluación de salida, de tal manera como para ofrecer garantías de que prueba también debe estar bajo el control de la gestión de con- figuración

los objetivos de la prueba se cumplirán de manera tivo costo-effec-. de software (ver el KA Software Configuration Management). Por otra

parte, la documentación de prueba incluye productos de trabajo que

pueden proporcionar material para manuales de usuario y la formación de

5.1. Consideraciones prácticas usuarios.

5.1.1. Actitudes / programación sin ego 

[1 * c16] [9 *, c15] 5.1.5. Desarrollo basado en pruebas 
[1 *, c1s16]
Un elemento importante de la prueba con éxito es una actitud de
colaboración hacia las actividades de prueba y garantía de calidad. Los Basado en pruebas de desarrollo (TDD) se originó como una de las

gerentes tienen un papel clave en la promoción de una recepción prácticas núcleo XP (programación extrema) y consiste en escribir las

favorable en general hacia el descubrimiento fracaso y la corrección pruebas unitarias antes de escribir el código para ensayar (ver Métodos

durante el desarrollo y mantenimiento de software; por ejemplo, ágiles en los modelos de ingeniería de software y métodos KA). De esta

mediante la superación de la mentalidad de código individual ERSHIP manera, TDD desarrolla los casos de prueba como rogate sur- para un

de propia entre los programadores y la promoción de un entorno de documento de especificación de requisitos de software en lugar de como

colaboración con el equipo de responsa- bilidad de anomalías en el una verificación independiente de que el software ha implementado

código. 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

5.1.2. Guías de prueba  tener un impacto positivo en la elaboración de las necesidades del usuario

[1 *, c12s1] [9 *, c15s1] y especificación de requisitos de software.

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 5.1.6. Interna frente del equipo de pruebas independientes 
escenario define casos de prueba basado en escenarios de software [1 *, c16]
especificados.

Formalizar el proceso de prueba también puede implicar la

5.1.3. Gestión de procesos de prueba  formalización de la organización del equipo de pruebas. El equipo de
[1 *, c12] [9 *, c15] 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
actividades de prueba llevados a cabo en diferentes niveles (ver tema 2, los miembros externos (con la esperanza de traer una perspectiva
los niveles de prueba) debe ser organizada en conjunto con las personas, imparcial, independiente), o de ambos miem- interna y externa bras.
herramientas, políticas y medidas en un proceso bien definido que es una Las consideraciones de costos, plazos, niveles de madurez de las
parte integral del ciclo de vida. organizaciones involucradas, y criticidad de la aplicación pueden guiar
la decisión.

5.1.4. Documentación de prueba y productos de trabajo 

[1 *, c8s12] [9 *, c4s5] 5.1.7. Costo / Esfuerzo de estimación y prueba mide Proceso 

La documentación es una parte integral de la ción formalización del [1 *, c18s3] [9 *, c5s7]

proceso de prueba [6, parte 3]. documentos de prueba pueden incluir,

entre otros, el plan de pruebas, especificación de diseño de la prueba, Una serie de medidas relacionadas con los recursos gastados en las

procedimiento de ensayo, la especificación de casos de prueba, registro de pruebas, así como a la relativa eficacia de búsqueda de errores de las

la prueba, y el informe de incidente prueba. El software bajo prueba se diversas fases de prueba, son utilizados por los administradores para

documenta como controlar y mejorar la prueba

4-14 Guía SWEBOK® V3.0
proceso. Estas medidas de prueba pueden cubrir aspectos tales como el
número de casos de prueba especificados, el número de casos de prueba
ejecutados, el número de casos de prueba pasó, y el número de casos de
prueba falló, entre otros.
Evaluación de los informes de las pruebas de fase puede ser
combinarse con el análisis de las causas para evaluar la efectividad del
proceso de Exámenes en la búsqueda de fallos tan pronto como sea
posible. Tal evaluación puede estar asociada con el análisis de riesgos.
Por otra parte, los recursos que merece la pena el gasto en las pruebas
deben ser com- realizó medición con el uso / criticidad de la apli- cación:
diferentes técnicas tienen diferentes costos y el rendimiento de los
diferentes niveles de confianza en la fiabilidad del producto.
5.1.8. Terminación  resultados no deseable. Si se mantiene más de una línea de base del
[9 *, c10s4]
Una decisión debe ser tomada en cuanto a cuánto ing Test- es
suficiente y cuando una etapa de prueba puede ser terminología NAT.
Minuciosidad medidas, tales como la cobertura de código alcanzado o
cobertura funcional, así como estimaciones de la densidad de culpa o
de su confiabilidad operativa, proporcionan un apoyo útil, pero no son
sufi- ciente en sí mismos. La decisión también implica consideraciones
sobre los costes y los riesgos que corren los posibles fallos restantes, a
diferencia de los costos incurridos al continuar la prueba (ver Criterios
de selección Prueba / Criterios de prueba de adecuación en la sección
1.2, Temas clave).
5.1.9. Prueba de reutilización y de prueba Patrones [ 9 *, c2s5]
Para llevar a cabo pruebas o mantenimiento de una forma nizado y
rentable or-, los medios utilizados para probar cada parte del
software deben ser reutilizados de forma sistemática. Un repositorio
de materiales de prueba debe estar bajo el control del software de
gestión de con- 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 probar algunos tipos de
aplicaciones, en determinadas circunstancias, con las motivaciones detrás
de las decisiones tomadas, forman un patrón de prueba que puede en sí
mismo ser documentados para su posterior reutilización en proyectos
similares.
5.2. Las actividades de prueba
Como se muestra en la siguiente descripción, manejo exitoso de
las actividades de prueba depende en gran medida Cess la
gestión de configuración de software pro (véase el software de
configuración Manage- ment KA).
5.2.1. Planificación 
[1 *, c12s1, c12s8]
Al igual que todos los otros aspectos de la gestión de proyectos, se deben
planificar las actividades de prueba. Los aspectos clave de la planificación
de controles incluyen la coordinación de la persona-nel, la disponibilidad
de instalaciones de prueba y equipos, creación y mantenimiento de todos
los docu- mentación relacionada prueba, y la planificación de posibles
software, a continuación, un plan- importante consideración es la que
define el tiempo y el esfuerzo necesarios para garantizar que el entorno de
prueba se establece en la configuración adecuada.
5.2.2. Ensayos caso de la generación [ 1 *, c12s1, c12s3]
Generación de casos de prueba se basa en el nivel de pruebas a
realizar y las técnicas de ensayo particulares. Los casos de
prueba deben estar bajo el con- trol de gestión de configuración
de software e incluir los resultados esperados para cada prueba.
5.2.3. Desarrollo Entorno de prueba 
[1 *, c12s6]
El entorno utilizado para la prueba debe ser com- patible 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 prin- cipio 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
 Software de Pruebas 4-15

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

5.2.5. Resultados de la prueba Evaluación  6. Herramientas de prueba de software

[9 *, c15]
6.1. Herramienta de soporte de pruebas 
Los resultados de las pruebas deben ser evaluados para determinar [1 *, c12s11] [9 *, c5]
si la prueba ha tenido éxito. En la mayoría de los casos, “éxito”
significa que el software lleva a cabo como se esperaba y no tenía Las pruebas requiere muchas tareas intensivas en mano de obra, de

ningún principales resultados inesperados. No todos los resultados funcionamiento ejecuciones numerosos programas Ning, y el manejo de

inesperados son necesariamente defectos, pero en algún momento una gran cantidad de información. herramientas adecuadas pueden aliviar

se determinan a ser simplemente ruido. Antes de que una falla la carga de opera- ciones de oficina, tediosas y hacerlos menos propensos

puede ser eliminado, es necesario un esfuerzo de análisis y a errores. Sofisticación herramientas CATed pueden apoyar el diseño de

depuración de aislar, identificar y describir. Cuando los resultados pruebas y generación de casos de prueba, por lo que es más eficaz.

son particularmente importantes, una junta de revisión formal puede

ser con- Vened para evaluarlas.
6.1.1. Selección de Herramientas 
[1 *, c12s11]

5.2.6. Informe de problemas / prueba de log [ 1 *, c13s9] Orientación a los directores y los probadores 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, ya que la selección de herramientas afecta en

Las actividades de prueba se pueden introducir en un registro de pruebas gran medida la eficiencia y la eficacia de la prueba. Selección de

para identificar cuándo se llevó a cabo una prueba, que se realiza el herramienta depende de la evidencia diversa, tales como las opciones de

examen, lo que la configuración del software se utilizó, y otra identificación desarrollo, los objetivos de evaluación, instalaciones de ejecución, y así

correspondiente infor- mación. resultados de prueba inesperados o sucesivamente. En general, puede no ser una herramienta única que va a

incorrectos pueden ser grabados en un sistema de notificación de satisfacer necesidades particulares, por lo que un conjunto de

problema, los datos para el cual constituye la base para más tarde debug- herramientas podría ser una opción apropiada.

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 6.2. Categorías de Herramientas 
previsto inicialmente. Los informes de ensayo son también aportaciones al

proceso de gestión de solicitudes de cambio (véase Control de la Clasificamos las herramientas disponibles de acuerdo a su
figuración Software Con- en el KA Software Configuration Management). 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

5.2.7. seguimiento de defectos  de un pro- grama, se proporcionan los conductores y los talones

[9 *, c9] para simular llamadas tarde y llamados módulos, respectivamente.

Los defectos pueden ser rastreados y analizados para determinar • generadores de prueba [ 1 *, c12s11] proporcionar tancia asis- en
cuando se introdujeron en el software, por qué fueron creados (por los casos de prueba generación. La gene- ración puede ser al azar,

ejemplo, requisitos de mal definidos, ción incorrecta variable de basado en vía modelo- basa, o una mezcla de los mismos.

declara-, pérdida de memoria, error de sintaxis de programación), y

cuando podían haber sido observado por primera vez en • herramientas de captura / reproducción [ 1 *, c12s11] automática-
mente volver a ejecutarlo, o de repetición, previamente
4-16 Guía SWEBOK® V3.0

pruebas ejecutadas que han grabado las entradas y salidas (por • trazadores [ 1 *, c1s7] registrar la historia de las rutas de ejecución
ejemplo, pantallas). de un programa.
• comparadores de Oracle / archivo / afirmación herramientas de • herramientas de pruebas de regresión [ 1 *, c12s16] apoyar la
comprobación [ 1 *, c9s7] ayudar a decidir si un resultado de la ejecución adicional de un conjunto de pruebas después de una

prueba es exitosa o no. sección del software ha sido modificado. También pueden ayudar a

• analizadores de cobertura y instrumenters [ 1 *, c4] trabajar seleccionar un subconjunto de pruebas de acuerdo con el cambio

juntos. analizadores de cobertura evaluar qué y cómo se han realizado.

ejercido muchas entidades de la gráfica de flujo del programa • herramientas de evaluación de la fiabilidad [ 9 *, c8] prueba apoyo
entre todos los requeridos por el criterio de cobertura de resultados de análisis y ción visualiza- gráfica a fin de evaluar medi-

prueba seleccionada. El análisis se puede hacer gracias a das relacionadas fiabilidad-de acuerdo con los modelos

instrumenters que insertan sondas de grabación en el código seleccionados.

del programa.
 Software de Pruebas 4-17

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Naik y Tripathy 2008

Sommerville 2011

Nielsen 1993
Kan 2003

[10 *]
[9 *]
[2 *]
[1 *]
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 las pruebas /

c1s14, c6s6,
Criterios prueba de adecuación (Reglas de
c12s7
parada)

1.2.2. Los tests de efectividad / Objetivos

c13s11, c11s4
para las pruebas

1.2.3. Las pruebas para detectar

c1s14
defectos de Identificación

c1s9,
1.2.4. El problema de Oracle
c9s7

1.2.5. Limitaciones teóricas y prácticas

c2s7
de las Pruebas

1.2.6. El problema de no factibles Caminos

c4s7

1.2.7. la capacidad de prueba c17s2

1.3. Relación de las pruebas a otras

actividades

1.3.1. Las pruebas estáticas vs Software

Técnicas de Gestión de Calidad c12

1.3.2. Las pruebas de exactitud frente a

c17s2
pruebas y verificación formal

1.3.3. Prueba de depuración vs. c3s6

1.3.4. Las pruebas contra Programación c3s2

2. Niveles de prueba

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

4-18 Guía SWEBOK® V3.0

Naik y Tripathy 2008

Sommerville 2011

Nielsen 1993
Kan 2003

[10 *]
[9 *]
[2 *]
[1 *]
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 fiabilidad y

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. Usabilidad y Human

c6
Computer Interaction Testing

3. Técnicas de Prueba

3.1. Sobre la base de la intuición y la

experiencia del ingeniero de software

3.1.1. Ad hoc

3.1.2. Prueba exploratoria

3.2. Las técnicas basadas en el

dominio de entrada

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 frontera c9s5

3.2.4. Pruebas al azar c9s7

3.3. Técnicas de código-base

3.3.1. Criterios basados ​en el flujo de

c4
control
 Software de Pruebas 4-19

Naik y Tripathy 2008

Sommerville 2011

Nielsen 1993
Kan 2003

[10 *]
[9 *]
[2 *]
[1 *]
3.3.2. Criterios basados ​en el flujo de datos c5

3.3.3. Modelos de referencia de las

c4
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 observación

C5, C7
del usuario

3.6. Técnicas de ensayo basado en

modelos

3.6.1. Tabla de decisión c9s6

3.6.2. Las máquinas de estados finitos c10

3.6.3. Pruebas de especificaciones

c10s11 c15
formales

3.7. Las técnicas basadas en la

naturaleza de la aplicación

3.8. La selección y 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 de la prueba el marco del

Programa

4.1.1. Las mediciones de programas que

ayudan en la planificación y ensayo de c11

Proyectos

4.1.2. FALLO Tipos, clasificación y

c4
estadísticas

4.1.3. Densidad de fallos c13s4 c4

4.1.4. Prueba de vida, Evaluación

c15 c3
Fiabilidad

4.1.5. Los modelos de crecimiento fiabilidad c15 c8

4-20 Guía SWEBOK® V3.0

Naik y Tripathy 2008

Sommerville 2011

Nielsen 1993
Kan 2003

[10 *]
[9 *]
[2 *]
[1 *]
4.2. La evaluación de las pruebas
realizadas

4.2.1. Medidas de cobertura /

c11
Minuciosidad

4.2.2. Siembra de fallos c2s5 c6

4.2.3. Puntuación mutación c3s5

4.2.4. La comparación y la eficacia

relativa de las diferentes técnicas

Proceso 5. Prueba

5.1. Consideraciones prácticas

5.1.1. Actitudes / programación

c16 c15
sin ego

5.1.2. Guías de prueba c12s1 c15s1

5.1.3. Gestión de procesos de prueba c12 c15

5.1.4. Documentación de prueba y productos

c8s12 c4s5
de trabajo

5.1.5. Desarrollo basado en pruebas c1s16

5.1.6. Interna frente del equipo de pruebas

c16
independientes

5.1.7. Costo / estimación de esfuerzo y otras

c18s3 c5s7
medidas de proceso

5.1.8. Terminación c10s4

5.1.9. Prueba de Reutilización y Patrones c2s5

5.2. Las actividades de prueba

c12s1
5.2.1. Planificación
c12s8

c12s1
5.2.2. Generación de casos de prueba
c12s3

5.2.3. Desarrollo Entorno de

c12s6
prueba

5.2.4. Ejecución c12s7

5.2.5. Resultados de la prueba Evaluación c15

 Software de Pruebas 4-21

Naik y Tripathy 2008

Sommerville 2011

Nielsen 1993
Kan 2003

[10 *]
[9 *]
[2 *]
[1 *]
5.2.6. Informe de problemas / Registro de
c13s9
Pruebas

5.2.7. seguimiento de defectos C9

6. Herramientas de prueba de software

6.1. Herramienta de soporte de pruebas c12s11 c5

6.1.1. Selección de Herramientas c12s11

c1s7, c3s9, c4,

c9s7,
6.2. Categorías de Herramientas c8
c12s11,
c12s16
4-22 Guía SWEBOK® V3.0

Referencias

[1 *] S. Naik y P. Tripathy, Pruebas de software  [8] S. Yoo y M. Harman, “pruebas de regresión

y aseguramiento de la calidad: teoría y
práctica, Wiley-Spektrum, 2008.
[2 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[3] MR Lyu, ed., Manual de Software  Ingeniería de calidad, 2ª ed., Addison-Wesley,
Ingeniería de Confiabilidad, McGraw-Hill y IEEE
Computer Society Press, 1996.
[4] H. Zhu, PAV Hall y JHR mayo,
“Unidad de Software Cobertura de la prueba y suficiencia” ACM
Computing Surveys, vol.
29, no. 4, diciembre de 1997 pp. 366-427.
[5] EW Dijkstra, “Notas sobre Estructurado
Programación,”Informe TH-70-WSE-03, Universidad
Tecnológica de Eindhoven, 1970;
http://www.cs.utexas.edu/users/EWD/ ewd02xx /
EWD249.PDF .
[6] ISO / IEC / IEEE P29119-1 / DIS Proyecto de Norma 
para software y sistemas de Engineering- pruebas de
software-Parte 1: Conceptos y definiciones, ISO / IEC /
IEEE 2012.
[7] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
Minimización, selección y priorización: una encuesta,” Pruebas
de verificación de software y fiabilidad, vol. 22, no. 2,
marzo 2012, pp. 67-120.
[9 *] SH Kan, Métricas y modelos de software 
2002.
[10 *] J. Nielsen, Ingeniería de la Usabilidad, Morgan
Kaufmann, 1993.
[11] TY Chen et al, “Adaptive Pruebas al Azar.:
El arte de caso de prueba Diversidad” Diario de sistemas
y software, vol. 83, no. 1, enero
2010, pp. 60-66.
[12] Y. Jia y M. Harman, “An Analysis
y la Encuesta de Desarrollo de pruebas de mutación” IEEE
Trans. Ingeniería de software, vol. 37, no. 5, Sep.-Oct.
2011, pp. 649-678.
[13] M. Utting y B. Legeard, Práctico 
Basado en modelos de prueba: Un Enfoque de herramientas,
Morgan Kaufmann, 2007.
 CAPÍTULO 5
MANTENIMIENTO DEL SOFTWARE
SIGLAS
SEÑOR Solicitud de modificación PR
Problema Informe del
Configuración del software de
SMC
Gestión de SLA
Servicio de nivel Acuerdo SQA
Software Quality Assurance 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 paradigma de código abierto ha
traído más aten- ción a la cuestión del mantenimiento de artefactos de
software desarrollados por otros. En esto Guía, mantenimiento del
software se define como el conjunto de actividades necesarias para
proporcionar soporte rentable de software. Las actividades se llevan a
cabo durante la etapa de pre-entrega, así como
5-1
durante la etapa de posparto. actividades antes de la entrega incluyen la
planificación para las operaciones de posparto, el mantenimiento, y la
determinación de la logística para las actividades de transición [1 *,
c6s9]. posparto actividades incluyen la modificación de software,
capacitación y operativo o interfaz con una mesa de ayuda. El área de
conocimiento de mantenimiento de software (KA) se relaciona con todos
los demás aspectos de la ingeniería de software. Por lo tanto, esta
descripción KA está vinculado a todos los demás de ingeniería de
software de la KAs Guía.
DISTRIBUCIÓN DE TEMAS PARA
MANTENIMIENTO DE SOFTWARE
El desglose de temas para el manteni- Software Principal- KA se
muestra en la Figura 5.1.
1. Fundamentos de mantenimiento de software
Esta primera sección presenta los conceptos y terminología que forman
una base subyacente a la comprensión de la función y el alcance del
mantenimiento del software. Los temas proporcionan definiciones y
hacer hincapié en por qué hay una necesidad de mantenimiento.
Categorías de mantenimiento de software son fundamentales para la
comprensión de su significado subyacente.
1.1. Definiciones y terminología
[1 *, c3] [2 *, c1s2, C2S2]
El propósito del mantenimiento del software se define en el estándar
internacional para el mantenimiento de software: ISO / IEC / IEEE
14764 [1 *]. 1 En el contexto de la ingeniería de software,
mantenimiento de software es esencialmente uno de los muchos
procesos técnicos.
1 A los efectos de la concisión y la facilidad de lectura ing, esta norma
se refiere simplemente como IEEE 14764 en el texto subsiguiente de
esta KA.
5-2 Guía SWEBOK® V3.0
Figura 5.1. Desglose de temas para el mantenimiento del software KA
El objetivo del mantenimiento del software es modificar el
software existente, preservando su 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 de los cambios propuestos, código de software y
otros artefactos son
modificada, la prueba se lleva a cabo, y una nueva versión del
producto de software es liberado. Además, forma- ción y apoyo diario
se proporcionan a los usuarios. El termino 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 desarrollador inicial no puede ser
alcanzado o ha pasado a otras tareas, lo que crea un desafío
adicional para man- recipientes. El mantenimiento debe tener
artefactos de software de desarrollo (por ejemplo, código o docu-
mentación) y apoyarlos de inmediato, y luego evolucionar
progresivamente / mantenerlas durante un ciclo de vida del
software.
1.3. La necesidad de mantenimiento  mantenimiento de software puede ayudar a contener los costos. Algunos
[2 *, c1s5]
El mantenimiento es necesario para asegurar que el software continúa
para satisfacer las necesidades del usuario. manteni- miento es aplicable
al software que se desarrolla utilizando cualquier modelo de ciclo de vida
del software (por ejemplo, espiral o lineal). productos de software
cambian debido a las acciones correctivas y de software noncorrective.
Mantenimiento debe ser realizado con el fin de
• corregir fallas;
• mejorar el 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;
• mantener controlar encima 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
• la prevención de rendimiento del software de la degradación
a niveles inaceptables.
1.4. La mayoría de los costos de mantenimiento  14764 incluye una cuarta categoría-preventivo.
[2 *, c4s3, c5s5.2]
Mantenimiento consume una parte importante de los recursos finan- ciales
en un ciclo de vida del software. Una común
El software de mantenimiento 5-3
percepción de mantenimiento del software es que se limita a fijar los
fallos. Sin embargo, estudios y encuestas realizadas a lo largo de los
años han indicado que la dad de División, más del 80 por ciento, del
mantenimiento del software se utiliza para acciones noncorrective [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
factores medioambientales y su relación con los costos de
mantenimiento de software incluyen los siguientes:
• Entorno de funcionamiento se refiere a hardware y
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 desa-
rrollo 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 soft- ware 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 perfec- tivo [2 *, c4s3]. IEEE
• El mantenimiento correctivo: modifica- ción reactiva (o
reparación) de un producto de software
5-4 Guía SWEBOK® V3.0
realizado después de la entrega para corregir problemas Ered
descu-. Se incluyen en esta categoría es el mantenimiento de
emergencia, que es una modificación no programada se realiza
para mantener temporariamente un producto de software en
funcionamiento en espera de mantenimiento correctivo.
• mantenimiento adaptativo: modificación de un producto de
software se realiza después de la entrega para mantener un
producto de software que puedan utilizarse en un entorno
cambiante o cambiar. Por ejemplo, el sistema operativo puede
ser actualizado y algunos cambios en el software puede ser
necesario.
• mantenimiento perfectivo: modificación de un producto de
software después de la entrega para proporcionar mejoras
para los usuarios, mejora de la documentación del programa, y
​la recodificación para mejorar el rendimiento del software,
capacidad maintain-, u otros atributos de software.
• El mantenimiento preventivo: modificación de un producto de
software después del parto para detectar fallas latentes y
correctas en el producto de software antes de que sean fallos de
funcionamiento.
IEEE 14764 clasifica mantenimiento adaptativo y perfectivo
como mejoras de mantenimiento. También agrupa a las
categorías de mantenimiento tiva correctivas y prevención en una
corrección CAT- goría, como se muestra en la Tabla 5.1.
Tabla 5.1. Mantenimiento de Software Categorías
Mejora de la corrección
Proactivo Preventivo perfectivo
Reactivo Correctivo Adaptado
2. Temas clave en el mantenimiento de software
Una serie de cuestiones clave debe ser tratada para garantizar el
mantenimiento eficaz de 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 otro ingeniero
de software desarrollados. Del mismo modo, compitiendo con los
desarrolladores de software de recursos es una batalla constante.
La planificación de una versión futura, que a menudo incluye la
codificación
próximo lanzamiento, mientras que el envío de parches de emergencia
para la versión actual, también crea un desafío. En la siguiente sección
se presentan algunos de los problemas gías Nical y de gestión
relacionados con el mantenimiento del software. Se han agrupado bajo
los siguientes encabezados de los temas:
• problemas técnicos,
• asuntos Gerenciales,
• estimación de costos, y
• medición.
2.1. Problemas técnicos
2.1.1. La comprensión limitada 
[2 *, c6]
comprensión limitada se refiere a la rapidez con que un ingeniero de
software puede entender que para hacer un cambio o corrección en el
software que él o ella no se desarrolló. Las investigaciones indican que
aproximadamente la mitad del total del esfuerzo de mantenimiento se
dedica a pie Adjunto del software para ser modificado. Por lo tanto, el
tema de la comprensión de software es de gran inter est a los ingenieros
de software. La comprensión es más difícil en el código fuente de la
representación en orientada a texto, por ejemplo, donde a menudo es
difícil trazar la evolución del software a través de sus publicaciones /
versiones si los cambios no están documentados y si los desarrolladores
no están disponibles a lo explican, lo que suele ser el caso. Por lo tanto,
los ingenieros de software pueden ini- cialmente tienen una comprensión
limitada del software; aún queda mucho por hacer para remediar esto.
2.1.2. Pruebas
[1 *, c6s2.2.2] [2 *, c9]
El costo de la repetición de la prueba completa 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 selec- tiva de software o un componente de ver- ify que las
modificaciones no han causado efectos unin- cuidados) es un concepto
importante en las pruebas de mantenimiento. 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 sigue siendo un desafío.
Cuando el software realiza fun- ciones críticos, puede ser difícil para
llevarlo fuera de línea para la prueba. Las pruebas no se pueden
ejecutar en el lugar-ful el sistema de producción más sentido-. La
Prueba KA Software proporciona información y referencias adicionales
sobre este asunto en su subtema en las pruebas de regresión.
2.1.3. Análisis de impacto [ 1 *, c5s2.5] [2 *, c13s3]
Análisis de impacto describe cómo llevar a cabo, de manera rentable,
un análisis completo del impacto de un cambio en el software
existente. Mantenedores deben poseer un conocimiento profundo de
la estructura y el contenido del software. Ellos usan este conocimiento
para llevar a cabo análisis de impacto, que identifica a 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 el cambio. Además, se determina el
riesgo de hacer el cambio. La solicitud de cambio, a veces se llama
una petición de modificación (MR) y, a menudo llamado un informe de
problemas (PR), primero debe ser analizado y traducido en términos
de software. Análisis de impacto se realiza después de una solicitud
de cambio entra en el proceso de gestión de la configuración soft-
ware. IEEE 14764 establece las tareas de análisis de impacto:
• analizar MRs / IPs;
• replicar o verificar el problema;
• desarrollar opciones para la aplicación de la
modificación;
• documentar el MR / PR, los resultados y las opciones de
ejecución;
• obtener la aprobación de la opción de modificación seleccionado.
La gravedad de un problema a menudo se utiliza para decidir
cómo y cuándo va a ser fijo. El ingeniero de soft- ware a
continuación, identifica los componen- tes afectados. Se
proporcionan varias soluciones posibles, seguido de una
recomendación sobre el mejor curso de acción.
Software diseñado con capacidad de mantenimiento en mente facilita
en gran medida el análisis del impacto. más infor- mación se puede
encontrar en el software de gestión de la configuración KA.
El software de mantenimiento 5-5
2.1.4. mantenibilidad [ 1 *, c6s8] [2 *, c12s5.5]
IEEE 14 764 [1 *, c3s4] define mantenibilidad como la capacidad del
producto de software para ser modificado. Las modificaciones
pueden incluir correcciones, mejoras, o la adaptación del software a
cambios en el entorno, así como cambios en los requisitos y
especificaciones funcionales. Como una característica de calidad del
software principal, capacidad de mantenimiento se debe especificar,
revisado y controlado durante los lazos de desarrollo de software
activi- el fin de reducir los costes de mantenimiento. Cuando se hace
correctamente, el mantenimiento del software mejorará. La
mantenibilidad es a menudo difícil de lograr debido a las
subcaracterísticas menudo no son un foco importante durante el
proceso de desarrollo de soft- ware. Los desarrolladores están, por
lo general, más preocupados con muchas otras actividades y con
frecuencia propensos a ignorar las exigencias del mantenedor. Esto
a su vez puede, ya menudo lo hace, dar lugar a una falta de
documentación de software y entornos de prueba, que es una de las
principales causas de los lazos dificultades en la comprensión del
programa y análisis de impacto posterior. La presencia de procesos
sistemáticos y maduros, técnicas y herramientas de ayuda para
mejorar la capacidad de mantenimiento de software.
2.2. Asuntos Gerenciales
2.2.1. La alineación con los objetivos
organizacionales 
[2 *, c4]
objetivos de la organización describen cómo 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.
5-6 Guía SWEBOK® V3.0
2.2.2. dotación de personal
[2 *, c4s5, c10s4]
Dotación de personal se refiere a la manera de atraer y mantener al
personal de mantenimiento soft- ware. El mantenimiento no es a menudo
visto como un trabajo glamoroso. Como resultado, el personal de
mantenimiento de software son frecuentemente vistos como “ciudadanos
de segunda clase”, y por lo tanto, la moral se resiente.
2.2.3. Proceso
[1 *, c5] [2 *, c5]
El proceso del ciclo de vida del software es un conjunto de actividades,
métodos, prácticas y 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  2.3. Estimación de costes 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;
• promueve una atmósfera sin ego, universitarios;
• reduce la dependencia de los individuos;
• permite controles de auditoría periódicas.
Puesto que hay muchos pros y los contras de cada opción, la
decisión debe hacerse sobre una base de caso por caso. Lo que es
importante es la delegación o
asignación de la responsabilidad de mantenimiento a un solo grupo o
persona, independientemente de la estructura de la organiza- ción.
2.2.5. La externalización
[3 *]
La externalización y la deslocalización de software manteni- miento 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 ser- vicio, 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.
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 iden- tifica 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 paramétricos
[2 *, c12s5.6]
el modelo de costos paramétricos (modelos matemáticos) se ha
aplicado al mantenimiento del software. De significación es que se
necesitan datos históricos del pasado de manteni- miento con el fin de
usar y calibrar los modelos matemáticos. atributos generador de
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
expe- riencia. 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
[2 *, c12]
El mantenedor debe determinar qué medidas son adecuadas para
una organización específica basada en el propio contexto de esa
organización. El software
El software de mantenimiento 5-7
modelo de calidad sugiere medidas que son específicos para el
mantenimiento del software. Medidas para la carac- subchar- de
mantenimiento incluyen la si- guiente [4 *, p. 60]:
• 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 comporta- miento inesperado de
software, incluidos los que se encontró durante la prueba.
• La capacidad de prueba: medidas del mantenedor del esfuerzo y de
los usuarios en el intento de probar el software modificado.
• Otras medidas que utilizan los mantenedores incluyen
• tamaño del software,
• complejidad del software,
• comprensibilidad, y
• facilidad
mantenimiento.
de
Proporcionar esfuerzo de mantenimiento de software, por categorías,
para diferentes aplicaciones proporciona información de la empresa a los
usuarios y sus organiza- ciones. También puede permitir la comparación
de los perfiles de mantenimiento soft- ware 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,
5-8 Guía SWEBOK® V3.0

• opinión de mantenimiento / aceptación, actividades y tareas son responsabilidad del mantenedor. Como ya se ha
• migración y señalado, muchas actividades de mantenimiento son similares a las del
• Retirada del software. software de Desa- ción. Mantenedores de realizar el análisis, diseño, ing
de bacalao, pruebas y documentación. Deben realizar un seguimiento de
los requisitos en sus actividades 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.

Figura 5.2. Proceso de Mantenimiento de Software • Transición: una secuencia controlada y coordinada de las
actividades durante el cual el software se transfiere
Otros modelos de procesos de mantenimiento incluyen: progresivamente de la oper desa- al mantenedor.

• arreglo rapido, • solicitud de modificación de la aceptación / rechazo: modificaciones

• espiral, que solicitan trabajo más allá de un CER Tain tamaño / esfuerzo /

• Osborne, complejidad pueden ser rechazados por los mantenedores y son

• mejora iterativa, y redirigidos a un desarrollador.

• reutilizar-orientado. • Mantenimiento de mesa de ayuda: un usuario final y la función de

soporte de mantenimiento coordinado que desencadena la
Recientemente, metodologías ágiles, que promueven los procesos evaluación, priorización y cálculo de costos de las solicitudes de
de luz, también se han adaptado a mante- manteni-. Este requisito modificación.
surge de la creciente demanda en constante para la entrega rápida • Análisis de impacto: una técnica para identificar las áreas afectadas

de los servicios de manteni- miento. Mejoras para el proceso de por un cambio potencial;

mantenimiento del software se apoya en modelos especializados • Acuerdos de mantenimiento de nivel de servicio (SLA) y
capacidad de mantenimiento de software de vencimiento (ver [6] y licencias de mantenimiento y con- tratos: acuerdos
[7], que están anotados brevemente en la sección Lecturas Además). contractuales que describen los servicios y los objetivos
de calidad.

3.2.2. Las actividades que apoyen

3.2. Actividades de mantenimiento[ 1 *, c5, c6s8.2, c7s3.3] [1 *, c4s1, c5, c6s7] [2 *, c9]

Mantenedores también pueden realizar actividades de apoyo, como

El proceso de mantenimiento contiene las actividades y tareas la documentación, gestión de configuración de software, verificación
necesarias para modificar un producto soft- ware existente, y validación, resolución de problemas, el software de control de
preservando su integridad. Estas calidad, revisión,

y las auditorías. Otra actividad importante apoyo consiste en la
formación de los mantenedores y usuarios.
3.2.3. Actividades de mantenimiento Planificación
[1 *, c7s3]
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 manteni- miento 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, seguido de un plan de mantenimiento. El concepto
de mantenimiento para cada producto de software debe ser documentado
en el plan [1 *, c7s2] y debe hacer frente a la
• ámbito del mantenimiento de software,
• la adaptación del proceso de mantenimiento de software,
El software de mantenimiento 5-9
• identificación de la organización de mantenimiento de
software, 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
modifi- caciones 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 manteni- miento. 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 pro- ceso SMC se
implementa mediante el desarrollo y siguiendo los 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 determinar el contenido de la próxima versión / versión.
5-10 Guía SWEBOK® V3.0
3.2.5. Calidad del software
[1 *, c6s5, c6s7, c6s8] [2 *, c12s5.3]
No es suficiente con la esperanza de que una mayor calidad tendrá
como resultado del mantenimiento de soft- ware. Mantenedores
deben tener un programa de cali- dad de software. Se debe
planificarse y procesos debe ser implementado para apoyar el
proceso de mantenimiento. Las actividades y técnicas para la Cesión
de Software Quality Assurance (SQA), V & V, opiniones y auditorías
deben ser seleccionados de común acuerdo con todos los demás
procesos para alcanzar el nivel deseado de calidad. También se
recomienda que el tainer man- adaptar el desarrollo de software
procesos, técnicas y resultados (por ejemplo, la documentación de la
prueba), y los resultados de las pruebas. Más detalles se pueden
encontrar en la calidad del software KA.
4. Técnicas de Mantenimiento
Este tema se presentan algunas de las técnicas generalmente aceptados
utilizados en el mantenimiento del software.
4.1. programa de Comprensión
[2 *, c6, c14s5]
Los programadores pasan considerable tiempo a la lectura y la
comprensión de los programas con el fin de implementar los cambios.
navegadores de código son herramientas clave 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 trata de
mejorar una estructura pro- grama y su facilidad de mantenimiento. ING
técnicas Refactor- se pueden utilizar durante los cambios de menor
importancia.
4.3. Ingeniería inversa[ 1 *, c6s2] [2 *, c7, c14s5]
La ingeniería inversa es el proceso de análisis de software para
identificar los componentes del software y sus interrelaciones y
crear representaciones del software en otra forma o en los
niveles más altos de abstracción. Reverse Engineer- ing es
pasivo; no cambia el software o dar lugar a un nuevo software.
Invertir Engineer- esfuerzos ing producen gráficos de llamada y
gráficos de flujo de control de código fuente. Un tipo de
ingeniería inversa es redocumentación. Otro tipo es la
recuperación de diseño. Por último, los datos inversa inge-
niería, donde los esquemas lógicos son recuperados de bases
de datos físicos, ha crecido en importancia en los últimos años.
Las herramientas son clave para inge- niería inversa y tareas
relacionadas, como redocumenta- ción y recuperación de
diseño.
4.4. Migración
[1 *, c5s5]
Durante la vida de software, que puede tener que ser modificada
convenientemente para funcionar en entornos diferentes. Con el fin de
migrar a un nuevo entorno, el responsable tiene que determinar las
acciones necesarias para la migración cumpla cabalmente, y luego
desarrollar y docu- mento los pasos necesarios para llevar a cabo la
migración en un plan de migración que cubre la migración tos requisitos,
herramientas de migración, conversión de producto y datos, la ejecución,
la verificación, y el 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;

• opinión después de la operación: una evaluación de la
operación parale- y el impacto del cambio al nuevo
entorno;
• archivado de datos: almacenamiento de los datos del software de edad.
4.5. Jubilación  conocer la vía de ejecución de un programa;
[1 *, c5s6]
Una vez que el software ha alcanzado el final de su vida ful uso-,
debe ser retirado. Un análisis debe llevarse a cabo para ayudar a
tomar la decisión de retiro. Este análisis debe ser incluido en el
plan de retiro, que cubre mentos de jubilación requisitos, el
impacto de reemplazo, calendario, y esfuerzo. Accesibilidad de
copias de archivo de datos también puede ser incluido. Retirarse
de software conlleva una serie de actividades similares a la
migración.
5. Herramientas de Mantenimiento de Software
[1 *, c6s4] [2 *, c14]
Este tema abarca herramientas que son particularmente importantes en el
mantenimiento de software donde se está modificando el software existen-
ing. Ejemplos CON RESPECTO A comprensión del programa incluye
El software de mantenimiento 5-11
• rebanadoras de programas, que seleccionan sólo partes de un
programa afectado por un cambio;
• analizadores estáticos, que permiten ing vista- general y
resúmenes de un contenido del programa;
• analizadores dinámicos, que permiten al tainer man-
• analizadores de flujo de datos, que permiten al tainer man- realizar
el seguimiento de todos los posibles flujos de datos de un programa;
• cruzadas referencers, que generan los índices de los
componentes del programa; y
• analizadores de dependencia, que ayudan a ERS maintain-
analizar y comprender las interrelaciones entre los
componentes de un programa.
Herramientas de ingeniería inversa ayudan al proceso trabajando
hacia atrás desde un producto existente para crear artefactos tales como
especificación y diseño descripciones, que a continuación se pueden
transformar para generar un nuevo producto de una antigua. Principal-
también utilizan recipientes de prueba de software, gestión de con-
figuración de software, documentación de software y herramientas de
medición de software.
5-12 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

IEEE / ISO / IEC 14764 2006

Grubb y Takang 2003

Sneed 2008
[3 *]
[2 *]
[1 *]
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 mantenimiento c4s3, c5s5.2

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. Alineamiento con los objetivos

c4
organizacionales

2.2.2. dotación de personal c4s5, c10s4

2.2.3. Proceso c5 c5

2.2.4. Aspectos de organización de

c7s.2.3 c10
Mantenimiento

2.2.5. Subcontrataciones / Offshoring todas

2.3. Estimación de costes de mantenimiento

2.3.1. Estimación de costos c7s4.1 c7s2.4

 El software de mantenimiento 5-13

IEEE / ISO / IEC 14764 2006

Grubb y Takang 2003

Sneed 2008
[3 *]
[2 *]
[1 *]
2.3.2. Los modelos paramétricos c12s5.6

2.3.3. Experiencia c12s5.5

2.4. Medición de mantenimiento de

c6s5 c12, c12s3.1
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. Actividades de mantenimiento

c7s2, c7s.3
Planificación

3.2.4. Gestión de la Configuración de

c5s1.2.3 c11
Software

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 de Software c6s4 c14

5-14 Guía SWEBOK® V3.0
LECTURAS
A. abril y A. Abran, Mantenimiento del software  [1 *] IEEE Std. 14764-2006 (también conocido como ISO / IEC
Gestión: Evaluación y Mejora Continua [ 6].
Este libro explora el dominio de los procesos de mantenimiento de
software pequeños (S3M). Proporciona mapas ROAD- para mejorar
cesos pro de mantenimiento de software en las organizaciones. En
él se describe un modelo de madurez específica mantenimiento de
software organizada por niveles que permiten la evaluación
comparativa y la mejora continuas con. Metas para cada área clave
Tice prác- se proporcionan, y el modelo de proceso de pre-tantes
está totalmente alineado con la arquitectura y el marco de las
normas ISO12207 internacional ISO14764 y ISO15504 y modelos de
madurez populares como ITIL, COBIT, CMMI y CM3.
M. Kajko-Mattsson, “Hacia un Modelo de Negocio de
Mantenimiento,” IEEE Int'l Conf. Mantenimiento
Software [7].
Este artículo presenta una visión general del modelo de madurez de
mantenimiento correctivas (cm3). A diferencia de otros modelos de
procesos, CM3 es un modelo espe- cializada, dedicado
exclusivamente al mantenimiento correctivo del software. Se
considera que el mantenimiento en términos de las actividades a
realizar y su orden, en función de la información 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.
Referencias
 
14764: 2006) estándar para el software de ingeniería
en software de ciclo de vida Procesos de
mantenimiento, IEEE 2006.
[2 *] P. Grubb y AA Takang, Software 
Mantenimiento: Conceptos y práctica, 2ª ed.,
Editorial Científico Mundial, 2003.
[3 *] HM Sneed “, software de Oferta
Mantenimiento como un servicio Marino,” Proc. IEEE Conf
Int'l. Mantenimiento del software
(ICSM 08), IEEE, 2008, pp. 1-5.
[4 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
Wiley-IEEE Computer Society Press, 2006.
[5] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
[6] A. abril y A. Abran, Software 
Gestión de Mantenimiento: evaluación y mejora
continua, Wiley-IEEE Computer Society Press,
2008.
[7] M. Kajko-Mattsson, “Hacia un negocio
Mantenimiento Modelo” Proc. Int'l Conf.
Mantenimiento del software, IEEE, 2001, pp. 500-509.
 CAPÍTULO 6
Software Configuration Management
SIGLAS
CCB Configuración de la tarjeta de control CM
Configuración de Gestión de la FCA
PCA Auditoría de Configuración Funcional
Auditoría de Configuración física
Software de configuración de la tarjeta de control
SCCE
SCI
Software SMC elemento de configuración
Configuración del software de
gestión PGCS
Plan de Gestión de la
Configuración de Software SCR
Solicitud de cambio de software SCSA
Software Estado de Configuración de
contabilidad SDD
El software de diseño de documentos SEI
/ CMMI Madurez de Capacidades del Software
Engineering Institute Modelo de Integración SQA
Software Quality Assurance SRS
Software de especificación de
requisitos
INTRODUCCIÓN
Un sistema puede ser definido como la combinación de elementos
organizados para lograr uno o más propósitos declarados [1]
interactuar. La configuración de un sistema es la carac- terísticas
funcionales y físicas de hardware o software que se exponen en
técnica- cal documentación o conseguidos en un producto [1]; También
se puede considerar como una colección de versiones específicas de
hardware, firmware, software o elementos combinados de acuerdo a los
procedimientos específicos de construcción
6-1
para servir a un propósito particular. Configuración hombre-agement
(CM), a continuación, es la disciplina de que identifique los valores de la
configuración de un sistema en distintos puntos en el tiempo con el fin
de sistemáticamente control- ling cambios en la configuración y el
mantenimiento de la integridad y la trazabilidad de la configuración de
todo el ciclo de vida del sistema. Se define formalmente como
Una disciplina aplicando dirección adminis- tración y
técnica y vigilancia a: tificar iden- y documentar las
características funcionales y cal Physicians de un
elemento de configuración, los cambios de control a las
características, el procesamiento y la aplicación de registro
y cambio de informe de estado, y verifican El cumplimiento
con los requisitos especificados. [1]
gestión de configuración de software (SCM) es un proceso de
ciclo de vida del software de apoyo que beneficia a las actividades
de gestión de proyectos, desarrollo y mantenimiento, actividades de
aseguramiento de la calidad, así como los clientes y usuarios del
producto final.
Los conceptos de gestión de la configuración se aplican a todos los
artículos que deben ser controlados, aunque hay algunas diferencias en
la implementación de hardware entre el CM y CM software. SMC está
estrechamente relacionado con el aseguramiento de la cali- dad (SQA)
actividad de software. Tal como se define en el área de conocimiento de
Calidad de Software (KA), SQA procesos garantizan que los productos de
software y procesos en el ciclo de vida del proyecto se ajustan a sus
requerimientos especificados por la planificación, la promulgación, y la
realización de un conjunto de actividades para proporcionar la confianza
adecuada de que la calidad se está construyendo en el software.
actividades de SCM ayudan en el cumplimiento de estos objetivos SQA.
En algunos contextos pro- yecto, los requisitos específicos SQA
prescriben ciertas actividades de SCM.
6-2 Guía SWEBOK® V3.0
Figura 6.1. Desglose de temas para el Software Configuration Management KA
Las actividades de la SCM son la gestión y la Planificación del
proceso de SMC, identificación de la configuración de software, el
control de la 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 información de
configuración. Desde la perspectiva del ingeniero de software, SCM
facilita
el desarrollo y el cambio aplicación activi- 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 responsabili- dad para realizar ciertas tareas
SCM podría ser asignado a otras partes de la organización (por
ejemplo, la organización de desarrollo), el responsa- bilidad global
para SCM menudo recae en un elemento zational orga- distinta o
persona designada. El software se desarrolló con frecuencia como
parte de un sistema más grande que contiene los elementos de
hardware y firmware. En este caso, las actividades se llevan a cabo
SCM

en paralelo con hardware y firmware CM activi- dades y deben
ser compatibles con el sistema de nivel
CM. Tenga en cuenta que el firmware contiene hardware y software;
Por lo tanto, ambos conceptos CM de hardware y software son
aplicables.
SMC podría interactuar con la actividad de 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
desa- rrollo, el mantenimiento y los propósitos de SCM.
1.2. Limitaciones y orientación para el proceso SMC  de la evolución de versiones de archivo fuente [1]. La fusión consiste
[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 pro- ceso 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 el nivel de formalismo seleccionado
para implementar el software afecta al diseño y la implementación
del proceso de SMC.
Una guía para el diseño y la implementación de un proceso de SMC
también se puede obtener de “mejores prácticas”, como se refleja en
las normas sobre el software
Configuración del software 6-3 Gestión
ingeniería emitido por las diversas normas orga- nizaciones
(ver Apéndice B de las normas).
1.3. La planificación de SMC 
[2 *, c6, Ann. D, Ann. E] [3 *, c23] [4 *, c29]
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
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.
1.3.1. Organización y responsabilidades SMC
[2 *, Ann. DS5, Ann. DS6] [3 *, c10-11]
[4 *, introducción, c29]
Para evitar la confusión sobre quién llevará a cabo las actividades
o tareas SCM dados, de la organización
6-4 Guía SWEBOK® V3.0
papeles para que participen en el proceso de SMC deben ser
claramente identificados. Las responsabilidades específicas para las
actividades o tareas SCM dados también tienen que ser asignados a
entidades de organización, ya sea por título o por el elemento de la
organización. Los informes dad y canales 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 de selección e implementación  (Donde se han diseñado elementos del banco de trabajo para trabajar
[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 pre- guntas 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, el mantenimiento
de las herramientas, entrenar y
personalización?
• Alcance: cómo se deployed- las nuevas herramientas, por
ejemplo, a través de toda la organización o sólo en proyectos
específicos?
• Propiedad: ¿quién es el responsable de la introducción de nuevas
herramientas?
• Futuro: ¿cuál es el plan para el uso de las herramientas en el
futuro?
• Cambiar: su capacidad de adaptación son las herramientas?
• Ramas y la mezcla: son capaci- dades 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 será abierto ( en otras palabras, las
herramientas de diferentes proveedores serán utilizados en diferentes
actividades del proceso SMC) o integrado
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
pro- yecto) 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 ser establecidos. Este último incluye la consideración de
lo que debe estar disponible para la vigilancia del cumplimiento
efectivo de información SMC.

1.3.5. control de interfaz
[2 *, c12] [3 *, c24s4]
Cuando un elemento de software de interfaz con otro elemento de
software o hardware, un cambio a cualquiera de elemento puede
afectar al otro. La planificación para el proceso SMC 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 manage- ment 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, responsabilidades,
autoridades, las políticas aplicables, directivas y
procedimientos)
• Actividades SCM (identificación de la configuración, control
de configuración, etc.)
Configuración del software 6-5 Gestión
• Horarios de SCM (coordinación con otras actividades del
proyecto)
• Recursos SCM (herramientas, recursos físicos y recursos
humanos)
• 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 soft- ware para adaptar los
procedimientos. Otras herramientas de cumplir proceso, dejando el
ingeniero de software con menos flexibilidad. requisitos de vigilancia y el
nivel de flexibilidad para ser proporcionados al ingeniero de software son
consideraciones importantes en la 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
6-6 Guía SWEBOK® V3.0
ideas que lleva a procesar los cambios y actualizaciones
correspondientes a la PGCS.
Bibliotecas de software y las diversas posibilidades de
herramientas SCM proporcionan fuentes para extraer información
acerca de las características del proceso de SMC (así como el
suministro de información agement hombre-proyecto y). Por
ejemplo, información 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).
Identificación 2. Configuración del 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.
2.1. Los productos que la identificación que deben ser controlados  tales como la construcción de software o el análisis del impacto
[2 *, c8s2.2] [4 *, c29s1.1]
Uno de los primeros pasos en el control del cambio es la identificación de
los elementos de software que deben ser controlados.
Esto implica la comprensión de la configuración del software en el contexto
de la configuración del sistema, la selección de los elementos de
configuración de software, 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]
Software configuración es las características de iCal funcionales y
phys- de hardware o software como se establece en la
documentación técnica o logrado en un producto. Puede ser visto
como parte de una configuración general del sistema.
2.1.2. Configuración del software de artículos [ 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, especifi- caciones 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,
de los cambios propuestos. seguimiento adecuado de estas
relaciones también es importante para apoyar la trazabilidad. El
diseño del esquema de identificación para LIC

Figura 6.2. Adquisición de artículos
debe considerar la necesidad de asignar elementos identificados a la
estructura del software, así como la necesidad de apoyar la
evolución de los elementos de software y sus relaciones.
2.1.4. Versión del software  la hora seleccionada durante el ciclo de vida del software. Cambio
[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
identifica- do 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 soft- ware.
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 todos los
cambios aprobados en la línea de base, representa la configuración actual
aprobado.
líneas de base utilizados comúnmente incluyen fun- cional,
asignado, de desarrollo, y el producto
Configuración del software 6-7 Gestión
líneas de base. La línea de base funcional 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
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 sis- tema. 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
6-8 Guía SWEBOK® V3.0
de los elementos cambiantes. La solicitud de cambio de software (SCR) se
describe en la sección 3.1.
En la adquisición de un SCI, se deben establecer su origen y
integri- dad inicial. Después de la adquisi- ción de un SCI, cambios
en el elemento debe ser formalmente aprobado como adecuado para
el SCI y la línea de base que participan, como se define en el PGCS.
Después de la aprobación, el elemento se incorpora en la línea de
base software de acuerdo con el procedimiento adecuado.
2.2. software Library
[3 *, c1s3] [4 *, c29s1.2]
Una biblioteca de software es una colección controlada de software y la
documentación relacionada diseñado para ayudar en el desarrollo de
software, uso o mantenimiento [1]. También es fundamental para la
versión de software agement hombre- y actividades de entrega. Existen
varios tipos de bibliotecas podrían ser utilizados, cada uno correspondiente
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 termi- nado. 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 trabajo y progreso.
3. Control de Configuración de Software
[2 *, c9] [4 *, c29s2]
control de la configuración de software se ocupa de la
gestión de cambios durante el ciclo de vida del software.
Cubre el proceso para determinar
qué cambios hacer, la autoridad de approv- ing ciertos cambios,
el apoyo a la ción ¡Ejecución de esos cambios, y el concepto de
desviaciones formales de los requisitos del proyecto, así como
exenciones de ellos. La información derivada de estas
actividades es útil en la medición de tráfico el cambio y la rotura,
así como los aspectos de reproceso.
3.1. Solicitar, evaluar y cambios que aprueba
Software 
[2 *, c9s2.4] [4 *, c29s2]
El primer paso en la gestión de los cambios a los artículos
controlados es determinar qué cambios hacer. El proceso de solicitud
de cambio de software (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 de actividad por tipo de
cambio de 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  decisiones CCB, y la información del proceso de cambio que se informa.
[2 *, c9s2.2] [3 *, c11s1] [4 *, c29s2]
La autoridad para aceptar o rechazar los cambios 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]
Una solicitud de cambio de software eficaz (SCR) proceso requiere
el uso de herramientas de apoyo y procedi- mientos para originar
las solicitudes de cambio, enforc- ing el flujo del proceso de
cambio, la captura
Configuración del software 6-9 Gestión
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 soft- ware de la edición del
mismo módulo, al mismo tiempo, y registrar todos los cambios realizados
en el
6-10 Guía SWEBOK® V3.0
código fuente. Los ingenieros de software de verificación módulos del
repositorio, hacer cambios, documentar los cambios, a continuación,
guarde los módulos editados en el repositorio. Si es necesario, los
cambios también pueden ser descartados, la restauración de una línea
de base anterior. herramientas más potentes pueden apoyar el
desarrollo paralelo y entornos distribuidos geográficamente. Estas
herramientas se pueden manifestar como aplicaciones
independientes, especializados bajo el control de un grupo
independiente SMC. También pueden aparecer como una parte
integrada del entorno de la ingeniería de software. Por último, pueden
ser tan elemental como un sistema de control de cambios rudimentaria
provisto de un sistema operativo.
3.3. Desviaciones y renuncias 
[1, c3]
Las limitaciones impuestas a un software Engineer- esfuerzo ing o las
especificaciones que se producen durante las actividades de desarrollo
podría contener disposiciones que no pueden ser satisfechas en el punto
designado en el ciclo de vida. Una desviación es un rización autori- escrita,
otorgada con anterioridad a la fabricación de un elemento, para apartarse
de una actuación en particular o requisito de diseño para un número
determinado de unidades o un período específico de tiempo. Una renuncia
es un diez autorización ESCRITO para aceptar un elemento de
configuración o de otro elemento designado que se encuentra, durante la
produc- ción o después de haber sido presentado para su inspección, a
apartarse de los requisitos especificados, pero se considera ertheless nev-
adecuado para uso como-es o después de la reanudación por un método
aprobado. En estos casos, un proceso formal se utiliza para obtener la
aprobación de las desviaciones de las renuncias, o de, las disposiciones.
4. Configuración de software de contabilidad Estado
[2 *, c10]
Software de contabilidad estado de configuración (SCSA) es un
elemento de gestión de la configuración sisting con- del registro y la
notificación de la informa- ción necesaria para gestionar una
configuración efectiva.
4.1. Software de información de estado de configuración  proceso bien definido que consiste en diversas funciones y
[2 *, c10s2.1]
Los diseños de actividad SCSA y opera un sis- tema para la captura y
presentación de la información necesaria a medida que avanza el ciclo
de vida. Como en cualquier
sistema de información, la información de estado de configuración para
ser administrado por los las configuraciones cambiantes deben ser
identificados, recogidos, y mantenido. Diversa información y las
mediciones son necesarias para apoyar el proceso de SMC y para cumplir
con el estado de con- figuración necesidades de información de gestión,
ingeniería de software, y otras actividades relacionadas. Los tipos de
información disponibles incluyen la identificación de la configuración
aprobada, así como la identificación y tus implementación actual de esta-
cambios, desviaciones, y las renuncias. Alguna forma de soporte de la
herramienta automatizada es preciso proceder para llevar a cabo la
recogida de datos SCSA y tareas de informes; esto podría ser una
capacidad de base de datos, una herramienta independiente, o una
capacidad de un entorno de herramientas más amplio e integrado.
4.2. Informes de estado de configuración de software 
[2 *, c10s2.4] [3 *, c1s5, c9s1, c17]
información reportada puede ser utilizado por varios elementos,
incluyendo los proyectos de organización y el equipo de desarrollo, el
equipo de mantenimiento, gestión de proyectos, y la calidad del
software activi- dades. Informes pueden tomar la forma de Que- hoc
Ries anuncios para responder a preguntas específicas o la producción
periódica de informes prediseñados. Algunos infor- mación producida
por la actividad contable de estado durante el curso del ciclo de vida
podría convertirse en los registros de control de calidad.
Además de informar el estado actual de la configuración, la
información obtenida por el SCSA puede servir como base de
diversas mediciones. Los ejemplos incluyen el número de
solicitudes de cambio por SCI y el tiempo medio necesario
para ejecutar una solicitud de cambio.
Auditoría 5. Configuración del software
[2 *, c11]
Una auditoría de software es una examina- ción 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
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

la planificación y realización de una auditoría pueden facilitar enormemente
el proceso.
auditoría de configuración software determina el grado en que
un elemento satisface las características funcionales y físicas
requeridas. auditorías informal de este tipo puede llevarse a cabo
en puntos clave del ciclo de vida. Hay dos tipos de auditorías
formales podrían ser requeridos por el contrato que rige (por ejem-
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  correctas de los elementos de configuración de software, utilizando los
[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
cali- dad 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 desarrollo.
6. El software de administración de lanzamientos y
Entrega
[2 *, c14] [3 *, c8s2]
En este contexto, lanzamiento se refiere a la distribu- ción de un
elemento de configuración de software fuera
Configuración del software de gestión 6-11
la actividad de desarrollo; esto incluye comunicados internos, así como la
distribución a los clientes. Cuando diferentes versiones de un elemento de
software están disponibles para la entrega (tales como versiones para
diferentes formas plataformas o versiones con diferentes capacidades),
frecuentemente es necesario volver a crear versiones específicas y
empaquetar los materiales adecuados para la entrega de la versión. La
biblioteca de software es un elemento clave en la realización de tareas de
liberación y entrega.
6.1. Edificio de software 
[4 *, c29s4]
edificio Software es la actividad de la combinación de las versiones
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
activi- dad 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 am- bientes desarrollo paralelos o distribuidos, esta
capacidad herramienta es necesaria. La mayoría de los entornos de
ingeniería de software proporcionan esta capacidad. Estas herramientas
varían en complejidad desde que requiere el ingeniero de software para
aprender un lenguaje de script espe- cializada a los enfoques orientados a
gráficos que ocultan gran parte de la complejidad de una instalación de
acumulación “inteligente”. El proceso de construcción y los productos son
a menudo sub- ject de verificación de la calidad del software. Las salidas
de
6-12 Guía SWEBOK® V3.0
el proceso de construcción podría ser necesaria para futuras referencias y
puede convertirse en los registros de control de calidad.
6.2. Software de administración de lanzamientos [ 4 *, c29s3.2]
gestión de versiones de software abarca la identificación, el
empaquetado, y la entrega de los elementos de un ejemplo de
producto-para, un programa capaz execut-, documentación, notas de la
versión, y datos de configuración. 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 den- sidades 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 contenidos de liberación de los SCR que se
han recibido. Esta capacidad herramienta también puede mantener
información sobre diversas plataformas de destino y en diversos
entornos de clientes.
7. herramientas de Software
[3 *, c26s1] [4 *, c8s2]
Cuando se habla de herramientas Ment manage- de configuración de
software, es útil para clasificarlos. herramientas de SCM se pueden
dividir en tres clases en función del ámbito en el que se proporcionan
apoyo: el apoyo vidual indicación, el apoyo relacionados con el proyecto,
y el apoyo en procesos com- panywide.
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 cali- dad, 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 pro- ceso 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.
 Configuración del software de gestión 6-13

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Sommerville 2011
IEEE 828-2012

Moore 2006
Hass 2003

[5 *]
[3 *]
[2 *]

[4 *]
1. Gestión del Proceso de SMC

1.1. Contexto de organización de SMC

c6, ann.D Introducción c29

1.2. Limitaciones y orientación para el c6, ann.D,

c2 c19s2.2 introducción c29
proceso SMC ann.E

c6, ann.D,
1.3. La planificación de SMC c23 c29
ann.E

1.3.1. Organización y
ann.Ds5-6 c10-11 introducción c29
responsabilidades SMC

1.3.2. Recursos SCM y

ann.Ds8 c23
horarios
1.3.3. Herramienta de selección e
c26s2; s6 c29s5
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 la Gestión de la

c11s3
Configuración de Software

1.5.1. Medidas de SCM y c9s2;

Medición c25s2-s3

1.5.2. En-Proceso de Auditorías de

C1S1
SMC

Identificación 2. Configuración del

c29s1.1
software

2.1. Los productos que la identificación

c8s2.2 c29s1.1
que deben ser controlados

2.1.1. Configuración del software

2.1.2. Software Elemento de Configuración

c29s1.1

2.1.3. Software Relaciones elemento de

c7s4
configuración

2.1.4. Versión del software c29s3

6-14 Guía SWEBOK® V3.0

Sommerville 2011
IEEE 828-2012

Moore 2006
Hass 2003

[5 *]
[3 *]
[2 *]

[4 *]
2.1.5. Base
2.1.6. La adquisición de elementos de
c18
configuración de software

2.2. software Library c1s3 c29s1.2

3. Control de Configuración de
C9 c29s2
Software

3.1. Solicitar, evaluar y cambios que

c9s2.4 c29s2
aprueba Software
3.1.1. Junta de Control de Configuración de
c9s2.2 c11s1 c29s2
Software

3.1.2. Software Proceso de

c1s4, c8s4
Solicitud de Cambio

3.2. Cambios en el software de

c29
aplicación

3.3. Desviaciones y renuncias

4. Configuración de software de
c10
contabilidad Estado

4.1. Software de información de estado

c10s2.1
de configuración

4.2. Informes de estado de configuración c1s5, c9s1,

c10s2.4
de software c17

Auditoría 5. Configuración del

c11
software

5.1. Software de Auditoría de

c11s2.1
Configuración Funcional

5.2. Auditoría de Configuración

c11s2.2
física de software

5.3. En-Proceso de Auditorías de una

c11s2.3
línea de base del software

6. El software de administración de
c14 c8s2 c29s3
lanzamientos y Entrega

6.1. Edificio de software c29s4

6.2. Gestión de la Entrega de

c29s3.2
Software

7. herramientas de Software
c26s1

LECTURAS
Stephen P. Berczuk y Brad Appleton,
Los patrones de software de gestión de configuraciones:
el trabajo en equipo, la integración práctica [ 6].
Este libro expresa prácticas de SCM y estrategias útiles como patrones.
Los patrones pueden ser implementado utilizando diversas herramientas,
sino que se expresa de una manera independiente del instrumento.
“CMMI para el Desarrollo”, versión 1.3, pp.
137-147 [7].
Este modelo presenta una recopilación de las mejores ticas ticas para
ayudar a las organizaciones de desarrollo de software a mejorar sus
procesos. En el nivel de madurez 2, sugiere actividades de gestión de
configuración.
Configuración del software de gestión 6-15
Referencias
[1] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
[2 *] IEEE Std. 828-2012, Norma para 
Gestión de la Configuración en Sistemas e Ingeniería
de Software, IEEE 2012.
[3 *] AMJ Hass, Gestión de la configuración 
Principios y Prácticas, 1ª ed., Addison-Wesley,
2003.
[4 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[5 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
Wiley-IEEE Computer Society Press, 2006.
[6] SP Berczuk y B. Appleton, Software 
Patrones de Gestión de la Configuración: el trabajo en
equipo, la integración práctica,
Addison-Wesley Professional, 2003.
[7] CMMI equipo de productos, “CMMI para
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
SIGLAS
PMBOK ® Guía para la Dirección de Proyectos del
Guía Conocimiento
SDLC La vida de desarrollo de software de ciclo SEM
Ingeniería de Software de Gestión de SQA
Calidad de Software
Extensión de software para el PMBOK ®
SWX
Guía
WBS Work Breakdown Structure
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 generación de informes 1 -para
asegurar que los productos de software y servicios de ingeniería de
software se entregan de manera eficiente, efectiva y en beneficio de los
interesados. 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
SWX.
7-1
• Los clientes a menudo no saben lo que se necesita o lo que es
factible.
• Los clientes a menudo carecen de reconocimiento por las
complejidades inherentes a la ingeniería de software, en particular
sobre el impacto de los requisitos de ING cam- bios.
• Es probable que el aumento de la comprensión y las
condiciones cambiantes generarán requisitos nuevos o
modificados de software.
• Como resultado de cambios en los requisitos, soft- ware se
construye a menudo usando un proceso iterativo en lugar de como
una secuencia de tareas cerradas.
• La ingeniería de software incorpora necesariamente las
tasas de creatividad y disciplina. El mantenimiento de un
equilibrio adecuado entre los dos es a veces difícil.
• El grado de novedad y complejidad es a menudo alta.
• A menudo hay una rápida tasa de cambio en la tecnología
subyacente.
actividades de gestión de la ingeniería de software se producen
en tres niveles: gestión de la organización y estructura de
infraestructura, gestión de proyectos y gestión del programa de
medición. Los dos últimos se tratan en detalle en esta descripción
KA. Sin embargo, esto no es para disminuir la importancia de los
problemas de gestión de la organización y de infraestructura. En
general se acepta que los gerentes de ingeniería de software de
organización deben estar familiarizados con el proyecto manage-
ment conocimiento y la medición del software descrito en este KA.
También deben poseer algunos conocimientos de dominio de
destino. Del mismo modo, también es útil si los gerentes de
proyectos y programas complejos en los que el software es un
componente de la arquitectura del sistema son conscientes de las
diferencias que los procesos de software introducen en la gestión
de proyectos y la medición del proyecto.
7-2 Guía SWEBOK® V3.0
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 organizaciones ejercen un
impacto en la 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 analizar los resultados anteriores pro- yecto e
implementar mejoras).
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 pro-
porciona 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 productividad y la
competitividad. reutilización efectiva requiere una visión
estratégica que refleja las ventajas y desventajas de reutilización.
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 comporta- miento, 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 el Guía para la Dirección de
Proyectos (PMBOK ® Guía) y el Extensión de software para el
PMBOK ® Guía (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 llevado al tratamiento
combinado en este KA.
Por desgracia, una percepción común de la industria del software es
que los productos de software se Ered deliv- tarde, por encima del
presupuesto, de mala calidad y con una funcionalidad incompleta. La
medición-informada
Ingeniería de Software de Gestión de 7-3
-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
miembros de 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.
7-4 Guía SWEBOK® V3.0
• El Proceso de Ingeniería de Software KA describe los
modelos del ciclo de vida del software y las relaciones
entre los procesos y productos de trabajo.
• La calidad del software KA hace hincapié en cali- dad 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 eje- cuta de diferentes maneras, el desglose de los temas es
basado en la actividad. Esa ruptura se muestra en la Figura 7.1. Los
elementos del Break-nivel superior mostrado en esa figura son las
actividades que se realizan por lo general cuando se está
gestionando un proyecto de desarrollo de software, independiente
del modelo de ciclo de vida de desarrollo de software (ver Software
Modelos de Ciclo de Vida de la 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;
• Software promulgación del proyecto, 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 son satisfactorios;
• Cierre, que se ocupa de las actividades realizadas para
completar un proyecto;
• Ingeniería de Software de medición, que se ocupa
del desarrollo efectivo y
implementación de programas de medición en las
organizaciones de ingeniería de software;
• Herramientas de software de gestión de ingeniería, que describe la
selección y el 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 estimaciones aproximadas de esfuerzo y
el coste sobre la base de métodos apropiados (véase la sección 2.3,
Esfuerzo, Schedule, y el coste de estimación).

1.3. Proceso para el examen y revisión de los
requisitos
[3 *, c3]
Dada la inevitabilidad del cambio, las partes interesadas deben
ponerse de acuerdo sobre los medios por los cuales los requisitos y
alcance han de ser examinado y revisado (por ejemplo, procedimientos
de gestión del cambio, 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 alguna forma 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, ment Riesgo Manage-, 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. software de planificación
El primer paso en la planificación de proyectos de software debe
ser la selección de un modelo de desa- rrollo 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
del software, verificación y validación, opiniones y auditorías (ver la
calidad KA software ). Procesos y responsabilidades para la
revisión en curso y la revisión del plan de proyecto y los planes
relacionados también deben estar claramente establecidos y
acordados.
Ingeniería de Software de Gestión de 7-5
2.1. Planificación de procesos 
[3 *, c3, c4, c5] [5 *, c1]
Software de ciclo de vida de desarrollo (SDLC) els mo- abarcan un
continuo que va desde predictivo para adaptable (consulte el software
del ciclo de vida Los modelos de la Ingeniería de Procesos de
Software KA). SDLCs predictivos se caracterizan por el desarrollo de
los requisitos de soft- ware 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 desa- rrollo iterativos. SDLCs
en la gama media de los incrementos SDLC continuum producto de
funcio- nalidad ya sea en un horario planificada de antemano (en el
lado predictivo del continuo) o como los pro- ductos de los ciclos de
desarrollo frecuentemente actualizadas (en el lado de 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 docu- mentos de diseño, informes de inspección,
el software probado) debe ser identificado y caracterizado.
Oportunidades para la reutilización de componentes de software de
proyec- tos anteriores o para utilizar los productos de software
off-the-shelf
7-6 Guía SWEBOK® V3.0
deben ser evaluados. Adquisición de software y el uso de
terceros para desarrollar las prestaciones debe ser planeada y
proveedores seleccionados (ver sección 3.2, Software de
Adquisición y Gestión de Proveedores de contrato).
2.3. Esfuerzo, Calendario, y Estimación de costos [ 3 *, c6]
El rango estimado de esfuerzo requerido para un proyecto, o partes de
un proyecto, se puede determinar utilizando un modelo de estimación
calibrada en base al tamaño y esfuerzo datos históricos (cuando esté
disponible) y otros métodos pertinentes, tales como el juicio de expertos
y la analogía. dependencias de tareas se pueden establecer y
oportunidades potenciales para la realización de tareas al mismo tiempo
y de forma secuencial pueden ser identificados y documentados
mediante un diagrama de Gantt, por ejem- plo. Para proyectos SDLC
predictivos, el calendario previsto de tareas con tiempos de inicio
proyectada, ciones durabilidad y el final de los tiempos se produce
normalmente durante la planificación. Para proyectos SDLC de
adaptación, una estimación general de esfuerzo y el horario típicamente
se desarrolló a partir de la comprensión inicial de los requisitos, o,
alternativamente, las restricciones sobre el esfuerzo global y el
calendario puede ser especificado y se utiliza para determinar una
estimación inicial de la nú- mero ciclos y estimaciones del esfuerzo de
iterativos y otros recursos asignados a cada ciclo. Recursos necesarios
(por ejemplo, personas y herramientas) pueden traducirse en
estimaciones de costos. la estimación inicial de esfuerzo, horario, y el
costo es una actividad iterativa que debe ser negociado y revisado entre
las partes interesadas afectadas hasta que se alcanza consenso sobre
los recursos y el tiempo disponible para la finalización del proyecto.
2.4. Asignación de recursos
[3 *, c5, c10, c11]
Equipos, instalaciones y personas deben asignarse los que las
tareas identificadas, incluyendo el catión alo de responsabilidades
para la realización de elementos de variabilidad ous de un proyecto
y el proyecto en general. Una matriz que muestra quién es
responsable de, responsables de, consultado sobre, e informado
sobre cada una de las tareas se pueden utilizar. La asignación de
recursos se basa en, y limitada por la disponibilidad de recursos y
su uso óptimo, como se
así como por las cuestiones relativas al personal (por ejem- plo, la
productividad de las personas y los equipos, la dinámica del equipo, y
estructuras de equipo).
2.5. Gestión de riesgos
[3 *, c9] [5 *, c5]
Riesgo e incertidumbre están relacionados pero distintos conceptos. La
incertidumbre resulta de la falta de informa- ción. El riesgo se caracteriza
por la probabilidad de un evento que se traducirá en un impacto negativo
además de una caracterización de los efectos negativos sobre un proyec-
ect. El riesgo es a menudo el resultado de la incertidumbre. Lo contrario
de riesgo es la oportunidad, que se caracterizarse por la probabilidad de
que un evento que tenga se puede producir un resultado positivo. La
gestión del riesgo implica la identificación de factores de riesgo y análisis
de la probabilidad y el impacto poten- cial de cada factor de riesgo, la
priorización de los factores de riesgo, y el desarrollo de estrategias de
mitigación de riesgos para reducir la probabilidad y minimizar el impacto
negativo si un factor de riesgo se convierte en un problema. métodos de
evaluación de riesgos (por ejemplo, la opinión de expertos, datos
históricos, árboles de decisión, y simulaciones de procesos) a veces se
pueden utilizar con el fin de identificar y evaluar los factores de riesgo.
condiciones de abandono del proyecto también se pueden determinar en
este punto de la discusión con todos los interesados. aspectos de
software única de riesgo, tales como la tendencia ingenieros de software
para añadir características que no sean necesarios, o los riesgos
relacionados con la naturaleza intangible del software, puede influir en el
riesgo hombre- agement de un proyecto de software. aten- ción
particular, se debe prestar a la gestión de los riesgos relacionados con
los requisitos de calidad de software, tales como la seguridad o la
seguridad (ver la calidad KA Software). La gestión del riesgo debe
hacerse no sólo en el comienzo de un proyecto, sino también a intervalos
periódicos a lo largo del ciclo de vida del proyecto.
2.6. Gestión de la calidad
[3 *, c4] [4 *, c24]
los requisitos de calidad de software deben ser identifi- cado, tal vez en
términos cuantitativos y cualitativos, para un proyecto de software y los
productos de trabajo asociados. Los umbrales para las mediciones de
calidad aceptables deben establecerse para cada requisito de calidad de
software basada en las necesidades de las partes interesadas

y expectativas. Procedimientos relacionados con el software en
curso Garantía de Calidad (SQA) y la mejora de la calidad
durante todo el proceso de desarrollo, y para la verificación y
validación del producto software entregable, también deben
especificarse durante la planificación de la calidad (por ejemplo,
las revisiones e inspecciones técnicas o de- mostraciones 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 ejem- plo, 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.
La promulgación 3. 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 objeti- vos 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]
Las actividades del proyecto deben llevarse a cabo en ajustan al
plan del proyecto y los planes de apoyo. Recursos (por ejemplo,
personal, tecnología y financiación) son utilizados y productos de
trabajo (por
Ingeniería de Software de Gestión de 7-7
ejemplo, diseño de software, código de software y pruebas de software
de los casos) se 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 desa- rrollo 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 relacionados
debe ser continuamente evaluado y al
7-8 Guía SWEBOK® V3.0
intervalos predeterminados. Además, se deben evaluar los productos y
los criterios pletion com- para cada tarea. Entregables deben ser
evaluados en términos de sus características requeridas (por ejemplo, a
través de las inspecciones o mediante la demostración de la
funcionalidad de 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, Riesgo Gestión) 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 proyecto (por ejemplo, los requisitos de software especifi- cación)
para dar cabida a eventos no previstos y sus implicaciones.
En algunos casos, el proceso de control puede llevar al
abandono del proyecto. En todos los casos,
procedimientos de gestión de control de configuración de software y
configuración de software deben ser atendidas (ver el 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. Como en la actividad proceso de control anteriormente
(véase sec- ción 3.5, Process Control), configuración de software

procedimientos de gestión de configuración de software de control y
se deben seguir (véase el Software Configuration Management KA),
las decisiones documentadas y comunicadas a todas las partes
interesadas, los planes de examinar y modificar 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 de
las partes interesadas; problemas conocidos deben ser
documentados.
Ingeniería de Software de Gestión de 7-9
5.2. Actividades de cierre
[2, s3.7, S4.8]
Tras el cierre se haya confirmado, el archivo de 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. Software de Ingeniería de medición
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 proyec- tos, 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 .
7-10 Guía SWEBOK® V3.0
la organización y el proyecto (por ejem- plo, un objetivo de la
organización podrían ser “los primeros en el mercado con
nuevos 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 responsabili- dad 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  y medir el proyecto.
[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. Información
necesidades se basan en los objetivos, limitaciones,
riesgos y problemas de la unidad organizativa. Ellos se
pueden derivar de negocio, objetivos de la organización,
regulación y / o de productos. Ellos deben ser
identificados y
priorizado. A continuación, un subconjunto de los objetivos que se
abordarán se puede seleccionar, documentado, com- municated, y
revisado por los interesados.
• 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
• 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. cri- terios 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 proceso de medición.
• Identificar recursos para poner a disposición para la
realización del planeado y aprobado

tareas de medición. La disponibilidad de recursos puede ser
puesta en escena en los casos en que los cambios han de ser
pilotado antes del despliegue generalizado. Deberán tener en
cuenta a los recursos necesarios para la implementación exitosa
de nuevos procedimientos o medidas.
• Adquirir y desplegar tecnologías de apoyo. Esto incluye la
evaluación de las tecnologías de soporte disponibles, la
selección de las tecnologías más adecuadas, la adquisición
de esas tecnologías, y el despliegue de esas tecnologías.
6.3. Realizar el proceso de medición [ 7 *, c1, c2]
• Integrar los procedimientos de medición con los procesos de
software Evant rel. Los procedimientos de medición, tales como
la recopilación de datos, deben integrarse en los procesos de
software que se está midiendo. Esto puede implicar cam- ing
procesos de software actuales para acomodar la recopilación de
datos de fecha 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 apropiado a la naturaleza de
los datos y las necesidades de información. Los resultados de
este análisis son típicamente indicadores tales como gráficos,
números u otras indicaciones que serán interpretadas, resultando
en conclusiones y recomendaciones que se presentará a las
partes interesadas (ver Análisis estadístico en el
Ingeniería de Software de Gestión 7-11
Fundamentos de ingeniería KA). Los resultados y
conclusiones son generalmente revisados, usando un
proceso definido por la organización (que puede ser formal o
informal). Los proveedores de datos y usuarios de medida
deben participar en la revisión de los datos para asegurarse
de que son significativos y precisos y que puedan dar lugar a
acciones razonables.
• Comunicar los resultados. Los productos de información deben ser
documentados y comunicados a los usuarios y grupos de interés.
6.4. evaluar Medición
[7 *, c1, c2]
• 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 el potencial mejoras. Tal
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
7-12 Guía SWEBOK® V3.0

proyecto de informe e información del producto. Las herramientas se y estimaciones subjetivas de las probabilidades de los eventos de riesgo.

pueden dividir en las siguientes categorías: herramientas de simulación Monte Carlo se pueden utilizar para producir

Planificación de proyectos y herramientas de seguimiento. planificación distribuciones de probabilidad de esfuerzo, horario, y el riesgo mediante la

de proyectos y herramientas de seguimiento se pueden utilizar para combinación de múltiples distribuciones de probabilidad de entrada de una

estimar el esfuerzo y el coste del proyecto compañero y preparar los manera algorítmica.

programas del proyecto. Algunos proyectos utilizan herramientas

automatizadas esti- mación que aceptan como entrada el tamaño estimado Herramientas de comunicación. Las herramientas de comunicación
y otras características de un producto de software y producen pueden ayudar a proporcionar información oportuna y consistente a las

estimaciones del esfuerzo total, el cronograma y costo requerido. partes interesadas que participan en un proyecto. Estas herramientas

herramientas de planificación también incluyen herramientas de pueden incluir cosas como las notificaciones de correo electrónico y

programación que analizan las tareas dentro de una estructura de transmisiones de los miembros del equipo y las partes interesadas.

desglose de trabajo automatizado, su estimación acoplado duraciones, sus También incluyen comu- nicación de las actas de las reuniones regulares

relaciones de precedencia, y los recursos asignados a cada tarea para del proyecto, reuniones diarias de stand-up, además de gráficos que

pro- ducir un calendario en forma de un diagrama de Gantt. herramientas muestran el progreso, el trabajo atrasado, y solicitud de mantenimiento

de seguimiento se pueden utilizar para realizar un seguimiento de los hitos resoluciones.

del proyecto, reuniones de estado del proyecto programadas

regularmente, ciclos de iteración programadas, demostraciones de Herramientas de medición. Herramientas de medición SUP- actividades
productos y / o elementos de acción. portuarias relacionadas con el programa de medición ción (véase el tema

6, Software Engineer- Medición ing) de software. Hay pocas herramientas

Herramientas de gestión de riesgos. herramientas de gestión del riesgo completamente automatizadas en esta categoría. instrumentos de

(ver sección 2.5, gestión de riesgos) se pueden utilizar para realizar un medición utilizados para reunir, analizar y reportar los datos de medición

seguimiento de la identificación del riesgo, estimación y supervisión. Estas de proyecto pueden estar basados ​en hojas de cálculo desarrollados por

herramientas incluyen el uso de enfoques como la simulación o de árboles los miembros del equipo de proyecto o empleados organizativas.

de decisión para analizar el efecto de los costos versus beneficios

 Ingeniería de Software de Gestión 7-13

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Boehm y Turner 2003

McGarry et al. 2001

Sommerville 2011
Fairley 2009

[7 *]
[5 *]
[3 *]

[4 *]
1. Iniciación y Definición del
Alcance

1.1. La determinación y la negociación

c3
de los requisitos

1.2. Análisis de viabilidad c4

1.3. Proceso para el examen y revisión

c3
de los requisitos

2. software de planificación

2.1. Planificación de procesos c2, c3, c4, c5 c1

2.2. determinar entregables c4, c5, c6

2.3. Esfuerzo, Calendario, y Estimación de

c6
Costos

2.4. Asignación de recursos C5, C10, C11

2.5. Gestión de riesgos 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 Gestión

C3, C4
de Proveedores Contrato

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. Revisión y Evaluación del

c8, c10
desempeño
7-14 Guía SWEBOK® V3.0

Boehm y Turner 2003

McGarry et al. 2001

Sommerville 2011
Fairley 2009

[7 *]
[5 *]
[3 *]

[4 *]
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 el

c1, c2
compromiso de Medición

6.2. Planificar el proceso de

c1, c2
medición

6.3. Realizar el proceso de medición

c1, c2

6.4. evaluar Medición c1, c2

7. Herramientas de Gestión de
C5, C6, C7
Ingeniería de Software
 Ingeniería de Software de Gestión 7-15

LECTURAS Referencias

Una guía para la Dirección de Proyectos  [1] Instituto de Gestión de Proyectos, Una guía para la 
(PMBOK ® Guía) [ 1]. Guía de los fundamentos de gestión de proyectos
(PMBOK (R) Guía), 5ª ed., Project Management
los PMBOK ® Guía proporciona directrices para la gestión de proyectos Institute, 2013.
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 [2] Instituto de Gestión de Proyectos e IEEE
sus procesos relacionados, así como el ciclo de vida del proyecto. Es Computer Society, Software de la extensión de la Guía
una guía reconocida a nivel mundial para la profesión agement el del PMBOK® quinta edición, Project Management
proyecto hombre-. Institute, 2013.

[3 *] RE Fairley, La gestión y líder 

Software de la extensión de la Guía para el  Los proyectos de software, Wiley-IEEE Computer Society
Guía de los fundamentos de gestió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 el Guía del
PMBOK® para proyectos de software ing manag-. La principal
contribución de esta extensión a la Guía del 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, La gestión del desarrollo de  2010.
Los sistemas intensivos de software, Wiley, 2010 [8].
Press, 2009.
[4 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[5 *] B. Boehm y R. Turner, agilidad Equilibrio 
y Disciplina: Una Guía de los Perplejos,
Addison-Wesley, 2003.
[6] IEEE Std. 15939-2008 La adopción del estándar 
ISO / IEC 15939: 2007 Sistemas y Procesos de
Software Ingeniería de Mediciones,
IEEE 2008.
[7 *] J. McGarry et al., Practical Software 
Medición: información objetiva para la Toma de
Decisiones, Addison-Wesley Professional, 2001.
[8] J. McDonald, La gestión del desarrollo de 
Los sistemas intensivos de software, John Wiley and Sons, Inc.,

Este libro de texto proporciona una introducción a la gestión de proyectos

para el comienzo de los desarrolladores de software y hard- ware 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,

software complejo, y sistemas de hardware, así como los resultados de la

inspección y las métricas de prueba para monitorear el estado del proyecto

Tor.
 CAPÍTULO 8

SOFTWARE INGENIERÍA DE PROCESOS

SIGLAS proceso”se denomina‘proceso de software’en este KA. Además,

tenga en cuenta que “el proceso de software” se refiere a las

BPMN Business Process Modeling actividades de trabajo, no el proceso de ejecu- ción para el software
CASO
implementado. procesos de software se especifican para un
Asistido por Computadora Ingeniería de número de razones: para facilitar la comprensión humana, la
notación
Software CM comunicación y la coordinación; para ayudar agement-hombre de

Configuración de Gestión de CMMI los proyectos de software; para medir y mejorar la calidad de los
productos de software de una manera eficiente; para apoyar
Capability Maturity Model
proceso de mejora ción; y para proporcionar una base para el
Integration
puerto SUP- automatizado de ejecución del proceso. SWEBOK KAs
GQM Meta-pregunta-Metric IDEF0
estrechamente relacionados con este proceso de Ingeniería de
Integración Definición LOE Software KA incluyen el software de gestión de ingeniería, modelos

Nivel de Esfuerzo de ingeniería de software y Métodos, y Calidad de Software; el

ODC Ortogonal Defecto Clasificación SDLC
La vida de desarrollo de software de ciclo SPLC
Software de vida del producto Ciclo UML
tema Análisis Causa Raíz Medición y que se encuentra en los
Fundamentos de Ingeniería KA también está estrechamente
relacionado. Software de gestión de ingeniería se ocupa de la
adaptación, la adaptación y la implementación de procesos de

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 de software.
Para facilitar la lectura “, la ingeniería de software
software para un proyecto de software específico (ver Proceso de
Planificación en el KA Software Engineering Management). Els y
métodos mo- apoyan un enfoque sistemático para el desarrollo de
software y modificación. La calidad KA software se ocupa de la
planificación, aseguramiento y control de procesos para el proyecto
y la calidad del producto. Medición y medición de los resultados en
la Ingeniería Foundation ciones KA son esenciales para la
evaluación de los procesos de software y control- ling.
DISTRIBUCIÓN DE TEMAS DE INGENIERÍA DE
PROCESOS DE SOFTWARE
Como se ilustra en la Figura 8.1, este KA tiene que ver con la definición
de procesos de software, los ciclos de vida del software, evaluación de
procesos de software y la mejora, la medición del software, el software y
herramientas de proceso de inge- niería.

8-1
8-2 Guía SWEBOK® V3.0
Figura 8.1. Desglose de los temas para el Proceso de Ingeniería de Software KA
1. Definición del proceso de software
[1 *, P177] [2 *, P295] [3 *, p28-29, p36, c5]
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 pro- ceso de software incluye entradas
requiere, transformar las actividades de trabajo y genera salidas. Como se
ilustra en la Figura 8.2, un proceso de software 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 especificadas deben ser satisfechas antes de que un
proceso puede ser con éxito
concluido, incluyendo los criterios de 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 subprogramas, cesos
pueden entraba y salía varias veces durante el desarrollo de
software o modificación. definición completa de un proceso de
software también puede incluir las funciones y 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 procedimien-
tos; un procedimiento se puede especificar como un conjunto ordenado de
pasos o, alternativamente, como una lista de control del trabajo a llevar a
cabo en la realización de una tarea. Se debe enfatizar que no hay mejor
proceso de software o conjunto de procesos de software. procesos de soft-
ware deben ser seleccionados, adaptados, y se aplican 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  la empresa modelo de organización es probable que sea necesario para
[3 *, s26.1] [4 *, p453-454]
Dos objetivos de la gestión de procesos de software son para
darse cuenta de la eficiencia y eficacia que
Software de Ingeniería de Procesos 8-3
resultado de un enfoque sistemático para 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 infra- estructura 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
acomodar los cambios en el proceso.
8-4 Guía SWEBOK® V3.0
1.2. Infraestructura de Procesos de Software
[2 *, P183, P186] [4 *, p437-438]
El establecimiento, implementación y gestión de procesos de software y
modelos de ciclo de vida del software a menudo se produce en el nivel
de los proyectos de software individuales. Sin embargo, la aplicación
sistemática de los 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 proceso influye en la calidad del producto de
software.
2. Ciclos de vida del software
[1 *, c2] [2 *, p190]
En este tema se aborda categorías de pro- cesos de software,
modelos de ciclo de vida del software, software
adaptación de procesos, y consideraciones prácticas. Un ciclo de vida
de desarrollo de software (SDLC) incluye los procesos de software
utilizados para especificar y transformar los requisitos de software en
un producto de software erable deliv-. Un ciclo de 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 considerados como menos efectivo a
menos que otros procesos de software se llevan a cabo al mismo tiempo
(por ejemplo, planificación de prueba de software durante el análisis de
los requisitos de software puede mejorar los requisitos de software).

2.1. Categorías de procesos de software
[1 *, Prefacio] [2 *, p294-295] [3 *, c22-c24]
Muchos procesos diferentes de software se han definido para su
uso en las diversas partes de los ciclos de vida de desarrollo de
software de mantenimiento y software. Estos procesos se pueden
clasificar como sigue:
1. procesos primarios cesos incluir software para pro- desarrollo,
desarrolla software en incrementos de aumentar la funcionalidad en
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 software para proteger
la seguridad de MENT el desarrollo ambiente y reducir el riesgo de actos
maliciosos. procesos de soft- ware también pueden ser desarrollados
para proporcionar un fundamento adecuado para el establecimiento de
la confianza en la integridad del software.
Software de Ingeniería de Procesos 8-5
2.2. Modelos de Ciclo de vida del software 
[1 *, c2] [2 *, S3.2] [3 *, S2.1] [5]
La naturaleza intangible y maleable de software permite una amplia
variedad de modelos de ciclo de vida del software de desarrollo, que
van desde los modelos lineales 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
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 traba-
jando, software entregable basado en la partición de los requisitos de
software para ser implementados en cada uno de los incrementos.
Los requisitos de software pueden ser rigurosamente controladas,
como en un modelo lineal, o puede haber cierta flexibilidad en la
revisión de los requisitos de software como el producto de software
evoluciona. modelos ágiles pueden definir el alcance del producto y
de alto nivel incluye inicialmente; Sin embargo, ágil
8-6 Guía SWEBOK® V3.0
modelos están diseñados para facilitar la evolución de los
requisitos de software durante el proyecto. Se debe enfatizar
que el continuo de SDLCs de lineal a ágil no es una línea
delgada, recta. Elementos de diferentes enfoques pueden ser
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 organiza- cional, 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 adaptarse para reflejar
las realidades del desarrollo y mantenimiento de software dentro del
contexto de la organización y ambiente de negocios. Otra
consideración práctica: procesos de software (como la gestión de la
configuración,
construcción y pruebas) se pueden adaptar para facilitar su manejo
Tate, soporte, mantenimiento, migración, y el retiro del software.
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 existen- tes
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 nive- les 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 se lleva a
cabo utilizando tanto un modelo de evaluación y un método de
evaluación. El modelo puede proporcionar una norma para una
evaluación comparativa

la comparación entre los proyectos dentro de una organiza- ción y
entre organizaciones.
Una auditoría de proceso difiere de un proceso de Assessment. Las
evaluaciones se realizaron para determinar niveles de capacidad o
madurez 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 pro- yecto, 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. fac- tores 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 objetivas que indica la consecución de los
objetivos y resultados de un proceso de software definido. Por
ejemplo, una evaluación cuantitativa del proceso de inspección
soft- ware puede ser realizada por
Software de Ingeniería de Procesos 8-7
examinar los pasos del procedimiento seguido y los resultados
obtenidos, además de los datos relativos a los defectos encontrados y el
tiempo requerido para encontrar y corregir los defectos 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 identificar y priorizar mejoras
deseadas (planificación); la introducción de una mejora,
incluyendo la gestión y la formación (hacer) el cambio;
evaluación de la mejora
8-8 Guía SWEBOK® V3.0
en comparación con los resultados anteriores o ejemplares de
proceso y costes (control); y hacer modificaciones adicionales (en
funciones). El Plan-Do-Check-Act modelo de mejora de procesos se
puede aplicar, por ejemplo, para 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 continuo sistema de calificación implica la
asignación de una calificación a cada una de procesos de software de
interés; un escenificado sistema de clasificación se establece mediante 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 lev- els 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 representación La representación por
continua de los niveles etapas de niveles de
Nivel
de capacidad madurez
0 incompleta 1
realizado Inicial
2 Managed Gestionado
3 definido definido
cuantitativamente
4 software y técnicas de medición de procesos de software (ver
Gestionado
5 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
nivel 1, pero de forma puntual, de manera informal. En el nivel 2, un
proceso de software (valoración capacidad) o los procesos en el nivel
de madurez 2 están siendo per- forman de una manera que
proporciona una gestión
visibilidad de los productos de trabajo intermedios y puede ejercer
algún control sobre 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 dife- rentes 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. Software de medición [ 3 *, s26.2] [4 *, s18.1.1]
Este proceso de software direcciones tema y medición pro- ducto, la
calidad de los resultados de medición, modelos de información,
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
proporcio- nar 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 ini- cial
después de que el proceso de inspección se introduce, el esfuerzo
combinado de la inspección

además de las pruebas puede ser comparada con la cantidad anterior de
esfuerzo requerido para probar solo. consideraciones simi- lar se aplican
si se cambia un proceso.
4.1. Proceso de Software y Medición del producto  ineficaz en la consecución de un resultado de procesos de software
[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. los 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 arriba recién introducido se ha reducido el
número restante de defectos en el software.
medidas de productos que pueden ser importantes en la
determinación de la eficacia de los pro- cesos de software incluyen la
complejidad del producto, defectos totales, densidad de defectos, y la
calidad de los requisitos,
Software de Ingeniería de Procesos 8-9
documentación de diseño, y otros productos de trabajo relacionados.
También tenga en cuenta que la eficiencia y la eficacia son
conceptos independientes. Un proceso de software eficaz puede ser
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 pro-
ductos deficientes, personal sin experiencia, la falta de herramientas e
infraestructura adecuados , el aprendizaje de un nuevo proceso, un
producto complejo, o un dominio del producto desconocido. La eficiencia
y eficacia de la 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, activi- dad 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 los defectos que encuentran, como en la unidad de
pruebas por los desarrolladores de software o en un equipo ágil de
funciones cruzadas. O el cálculo de la productividad puede incluir ya
sea el esfuerzo del software
8-10 Guía SWEBOK® V3.0

desarrolladores o el esfuerzo de un equipo ING Ensayos 4.3. Información de software Modelos

independientes, dependiendo de quién fija los defectos encontrados [1 *, p310-311] [3 *, p712-713] [4 *, s19.2]
por los probadores independientes. Tenga en cuenta que este ejemplo
se refiere al esfuerzo de los equipos de Ircops o equipos de modelos de información de software permiten el modelado, análisis y

probadores desa- y no a los individuos. la productividad del software predicción de procesos de software y producto de software atributos para

calculado al nivel de los individuos puede ser engañoso debido a los proporcionar respuestas a las preguntas pertinentes y lograr los objetivos

muchos factores que pueden afectar la productividad individual de los del proceso y mejora del producto. datos necesarios pueden ser recogidos

ingenieros de software. 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

definiciones estandarizadas y las reglas de recuento para la modelos de información de software se producen durante los proyectos de

medición de los procesos de software y productos de trabajo son software y después de la conclusión de los proyectos para asegurar que el

necesarias para proporcionar resultados de medición estandarizados a nivel de precisión es suficiente y que sus limitaciones son conocidas y

través de proyectos dentro de una organización, para rellenar un comprendidas. modelos de información de software también pueden ser

depósito de datos cal históricamente que pueden ser analizados para desarrolladas para contextos distintos proyectos de software; por ejemplo,

identificar procesos de software que necesitan ser mejoradas y para un modelo de información de software podría ser desarrollado para los

construir modelos predictivos basados ​en los datos acumulados. En el procesos que se aplican en toda la organización, tales como los procesos

ejemplo anterior, serían necesarias las definiciones de defectos de de garantía de calidad del software software de gestión de configu- ración

software y personal-horas de pruebas esfuerzo más contando reglas o en el nivel de organización. edificio de información de software modelo

para defectos y esfuerzo para obtener resultados de medición de análisis impulsado implica el desarrollo, la calibración y evaluación de

satisfactorios. La medida en que se institucionaliza el proceso de un modelo. Un software de infor- mación modelo se desarrolla mediante el

software es importante; insuficiencia ins- titucionalización de un proceso establecimiento de una transformación planteado la hipótesis de variables

de software puede explicar por qué los “buenos” los procesos de de entrada en resultados deseados; por ejemplo, el tamaño y la

software no siempre pro duce resultados anticipados. procesos de complejidad de los productos pueden ser transformados en estimación

software pueden ser institucionalizados por adopción dentro de la acoplado esfuerzo necesario para desarrollar un producto de software

unidad organizativa local oa través de unidades más grandes de una utilizando una ecuación de regresión desarrollado a partir de los datos

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

4.2. Calidad de los resultados de medición [ 4 *, s3.4-3.7] 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

La calidad del proceso y medición del producto resultados se similares. Hay tres posibles resultados de la evaluación:

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.

1. resultados calculados para un conjunto de datos diferente varían

El tema de ingeniería de software de medición de la Ingeniería ampliamente de los resultados reales para ese conjunto de datos,
de Software de Gestión de KA describe un proceso para la en cuyo caso el modelo derivado no es aplicable para establecer los
implementación de un programa de medición de software. nuevos datos y no se deben aplicar para analizar o hacer
predicciones para proyectos futuros;

2. Los resultados calculados para un nuevo conjunto de datos se
encuentran cerca de los resultados reales de ese conjunto de datos,
en cuyo caso los menores se realizan ajustes a los parámetros del
modelo para mejorar el acuerdo;
3. Los resultados calculados para los nuevos conjunto de datos y
conjuntos de datos posteriores están muy cerca y no se necesitan
ajustes en el modelo.
La evaluación continua del modelo puede Cate indicación de una
necesidad de adaptación en el tiempo como el con- texto en el que se
aplica el modelo de cambios. Las Metas / Preguntas / Métrica método
(GQM) fue pensado originalmente para el establecimiento de
actividades La medición, pero también se pueden utilizar para guiar el
análisis y mejora de procesos de software.
Se puede utilizar para guiar la construcción de información de software
modelo de análisis impulsada; resultados obtenidos del modelo de
información de software se puede utilizar para guiar la mejora del proceso.
El siguiente ejemplo ilustra la aplicación del método
GQM:
• Meta: Reducir el tiempo medio de solicitud de cambio 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 los tiempos de procesamiento de
solicitud de cambio en la fecha de inicio
• Métricas 1-1-2: Desviación estándar de los tiempos de
procesamiento de solicitud de cambio en 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 los tiempos de procesamiento de
solicitud de cambio actualmente
• Métricas 1-2-2: Desviación estándar de los tiempos de
procesamiento de solicitud de cambio actualmente
4.4. Técnicas de medición de procesos de software
[1 *, c8]
técnicas de medición de procesos de software se utilizan para
recopilar datos de proceso y producto de trabajo, transformar los
datos en información útil, y analizar la información para identificar
las actividades del proceso que son candidatos para la mejora. En
algunos casos, pueden ser necesarios nuevos procesos de
software.
Software de Ingeniería de Procesos 8-11
Técnicas de medición de proceso también proporcionan la
información necesaria para medir los efectos de las iniciativas de
mejora de procesos. técnicas surement medi- proceso puede ser
utilizado para recoger datos tanto cuantitativos como cualitativos.
4.4.1. Técnicas de medición de procesos
cuantitativa
[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
productivi- dad 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-12 Guía SWEBOK® V3.0
cada categoría para los procesos del proceso de software o software,
donde un grupo de defectos origi- NATed (ver Defecto Caracterización en
la Soft mercancías Quality KA). defectos interfaz de software, por ejemplo,
pueden haberse originado durante una inade- equiparan proceso de
diseño de software; mejorar el proceso de diseño de software reducirá el
número de defectos de la interfaz de software. ODC puede proporcionar
datos cuantitativos para la aplicación de análisis de causa raíz. Control
Estadístico de Procesos se puede utilizar para realizar un seguimiento de
la estabilidad del proceso, o la falta de estabilidad del proceso, utilizando
gráficos de control.
4.4.2. Técnicas de medición de procesos
cualitativos
[1 *, s6.4]
Cualitativa técnicas- medición de procesos que incluyen
entrevistas, cuestionarios y la opinión de expertos, se puede
utilizar para aumentar las técnicas de medición de procesos
cuantitativos. técnicas de consenso del grupo, incluyendo la
técnica Delphi, se pueden utilizar para obtener un consenso entre
los grupos de interesados.
5. Proceso de Ingeniería de Software Herramientas [ 1 *, s8.7]
herramientas de proceso de software soportan muchas de las notaciones
ciones utilizadas para definir, implementar y gestionar los procesos de
software individuales y los modelos del ciclo de vida del software. Incluyen
editores para anotaciones tales como diagramas de flujo de datos, gráficos
de estado, BPMN, diagramas IDEF0, redes de Petri, y los diagramas de
actividad UML. En algunos casos, las herramientas de proceso de software
permiten diferentes tipos de análisis y simulaciones (por ejemplo, de
simulación de eventos discretos). En
Además, las herramientas de negocio de propósito general, tal como una
hoja de cálculo, puede ser útil. Ingeniería de Software (CASE),
herramientas de ayuda de computadora pueden reforzar el uso de
procesos integrados, apoyar la ejecución de las definiciones de procesos
defi-, y proporcionar orientación a los seres humanos en la formación de
per- procesos bien definidos. herramientas simples, tales como
procesadores de texto y hojas de cálculo se pueden utilizar para preparar
las descripciones textuales de pro- cesos, actividades y tareas; Estas
herramientas también SUP- puerto de trazabilidad entre las entradas y
salidas de múltiples procesos de software (como el análisis de las
necesidades de los interesados, los requisitos de software ción
especificaciones, arquitectura de software, y el diseño detallado de
software), así como los resultados de los procesos de software como la
documentación , componentes de software, casos de prueba, y la
información de errores. La mayor parte de las áreas de conocimiento en
este Guía
Describir las herramientas especializadas que pueden ser utilizados para
gestionar los procesos dentro de ese KA. En particu- lar, véase la Gestión
de la Configuración de Software KA para una discusión de las
herramientas de gestión de configuración de software que pueden ser
utilizados para gestionar la construcción, integración y procesos para
liberar los productos de software. Otras herramientas, como los de gestión
de requisitos y pruebas, se describen en la KAs apropiado. herramientas
de proceso de software pueden apoyar proyectos que involucran
geográficamente equipos dispersos (virtuales). Cada vez más, las
herramientas de proceso de software están disponibles a través de las
instalaciones de computación en la nube, así como a través de
infraestructuras dedicadas. Un panel de control de proyectos o en el
salpicadero pueden dis- proceso seleccionado el 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.
 Software de Ingeniería de Procesos 8-13

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Sommerville 2011
Fairley 2009

Moore 2009

Kan 2003
[2 *]

[3 *]

[4 *]
[1 *]
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 Software p437-438

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 software c2 S3.2 S2.1

2.3. La adaptación de procesos de software s2.7 p51

2.4. Consideraciones prácticas p188-190

3. Software de Evaluación y Mejora de

P188, P194 c26 P397, c15
Procesos

S4.5,
3.1. Modelos de evaluación de procesos de software s26.5 p44-48
S4.6

3.2. Proceso de Software Métodos de evaluación p44-48,

p322-331 s26.3
s16.4

3.3. Modelos de mejora de procesos de software

p187-188 s26.5 s2.7

3.4. Calificaciones continuas y puesta en escena p28-34 s26.5 p39-45

4. Medición de Software s26.2 s18.1.1

4.1. Proceso de Software y Medición del S6.3, s26.2,

producto P273 P638

S3.4,
S3.5,
4.2. Calidad de los resultados de medición
S3.6,
s3.7

4.3. Información de software Modelos p310-311 pag. 712-713 s19.2

S5.1,
4.4. Técnicas de medición de procesos de s6.4,
S5.7,
software c8
s9.8

5. Proceso de Ingeniería de Software Herramientas s8.7

8-14 Guía SWEBOK® V3.0
LECTURAS
Software de la extensión de la Guía para el Proyecto  [1 *] RE Fairley, La gestión y líder
Cuerpo de Gestión de Knowledge® ( SWX) [5].
SWX ofrece adaptaciones y ampliaciones de las prácticas genéricas
de gestión de proyectos documentado en el Guía del PMBOK® para
la gestión de proyectos de software. La principal contribución de
esta extensión a 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 tecno-
evaluación-Parte-logía Proceso 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 forman las
evaluaciones de proceso.
Referencias
 
Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009.
[2 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
Wiley-IEEE Computer Society Press, 2006.
[3 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[4 *] SH Kan, Métricas y modelos de software 
Ingeniería de calidad, 2ª ed., Addison-Wesley,
2002.
[5] Instituto de Gestión de Proyectos e IEEE
Computer Society, Software de la extensión de la Guía
del PMBOK® 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
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.
 CAPÍTULO 9

MODELOS DE INGENIERÍA DE SOFTWARE

Y MÉTODOS

SIGLAS DISTRIBUCIÓN DE TEMAS PARA MODELOS Y

MÉTODOS DE INGENIERÍA DE SOFTWARE
3GL Tercera generación de lenguaje BNF

Backus-Naur Form FDD

Característica-Driven IDE Desarrollo Este capítulo sobre modelos de ingeniería de software y métodos se
divide en cuatro áreas temáticas principales:
Entorno de desarrollo
integrado PBI
• Modelado: discute la práctica general de modelado y
La cartera de productos Artículo
presenta temas en los principios de modelado;
RAD El rápido desarrollo de aplicaciones UML propiedades y expresión de los modelos; modelado de
Unified Modeling Language XP sintaxis, la semántica y la pragmática; y las condiciones
previas, postcondi- ciones, e invariantes.
Programación extrema

• Tipos de modelos: discute brevemente modelos y agregación de

INTRODUCCIÓN
modelos y métodos de ingeniería de software imponen estructura en
la ingeniería de software con el objetivo de hacer que la actividad
sistemática y repetible, y en definitiva más éxito-orientado. El uso de
modelos proporciona un enfoque para la resolución de problemas,
una notación, y los procedimientos para la construcción y análisis de
modelo. Métodos proporcionan una aproximación a la especificación
sistemática, diseño, construcción, pruebas y verificación del software
de punto final y los productos de trabajo asociados. modelos y
métodos de ingeniería de software varían ampliamente en su
alcance-de abordar una sola fase del ciclo de vida del software de
cubrir el ciclo de vida del software pleta com-. El énfasis en esta
área de conocimiento (KA) está en ingeniería de software modelos y
métodos que abarcan múltiples fases del ciclo de vida del software,
ya que los métodos específicos para las fases individuales del ciclo
de vida están cubiertas por otra KAs.
submodelos y proporciona algunas características generales de
los tipos de modelo comúnmente encontradas en la práctica de la
ingeniería de software.
• El análisis de los modelos: presenta algunas de las técnicas de
análisis comunes utilizados en ing modelo- para verificar la
integridad, la consistencia, rectness cor-, trazabilidad, y la
interacción.
• Métodos de software de ingeniería: presenta un breve resumen
de los métodos de ingeniería de software de uso común. La
discusión se guía al lector a través de un resumen de los
métodos heurísticos, métodos formales, la creación de
prototipos, y los métodos ágiles.
El desglose de los temas para los modelos de ingeniería de
software y métodos KA se muestra en la Figura 9.1.

1. Modelado

Modelización de software se está convirtiendo en una técnica generalizada

para ayudar a los ingenieros de software a entender,

9-1
9-2 Guía SWEBOK® V3.0
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- ware a las partes
interesadas pertinentes. Las 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 autori- dad, 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  normas para la expresión del modelo dentro de cada vista.
[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
decisiones sobre el software o elementos de la misma, y ​la
comunicación de los
decisiones importantes a otros en las 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
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 mediante las apropiadas
notación, el vocabulario, métodos y herramientas.
• Permitir comunicaciones efectivas: modelado emplea el
dominio de aplicación 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 la simplificación de un
componente de software. Una consecuencia del uso de la
abstracción es que hay una única abstracción completa- mente
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 en conflicto, ciones aseveraciones, restricciones,
funciones o descripciones de componentes.
• Exactitud: el grado en que el modelo satisface sus
requisitos y el diseño especifi- caciones y está libre de
defectos.
Modelos de Ingeniería de Software y Métodos 9-3
Los modelos se construyen para representar objetos del mundo
real y sus comportamientos para responder a preguntas específicas
acerca de cómo se espera que el software para operar. Interrogar a
los modelos, ya sea a través de la exploración, simulación, o
revisión-puede exponer áreas de incertidumbre dentro del modelo y
el software al que se refiere el 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 rela-
ciones (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]
Los modelos pueden ser sorprendentemente engañoso. El hecho de
que un modelo es una abstracción con la falta de informa- ción puede
conducir a uno en un falso sentido de completa- mente la comprensión
del software de un solo modelo. Un modelo completo ( “completo”
siendo
9-4 Guía SWEBOK® V3.0
en relación con el esfuerzo de modelado) puede haber una unión de varios
submodelos y cualquiera de los modelos de función especiales. El examen
y la relación tivo de toma de decisiones a un modelo único dentro de esta
colección de submodelos pueden ser problemáticos.
La comprensión de los significados precisos de 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 len- guaje 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 y
con- las cajas 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 entorno de modelado; esto puede
no ser obvia. El modelo debe ser revisado para supuestos
documentados. Mientras que la sintaxis de modelado puede ser
idéntico, el modelo puede significar algo muy diferente en el nuevo
entorno, que es un contexto diferente. Además, consideran que
como software madura y se realizan cambios, la discordia
semántica
puede ser introducido, lo que conduce a errores. Con muchos
ingenieros de software que trabajan en una parte del modelo con el
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.
• Condiciones posteriores: 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 de Modelos
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 específico; que puede estar compuesta de uno o más
diagramas. La colección de submodelos puede emplear
múltiples

lenguajes de modelado o una sola modelado LANGUAGE. El
Lenguaje de Modelado Unificado (UML) reconoce una rica colección
de modelar dia- gramos. El uso de estos diagramas, junto con las
construcciones del lenguaje de modelado, lleva cerca de tres tipos de
modelos generales de uso común: los modelos de información,
modelos de comportamiento, y los modelos de estructura (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 fun- ciones 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 evento de activación guardado o
descuido que se produce en el entorno de modelado. modelos de flujo de
control representan cómo una secuencia de acontecimientos provoca
procesos para ser activado o desactivado. Los datos de flujo tamiento ior
se tipifica como una secuencia de pasos donde los datos se mueve a
través de procesos hacia almacenes de datos o sumideros de datos.
Modelos de Ingeniería de Software y Métodos 9-5
2.3. Modelado estructura
[1 *, c7s2.5, c7s3.1, c7s3.2] [3 *, c5s3] [4 *, c4]
modelos de estructura ilustran la composición física o lógica de
software a partir de sus diversas partes compo- nente. modelado
de 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 fun- cional, 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 modelos de estado se alcanzan por un
conjunto de entradas correctas); modelos también se pueden examinar
para Ness COMPLETE- manualmente mediante inspecciones u otras
técnicas de revisión (ver la calidad KA Software). errores
9-6 Guía SWEBOK® V3.0
y avisos generados por estas herramientas de análisis y demostrado en
una inspección o revisión indican las acciones correctivas necesarias
probables para garantizar la integridad de los modelos.
3.2. La consistencia para analizar
[3 *, c4s1.1p7, c4s6] [5 *, P8-11]
La consistencia es el grado en que los modelos con- tienen no hay
requisitos en conflicto, afirmaciones, straints con-, funciones o
descripciones de componentes. 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 indicar 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]
El desarrollo de software normalmente implica el uso, creación y
modificación de muchos productos de trabajo, tales como documentos
de planificación, especificación ciones de proceso, requisitos de
software, diagramas, diseños
y pseudo-código, código escrito a mano y generado herramienta, casos
manuales y automatizados de prueba e informes, y archivos y datos. Estos
productos de trabajo 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 manage- ment de productos de trabajo de software y
software de calidad pro- ceso; 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 oper- ating, middleware,
y aplicaciones). También puede ser importante para algunas
aplicaciones de software para examinar las interacciones entre la
aplicación de software orde- nador 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 análisis para el
ingeniero de software para revisar el diseño de interacción y verificar
que las diferentes partes de la obra de software juntos para
proporcionar las funciones previstas.

4. Métodos de ingeniería de software
métodos de ingeniería de software proporcionan un enfoque
sistemático y nizado or- al desarrollo de soft- ware para un equipo de
destino. Existen numerosos métodos entre los que elegir, y es
importante para el ingeniero de software para 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 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.
• Datos métodos de modelado: El modelo de datos se construye
desde el punto de vista de los datos o informaciones utilizados.
Las tablas de datos y barcos PARENTESCO definen los modelos
de datos. Este método mo- datos eling se utiliza principalmente
para definir y analizar las necesidades de datos de apoyo
Modelos de Ingeniería de Software y Métodos 9-7
diseños de bases de datos o datos de repositorios Tıpicamente
encuentran en software de negocios, donde los datos se gestiona
activamente como un recurso sistemas de negocio o activo.
• Análisis y Diseño Orientado a Objetos met ODS-: 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 mode- los 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.
• Idiomas: Especificación Especificación
lenguajes 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, análisis de requerimientos, y / o etapas de
diseño específico para describir la entrada / salida
comportamiento. lenguajes de especificación son idiomas no
directamente ejecutables; son
9-8 Guía SWEBOK® V3.0
típicamente compuesto de una notación y sintaxis, la semántica
para el uso de la notación, y un conjunto de relaciones permitidos
para objetos.
• Programa de Perfeccionamiento y 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: la verificación de modelos 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: 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 predecir el
comportamiento del software sin tener que ejecutar el
software. Algunos entornos de desarrollo integrado (IDE)
incluyen formas de representar estas pruebas junto con el
diseño o código.
4.3. Los métodos de prototipado
[1 *, c12s2] [3 *, c2s3.1] [6 *, c7s3p5]
creación de prototipos de software es una actividad que generalmente
crea siones ver- 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 compo- nentes 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 traba- jando, 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.
• Creación de un prototipo de destino: El objetivo de la actividad proto-
tipo 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 proto- tipo puede
ser usado o evaluado en un nú- mero de maneras por el
ingeniero de software u otros interesados ​en el proyecto,
impulsado principalmente por las razones subyacentes que
llevaron a promover el desarrollo del totipo en el primer lugar.
totypes Pro- pueden ser evaluados o probados contra el
software implementado real o contra

un objetivo conjunto de requisitos (por ejemplo, un prototipo
requisitos); el prototipo también puede servir como modelo para
un futuro esfuerzo de desarrollo de software (por ejemplo, como
en una especificación de interfaz de usuario).
4.4. Los métodos ágiles  definidas, prioridad, y estima. Una versión traba- jando del
[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 asocia- dos 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 lit- eratura; 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 enfoque 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 ensayaron. Cada ment
incre- de software se prueba con pruebas automatizados y
manuales; un incremento puede ser liberado con frecuencia,
como cada dos semanas más o menos.
Modelos de Ingeniería de Software y Métodos 9-9
• Melé: Este enfoque es más ágil la gestión del medio ambiente
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,
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 software.
9-10 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Boehm y Turner 2003

Mellor y Balcer 2002

Sommerville 2011

Brookshear 2008
Página-Jones 1999
Budgen 2003

ala 1990

[7 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
[1 *]

1. Modelado

C2S2,
1.1. Principios de
c5s1, C2S2 c5s0
modelado
c5s2

1.2. Propiedades y c4s1.1p7,

c5s2,
Expresión de Modelos c4s6p3,
c5s3
c5s0p3

1.3. Sintaxis, la
c2s2.2.2
semántica y la c5s0
P6
pragmática

1.4. Condiciones previas, c10s4p2,

postConditions, e c4s4 c10s5
invariantes p2p4

2. Tipos de Modelos

2.1. Modelado de
c7s2.2 c8s1
información

c7s2.1,
2.2. Modelado del
c7s2.3, c9s2 c5s4
comportamiento
c7s2.4

c7s2.5,
2.3. Modelado
c7s3.1, c5s3 c4
estructura
c7s3.2

3. Análisis de Modelos

3.1. Para completar el c4s1.1p7,

pp8-11
análisis c4s6

3.2. La consistencia para c4s1.1p7,

pp8-11
analizar c4s6

3.3. El análisis de la
pp8-11
corrección

c4s7.1,
3.4. trazabilidad
c4s7.2

3.5. Análisis de
c10, c11 c29s1.1, c5
interacción c29s5
 Modelos de Ingeniería de Software y Métodos 9-11

Boehm y Turner 2003

Mellor y Balcer 2002

Sommerville 2011

Brookshear 2008
Página-Jones 1999
Budgen 2003

ala 1990

[7 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
[1 *]

4. Software
Los métodos de ingeniería

c2s2.2,
4.1. Los métodos c13, c15,
c7s1,
heurísticos c16
c5s4.1

4.2. Métodos formales c18 c27 pp8-24

4.3. Los métodos de
c12s2 c2s3.1 c7s3p5
prototipado

c6, app.
4.4. Los métodos ágiles c3 c7s3p7
UN
9-12 Guía SWEBOK® V3.0

Referencias

[1 *] D. Budgen, Diseño de software, 2ª ed., [5 *] JM Wing, “Introducción de un especificador de

Addison-Wesley, 2003.
[2 *] SJ Mellor y MJ Balcer, Ejecutable 
UML: La Base para Model-Driven
Architecture, 1ª ed., Addison-Wesley,
2002.
[3 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
Métodos formales,” Computadora, vol. 23, no. 9,
1990, pp. 8, 10-23.
[6 *] JG Brookshear, Ciencias de la Computación: Un 
Visión de conjunto, 10ª ed., Addison-Wesley, 2008.
[7 *] B. Boehm y R. Turner, agilidad Equilibrio 
y Disciplina: Una Guía de los Perplejos,
Addison-Wesley, 2003.

[4 *] M. Página-Jones, Fundamentos de objeto-

Diseño orientado en UML, 1ª ed., Addison-Wesley,
1999.
 CAPÍTULO 10

La 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 define como la
CMMI
Integration cosq “capacidad de producto de software para satisfacer necesidades
Costo de software comercial de expresadas o implícitas, en condiciones especiales” requisitos [4] y

Commercial Off-The-Shelf como “el grado en que un producto de software cumple creada; Sin
calidad
Software embargo, la calidad depende del grado en que esos requisitos cado
blecimientos representan con exactitud las necesidades de los
Modo de Falla y Efectos FMEA Análisis TLC
interesados, deseos y expectativas”[5]. Ambas definiciones abrazan
El análisis de fallos árbol
la premisa de conformidad con los requisitos. Ni se refiere a tipos de
PDCA Plan-Do-Check-Act PDSA los requisitos (por ejemplo, funcional, fiabilidad, rendimiento,

Plan-Do-Study-Act QFD fiabilidad, o cualquier otra característica). Significativamente, sin

Despliegue de la Función Calidad SPI
Software SQA Mejora de Procesos
Software Quality Assurance SQC
embargo, estas definiciones hacen hincapié en que la calidad
depende de los requisitos. Estas definiciones se ilustran también
otra razón de la prevalencia de la calidad del software lo largo de
esta Guía: una ambigüedad frecuente de la calidad del software versus

SQM Software de Control de Calidad los requisitos de calidad de software

Software de Gestión de Calidad TQM

Gestión de Calidad Total V & V

Verificación y validación
INTRODUCCIÓN
¿Cuál es la calidad del software, y por qué es tan impor- tante que
se incluye en muchas áreas de conocimiento (KAS) de la Guía
SWEBOK?
Una de las razones es que el término la calidad del software está
sobrecargado. La calidad del software puede referirse: a deseable
características capaces de productos de software, en la medida en
que un determinado posi- producto de software sess esas
características, y para procesos, herramientas y técnicas utilizadas
para lograr esas características. Con los años, los autores y
organizaciones han definido el término calidad diferente. Para Phil
Crosby, que era “la conformidad con los requisitos” [1]. Watts
Humphrey refiere a él como “lograr excelentes niveles de‘aptitud
para el uso’[2]. Entre tanto, IBM acuñó la frase “impulsada por el
mercado
("el -ilities ”Es una abreviatura común). los requisitos de calidad de
software son en realidad los atributos de (o limitaciones) sobre los
requisitos funcionales (lo que hace el sistema). Requisitos de software
también pueden especificar el uso de recursos, un protocolo de
comunicación, o muchas otras características. Este KA intenta claridad
mediante el uso de la calidad del software en el sentido más amplio de
las definiciones anteriores y mediante el uso de los requisitos de calidad
de software como con- straints sobre los requisitos funcionales. La
calidad del software se logra mediante la conformidad con todos los
requisitos, independientemente de lo que es característico manera
especificada o cómo se agrupan o se nombra requisitos. La calidad del
software también se considera 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 nieros, el objetivo principal es ofrecer un
valor máximo de las partes interesadas, mientras que el equilibrio de las
limitaciones de costo y cronograma de desarrollo; esto a veces se
caracteriza como “aptitud para

10-1
10-2 Guía SWEBOK® V3.0
Figura 10.1. Desglose de los temas de la calidad del software KA
utilizar.”valor de los grupos de interés se 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.
DISTRIBUCIÓN DE TEMAS PARA LA CALIDAD
DEL SOFTWARE
El desglose de los temas de la calidad del software KA se
presenta en la figura 10.1.
1. Fundamentos de Calidad de 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
ingenieros de software que requieren
los muchos aspectos de la calidad se definirán y discutirán
formalmente.
Un ingeniero de software debe entender los conceptos cali-
dad, 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]
Se espera que los ingenieros de software para 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 pro- ducto. Una ética fuerte de ingeniería de software asume

que los ingenieros informan con precisión la información, con-
diciones, y los resultados relacionados con la calidad. La ética
también juegan un papel importante en la calidad del software, la
cultura, y las actitudes de los ingenieros de software. El IEEE
Computer Society y la ACM han desarrollado un código de ética y
la práctica pro- fesional (ver Códigos de Ética y Conducta
Profesional de la Ingeniería de Software KA Práctica Profesional).
1.2. Valor y costos de la Calidad
[7 *, c17, c22]
Definir y luego la consecución de la calidad del software no es
simple. Las características de calidad pueden o pueden no ser
necesarios, o se les puede pedir a un mayor o menor grado, y las
compensaciones se pueden hacer entre ellos. Para ayudar a
determinar el nivel de calidad del software, es decir, el logro de
valor para los 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.
Los costos de prevención incluyen inversiones en los esfuerzos de
mejora de procesos de software, infra- estructura 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 de
software, pruebas de nivel de sistema, pruebas de aceptación); los costos
de evaluación se extenderían a los proveedores de software
subcontratados. Los costos de fallos internos son los que se incurre para
fijar defectos encontrados durante las actividades de evaluación y
descubrió antes de la entrega de la
La calidad del software 10-3
producto de software para el cliente. costos ure Fail externos incluyen
actividades para responder a problemas de software descubiertas
después de la entrega al cliente. Los ingenieros de software deben ser
capaces de utilizar métodos cosq para determinar los niveles de calidad
del software y también deben ser capaces de presentar alternativas de
calidad y sus costes de manera que se pueden realizar compensaciones
entre costo, horario, y la entrega de valor para los accionistas.
1.3. Modelos y características de calidad
[3 *, c24s1] [7 *, c2s4] [8 *, c17]
Terminología para características de calidad de 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 en el Guía
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 pro-
yecto 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.
10-4 Guía SWEBOK® V3.0
1.3.2. Calidad del producto de software
El ingeniero de software, en primer lugar, debe determinar el verdadero
propósito del software. En este sentido, requisitos de los interesados
​son de suma importancia, y que incluyen los requisitos de calidad,
además de los requisitos fun- cionales. Por lo tanto, los ingenieros de
software tienen la responsabilidad de obtener los requisitos de calidad
que pueden no ser explícita al principio y al Deben conocerse su
importancia, así como el nivel de difi- cultad en el logro de ellos. Todos
los procesos de desarrollo de software (por ejemplo, la 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 desa- rrollo 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 fallos / defecto, la eliminación, y pre- vención, y (3) el
proceso de mejora de la calidad. La teoría y los conceptos detrás
de la mejora de la calidad, tales como la construcción de la
calidad a través de la detección temprana y la prevención de
defectos, la mejora continua de las partes interesadas, y enfoque
son pertinentes para la ingeniería de software. Estos conceptos se
basan en el trabajo de los expertos
en la calidad que han declarado que la calidad de un producto
está directamente relacionada con la calidad del proceso utilizado
para crearlo. Enfoques como el ciclo de mejora de 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 cali- dad ahora es reconocido por el 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
sis- tema 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 indus- tria, 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 para
desarrollar software crítico seguridad-. software indirecta se incluye
en entornos de ingeniería de software y entornos de prueba de
software.

Tres técnicas complementarias para reducción ing el riesgo de
fallo son la evitación, detección y eliminación, y la limitación del
daño. Estos software técnicas impacto requisitos funcionales,
requisitos de rendimiento del software y los procesos de desarrollo.
El aumento de los niveles de riesgo implican el aumento de los
niveles de calidad del software assur- técnicas ANCE y control tales
como las inspecciones. 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 Gestión de Calidad de Software
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 utilizados. dades SQA
activi- definir y evaluar la adecuación de los procesos de software para
proporcionar evidencia que establezca la confianza de que los procesos
de software son consignados para piado y producir productos de
software de calidad traje- poder para los fines previstos [5]. actividades
SQC examinan artefactos específicos del proyecto (docu- mentos y
ejecutables) para determinar si
La calidad del software 10-5
cumplir con las normas establecidas para el proyecto (incluyendo
los requisitos, limitaciones, diseños, contratos y planes). SQC
evalúa inter- medio productos, así como los productos finales. La
cuarta categoría SQM se trata de la mejora tiene varios nombres en
el software indus- tria, incluyendo SPI, la mejora de la calidad del
software y el software de acciones correctivas y preventivas. Las
actividades en esta 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 mate- rial 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 la función SQA con respecto al proyecto.
La función SQA también puede ser organizativamente
independiente de la proyec- ect; es decir, libre de técnica, de
gestión y
10-6 Guía SWEBOK® V3.0
las presiones financieras del proyecto [5]. SQA tiene dos aspectos: de
garantía de producto y de garantía de proceso, que se explican en la
sección 2.3. El plan de la calidad del software (en algunos sectores de
la industria que se denomina el plan de software de aseguramiento de
la calidad) 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 crite- ria, 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],
El propósito de V & V es ayudar a la calidad de
construcción organización desa- rrollo en el sistema
durante el ciclo de vida. procesos de V & V
proporcionan una evaluación objetiva de los productos
y procesos en todo el
ciclo vital. Esta evaluación demuestra si los
requisitos son correctos, com- pleta, precisa,
coherente y comprobable. Los procesos de V & V
determinar si los productos de desarrollo de una
actividad 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 especificacio- nes 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 pro- yecto 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 garantía de producto y auditorías de
aseguramiento de proceso son normalmente llevadas a cabo por la
garantía de la calidad del software (SQA) personal independiente del
desarrollo

equipos. revisiones por la dirección están a cargo de la gestión de la
organización o proyecto. El personal de inge- niería lleva a cabo
revisiones técnicas.
• revisiones por la dirección evalúan los resultados reales del proyecto
con respecto a los planes.
• 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 manteni- miento. 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 incluir informes
de auditoría, informes, V & V informes y planes de muchos tipos,
incluyendo la gestión de riesgos, gestión de proyectos, gestión de
configuración de software, la seguridad de software, y Assessment
riesgo, entre otros progresar. (Consulte el software de gestión de
Inge- niería y el software de configu- ración de Gestión KAs para
el material relacionado).
La calidad del software 10-7
2.3.2. Comentarios técnicos
Como se indica en [16 *],
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 adhesión a la
codificación de las normas, la estructura y
10-8 Guía SWEBOK® V3.0
organización de código para la capacidad de prueba, y consideraciones
críticas la seguridad operacional.
Tenga en cuenta que las revisiones técnicas de los modelos de código
fuente o el diseño tales como UML también se denominan análisis estático
(véase el tema 3, Consideraciones prácticas).
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. Toma de muestras. 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. Peer. 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 miem- bros 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 grabadora, un lector, y algunos (de
dos a cinco) Damas (inspectores). Los miembros de un equipo de
inspec- ción pueden poseer diferentes conocimientos, tales como
experiencia en el campo, experiencia en métodos de diseño de software,
o la experiencia lenguaje de programación. las inspecciones se realizan
normalmente en un relativamente
pequeña sección del producto a la vez (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. Aceptar con ninguna o, a lo sumo, reelaboración de menor importancia
2. Aceptar con la verificación de la reanudación
3. volver a inspeccionar.
2.3.4. Tutoriales
Como se indica en [16 *],
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 soft- ware.
Tutoriales se distinguen de las inspecciones. La diferencia principal
es que los Ents autor Las presiones para el trabajo de productos a los
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 Aseguramiento de auditorías
Como se indica en [16 *],
El propósito de una auditoría de software consiste en pro-
porcionar una evaluación independiente de la con- Formance
de productos de software y pro cesos a los reglamentos
aplicables, normas, directrices, planes y procedimientos.
auditorías de aseguramiento proceso 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. Consideraciones prácticas
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 soft- ware; 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
soft- ware
• (qué tan bien el sistema realiza sus funciones)
requisitos del sistema y software funcional (lo que
hace el sistema) y calidad
• los componentes comerciales (externos) o estándar (inter- nal)
para ser utilizados en el sistema de
La calidad del software 10-9
• las normas específicas de ingeniería de software aplicables
• los métodos y herramientas de software para ser utilizados para
el desarrollo y mantenimiento y para la evaluación y mejora de
cali- dad
• 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 soft- ware 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
La definición de los niveles de integridad es un método de gestión de
riesgos.
los niveles de integridad de software son un rango de valores
que representan la complejidad del software, la criticidad, riesgo,
nivel de seguridad, nivel de seguridad,
10-10 Guía SWEBOK® V3.0
rendimiento deseado, fiabilidad, u otras características
únicas en proyectos que definen la importancia del
software para el usuario y adquirente. Las
características utilizadas para determinar el nivel de
integridad puede variar dependiendo de la aplicación
prevista y el uso del sistema. El software es una parte
del sistema, y ​su nivel de integridad se ha de determinar
como una parte de ese 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 puede 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 lenguas evolucionan, junto con los avances en el software
en general tecnolo- gías, aparecen nuevas clases de defectos, y se
requiere una gran cantidad de esfuerzo para interpretar clases
definidas anteriormente. Cuando el seguimiento de defectos, el
ingeniero de soft- ware está interesado no sólo en el número de
defectos, sino también los tipos. Información por sí sola, sin un poco de
clasificación, puede no ser suficiente para identificar las causas
subyacentes de los defectos.
Los tipos específicos de problemas deben ser agrupados para identificar
tendencias en el tiempo. El punto es establecer una taxonomía de
defectos que sea significativo para la organiza- ción y para los ingenieros
de software. las actividades de control de calidad de software descubrir
infor- mación en todas las etapas de desarrollo de software y
mantenimiento. En 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 per- sona. 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 deseada dentro de 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 soft- ware
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 o desde el software
en el servicio y por lo tanto pueden ser utilizados para estimar la
probabilidad de fallos futuros y para ayudar en las decisiones sobre
cuándo detener la prueba. Una probable acción resultante de SQM
hallazgo Ings es eliminar los defectos del producto objeto de examen
(por ejemplo, encontrar y corregir errores, crear nueva construcción).
Otras actividades intentan eliminar

las causas de los defectos, por ejemplo, análisis de la causa raíz
(RCA). RCA actividades incluyen analizar y resumir los resultados
para encontrar las causas de raíz y el uso de técnicas de medición
para mejorar el producto y el 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 cali- dad
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*] equipo de desarrollo. La Prueba KA Software está dedicado
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 soft- ware (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. Se utilizan sobre todo para
verificar los requisitos de software y diseños. En su mayoría se han
utilizado en la veri ficación de partes cruciales de los sistemas
críticos, como los requisitos de seguridad y protección específicas.
(Ver
La calidad del software 10-11
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 soft- ware.
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 inde- pendiente del
enteramente a este tema.
3.3.3. Pruebas
Dos tipos de pruebas pueden caer bajo V & V debido a su
responsabilidad por la calidad de los mate- riales utilizados en el
proyecto:
• 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).
10-12 Guía SWEBOK® V3.0
3.4. Medición de la Calidad de Software
[3 *, c4] [8 *, c17] [9 *, p90]
mediciones de calidad de software se utilizan para apoyar la toma
de decisiones. Con la creciente sofisticación de software, las
cuestiones de calidad van más allá de si es o no el software
funciona a lo bien que logra los 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 desa- rrollo. 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, ji prueba al
cuadrado)
• análisis de tendencia (por ejemplo, gráficos de control; ver
La caja de herramientas de calidad en la lista de lecturas
adicionales)
• la predicción (por ejemplo, modelos de fiabilidad).
Descriptivos técnicas y ensayos basados ​en estadísticas a
menudo proporcionan una instantánea de la más
áreas problemáticas del producto de software bajo examen. Las
tablas y gráficos resultantes son ayudas de visualización, que la
decisión MAK- ERS puede utilizar para enfocar los 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
Proceso de Ingeniería de Software de Kas.
4. Herramientas de software de calidad
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 semántico sin ejecutar el
código, y presentar los resultados a los usuarios. Hay una gran variedad
en la profundidad, THOR oughness, y el alcance de herramientas de
análisis estático que
 La calidad del software 10-13

se puede aplicar a los artefactos incluyendo modelos, además de código • Herramientas que apoyan el seguimiento de los problemas más

fuente. (Véase el trucción Software Con-, pruebas de software, y software para proporcionar una entrada de anomalías descu- Ered

manteni- Software Principal- KAs para las descripciones de las durante las pruebas de software y análisis posterior, disposición y

herramientas de análisis dinámicos.) resolución. Algunas herramientas incluyen soporte para flujo de

trabajo y para el seguimiento del estado de resolución de

Categorías de herramientas de análisis estático se incluyen los problemas.

siguientes: • Herramientas que analizan los datos capturados a partir de entornos

de ingeniería soft- ware y entornos de prueba Ware soft- y producen

• Las herramientas que facilitan y automatizan parcialmente las pantallas visuales de datos cuantificados en forma de gráficos,

revisiones e inspecciones de documentos y código. Estas tablas, y tablas. Estas herramientas incluyen algu- veces la

herramientas pueden trabajar ruta a diferencias ent participantes funcionalidad para realizar un análisis estadístico de los conjuntos

con el fin de automatizar y controlar un proceso de revisión parcial. de datos (por El propósito de las tendencias más exigentes y hacer

Permiten a los usuarios introducir defectos encontrados durante las extremidades anteriores de los contenedores). Algunas de estas

inspecciones y revisiones para su posterior eliminación. herramientas proporcionan tasas de defectos y de inyección de

extracción; densidades de defecto; los rendimientos; distribución de

• Algunas herramientas ayudan a las organizaciones realizar análisis inyección de defectos y con cada una de las fases del ciclo de vida.

de riesgo para la seguridad soft- ware. Estas herramientas

proporcionan, por ejemplo, soporte automatizado para el análisis de

modo de fallo y efectos (FMEA) y el análisis de árbol de fallos

(FTA).
10-14 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

IEEE Std. 1028-2008

Naik y Tripathy 2008

Sommerville 2011

[dieciséis*]
Bott et al. 2000

Wiegers 2003
Voland 2003

Moore 2006
Galin 2004
Kan 2002

[10 *]

[18 *]
[17 *]
[8 *]

[9 *]
[7 *]
[3 *]

[6 *]

1. Calidad del

Software

fundamentos
1.1. Software de
Ingeniería de la
c1s4 c2s3.5
Cultura y Ética

1.2. Valor y Costo c17,

de la Calidad c22

1.3. Modelos y
características de c24s1 c2s4 c17
calidad

1.4. Mejora de la
S2.4
Calidad de c1s4 c24
c11
Software

1.5. software de
c11s3
Seguridad

2. Calidad de
Software
Los procesos de
gestión

2.1. Calidad de C4-C6,

Software C11,
c26-27

c2
S2.3, c8,
2.2. Verificación y c15
validación S1.1,
S3.3 c21

2.3. Revisiones y
c24s3 *
auditorías
 La calidad del software 10-15

IEEE Std. 1028-2008

Naik y Tripathy 2008

Sommerville 2011

[dieciséis*]
Bott et al. 2000

Wiegers 2003
Voland 2003

Moore 2006
Galin 2004
Kan 2002

[10 *]

[18 *]
[17 *]
[8 *]

[9 *]
[7 *]
[3 *]

[6 *]

3. Consideraciones

prácticas de la calidad del

software

c15
s3.2.2,
3.1. Requisitos de
c15
calidad de c11s1 c12
s3.3.1,
software
c16
s9.10

c3s3,
3.2. Caracterización de
c8s8,
defectos
c10s2

c12s5,
3.3. Técnicas
c7s3 c17 c15s1, *
de SQM
P417

3.4. Medición de la
Calidad de c4 c17 p90
Software

4. Herramientas de

software de calidad
10-16 Guía SWEBOK® V3.0
LECTURAS
N. Leveson, Safeware: Sistema de seguridad y  KE Wiegers, Peer Reviews en el software: A
Ordenadores [ 20].
Este libro describe la importancia de las prácticas de seguridad de
software y cómo estas prácticas se pueden incorporar en los
proyectos de desarrollo de software.
T. Gilb, Principios de Ingeniería de Software  determinadas circunstancias se proporciona.
Administración [ 21].
Este es uno de los primeros libros sobre técnicas de desarrollo
iterativo e incremental. El Método Evo define objetivos
cuantificados, frecuentes iteraciones en caja tiempo-, las
mediciones de progreso hacia las metas, y la adaptación de los
planes en base a los resultados reales.
T. Gilb y D. Graham, inspección de software
[22].
Este libro presenta el muestreo y medición de cal estadísticamente
para las revisiones y defectos. Presenta técnicas que producen
resultados cuantificados para reducir los defectos, la mejora de la
productividad, la pista- ing proyectos y la creación de documentación.
 
Guía Práctica [ 23].
Este libro ofrece explicaciones claras y concisas de los diferentes
métodos de revisión por pares que se distinguen por el nivel de
formalidad y eficacia. orientación pragmática para la aplicación de los
métodos y cómo seleccionar qué métodos son apropiados para
NR Tague, La caja de herramientas de calidad, Segunda ed., [24].
Proporciona una pragmática de cómo hacerlo explicación de un amplio
conjunto de métodos, herramientas y técnicas para la resolución de
proble- mas de mejora de calidad. Incluye las siete herramientas
básicas de control de calidad y muchos otros.
IEEE Std. Proyecto de Norma para P730-2013 
Los procesos de software de aseguramiento de calidad [ 5].
Este proyecto de norma expande los procesos 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.
 La calidad del software 10-17

Referencias

[1] PB Crosby, La calidad es gratuito, McGraw-Hill, [13] IEEE Std. 12207-2008 (también conocido como ISO / IEC 

1979. 12207: 2008) Estándar de Sistemas y Software de

Ingeniería de Software-procesos de ciclo de vida, IEEE
[2] W. Humphrey, La gestión del software  2008.
Proceso, Addison-Wesley, 1989.
[14] ISO 9000: 2005 de Gestión de Calidad 
[3 *] SH Kan, Métricas y modelos de software  Sistemas-Fundamentos y vocabulario,
Ingeniería de calidad, 2ª ed., Addison-Wesley, ISO 2005.
2002.
[15] IEEE Std. 1012-2012 estándar para el Sistema 
[4] ISO / IEC 25010: 2011 Sistemas y Software  y software de verificación y validación,
Ingeniería-Systems y requisitos de calidad de IEEE 2012.
software y Evaluación (cuadrado) -Sistemas y
modelos de calidad del software, ISO / IEC 2011. [dieciséis*] IEEE Std. 1028-2008, Reseñas de Software 
y Auditorías, IEEE 2008.

[5] IEEE P730 ™ / D8 Proyecto de Norma para  [17 *] JW Moore, La hoja de ruta de software 
Procesos de Calidad de Software Assurance, Ingeniería: Una guía basada en estándares,
IEEE 2012. Wiley-IEEE Computer Society Press, 2006.

[6 *] F. Bott et al., Cuestiones profesionales en  [18 *] KE Wiegers, Requisitos de Software, segundo
Ingeniería de software, 3ª ed., Taylor & Francis, ed., Microsoft Press, 2003.
2000.
[19] ISO / IEC / IEEE 24765: 2010 Sistemas y 
[7 *] D. Galin, Calidad de Software:  Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
De la Teoría a la implementación, Pearson 2010.
Educación, SA, 2004.
[20] N. Leveson, Safeware: Sistema de seguridad y 
[8 *] S. Naik y P. Tripathy, Pruebas de software  Ordenadores, Addison-Wesley Professional,
y aseguramiento de la calidad: teoría y 1995.
práctica, Wiley-Spektrum, 2008.
[21] T. Gilb, Principios de Ingeniería de Software 
[9 *] P. Clements et al., Software de documentación  Administración, Addison-Wesley Professional,
Vistas: arquitecturas y más allá, 2ª ed., Pearson 1988.
Education, 2010.
[22] T. Gilb y D. Graham, Software 
[10 *] G. Voland, Ingeniería de Diseño, segundo Inspección, Addison-Wesley Professional,
ed., Prentice Hall, 2003. 1993.

[11] RTCA DO-178C, Consideraciones sobre el software  [23] K. Wiegers, Peer Reviews en el software: A 
en sistemas de vuelo y certificación de equipos, Comisión Guía Práctica, Addison-Wesley
Técnica de radio para la aeronáutica, 2011. Professional, 2001.

[24] NR Tague, La caja de herramientas de calidad, 2ª ed.,

[12] IEEE Std. 15.026,1-2011 Trial-Uso Estándar  ASQ Quality Press, 2010.
La adopción de la norma ISO / IEC TR 15026-1: 2010
Sistemas y Software Systems ingeniería- y Software
Assurance-Parte 1: Conceptos y Vocabulario, IEEE
2011.
 CAPÍTULO 11

INGENIERÍA DE SOFTWARE LA
PRÁCTICA PROFESIONAL

SIGLAS de software con las características conocidas y fiabili- dad. Este

requisito exige ingenieros de software que poseen un conjunto

Asociación para la Computación ACM adecuado de conocimientos, habilidades, capacitación y experiencia

maquinaria
en la práctica profesional. El término “práctica profesional” se refiere
BCS Desarrollo de la Sociedad Británica de a una forma de realización de los servicios a fin de lograr los

Computación CSDA Certified Software estándares o criterios determi- nados, tanto en el proceso de

PCSD realización de un servicio y el producto final RESULTEN del servicio.

Estas normas y cri- terios pueden incluir tanto los aspectos técnicos
Certificado de desarrollo de software
asociado y no técnicos. El concepto de la práctica profesional puede ser visto
profesional IEC como más aplicable dentro de aquellas profesiones que tienen un
Comisión Electrotécnica
cuerpo generalmente aceptada de conocimiento; códigos de ética y
Internacional
conducta profesional con sanciones por violaciónes; aceptadas para
IEEE CS IEEE Computer Sociedad IFIP los procesos de acreditación, certificación y concesión de licencias;

Internacional. Federación de y las sociedades profesionales para proporcionar y administrar todos

Información IP Procesamiento estos. La admisión a estas sociedades profesionales a menudo se

basa en una combinación prescribirse de educación y experiencia.
Propiedad Intelectual ISO
Un ingeniero de software mantiene una práctica profesional
Organización Internacional de
mediante la realización de todo el trabajo de conformidad con las
Normalización NDA prácticas generalmente aceptadas, las normas y directrices
Acuerdo de no divulgación de la OMPI establecidas en particular sucesivamente por la sociedad profesional

Mundial de la Propiedad Intelectual aplicable. Por ejemplo, la Association for Computing Machinery

Organización
Organización Mundial del Comercio OMC
INTRODUCCIÓN
El área de conocimiento Tice ticas Profesional de Ingeniería de
Software (KA) tiene que ver con los conocimientos, habilidades y
actitudes que los ingenieros de software deben poseer para
practicar software de inge- niería de manera cal profesional,
responsable, y ethi-. Debido a las aplica- ciones generalizadas de
los productos de software en la vida social y personal, la calidad de
los productos de software puede tener un profundo impacto en
nuestro bienestar personal y la armonía social. Los ingenieros de
software deben manejar los problemas de ingeniería únicas,
produciendo
(ACM) y la Sociedad IEEE Com- puter (IEEE CS) han establecido un
Código Ingeniería Cesión de Software de Ética y Práctica
Profesional. Tanto la British Computer Society (BCS) y la Federación
Internacional para el Tratamiento de la Información (IFIP) han
establecido normas de la práctica pro- fesional similares. ISO / IEC e
IEEE han proporcionado aún más los estándares de ingeniería de
software internacionalmente aceptadas (véase el Apéndice B de
este
Guía). IEEE CS ha establecido dos programas internacionales de
certificación (CSDA, PCSD) y un correspon- diente Guía de la
Ingeniería de Software de Administración de Conocimiento (Guía
SWEBOK). Todos estos son

11-1
11-2 Guía SWEBOK® V3.0

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 profe- sional 11.1. Las subáreas presentados en este KA son el profesionalismo,
de la ingeniería de software. la dinámica de grupo y la psicología, y habilidades de comunicación.

DISTRIBUCIÓN DE TEMAS PARA LA

PRÁCTICA PROFESIONAL DE INGENIERÍA 1. Profesionalismo
DE SOFTWARE
Un ingeniero de software muestra el profesionalismo en
desglose de los temas de la Ingeniería de Software Profesional particular mediante la adhesión a códigos de ética y
Práctica de KA se muestra en la figura conducta profesional y las normas y

prácticas que son establecidos por la comunidad profesional
del ingeniero.
La comunidad profesional es a menudo representada por una o
varias sociedades profesionales; aquellas sociedades publican
códigos de ética y conducta profe- sional, así como los criterios para
la admisión a la 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  calificación de una persona como ingeniero de software. Por ejemplo,
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 institu- ciones más
altas o más especializados o para el ejercicio profesional” [2].
1.1.2. Proceso de dar un título
Certificación se refiere a la confirmación de las características
particulares de cada per- sona. Un tipo común
Ingeniería de Software Profesional Práctica 11-3
de la certificación es la certificación profesional, cuando una persona
está certificado como ser capaz de completar una actividad en una
cierta disciplina en un nivel determinado de competencias. certificación
profesional también puede verificar la capacidad del titular para
cumplir con las 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 organiza- ciones no
gubernamentales, como las asociaciones profesionales. En la
ingeniería de software, certificación monio con inversión extranjera a la
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 soft- ware 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 activi- dades 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 profesional a través de su carrera, las
habilidades y capacidades requeridas cambiar y evolucionar. En
general, los ingenieros tienen licencia como un medio de proteger al
público de personas no cualificadas. En algunos países, no se puede
ejercer como ingeniero de pro- fesional menos que esté autorizado;
o más, sin
11-4 Guía SWEBOK® V3.0
empresa puede ofrecer “servicios de ingeniería” a no ser que al menos
un ingeniero con licencia se emplea allí.
1.2. Códigos de Ética y Conducta Profesional  responsabilidad de su propio estudio tinuing con- para mantenerse
[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 po- sible 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 con- cerning el público, clientes
y empresarios, el producto, el juicio, la gestión, profe-
sión, colegas, y el auto, respectivamente .
Dado que se pueden introducir normas y códigos de ética y
conducta profesional, modificado o reemplazado en cualquier
momento, inge- niería de software individuales tienen la
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 correspon- dientes. 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 gene-
ralmente 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]
normas de ingeniería de software abarcan 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
este Guía proporciona orientación sobre las normas de ingeniería de
software IEEE e ISO / IEC que apoyan las áreas de conocimiento de
esta Guía.
Los beneficios de las normas de ingeniería de software son muchas e
incluyen la mejora de la calidad del software,

ayudar a evitar errores, la protección de los productores y los usuarios
de software, el aumento de disci- plina profesional, y ayudar a la
transición de la tecnología.
1.5. Impacto económico de Software
[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 suministrador de empresa a
cliente, Engineer- asesoramiento a cliente, contratación directa, o
incluso como voluntario. En todas estas situaciones, el al cliente
central y proveedor de acuerdo en que un producto o ser- vicio será
proporcionado a cambio de algún tipo de
Ingeniería de Software Profesional Práctica 11-5
consideración. En este caso, estamos más preocupados con el
arreglo de ingeniero a los clientes y sus acompañantes acuerdos o
contratos, si son de la variedad contratación directa o consultor, y
los problemas que suelen abordar. 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 intelec- tual (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.
Por último, los 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 para poseer el
conocimiento de estas cuestiones y su aplicabilidad. cuestiones legales se
basan jurisdiccionalmente; Los ingenieros de soft- ware deben consultar a
los abogados que
11-6 Guía SWEBOK® V3.0
especializarse en el tipo y la jurisdicción de cualquier problema legal
tificado iden-.
1.7.1. normas
normas de ingeniería de software establecen 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 este
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].
La protección de marcas 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 intelec- tual como medio de estimular la in-
novación y la creatividad.
1.7.3. patentes
Las patentes protegen el derecho del inventor a cantes tura y vender una
idea. Una patente consiste en un conjunto de derechos exclusivos
concedidos por una ernment gobier- soberano a un individuo, grupo de
individuos, o de la organización durante un periodo limitado de tiempo.
patentes
son una forma antigua de la protección idea de la propiedad y se
remontan al siglo 15. Solicitud de patente implica un registro cuidadoso
del proceso que condujo a la 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 soft-
ware.
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. Secretos comerciales
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
Es común que los ingenieros de software para ser con- cerned con
cuestiones de responsabilidad profesional. Como

un individuo presta servicios a un cliente o empleador, es vital para
cumplir con las normas 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 desa- rrollo
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 internacional se
puede acceder desde la Organización Mundial del Comercio
(OMC).
Ingeniería de Software Profesional Práctica 11-7
1.7.8. Cumplimiento comercial
Todos los profesionales de software deben estar al tanto de las
restricciones legales a la importación, exportación o reexportación de
mercancías, servicios y tecnología en las 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 sis- tema. 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 activi- dad 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 
[1 *, c10s5.8] [3 *, c1s5] [5 *, c32]
Proporcionar clara, completa y precisa docu- mentación es la
responsabilidad de cada ingeniero de software. La idoneidad
de la documentación es
11-8 Guía SWEBOK® V3.0
juzgado por diferentes criterios basados ​en las necesidades de los
diversos públicos interesados.
Una buena documentación cumple con las 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 desa-
rrollo.
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 procedimientos críticos.
El uso de software puede incluir la instalación, fun-
cionamiento, la administración y el desempeño de otras
funciones por varios grupos de usuarios y personal de apoyo. Si
el cliente adquirirá la propiedad
del código fuente del software o el derecho a modificar el código, el
ingeniero de software debe proporcionar documentación de las
especificaciones funcionales, el diseño del 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 costo contra el riesgo, especialmente donde la
producción primaria y los costos basados ​en el riesgo ary de segunda
deben comercializarse uno contra el otro.

Un ingeniero de software debe realizar un análisis de equilibrio de una
manera ética de manera -en particular por ser objetiva e imparcial la hora
de seleccionar los criterios para la comparación de soluciones a los
problemas 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  En general, de un individuo (en particular, de un ingeniero de software)
[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.
Los miembros del equipo 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 comuni- carse con claridad, directamente
entre sí y en el docu- mentos, 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 calidad del software KA).
Esto permite que todos los miem- bros que persiguen un ciclo de
mejora continua y el crecimiento sin riesgo personal. En general, los
miembros de equipos cohesivos demuestran respeto por los demás y
su líder.
Ingeniería de Software Profesional Práctica 11-9
Un punto a destacar es que el software de inge- nieros deben ser
capaces de trabajar en entornos multidisciplinares y en variados
campos de aplicación. Dado que el software de hoy está en todas
partes, desde un teléfono a un 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 proble- ma. 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.
la capacidad 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, ya sea dominio de aplicación o de
organización,
• 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 con- sultado 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 KA). El desglose de los problemas y les resolución de una
sola pieza a la vez reduce la sobrecarga cognitiva. Aprovechando la
curiosidad profesional y la búsqueda del desarrollo profesional continuo
11-10 Guía SWEBOK® V3.0
mediante la formación y estudio añadir habilidades y El conocimiento de
la cartera del ingeniero de software; la lectura, la creación de redes, y
experimentando con nuevas herramientas, técnicas y métodos son
válidos todos los medios de desarrollo profesional.
2.3. Tratar con el problema Complejidad 
[3 *, c3s2] [5 *, c33]
Muchos, si no la mayoría, blemas de ingeniería de software blemas son
demasiado complejos y difíciles de abordar en su conjunto o para ser
abordado por los ingenieros de software individuales. Cuando surgen tales
circunstancias, los medios habituales para adoptar es el trabajo en equipo
y el problema de la descomposición (véase el problema técnicas de
resolución en los Fundamentos de Informática KA).
Los equipos trabajan juntos para resolver los problemas más
complejos y grandes por compartir las cargas y N ° de dibujo en el
conocimiento y la creatividad de cada uno. Cuando los ingenieros de
software trabajan en equipos, puntos de vista dife- rentes y habilidades de
los ingenieros individuales se complementan entre sí y ayudar a construir
una solución que sea de otro modo difícil de conseguir. Algunos ejemplos
de trabajo en equipo espe- CIFIC a la ingeniería de software son la
programación en parejas (ver Métodos ágiles en los modelos de
ingeniería de software y métodos KA) y la revisión de código (ver
revisiones y auditorías de la calidad del software KA).
2.4. La interacción con las partes interesadas
[9 *, c2s3.1]
El éxito de una empresa de ingeniería de software depende de las
interacciones positivas con los titulares de stake-. Deben proporcionar
apoyo, informa- ción, y la retroalimentación en todas las etapas del
proceso del ciclo de vida del software. Por ejemplo, durante las
primeras etapas, es fundamental para identificar todas las partes
interesadas y descubrir cómo el producto les afecta, por lo que la
definición suficiente de la parte interesada los requisitos puede ser
adecuada y completamente capturado. Durante el desarrollo, los
interesados ​pueden pro- vide retroalimentación sobre las
especificaciones y / o las primeras versiones del software, cambio de
prioridad, así como la clarificación de requisitos detallados o nuevo
software. Por último, durante el mantenimiento de software y hasta el
final de su vida útil, los interesados ​Pro- retroalimentación vide en
evolución o nuevos requisitos que los informes de problemas así para
que el software puede ser ampliado y mejorado.
Por lo tanto, es vital para mantener abierta la comunicación y pro-
ductiva con las partes interesadas para la duración de la vida útil del
producto de software.
2.5. Superación de la incertidumbre y la ambigüedad 
[4 *, c24s4, c26s2] [9 *, c9s4]
Al igual que con los ingenieros de otros campos, los ingenieros de
software a menudo deben atender y resolver la incertidumbre y la
ambigüedad, mientras que la prestación de servicios y el desarrollo de
productos. El ingeniero de software debe atacar y reducir o eliminar
cualquier falta de claridad que es un obstáculo para la realización de
trabajos. A menudo, la incertidumbre es simplemente un reflejo de la falta
de conocimiento. En este caso, la investigación mediante el recurso a
fuentes formales tales como libros de texto y revistas profesionales,
entrevistas con ERS stakehold-, o consulta con los compañeros y
compañeros puede superarla.
Cuando la incertidumbre o ambigüedad no pueden ser excesivamente
sido fácil, los ingenieros de software u organizaciones pueden optar por
considerar como un riesgo del proyecto. En este caso, las estimaciones de
trabajo o de precios se ajustan para mitigar el costo anticipado de hacer
frente a ella (véase Gestión de Riesgos en el KA Software Engineering
Management).
2.6. Tratar con entornos multiculturales 
[9 *, c10s7]
entornos multiculturales 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 las normas etal
ciedades y que no todas las sociedades derivan las mismas soluciones
y expectativas.
Esta tolerancia y comprensión ing acompañante pueden ser
facilitadas por el apoyo de la dirección y gestión. comunicaciones
más 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  tomar decisiones, y deben ser generados planes. Cuanto mayor sea
[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 para ellos, lo que simplifica o
explicarla de manera que puedan tomar la decisión final entre
soluciones de la competencia. La lectura y la comprensión de código
fuente es también un componente de recopilación de información y
resolución de problemas. Al modificar, extender,
Ingeniería de Software Práctica Profesional 11-11
o software de reescritura, es fundamental para comprender tanto su
implementación derivado directamente del código presentado y su
diseño, que a menudo se debe inferirse.
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
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
útil, no siempre es suficiente; También, si uno envía demasiados
mensajes, se hace difícil identificar la información importante. Cada
vez más, las organizaciones están utilizando la empresa
11-12 Guía SWEBOK® V3.0
herramientas de colaboración para compartir información. Otras medidas,
además, el uso de almacenes de información electrónicos, accesibles a
todos los miembros del equipo, para las políticas organiza- cionales,
normas, procedimientos comunes de la ingeniería, y la información
específica del proyecto, puede ser más beneficioso.
Algunos equipos de ingeniería de software se centran en la
interacción cara a cara y promover dicha interacción por el arreglo de
oficinas. Aunque las oficinas privadas mejoran la productividad
individual, implantación común de los miembros del equipo en formas
físicas o virtuales y proporcionar áreas de trabajo comunal que es
importante para los esfuerzos de colaboración.
3.4. Habilidades de presentación  archivados en forma de diapositivas, el conocimiento contra escritura
[3 *, c1s5] [4 *, c22] [9 *, c10s7-c10s8]
Los ingenieros de software confían en sus habilidades de presentación
durante los procesos del ciclo de vida del software. Por ejemplo,
durante los requisitos de software
fase, los ingenieros de software puede caminar a los clientes y
compañeros de equipo a través de los requisitos de software y llevar a
cabo los requisitos formales reseñas (véanse los requisitos críticas en el
software de los requisitos KA). Durante y después del diseño de
software, la construcción de software y mantenimiento de software,
ingenieros de software llevan los comentarios, walk-through de
productos (véase comprobación y actuaciones en la calidad del software
KA), y la formación. Todo esto requiere la capacidad de presentar
información técnica a los grupos y solicitar ideas o comentarios. La
capacidad del ingeniero de software para transmitir conceptos de
manera efectiva en una presentación, por lo tanto influye en la
aceptación del producto, gestión y atención al cliente; sino que también
influye en la abil- dad de las partes interesadas a comprender y ayudar
en los esfuerzos de producto. Este conocimiento tiene que ser
hasta, white papers técnicos, y cualquier otro material utilizado para la
creación de conocimiento.
 Ingeniería de Software Práctica Profesional 11-13

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

IEEE-CS / ACM 1999

Sommerville 2011
Bott et al. 2000

McConnell 2004

Tockey 2004
Voland 2003

Fairley 2009
Moore 2006

[8 *]

[9 *]
[7 *]
[5 *]
[3 *]

[4 *]

[6 *]
[1 *]

1. Profesionalismo

1.1. Acreditación, c1s4.1,

Certificación y c1s5.1-
Licencias c1s5.4

1.2. Códigos de Ética y

c1s9
Conducta Profesional c8 c1s2 c33 *
c1s6-

1.3. La naturaleza y la función

c1s2
de las Sociedades c1s2 c35s1
c1s1-
Profesionales

1.4. La naturaleza y la

función de las normas de c5s3.2,

c32s6 c1s2
ingeniería de software c10s2.1

1.5. Impacto económico

c10s8 c1s1.1 c1
de Software

1.6. Contratos de
c7
trabajo

1.7. Asuntos legales C6, C11 c5s3- c1s10

c5s4

1.8. c10s5.8 documentación c1s5 c32

1.9. Análisis c1s2,

c9s5.10
compensación c10

2. Grupo de Dinámica y
Psicología

2.1. Dinámica de trabajo

c1s3.5,
en equipos / grupos c1s6
c10

2.2. cognición
c1s6.5 c33
individual

2.3. 2.3 Tratar con

c3s2 c33
problemas Complejidad

2.4. La interacción con las

c2s3.1
partes interesadas
11-14 Guía SWEBOK® V3.0

IEEE-CS / ACM 1999

Sommerville 2011
Bott et al. 2000

McConnell 2004

Tockey 2004
Voland 2003

Fairley 2009
Moore 2006

[8 *]

[9 *]
[7 *]
[5 *]
[3 *]

[4 *]

[6 *]
[1 *]

2.5. Superación de la
c24s4,
incertidumbre y la c9s4
c26s2
ambigüedad

2.6. Tratar con

entornos c10s7
multiculturales
3. Habilidades de

Comunicación

3.1. Leyendo,
Comprensión, y c33s3
resumir
3.2. Escritura c1s5

3.3. Equipo y
c1s6.8 c22s3 c27s1 c10s4
Comunicación Grupo
3.4. Habilidades de c10s7-
c1s5 c22
presentación c10s8
 Ingeniería de Software Práctica Profesional 11-15

LECTURAS Referencias

Gerald M. Weinberg, La psicología de la  [1 *] F. Bott et al., Cuestiones profesionales en 

Computadora 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 individual y de equipo y se convirtió en un clásico en el fiel re. [2] Diccionario Colegiado de Merriam-Webster,
ed 11., 2003.

Kinney y Lange, PA, Propiedad intelectual  [3 *] G. Voland, Ingeniería de Diseño, 2ª ed.,

Ley para el negocio Abogados [ 11]. Prentice Hall, 2003.

Este libro cubre las leyes de propiedad intelectual en los EE.UU.. No sólo [4 *] I. Sommerville, Ingeniería de software, noveno
habla de lo que el derecho de propiedad intelectual es; También explica ed., Addison-Wesley, 2011.
por qué se ve la forma en que lo hace.

[5 *] S. McConnell, Código completo, 2ª ed.,

Microsoft Press, 2004.

[6 *] IEEE CS / ACM Grupo de Trabajo Conjunto sobre

Ética de software de ingeniería y prácticas

profesionales, “software de código de Ingeniería 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 software 

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

[8 *] S. Tockey, Retorno de software: Maximizar 

el retorno de su inversión en software,
Addison-Wesley, 2004.

[9 *] RE Fairley, La gestión y líder 

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

[10] GM Weinberg, La psicología 

de Programación: Silver Anniversary Edition, Dorset
House, 1998.

[11] Kinney y Lange, PA, Intelectual 

Ley de la Propiedad de negocio Abogados,
Thomson West, 2013.
 CAPÍTULO 12
ECONOMÍA INGENIERÍA DE SOFTWARE
SIGLAS
EVM Gestión de Valor Ganado TIR
Tasa Interna de Retorno TREMA
mínima tasa aceptable de
Volver
SDLC La vida de desarrollo de software de ciclo SPLC
El software del producto ROI del Ciclo de
Vida Retorno de la Inversión ROCE retorno
sobre el capital empleado 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 producción o adquisición de negocios. la
economía de ingeniería de software se ocupa de la alineación de las
decisiones técnicas de software con
12-1
los objetivos de negocio de la organización. En todos los tipos de
organizaciones-sea “con fines de lucro”, “sin fines de lucro,” o
gubernamental, esto se traduce en forma sostenible permanecer en el
negocio. En las organizaciones con fines de lucro “” Esto, además, se
relaciona con achiev- ing un retorno tangible de los invertidos en capital
los activos y el capital empleado. Esta KA ha sido formulado de una
manera para hacer frente a todo tipo de organizaciones independientes
de foco, cartera de productos y servicios, o la propiedad del capital y
las restricciones de la tributación.
Decisiones como “¿Hay que utilizar un compo- nente específico?”
Puede parecer fácil desde el punto de vista técnico, pero pueden tener
graves consecuencias sobre la viabilidad empresarial de un proyecto de
software y el producto resultante. A menudo, los ingenieros se preguntan
si estas preocupaciones se aplican en absoluto, ya que son “sólo los
ingenieros.” Análisis económico y la toma de decisiones son importantes
consideraciones de ingeniería porque los ingenieros son capaces de
evaluar las decisiones tanto técnicamente como desde un punto de vista
comercial. El contenido de esta área de conocimiento son importantes ics
de alta para los ingenieros de software a tener en cuenta, incluso si nunca
realmente están involucrados en concreto de Em- presas de decisiones;
van a tener una visión cabal de las cuestiones de negocios y el papel
racio técnicos consideraciones juegan en la toma de decisiones de
negocio. Muchas de las propuestas de ingeniería y decisiones, tales como
hacer frente a comprar, tienen profundos impactos económicos
intrínsecos que deben ser considerados de manera explícita. Esta KA
cubre primero las fundaciones, minology clave ter-, conceptos básicos y
las prácticas comunes de la economía de ingeniería de software para
indicar la forma en la toma de decisiones en ingeniería de software
incluye o debe incluir un negocio perspec- tiva. A continuación,
proporciona una perspectiva del ciclo de vida, destaca la gestión del
riesgo y la incertidumbre, y muestra cómo se utilizan los métodos de
análisis económico. Algunas consideraciones prácticas terminar el área El
conocimiento.
12-2 Guía SWEBOK® V3.0

Figura 12.1. Desglose de temas para la Ingeniería de Software Economía KA


DISTRIBUCIÓN DE TEMAS PARA ECONOMÍA
INGENIERÍA DE SOFTWARE
El desglose de temas para el Software Inge- niería
Economía KA se muestra en la figura 12.1.
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.
1.2. Contabilidad
[1 *, c15]
La contabilidad es parte de las finanzas. Permite a las personas cuyo
dinero está siendo utilizado para dirigir una organización
Ingeniería de Software Economía 12-3
para conocer los resultados de su inversión: sacaron los beneficios que
se esperaban? En las organizaciones “con fines de lucro”, esto se
relaciona con el retorno de la inversión tangible (ver sección 4.3,
Retorno de la 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 que ser gastado para llevar a cabo esa propuesta dinero. Los
ingresos por ventas de producto X en el mes 11 después de su
lanzamiento al mercado es un ejemplo de un flujo de caja entrante
12-4 Guía SWEBOK® V3.0
Figura 12.2. Un Diagrama de Flujo de Caja
ejemplo. El dinero iba a venir a causa de la realización de la
propuesta. El termino flujo de efectivo se refiere al conjunto de
instancias de flujo de efectivo con el tiempo que son causadas por la
realización de alguna propuesta determinada. 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 igualmente bien, ¿por qué se
elige el cuidado organización cuál? La respuesta es que por lo
general hay una gran diferencia en los costes e ingresos de los
diferentes
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 solu- ciones
alternativas, definir los criterios de selección, evaluar las solu-
ciones, implementar una solución seleccionada, y moni- tor 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. También es importante
entender que este mismo proceso se aplica a todos los niveles de
toma de decisiones: a partir de una decisión tan grande como la
determinación de si un proyecto de software se debe hacer en
absoluto, a una decisión sobre una estructura de algoritmo o de datos
a utilizar en un módulo de 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
diversas interrelaciones, en un conjunto de alternativas sive excluyen
mutuamente. La elección puede hacerse entonces entre estas
alternativas.
Ingeniería de Software Economía 12-5
1.6. Valuación
[1 *, C5, C8]
En un 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 evaluados objetivamente.
12-6 Guía SWEBOK® V3.0
1.7. Inflación
[1 *, c13]
La inflación se describen las tendencias a largo plazo de los precios.
La inflación significa que las mismas cosas cuestan más que antes. Si
el horizonte de planificación de una decisión de negocios es más de
unos pocos años, o si la tasa de inflación es más de un par de puntos
porcentuales por año, puede causar cambios notables en el valor de
una propuesta. Por lo tanto, el valor del tiempo actual necesita ser
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 desa- rrollo 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
deter- minar 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 utilidad bruta de una corporación. Un análisis de decisión
que no tiene en cuenta los impuestos puede conducir a una mala elección.
Una propuesta con una alta ganancia antes de impuestos no se parecerá
casi tan rentable en términos posttax. Sin tener en cuenta los impuestos
también puede conducir a unre- alistically altas expectativas sobre la
rentabilidad podría ser un producto propuesto.
1.10. Valor temporal del dinero
[1 *, c5, c11]
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 con- cepto ha estado presente
desde la historia humana registrada más temprana y es comúnmente
conocido como valor del 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 desde una
perspectiva económica. La salida es el valor

entregado. Entrada abarca todos los recursos (por ejemplo,
esfuerzo) pasaron a generar la salida. Productividad com- eficiencia
y eficacia combina desde una perspectiva orientada de valor: la
maximización de la productividad es sobre la generación de mayor
valor con menor consumo de recursos.
2. La vida de ciclo Economía
2.1. Producto
[2 *, c22] [3 *, c6]
Un producto es un bien económico (o de salida) que se crea en un
proceso que transforma fac- tores de productos (o entradas) a una
salida. Cuando se vende, un pro- ducto es un entregable que crea un
valor y una experiencia para sus usuarios. Un producto puede ser una
combinación de sistemas, soluciones, materiales, y servicios
entregados internamente (por ejemplo, en casa de la solución IT) o
externamente (por ejemplo, software aplicabilidad ción), ya sea tal cual
o como un componente para otro producto (por ejemplo, , software
embebido).
2.2. Proyecto
[2 *, c22] [3 *, c1]
Un proyecto es “un esfuerzo temporal emprendido para crear un
único producto, servicio o resultado”. 1
En la ingeniería de software, diferentes tipos de proyectos se distinguen
(por ejemplo, el desarrollo de productos, servicios externalizados,
mantenimiento de software, la creación de ser- vicio, y así
sucesivamente). Durante su ciclo de vida, un producto de software puede
requerir muchos proyectos. Por ejemplo, durante la fase de concepción
del producto, un proyecto podría llevarse a cabo para determinar los
requisitos de necesidad del cliente y del mercado; durante el
mantenimiento, un proyecto podría llevarse a cabo para producir una
próxima versión de un producto.
2.3. Programa
Un programa es “un grupo de proyectos relacionados, subprogramas y
actividades del programa gestionado de manera coordinada para obtener
beneficios que no están disponibles
1 Project Management Institute, Inc., PMI Léxico de Proyecto
Términos de gestión, 2012, www.pmi.org/
PMBOK-Guía-y-Normas / ~ / media / registro /
PMI_Lexicon_Final.ashx .
Ingeniería de Software Economía 12-7
desde la gestión de ellos de forma individual “. 2 Los programas se
utilizan a menudo para identificar y gestionar las diferentes entregas a
un solo cliente o mercado en un horizonte de tiempo de varios años.
2.4. portafolio
Los portafolios son “proyectos, programas, subcarteras y operaciones
gestionadas como un grupo para alcanzar los objetivos estratégicos.” 3 Las
carteras se utilizan para agrupar y gestionar simultáneamente todos los
activos dentro de una línea de negocio o de la organización. Mirando a
una cartera completa se asegura de que los impactos de las decisiones
son consideradas, tales como la asignación de recursos a un proyecto
específico, lo cual significa que los mismos recursos no están disponibles
para otros proyectos.
2.5. Ciclo de vida del producto
[2 *, c2] [3 *, c2]
Un ciclo de vida del producto de software (SPLC) incluye todas las
actividades necesarias para definir, construir, operar, mantener y
retirar un producto de software o servicio y sus variantes. Las
actividades de SPLC “oper- comió”, “mantener” y “retirarse” suelen
ocurrir en un período de tiempo mucho más largo que el desarrollo
de software inicial (el software de vida de desarrollo del ciclo de
SDLC-ver els Software del ciclo de vida en el mo- Ingeniería de
Software proceso KA). También las actividades de operación y
mantenimiento-retirarse de un SPLC consumen típicamente más
esfuerzo total y otros recursos de las actividades SDLC (ver La
mayoría de los costos de mantenimiento en el KA Mantenimiento de
Software). El valor aportado por un producto de software o servicios
asociados puede determinarse objetivamente durante el marco de
“operar y mantener” tiempo. ingeniería de software Economics
deben preocuparse por todas las actividades SPLC, incluyendo las
actividades después de la liberación inicial del producto.
2.6. Ciclo de Vida del Proyecto
[2 *, c2] [3 *, c2]
las actividades del ciclo de vida del proyecto implican típicamente
cinco grupos de iniciación de procesos, planificación, Execut- ción,
seguimiento y control, y cierre [4]
2 Ibídem.
3 Ibídem.
12-8 Guía SWEBOK® V3.0
(Ver el KA Software Engineering Management). Las actividades dentro
de un ciclo de vida del proyecto de software son a menudo intercalada,
se superponen, y reiterada en diversas formas [3 *, c2] [5] (ver la
Ingeniería de Procesos de Software KA). Por ejemplo, el desarrollo de
productos ágil dentro de un SPLC implica múltiples iteraciones que
producen incrementos de software entregable. Un SPLC debe incluir la
gestión del riesgo y la sincronización con los proveedores dife- rentes
(si los hay), al tiempo que proporciona información audit- poder de
toma de decisiones (por ejemplo, comply- ing con las necesidades de
responsabilidad por productos o las reglas de gobierno). El ciclo de
vida del proyecto de software y el software de ciclo de vida del
producto están relacionados entre sí; un SPLC puede incluir varios
SDLCs.
2.7. propuestas
[1 *, c3]
De tomar una decisión de negocios comienza con la noción de una propuesta.
económicos de la propuesta, ya sea de corte de seis años por dos años
Propuestas se refieren a alcanzar un objetivo de negocio, en el
proyecto, producto o nivel de cartera. Una propuesta es una opción
única, separada que se está considerando, como llevar a cabo un
proyecto de desarrollo de software en particular o no. Otra propuesta
podría ser para mejorar un componente de software existen- tes, y
todavía podría ser otra que volver a desarrollar mismo software
desde cero. Cada propuesta representa una unidad de elección, ya
sea que usted puede elegir para llevar a cabo esa propuesta o
puede optar por no hacerlo. Todo el propósito de la toma de
decisiones de negocio es averiguar, dadas las circunstancias
actuales de negocios, que las propuestas deben llevarse a cabo y
cuáles no.
2.8. Decisiones de inversión
[1 *, c4]
Los inversores a tomar decisiones de inversión para gastar dinero y
recursos en la consecución de un objetivo obje- tivo. Los inversores están
ya sea en el interior (por ejemplo, las finanzas, la placa) o fuera (por
ejemplo, bancos) de la organización. El objetivo se relaciona con algunos
criterios económicos, tales como el logro de un alto retorno de la
inversión, el fortalecimiento de las capacidades de la organización, o de
mejorar el valor de la empresa. aspectos Intangi- bles tales como la
buena voluntad, la cultura y competen- cias deben ser considerados.
2.9. Planeando el horizonte
[1 *, c11]
Cuando una organización decide invertir en una propuesta cular
par-, el dinero se hace atar en esa propuesta, los llamados “activos
congelados.” El impacto económico de los bienes congelados tiende
a comenzar y disminuye con el tiempo. Por otra parte, ING y
mantenimiento operat- costes de los elementos asociados con la
propuesta tienden a empezar con poco, pero aumentará con el
tiempo. El costo total de la propuesta, es decir, poseer y operar un
producto es la suma de estos dos costos. Al principio, los costos de
los activos congelados dominan; más tarde, los costos de operación
y mantenimiento dominan. Hay un punto en el tiempo que se
minimiza la suma de los costos; esto se llama el
tiempo de vida mínimo costo.
Para comparar adecuadamente una propuesta con una vida útil de
cuatro años a una propuesta con una vida útil de seis años, los efectos
o invertir los beneficios de la propuesta de cuatro años por otros dos
años deben ser abordados. El horizonte de planificación, a veces
conocido como el período de estudio, es el marco de tiempo constante
durante los cuales se consideran propues- tas. tendrán que tenerse en
cuenta en el establecimiento de un horizonte de planificación efectos
tales como el software vida tiempo. Una vez establecido el horizonte de
planificación, varias técnicas están disponibles para presentar
propuestas de vida diferentes períodos en que el horizonte de
planificación.
2.10. Precio y precios
[1 *, c13]
Un precio es lo que se paga a cambio de un bien o servicio. El precio es
un aspecto fundamental de la modelización financiera y es una de las
cuatro P de la comercialización
mezcla. Los otros tres son Sal producto, promoción y lugar. El precio es
el ele- mento ú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 factura fecha,
combinación de varios pedidos, ofertas de servicios, y muchos otros. Las
necesidades del consumidor se pueden convertir en la demanda sólo si el
consumidor tiene la voluntad y la capacidad para comprar el pro- ducto.
Por lo tanto, el precio es muy importante en la comercialización. La fijación
de precios se realiza inicialmente durante la fase ción iniciativa del
proyecto y es una parte de la toma de decisiones “ir”.
2.11. Costo y costeo
[1 *, c15]
Un coste es el valor del dinero que se ha utilizado para producir algo
y, por lo tanto, no está disponible para su uso más. En economía, un
coste es una alter- nativa que se da como resultado de una decisión.
Un costo hundido es los gastos antes de un cierto tiempo,
normalmente se utiliza para decisiones abstractas de los gastos en
el pasado, 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 manage- ment 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 (llamado manejo de costos) es
importante y siempre debe ser incluido 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 pro- ducto 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 de decisiones económicas.
2.12. Medición del desempeño
[3 *, C7, C8]
La medición del desempeño es el proceso mediante el cual
una organización establece y mide la
Ingeniería de Software Economía 12-9
parámetros utilizados para determinar si los programas,
inversiones y adquisiciones están logrando los resultados
deseados. Se utiliza para evaluar si realmente se logran los
objetivos de rendimiento; para controlar los presupuestos, los
recursos, el progreso y las decisiones; y para mejorar el
rendimiento.
2.13. Gestion del valor ganado
[3 *, c8]
gestión del valor ganado (EVM) es una técnica de gestión de
proyectos para medir el progreso basado 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.
12-10 Guía SWEBOK® V3.0
Figura 12.4. Metas, estimaciones, y Planes
2.15. Las decisiones de reemplazo y jubilación  Uno de los objetivos de negocio se relaciona necesidades empresariales
[1 *, c12] [2 *, c9]
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 fac- tores 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 en su mayoría los
objetivos de negocio (u objetivos de negocio).
(como el aumento de la rentabilidad) a los recursos de inversión (tales
como iniciar un proyecto o el lanzamiento de un pro- ducto 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 en el KA Software
Engineering Management). El plan debe estar en línea con la meta
y el compañero de estimación, que no es necesariamente fácil y
obvi- ous-por ejemplo, cuando un proyecto de software con los
requisitos dados tomaría más tiempo que la fecha límite prevista por
el cliente. En tales casos, los planes exigen una revisión de los
objetivos iniciales, así como Las estimaciones y las incertidumbres
subyacentes y las inexactitudes. soluciones creativas con los
fundamentos del sistema de alcanzar una posición de ganar-ganar
se aplican para resolver conflictos.
Para ser de valor, la planificación debe involucrar consideración con-
de las restricciones del proyecto y los compromisos a los interesados. La
figura 12.4 muestra cómo se definen inicialmente objetivos. Los cálculos
se realizan sobre la base de los objetivos iniciales. El plan intenta hacer
coincidir los objetivos y las estimaciones. Este es un proceso iterativo,
debido a una estimación inicial normalmente no cumple con los objetivos
iniciales.
3.2. Las técnicas de estimación
[3 *, c6]
Las estimaciones se utilizan para analizar y prever los recursos o el
tiempo necesarios para implementar los requisitos (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). Existen cinco familias de técnicas de
estimación:
• Juicio experto
• Analogía
• Estimación por piezas
• 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 factores que causaron la
propagación y luego volver a estimar de nuevo para pro- ducir
resultados que convergen podría conducir a una mejor estimación.
Ingeniería de Software Economía 12-11
3.3. La incertidumbre abordar
[3 *, c6]
Debido a los muchos factores desconocidos durante la iniciación y
planificación de proyectos, las estimaciones son inciertas; que la
incertidumbre debe tratarse de decisiones de negocio. Las
técnicas para hacer frente a la incertidumbre incluyen
• considerar rangos de estimaciones
• analizar la sensibilidad a los cambios de las hipótesis
• retrasar las decisiones finales.
3.4. priorización
[3 *, c6]
Priorización implica alternativas clasificación basada en criterios
comunes para ofrecer el mejor valor posible. En los proyectos de
ingeniería de software, requisitos de software a menudo se
priorizan con el fin de ofrecer el mayor valor al cliente dentro de
straints con- de programación, presupuesto, recursos y tecno-
logía, o para proporcionar para la construcción de incrementos de
productos, donde los primeros incrementos proporcionar el mayor
valor para el cliente (ver requisitos de clasificación y requisitos de
la Negociación en los requisitos de software KA y del ciclo de vida
del software los modelos de la Ingeniería de procesos de Software
KA).
3.5. Las decisiones en riesgo
[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.
12-12 Guía SWEBOK® V3.0

Figura 12.5. El proceso de toma de decisiones con fines de lucro

3.6. Las decisiones bajo incertidumbre [ 1 *, c25] [3 *, c9] 4. Métodos de Análisis Económico

4.1. Con fines de lucro Análisis de Decisiones

Las decisiones bajo incertidumbre técnicas se utilizan cuando el [1 *, c10]
tomador de decisiones no puede asignar probabili- dades a los
diferentes resultados posibles porque la información necesaria no Figura 12.5 se describe un procedimiento para la identificación de la mejor

está disponible (véase Gestión de Riesgos en el KA Software alternativa de un conjunto de alternativas sivos mutuamente exclusiones.

Engineering Management). Las técnicas específicas incluyen Los criterios de decisión dependen de los objetivos de negocio y por lo

general incluyen retorno de la inversión (véase la sección 4.3, Retorno de

la Inversión) o Retorno sobre el capital empleado (ROCE) (ver sección 4.4,

• Regla de Laplace rendimiento del capital invertido). Para fines de lucro técnicas de toma no

• Regla Maximin se aplican a las organizaciones gubernamentales y sin fines de lucro. En

• Regla maximax estos casos, las organizaciones tienen diferentes objetivos, lo que significa

• Regla Hurwicz que se necesita un conjunto diferente de las técnicas de toma, como el

• Regla arrepentimiento minimax. coste-beneficio o el análisis coste-efectividad Ness.


4.2. Tasa aceptable de retorno mínima [ 1 *, c10]
La tasa mínima aceptable de rendimiento (TREMA) es la más baja
tasa interna de retorno de la organiza- ción consideraría como una
buena inversión. En términos generales, no sería inteligente para
invertir en una actividad con un rendimiento del 10% cuando no hay
otra actividad que se sabe que devolver el 20%. La TREMA es una
declaración de que una organización confía en que puede lograr al
menos que la tasa de rendimiento. La TREMA representa el costo
de oportunidad de la organización para las inversiones. Al elegir a
invertir en algún tipo de actividad, la organización está decidiendo
explícitamente a no invertir ese mismo dinero en otro lugar. Si la
organización es ya confía en que puede conseguir un poco de
velocidad conocida de retorno, otras alternativas deben elegirse sólo
si su tasa de rendimiento es al menos tan alto. Una manera sencilla
para dar cuenta de que el coste de oportunidad es utilizar la TREMA
como la tasa de interés en las decisiones empresariales. valor
actual de una alternativa evaluada en la TREMA muestra cuánto
más o menos (en términos de caja actuales) que vale la pena
alternativa es que la inversión en el Marr.
4.3. Retorno de la Inversión
[1 *, c10]
Retorno de la inversión (ROI) es una medida de la rentabilidad de
una empresa o unidad de negocio. Se define como la relación entre
el dinero ganado o perdido (realizadas o no realizadas) en una
inversión con respecto a la cantidad de dinero invertido. El
propósito de retorno de la inversión varía e incluye, por ejemplo,
proporcionando una base para futuras inversiones y decisiones de
adquisición.
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 describe el
rendimiento del capital utilizado.
Ingeniería de Software Economía 12-13
4.5. Análisis coste-beneficio
[1 *, c18]
Análisis coste-beneficio es uno de los métodos más utilizados para
la evaluación de ALS propues- individuales. Cualquier propuesta
con una relación beneficio-costo de menos de 1,0 por lo general
puede ser rechazada sin análisis adicional porque costaría más
que el beneficio. Las propuestas con una necesidad mayor
proporción de con- Sider el riesgo asociado de una inversión y
comparar los beneficios con la opción de invertir el dinero a una
tasa de interés garantizada (ver sec- ción 4.2, aceptable tasa de
retorno mínima).
4.6. Análisis coste-efectividad
[1 *, c18]
Análisis coste-efectividad es similar al análisis de
coste-beneficio. Hay dos versiones de análisis
coste-eficacia: la precio fijo Versión maximiza el beneficio
dado alguna cota superior en el precio; el -Efectividad fijo Versión
minimiza el costo necesario para lograr un objetivo fijo.
4.7. Punto de equilibrio de analisis
[1 *, c19]
análisis de equilibrio identifica el punto en el que los costos de
desarrollo de un producto y los ingresos que se generen son
iguales. Tal análisis se puede utilizar para elegir entre diferentes
propuestas a diferentes costos estimados y los ingresos.
estimación dada acoplado costes e ingresos de dos o más ALS
propues-, análisis de equilibrio ayuda a la hora de elegir entre
ellos.
4.8. Business Case
[1 *, c3]
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
12-14 Guía SWEBOK® V3.0
gerente y utilizada en apoyo de la consecución de los objetivos de
negocio.
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 estudio de una
función de coste en un rango de valores para
encontrar el punto en el rendimiento general es mejor. clásica disyuntiva
espacio-tiempo de software es un ejemplo de optimización; un algoritmo
que se ejecuta más rápido con frecuencia utiliza más memoria.
Optimización equilibra el valor del tiempo de ejecución más rápida contra
el costo de la memoria adicional. 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. Consideraciones prácticas
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
funciona- lidad 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 cali- dad, o
relativas a la programación con- tenido 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 meca- nismos 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 insuficiente
calidad o cantidad insuficiente no es lo suficientemente bueno. Los
métodos ágiles son ejemplos de “suficientemente bueno” que tratan de
optimizar el valor mediante la reducción de la cabeza excesiva de
retrabajo retrasado y el chapado de oro que

resulta de la adición de características que tienen valor marginales
bajos para los usuarios (ver Métodos ágiles en los modelos de
ingeniería de software y métodos KA y Vida Software 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 merca- dos 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
Un ecosistema es un entorno compuesto por todas las partes
mutuamente dependientes, unidades de negocio y empresas que
trabajan en un área particular.
Ingeniería de Software Economía 12-15
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, tradicional- mente, 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 offshor- ing). 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).
12-16 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Sommerville 2011
Tockey 2005

Fairley 2009
[3 *]
[2 *]
[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, C8

2.13. Gestion del valor ganado c8

2.14. Las decisiones de terminación c11, c12 C9

2.15. Las decisiones de reemplazo y jubilación c12 C9

 Ingeniería de Software Economía 12-17

Sommerville 2011
Tockey 2005

Fairley 2009
[3 *]
[2 *]
[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. Consideraciones prácticas

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

12-18 Guía SWEBOK® V3.0

LECTURAS Referencias

Una guía para la Dirección de Proyectos  [1 *] S. Tockey, Retorno de software: Maximizar 

Conocimiento (Guía PMBOK®) [ 4].
los Guía del 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 de la Guía para el Proyecto 
Cuerpo de Gestión del Conocimiento (SWX) [ 5].
SWX proporciona adaptaciones y ampliaciones de las prácticas
genéricas de gestión de proyectos documentado en el Guía del
PMBOK® para la gestión de proyectos de software. La principal
contribución de esta extensión a la Guía del PMBOK® es descrip- ción [5] Instituto de Gestión de Proyectos e IEEE
de los procesos que son aplicables para la gestión de proyectos de
software de ciclo de vida de adaptación.
el retorno de su inversión en software,
Addison-Wesley, 2004.
[2 *] JH Allen et al., software de Seguridad 
Ingeniería: Guía para los gerentes de
proyecto, Addison-Wesley, 2008.
[3 *] RE Fairley, La gestión y líder 
Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009.
[4] 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.
Computer Society, Software de la extensión de la Guía
del PMBOK® quinta edición, ed: Project Management
Institute, 2013.

BW Boehm, Economía Ingeniería de Software  [6] BW Boehm, Ingeniería de software 

[6]. Ciencias económicas, Prentice-Hall, 1981.

Este libro es la lectura clásica en la economía de ingeniería de [7] C. Ebert y R. Dumke, Software 
software. Proporciona una visión general del pensamiento Medición, Springer, 2007.
empresarial en ingeniería de software. Aunque los ejemplos y
figuras son anticuadas, todavía vale la pena leer. [8] DJ Reifer, Haciendo la Business Software 
Caso: Mejoramiento por los números,
Addison Wesley, 2002.
C. Ebert y R. Dumke, Medición de 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 de un caso

Ness Busi- en el software y las empresas. Muchos ejemplos útiles
ilustran cómo el caso de negocio se formula y se cuantificó.
 CAPÍTULO 13

FUNDAMENTOS DE INFORMATICA

SIGLAS

AOP Programación Orientada a Aspectos ALU SCSI SQL Small Computer System Interface

Unidad Lógica Aritmética y API Estructurada TCP Query Language

Interfaz de programación de Protocolo de control de transporte UDP

aplicaciones Protocolo de datagramas de usuario

Modo de transferencia asíncrono ATM B / S de VPN Red Virtual Privada WAN

Navegador-Servidor Wide Area Network

CERT ordenador de Respuesta a Emergencias

COTS

equipo Commercial Off-The-Shelf CRUD INTRODUCCIÓN

crear, leer, actualizar, eliminar C / S

El alcance de los Fundamentos Informática knowl- área de borde
Cliente-servidor CS
(KA) abarca el desarrollo y el medio ambiente operacional en el
Ciencias de la Computación que evoluciona de software y se ejecuta. Debido a que ningún

Sistema de Gestión de Base de Datos DBMS FPU software puede existir en un vacío o correr sin un ordenador, el
núcleo de un entorno de este tipo es el ordenador y sus diversos
Flotar Point Unidad de E
componentes. El conocimiento acerca de la computadora y sus
/S Entrada y salida de ISA
principios subyacentes de las mercancías de hardware y software
Arquitectura del conjunto de instrucciones sirve como un marco en el que se ancla la ingeniería de software.
Organización Internacional de Por lo tanto, todos los ingenieros de software deben tener una
ISO
Normalización ISP buena comprensión de los ing Fundamentos de Informática KA. En
general se acepta que el software de inge- niería se acumula en la
Proveedor de Servicios de Internet
parte superior de la informática. Por ejemplo, “Ingeniería de
LAN Red de área local
Software 2004: Directrices riculum mentos de Pregrado Programas
multiplexor MUX NIC de Grado en Ingeniería de Software” [1] establece claramente, “Un
Tarjeta de interfaz de red de aspecto particularmente importante es que

Programación
programación orientada a objetosorientada a objetos OS

OSI sistema operativo

PC Interconexión de sistemas abiertos la ingeniería de software se basa en la informática

PDA Personal Computer y matemáticas”(cursiva añadida). Steve Tockey escribió en

PPP Personal Digital Assistant

su libro Retorno de software:

Punto-a-Punto Protocolo RFID

Identificación por Radio Frecuencia RAM Memoria Tanto la informática y el software de inge- niería acuerdo con
de acceso aleatorio ROM memoria de sólo lectura ordenadores, computación y software. La ciencia de la
computación, como un conjunto de conocimientos, está en el
centro de ambos.

13-1
13-2 Guía SWEBOK® V3.0
Figura 13.1. Desglose de los temas de los Fundamentos de Informática KA
... Ingeniería de software se ocupa de la aplicación de las
computadoras, computación y software para propósitos
prácticos, específica- mente el diseño, la construcción y
funciona- miento 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 dis- tribuido, 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 de los temas que
de otra forma estarían cubiertos en un curso de informática no están
cubiertos en este
KA. Por ejemplo, los gráficos de ordenador, 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. El
Fundamentos de Informática 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
esta KA (ver 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 temas para los cimientos Informática KA
se muestra en la figura 13.1.

1. Técnicas de Resolución de Problemas
[2 *, S3.2, c4] [3 *, c5]
La conceptos, nociones y terminología 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 para ayudar a uno formular el problema real
incluyen la declaración-reexpresión, determinar el origen y la
causa, la revisión de la declaración, analizando el estado
actual y el deseado, y utilizando el enfoque del ojo fresco.
Fundamentos de computación 13-3
1.3. Analizar el problema
Una vez que el planteamiento del problema se encuentra disponible, el
siguiente paso es analizar el planteamiento del problema o la situa- ción
para ayudar a estructurar nuestra búsqueda de una solución. Cuatro tipos
de análisis incluyen análisis de la situación,
en el que se identifican primero los aspectos más urgentes o
críticos de una situación; análisis del problema, en el que la causa
del problema debe ser deter- minadas; análisis de decisión, en el
que la acción (s) necesaria para corregir el problema o eliminar su
causa se debe determinar; y análisis problema potencial, en el que
la acción (s) necesario para prevenir la recurrencia de cualquier
problema o el desa- rrollo de nuevos problemas deben ser
determinados.
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 orde- nador a
hacer?
• ¿Cómo podemos convertir el planteamiento del problema en un
algoritmo?
• ¿Cómo podemos convertir el algoritmo en instrucciones de
máquina?
La primera tarea de resolver un problema utilizando una computadora
es determinar qué decirle a la computadora para hacer. Puede haber
muchas maneras de contar la historia, pero todos deben tener la
perspectiva de una computadora tales
13-4 Guía SWEBOK® V3.0
de que el equipo con el tiempo puede resolver el pro- blema. En
general, un problema debe expresarse de tal manera que se facilite
el desarrollo de algoritmos y estructuras de datos para resolverlo. El
resultado de la primera tarea es ment un problema por el estado. El
siguiente paso es 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) El desarrollo de algoritmos de la declaración proble-
Lem.
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 asocia- dos con la
resolución de problemas. Se refiere tanto al proceso y el resultado de la
generalización mediante la reducción de la información de un concepto,
un problema o un fenómeno observable de manera que uno puede
centrarse en el “cuadro grande”. Una de las habilidades más
importantes en cualquier empresa de ingeniería que se enmarca la
niveles de abstracción adecuadamente.
“A través de la abstracción”, según Voland, “vemos el problema
y sus posibles vías de 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,
proble- ma, 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 problema y la solución de
formulación ción, podemos utilizar diferentes abstracciones

en diferentes momentos, en otras palabras, se trabaja en diferentes
niveles de abstracción como la situación lo requiere. La mayoría de las
veces, estos diferentes niveles de abstracción se organizan en una
jerarquía. Hay muchas 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 más inferior capa (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 ejem- plo, 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
[3 *, C6-19]
La programación se compone de las metodologías o actividades para
la creación de programas informáticos que
Fundamentos de computación 13-5
realizar una función deseada. Es una parte indispensable en la
construcción de software. 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. 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. Escritura es la codificación real del diseño en un
lenguaje de programación adecuado. Pruebas
es la actividad para verificar que el código se escribe en realidad hace
lo que se supone que debe hacer. ging de Depuración es la actividad de
encontrar y corregir los bugs (errores) en el código fuente (o diseño). 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 el 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 dife- rentes 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 la programación
estructurada, un programador sigue a su / su
13-6 Guía SWEBOK® V3.0
presentimiento a escribir el código de la manera que él / ella le gusta,
siempre y cuando la función está operativa. A menudo, la práctica es
escribir código para cumplir una utilidad específica sin tener en cuenta
cualquier otra cosa. Los programas escritos de esta manera, no exhiben
estructura- particular, de ahí el nombre de “programación estructurada.”
Programación no estructurada también a veces se llama la
programación ad hoc.
Estructurada / Procedimientos / Imperativo 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 procedi- miento (o función) realizar una
tarea específica. Existen interfaces entre los procedimientos para
facilitar las operaciones de llamada correcta y adecuada de los pro-
gramas. 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 asociado con la programación orientada a objetos, en el
que las interacciones entre los objetos se convierten en muy compleja. La
esencia de AOP es la separación en gran medida enfatizado de
preocupaciones, que separa las preocupaciones funcionales no esenciales
o lógica en varios aspectos.
Programación Funcional: Aunque menos pobla- lar, la
programación funcional es tan viables como los otros paradigmas
de programación en la solución de
problemas. En la programación funcional, todas las computaciones
son tratados como la evaluación de las funciones ematical
Matemáticas-. En contraste con la programación imperativo que
enfatiza los cambios de estado, la programación funcional hace
hincapié en la apli- cación de las funciones, evita los datos del estado
y mutables, y proporciona transparencia referencial.
4. Principios 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 orde- nador. En un
sentido práctico, un len- guaje 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.
4.2. Sintaxis y semántica de lenguajes de programación
Al igual que los lenguajes naturales, muchos lenguajes de
programación tienen alguna forma de especifica- ción por escrito de
su sintaxis (forma) y semántica (Entretanto ing). Tales
especificaciones incluyen, por ejemplo,

requisitos específicos para la definición de Ables variabilidad
y constantes (en otras palabras, declara- ción y tipos) y
requisitos de formato para las mismas instrucciones.
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 se deben traducir en un lenguaje de
máquina mediante un programa de utilidad llama
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 fun- cionamiento 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 tipos de lenguaje es su
estrecha asociación con las características específicas de un tipo de
arquitectura del ordenador Conjunto de instrucciones (ISA).
Fundamentos de computación 13-7
4.4. -Programación y Lenguajes
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 ele- mentos 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 indi-
viduales 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 qué el programa debe lograr sin
describir cómo para 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 Java.
13-8 Guía SWEBOK® V3.0
5. Herramientas de depuración y Técnicas
[3 *, c23]
Una vez que un programa se codifica y se compila (ción compilación
será discutido en la sección 10), el siguiente paso es la depuración,
que es un proceso metódico de encontrar y reducir el número de
errores o fallos en un programa. El propósito de la depuración es
averiguar por qué un programa no funciona o produce un resultado o
salida equivocada. 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 ex- pectativas de usuario. Por ejemplo,
en el lenguaje de programación C / C ++, la función en línea “int f (int x)
{ f retorno ( x- 1);}”para el cálculo de factorial de x! 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 rastreo de la ejecución del programa (damas estáticos
modernos hacen identificar algunos de estos errores. Sin embargo, el
punto es que estos no son verificables máquina en general).
Los errores de datos son los errores de entrada que resultan ya sea en
datos de entrada que es diferente de lo que espera el programa o en el
tratamiento de los datos erróneos.
5.2. Las técnicas de depuración
Depuración implica muchas actividades y puede ser estático, dinámico
o post-mortem. ging debug- estática por lo general toma la forma de
revisión de código, mientras
depuración dinámico por lo general 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 ejecu- tados
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
permitir al programador para controlar la ejecución de un programa,
detener la ejecución, reiniciar la ejecución, establecer puntos de
interrupción, los valores de cambio en la memo- ria, e incluso, en algunos
casos, volver atrás en el tiempo. Para la depuración estática, hay muchos las
herramientas de análisis de código estático, los cuales buscan un conjunto
específico de problemas conocidos dentro del código fuente.

Existen dos herramientas comerciales y gratuitas en varios idiomas.
Estas herramientas pueden ser extremadamente útil para comprobar
muy grandes árboles de origen, donde no es práctico hacer tutoriales
de código. el UNIX
hilas programa es un ejemplo temprano.
6. Estructura de datos y representación
[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 pro- grama. 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
perspectiva de ordenamiento cal física y logi-, una estructura de datos
es ya sea lineal o no lineal. Otras perspectivas dan lugar a dife- rentes
clasificaciones que incluyen homogénea vs. heterogénea, estático vs.
dinámico, persistente vs. transitoria, externo vs. interna, primitivo vs.
agregado, recursiva vs. no recursiva; pasiva vs. activo; y estructuras
con estado vs sin estado.
Fundamentos de computación 13-9
6.2. Tipos de Estructuras de Datos
Como se mencionó anteriormente, diferentes perspectivas se pueden
utilizar para clasificar las estructuras de datos. Sin embargo, la
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: Insertar una nueva entrada de datos en la 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 estructura.
Algunas estructuras de datos también apoyan las operaciones
adicionales:
13-10 Guía SWEBOK® V3.0
• Buscar un elemento en particular en la estructura.
• Ordenar todos los elementos de acuerdo con algún orden.
• Recorrer todos los elementos en un orden específico.
• Reorganizar o reequilibrar la estructura.
Diferentes estructuras de apoyo diferentes opera- ciones 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 ele-
mento 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 opera- ciones 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 existe una definición universalmente
aceptada de Sally, existe cierto acuerdo en que un algoritmo tiene que
ser correcta, finita (en otras palabras, terminan con el tiempo o uno
debe ser capaz de escribir en un número finito de pasos), y sin
ambigüedades.
7.2. Atributos de Algoritmos
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
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 norte.
En análisis caso promedio,
se determina el tiempo de espera o los recursos requeridos por el
algoritmo sobre todas las entradas de tamaño
norte; 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 la análisis mejor de los
casos, en el que se determina el tiempo mínimo o los recursos
requeridos por el algoritmo en cualquier entrada de tamaño norte. 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ásicas, hay también la
están Análisis de amortización, en el que uno de- termina 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).

7.4. Estrategias de diseño algorítmico
El diseño de algoritmos sigue generalmente una de las siguientes
estrategias: la fuerza bruta, divide y vencerás, programación dinámica,
y la selección codiciosos. los estrategia de 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. los divide y
conquistaras estrategia 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. los estrategia de
programación dinámica mejora en el divide y vencerás estrategia por
reconocibles ING que algunos de los sub-problemas producidos por la
división pueden ser iguales 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. los 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
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
análisis de recuento de base, en el que uno realmente cuenta el que hace un sistema. Por ejemplo, las propiedades funcionales de un
número de pasos de un algoritmo tarda en completar su tarea; análisis
avión incluyen la flotación en el aire, llevando a las personas o carga,
asintótico, en el que uno sólo considera el orden de magnitud
del número de pasos de un algoritmo toma para com- pleta su
tarea; análisis probabilístico, en el que se hace uso de las
probabilidades en el análisis del rendimiento promedio de un
algoritmo; amor- análisis Tized, en el que uno utiliza los
métodos de
Fundamentos de computación 13-11
agregación, potencial, y la contabilidad para ana- Lyze el peor
rendimiento de un algoritmo en una secuencia de
operaciones; y Análisis competitivo,
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 sis- tema 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
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 seguridad, etc.
13-12 Guía SWEBOK® V3.0
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
“La ingeniería de sistemas es el enfoque 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 activi- dades 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.
Una computadora es una máquina que ejecuta programas o
software. Se compone de una colección con propósito de
mecánica, eléctrica,
y componentes electrónicos con cada componente realiza una
función de preajuste. Conjuntamente, estos com- ponentes 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 las instrucciones y
almacenar datos, una unidad Central de procesamiento 
para realizar operaciones aritméticas y lógicas, una unidad de control para
la secuenciación y las instrucciones de interpretación, entrada para
obtener informa- ción externa en la memoria, y salida para la
producción de resultados para el usuario. Los componentes básicos
de un sistema de ordenador basado en el modelo de von Neumann se
representan en la figura 13.3.

9. Organización del ordenador
[8 *, c1-c4]
Desde la perspectiva de un ordenador, existe una gran diferencia
semántica entre su intención comporta- miento y el funcionamiento
de los dispositivos electrónicos subyacentes que realmente hacen el
trabajo dentro del equipo. Esta brecha se puentea a través 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, memo- ria, 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). los arquitectura macro nivel es la especificación formal de codificado como 0001, y así sucesivamente. El componente del
todas las funciones de una máquina particular puede llevar a cabo y
que se conoce como la arquitectura del conjunto de instrucciones
(ISA). los arquitectura micro nivel es la actividad mental en práctica de
la Ley de Seguridad en una CPU específica, en otras palabras, la
forma en que las especificaciones del ISA se llevan a cabo realmente.
los circuitos lógicos nivel es el nivel en el que cada componente
funcional de la micro arquitectura se construye de circuitos que toman
decisiones basadas en reglas simples. los
dispositivos nivel es el nivel en el que, 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 así sucesivamente.
Macro Arquitectura Nivel (ISA)
Micro Arquitectura Nivel
Circuitos lógicos Nivel
Nivel dispositivos
Figura 13.4. Niveles arquitectura de la máquina
Cada nivel proporciona una abstracción al nivel superior y es
dependiente en el nivel inferior. Para un programador, el más
importante es la abstracción
Fundamentos de computación 13-13
la ISA, que especifica las cosas tales como los tipos de datos
nativos, instrucciones, registros, modos de direccionamiento, la
arquitectura de memoria, interrumpen y el manejo 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 memo- ria 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
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 lógica digital porque
tiene que ver con 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-14 Guía SWEBOK® V3.0
expresión de datos, un sistema de este tipo se llama una sistema
binario de expresión. Debido a la naturaleza inherente de un sistema
binario, el valor máximo numérico expresable por un código binario de
n bits es 2 norte - 1. Específicamente, número binario un norte un n-1 ... un 1 un 0 corresponde
a un norte × 2 norte + un n-1 × 2 n-1 + ... + un 1 × 2 1 +
un 0 × 2 0. Por lo tanto, el valor numérico de la expresión binaria de una sola digital y el montaje de unidades de un solo dígito en matrices
1011 es 1 × 8 + 0 × 4 + 1 × 2 + 1
× 1 = 11. Expresar un valor no numérico, necesitamos para
decidir el número de ceros y unos de usar y el orden en que
están dispuestos los ceros y unos.
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 instruc- ciones
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
La memoria es la unidad de almacenamiento de un ordenador. It
preocupaciones con- el montaje de un sistema de memoria a gran escala a
partir de unidades más pequeñas y de almacenamiento de un solo dígito.
Los principales temas tratados en la arquitectura de memoria tem sis-
incluyen los siguientes:
• Las células de memoria y chips
• placas y módulos de memoria
• jerarquía de memoria y la memoria caché
• La memoria como un subsistema del equipo.
Las células de memoria y chips tratar con el almacenamiento de
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 preocupación
el 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 de 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; memoria de E / S mapeada trata 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. I programada / O
vamos a la espera de la CPU mientras que el dispositivo de E / S está
haciendo E / S; interrumpir impulsada I / O permite la manipulación de I de
la CPU / O ser accionado por el dispositivo de I / O; y acceso directo a
memoria (DMA) Lets I / O ser manejado por un CPU secundaria incrustado
en un dispositivo DMA (o

canal). (Excepto durante la configuración inicial, la CPU principal
no se altera durante una operación de DMA I / O).
Independientemente de los tipos de esquema de E / S que se utilizan,
las principales cuestiones relacionadas con la E / S incluyen I / O 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 O el trabajo de
E / dispositivo en armonía durante la I / O), y 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  han de ser ignorados en las acciones posteriores, y símbolos
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 imagen ejecutable para ejecutar el programa. La mayoría
del software aplica- ción se vende en esta forma.
Mientras tanto la compilación e interpretación con- vert código de
lenguaje de alto nivel en código máquina,
Fundamentos de computación 13-15
hay algunas diferencias importantes entre los dos métodos. En primer
lugar, un compilador hace que la conver- sión sólo una vez, mientras que
un intérprete normalmente con- verts cada 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 separada comentarios, que
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 len- guaje 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 ajusta a un formato esperado. ¿Es esta una
correcta programa aliado textu- C ++? o Es la entrada tex-
tualmente correcta? son preguntas típicas que pueden ser
13-16 Guía SWEBOK® V3.0
respondida por análisis de sintaxis. análisis sintáctico determina si el
código fuente de un programa es rect cor- y la convierte en una re-
presentación (árbol de análisis sintáctico) más 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 codigo
de GENERACION comienza y transforma el código intermedio
producido en las fases anteriores al idioma nativo de la máquina
de la computadora en cuestió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 proporcio- nar 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. Fundamentos de Sistemas Operativos
[4 *, c3]
Cada sistema de complejidad significativa debe ser gestionado. Un
ordenador, como un sistema eléctrico-mecánicos más bien
compleja, necesita su propio hombre-ager para la gestión de los
recursos y actividades que tienen lugar en él. Eso se llama un
gerente sistema operativo ( OS).
11.1. Operativo general Sistemas
sistemas operativos es una colección de software y firmware, que
controla la ejecución de programas de ordenador y proporciona
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. administració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. Espejismo se
refiere a las buenas abstracciones del sistema operativo proporciona.
11.2. Las 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. En concreto, 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 / usuarios y su
abstracción principal es el sistema de archivos. Yo dispositivo de E / S
manage- ofertas de unificación con la asignación y liberación de varios
dispositivos de E / S entre los procesos que compiten.

Seguridad y protección de acuerdo con la protección de los recursos
informáticos de uso ilegal.
11.3. Las abstracciones del sistema operativo
El arsenal de sistemas operativos es la abstracción. Correspondiente a
las cinco tareas físicas, sistemas operativos utilizan cinco abstracciones:
proceso / hilo, memoria virtual, siste- mas 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 relativa- mente 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 puede ser clasificado como uno de los
siguientes.
• OS procesamiento por lotes: organiza y procesos de trabajo en
lotes. Ejemplos de tales sistemas operativos incluyen FMS de
IBM, IBSYS, y Universidad de UMES de Michigan.
Fundamentos de computación 13-17
• Multiprogramado OS procesamiento por lotes: añade la capacidad de
multi- titask en principios simples de procesamiento por lotes
sistemas operativos. Un ejemplo de un sistema operativo como es
de IBM OS / 360.
• Tiempo compartido OS: agrega multi-tarea y las capacidades
activas inter en el sistema operativo. Ejemplos de tales 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. Conceptos básicos de bases de datos y gestión de datos
[4 *, c9]
Una base de datos se compone de una colección organizada de datos
para uno o más usos. En un sentido, una base de datos es una
generalización y expansión de estructuras de datos. Pero la diferencia es
que una base de datos suele ser externa a programas individuales y
permanente en existencia en comparación con las estructuras de datos.
Las bases de datos se utilizan cuando el volumen de datos es grande o
lógico
13-18 Guía SWEBOK® V3.0
las relaciones entre los elementos de datos son importantes. Los factores
considerados en el diseño de la base de datos incluyen Formance per-,
concurrencia, la integridad, y la recuperación de fallos de hardware.
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 la 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 la
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 almace- namiento 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,
manteni- miento, 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
base de datos relacional (RDBMS) implementa las distintas prestaciones
del modelo relacional. Un sistema de gestión de base de datos de objeto
(ODBMS) implementa las distintas prestaciones del modelo de objetos.
12.3. Lenguaje de consulta de base de datos
Usuarios / aplicaciones interactúan con una base de datos a través de un
lenguaje de consulta de base de datos, que es un lenguaje 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 de 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 aplicación escrita a máquina proto.
También se refiere al uso de cuarto de idioma o aplicación de
generación de erators generaciones para desarrollar o generar
código de programa.

12.5. Gestión de datos
Una base de datos debe gestionar los datos almacenados en ella. Esta
gestión incluye tanto la organización y almacenamiento.
La organización de los datos reales en una base de datos depende del
modelo de base de datos. En un modelo relacional, los datos se 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 aprovechar al máximo de una base de datos, se puede realizar el
análisis estadístico y el patrón de dis- covery sobre el contenido de una
base de datos utilizando una téc- nica llama minería de datos. 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. Red de Comunicación Conceptos básicos [ 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
comunicaciones entre todos los ordenadores conectados y
puede dar la ilusión de un único equipo, omnipresente. Cada
dispositivo puter o com- conectado a una red se denomina nodo
de red.
Una serie de paradigmas de computación han surgido para
beneficiarse de las funciones y capacidades
Fundamentos de computación 13-19
proporcionada por las redes de ordenadores. Estos paradigmas
incluyen computación distribuida, grid computing, computación
Internet, y la nube.
13.1. Tipos de 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
per- sona. 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 componentes básicos hard-
ware, incluyendo las computadoras, la red
13-20 Guía SWEBOK® V3.0
tarjetas de interfaz (NIC), puentes, concentradores, conmutadores y
routers. Todos estos componentes se denominan nodos
en la jerga de las redes. Cada componente per- forma una
función distintiva que es esencial para el 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 del modelo de
redes de siete capas interconexión de sistemas abiertos (OSI),
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 la capa de red IP, pro Viding de mejor
esfuerzo, el transporte no fiable (UDP) vs. función de transporte
confiable (TCP). protocolos de capa física incluyen token ring,
Ethernet, Fast Ethernet, Gigabit Ethernet, y Ethernet inalámbrico.
Datos
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 desa- rrollo de los
protocolos correspondientes.
Aplicación Capa de
presentación Capa de
enlace de capa de sesión
Capa de transporte Capa
de Red de datos de capa
de la capa física
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 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 de amplia difusión.

13.6. Red Privada Virtual (VPN)  Fundamentalmente, la informática distribuida es otra forma de
Una red privada virtual es una conexión virtual planificada de
antemano entre los nodos de una 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. Paralelo y Distributed Computing [ 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 desa- rrollo 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 posi- ble 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
computación distribuida de sistemas distribuidos, que consta de
múltiples
autónomo ordenadores que se comunican a través de una red
informática. 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 computación distribuida
estudia las formas de dividir un problema en muchas tareas y la
asignación de estas tareas a varios equipos implicados en el
cálculo.
Fundamentos de computación 13-21
computación en paralelo, aunque en una escala más grande. En
computación distribuida, las unidades funcio- 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 distri- buido 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 distri-
buido
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 distribuida / paralelo, una cierta coordinación entre las
partes involucradas es nece- Essary para garantizar un comportamiento
correcto del sistema.
13-22 Guía SWEBOK® V3.0
Las diferentes formas de coordinación dan lugar a diferencias ent
modelos de computación. Los els MOD- más comunes a este respecto
son el modelo de memoria compartida (lel paralelismos) y el modelo de
paso de mensajes (distribuido). En un memoria compartida (paralelo) modelo,
El software se desarrolla para satisfacer deseos o necesidades
todos los com- putadoras tienen acceso a una memoria central
compartida donde 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 de paso de mensajes (distribuido) modelo, todos los ordenadores
ejecutar 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
denominan
middleware, que es un tema 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 memoria y
el consenso entre todos los equipos son los más ficult rencias.
Muchos paradigmas de computación se han inventado para resolver
estos problemas y son los principales puntos de discusión en la
computación distribuida / paralela.
15. Factores Humanos de usuario básica [ 3 *, c8] [9 *, c5]
humanas. Por lo tanto, todo el diseño de software y desa- rrollo 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 la manera más conveniente para los usuarios entrar en la
entrada?
• ¿Qué formato requiere la computadora 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 desean
ver:
• ¿En qué formato se desea ver los usuarios de salida?
• ¿Cuál es la manera más agradable para mostrar la salida?

Si la parte que interactúa con el software no es humana sino otro
software o equipo o sistema de con- trol, entonces tenemos que
considerar el tipo de entrada / salida y el formato que el 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 soft- ware. 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 con- tiene 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 con- diciones 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.
Sin embargo, los mensajes relacionados con errores de acceso de
seguridad no deben proporcionar información adicional que ayude a las
personas no autorizadas minan.
Fundamentos de computación 13-23
15.3. La robustez del software
robustez del software se refiere a la capacidad de soft- ware 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. Developer básico 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 son importantes estructura
( o diseños de programas) y (comentarios documentación).
13-24 Guía SWEBOK® V3.0
16.1. Estructura  • Dentro de una función, los comentarios se deben dar por
programas bien estructurados son más fáciles de entender y modificar. Si
un programa no está bien estructurado, entonces ninguna cantidad de
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 posi- blemente 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:
• Los comentarios deben ser coherentes en todo el
programa.
• Cada función debe estar asociado con los comentarios
que explican el propósito de la función y su papel en el
programa general.
cada sección lógica de 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
indi- viduales. Si necesita una declaración comen- tarios, 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, software la
seguridad del diseño, la seguridad de construcción de software, y las
pruebas de software seguri- dad. 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 política y objetivos de seguridad en los
requisitos de software, los cuales

sienta las bases para consideraciones de seguridad en el desarrollo
de software. Los factores a considerar en esta fase incluyen los
requisitos de software y amenazas / riesgos. El primero se refiere a
las funciones específicas que se requieren para el bien de seguri-
dad; Este último se refiere a las posibles formas en que se ve
amenazada la seguridad del software.
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
la seguridad de construcción de software 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
construcción de software de seguridad en su estado actual de refiere
existencia-principalmente con el segundo aspecto mencionado
anteriormente: la codificación de seguridad en el software.
La codificación de la seguridad en el software se puede lograr
siguiendo las normas recomendadas. Unos dichas reglas a continuación:
Fundamentos de computación 13-25
• Estructurar el proceso para que todas las secciones que
requieren privilegios adicionales son módulos. Los módulos
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, docu- mento 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 soft- ware
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 pro- ceso
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 el desarrollo de software
seguro, existen algunas pautas generales que se pueden utilizar para
ayudar a tales esfuerzos. Estas
13-26 Guía SWEBOK® V3.0

directrices abarcan todas las fases del ciclo de vida de desarrollo de 1. Entrada de Validar.

software. Algunas líneas directrices de buena reputación son publicados 2. Haga caso de las advertencias del compilador.

por el Equipo de Respuesta a Emergencias Informáticas (CERT) y por 3. El arquitecto y el diseño de las políticas de seguridad.

debajo son las 10 mejores prácticas de seguridad de software (los detalles 4. Debe ser sencillo.
se pueden encontrar en [12]: 5. denegación predeterminada.

6. Respetar el principio de privilegios mínimos.

7. Los datos Desinfectar enviados a otro software.

8. defensa práctica en profundidad.

9. Utilizar técnicas de garantía de calidad eficaz.

10. Adoptar un estándar de seguridad de construcción de software.
 Fundamentos de computación 13-27

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
1. Técnicas de Resolución S3.2,
de Problemas S4.2

1.1. Definición de la
S3.2
resolución de problemas

1.2. Formular el
S3.2
problema real
1.3. Analizar el
S3.2
problema

1.4. Diseñar una

estrategia de búsqueda S4.2

de soluciones

1.5. La resolución de
c5
problemas Utilización de programas

s5.2-
2. Abstracción
5.4

2.1. Los niveles de s5.2-

abstracción 5.3

2.2. La encapsulación S5.3

2.3. Jerarquía S5.2

3. Fundamentos de
C6-19
programación

3.1. El proceso de
programación C6-C19

3.2. Los paradigmas de

C6-C19
programación

3.3. La programación
c8
defensiva

4. Principios básicos del

c6
lenguaje de programación

4.1. Lenguaje de
S6.1
Programación general

4.2. Sintaxis y
semántica del
S6.2
lenguaje de
programación
13-28 Guía SWEBOK® V3.0

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
4.3. Bajo nivel de
s6.5-
lenguaje de
6.7
programación

4.4. Alto Nivel de

s6.5-
Programación
6.7
Lenguaje

4.5. frente a
declarativa lenguaje s6.5-
de programación 6.7
imperativo

5. Herramientas de
c23
depuración y Técnicas

5.1. Tipos de error s23.1

5.2. Las técnicas de

s23.2
depuración:

5.3. Herramientas de
s23.5
depuración

6. Estructura de datos y s2.1-

representación 2.6

6.1. Presentación de la s2.1-

estructura de datos 2.6

6.2. Tipos de Estructuras s2.1-

de Datos 2.6

6.3. Las operaciones en s2.1-

Estructuras de Datos 2.6

s1.1-
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
 Fundamentos de computación 13-29

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
7.1. Descripción general
s1.1-1.2
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 de 5,7,
diseño algorítmico s6.1-
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 algorítmico s6.1-
6.3,
s7.1-
7,6,
s11.1,
S12.1

8. Concepto básico de un
c10
sistema de

8.1. Propiedades del

s10.1
sistema emergente

8.2. Ingeniería de
s10.2
sistemas

8.3. Visión general de un

sistema informático
13-30 Guía SWEBOK® V3.0

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
9. Organización del
C1-4
ordenador

9.1. Organización
general del s1.1-1.2
ordenador

9.2. Sistemas digitales c3

9.3. lógica digital c3

9.4. Expresión de datos del

c2
ordenador

9.5. La Unidad Central

s4.1-
de Procesamiento
4.2
(CPU)

9.6. Organización del Sistema

S4.6
de memoria

9.7. Entrada y salida (I / O)

S4.5

10. Fundamentos del compilador s6.4 S8.4

10.1. compilador
S8.4
general

10.2. Interpretación y
S8.4
compilación
10.3. los
s6.4 S8.4
Proceso de compilación

11. Fundamentos de
c3
Sistemas Operativos

11.1. Operativo general

S3.2
Sistemas

11.2. Tareas del Sistema

S3.3
Operativo

11.3. Las abstracciones del

S3.2
sistema operativo

11.4. Sistemas para

realizar la clasificación S3.1
 Fundamentos de computación 13-31

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
12. Conceptos básicos

de bases de datos y C9
gestión de datos

12.1. Entidad y de
S9.1
esquema

12.2. Sistemas de Gestión

de Bases de Datos S9.1

(DBMS)

12.3. Lenguaje de
S9.2
consulta de base de datos

12.4. Tareas de
S9.2
paquetes de DBMS

12.5. Gestión
s9.5
de datos

12.6. La minería de datos s9.6

13. Conexión de red

básica de comunicación c12

13.1. Tipos de s12.2-

Red 12.3

13.2. Componentes de la
S12.6
Red Básica

13.3. Protocolos de
s12.4-
red y Estándares
12.5

13.4. La Internet
13.5. Internet de las
s12.8
Cosas

13.6. Red Privada

Virtual
14. Computación
Paralela y C9
Distribuida

14.1. Computación
paralela y s9.4.1-
distribuida general 9.4.3
13-32 Guía SWEBOK® V3.0

Horowitz et al. 2007

Nula y Lobur 2006

Sommerville 2011
Brookshear 2008
McConnell 2004

Nielsen 1993
Voland 2003

Bishop 2002
[11 *]
[8 *]

[9 *]
[5 *]
[3 *]
[2 *]

[4 *]

[6 *]
14.2. Las diferencias
entre Computación s9.4.4-
Paralela y Distribuida 9.4.5

14.3. Modelos de
s9.4.4-
Computación Paralela y
9.4.5
Distribuida

14.4. Problemas

principales en Distributed

Computing

15. Los factores

c8 c5
humanos básicos de los usuarios

15.1. Entrada y S5.1,

salida S5.3

S5.2,
15.2. Error de mensajes
s5.8

15.3. La robustez del s5.5-

software 5.6

16. Developer básico

c31-32
Factores Humanos

16.1. Estructura c31

16.2. comentarios c32

17. asegurar el desarrollo y

mantenimiento de software c29

17.1. Dos aspectos de

s29.1
codificación segura

17.2. Codificación

de Seguridad en s29.4
Software

17.3. Seguridad
s29.2
requisito
17.4. Seguridad
s29.3
diseño

17.5. Seguridad
s29.5
implementación

Referencias
[1] Grupo de Trabajo Conjunto sobre Computación planes de estudio,
IEEE Computer Society y la Association for Computing
Machinery, Ingeniería de Software 2004: Directrices
Curriculares para Pregrado Programas de Grado en
Ingeniería de Software, 2004; http: // sites.
computer.org/ccse/SE2004Volume.pdf .
[2 *] G. Voland, Ingeniería de Diseño, 2ª ed.,
Prentice Hall, 2003.
[3 *] S. McConnell, Código completo, 2ª ed.,
Microsoft Press, 2004.
[4 *] JG Brookshear, Ciencias de la Computación: Un 
Visión de conjunto, 10ª ed., Addison-Wesley, 2008.
[5 *] E. Horowitz et al., Los algoritmos de ordenador,
2ª ed., Silicon Press, 2007.
[6 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
Fundamentos de computación 13-33
[7] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
[8 *] L. Null y J. Lobur, Lo Esencial de la 
Organización ordenador y Arquitectura,
2ª ed., Jones and Bartlett Publishers,
2006.
[9 *] J. Nielsen, Ingeniería de la Usabilidad, Morgan
Kaufmann, 1993.
[10] ISO 9241 a 420: 2011 ergonomía de Human-
La interacción del sistema, la norma ISO 2011.
[11 *] M. Bishop, Seguridad informática: Arte y 
Ciencia, Addison-Wesley, 2002.
[12] RC Seacord, La codificación Secure CERT C 
Estándar, Addison-Wesley Professional,
2008.
 CAPÍTULO 14
Fundamentos matemáticos
INTRODUCCIÓN
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. los Guía SWEBOK 'S
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 siguien-
tes 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 ematical Matemáticas- para deducir
de forma concluyente la verdad absoluta de ciertos conceptos más
allá de los números. En
14-1
resumen, se puede escribir un programa para un problema sólo
si se sigue una cierta lógica. El objetivo de este KA es ayudar a
desarrollar la habilidad de identificar y describir tal lógica. El
énfasis está en ayudar a entender los conceptos básicos más
que en desafiar sus habilidades aritméticas.
DISTRIBUCIÓN DE TEMAS PARA
fundamentos matemáticos
El desglose de temas para los fundamentos matemáticos KA
se muestra en la figura 14.1.
1. Establecer, relaciones, funciones
[1 *, c2]
Conjunto. Un conjunto es una colección de objetos, llamado elementos del
conjunto. Un conjunto puede ser representado por listar sus elementos
entre aparatos ortopédicos, por ejemplo, S = {1, 2, 3}. El símbolo ∈ se usa
para expresar que un ele- mento pertenece a un conjunto, o, en otras
palabras-es un miembro del conjunto. Su negación está representado por
∉, por ejemplo, 1 ∈ S, pero 4 ∉ S.
En una representación más compacta del conjunto usando la notación
establecer constructor, {x | P (x)} es el conjunto de todos los x tales que P
(x) para cualquier proposición P (x) sobre cualquier universo de discurso.
Ejemplos de algunos conjuntos impor- tantes incluyen los siguientes:
N = {0, 1, 2, 3, ...} = el conjunto de enteros no negativos.
Z = {..., -3, -2, -1, 0, 1, 2, 3, ...} = el conjunto de enteros.
Conjunto finito e infinito. Un conjunto con un nú- mero finito de
elementos se denomina un conjunto finito. Por el contrario, cualquier
conjunto que no tiene un número finito de ele- mentos en que es una conjunto
infinito. El conjunto de los números naturales, por ejemplo, es un conjunto
infinito.
14-2 Guía SWEBOK® V3.0

Figura 14.1. Desglose de los temas de los fundamentos matemáticos KA

Cardinalidad. La cardinalidad de un conjunto finito S es el número de Conjunto vacio. Un conjunto sin elementos se llama una
elementos en S. Esto se representa | S |, por ejemplo, si S = {1, 2, 3}, conjunto vacio. Un conjunto vacío, denotado por ∅, También se conoce
entonces | S | = 3. como un conjunto nula o ineficaz.

Conjunto universal. En S general = {x ∈ T | p (x)}, donde T es el Set de poder. El conjunto de todos los subconjuntos de un conjunto X se
universo de discurso en el que debe interpretarse el predicado P (x). El llama set de poder de X. Se representa como

“verso uniforme del discurso” de un predicado dado se refiere a ℘ ( X).

menudo como el conjunto universal. Alternativamente, se puede definir
un 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).
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) | = 2 norte.
Diagramas de Venn. Los diagramas de Venn son resentations tantes
gráficas de conjuntos como áreas cerradas en el plano. Por ejemplo, en
la figura 14.2, el rectángulo representa el conjunto universal y la región
sombreada representa un conjunto X.

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.

Subconjunto propio. 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 = Figura 14.2. Diagrama de Venn para el conjunto X

{1, 2, 3, 4}, y Z = {1, 2, 3}, entonces X ⊂ Y, pero X no es un

subconjunto propio de Z. Establece X y Z son conjuntos iguales. Si
X no es un subconjunto propio de Y, que se denota como X ⊄ Y. 1.1. las operaciones Set

Intersección. La intersección de dos conjuntos X y

Y, denotado por X ∩ Y, es el conjunto de ele- mentos comunes tanto
en X y Y. En otras palabras, X ∩ Y = {p | (pag ∈ X) ∧ ( pag ∈ Y)}. Como,
Superconjunto. Si X es un subconjunto de Y, entonces Y se denomina superconjunto
de X. Esto se denota por Y ⊇ X, es decir, Y por ejemplo, {1, 2, 3} ∩ { 3, 4, 6} = {3} Si X ∩ Y = f, entonces los dos
⊇ X si y sólo si X ⊆ Y. conjuntos X e Y se dice que es un par disjunta de conjuntos.
Por ejemplo, si X = {1, 2, 3} y Y = {1, 2, 3,
4, 5}, entonces Y ⊇ X.

Un diagrama de Venn para intersección de conjuntos se muestra en la
figura 14.3. La parte común de los dos conjuntos representa la intersección
de conjuntos.
Figura 14.3. Intersección de conjuntos X e Y
Unión. La unión de dos conjuntos X e Y, 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 | (pag ∈ X) ∨ ( pag ∈ Y)}. Como, por
ejemplo, {1, 2, 3} ∪ { 3, 4, 6} = {1, 2,
3, 4, 6}.
Figura 14.4. Unión de conjuntos X e Y
Cabe señalar que | X ∪ Y | = | X | + | Y | - | X
∩ Y |.
Un diagrama de Venn que ilustra la unión de dos conjuntos se
representa por la región sombreada en la figura
14.4.
Complemento. El conjunto de elementos en el conjunto uni- versal que
no pertenecen a un conjunto dado X se llama su conjunto complemento
X'. En otras palabras, X'= {p | (pag ∈ T) ∧ ( pag ∉ X)}.
Figura 14.5. Diagrama de Venn para el complemento Conjunto de X
Fundamentos matemáticos 14-3
La parte sombreada del diagrama de Venn en Fig- ure 14.5
representa el complemento conjunto de X.
Establecer diferencia o complemento relativa. El conjunto de
elementos que pertenecen al conjunto X, pero no para establecer Y
construye la diferencia de conjuntos de Y de X. Esto es repre- sentadas
por X - Y. En otras palabras, X - Y = {p | (pag ∈ X) ∧ ( pag ∉ Y)}. Como,
por ejemplo, {1, 2, 3} - {3, 4, 6} = {1, 2}. Puede probarse que X - Y = X ∩ Y'.
Conjunto diferencia X - Y se ilustra por la región sombreada en la figura
14.6 el uso de un diagrama de Venn.
Figura 14.6. Diagrama de Venn para X - Y
Producto cartesiano. Un par ordinario {p, q} es un conjunto con
dos elementos. En un conjunto, el orden de los elementos es
irrelevante, por lo que {p, q} = {q, p}. En un par ordenado (p, q), el
orden de ocurrencias de los elementos es relevante. Por lo tanto, (p,
q) ≠ (q, p) a menos que p = q. En general (p, q) = (s, t) si y sólo si p
= s y q = t.
Dados dos conjuntos X e Y, su producto cartesiano X × Y es el
conjunto de todos los pares ordenados (p, q) tal que p ∈ X y q ∈ Y.
En otras palabras, X × Y = {(p, q) | (pag ∈ 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.
1. Leyes asociativas: X ∪ ( Y ∪ Z) =
(X ∪ Y) ∪ ZX ∩ ( Y ∩ Z) = (X ∩ Y) ∩ Z
14-4 Guía SWEBOK® V3.0

2. La ley conmutativa: X ∪ Y esto se convierte en una relación de buen comportamiento y por lo tanto

=Y∪x x∩Y=Y∩x 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

3. La ley de distribución: X ∪ ( Y ∩ Z) = (X ∪ Y) ∩ dada una x, se obtiene uno y exactamente uno y para cada par ordenado ( x,

( x ∪ Z) X ∩ ( Y ∪ Z) = (X ∩ Y) ∪ ( x ∩ Z) y).
Por ejemplo, consideremos las dos relaciones siguientes.

4. La ley de identidad: X ∪ ∅ = XX ∩ U
=X
5. La ley del complemento: X ∪ X'=
UX ∩ = X' ∅
6. Leyes Idempotent: X ∪ X = XX ∩
X=X
7. Leyes Bound: X ∪ U = UX ∩ ∅ =
∅
8. Leyes absorción: X ∪
( x ∩ Y) = X
9. De Leyes de Morgan: (X ∪
Y) '= X' ∩ Y'
1.3. Relación y función
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 todos los valores de y, 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}.
x ∩ ( x ∪ Y) = X 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
(X ∩ Y) '= X' ∪ Y' 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:

Una relación es una asociación entre dos conjuntos de información. Por Dada la gráfica de una relación, si se puede dibujar una línea
ejemplo, consideremos un conjunto de residentes de una ciudad y sus vertical que atraviesa el gráfico en más de un lugar, entonces la
números de teléfono. El emparejamiento de los nombres con números de relación no es una función. 
teléfono correspondientes es una relación. Este emparejamiento es ordenado 
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 se llama el primer elemento conjunto
de dominio y el otro conjunto se llama el margen establecido. El dominio
es lo que empezar y es el rango de lo que se termina con. Una función
es una de buenos ademanes relación. 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 Figura 14.7. Prueba de la recta vertical para la Función

persona puede tener más de un número de teléfono, la relación que se

considera que no es una función. Sin embargo, si dibujamos una relación En este ejemplo, las dos líneas L1 y L2 cortan el gráfico para la
entre los nombres de los residentes y su fecha de nacimiento con el relación tres veces. Esto significa que para el mismo valor de x, hay
nombre establecido como dominio, tres valores de y diferentes para cada uno de caso. Por lo tanto, la
relación no es una función.

2. Lógica Básica
[1 *, c1]
2.1. Lógica proposicional
Una proposición es una afirmación que es 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: cierto
o falso. Algunos ejemplos de proposiciones se dan a continuación.
1. El sol es una estrella
2. 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 un y segundo.
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 las
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), y la 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 pag ∨ F ≡ p
leyes de dominación: p ∨ T
T≡ pag ∧ F ≡ F
Fundamentos matemáticos 14-5
leyes Idempotent: p ∨ p
≡p pag ∧ p ≡ p
Ley doble negación: ¬ (¬
p) ≡ p
conmutativa: p ∨ q ≡ q ∨ páginas ∧ q ≡
q ∧ pag
leyes asociativas: (p ∨ q) ∨ r ≡ p ∨
( q ∨ r) (p ∧ q) ∧ r ≡ p ∧ ( q ∧ r)
leyes distributivas: p ∨ ( q ∧ r) ≡ (p ∨ q) ∧ ( pag
∨ r) p ∧ ( q ∨ r) ≡ (p ∧ q) ∨ ( pag ∧ 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 frase, La flor es de color rojo, la plantilla es
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
rojo. Suponiendo R como el nombre de la predi- cado es rojo, frases
que afirman es un objeto del color rojo se puede representar como R
(x), dónde x repre- senta un objeto arbitrario. R (x) dice lo x es de color
rojo.
Cuantificadores permiten afirmaciones sobre Lections COL- enteros
de objetos en lugar de tener que enumer- comieron los objetos por su
nombre. El cuantificador universal ∀ x afirma que una sen- tencia 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.
14-6 Guía SWEBOK® V3.0
Una variable x que se introduce en una expresión lógica por un
cuantificador está unido al cuantificador de encerramiento más cercano.
Una variable se dice que es una variable libre si no está unido a un
cuantificador.
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 cuantificado. 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 a es mayor que 1 No es una
proposición porque no se puede inferir si es verdadero o falso sin
saber 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 implicado en los
siguientes dos Lences equivalencias lógicas no puede ser
capturado por la lógica de proposiciones: “ No todos los hombres
son fumadores ”Y“ Algunos hombres no fuman. ”Cada uno de estos
dos proposiciones se trata de forma independiente en la lógica de
proposiciones. 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
[1 *, c1]
Una prueba de ello es un argumento que establece rigurosamente la
verdad de un enunciado. Las pruebas pueden estar a su vez
representadas formalmente como estructuras discretas.
Declaraciones utilizados en una prueba incluyen axiomas y
postulados que son esencialmente los supuestos subyacentes
sobre estructuras matemáticas, las hipótesis del 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 estable- cido
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 esta- blecer 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 impar, entonces n 2 -1
es par, supongamos que n es impar, es decir, n = 2k + 1 para algún entero
k:
∴ norte 2 = ( 2k + 1) 2 = 4k 2 + 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, el lado
izquierdo (LHS) (es decir, n 2) es un número impar. Por lo tanto, n 2 -1 es aún.
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.
Demostración por inducción. Demostración por inducción se realiza en
dos fases. En primer lugar, la proposición se estable- cido para ser verdad
para una base de caso-típicamente para la

entero positivo 1. En la segunda fase, se ció esta- que si la proposición
es válida para un número entero positivo arbitrario k, entonces también
debe mantener para el siguiente mayor número entero, k + 1. En otras
palabras, demostración por inducción se basa en la regla de inferencia
que nos dice que la verdad de una secuencia infinita de proposiciones P
(n), ∀ norte ∈ [ 1 ... ∞] se establece si P (1) es verdadero, y en segundo
lugar, ∀ k ∈ [ 2 ... n] si P (k)
→ P (k + 1).
Cabe señalar aquí que, para una demostración por inducción
ematical Matemáticas-, no se supone que P (k) es verdadera para
todos los números enteros positivos k. Probar una rem teo o
proposición sólo nos requiere para establecer que si se supone P (k) es
cierto para cualquier arbitraria entero positivo k, entonces P (k + 1)
también es cierto. La corrección de la inducción matemática como una
técnica de prueba válida está más allá de la discusión del texto Cur-
alquiler. Probemos el siguiente proposición mediante inducción.
Proposición: La suma de la primera positivo n enteros impares P (n) es
n 2.
Paso base: La proposición es verdadera para n = 1 como P (1) = 1 2
= 1. El paso de base es completa. Paso inductivo: la hipótesis de
inducción (IH) es que la proposición es verdadera para n = k, siendo k
un número entero arbitrario k positivo.
∴ 1 + 3 + 5 + ... + (2k - 1) = k 2
Ahora, es necesario demostrar que P (k) → P (k + 1).
P (k + 1) = 1 + 3 + 5 + ... + (2k - 1) + (2k + 1) = P (k) +
(2k + 1) = k 2 + ( 2k + 1) [usando IH] = k 2 + 2k + 1 = (k + 1) 2
Por lo tanto, se muestra que si la proposición es cierto para n = k,
entonces también es cierto para n = k + 1. La etapa de base junto con el
paso inductivo de la muestra prueba de que P (1) es verdadera y el
condicional declaración P (k) → P (k + 1) es verdadera para todos los
números enteros positivos k. Por lo tanto, la proposición se prueba.
4. Fundamentos de Conteo
[1 * c6]
La regla de la suma indica que si una tarea t 1 se puede hacer en n 1 maneras conjuntos no se cuentan más de una vez.
y una segunda tarea t 2 se puede hacer de
Fundamentos matemáticos 14-7
norte 2 maneras, y cuando estas actividades no se pueden hacer al mismo
tiempo, entonces hay n 1+ norte 2 maneras de hacer bien la tarea.
• Si A y B son conjuntos disjuntos, entonces | A ∪ B | = | A |
+ | B |.
• En general, si A1, A2, .... , An son conjuntos disjuntos,
entonces | A1 ∪ A2 ∪ ... ∪ un | = | A1 | + | A2 |
+ ... + | An |.
Por ejemplo, si hay 200 atletas que realizan pruebas de
velocidad y 30 atletas que participan en el evento de salto de
longitud, entonces cuántas formas hay que elegir un atleta que
es o bien un velocista o un largo puente?
Usando la regla de la suma, la respuesta sería 200
+ 30 = 230.
La regla del producto establece que si una tarea t 1 se puede hacer en n 1 maneras
y una segunda tarea t 2 se puede hacer en n 2 maneras después de que la
primera tarea se ha hecho, entonces hay n 1 * norte 2 maneras de hacer el
procedimiento.
• Si A y B son conjuntos disjuntos, entonces | A × B | = | A | * | B |.
• En general, si A1, A2, ..., An son conjuntos disjuntos, entonces |
A1 A2 × × × ... Un | = | A1 | * | A2 | * ....
* | An |.
Por ejemplo, si hay 200 atletas que realizan pruebas de velocidad y
30 atletas que participan en el evento de salto de longitud, entonces
¿Cuántas maneras hay para recoger dos atletas por lo que uno es un
velocista y el otro es un saltador de longitud? Usando la regla del
producto, la respuesta sería de 200 x 30 = 6000. El principio de
inclusión-exclusión establece que si una tarea t 1 se puede hacer en n 1 maneras
y una segunda tarea t 2 se puede hacer en n 2 maneras al mismo tiempo
con t 1, a continuación, para encontrar el número total de maneras las
dos tareas se puede hacer, restar el número de maneras de hacer las
dos tareas de n 1 + norte 2.
• Si A y B no son disjuntos, | A ∪ B | = | A | + | B | - | A ∩ B
|.
En otras palabras, el principio de inclusión-exclusión tiene por
objeto asegurar que los objetos en la intersección de dos
14-8 Guía SWEBOK® V3.0

recursividad es el término general para la práctica de la definición 5. Los gráficos y los árboles

de un objeto en términos de sí mismo. Hay algoritmos recursivos, fun- [1 *, c10, c11]

ciones definidas recursivamente, relaciones, juegos, etc.
5.1. Los gráficos 
Una función recursiva es una función que llama a sí mismo.
Por ejemplo, definimos f (n) = 3 * f (n - 1) para todo n ∈ N y n ≠ 0 Un gráfico G = (V, E) donde V es el conjunto de vértices (nodos) y E es el
y f (0) = 5. conjunto de bordes. Los bordes también se conocen como arcos o
Un algoritmo es recursivo si se soluciona un problema reduciéndolo a enlaces.
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 satisface un 0 ≤ P (A) ≤

1. Cualquier probabilidad es un número entre 0 y 1. Si S es el espacio
de la muestra en un modelo de probabilidad, el P (S) = 1 . Todos los
posibles resultados juntos deben tener probabilidad de 1.
Figura 14.8. Ejemplo de un gráfico

Dos sucesos A y B son disjuntos si no tienen resultados en

común y por lo tanto nunca pueden ocurrir juntos. Si A y B son dos
sucesos disjuntos, P (A o B) = P (A) + P (B). Esto se conoce como
la regla ción adiciones para eventos disjuntos.
Si dos eventos no tienen resultados en común, la probabilidad
de que uno u otro se produce es la suma de sus probabilidades
individuales.
Permutación es un arreglo de objetos en los que el orden es
importante, sin repetición. Uno puede elegir r objetos en un orden
particular de un total de n objetos mediante el uso de norte PAG r maneras,
en donde, norte pag r =
¡norte! / (N - r) !. Varios notaciones como norte PAG r y P (n, r) se utiliza para
representar el número de permutaciones de un conjunto de n objetos
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 combinación. Uno
puede elegir r objetos en cualquier orden de un total de n objetos
mediante el uso de norte do r maneras, en donde,
F es una función que mapea el conjunto de aristas E a un
conjunto de pares ordenados o no ordenados de elementos de V. Por
ejemplo, en la figura 14.8, G = (V, E), donde V = {A, B, C}, E = {e1,
e2, e3}, y F = {(e1, (A,
C)), (e2, (C, B)), (e3, (B, A))}. El gráfico de la figura 14.8 es un gráfico
simple que consiste en un conjunto de vértices o nodos y un conjunto
de aristas que conectan pares no ordenadas. Los bordes en gráficos
simples no son dirigidas. Tales gráficos también se denominan
gráficos como no dirigidos.
Por ejemplo, en la figura 14.8, (e1, (A, C)) puede sustituirse
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.

do r = ¡norte! / [R! * (N - r)]!.

norte
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.

Figura 14.9. Ejemplo de un Multigraph
En un pseudógrafo, se permiten bordes de conexión de un nodo a sí
mismo. Tales bordes son llamados bucles.
Figura 14.10. Ejemplo de un pseudógrafo
Por ejemplo, en la figura 14.10, el borde E4 ambos comienza y
termina en B. Figura 14.10 es un gráfico en el que pseudo- e4 es un
bucle.
Figura 14.11. Ejemplo de un grafo dirigido
Fundamentos matemáticos 14-9
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.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, y 15 respectivamente. Si los
vértices A, B y C representan tres ciudades en un estado, los
pesos, por ejemplo, podrían ser las distancias en millas entre
estas ciudades.
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 las
siguientes terminologías correo:
• u, v se dice que son adyacente o vecinos o
conectado.
• arista e es incidente con vértices u y v.
• arista e Conexiones uy v.
• vértices u y v son criterios de valoración de arista e.
Si vértice v ∈ V, el conjunto de vértices en el gráfico rected Gastos no
dis-G (V, E), entonces:
• el la licenciatura de v, deg (v), es su número de bordes inci- dente,
excepto que cualquier auto-bucles se cuentan dos veces.
14-10 Guía SWEBOK® V3.0
• un vértice con grado 0 se denomina vértice aislado.
• un vértice de grado 1 se llama una 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:
• u es adyacente a v y v es adyacente de u.
• e viene de uy va a v.
• e Conexiones u para v, o por correo viene de u para v.
• el vértice inicial de e es u.
• el vértice terminal de de E es v.
Si vértice v está en el conjunto de vértices para el grafo dirigido
G (V, E), entonces
• en grados de v, deg - ( v), es el número de aristas que van a
v, es decir, para el que v es el vértice borne.
• grado de salida de v, deg + (v), es el número de aristas que
vienen de v, es decir, para el que v es el vértice inicial.
• la licenciatura de v, deg (v) = deg -( v) + deg + (v), es la suma de
vs en grados y fuera grados.
• un bucle en un vértice contribuye 1 a tanto grado dentro y
fuera de grado de este vértice.
Se puede observar que, después de las definiciones anteriores, el
grado de un nodo es sin cambios si tenemos en cuenta sus bordes
para ser dirigidos o no dirigidos. En un grafo no dirigido, un camino
de longitud n de u a v es una secuencia de n bordes adyacentes de
vértice u al vértice v.
• Un camino es una circuito si u = v.
• Un camino poligonales los vértices a lo largo de ella.
• Un camino es sencillo si no contiene ningún borde más de una vez.
Un ciclo en n vértices C norte para cualquier n ≥ 3 es un gráfico que
PLE sim- donde V = {v 1, v 2, ..., v norte} y E = {{v 1,
v 2}, { v 2, v 3}, ..., v { n-1, v n}, { v norte, v 1}}.
Por ejemplo, la figura 14.13 ilustra dos ciclos de
longitud 3 y 4.
Figura 14.13. Ejemplo de ciclos C 3 y C 4
Una lista de adyacencia es una tabla con una fila por cada vértice,
enumerando sus vértices adyacentes. La adyacencia listado para un
grafo dirigido mantiene una lista de los nodos terminales para cada uno
de los vértices en el gráfico.
vértice de Adyacencia
Lista
UN ANTES DE CRISTO
segundo ABC
do A, B
Figura 14.14. Listas de adyacencia para los gráficos de las Figuras 14.10
y 14.11
Por ejemplo, la figura 14.14 ilustra las listas decencia adja- para la
pseudógrafo en la figura 14.10 y el gráfico dirigido en la figura 14.11.
A medida que el cabo-grado de vértice C en la figura 14.11 es cero,
no hay ninguna entrada en contra de C en la lista de adyacencia.
Diferentes representaciones para una matriz gráfica similar de
adyacencia, matriz de incidencia, y adyacencia listas-necesidad de
ser estudiados.
5.2. árboles 
Un árbol T (N, E) es una estructura de datos jerárquica de n = | N |
nodos con un nodo raíz especialmente designado R mientras que
los restantes n - 1 forman nodos subárboles en virtud de la R. nodo
raíz el número de bordes | E | en un árbol siempre sería igual a | N |
- 1. El sub-árbol en el nodo X es el subgrafo del árbol que consiste
en el nodo X y sus descendientes y todos aristas incidentes a los
descendientes. Como una alternativa a esta definición recursiva, un
árbol se puede definir como un grafo no dirigido conectado sin
circuitos simples.

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 de 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 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
Fundamentos matemáticos 14-11
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 están en el nivel 1. Los nodos restantes en la
figura 14.15 son todos en el nivel 2. La altura de un árbol es el
máximo de los nive- les de nodos en el árbol.
Por ejemplo, en la figura 14.15, la altura del árbol es 2. Un
nodo se denomina 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 de K son todos
los nodos de la hoja con el grado 0. Los antepasados ​o predecesores
de un nodo no raíz X son todos los nodos en el camino desde la raíz al
nodo X.
Por ejemplo, en la figura 14.15, los nodos A y D forman el
conjunto de antepasados ​para 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
denominan hermano linfáticos. 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 árbol ordenado si la posición relativa de
las apariciones de 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.
14-12 Guía SWEBOK® V3.0
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.16. Ejemplos de árboles binarios
Por ejemplo, en la figura 14.16, los dos árboles binarios son
diferentes como las posiciones de las apariciones de los niños de A
son diferentes en los dos árboles.
Figura 14.17. Ejemplo de un árbol binario completo
De acuerdo con [1 *], un árbol binario se llama un árbol binario
completo si cada nodo interno tiene exactamente dos hijos.
Por ejemplo, el árbol binario en la figura 14.17 es un árbol
binario completo, ya que ambos de los dos nodos internos A y B
son de grado 2.
Un árbol binario completo después de la definición anterior también se
conoce como una árbol estrictamente binario.
Por ejemplo, ambos árboles binarios en la figura 14.18 son
árboles binarios completos. El árbol de la figura
14.18 (a) es un árbol binario completo completo, así como. Un árbol binario
completo tiene todos sus niveles, excepto posiblemente el último, se
llenaron a capacidad. En caso de que el último nivel de un árbol binario
completo no está lleno, los nodos se producen desde las posiciones más a
la izquierda disponibles.
Figura 14.18. Ejemplo de árboles binarios completos
Curiosamente, a raíz de las definiciones anteriores, el árbol de la
figura 14.18 (b) es un árbol binario completo, pero no completo como
nodo B ha sólo un niño en D. Por el contrario, el árbol de la figura
14.17 es un completo
- pero no completar binario árbol, como los hijos 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
se producen en los niveles de 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 2 MARIDO 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 =
• Iniciar sesión 2 L •.
Por ejemplo, esta afirmación es cierta para los dos árboles en las
figuras 14,17 y 14,18 (a) ya que ambos árboles son completa y
equilibrada. Sin embargo, la expre- sión anterior no coincide con el
árbol de la figura
14.18 (b), ya que no es un árbol binario completo. Un árbol de búsqueda
binaria (BST) es un tipo especial de árbol binario en el que cada nodo
contiene un valor de clave distinta, y el valor de la clave de cada nodo del
árbol es menos de todos los valores clave en su subárbol derecho y
mayor que todos los valores clave en su subárbol izquierdo. Un algoritmo
de recorrido es un procedimiento para visitar de forma sistemática todos
los nodos de un árbol binario. recorrido de árboles pueden definirse de
forma recursiva. Si T es un árbol binario con raíz de R y los nodos de ING
restante formar un par ordenado de subárbol izquierdo T no nulo L y no nulo
subárbol derecho de T R inferior a R, entonces el orden previo función
preorder traversal (T) se define como:
PREORDER (t) = R, PREORDER (T L), Preorden (T R)
... la ecuación. 1

El proceso recursivo de encontrar el recorrido en preorden de los
subárboles continúa hasta que los subárboles se encuentran para
ser nulo. Aquí, las comas se han utilizado como delimitadores en
aras de mejorar la legibilidad.
El orden posterior y en orden pueden ser definidos de forma similar
usando la ecuación. 2 y la ecuación. 3 respectivamente.
Postorden (T) = postorden (T L), Orden posterior (T R),
R ... la ecuación 2
Finde (T) = finde (T L), R, a finde (T R) ... eqn 3
Figura 14.19. Un árbol de búsqueda binaria
Por ejemplo, el árbol de la figura 14.19 es un árbol binario de
búsqueda (BST). Las salidas de recorrido preorden, postorden, y en
orden para la BST se dan a continuación en su orden respectivo.
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
Mayor discusión sobre los árboles y su uso ha sido incluido en la
sección 6, Estructura de Datos y de re- presentación, de los
Fundamentos de Informática KA.
6. probabilidad discreta
[1 *, c7]
La probabilidad es la descripción matemática de la
aleatoriedad. definición básica de la probabilidad y
Fundamentos matemáticos 14-13
aleatoriedad se ha definido en la sección 4 de este KA. A continuación,
vamos a empezar con los conceptos detrás de la distribución de
probabilidad y la probabilidad discreta. Un modelo de probabilidad es
una descripción matemática de un fenómeno aleatorio que consta de
dos partes: un espacio de muestra S y una forma de asignar
probabilidades a los eventos. El espacio de muestra define el conjunto
de todos los posibles resultados, mientras que un evento es un
subconjunto de un espacio muestra que representa un posible resultado
o un conjunto de resultados. Una variable aleatoria es una función o
regla que asigna un número a cada resultado. Básicamente, es sólo un
símbolo que representa el resultado de 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 po- sible 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. Por ejemplo, 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á a la nombre de
la variable aleatoria. Su minúscula contraparte, x,
representará a la valor de la variable dom ran-.
La probabilidad de que la variable aleatoria X será igual a 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 aso- ciados con estos valores.
14-14 Guía SWEBOK® V3.0

Probabilidades asociadas con variables aleatorias discretas Estos números de hecho apuntan a derivar el valor de edad
tienen las siguientes propiedades: promedios a partir de experimentos repetidos. Esto se basa en el
único fenómeno más importante de la probabilidad, es decir, el
yo. 0 ≤ P (x) ≤ 1 para todo x valor promedio de los experimentos repetidos es probable que sea
ii. ΣP (x) = 1 próximo al valor esperado de un experimento. Por otra parte, el
valor medio es más probable que sea más próximo al valor
Una distribución de probabilidad discreta puede repre- tantes como esperado de cualquier un experimento como el número de
una variable aleatoria discreta. experimentos aumenta.

x 1 2 3 4 5 6
7. máquinas de estados finitos
P (x) 1/6 1/6 1/6 1/6 1/6 1/6 [1 *, c13]

Figura 14.20. Una función de probabilidad discreta para un balanceo Un sistema informático puede ser abstraído como un mapeo de de
Morir estado a estado impulsado por insumos. En otras palabras, un sistema
puede ser considerado como una función T transición: S × I → S × O,
El significado μ de un modelo de distribución de probabilidad es la donde S es el conjunto de estados y I, O son las funciones de entrada y

suma de los términos de productos para eventos individuales y su de salida. Si el estado conjunto S es finito (no infinita), el sis- tema se

probabilidad de resultado. En otras palabras, por los posibles llama máquina de estados finitos ( FSM). Alternativamente, una máquina
de estado finito (FSM) es una abstracción matemática compuesta de un
resultados x 1, x 2, … , x norte
en un espacio de muestra S si p k es la probabilidad de OUT- llegado x k, la número finito de estados y transiciones entre dichos estados. Si el
media de esta probabilidad sería μ = x 1 pag 1 + x 2 pag 2 + ... + x norte pag norte. dominio S × I es razonablemente pequeño, entonces se puede
especificar T explícitamente usando diagramas similares a un gráfico de
Por ejemplo, la media de la densi- dad de probabilidad para flujo para ilustrar los flujos de la forma lógica para diferentes entradas.
la distribución en la figura 14.20 sería Sin embargo, esto es prác- tica sólo para máquinas que tienen una
capacidad muy pequeña información.
1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5
* (1/6) + 6 * (1/6) = 21
* (1/6) = 3,5
Un FSM tiene una memoria finita interna, una característica de entrada

En este caso, el espacio muestral se refiere al conjunto de todos los que lee símbolos en una secuencia y de una en una, y una entidad de

resultados posibles. La varianza es 2 de un modelo de probabilidad discreta salida. El funcionamiento de una MEF comienza a partir de un estado

es: s 2 = ( x 1 - μ) 2 pag 1 + ( x 2 - μ) 2 pag 2 + ... + (x k - μ) 2 pag k. inicial, pasa a través de transiciones en función de la entrada a los

diferentes estados, y puede terminar en cualquier estado válido. Sin

los desviación estándar s es la raíz cuadrada de la varianza. embargo, sólo unos pocos de todos los estados marcan un flujo exitoso de

la operación. Estos se llaman aceptar estados.

Por ejemplo, para la distribución de probabilidad en la figura

14.20, la variación σ 2 sería
La capacidad de información de una MEF es C = log | P |. Por lo tanto,

s 2 = [( 1 - 3.5) 2 * ( 1/6) + (2 - 3.5) 2 * ( 1/6) + ácido (3 - 3.5) 2 * ( 1/6) si representamos una máquina que tiene una capacidad de información

+ (4 - 3.5) 2 * ( 1/6) + (5 - de bits C como un FSM, entonces su gráfica de transición de estado

3.5) 2 * ( 1/6) + (6 - 3.5) 2 * ( 1/6)] = (6,25 + 2,25 + 0,25 + tendrá | S | = 2 do linfáticos. Una máquina de estado finito se define

0,5 + 2,25 + 6,25) * (1/6) formalmente como METRO 

= ( S, YO, O, F, g, s 0).

= 17,5 * (1/6) =
2,90 S es el conjunto de estado;
yo es el conjunto de símbolos de entrada;
∴ desviación estándar s = O es el conjunto de símbolos de salida;
F es la función de transición de estado;
 Fundamentos matemáticos 14-15

gramo es la función de salida; y s 0 es Los valores de transición y de salida de estado para diferentes entradas

el estado inicial. sobre diferentes estados pueden ser representados usando una tabla de

estados. La tabla de estado para el FSM en la figura 14.21 se muestra en

Dada una entrada x ∈ I en el estado S k, la FSM hace una la figura 14.22. Cada par contra un símbolo de entrada representa el nuevo

transición al estado S marido siguiente estado tran- sición función f y estado y el símbolo de salida.

produce una salida Y ∈ O el uso de la función de salida g.

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 len- guaje 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 la ayuda de estas
reglas, se refiere como reglas de producción.

Figura 14.21. Ejemplo de 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
Por ejemplo, la figura 14.21 ilustra una FSM con S 0 como el reglas para la formación de estas palabras o cadenas. Todo el
estado de inicio y S 1 como el estado final. Aquí, S = {S 0, S 1, S 2}; I =conjunto de palabras que son válidos para una gramática constituye
{0, 1}; O = {2, 3}; f (S 0, el len- guaje de la gramática. Por lo tanto, la gramática G es
0) = S 2, f (S 0, 1) = S 1, f (S 1, 0) = S 2, f (S 1, 1) = S 2, f (S 2, cualquiera, definición matemática precisa compacta de un lenguaje
0) = S 2, f (S 2, 1) = S 0; g (S 0, 0) = 3, g (S 0, 1) = 2, G (S 1, L en lugar de sólo una lista sin procesar de todas las frases o
0) = 3, g (S 1, 1) = 2, G (S 2, 0) = 2, G (S 2, 1) = 3. ejemplos de esas frases legales de la lengua.

Estado Entrada

actual 0 1 Una gramática implica un algoritmo que genere todas las

sentencias legales de la lengua. Hay diferentes tipos de
S0 S2 S1
gramáticas. A-estructura de la frase o de tipo 0 gramática G
S1 S2 S2 = (V,
S2 S2 S0 T, S, P) es un 4-tupla en los que:

(un) • 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 símbolo de inicio.

Salida Estado
Estado
Entrada Entrada • P es el conjunto de reglas producciones para sustituyéndolo por
actual
un fragmento de frase para otra.
0 1 0 1

S0 3 2 S2 S1
Existe otro conjunto N = V - T de palabras llamado no terminales.
S1 3 2 S2 S2 Los no terminales representan conceptos como sustantivo. Las reglas
S2 2 3 S2 S0 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
(segundo) cadena. El símbolo inicial S es un no terminal.

Figura 14.22. Representación tabular de una MEF

14-16 Guía SWEBOK® V3.0
El lenguaje generado por una gramática formal
G, denotado por L (G), es el conjunto de todas las cadenas sobre el
conjunto de alfabetos V que puede ser generada, puesta en ing con el
símbolo de inicio, mediante la aplicación de reglas de pro- ducción hasta
que todos los símbolos no terminales son sustituidos en la cadena de .
Por ejemplo, sea G = ({S, A, a, b}, {a, b}, S, S {
→ aA, S → b, A → aa}). En este caso, el conjunto de termina- nales
son N = {S, A}, donde S es el símbolo inicial. Las tres reglas de
producción de la gramática se dan como P1: S → aA; P2: S → b; P3: A
→ AA. La aplicación de las normas de producción en todas las formas
posibles, las siguientes palabras pueden ser generados a partir del
símbolo de inicio.
S → aA (Usando el símbolo de inicio P1)
→ aaa (Usando P3)
S→b (P2 utilizando el símbolo de inicio)
Nada más se puede derivar para G. Por lo tanto, el lenguaje
de la gramática G consta de sólo dos palabras: L (g) = {aaa, b}.
8.1. Reconocimiento idioma  gramática lineal derecha. Por otra parte, si a = Dc, a continuación, la
gramáticas formales pueden ser clasificados de acuerdo a los tipos
de producciones que se permiten. La jerarquía de Chomsky
(introducido por Noam Chomsky en
1956) describe un esquema de dicha clasificación.
Figura 14.23. Jerarquía de Chomsky de gramáticas
Como se ilustra en la figura 14.23, inferimos la siguien- tes en
diferentes tipos de gramáticas:
1. Cada gramática regular es una gramática libre de contexto
(CFG).
2. Cada CFG es una gramática sensible al contexto (CSG).
3. Cada CSG es una gramática-estructura de la frase (PSG).
Contextual Gramática: Todos los fragmentos en el RHS son o
bien más largo que los fragmentos correspondientes en el LHS o
vacío, es decir, si b → a, entonces | b | <| A | o a = ∅.
Un lenguaje formal es sensible al contexto, si una gramática sensible
al contexto genera. Gramática de contextos libre: Todos los fragmentos
en el LHS son de longitud 1, es decir, si A → a, entonces | A | = 1 para
todos A ∈ NORTE.
El término deriva libres de contexto desde el hecho de que A siempre
puede ser sustituido por una, independientemente del contexto en el que
ocurre.
Un lenguaje formal es independiente del contexto, si una
gramática libre del contexto genera. lenguajes libres de contexto
son la base teórica para la sintaxis de los lenguajes de
programación.
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
terminal; es decir, si A → a, entonces o bien una ∈ T, o a = CD, o a = Dc
para c ∈ T, D ∈ N. Si a = CD, y después la gramática se llama una
gramática se llama una gramática lineal izquierda. Tanto la derecha y
gramáticas lineales lineales izquierda son regu- lar o tipo 3 gramática.
El lenguaje L (G) generado por una gramática regular G se
denomina un lenguaje regular. 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, OR (+), PRODUCTOS (.), Nación concatenación (*).
El lenguaje de G, L (G) es igual a todas esas cadenas que
coinciden con G, L (G) = {x ∈ S * | x ​coincide con G}.
Para cualquier una ∈ S, L (A) = a; L (e) = { ε}; L (0) = 0.
+ funciona como un o, L (A + B) = L (A) ∪ L (B).
. crea una estructura de producto, L (AB) = L (A). L (B).
* denota la concatenación, L (A *) = {x 1 x 2 …x n |
x yo ∈ L (A) y n ³ 0}
Por ejemplo, la expresión regular (ab) * coincide con el
conjunto de cadenas: {e, ab, ABAB, ababab, ABABABAB, ...}.

Por ejemplo, la expresión regular (aa) * coincide con el conjunto
de cadenas en una carta un que tienen igual longitud.
Por ejemplo, la expresión regular (aaa) * + (aaaaa) * coincide
con el conjunto de cadenas de longitud igual a un múltiplo de 3 o 5.
9. numérica 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 = 2 k diferentes números.
Por ejemplo, un equipo que utiliza 32 bits aritmética puede
almacenar un total de N = 2 32 ≈ 4,3 × 10 9 números dife- rentes,
mientras que otro que utiliza 64 bits puede manejar N'= 2 64 ≈ 1,84 ×
10 19 diferentes números. 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 - 2 k-1 a 1. Como 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 en estrecha colaboración -por
ejemplo con una separación uniforme de 2 -n -y así distribuir el número total
N de manera uniforme sobre el intervalo de -2 -n-1 N <x ≤ 2 -n-1 N. Los números
reales que se encuentran entre los huecos están representados por
cualquiera ING redonda ( es decir, el representante más cercano exacta)
Fundamentos matemáticos 14-17
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 a definir un par de términos muy importantes:
exactitud y precisión como asociado con el análisis ical numer-.
La precisión 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 un valor exacto.
Sea x un número real y sea x * sea una aproximación.
los error absoluto en la aproximación x * x ≈ se define como |
x * - x |. los 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 ≥ 0, y son = 0 si y
sólo si la aproximación es exacta.
Una aproximación x * tiene k dígitos significativos mal deci- si
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 una regla de 15,5 mm con ± 0,5 mm máximo
14-18 Guía SWEBOK® V3.0
error permisible tiene 2 dígitos significativos, mientras que una
medición de la misma longitud usando un calibrador y se registrará
como 15,47 mm con ± 0,01 mm error permisible mamá maxi- tiene 3
dígitos significativos.
10. Teoría de Números
[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  -1. Cualquier número real de múltiples yo es un número imaginario,
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 natu-
ral 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 que se pueden expresar
como un cociente de dos números enteros. El símbolo común para el
conjunto de todas las fibras No. de orden racional es Q.
Los números racionales se pueden clasificar en tres tipos, en
función de cómo actúan los decimales. los
decimales o no existen, por ejemplo, 15, o, cuando existen
decimales, pueden terminar, como en 15.6, o pueden repetir
con un patrón, como en 1,666 ..., (que es 5/3).
Numeros irracionales. Estos son números que no se pueden expresar
como un número 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 yo. Este número imaginario es igual a la raíz cuadrada de
por ejemplo, yo, 5 yo,
3.2 yo, -2.6 yo, etcétera
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 + b yo. 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 DO.
Por ejemplo, 2 + 3 yo, 3-5 yo, 7,3 + 0 yo, y 0 + 5 yo.
Tenga en cuenta los dos últimos ejemplos:
7,3 + 0 yo 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 + 5 yo es sólo el número imaginario 5 yo. 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 una ≠ 0. El expre- sión a | b, es decir, un
divide b Si ∃ do ∈ 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 un
divisiones segundo, entonces se dice que un es un factor de
segundo o un es un divisor de segundo, y segundo es un múltiplo de a.
segundo es incluso si y sólo si 2 | segundo.
Dejar a, d ∈ Z con d> 1. Entonces un mod d denota que el
resto r desde el algoritmo de la división con dividendo un y el
divisor re, es decir, el resto cuando una se divide por d. Podemos
calcular ( un mod 
re) por: A - d * • anuncio •, dónde • anuncio • representa el límite inferior del
número real. Sea Z + = {n ∈ Z | n> 0} y a, b ∈ Z, m ∈ Z +, entonces A es
congruente con b módulo m, escrita como un ≡
b (mod m), si y solo si m | a-b.

Alternativamente, un es congruente con b módulo m si y solo si ( a-b)11.1. Grupo
m mod = 0.
10.2. Número primo, GCD  operación binaria satisface el seguimiento ing cuatro criterios:
Un entero p> 1 es primo si y sólo si no es el producto de
dos números enteros mayores que 1,
es decir, si p es primo p> 1 ∧ ∃ ¬ a, b ∈ N: a> 1, b>
1, a * b = p.
Los únicos factores positivos de un primo p es 1 yp sí.
Por ejemplo, los números 2, 13, 29,
61, etc., son números primos. nonprime números enteros mayores que
1 se llaman números compuestos. Un número compuesto puede estar
compuesto por plying multi- dos números enteros mayores que 1.
Hay muchas aplicaciones interesantes de números primos;
entre ellos se encuentran la criptografía de clave pública esquema,
que implica el intercambio de claves públicas que contiene el
producto
p * q de dos grandes números primos aleatorios pag y q ( una clave privada)
que debe mantenerse en secreto por un partido determinado. El gcd
máximo común divisor (a, b) de Gers inte- a, b es el mayor número entero
d que es un divisor tanto de A y de B, es decir,
d = gcd (a, b) para max (d: d | a ∧ d | b)
Por ejemplo, gcd (24, 36) = 12. Los números enteros un y segundo se
llaman primos o primos entre sí, si y sólo si su MCD es 1. Por ejemplo,
ni 35 ni 6 son primos, pero están coprimeros ya que estos dos
números no tienen factores comunes mayor que 1, por lo que su MCD
es 1. Un conjunto de números enteros X = {i 1, yo 2, ...} es relativamente
primo si todos los pares posibles i marido, yo k, h ≠ k trazada desde el
conjunto X son relativamente primos.
11. Estructuras algebraicas
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 ningunos.
Por ejemplo, grupo, monoid, anillo, y celosía son ejemplos de
estructuras algebraicas. Cada una de ellas se define en esta
sección.
Fundamentos matemáticos 14-19
Un conjunto S cerrado bajo una operación binaria • forma un grupo si la
• Asociativa: ∀ a B C ∈ S, la ecuación (a • b)
• c = a • (b • c) se mantiene.
• Identidad: No existe un elemento que la identidad ∈
S tal que para todo un ∈ S, I • a = a • I = a.
• Inversa: Cada elemento de una ∈ S, tiene una inversa a' ∈ S
con respecto a la operación binaria,
es decir, un • a'= I; Por ejemplo, el conjunto de los enteros Z
con respecto a la operación de suma es un grupo. El
elemento de identidad del conjunto es 0 para la operación de
adición. ∀ x ∈ Z, la inversa de x sería -x, que también se incluye
en Z.
• propiedad de encierro: ∀ a, b ∈ S, el resultado de la operación a
• b ∈ S.
• Un grupo que es conmutativa, es decir, un • b = b • a, que se conoce
como un grupo conmutativo o abeliano.
El conjunto de números naturales N (con el funciona- miento de
adición) no es un grupo, ya que no hay inversa para cualquier x> 0 en el
conjunto de números naturales. Por lo tanto, se viola la tercera regla (de
inversa) para nuestra operación. Sin embargo, el conjunto de los números
naturales tiene alguna estructura.
Sets con una operación asociativa (la primera condición
anterior) se llaman semigroups; si también tienen un elemento
de identidad (el segundo ción condi-), entonces se les llama
monoides. Nuestro conjunto de los números naturales bajo la
suma es entonces un ejemplo de un monoide, una estructura
que no es un grupo bastante porque falta el requisito de que
cada elemento tiene una inversa bajo la operación.
Un monoide es un conjunto S que se cierra en una sola operación
binaria asociativa • y tiene un elemento de identidad I ∈ S tal que para
todo un ∈ 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 un monoide conmutativo bajo la
multiplicación con el elemento de identidad 1. Se puede observar que,
a diferencia de los de un grupo, los elementos de un monoid no
necesita tienen inversos. UN
14-20 Guía SWEBOK® V3.0
monoid también puede ser pensado como un semigrupo con un elemento
de identidad. UN subgrupo es un grupo MARIDO contenida dentro de una
más grande, GRAMO, de tal manera que el elemento de identidad de
GRAMO está contenido en MARIDO, y siempre marido 1 y marido 2 se
sobre la primera, entonces tenemos un anillo.
encuentran en MARIDO, entonces también lo son marido 1 • marido 2 y marido 1-1.
Así, los ele- mentos de MARIDO, equipado con la operación del grupo en
GRAMO prohibido para MARIDO, de hecho formar un grupo. Dado
cualquier subconjunto S de un grupo GRAMO, el subgrupo generado por S se+ ) es un grupo abeliano, (S, •) es un semigrupo, y
compone de productos de elementos de S y sus inversos. Es el subgrupo
más pequeño de GRAMO que contiene S.
Por ejemplo, sea GRAMO ser el grupo abeliano cuyos
elementos son G = { 0, 2, 4, 6, 1, 3, 5, 7} y cuya operación de
grupo es suma de módulo 8. Este grupo tiene un par de
subgrupos no triviales: J = { 0, 4} y
H = { 0, 2, 4, 6}, donde J es también un subgrupo de MARIDO.
En la teoría de grupos, un grupo cíclico es un grupo que puede
ser generada por un solo elemento, en el sentido de que el grupo
tiene un elemento un ( llamó al
generador del grupo) de tal manera que, cuando se escribe
multiplicativa, cada elemento del grupo es una potencia de a.
Un grupo G es cíclico si G = {a norte para cualquier número entero n}.
Puesto que cualquier grupo generado por un elemento en un grupo es
un subgrupo de dicho grupo, que muestra que el único subgrupo de un
grupo G que contiene un es en sí misma G es suficiente para mostrar
que G es cíclico. Por ejemplo, el grupo G = { 0, 2, 4, 6, 1, 3, 5, 7}, con
respecto a la adición de módulo 8 operación, es cíclico. los subgrupos J
= { 0, 4} y H = { 0, 2,
4, 6} también son cíclicos.
11.2. anillos 
Si tomamos un grupo abeliano y definimos una segunda operación en
él, una nueva estructura se encuentra que es diferente de sólo un
grupo. Si esta segunda funciona- miento es asociativa y es distributiva
Un anillo es un triple de la forma (S, +, •), donde (S,
• es distributiva sobre +; es decir, “a, b, c ∈ S, la ecuación ción un • ( segundo
+ c) = (a • segundo) + (Una • do) sostiene. Además, si
• es conmutativo, entonces el anillo se dice que es conmutativa. Si hay
un elemento de identidad para el • funcionamiento, entonces el anillo
se dice que tiene una identidad. Por ejemplo, (Z, +, *), es decir, el
conjunto de los enteros Z, con la adición usual y multiplicación opera-
ciones, es un anillo. Como (Z, *) es conmutativo, este anillo es un anillo
conmutativo o abeliano. El anillo tiene 1 como su elemento de
identidad.
Vamos a señalar que la segunda operación no puede tener un
elemento de identidad, ni tampoco tenemos que encontrar un inverso
para cada elemento con respecto a esta segunda operación. En cuanto a
lo que significa la distribución, de manera intuitiva que es lo que
hacemos en matemá- ticas elementales al realizar el siguiente cambio:
una
* (B + c) = (a * b) + (a * c).
Un campo es un anillo para el que los elementos del conjunto, con
exclusión de 0, forman un grupo abeliano con la segunda operación.
Un ejemplo simple de un campo es el campo de los números
gestionar racionalmente (R, +, *) 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
segundo ≠ 0. El inverso aditivo de una fracción tal es simplemente - a / b, y
es el inverso multiplicativo licenciado en Letras
siempre que un ≠ 0.
 Fundamentos matemáticos 14-21

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Cheney y Kincaid 2007

Rosen 2011

[2 *]
[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

14-22 Guía SWEBOK® V3.0

Referencias EXPRESIONES DE GRATITUD

[1 *] K. Rosen, Matemática Discreta y sus  El autor reconoce por suerte la contribución del profesor Arun
aplicaciones, 7ª ed., McGraw-Hill, 2011. Kumar Chatterjee, Ex-Jefe del Departamento de Matemáticas de
la Universidad de Manipur, India, y el Prof. Devadata Sinha,
[2 *] EW Cheney y DR Kincaid, Numérico  Ex-Jefe del Departamento de Ciencias de la Computación y
Matemáticas y Computación, 6ª ed., Brooks / Engineer- ing, Universidad de Calcuta, India, en la preparación de
Cole, 2007. este capítulo sobre Fundamentos matemáticos.
 CAPÍTULO 15
FUNDAMENTOS DE INGENIERÍA
SIGLAS
CANALLA Computer-Aided Design CMMI
Capability Maturity Model
Integration pdf
Función de densidad de probabilidad PMF
Probabilidad función de masa de RCA
Análisis de Causa Raíz
SDLC Ciclo de vida del desarrollo de programas
INTRODUCCIÓN
IEEE define de 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 com- mon 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 de manera eficiente y de
ingeniería
15-1
efectivamente es un objetivo de todos los ingenieros en todas las
disciplinas de inge- niería.
DISTRIBUCIÓN DE TEMAS PARA
FUNDAMENTOS DE INGENIERÍA
El desglose de los temas de los Fundamentos de Ingeniería KA
se muestra en la figura 15.1.
1. Métodos empíricos y técnicas
experimentales
[2 *, c1]
Un método de ingeniería para la resolución de problemas implica
proponer soluciones o modelos de soluciones y luego la realización
de experimentos o ensayos para estudiar las soluciones o modelos
propuestos. Por lo tanto, los ingenieros deben entender cómo crear
un iment exper- y luego analizar los resultados del experi- mento con
el fin de evaluar la solución propuesta. Los métodos empíricos y
técnicas experimentales ayudan al ingeniero para describir y
entender la variabilidad en sus observaciones, para identificar las
fuentes de variabilidad, y para tomar decisiones. experimentos tres
tipos diferentes de estudios empíricos com- utilizan comúnmente en
los esfuerzos de ingeniería están diseñados, estudios
observacionales y estudios retrospectivos. Breves descripciones de
los com- métodos utilizados comúnmente se dan a continuación.
1.1. experimento diseñado
Un experimento diseñado o controlada es un investiga- ción de
una hipótesis comprobable donde una o más variables
independientes son manipuladas para medir su efecto sobre una
o más variables dependientes. Una condición previa para la
realización de un experimento es la existencia de una hipótesis
clara. Es importante para un ingeniero para entender cómo
formular hipótesis claras.
15-2 Guía SWEBOK® V3.0
Figura 15.1. Desglose de los temas de los Fundamentos de Ingeniería KA
experimentos diseñados permiten a los ingenieros para
determinar de forma precisa cómo se relacionan las variables y, en
concreto, si existe una relación causa-efecto entre ellos. Cada
combinación de valores de las variables independientes es una tratamiento.
Con el fin de llevar a cabo sus responsabilidades, inge- nieros deben
Los experimentos simples tienen sólo dos tratamientos que
representan dos niveles de una variable independiente GLE 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 un 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 con-
textual 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 eventos futuros, o para identificar
tendencias. La calidad de los resultados del análisis dependerá de la
calidad de la información contenida en los datos archivados. Los datos
históricos pueden ser incompleta, inconsistente medido, o incorrecta.
2. Análisis estadístico [ 2 *, c9s1, C2S1] [3 *, c10s3]
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 ejem- plo, 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 diferentes. Por
ejemplo, cuando la población de estudio consta de sólo el pasado
observaciones y generalizaciones son necesarios para el futuro, la
población estudiada y la población objetivo 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 de probabilidad.
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 estu- dios 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 discreta. En
otros casos, la variable aleatoria bajo consideración puede tomar
valores en una escala continua y que se llama una variable de dom
ran- continua. Evento. Un subconjunto de valores posibles de una
variable aleatoria se llama un evento. Supongamos que X denota
algún variable aleatoria; entonces, por ejemplo, podemos definir
diferentes eventos tales como X ³ X <x x o y así sucesivamente.
Fundamentos de Ingeniería 15-3
Distribución de una variable aleatoria. La gama y el patrón de
variación de una variable aleatoria está dada por su distribución.
Cuando se conoce la distribución de una variable 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: se utiliza para modelar variables
aleatorias que cuentan el número de éxitos en norte ensayos
realizados independientemente unos de otros, en cada ensayo
da como resultado el éxito o el fracaso. Hacemos una
suposición de que la posibilidad de obtener un éxito permanece
cons- tante [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 ejem- plo, 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
completa- mente 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 densidad y tiene que integrarse en un
rango para obtener la probabilidad de que los continuos variabilidad
aleatoria capaces mentiras entre ciertos valores. Por lo tanto, si el
pdf
15-4 Guía SWEBOK® V3.0
o PMF se conoce, las posibilidades de la variabilidad aleatoria capaz
teniendo cierto conjunto de valores pueden ser calculadas teóricamente.
Concepto de la estimación [ 2 *, c6s2, c7s1, c7s3]. Los verdaderos
valores de los parámetros de una distribución son generalmente
desconocidas y necesitan ser estimada a partir de las observaciones de la
muestra. Las 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 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 posible tamaño del error o propiedades estadísticas del
compañero de estimación punto. Por lo tanto, necesitan un suplemento
de una estimación puntual con el tamaño de la muestra, así como la
varianza de la estimación. Como alternativa, podríamos utilizar una
estimación de intervalo. Una estimación de intervalo es un intervalo
aleatorio con el li- inferior y superior del intervalo de sus siendo
funciones de la muestra
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 pro- puesto
hipótesis debe ser aceptada o rechazada. Para la prueba de
hipótesis, se forman las hipótesis nula y alternativa. La hipótesis
nula es la hipótesis de no cambio y se denota como H 0. La
hipótesis alternativa se escribe como H 1. Es impor- tante 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 creer que la hipótesis alternativa es
verdadera.

A medida que se toma la decisión sobre la base de las
observaciones de la muestra, los errores son posibles; los tipos de
tales errores se resumen en la tabla siguien- tes.
Decisión estadística
Naturaleza
aceptar H 0 rechazar H 0
MARIDO error tipo I
DE ACUERDO
es verdad (probabilidad = a)
0
MARIDO error tipo II
DE ACUERDO
0 Es falso (probabilidad = b)
En la prueba de hipótesis, nuestro objetivo es maximizar la potencia de
la prueba (el 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 posi- ble 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 dife- rentes 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 entre las
variables es perfecto, es decir,
Fundamentos de Ingeniería 15-5
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 llama 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
15-6 Guía SWEBOK® V3.0
sistema empírico real. Métodos de medición definen
actividades que asignan un valor o un símbolo a un atributo de
una entidad.
Los atributos deben entonces ser definidos en términos de las
operaciones utilizadas para identificar y medir ellos- es decir, los
métodos de medición. En este enfoque, un método de medición se
define 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 atri- buye, 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 medida; a veces una 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 que la altura de los individuos varían a
través de varios puntos de tiempo del día), cómo la variabilidad
debida al cabello lo que se ocuparon de, si la medición será con
o sin zapatos, ¿qué clase de precisión que se espera (corregir
hasta una pulgada, 1/2 pulgada, centímetro, etc.) -, incluso
esta simple medida dará lugar a una variación sustancial. Los
ingenieros deben apreciar la necesidad de definir medidas desde
una 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)
• Modelo de Capacidad de Madurez Integración
(CMMI) niveles de madurez de software de desa- rrollo
organizaciones

• Nivel de adherencia a procesar tal como se mide en una escala de
5 puntos de excelente, encima de la media, media, por debajo de
la media, y pobre, lo que indica el intervalo de adhesión total a no
adherencia en absoluto
La medición en escala ordinal satisface la propiedad sibilidad
tran- en el sentido de que si A> B y B
> C, entonces A> C. Sin embargo, las operaciones aritméticas no
puede llevarse a cabo en variables medidas en escalas ordinales. Por
lo tanto, si se mide la satisfacción del cliente en una escala ordinal de 5
puntos de 5 lo que implica un alto nivel de satisfacción y 1 lo que
implica un alto nivel de insatisfacción, no podemos decir que una
puntuación de cuatro es dos veces mejor que una puntuación de dos.
Por lo tanto, es mejor utilizar terminología como excelente, encima de
la media, media, por debajo de la media, y pobres que los números
ordinales con el fin de evitar el error de tratamiento de una escala
ordinal como una escala de proporción. Es importante tener en cuenta
que las medidas ordinales escala son comúnmente mal y el mal uso
puede llevar a conclusiones erróneas [6 *, P274]. Un mal uso común de
medi- das escala ordinal es presentar una media y la desviación
estándar para el conjunto de datos, los cuales son de sentido. Sin
embargo, podemos encontrar la mediana, como el cálculo de la
mediana consiste en el conteo solamente.
escalas de intervalo: Con la escala de intervalos, llegamos a una
forma que es cuantitativa en el sentido ordinario de la palabra. Casi
todas las medidas habituales Statistical Sta son aplicables aquí, a
menos que requieran el conocimiento de una cierto Punto cero. El
punto cero en una escala de intervalo es una cuestión de con-
vención. Proporciones no tienen sentido, pero la diferencia entre los
niveles de atributos se pueden calcular y es significativo. Algunos
ejemplos de escala de intervalo de seguimiento de medición:
• Medición de la temperatura en diferentes escalas, como
Celsius y Fahrenheit. SUP- plantear T 1 y T 2 son
temperaturas medidas en alguna escala. Observamos
que el hecho de que T 1
es el doble T 2 no quiere decir que un objeto es dos veces más
caliente que otro. También observamos que los puntos cero son
arbitrarias.
• Las fechas del calendario. Mientras que la diferencia entre las
fechas para medir el tiempo transcurrido es un concepto ingful
Entretanto, la relación no tiene sentido.
• Muchas mediciones psicológicas aspiran a crear escalas de
intervalo. La inteligencia es a menudo
Fundamentos de Ingeniería 15-7
medido en escala de intervalo, ya que no es preciso proceder
a definir lo que significaría cero inteligencia.
Si una variable se mide en escala de intervalos, la mayoría de los
análisis estadísticos habituales, como media, Normaliza- dard
desviación, correlación y regresión pueden llevarse a cabo sobre los
valores medidos.
Escala de proporción: Estos son muy comúnmente encon- trada en la
ciencia física. Estas escalas de medi- das se caracterizan por el hecho
de que existen operaciones para la determinación de los 4 relaciones:
igualdad, orden de rango, la igualdad de los intervalos, y la igualdad de
las proporciones. Una vez que tal escala está disponible, sus ues Val-
numérico se pueden transformar de una unidad a otra con sólo
multiplicar por una constante, por ejemplo, la conversión de pulgadas a
pies o centímetros. Cuando las mediciones se realizan en escala de
razón, la existencia de un cero no arbitrario es obligatorio. Todas las
medidas estadísticas son aplicables a escala de razón; uso logaritmo
sólo es válido cuando se utilizan estas escalas, como en el caso de
decibelios. Algunos ejemplos de medidas de razón son
• el número de declaraciones en un programa de software
• temperatura medida en la escala Kelvin (K) o en
Fahrenheit (F).
Una escala de medición adicional, la escala absoluta, es una escala
de proporción con singularidad del seguro de medi-; es decir, una
medida para la cual no es posible la transformación (por ejemplo, el
número de los programadores trabajando en un proyecto).
3.2. Medidas directos y derivados 
[6 *, c7s5]
Las medidas pueden ser directa o derivados (algunas veces
llamados medidas indirectas). Un ejemplo de una medida directa
sería una cuenta de cuántas veces que ocurre un evento, como
por ejemplo el número de defectos encontrados en un producto de
software. A medida derivada es uno que combina las medidas
directas de alguna manera que es consistente con el método de
medición. Un ejemplo de una medida derivada sería el cálculo de
la productividad de un equipo como el número de líneas de código
desarrolladas por mes Developer-. En ambos casos, el método de
medición determina cómo hacer la medición.
15-8 Guía SWEBOK® V3.0
3.3. Fiabilidad y Validez
[4 *, c3s4, c3s5]
Una cuestión fundamental que se plantea para cualquier método
de medi- ción es si el método de medi- ción propuesta es
realmente medir el concepto de buena calidad. Fiabilidad y
validez son los dos criterios más importantes para abordar esta
cuestión. La fiabilidad de un método de medición es el grado en
el que la aplicación del método de medición proporciona
resultados de medición consistentes. Esencialmente, confiabilidad de esta sección es identificar los conceptos necesarios para
se refiere a la consistencia de los valores obtenidos cuando el
mismo artículo se mide un número de veces. Cuando los
resultados están de acuerdo entre sí, se dice que el método de
medición fiables. Fiabilidad por lo general depende de la
definición operativa. Se puede cuantificarse utilizando el índice
de variación, que se computadas como la relación entre la
desviación estándar y la media. Cuanto menor sea el índice,
más fiables serán los resultados de la medición.
Validez se refiere a si el método de medición mide
realmente lo que pretendemos medi- seguro. Validez de un
método de medición puede ser visto desde tres perspectivas
diferentes: a saber, la validez de constructo, validez criterios,
y validez de contenido.
3.4. Fiabilidad evaluar 
[4 *, c3s5]
Hay varios métodos para evaluar su 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]
los costos del ciclo de vida del producto están muy influenciados por el
diseño del producto. Esto es cierto para los productos manufacturados, así
como para productos de software.
El diseño de un producto de software es guiada por las
características que deben incluirse y los atri- buye calidad que deben
presentar. Es importante tener en cuenta que los ingenieros de
software usan el término “diseño” en su propio contexto; si bien hay
algunas lidades de common, también hay muchas diferencias entre
el diseño de ingeniería como se explica en esta sección y software
de diseño de ingeniería como se discutió en el software de diseño
KA. El alcance del diseño de inge- niería es generalmente visto como
mucho más amplio que el de diseño de software. El objetivo principal
desarrollar una comprensión clara con respecto a la pro- ceso de
diseño de ingeniería.
Muchas disciplinas participan en la solución de problemas
actividades donde hay una única solu- ción correcta. En ingeniería, la
mayoría de los problemas tienen muchas soluciones y la atención se
centra en la búsqueda de una solución factible (entre las muchas
alternativas) que mejor se adapte a las necesidades planteadas. El
conjunto de soluciones po- sible es a menudo limitada por explic-
limitaciones impuestas tamente como el coste, recursos disponibles, y
el estado de la disciplina o el dominio del conocimiento. En los
problemas de ingeniería, a veces también hay limitaciones implícitas
(como las propiedades físicas de los materiales o las leyes de ics
phys-) que también restringen el conjunto de soluciones factibles para
un problema dado.
4.1. Diseño de ingeniería en la 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 soluciones de
ingeniería, proble- blemas indefinidos complejas y diseñar
sistemas, componentes o procesos que satisfagan las
necesidades especificadas con la debida atención a los
riesgos de salud y seguridad, las normas aplicables, y
con económico, ambiental, cultural y social -
consideraciones. [8, p12]
De una manera similar, ABET define el diseño de ingeniería como
el proceso de elaboración de un sistema, compo- nente 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
una malvados problema -un 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 proble- mas abordados por
los diseñadores son proble- mas 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 implica, esencialmente, de que un problema complejo
tiene que ser resuelto de una vez con el fin de definir con claridad y luego
resuelve de nuevo para crear una solución que funcione. Esta ha sido una
idea importante para los diseñadores de los programas durante varias
décadas [10 *, c5s1].
Fundamentos de Ingeniería 15-9
4.3. Pasos a seguir en Ingeniería de Diseño [ 7 *, c4]
la resolución de problemas de ingeniería 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) aplicar 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.
segundo. Recopilar información pertinente. En esta etapa, el
diseñador intenta ampliar su / su El conocimiento sobre el problema.
Esta es una etapa vital, ya menudo no. La recopilación de
información pertinente puede revelar hechos que conducen a una
redefinición de la
15-10 Guía SWEBOK® V3.0
problemas, en particular, los errores y las salidas en falso puede ser
identificado. Este paso puede implicar también la descomposición del
problema en subproblemas más pequeños y más fáciles de resolver.
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.
do. Generar múltiples soluciones. Durante esta etapa, las
diferentes soluciones al mismo problema son de- sarrollados. Ya
se ha indicado que el diseño proble- blemas tienen múltiples
soluciones. El objetivo de este paso es conceptualizar múltiples
solu- ciones posibles y refinar a un nivel de detalle suficiente que
la comparación puede hacerse entre ellos.
re. 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.
mi. 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
llama una prototyp E puede ser de- sarrollados inicialmente para
poner a prueba el diseño propuesto solu- ción bajo ciertas
condiciones. Comentarios como resultado de la prueba de un
prototipo puede ser utilizado ya sea para
refinar el diseño o conducir a la selección de una solución de diseño
alter- nativa. Una de las actividades más impor- tantes en el diseño
es la documentación de la solución de diseño, así 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 proto- tipo
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
físicos, tales como un dibujo CAD de un diente o un modelo
matemático para un proceso. Los modelos ayudan a los ingenieros a
entender la razón y los aspectos de

un problema. También pueden ayudar a los ingenieros Deben
conocerse lo que saben y lo que no saben sobre el problema en
cuestión.
Hay tres tipos de modelos: icónicas, la lógica ana- y simbólica.
Un modelo icónico es un 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 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  ser en realidad la primera versión totalmente funcional de un
Todos los modelos de simulación son una especificación de la reali-
dad. 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 este tipo incluyen
entidades, actividades y eventos, recursos, el estado del sistema,
un reloj de simulación, y un generador de números aleatorios. De
salida es generada por la simulación y debe ser analizada.
Fundamentos de Ingeniería 15-11
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
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.
15-12 Guía SWEBOK® V3.0
6. Normas
[5 *, c9s3.2] [13 *, c1s2]
Moore afirma que una
estándar puede ser; (A) un objeto o medida de
comparación que define o 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, estable-
cido 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, pro- cesos 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 organiza- ciones 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 Normalización (ISO)
reconocidas internacionalmente. Además, hay
regional y gubernamental reconocida organiza- ciones que
generan estándares para esa región o país. Por ejemplo, en los
Estados Unidos, hay más de 300 organizaciones que
desarrollan Standards. Estos incluyen organizaciones como el
American National 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 los EE.UU. . 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.
Análisis Causa Raíz 7.
[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 evento no deseable. Por lo
tanto, cuanto más 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. UN forma común para identificar causa subyacente específica
(s) es preguntar a una serie de por qué preguntas.
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 subfactores y
sub-subfactores hasta causas fundamentales pueden ser identificados.
Fundamentos de Ingeniería 15-13
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
par- cialmente completados.
Por último, los 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. Análisis del árbol de fallos es una técnica que puede usarse
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. Varios tipos de análisis de correlación se pueden utilizar
para comprender la relación entre diversas causas y su
impacto. 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).
15-14 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

[10 *] Cheney y
Montgomery y Runger 2007
[2 *] nulo y

[6 *] Tockey
[4 *] Voland

[5 *] Fairley

[12 *] Moore
[3 *] Kan

Sommerville 2011
McConnell 2004

[11 *]

[13 *]
[7 *]
Lobur 2006

2002

Kincaid 2007

2006
2009
2003

2004
1. Métodos
empíricos y
c1
técnicas
experimentales
1.1. experimento
diseñado

1.2.
Estudio
observacional

1.3.
Estudio
retrospectivo

2. Análisis c9s1, c10s3

C2S1
estadístico

c3s6,
c3s9,
2.1. Concepto de
c4s6,
unidad de análisis
c6s2,
(unidades de
c7s1,
muestreo), Muestra y
c7s3,
población
c8s1,
c9s1

2.2. Conceptos de
c11s2,
correlación y
c11s8
regresión

c3s1, c4s4
3. Medición c3s2 c7s5

3.1. Niveles
(Scales) de c3s2 P442 c7s5
- 447
Medición
3.2. Medidas
directos y
derivados
 Fundamentos de Ingeniería 15-15

[10 *] Cheney y
Montgomery y Runger 2007
[2 *] nulo y

[6 *] Tockey
[4 *] Voland

[5 *] Fairley

[12 *] Moore
[3 *] Kan

Sommerville 2011
McConnell 2004

[11 *]

[13 *]
[7 *]
Lobur 2006

2002

Kincaid 2007

2006
2009
2003

2004
3.3. Fiabilidad y c3s4,
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 diseño como c1s4,

Solución de problemas C2S1, c5s1
Actividad c3s3

4.3. Pasos a
seguir en Diseño
c4
de Ingeniería

5. Modelado, creación de
S3.1
prototipos y simulación c6 c13s3
c2

5.1. Modelado

5.2. Simulación

5.3. prototipado

S3.2
6. Normas c1s2
c9

c5, c9s3,
Análisis Causa s3.4.5
c3s7, c9s4,
Raíz 7. c13
c9s8 c9s5

7.1. Las técnicas para

la realización de
c5 c3
análisis de causa raíz
15-16 Guía SWEBOK® V3.0

LECTURAS

A. Abran, Las métricas de software y software  WG Vincenti, Lo que los ingenieros saber y cómo 
Metrología. [ 14] Ellos lo saben. [ 15]

Este libro ofrece muy buena información sobre el uso correcto Este libro ofrece una introducción interesante para bases de
de la medida de términos, método de medición y los resultados ingeniería a través de una serie de estudios de casos que muestran
de medición. Proporciona material de soporte fuerte para toda muchos de los conceptos fundacionales que se utiliza en
la sección sobre la medición. aplicaciones de ingeniería del mundo real.
 Fundamentos de Ingeniería 15-17

Referencias

[1] ISO / IEC / IEEE 24765: 2010 Sistemas y  [9] ABET Ingeniería Acreditación
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE Comisión, “Criterios para la Acreditación de Programas
2010. de Ingeniería, 2012-2013”, ABET, 2011; www.abet.org/uploadedFiles/
Acreditación / Accreditation_Process /
[2 *] DC Montgomery y GC Runger, Accreditation_Documents / Corriente / eac-
Aplicada Estadística y Probabilidad para criterios-2012-2013.pdf .
Ingenieros, 4ª ed., Wiley, 2007.

[3 *] L. Null y J. Lobur, Lo Esencial de la  [10 *] S. McConnell, Código completo, 2ª ed.,

Organización ordenador y Arquitectura, Microsoft Press, 2004.
2ª ed., Jones and Bartlett Publishers,
2006. [11 *] EW Cheney y DR Kincaid, Numérico 
Matemáticas y Computación, 6ª ed., Brooks /
[4 *] SH Kan, Métricas y modelos de software  Cole, 2007.
Ingeniería de calidad, 2ª ed., Addison-Wesley,
2002. [12 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[5 *] G. Voland, Ingeniería de Diseño, 2ª ed.,
Prentice Hall, 2003. [13 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
[6 *] RE Fairley, La gestión y líder  Wiley-IEEE Computer Society Press, 2006.
Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009. [14] A. Abran, Las métricas de software y software 
Metrología, Wiley-IEEE Computer Society Press, 2010.
[7 *] S. Tockey, Retorno de software: Maximizar 
el retorno de su inversión en software,
Addison-Wesley, 2004. [15] WG Vincenti, Saber lo que los ingenieros 
y cómo ellos lo saben, John Hopkins University
[8] Consejo de Acreditación de Ingeniería de Canadá, Press, 1990.
Los ingenieros de Canadá, “Criterios de Acreditación y
Procedimientos”, Consejo Canadiense de Ingenieros,
2011; www. Criteria_Procedures_2011.pdf
engineerscanada.ca/files/w_Accreditation_ .
 APÉNDICE A
ÁREA DE CONOCIMIENTO DESCRIPCIÓN
PRESUPUESTO
INTRODUCCIÓN
En este documento se exponen las características 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 el 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
los 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. los Guía SWEBOK TambiénDebido a la naturaleza estructural de la Guía SWEBOK y su
es más ampliamente reconocido como un documento fundamental
dentro de la comunidad de ingeniería de software en
A-1
grande en particular mediante el reconocimiento oficial de la
versión 2004 como Informe Técnico ISO / IEC 19759: 2005. Se
describe la lista de áreas de conocimiento (KAs) y la ruptura de
los temas dentro de cada KA y detallada en la introducción de
esta
Guía SWEBOK.
En consecuencia, la Guía SWEBOK es fundacional a otras
iniciativas dentro de la Sociedad IEEE Com- puter:
a) La lista de Kas, y la ruptura de los temas dentro de cada
KA también son adoptados por la certificación de la
ingeniería de soft- ware y productos asociados de
desarrollo profesional ofrecidos por la IEEE Computer
Society (ver www. computer.org/certification ).
b) La lista de Kas, y la ruptura de ics Top- también son
fundamentales para las pautas de los planes de estudio de
ingeniería de software desarrollado o avalados por la IEEE
Computer Society ( Los planes de estudio
www.computer.org/portal/web/education/ ).
c) La lista de referencias consolidado (ver Appen- Dix C), es
decir, la lista de materiales de referencia recomendados
(a nivel de número de sección) que acompaña a la ruptura
de los temas dentro de cada KA también es adoptada por
la certificación de ingeniería de software y aso- ciados
productos de desarrollo profesional ofrecidos por la IEEE
Computer Society.
Línea de base y JUNTA DE CONTROL DE CAMBIO
adopción por otros productos, una línea de base fue desarrollado
desde el principio del proyecto formó parte de la lista de Kas, en
el desglose de
A-2 Guía SWEBOK® V3.0
temas dentro de cada KA, y la Lista consolidada rencia Ref-.
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 el Guía SWEBOK Editores y por el CCB antes de ser
implementados. 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 detalle 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 indus- tria y en la literatura y
las normas de ingeniería de software.
) Se espera que el desglose de los temas g 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
conocimiento, que son también una parte integral de todo el
conocimiento
Las áreas y, por tanto, deben ser incorporados en la
propuesta de reparto de los temas de cada área de
conocimiento. Estos temas comunes son la medición, la
calidad (en gene- ral), 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.
nombres j) Tema deben ser lo suficientemente significativo para ser
significativa incluso cuando citado fuera de la
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 mate- rial 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) asigna- do a su KA por la
Lista consolidada de referen- cia como sus referencias
recomendadas.
b) Hay tres categorías de material de referencia:
» Referencias recomendadas. El conjunto de referencias
recomendadas (a nivel de número de sección) se
conoce colectivamente como la lista de referencia
consolidado.
» LECTURAS ADICIONALES.
» 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 argumento particular).

c) La Guía SWEBOK se pretende por definición ser selectivo
en su elección de los temas y material de referencia
asociado. La lista de material de referencia debe ser
claramente vista como una “selección informada y
razonable” y no como una lista definitiva.
d) El material de referencia puede ser capítulos de libros, artículos
en revistas arbitradas, artículos técnicos referenciados confe-
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) El 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) Los criterios y requisitos para el material de referencia
recomendada o la lista de referen- cia consolidada:
» Colectivamente la lista de referencias debe ser
recomendados
yo. completar: cubre todo el alcance de la Guía
SWEBOK
ii. suficiente: proporcionando suficiente
información para describir “generalmente
aceptadas” 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 recomendada debe ser identificado
para cada tema. Cada elemento de referencia recomiendan
especialmente puede cubrir por supuesto múltiples temas.
Excepcionalmente, un tema puede ser auto-descriptivo y no
cita un artículo de material de referencia (por ejemplo, un
tema que es una definición o una materia competencia de la
descripción misma sin ningún
Apéndice A A-3
material de referencia citado es suficiente para los
objetivos de la Guía SWEBOK).
» Cada referencia al material de referencia recomendada
debe 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 (al nivel de número
de sección) versus temas debe ser proporcionada.
» Una cantidad razonable de material de referencia
recomendado debe ser identificado para cada KA.
Las siguientes pautas deben ser utilizados en la
determinación de cuánto es razonable:
yo. 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 recomendado 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
completar cuatro años de experiencia
laboral.
h) adicional material de referencia puede ser
incluido por el Editor de KA en una lista “Otras
lecturas”:
A-4 Guía SWEBOK® V3.0
» Estas lecturas adicionales deben estar relacionados con los
temas de la descomposición en lugar de, por ejemplo, a
temas más avanzados.
» La lista debe ser anotado (a menos de 1 párrafo por
referencia) de por qué este material de referencia se
incluyó en la lista de lecturas adicionales. Lecturas
adicionales podrían incluir: nuevas versiones de una
referencia existen- tes 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 más 10 o
menos lecturas por KA.
» No hay matriz de los materiales de referencia que
figuran en lecturas adicionales y la ruptura de
temas.
i) Los criterios y requisitos con respecto adi- cionales
referencias citadas en el KA Descripción:
» los 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 estructura:
• acrónimos
• Introducción
• Desglose de los temas de la KA (incluyendo una figura que
describe la descomposición)
• Matriz de Temas vs. Material de Referencia
• Lista de lecturas recomendadas
• referencias
¿QUÉ SIGNIFICA “GENERALMENTE RECONOCIDAS
DE CONOCIMIENTO”?
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, el 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 para la Dirección de
Proyectos del Conocimiento
define el conocimiento “generalmente reconocido” para 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 en general”, pero
hoy y lo que esperan será “generalmente reconocido” en un plazo
de 3 a 5 años .
 Apéndice A A-5

Prácticas especializado que Generalmente reconocido y comités de normas de sistemas de ingeniería. También se ha
se utiliza sólo para ciertos tipos de Establecidas ticas ticas tradicionales designado como norma fundamental por el Comité de software y
recomendadas por muchos sistema de ingeniería Normaliza- ción (S2ESC) de la IEEE. A pesar
organizaciones de que no tenemos la intención de que el Guía de la Ingeniería de

Avanzada e Investigación Software de Administración de Conocimiento sea ​plenamente

prácticas innovadoras probados y utilizados 12207-conformant, este estándar sigue siendo una entrada de

solamente por algunas organiza- ciones y tecla a la Guía SWEBOK, y especial se tendrá cuidado en todo el Guía

conceptos todavía siendo desarrolladas y SWEBOK

software

probadas en

organizaciones de investigación en cuanto a la compatibilidad de la Guía con la norma

12207.
La figura A.1. Categorías de Conocimiento

3. JW Moore, La hoja de ruta de software 

Ingeniería: Una guía basada en estándares,
LONGITUD DE KA DESCRIPCIÓN Wiley-IEEE Computer Society Press, 2006. [4 *]

Las descripciones son KA ser aproximadamente de 10 a 20 páginas

utilizando la plantilla de formato para documentos de publi- cado aún Este libro describe el alcance, funciones, usos y tendencias de
en actas de la conferencia de la IEEE Computer Society. Esto desarrollo de las normas de ingeniería de soft- ware más
incluye texto, las referencias, apéndices, tablas, etc. Esto, por ampliamente utilizados. Se concentra en las actividades
supuesto, no incluye los materiales de referencia mismos. importantes-cali- dad 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
DOCUMENTOS RELACIONADOS IMPORTANTE al lector a las relaciones clave entre las normas. A pesar de Guía
SWEBOK no es un estándar de ingeniería de soft- ware per se,
1. Graduado de Ingeniería de Software 2009  la atención especial se tendrá en todo el documento con
(GSwE2009): Directrices Curriculares para programas respecto a la compatibilidad de la Guía con el estándar IEEE
de postgrado en Ingeniería de Software, 2009; www.gswe2009.org
actual y Sistemas ISO / IEC y software Inge- niería Normas
. [2] Colección.

Este documento “Proporciona directrices y recomenda- ciones”

para definir el plan de estudios del programa de nivel de
maestría profesional en ingeniería de software. los Guía 4. Ingeniería de Software 2004: Plan de estudios 
SWEBOK se identifica como una “referencia primaria” en el Directrices para los programas de grado Grado en
desarrollo del conjunto de conocimientos que subyace a estas Ingeniería de Software, IEEE Computer Society y la
directrices. Este documento ha sido aprobado oficialmente por el Association for Computing Machinery, 2004; http: //
IEEE Computer Society y patrocinada por la Association for sites. computer.org/ccse/SE2004Volume.pdf . [5]
Computing Machinery.

Este documento describe las directrices del plan de estudios

2. IEEE Std. 12207-2008 (también conocido como ISO / IEC  para una licenciatura en ingeniería de software. los Guía
12207: 2008) Estándar de Sistemas y Software de SWEBOK se identifica como “una de las fuentes primarias” en el
Ingeniería de Software-procesos de ciclo de vida, IEEE desarrollo del conjunto de conocimientos que subyace a estas
2008 [3]. directrices.

Esta norma se considera el estándar clave en cuanto a la 5. ISO / IEC / IEEE 24765: 2010 Sistemas y 
definición de procesos de ciclo de vida y ha sido adoptado por los Ingeniería de Software-Vocabulario, ISO / IEC / IEEE,
dos principales organismos de normalización en la ingeniería de 2010; www.computer.org/ sevocab . [6]
software: ISO / IEC JTC 1 / SC7 y la Sociedad IEEE Computer
Software
A-6 Guía SWEBOK® V3.0
La jerarquía de referencias para la terminología es
Diccionario de la Real Academia Webster ( 11 ed.) [7], IEEE / ISO
/ IEC 24765 [6], y el nuevo pro- puesto definiciones si es
necesario.
6. “Certificación y Capacitación para Profesionales de
software,” IEEE Computer Society, 2013; www.computer.org/certification
significan. Para asegurarse de que alguna información en el
. [8]
Información sobre la certificación y productos de desarrollo
profesional asociados desarrollados y ofrecidos por la IEEE
Computer Society para los profesionales en el campo de la
ingeniería de software se puede encontrar en este sitio web. los Guía
SWEBOK es fundamental para estos productos.
Estilo y las Directrices Técnicas
• Las descripciones KA deben ajustarse a la plantilla de
Word disponible en www.computer. org / portal / web /
cscps / formato .
• Se espera Descripción KA seguir la guía de estilo
IEEE Computer Society ( www. Styleguide
computer.org/portal/web/publications/ ).
• Los archivos deben ser presentadas en formato Microsoft Word.
• Todas las citas de material de referencia han de ser producido
utilizando EndNote Web como se indica en las instrucciones
proporcionadas a los editores KA en este sentido.
OTROS directrices detalladas
Al hacer referencia a la Guía de la Ingeniería de Software de
Administración de Conocimiento, utilizar el título “ Guía SWEBOK. ”
A los efectos de simplicidad, evitar las notas al pie y tratar de incluir su
contenido en el texto principal. Utilizar referencias explícitas a las normas,
a diferencia de los números que hacen referencia a los elementos de la
simple inserción
la bibliografía. Creemos que este enfoque permite al lector a
ser mejor expuesta a la fuente y el alcance de una norma.
Las figuras y tablas que se acompañan de texto deben
explicarse por sí mismo o tener suficiente texto relacionado.
Esto garantizaría que el lector sabe lo que las figuras y tablas
Guía SWEBOK no se convierta rápidamente lete obso- y debido a su
carácter genérico, por favor, evitar directamente las herramientas y los
productos de denominación. En su lugar, tratar de nombrar sus funciones.
EDICIÓN
Editores de la Guía SWEBOK sionales, así como correctores
sionales editarán Descripción KA. La edición incluye edición
de textos (gramática, tuation pun-, y las mayúsculas), edición
de estilo (confor- Mance el libro de estilo Computer Society), y
la edición de contenidos (flujo, es decir, la claridad, Ness
directa-, y la organización). La edición final será un proceso de
colaboración en el que los editores de la Guía SWEBOK y los
editores KA trabajan juntos para lograr una concisa, bien
redactado-y útil KA Descripción.
DIVULGACIÓN DE AUTOR
Todos los derechos de propiedad intelectual relacionados con el Guía
SWEBOK permanecerá con la IEEE. Editores KA deben firmar un
formulario de autorización de derechos de autor. También se entiende
que la Guía SWEBOK
seguirá siendo disponible de forma gratuita en el dominio público
en al menos un formato, proporcionado por la IEEE Computer
Society través de la web tecnolo- gía o por otros medios. Para
más información, ver www.computer.org/ copyright.htm .
 Apéndice A A-7

Referencias

[1] Instituto de Gestión de Proyectos, Una guía para la  [5] Grupo de Trabajo Conjunto sobre Computación planes de estudio,

Guía de los fundamentos de gestión de proyectos
(PMBOK (R) Guía), 5ª ed., Project Management
Institute, 2013.
[2] Software y Sistemas Integrados
Plan de estudios de ingeniería (ISSEC) Proyecto,
Graduado de Ingeniería de Software 2009
(GSwE2009): Directrices Curriculares para programas
de postgrado en Ingeniería de Software, Stevens
Institute of Technology, 2009; www.gswe2009.org .
IEEE Computer Society y la Association for Computing
Machinery, Ingeniería de Software 2004: Directrices
Curriculares para Pregrado Programas de Grado en
Ingeniería de Software, 2004; http: // sites.
computer.org/ccse/SE2004Volume.pdf .
[6] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.

[7] Diccionario Colegiado de Merriam-Webster,

[3] IEEE Std. 12207-2008 (también conocido como ISO / IEC  ed 11., 2003.
12207: 2008) estándar para los sistemas y procesos de ciclo
de vida del software Ingeniería de Software, IEEE 2008. [8] IEEE Computer Society, “Certificación y
Formación de los profesionales de software,”2013;
www.computer.org/certification .
[4 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
Wiley-IEEE Computer Society Press, 2006.
 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 normas niería de
software niería supera con creces la demanda. Rara vez se
escucha una conferencia sobre el tema sin sufrir alguna 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. Para 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 organiza- ciones, 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 bases de datos . Como
cualquier base de datos, estos contienen a veces errores,
sobre todo para los títulos. Así que este artículo menudo
parafraseará la
B-1
título de la norma o simplemente utilizar su número. En la
obtención de un nivel de interés, el lector debe basarse en el
número, no el título, dada en este artículo. Por razones de
coherencia, el artículo va a utilizar la convención del IEEE
para la capitalización de títulos sustantivos, pronombres,
adjetivos, verbos, adverbios y primera y última palabra tiene
una letra, a pesar de capital inicial el hecho de que IEEE e
ISO / IEC uso diferente convenciones.
• Debido a que estas normas están siendo aliado continua-
revisarse para tener en cuenta las nuevas tecnolo- gías y
patrones de uso, este artículo será obsoleta antes de su
publicación. Por lo tanto, de vez en cuando discuten las
normas que aún no han sido publicados, si existe la
posibilidad de asumir una importancia significativa.
• marcas explícitas se omiten. Baste decir que el IEEE
coloca una marca en todas sus denominaciones
normalizadores.
Hay algunos otros convenios de interés:
• En tanto IEEE e ISO / IEC, las normas para
sistemas ingeniería son mantenidos por el mismo comité
que para software Ingenieria. Muchas de las normas se
aplican a ambos. Así, en lugar de hacer distinciones
sutiles, este artículo va a tratar con ambos.
• Por otro lado, tanto S2ESC y SC 7 (ver más abajo para
una descripción de estas organiza- ciones) son
responsables de las normas que no califican como
“ingeniería”. En los EE.UU. y muchos otros países, los
servicios de un ingeniero con licencia son requiere cuando
un producto puede afectar a la seguridad pública, la salud,
B-2 Guía SWEBOK® V3.0
y el bienestar en lugar de afectar únicamente el bolsillo
del cliente. En este apéndice se respetará esa
distinción e ignorar Standards que parecen ser
meramente económica en consecuencia.
• documentación del usuario se supone que es de- sarrollados 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 ción estándar adopció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 organiza- ciones,
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 (JTC 1) es un niño de la Organización
Internacional para la estandarización (ISO) y la Comisión
Electrotécnica Internacional (IEC); tiene el alcance de la
“tecnología de informa- ción” y subdivida su trabajo entre
varios subcomités; Subcomité 7 (SC
7) es el responsable de software y siste- mas 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 partici- pantes. Cada país sigue su
propio procedi- mientos 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): docu- mentos 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 orde- nador. 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 Carolina del Sur 7.

IEEE-SA publica tres tipos de “normas”:
• Normas, con una preponderancia del verbo “deberá”
• Métodos recomendados, con una preponderancia del
verbo “debería”
• Guías, con una preponderancia de la palabra “podrá”.
Los tres de estos comparan con Dardos ISO / IEC Están-.
IEEE-SA tiene el concepto de un “uso juicio-” estándar, que es más
o menos comparable a la norma ISO / IEC Especificación Técnica.
Sin embargo, no tiene nada comparable a un Informe de cal ISO /
IEC Técnicamente; se buscaría en otro lugar IEEE para los
documentos de esta calaña.
LOS ESTANDARES
El resto de este artículo asigna los estándares seleccionados a áreas
de conocimiento relevantes (KAS) de la Guía SWEBOK. Hay una
sección para cada KA. Dentro de cada sección, las normas
pertinentes son los que se aplican principalmente a la KA, así como
otros que se aplica principalmente a otra KAs sino que también
están relacionados con el alquiler de un Cur- los enumerados.
Después de cada estándar es un breve resu- men. En la mayoría de
los casos, el resumen es una cita o paráfrasis del material
introductorio abstracto o otra del texto de la norma. La mayor parte
de las normas caber fácilmente en un solo KA. Algunos encajan en
más de uno; en tales casos, se proporciona una referencia cruzada.
Dos normas se aplican a todos los Kas, por lo que se enumeran en
una categoría denominada “General”. Todas las normas
relacionadas con la ingeniería de software asistida por ordenador
herramientas y entornos (CASE) se enumeran en los modelos de
ingeniería de software y métodos sección KA.
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
descripciones de varias otras normas se refieren a ellos. ISO
/ IEC TR 19759 es la Guía SWEBOK
sí mismo. No es un estándar IEEE porque, a falta de verbos
prescriptivos, que no satisface los criterios
Apéndice B B-3
para cualquiera de las categorías del IEEE. En la norma ISO / IEC, se trata
de un “informe técnico” -definido como un documento inherentemente
inadecuado para ser un estándar. El IEEE 2004
Guía SWEBOK fue adoptado por la norma ISO / IEC con- cabo el
cambio. Presumiblemente, ISO / IEC adoptará Ver- sion 3 de la Guía
SWEBOK.
ISO / IEC TR 19759: 2005 Software Ingeniería-
Guía de la Ingeniería de Software de Administración de Conocimiento
(SWEBOK)
Se aplica a todos los KAs
ISO / IEC 19759: 2005, una Guía de la Ingeniería de Software de
Administración de Conocimiento (SWEBOK),
identifica y describe ese subconjunto del conjunto de conocimientos
que es generalmente aceptado, a pesar de que los ingenieros de
software deben ser capaces no sólo de conocimientos en ingeniería
de software, sino también, por supuesto, en otras disciplinas
relacionadas. SWEBOK es un término inclusivo que describe la suma
de conocimientos dentro de la profesión de la ingeniería de software.
El texto de la Guía SWEBOK es de libre dispo- capaz en www.swebok.org/
. La adopción de ISO / IEC de la Guía está disponible gratuitamente
en http: // estándares. iso.org/ittf/PubliclyAvailableStandards/index.
html .
ISO / IEC / IEEE 24765 proporciona una ulary vocab- compartido
para los sistemas y normas de ingeniería de software, tanto de SC 7
y S2ESC.
ISO / IEC / IEEE 24765: 2010 Sistemas y de 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
B-4 Guía SWEBOK® V3.0
estándares de código activos para cada definición de manera que el uso
del término se puede explorar más.
El vocabulario es descriptiva, en lugar de prescriptivo; que
recoge todas las definiciones de todas las normas pertinentes,
así como algunas otras fuentes, en lugar de elegir entre las
definiciones que compiten entre sí.
El contenido de la norma 24765 es de libre acceso en línea
en www.computer.org/sevocab . Dos estándares, 12207 y
15288, proporcionan un conjunto completo de procesos de todo
el ciclo de vida de un sistema o de un producto de software.
Los dos Standards están alineadas para su uso simultáneo en
un solo proyecto o en una sola organización. Se mencionan
aquí porque se utilizan a menudo como un marco para explicar
o localizar el papel de otras normas en el ciclo de vida.
IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008)
estándar para los sistemas y software Ingeniería- Software Procesos del
ciclo de vida
Consulte Software Ingeniería de Procesos KA
IEEE Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008)
estándar para los sistemas y S oftware Ingeniería- Sistema de Vida los
procesos de ciclo
Consulte Software Ingeniería de Procesos KA
REQUISITOS DE SOFTWARE
La norma principal para la ingeniería de requisitos de software y
sistemas es una nueva que sustituye varios estándares IEEE
existentes. Se pro- porciona una visión amplia de la ingeniería de
requisitos a través de todo el ciclo de vida.
/ IEC / IEEE 29148 ISO: 2011 Sistemas y de Ingeniería de
Software-Life Cycle procesos de Ingeniería de Requisitos
ISO / IEC / IEEE 29148: 2011 contiene disposiciones para los
procesos y los productos relacionados con la inge- niería de
requisitos para los sistemas y productos de software y servicios a lo
largo del ciclo de vida.
Se define la construcción de un buen requisito, proporciona
atributos y características de los requisitos, y discute la aplicación
iterativa y recursiva de los procesos de requisitos pasantes a cabo
el ciclo de vida. ISO / IEC / IEEE 29148: 2011 proporciona
orientación adicional en la aplicación de los procesos de requisitos
de ingeniería y gestión de las actividades de los requisitos
relacionados en la norma ISO / IEC 12207: 2008 e ISO / IEC
15288: 2008. Los elementos de información aplicables a la
ingeniería de requisitos y su contenido están definidos. El contenido
de la norma ISO / IEC / IEEE 29148: 2011 puede ser añadido al
conjunto existente de los procesos del ciclo de vida relacionada
REQUISITOS definidos por la norma ISO / IEC 12207: 2008 o ISO /
IEC 15288: 2008, o puede ser utilizado de forma independiente.
Una norma ISO / IEC multiparte proporciona prin- cipios y métodos
para el software “dimensionamiento” en base a sus requerimientos. El
tamaño funcional es a menudo uso-ful en el denominador de las
mediciones de cali- dad y la productividad en el desarrollo de software.
También puede desempeñar un papel en la contratación de los acuerdos
de nivel de servicio.
ISO / IEC 14143 [seis partes] Medición-funcional
Tecnología de la Información-Software tamaño
Medición
ISO / IEC 14143 describe FSM (medida del tamaño funcional). Los
conceptos de medición de tamaño funcional (FSM) se han diseñado
para superar las limitaciones de los métodos anteriores de software
de dimensionamiento desplazando el foco lejos de medir cómo el
software se implementa para medir el tamaño en términos de las
funciones requeridas por el usuario.
FSM es a menudo conocido como “punto de la función de cuenta.”
Las cuatro normas que figuran a continuación son métodos alternativas
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

sobre todo destinados a ser utilizados en el software con un componente
en tiempo real.
ISO / IEC 19761: 2011 Ingeniería de Software-CÓSMICO: Un
Tamaño Funcional Método de medición
ISO / IEC 20926: 2009 Software e Ingeniería de
Sistemas-Software-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
Función de conteo de Ingeniería de Software-MK II
ISO / IEC 24570: 2005 Software Ingeniería- NESMA funcional
tamaño de la medida Método Versión 2.1-Definiciones y
Lineamientos contando para la Aplicación del Análisis de
Puntos de Función
A veces requisitos se describen en lenguaje natu- ral, pero a
veces se describen en las notaciones formales o semiformales.
El objetivo de Unified Modeling Language (UML) es proporcionar
a los arquitectos de sistemas, ingenieros de software y
desarrolladores de software con herramientas para el análisis,
diseño e implementación de sistemas basados ​en software, así
como para el modelado de negocios y procesos similares. Las
dos partes de la norma 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 se utilizan para modelar los
requisitos.
ISO / IEC 19501: 2005 Tecnología de la Información -
Procesamiento distribuido abierto - Unified Modeling Language
(UML) Versión 1.4.2
Ver Modelos de Ingeniería de Software y
métodos KA
ISO / IEC 19505: 2012 [dos partes] Tecnología de la Información - Object
Management Group Unified Modeling Language (UML del OMG)
Ver Modelos de Ingeniería de Software y
métodos KA
Apéndice B B-5
DISEÑO DE SOFTWARE
El diseño de software KA incluye tanto el diseño de software de
arquitectura (para la determinación de los barcos PARENTESCO Entre
los elementos de software y diseño detallado (para la descripción de
los elementos individuales). ISO / IEC / IEEE 42010 se refiere a la
descripción de la arquitectura de sistemas y software.
ISO / IEC / IEEE 42010: 2011 Sistemas e Ingeniería de Software - Arquitectu
Descripción
ISO / IEC / IEEE 42010: 2011 se refiere a la crea- ción, el análisis, y el
mantenimiento de arquitecturas de sistemas mediante el uso de las
descripciones de la arquitectura. Se establece un modelo conceptual
de la descripción de la arquitectura. Los contenidos requeridos de una
descripción de la arquitectura se especifican. puntos de vista arqui-
tectura, los marcos de arquitectura y descripción de la arquitectura
idiomas se introducen para la codificación de convenciones y
prácticas comunes de la descripción de la arquitectura. El contenido
requerido de puntos de vista de la arquitectura, la arquitectura marco
funciona y descripción de la arquitectura idiomas se especifica.
Anexos proporcionan la motivación y los antecedentes de los
principales conceptos y terminología gía y ejemplos de aplicación de
la norma ISO / IEC / IEEE 42010: 2011.
Al igual que la norma ISO / IEC / IEEE 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 en la descripción del diseño, en lugar de en el
diseño en sí.
IEEE Std. 1016-2009 estándar para la Tecnología de la Información - Diseño
de sistemas - Las descripciones de 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
B-6 Guía SWEBOK® V3.0
grupos de interés. Esta norma está destinada para su uso en
situaciones de cálculo en la que una descripción explícita de diseño
de software es estar preparado. Estas situaciones incluyen
actividades tradicionales de construcción de software (cuando el
diseño conduce a código) y situaciones de ingeniería inversa (cuando
una descripción del diseño se recupera de una implementación
existente). Esta norma se puede aplicar a, cien- cien- comercial,
militar o el software que se ejecuta en los ordenadores digitales.
Aplicabilidad no está limitado por el tamaño, la complejidad o
criticidad del software. Esta norma puede ser aplicado a la
descripción de alto nivel y diseños detallados. Este Dard Están- no
prescribe metodologías específicas para el diseño, gestión de la
configuración, o la garantía de cali- dad. Esta norma no requiere el
uso de cualquier lenguaje de diseño particulares, pero esta- lishes
requisitos en la selección de lenguajes de diseño para su uso en un
SDD. Esta norma se puede aplicar a la preparación de los agentes
de valores capturados como documentos en papel, bases de datos
automatizadas, herramientas de desarrollo de software, u otros
medios de comunicación.
Por convención, este apéndice trata usuario docu- mentación como
parte de un sistema de software. Por lo tanto, los diversos aspectos de
usuario Documentación- su diseño, su prueba, y así sucesivamente-se
asignan a diferentes KAs. La siguiente norma se ocupa del diseño de
la documentación del usuario.
IEEE Std. 26514-2010 La adopción del estándar ISO / IEC 26514: 2008
Sistemas e Ingeniería de Software - Requisitos para los diseñadores y
desarrolladores de documentación del usuario
Esta norma establece los requisitos para el diseño y desarrollo de
software de usuario docu- 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 usuario y también proporciona una guía
informativa para el estilo de documentación del usuario. Es
independiente de las herramientas de software que pueden ser
utilizados para producir la documentación y se aplica tanto a la
documentación impresa y la documentación en pantalla. Gran parte
de esta
norma es aplicable a la documentación del usuario para los sistemas de
hardware incluyendo también.
CONSTRUCCIÓN DEL SOFTWARE
El término “construcción de software” se refiere a la creación detallada
de software de trabajo, significativa 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. Hay pocas normas sobre los detalles de la
codificación de soft- ware. Se ha encontrado a través de (en su mayoría
mala) experiencia de que las convenciones de codificación no son
apropiados para la estandarización, ya que, en la mayoría de los casos,
el beneficio real viene de la consistencia de la aplicación de una
convención arbitraria en lugar de la propia convención. Así, a pesar de
las convenciones de codificación son una buena idea, en general se
deja a la organización o el proyecto para desarrollar un estándar tales.
Sin embargo, el tema de la codificación segura 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 técnico
preparado por la norma ISO / IEC JTC 1 / SC 22 (lenguajes de
programación) describe nerabilities vul- en lenguajes de
programación y cómo se puede evitar.
ISO / IEC TR 24772: 2013 Tecnología de la Información -
Lenguajes de programación - Orientación para evitar vulnerabilidades
en lenguajes de programación a través de selección de idioma y Uso
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 soft- ware 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.

El Informe Técnico está disponible gratuitamente en http: //
standards.iso.org/ittf/PubliclyAvailableStandards/ index.html .
Se mencionan dos normas aquí porque la unidad de pruebas es a
menudo considerado como una actividad de construcción de software.
IEEE e ISO / IEC están cooperando en el desarrollo de una norma
conjunta de cuatro partes,
29119, que proporcionará un trata- miento integral de la
prueba y suplantar IEEE Std. 1008.
IEEE Std. 1008-1987 estándar para el software de pruebas unitarias
Consulte Software Testing KA
/ / IEEE 29119 [cuatro partes] (Borrador) Software IEC ISO e Ingeniería
de Sistemas - Pruebas de software
Consulte Software Testing KA
La siguiente norma prevé la elaboración de la
documentación de usuario durante un proceso de desarrollo
ágil. Se menciona aquí porque el desarrollo ágil es a veces
considerado como la construcción.
ISO / IEC / IEEE 26515: 2012 Sistemas e Ingeniería de Software - El
desarrollo de documentación del usuario en un entorno ágil
Ver Modelos de Ingeniería de Software y
métodos KA
Codificación no es la única manera de crear un producto de software.
A menudo código (así como los requisitos y diseño) se vuelve a utilizar
en proyectos anteriores o Engineers neered para su reutilización en
proyectos futuros. IEEE Std. 1517 se menciona aquí, ya que proporciona
un marco común para la ampliación de los procesos del ciclo de vida del
sistema y software de IEEE Std. 12207: 2008 para incluir la práctica
sistemática de la reutilización.
IEEE Std. 1517-2010 estándar para la Tecnología de la Información - Del
sistema y los procesos de ciclo de vida del software - Los procesos de
reutilización
Consulte Software Ingeniería de Procesos KA
Apéndice B B-7
PRUEBAS DE SOFTWARE
Curiosamente, hay pocos estándares para las pruebas. IEEE Std.
829 es el más completo.
IEEE Std. 829-2008 Norma para el software y la documentación de prueba
del sistema
procesos de prueba a determinar si los productos de desa- rrollo de
una actividad determinada se ajustan a los requisitos de esa
actividad y si el tem y / o software sis- satisface sus necesidades de
uso y de usuarios previstos. tareas de proceso de pruebas se
especifican para diferentes niveles de integridad. Estas tareas de
proceso determinan la amplitud y la profundidad adecuada de la
documentación de prueba. Los elementos de documentación para
cada tipo de documentación de prueba a continuación, pueden ser
seleccionados. El alcance de las pruebas abarca sistemas basados
​en software, software, hardware, cerámica y sus interfaces. Esta
norma se aplica a los sistemas basados ​en software a desarrollar,
mantener, o reutilizados (herencia, comerciales off-the-shelf,
artículos nondevelopmental). El término “software” también incluye
el firmware, microcódigo, y documentación. procesos de prueba
pueden incluir la inspección, análisis, demostración, verificación y
validación de software y productos de sistemas basados ​en
software.
IEEE Std. 1008 se centra en las pruebas unitarias.
IEEE Std. 1008-1987 estándar para el software de pruebas unitarias
El objetivo principal es especificar un método estándar para la
unidad de pruebas de software que puede ser utilizado como
base para el software de sonido Engineer- ing práctica. Un
segundo objetivo es describir los conceptos de ingeniería de
software y supuestos de pruebas en que se basa el enfoque
estándar. Un tercer objetivo es proporcionar orientación e
información para ayudar con la puesta en imple- y el uso del
enfoque de la unidad de pruebas estándar de recursos.
B-8 Guía SWEBOK® V3.0
IEEE e ISO / IEC JTC 1 / SC 7 están cooperando en un proyecto
para desarrollar una única norma global que cubre todos los
aspectos de las pruebas. Uno puede esperar la publicación de la
norma de cuatro partes para el año 2014. Las porciones del
contenido siendo 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 dentro del alcance de la “ing Ensayos” o
deben ser distinguido como “verificación y validación.” A pesar de
que la resolución de la cuestión es, probablemente, de poca
importancia para los usuarios de la norma, asume una gran
importancia a los estándares escritores que deben gestionar un
conjunto integrado de interoperar normas.
/ / IEEE 29119 [cuatro partes] (Borrador) Software IEC ISO e Ingeniería
de Sistemas - Pruebas de software
El propósito de la norma ISO / IEC 29119 Software Testing es definir un
estándar internacionalmente aceptado para las pruebas de software que
puede ser utilizado por cualquier organiza- ción al realizar cualquier tipo
de pruebas de software.
Las pruebas de la documentación del usuario se describe en el
próximo estándar, proporcionando requisitos para el examen y revisión
de la documentación de usuario del software como parte de los procesos
del ciclo de vida. Define el proceso de documentación del punto de vista
del probador de documentación y revisor. Es relacionadas con las
funciones que participan en las pruebas y desarrollo de software y
documentación del usuario, incluyendo proyec- gestores ect, expertos en
usabilidad y desarrolladores de información adicionales a los probadores
y colaboradores.
IEEE Std. 26513-2010 La adopción del estándar ISO / IEC 26513:
2009 Sistemas e Ingeniería de Software - Requisitos para los
probadores y Revisores de Documentación
ISO / IEC 26513 proporciona las exigencias mínimas para la
comprobación y revisión de usuario docu- mentación, incluyendo
tanto documentos impresos y en pantalla se utilizan en el entorno de
trabajo de los usuarios del software de sistemas. Se aplica a los
manuales impresos de usuario, ayuda en línea, tutoriales y
documentación Las alusiones usuario.
En él se especifica procesos para su uso en pruebas y revisión
de la documentación del usuario. No se limita- das a la fase de
prueba y revisión del ciclo de vida, sino que incluye actividades
durante los procesos de gestión de información y de gestión de la
documentación.
Se mencionan dos normas aquí porque algunas fuentes
consideran la verificación y validación de software que se incluyen
en las pruebas taxonómicamente.
IEEE Std. 1012-2012 estándar para el sistema y la verificación y
validación de software
Ver la calidad del software KA
IEEE Std. 1044-2009 norma para la clasificación para el software de
anomalías
Ver la calidad del software KA
MANTENIMIENTO DEL SOFTWARE
Este estándar el resultado de la armonización de distintos
estándares IEEE e ISO / IEC en el sujeto-describe un proceso
integral para la gestión y ejecución de software de manteni-
miento. Se expande en lo dispuesto en el proceso de
mantenimiento de soft- ware previsto en la norma ISO / IEC /
IEEE 12207.
IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006)
estándar para el software del ciclo de vida del software de ingeniería y
procesos de mantenimiento
ISO / IEC 14764: 2006 describe en la mayor
gestión detalle del proceso de mantenimiento se describe en ISO /
IEC 12207, incluyendo tos modifica-. También establece las
definiciones de los tipos ous variabilidad de mantenimiento. ISO / 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.

ISO / IEC 14764: 2006 proporciona el marco dentro del cual
se pueden ejecutar los planes de mantenimiento de software
genéricas y específicas, evaluados y adaptados al ámbito
mantenimiento y la magnitud de los productos de software dadas.
Proporciona el marco, la terminología precisa, y procesos para
permitir la aplicación coherente de gía tecnolo- (herramientas,
técnicas y métodos) para mantenimiento de software.
No se refiere a la operación del software y las funciones
operativas, por ejemplo, copia de seguridad, recuperación y
administración del sistema, que normalmente se lleva a cabo por
aquellos que operan el software.
ISO / IEC 14764: 2006 está dirigido principalmente a los encargados
del mantenimiento de software y, además, para los responsables del
desarrollo y Ance assur- calidad. También puede ser utilizado por los
adquirentes y usuarios de sistemas que contienen software, que pueden
proporcionar insumos para el plan de mantenimiento.
Software Configuration Management
Hay un estándar para la gestión de la configuración.
IEEE Std. 828-2012 Norma para la Gestión de la Configuración
de Sistemas e Ingeniería de Software
Esta norma establece las exigencias mínimas para los
procedimientos de gestión de la configuración (CM) en los
sistemas e ingeniería de software. La aplicación de esta norma se
aplica a cualquier forma, clase o tipo de software o sistema. Esta
revisión de la norma amplía la versión anterior para explicar CM,
incluyendo la identificación y adquisición de elementos de
configuración, el control de cambios, Informe-ing el estado de los
elementos de configuración, así como el software construye y
liberar la ingeniería. Su predece- predefinido sólo el contenido de
un plan de gestión de configuración de software. Esta norma
aborda lo que CM actividades se van a hacer, cuando están a
suceder en el ciclo de vida, y qué planificación y se requieren
recursos. También se describen las áreas de contenido para un
plan de CM. Los puertos SUP- estándar ISO / IEC / IEEE 12207:
2008 e ISO / IEC / IEEE 15288: 2008 y se adhiere a la
terminología
Apéndice B B-9
en la ISO / IEC / IEEE Std. 24765 y los requisitos de elemento de
información de IEEE Std. 15939.
ISO / IEC JTC 1 / SC 7 aún no ha determinado qué medidas
se deben tomar con respecto a la nueva norma IEEE Std. 828.
Hay cuestiones relativas a la medida de la compatibilidad con la
norma ISO / IEC / IEEE 12207 y otras normas en la suite SC 7.
Cabe señalar, sin embargo, que SC 7 no tiene un estándar de
competencia.
GESTIÓN DE INGENIERÍA DE
SOFTWARE
La mayoría de los lectores interpretarán la frase “la gestión de la
ingeniería de software” para referirse a la gestión de una proyecto que
se refiere a software. Hay al menos dos posibles extensiones a este
eralization ge-, sin embargo. Algunas de las actividades de software
se gestionan de acuerdo con un acuerdo de nivel de servicio (SLA).
SLA no cumplen con los criterios de “pro- yecto” de acuerdo con
algunas definiciones. También, se ha convertido en un acuerdo
general de que algunos gestión de software debe ocurrir en la
organización a un 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 cesos pro de
software y herramientas por la organización. gestión de proyectos
de software puede ser considerado como una especialización de
“gestión de proyectos” - a menudo considerado como una disciplina
distinta. El Instituto de Gestión de proyec- etc. Guía para la Dirección
de Proyectos (PMBOK ®
Guía) es a menudo considerado como la fuente autorizada
para este conocimiento. De vez en cuando, IEEE adopta la
versión más reciente del
PMBOK ® Guía como un estándar IEEE.
IEEE Std. 1490-2011 Guía de implantación de la Gestión de
Proyectos Institute (PMI ®) estándar, una guía para la Dirección
de Proyectos del Conocimiento (Guía del PMBOK®) -Cuarto
Edición
los Guía del PMBOK® identifica el subconjunto de la Dirección de
Proyectos del conocimiento gene- ralmente 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
B-10 Guía SWEBOK® V3.0
el tiempo y existe un 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 siempre debe aplicarse de
manera uniforme a todos los proyectos descritos; ción del equipo y /
o gestión de proyectos organiza- se respon- sable para determinar
lo que es apropiado para cualquier proyecto dado. los Guía del
PMBOK® También proporciona y promueve un vocabulario común
dentro de la profesión de gestión de proyectos para la discusión, la
escritura y la aplicación de conceptos de gestión de proyectos. Tal
vocabulario estándar es un elemento esencial de una disciplina
profesional. El Project Management Institute (PMI) considera que
esta norma como referencia fundamental la gestión de proyectos
para sus programas y certificaciones de desarrollo profesional.
Las revisiones de la norma ISO / IEC / IEEE 2008 12207 y 15288
proporcionan los procesos de gestión de proyectos de software y
sistemas y relacionarlos con los procesos a nivel de organización, así
como los procesos gías Nical. El desarrollaron conjuntamente norma
16326, en sustitución de dos normas más antiguas, amplía estas
disposiciones con orientación para su aplicación.
ISO / IEC / IEEE 16326: 2009 de Gestión de Sistemas y de
Ingeniería de Software-Life Cycle Procesos-Proyecto
ISO / IEC / IEEE 16326: 2009 proporciona las especificaciones de
contenido normativo de los planes de gestión de proyectos que cubren los
proyectos de software y proyectos de sistemas intensivos en software.
También proporciona una discusión detallada y asesoramiento sobre la
aplicación de un conjunto de procesos pro- yecto que son comunes tanto
para el ciclo de vida del sistema ware y blandas como cubierto por la
norma ISO / IEC 12207: 2008 (IEEE Std 12207 a 2.008.) E ISO / IEC
15288: 2008 (IEEE Std 15.288-2008.), respectivamente. La discusión y
consejos están destinados a ayudar en la preparación del contenido
normativo de los planes de gestión de proyectos. ISO / IEC / IEEE 16326:
2009 es el resultado de la armonización de la norma ISO / IEC TR 16326:
1999 e IEEE Std. 1058-1998.
Particularmente en aplicaciones de alta tecnología y proyectos
de graves consecuencias, la gestión de riesgos es un aspecto
importante de las responsabilidades de gestión en general pro-
yecto. Esta norma se ocupa de ese tema.
IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) Ciclo
de vida estándar para los sistemas y software de Gestión de Procesos de
Software Ingeniería--Riesgo
ISO / IEC 16085: 2006 define un proceso para la gestión del riesgo en
el ciclo de vida. Se puede añadir al conjunto existente de los procesos
del ciclo de vida del software del sistema y definidos por la norma ISO /
IEC 15288 y ISO / IEC 12207, o puede ser utilizado
independientemente. ISO / IEC 16085: 2006 puede ser aplicado
igualmente a sistemas y software.
El propósito de la gestión de riesgos es iden- potenciales
problemas de gestión y técnicas tificar antes de que ocurran de
manera que se pueden tomar medidas que reducen o eliminan la
probabilidad y / o el impacto de estos problemas que puedan
producirse. Es una herramienta de cal criti- para determinar
continuamente la viabi- lidad de los planes de proyecto, para mejorar
la 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 .
El análisis de riesgos y mitigación de riesgo depende
crucialmente de medición. Esta norma internacional proporciona
una elaboración del proceso de medi- ción de la norma ISO /
IEC / IEEE 15288: 2008 e ISO / IEC / IEEE 12207: 2008.
IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939:
2007 Sistemas y Procesos de Ingeniería de Software de
Mediciones
ISO / IEC 15939 define un proceso de medición aplicables a
sistema y ingeniería de software y disciplinas de gestión. El
proceso se describe a través de un modelo que define las
activi- dades 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 proceso de medición es para producir o gestionar la documentación, y se aplica tanto a la

flexible, tailorable, y adaptable a las necesidades de diferentes documentación impresa y la documentación en pantalla. Gran parte de su

usuarios. orientación es aplicable a la documentación del usuario para los sistemas

ISO / IEC 15939: 2007 identifica un proceso que es compatible con la que incluyen utensilios de hardware así como software.

definición de un conjunto adecuado de medidas que aborden las

necesidades de información específica. En él se identifican las actividades

y tareas que son necesarias para éxito- totalmente identificar, definir,

seleccionar, aplicar y mejorar la medición dentro de un proyecto global o la A veces, el software o los componentes del sistema se adquieren en
estructura de medición zational orga-. También proporciona definiciones lugar de desarrollarse.
para los términos de medición utilizados comúnmente dentro de las

industrias de sistema y software.

IEEE Std. 1062-1998 Práctica Recomendada para la adquisición de

software

proyectos de software a menudo requieren el desa- rrollo de la Se describe un conjunto de prácticas útiles de calidad que pueden ser

documentación del usuario. Gestión del proyecto, por lo tanto, seleccionados y aplicados durante uno o más pasos de un proceso de

incluye la gestión del esfuerzo de documentación. adquisición de software. Esta práctica recomendada se puede aplicar al

software que se ejecuta en cualquier sistema informático,

independientemente del tamaño, complejidad o criticidad del software,

pero es más adecuado para su uso on-off-the-modificado el software de la

ISO / IEC / IEEE 26511: 2012 Sistemas y de Ingeniería de plataforma y el software desarrollado completamente.

Software-Requisitos para los gerentes de Documentación del

usuario

ISO / IEC / IEEE 26511: 2012 especifica los procedimientos para la A veces, la documentación del usuario se adquiere con
gestión de la documentación de usuario en todo el ciclo de vida del independencia de que el software se describe fue adquirida.
software. Se aplica a las personas u organizaciones que producen suites Los siguientes Norma se ocupe de ese tema.
de documentación, a los que realizan un único proyecto de
documentación, y la documentación producida internamente, así como a
la documentación contratada para las organizaciones de servicios
externos. Proporciona una visión general de los procesos de ISO / IEC / IEEE 26512: 2011 Sistemas y de Ingeniería de

documentación ware y gestión de la información blandos, y también Software-Requisitos para los adquirentes y proveedores de

presenta aspectos de la planificación de la cartera y gestión de Documentación del usuario

contenidos que los administradores de la documentación de usuario se

aplican. Abarca las actividades de gestión en el inicio de un proyecto, ISO / IEC / IEEE 26512: 2011 ha sido desarrollado para ayudar a los

incluyendo el establecimiento de procedimientos y especificaciones, el usuarios de la norma ISO / IEC / IEEE 15288: 2008 o ISO / IEC / IEEE

establecimiento de infraestructura y construcción de un equipo. Incluye 12207: 2008 para la adquisición o la documentación de usuario del

ejemplos de funciones necesarias en un equipo de documentación del software de alimentación como parte de los procesos del ciclo de vida del

usuario. Se ocupa de las mediciones y estimaciones necesarias para el software. Define el proceso de documentación desde el punto de vista de

control de la gestión y el uso de procesos tales como la gestión del la entidad adquirente y el punto de vista del proveedor. ISO / IEC / IEEE

cambio, el horario y el control de costes, gestión de recursos y gestión 26512: 2011 cubre los requisitos de los elementos de información

de la calidad y el proceso de mejora ción de apoyo. Incluye requisitos utilizados en la adquisición de productos de documentación de usuario: el

para documentos clave producidos para la gestión de la documentación plan de adquisición, especificación documento, Ment por el estado de

del usuario, incluyendo los planes de documentación y los planes de trabajo, solicitud de propuestas, y propuesta. Proporciona una visión

gestión de documentación. ISO / IEC / IEEE 26511: 2012 es general de los procesos de documentación de usuario del software y la

independiente de las herramientas de software que pueden utilizarse 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

B-12 Guía SWEBOK® V3.0
documentación del usuario de software. Estos requisitos son esenciales
para la especificación de documentos del usuario y declaración de
trabajo. Incluye requisitos para salidas de documentos primarios del
proceso de adquisición y suministro: la solicitud de propuesta y la
propuesta de productos y servicios de documentación del usuario.
También se analiza el uso de un plan de gestión de la documentación y
la de un plan de documento a medida que surjan en los procesos de
adquisición y suministro. ISO / IEC / IEEE 26512: 2011 es independiente
de las herramientas de software que pueden ser utilizados para producir
la documentación y se aplica tanto a la documentación impresa y la
documentación en pantalla. Gran parte de su orientación es aplicable a
la documentación del usuario para los sistemas que incluyen hardware,
así como el software.
Se mencionan las siguientes dos normas aquí, porque
proporcionan información utilizada en la toma de decisiones ción
manage-.
IEEE Std. 1028-2008 estándar para las revisiones de software y auditorías
Ver la calidad del software KA
IEEE Std. 1061-1998 Estándar de Calidad de Software Metodología
Métrica Ver la calidad del software KA
La siguiente norma se menciona, ya que incluye el papel del
gerente en el desarrollo de documentación de usuario en un
proyecto ágil.
ISO / IEC / IEEE 26515: 2012 Sistemas y de Ingeniería de Software-El
desarrollo de documentación del usuario en un entorno ágil
Ver Modelos de Ingeniería de Software y
métodos KA
SOFTWARE INGENIERÍA DE PROCESOS
procesos de software e ingeniería de sistemas son
fundamentales para la normalización de esas dos disciplinas,
no sólo porque muchos están intere- sadas en la mejora de
procesos, sino también porque los procesos son eficaces para
la descripción de
mejora de las prácticas. Por ejemplo, se podría pro- poner una práctica
mejorada para el software de análisis de los requisitos. Un tratamiento
ingenuo podría relacionar la descripción a una etapa temprana del
modelo del ciclo de vida. Un enfoque superior es para describir la
práctica en el contexto de un proceso que puede ser aplicado en
cualquier etapa del ciclo de vida. El proceso de análisis de requisitos,
por ejemplo, es preciso proceder a la etapa de desarrollo, para el
mantenimiento, y con frecuencia para el retiro, por lo que una mejora
de la práctica se describe en términos del proceso de análisis de
requisitos se puede aplicar a cualquiera de estas etapas. Las dos
normas principales son la norma ISO / IEC / IEEE
12207, Los procesos de software de ciclo de vida, e ISO / IEC / IEEE
15288, Procesos del ciclo de vida del sistema.
Las dos normas tienen historias distintas, pero ambos fueron
revisados ​en 2008 para alinear sus pro- cesos, lo que permite su uso
interoperable a través de un amplio espectro de proyectos que van
desde un componente de software autónomo a un sistema con
contenido de software ligible neg. Ambos están siendo revisados ​de
nuevo con la intención de que contiene una lista idéntica de los
procesos, pero con disposiciones especializados para las respectivas
disciplinas.
IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008)
estándar para los sistemas y software Ingeniería- Software Procesos del
ciclo de vida
ISO / IEC 12207: 2008 establece un marco común para los
procesos del ciclo de vida del software, con la terminología bien
definida que puede ser referenciado por la industria del software.
ISO / IEC 12207: 2008 se aplica a la adquisi- ción de los
sistemas y productos de software y servi- cios y para el
suministro, desarrollo, 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.

IEEE Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008)
estándar para los sistemas y software Ingeniería- vida del sistema los
procesos de ciclo
ISO / IEC 15288: 2008 establece un marco común para describir el
ciclo de vida de los siste- mas creados por los seres humanos. Se
define un conjunto de procesos y terminología asociada. Estos
procesos se pueden aplicar en cualquier nivel en la jerarquía de la
estructura de un sistema. conjuntos seleccionados de estos
procesos se pueden aplicar durante todo el ciclo de vida de la
gestión y la realización de las etapas del ciclo de vida de un
sistema. Esta es plished acompa- mediante la participación de
todas las partes interesadas, con el objetivo último de lograr la
satisfacción al cliente central.
ISO / IEC 15288: 2008 también proporciona procesos que apoyan la
definición, el control, y la mejora de los procesos del ciclo de vida
utilizadas dentro de una organización o de un proyecto. Las
organizaciones y los proyectos pueden utilizar estos procesos de ciclo
de vida en que la adquisición y el suministro de sistemas.
ISO / IEC 15288: 2008 se refiere a los sistemas que son hechas por el
hombre y pueden ser configurados con uno o más de los siguientes:
hardware, software, datos, los humanos, los procesos (por ejemplo, los
procedimientos para el servicio a los usuarios Viding pro), procedimientos (
por ejemplo, instrucciones de opera- tor), instalaciones, materiales y
entidades de rally que ocurre natu-. Cuando un elemento del sistema es el
software, los procesos del ciclo de vida del software documentado en la
Norma ISO / IEC 12207: 2008 se pueden utilizar para poner en práctica
ese elemento del sistema.
ISO / IEC 15288: 2008 e ISO / IEC 12207: 2008 se
armonizan para su uso simultáneo en un solo proyecto o en una
sola organización.
Estas dos normas especifican que los procesos pueden producir
elementos de información, pero no pre- escriba su contenido o
formato. El siguiente estándar proporciona ayuda con eso.
ISO / IEC / IEEE 15289: 2011 Sistemas y de Ingeniería de
Software-contenido del Ciclo de Vida de Productos de Información
(Documentación)
ISO / IEC / IEEE 15289: 2011 proporciona los requisitos para la
identificación y planificación de la específica
Apéndice B B-13
elementos de información (productos de información, docu- mentación)
para ser desarrollados y revisados ​en los sistemas y los ciclos de vida
del software y procesos de gestión de servicios. Se especifica el
propósito y el contenido de todos los sistemas identificados y los
registros de datos de software y elementos de información de ciclo de
vida, así como los registros y elementos de información para la gestión
de servicios de tecnología de la información. El contenido elemento de
información se definen de acuerdo con los tipos genéricos de
documentos (descripción, plan de, helado Pol, el procedimiento,
informe, solicitud, y en las especificaciones) y el propósito específico del
documento. Para simplificar la referencia, cada elemento de información
se describe como si se publicó como documento separado. Sin
embargo, los elementos de información pueden ser inéditos pero está
disponible en un repositorio para refe- rencia, dividido en documentos
separados o volúme- nes, o en combinación con otros elementos de
información en un solo documento. ISO / IEC / IEEE 15289: 2011 se
basa en los procesos del ciclo de vida que se especifican en la norma
ISO / IEC 12207: 2008 (IEEE Std 12207-2008.) E ISO / IEC 15288:
2008 (IEEE Std 15288-.
2008), y la gestión de servicios de procesos especificados en la
norma ISO / IEC 20000-1: 2005 e ISO / IEC 20000-2: 2005.
Las siguientes dos guías proporcionan información
complementaria útil en la aplicación de 12207 y 15288.
IEEE Std. 24748,2-2012 Guía de implantación de la norma ISO / IEC TR
24748-2: 2011 Sistemas y de Ingeniería de Software de Gestión de
Vida-Parte 2 Ciclo: Guía para la aplicación de la norma ISO / IEC 15288
(Procesos del ciclo de vida del sistema)
ISO / IEC TR 24748-2 es una guía para la apli- cación de la norma ISO /
IEC 15288: 2008. Aborda sis- tema, ciclo de vida, proceso, organización,
proyecto, y los conceptos de 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, proporciona orientación sobre la aplicación de la norma ISO
/ IEC 15288: 2008, de los aspectos de la es- trategia, la planificación, la
aplicación en las organizaciones, y la aplicación de proyectos.
IEEE Std. 24.748,3-2012 Guía de implantación de la norma ISO /
IEC TR 24748-3: 2011 Sistemas y Software
B-14 Guía SWEBOK® V3.0
Ingeniería-Life Management-Parte 3 Ciclo: Guía para la aplicación
de la norma ISO / IEC 12207 (procesos del ciclo de vida del
software)
ISO / IEC TR 24748-3 es una guía para la apli- cación de la norma ISO /
IEC 12207: 2008. Aborda sis- tema, ciclo de vida, proceso, organización,
proyecto, y los conceptos de adaptación, principalmente a través de la
referencia a la norma ISO / IEC TR 24748-1 e ISO / IEC 12207: 2008. Se
proporciona orientación sobre la aplicación de la norma ISO / IEC 12207:
2008, de los aspectos de la estrategia, la planificación, la aplicación en
las organizaciones, y la aplicación de proyectos.
Las normas 12207 y 15288 proporcionan cesos pro que cubren el ciclo
de vida, pero que no proporcionan un modelo estándar de ciclo de vida
(cascada, la entrega incrementales, prototipo impulsado, etc). La selección
de un modelo de ciclo de vida apropiado para un proyecto es una de las
principales preocupaciones de la norma ISO / IEC 24748-1.
IEEE Std. 24.748,1-2011 Guía de implantación de la norma ISO / IEC
TR 24748-1: 2010 Sistemas y de Ingeniería de Software de
Gestión-Life-Cycle Parte 1: Guía para la Gestión del Ciclo de Vida
ISO / IEC TR 24748-1 proporciona información sobre los conceptos de
ciclo de vida y las descripciones de las poses PUR y los resultados de las
etapas del ciclo de vida representativos. También ilustra el uso de un
modelo de ciclo de vida para los sistemas en el contexto de la norma ISO
/ IEC 15288 y proporciona una ilustración correspondiente de la utilización
de un modelo de ciclo de vida para el software en el contexto de la norma
ISO / IEC 12207. ISO / IEC TR 24748- 1 proporciona, además, una
discusión detallada y asesoramiento sobre la adaptación de un modelo de
ciclo de vida para su uso en un proyecto específico y entorno de la
organización. Se proporciona orientación adicional sobre el ciclo de vida
modelo de uso de los ámbitos, disciplinas y especialidades. ISO / IEC TR
24748-1 da una comparación detallada entre las versiones anteriores y
actuales de ISO / IEC 12207 y ISO / IEC 15288, así como consejos sobre
la transición de antes de las versiones actuales y sobre el uso de sus
guías de aplicación. La dis- cusión y asesoramiento están destinadas a
proporcionar un modelo de referen- cia para los modelos de ciclo de vida,
facilitar el uso de la versión actualizada de la norma ISO / IEC 15288 e
ISO / IEC 12207, y proporcionar un marco para el desarrollo de
guías de aplicación actualizados para los estándares internacionales.
ISO / IEC TR 24748-1 es el resultado de la etapa de alineación de la
armonización de la norma ISO / IEC 12207 y ISO / IEC 15288.
La siguiente norma amplía las disposiciones de la norma ISO / IEC /
IEEE 12207 para hacer frente a la reutilización del software sistemática.
IEEE Std. 1517-2010 estándar para la tecnología de la información del
sistema y del software-Vida Procesos de reutilización de procesos de
ciclo
Un marco común para la ampliación de los procesos del ciclo de
vida del sistema y software de IEEE Std. 12207: 2008 para incluir
se proporciona la práctica sistemática de la reutilización. Los
procesos, actividades y tareas que deben aplicarse durante cada
proceso de ciclo de vida para permitir a un sistema y / o producto
para ser construido a partir de los activos reutilizables se
especifican. Los procesos, actividades y tareas que permitan la
identificación, construcción, mantenimiento y gestión de los bienes
suministrados también se especifican.
IEEE Std. 1220 ha sido ampliamente aplicado como un proceso de
ingeniería de sistemas y fue adoptado por la norma ISO / IEC 26702.
con el número Desafortunadamente, la norma no es totalmente
compatible con la norma ISO / IEC / IEEE 15288 y está siendo
revisada para resolver ese problema. El resultado será publicado
como ISO / IEC / IEEE 24748-4.
IEEE Std. 1220-2005 (también conocido como ISO / IEC 26702: 2007)
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

que el producto está correctamente diseñado para que sea
asequible para producir, poseer, operar, mantener y eventualmente
gastar sin riesgos indebidos para la salud o el medio ambiente.
Desde SC 7 e IEEE han escrito tantas normas de proceso,
uno no puede sorprenderse al saber que su modelo para la
descripción del proceso se registra en un informe técnico.
IEEE Std. 24774-2012 Guía de implantación de la norma ISO / IEC TR
24474: 2010 Sistemas y Software Engineering-Life Cycle
Management-Directrices para la Descripción del Proceso
Un número cada vez mayor de, y las normas internacionales,
nacionales industria de procesos mode- los describa. Estos modelos
son desarrollados para una serie de propósitos, incluyendo la
implementación de procesos y evaluación. Los términos y las
descripciones utilizadas en tales modelos varían en formato, contenido
y nivel de prescripción. ISO / IEC TR 24774: 2010 PRESION ents
directrices para los elementos utilizados más fre- cuentemente en la
descripción de un proceso: el título, PUR pose, resultados, actividades,
tareas y elemento de información. Mientras que el propósito primario de
ISO / IEC TR 24774: 2010 es fomentar la coherencia en modelos de
referencia proceso Dard Standards, las directrices que proporciona se
pueden aplicar a cualquier modelo de proceso desarrollado para
cualquier propósito.
Una muy pequeña entidad (VSE) es una empresa, una
organización, un departamento o un proyecto que tiene hasta 25
personas. La serie 29110 ISO / IEC “pro” archivos grandes, tales
como las normas ISO / IEC 12207 para el software y la norma ISO /
IEC 15288 para sistemas, en otras más pequeñas para las MPE. ISO
29110 es aplicable a las empresas muy pequeñas que no desarrollan
sistemas críticos o software crítico. Perfiles proporcionan una hoja de
ruta que permite una puesta en marcha a crecer un paso a la vez
usando las guías de gestión y de ingeniería ISO 29110. ISO / IEC
29110 serie de normas e informes técnicos son el blanco de la
audiencia tales como las microempresas, los clientes o los auditores.
ISO / IEC 29110 no pretende excluir el uso de diferentes ciclos de
vida se acerca, como la cascada, iterativo e incremental, evolutivo, o
ágil.
Apéndice B B-15
A VSE podría obtener una ISO / IEC 29110 certifica- ción. El
conjunto de informes técnicos está disponible sin costo alguno en el
sitio web de la ISO. Muchos ISO 29110 documentos están
disponibles en Inglés, Español, tugueses Por-, japonés y francés.
ISO / IEC TR 29110-5-1-2: Perfiles 2011 Ingeniería de
Software-ciclo de vida de entidades muy pequeñas (MPE) -Parte
5-1-2: Gestión y Guía de Ingeniería: Perfil genérico Grupo: todos
los datos generales
ISO / IEC TR 29110-5-1-2: 2011 es aplicable a entidades muy
pequeñas (MPE). Un VSE se define como una empresa,
organización, departamento, o pro- yecto que tiene hasta 25
personas. Un conjunto de normas y guías se ha desarrollado de
acuerdo con un conjunto de características y necesidades MPE. Las
guías se basan en subconjuntos de estándares apropiados ele-
mentos, conocidos como perfiles VSE. El propósito de un perfil VSE
es definir un subconjunto de las normas internacionales ISO / IEC
pertinentes al contexto las empresas muy pequeñas.
ISO / IEC TR 29110-5-1-2: 2011 proporciona la guía de
gestión e ingeniería para el perfil VSE base aplicable a
empresas muy pequeñas que no desarrollan software crítico.
El grupo de perfil genérico no implica ningún dominio de
aplicación específica.
El siguiente estándar puede ser visto como una alternativa a
12207 para proyectos individuales. La norma de 1074, explica cómo
definir los procesos para su uso en un proyecto determinado. Las
normas 12207 y 15288, sin embargo, se centran en la definición de
procesos para la adopción de la organización y el uso repetido en
muchos proyectos. La corriente 1074 es la actualización de una
norma que fue un precursor de 12207.
IEEE Std. 1074-2006 estándar para desarrollar un proceso del ciclo de vida
del software del proyecto
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.
B-16 Guía SWEBOK® V3.0
Todas las normas descritas hasta ahora en esta sec- ción
proporcionar una base para definiendo procesos. Algunos usuarios
están interesados ​en evaluar y la mejora de sus procesos después de
la implementación. La serie 15504 prevé la evaluación del proceso;
que actualmente es de ser revisado y pasa a ser 330xx.
ISO / IEC 15504 [diez partes] Tecnología-Proceso de Información
de Evaluación
ISO / IEC 15504-2: 2003 define los requisitos para realizar la
evaluación de proceso como base para su uso en la mejora de
procesos y la determinación de la capacidad.
evaluación de proceso se basa en un modelo sional de dos
dimen- que contiene una dimensión de proceso y una dimensión de
capacidad. La dimensión proceso es proporcionado por un modelo
externo referencia de proceso (tal como 12.207 o 15.288), que define
un conjunto de procesos que se caracterizan por estados de
resultados de propósito proceso y de proceso. La dimensión
capacidad consiste en un marco de medición que comprende seis
niveles de capacidad del proceso y sus atributos de proceso
asociados.
La salida de evaluación consta de un conjunto de puntuaciones
de atributos proceso para cada proceso evaluado, denominado el
perfil de 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 estruc- tura que
• facilita la autoevaluación;
• proporciona una base para uso en el proceso de mejora ment y
determinación de la capacidad;
• tiene en cuenta el contexto en el que se implementa el
proceso de evaluar;
• produce una calificación de proceso;
• aborda la capacidad del proceso para lograr su propósito;
• es aplicable en todos los dominios de aplicación y tamaños
de organización; y
• puede proporcionar un punto de referencia objetiva entre las
organizaciones.
El conjunto mínimo de requisitos definidos en la norma ISO / IEC
15504-2: 2003 asegura que los resultados de evaluación son objetivo,
imparcial, consistente, repetible capaz, y representante de los procesos
evaluados. Resultados de las evaluaciones de proceso conformes
pueden compararse cuando se consideran los alcances de las
evaluaciones a ser similares; para obtener orientación sobre este tema,
consulte la norma ISO / IEC 15504-4.
Se mencionan varias otras normas aquí porque están
escritos como elaboraciones de los procesos de 12207 o
15288. Están asignados a otras KAs debido a que cada uno
se ocupa de temas descritos en los otros KAs.
IEEE Std. 828-2012 Norma para la Gestión de la Configuración
de Sistemas e Ingeniería de Software
Consulte Gestión de la Configuración de Software KA
IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006)
estándar para el software del ciclo de vida del software de ingeniería y
procesos de mantenimiento
Ver Mantenimiento de Software KA
ISO / IEC 15026-4: 2012 Sistemas y de Ingeniería de Software-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 de Ingeniería de Software de
Mediciones
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
IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) Ciclo
de vida estándar para los sistemas y software de Gestión de Procesos de
Software Ingeniería--Riesgo
Consulte Software Engineering Management KA

ISO / IEC / IEEE 16326: 2009 de Gestión de Sistemas y de
Ingeniería de Software-Life Cycle Procesos-Proyecto
Consulte Software Engineering Management KA
/ IEC / IEEE 29148 ISO: 2011 Sistemas y de Ingeniería de
Software-Life Cycle procesos de Ingeniería de Requisitos
Consulte Requisitos de software KA
Algunos usuarios desean estándares de procesos que pueden
utilizarse para operaciones de TI o la gestión de servicios de TI. La
serie ISO / IEC 20000 describen la gestión de servicios. Los
procesos se definen con menos rigor que los de las normas antes
mencionadas inge- niería, pero pueden ser preferibles para situa-
ciones donde los riesgos de fracaso implican dinero o la satisfacción
del cliente en lugar de la salud pública, la seguridad y el bienestar.
La serie ISO / IEC 20000 se extienden ahora a muchas partes. El
fundamento de la serie, ISO / IEC 20000-1, se describe brevemente
a continuación.
ISO / IEC 20000-1: 2011 Tecnología de Información de Gestión de
Servicio-Parte 1: Requisitos del Sistema de Gestión de Servicios
ISO / IEC 20000-1: 2011 es un sistema de gestión de servicios
(SMS) estándar. Especifica los requisitos para el proveedor de
servicios para planificar, establecer, imple- ment, operar,
supervisar, revisar, mantener y mejorar un SMS. Los requisitos
incluyen el diseño, la transición, la entrega y la mejora de los
servicios para satisfacer los requisitos de servicio acordados.
IEEE ha adoptado las dos primeras partes de la serie ISO / IEC
20000.
Modelos y métodos de software de ingeniería
Algunos enfoques de métodos de ingeniería de software de uso
que abarcan gran parte de su ciclo de vida, en lugar de
centrarse en procesos específicos. “Jefe programador” era uno
ejem- plo tradicionales. “El desarrollo ágil” (en realidad un
ejemplo de entrega incrementales tradicional) es una corriente
Apéndice B B-17
ejemplo. Ni tampoco S2ESC SC 7 tiene un estándar para el
desarrollo ágil, pero no existe un estándar para el desarrollo de
documentación de usuario en un proyecto ágil.
ISO / IEC / IEEE 26515: 2012 Sistemas y de Ingeniería de Software-El
desarrollo de documentación del usuario en un entorno ágil
ISO / IEC / IEEE 26515: 2012 especifica la manera en que la
documentación del usuario se puede desarrollar en los proyectos de
desarrollo ágil. Está diseñado para su uso en todas las
organizaciones que están utilizando desa- rrollo ágil o están
considerando la implementación de sus proyec- tos utilizando estas
técnicas. Se aplica a las personas u organizaciones que producen
suites de documentación, a los que realizan un único proyecto de
documentación, y la documentación producida internamente, así
como a la documentación contratada para las organizaciones de
servicios externos. ISO / IEC / IEEE 26515: 2012 se refiere a la
relación entre el proceso de documentación del usuario y el proceso
de documentación del ciclo de vida de desarrollo ágil. Describe
cómo el desarrollador de información o administrador de proyec- ect
pueden planificar y gestionar el desarrollo de usuario docu-
mentación en un entorno ágil. Se pretende ni para alentar ni a
desanimar el uso de cualquier herramienta de desarrollo ágil
particulares o métodos.
Muchas metodologías se basan en descripciones semiformales
del software que se construirá. Estos van desde notaciones
descriptivas simples a los modelos que pueden ser manipulados y
probados y, en algunos casos, puede generar código. Dos técnicas
antiguas rela- tivamente comienzan la lista; la primera ha sido
ampliamente aplicado para el modelado de procesos y flujos de
trabajo.
IEEE Std. 1320,1-1998 estándar para Funcional del Lenguaje de
Modelado en sintaxis y la semántica de IDEF0
modelado IDEF0 función está diseñada para repre- sentan 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
B-18 Guía SWEBOK® V3.0
comprensión, el análisis de apoyo, proporcionan la lógica de los
cambios potenciales, especificar necesidades, y diseño de apoyo a
nivel de sistema y activi- integración lazos. IDEF0 puede ser usado
para modelar una amplia variedad de sistemas, compuestos por
personas, máquinas, mate- riales, las computadoras y la información
de todas las variedades, y estructurada por las relaciones entre ellos,
tanto automatizados y no automatizados. Para los nuevos siste- mas,
IDEF0 puede ser utilizado por primera vez para definir los requisitos y
especificar las funciones a realizar por el sistema futuro. Como base
de esta arquitectura, IDEF0 continuación, se puede utilizar para
diseñar una aplicación que cumple con estos requisitos y realiza estas
funciones. Para siste- mas existentes, IDEF0 se puede utilizar para
analizar las funciones que el sistema funciona y para grabar los
medios por los cuales estos se realizan.
IEEE Std. 1320,2-1998 estándar para Modelado Conceptual
Idioma-sintaxis y la semántica de IDEF1X97 (IDEFobject)
IDEF1X 97 consta de dos lenguajes de modelado conceptual. El
lenguaje de estilo clave soporta el modelado de datos / información y
es a la baja COMPATIBLES con el estándar del gobierno de Estados
Unidos de 1993, FIPS PUB 184. El lenguaje de estilo identidad se
basa en el modelo de objetos con las reglas y restricciones
declarativas. IDEF1X 97 estilo identidad incluye construcciones para
los componentes distintos pero relacionados de abstracción objeto:
interfaz, solicitudes y realización; utiliza gráficos para indicar la
interfaz; y define un lenguaje de reglas y la restricción declarativa,
directamente ejecutable para solicitudes y realiza- ciones. IDEF1X 97
modelado conceptual apoya la implementación de bases de datos
relacionales, bases de datos relacionales, bases de datos extendidos
de objeto, y el objeto lenguajes de programación. 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 IDEF1X 97
puede ser transformada en una teoría equivalente en la lógica de
primer orden. Este procedimiento se aplica entonces a un metamodelo
de IDEF1X 97 para definir el conjunto válido de IDEF1X 97 modelos.
En los últimos años, la notación UML se ha convertido en popular para
el modelado de sistemas intensivos en software.
Las siguientes dos normas proporcionan dos versiones del
lenguaje UML.
ISO / IEC 19501: 2005 Información Tecnología distribuido
abierto Modeling Language (UML) Versión 1.4.2
Procesamiento-Unificado
ISO / IEC 19501 describe el Modelo- Unificado ing Language (UML),
un lenguaje gráfico para visualizar, especificar, construir y
documentando los artefactos de un sis- tema intensivos en software.
El UML ofrece una forma estándar para escribir planos de un
sistema, incluyendo cosas conceptuales tales como procesos de
negocio y funciones del sistema, así como las cosas concretas, tales
como instrucciones de lenguaje de programación, esquemas de
bases de datos y componentes de software capaces Reus-.
ISO / IEC 19505: 2012 [dos partes] a objetos Grupo de Tecnología
de Gestión de Información Unified Modeling Language (UML del
OMG)
ISO / IEC 19505 define el Unified Modeling Language (UML),
revisión 2. El objetivo de UML es proporcionar arquitectos de
sistemas, ingenieros de software y desarrolladores de software
con herramientas para el análisis, diseño e implementación de
sistemas basados ​en software, así como para modelado de
negocios y procesos similares.
Dos estándares más construyen sobre la base de UML para
proporcionar capacidades de modelado adicionales:
ISO / IEC 19506: Modernización-Driven Architecture 2012
Información de Tecnología de administración de grupos de objetos
(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

proyectos que involucran sistemas de software existentes asegurando la
interoperabilidad y el intercambio de datos entre las herramientas
proporcionadas por diferentes proveedores.
ISO / IEC 19507: 2012 Grupo de Gestión de Información de
Tecnología de objetos Object Constraint Language (OCL)
ISO / IEC 19507: 2012 define el objeto Con- Idioma
straint (OCL), versión 2.3.1. OCL versión 2.3.1 es la
versión de OCL que está alineado con UML 2.3 y 2.0
MOF.
Algunas organizaciones invierten en entornos de software
niería niería (SEE) para ayudar en la construcción de software.
Un SEE, per se, no es un sustituto de los procesos de sonido. Sin
embargo, un VER adecuada debe ser compatible con los
procesos que han sido elegidos por la organización.
ISO / IEC 15940: 2006-Tecnologías de la Información Ingeniería de
Software Environment Services
ISO / IEC 15940: 2006 define el entorno de ingeniería de software (VER)
servicios conceptualmente en un modelo de referen- cia que se puede
adaptar a cualquier vela por 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 refe-
rencia 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 herramienta para su uso en la
evaluación técnica y la selección final de una herramienta CASE.
IEEE Std. 14102-2010 La adopción del estándar ISO / IEC 14102: 2008
Tecnología de la Información-Directrices para la evaluación y
selección de herramientas CASE
Apéndice B B-19
Dentro de los sistemas e ingeniería de software, ingeniería com-
putadora asistido por software (CASE) representan una parte
importante de las tecnolo- gías de apoyo utilizados para desarrollar y
mantener sistemas de tecnología de informa- ción. Su selección debe
llevarse a cabo con una cuidadosa consideración de tanto los
requisitos técnicos y de gestión. ISO / IEC 14102: 2008 define tanto un
conjunto de cesos pro y un conjunto estructurado de herramienta del
caso de carac- terísticas para su uso en la evaluación técnica y la
selección 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-5: 1998.
ISO / IEC 14102: 2008 adopta el modelo general de las características
de calidad de producto de software y subcaracterísticas definidas en la
norma ISO / IEC 9126- 1: 2001 y se extiende estos cuando el producto de
software es una herramienta CASE; que proporciona carac- terísticas de
productos únicos para herramientas CASE.
El siguiente documento es una guía sobre cómo adoptar herramientas
CASE, una vez seleccionado.
IEEE Std. 14471-2010 Guía de implantación de la norma ISO / IEC TR 14471:
2007 Tecnología de la Información-Ingeniería de Software-Directrices para la
adopción de las herramientas CASE
El propósito de la norma ISO / IEC TR 14471: 2007 es
proporcionar una práctica recomendada para la adop- ción
CASO. Proporciona una guía para establecer cesos y actividades
que se van a aplicar para la adopción exitosa de la tecnología
CASE pro. El uso de la norma ISO / IEC TR 14471: 2007 ayudará
a maximizar el rendimiento y minimizar el riesgo de invertir en la
tecnología CASE. Sin embargo, la norma ISO / IEC TR 14471:
2007 no establece criterios El cumplimiento.
Se utiliza mejor en combinación con la norma ISO / IEC 14102
para la evaluación herramienta CASE y selección. Se dicta ni
tampoco aboga por normas particulares desarrollos Ment, procesos
de software, diseño met ods, metodologías, técnicas, lenguajes de
programación, o paradigmas del ciclo de vida.
B-20 Guía SWEBOK® V3.0
Dentro de un entorno de ingeniería de software, es importante
para las diversas herramientas para interoperar. Las siguientes
normas proporcionan un esquema para la interconexión.
IEEE Std. 1.175,1-2002 Guía para la caja de herramienta
Interconexiones-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,
sobre 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:
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 la norma ISO 9001: 2000 para Programas informáticos
ISO / IEC 90003 proporciona una guía para organiza- ciones
en la aplicación de la norma ISO 9001: 2000 para la
adquisición, suministro, desarrollo, operación y mantenimiento
de software y servicios de apoyo relacionados. ISO / IEC
90003: 2004 no se suma a cambiar o no los requisitos de la
norma ISO 9001: 2000. Las directrices proporcionadas
en ISO / IEC
90003: 2004 no están destinados a ser utilizados como criterios
Assessment en la gestión de la calidad del sistema de registro /
certificación.
La aplicación de la norma ISO / IEC 90003: 2004 es apropiado
para el software que es
• parte de un contrato comercial con otra
organización,
• un producto disponible para un sector del mercado,
• utilizado para apoyar los procesos de una
organización,
• incrustado en un producto de hardware, o
• en relación con los servicios de software.
Algunas organizaciones pueden estar involucrados en todas las
actividades mencionadas; otros pueden especializarse en un área. Sea
cual sea la situación, el sistema de gestión de calidad de la organiza-
ción debe cubrir todos los aspectos (relacionados con el software y
nonsoftware relacionado) de la empresa.
ISO / IEC 90003: 2004 identifica las cuestiones que deben
abordarse y es independiente de la tecnología de procesos,
modelos de ciclo de vida, Desa- Ment, secuencia de
actividades y estructura organizativa utilizada por una
organiza- ción. orientaciones adicionales y referen- cias
frecuente a las normas de ingeniería de software 7 1 / SC
ISO / IEC JTC se proporcionan para ayudar en la aplicación
de la norma ISO 9001: 2000: en particu- lar, ISO / IEC 12207,
ISO / IEC TR 9126, ISO / IEC 14598, ISO / IEC 15939 y ISO /
IEC TR
15504.
El enfoque de la ISO 9001 postula un proceso de gestión de la
calidad a nivel de organiza- ción junto con la planificación de la garantía
de calidad a nivel de proyecto para alcanzar los objetivos de la
organización. IEEE 730 describe la planificación de la calidad a nivel de
proyecto. Es

Actualmente alineado con una edición obsoleta de
12207, pero se está preparando una revisión.
IEEE Std. 730-2002 estándar para los planes de garantía de calidad de
software
La norma especifica el formato y contenido de los planes de
aseguramiento de la calidad del software.
Otro punto de vista de la calidad del software comienza con la
enumeración de las características deseadas de un producto de
software y la selección de las medidas u otras evaluaciones para
determinar si se ha alcanzado el nivel deseado de características.
La serie de llamados (requisitos de calidad del producto de
software y evaluación) cuadrados de normas SC 7 cubre este
enfoque en gran detalle.
ISO / IEC 25000 25099 a través de software de ingeniería y 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 docu- mentos,
permitiendo a los usuarios de esta guía una buena comprensión
de las normas internacionales. Este documento contiene una
explicación del proceso de tran- sición entre la antigua norma
ISO / IEC 9126 y la 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.
Apéndice B B-21
cuadrados ofrece
• Términos y definiciones,
• modelos de referencia,
• guías
• normas para los requisitos de la especificación con
fines de evaluación, planificación y gestión, medición
y.
El próximo estándar cuadrados proporciona una Omy taxón de las
características de calidad de software que puede ser útil en la selección de
características relevantes para un proyecto específico:
ISO / IEC 25010: 2011 Sistemas y de Ingeniería de
Software-Systems y requisitos de calidad de software y
Evaluación (cuadrados) -Sistema y modelos de calidad del
software
ISO / IEC 25010: 2011 define lo siguiente:
1. Una calidad en uso modelo compone de cinco
características (algunas de las cuales se subdividen
en subcaracterísticas) ese
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
com- pleta, 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.
B-22 Guía SWEBOK® V3.0
Aunque el alcance del modelo de calidad del producto está
destinado a ser software y sistemas informáticos, muchas de las
características también son Evant rel a los sistemas y servicios más
amplios.
ISO / IEC 25012 contiene un modelo para dad datos cali- que
es complementaria a este modelo. El alcance de los modelos
excluye propiedades puramente funcionales, pero incluye
idoneidad funcional.
El ámbito de aplicación de los modelos de calidad incluye el apoyo
a la especificación y evaluación de software y de software intensivo
Systematic informáticos TEMS desde diferentes perspectivas por
aquellos que están asociados con su adquisición, requisitos,
desarrollo, uso, evaluación, apoyo, manteni- miento, la calidad
aseguramiento y control y auditoría. Los modelos pueden ser, por
ejemplo, ser usado para operadores desa-, adquirentes, garantía de
calidad y personal de control, y los evaluadores independientes, en
particular los responsables de especificar y evaluar la calidad del
producto de software. Las actividades durante el desarrollo de pro-
ducto que pueden beneficiarse de la utilización de los modelos de
calidad incluyen
• la identificación de los requisitos de software y del sistema;
• la validación de la amplitud de una definición de los
requisitos;
• la identificación de objetivos y de software de diseño de sistemas;
• la identificación de objetivos y pruebas del software del sistema;
• la identificación de los criterios de control de calidad como parte de
la garantía de calidad;
• la identificación de los criterios de aceptación para un producto de
software y / o el sistema informático de software intensivo;
• el establecimiento de medidas de calidad tics carac- en
apoyo de estas actividades.
Algunos documentos de la serie tratan cuadrados específica- mente
con la característica de facilidad de uso. El formato de la Industria común
(CIF) para ING usabilidad informe- comenzó en el Instituto Nacional de
Estándares y Tecnología (NIST) de Estados Unidos y se trasladó a la
norma ISO / IEC JTC 1 / SC 7 para fines de estandarización.
ISO / IEC 25060 25064 a través de software de ingeniería y
software Requisitos de calidad del producto y
Evaluación del formato (cuadrados) Industria -Common (CIF) de la
Usabilidad
Una familia de estándares internacionales, designados con
la industria de formatos comunes (CIF), documenta la
especificación y evaluación de la usabilidad de los sistemas
interactivos. Proporciona una visión general general del
marco CIF y contenidos, defini- ciones, y la relación de
mentos el marco ele-. Los usuarios previstos del marco se
identifican, así como las situaciones en las que el marco se
puede aplicar. Los supuestos y las limitaciones del marco
también se enumeran. El contenido de marco incluye lo
siguiente:
• terminología coherente y clasificación de especificación,
evaluación y presentación de informes;
• una definición del tipo y alcance de los formatos y la
estructura de alto nivel que se utilizará para documentar la
información requerida y los resultados de la evaluación.
La familia de normas CIF es aplicable a los productos de software y
hardware utilizados para la pre- tareas definidas. Los elementos de
información están destinadas a ser utilizado como parte de la
documentación de nivel de sistema resultante de los procesos de
desarrollo tales como los que en la norma ISO 9241 a 210 y ISO / IEC
JTC 1 / SC estándares 7 de proceso.
La familia CIF centra en documentar aquellos elementos
necesarios para el diseño y desarrollo de sistemas utilizables,
en lugar de prescribir un proceso específico. Está destinado a
ser utilizado en conjunción con las normas internacionales
existentes, INCLUYENDO ISO 9241, ISO 20282, ISO / IEC
9126, y la serie cuadrada (ISO / IEC 25000 a ISO / IEC
25099).
La familia de normas CIF no prescribe ningún tipo de
método, ciclo de vida o proceso.
No todo el mundo está de acuerdo con la taxonomía de las
características de calidad en la norma ISO / IEC 25010. La norma tiene
un factor de calidad llamado “fiabilidad” que tiene subfactores de la
madurez, disponibilidad, tolerancia a fallos, y capacidad de
recuperación. IEC TC 65, que es responsable de las normas sobre
“dad dependabil-,” define este término como un com- puesto no
cuantitativo de fiabilidad, facilidad de mantenimiento y soporte de
manteni- miento. Otros utilizan el término “fiabilidad”

para denotar una medida definida por una ecuación matemática. El
desacuerdo sobre el uso de estas palabras significa que las normas
sobre la materia son inherentemente no alineado. Unos pocos se verá
más adelante, pero las palabras como los mencionados más arriba
pueden tener diferentes significados en diferentes estándares.
IEEE Std. 982,1-2.005 estándar para Diccionario de Medidas de
los aspectos del software de Fiabilidad
Un diccionario estándar de las medidas de los aspectos del
software de fiabilidad para evaluar y predecir la fiabilidad, facilidad
de mantenimiento, y la disponibilidad de cualquier sistema de
software; en particular, se aplica a los sistemas de software de
misión crítica.
IEEE Std. 1633-2008 Práctica Recomendada para la fiabilidad del
software
Los métodos para evaluar y predecir la fiabilidad del software, basado
en un enfoque de ciclo de vida para la ingeniería de la fiabilidad del
software, se prescriben en esta práctica recomendada. Se proporciona
la información necesaria para la aplicación de la fiabilidad del software
de medición (SR) a un proyecto, establece una base para la
construcción de métodos consistentes, y establece el principio básico
para la recogida de los datos necesarios para evaluar y predecir la
fiabilidad del software. La práctica recomendada prescribe cómo
cualquier usuario puede participar en las evaluaciones y predicciones
SR.
IEEE tiene un estándar global para la calidad del producto
de software que tiene un alcance similar a la serie 250xx ISO /
IEC descrito previamente. Su terminología difiere de la serie
ISO / IEC, pero es sustancialmente más compacto.
IEEE Std. 1061-1998 Estándar de Calidad de Software Metodología
Métrica
se define una metodología para establecer los requisitos de
calidad y definición, ejecución, análisis y validación de las
métricas de calidad de proceso y de producto de software. La
metodología abarca todo el ciclo de vida del software.
Apéndice B B-23
Un enfoque para el logro de la calidad del software es llevar a
cabo un amplio programa de verificación y validación. IEEE Std.
1012 es probablemente estándar más ampliamente aplicada del
mundo en esta sub-Ject. Una revisión se publicó recientemente.
IEEE Std. 1012-2012 estándar para el sistema y la verificación y
validación de software
Verificación y validación procesos (V & V) se utilizan para
determinar si el desarrollo Pro- ductos de una actividad dada
ajustarse a las exigencias de que la actividad y si el producto
cumple su uso previsto y las necesidades del usuario. requisitos
del proceso de ciclo de vida de V & V se especifican para niveles
de integridad de dife- rentes. El alcance de los procesos de V & V
abarca sistemas, software y hardware, e incluye sus interfaces.
Esta norma se aplica a los sistemas, el software y el hardware se
está desarrollando, mantenida o reutilizados [legacy, comercial
plataforma frente-el-(COTS), artículos nondevelopmental]. El
término software también incluye el firmware y el microcódigo, y
cada uno de los términos del sistema, software y hard- ware
incluye documentación. procesos de V & V incluyen el análisis,
evaluación, revisión, inspec- ción, evaluación, y el ensayo de los
productos.
Hay otras normas que apoyan los procesos ficación y
validación veri. Uno describe las técnicas para llevar a cabo
revisiones y auditorías durante un proyecto de software.
IEEE Std. 1028-2008 estándar para las revisiones de software y auditorías
Cinco tipos de revisiones de software y auditorías, así como los
procedimientos necesarios para la ejecu- ción de cada tipo, se
definen en la presente norma. Esta norma se refiere únicamente a
las revisiones y 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.
B-24 Guía SWEBOK® V3.0
En muchos casos, una base de datos de software de anoma-
reside se utiliza para apoyar las actividades de verificación y
validación. La siguiente norma sugiere cómo deben clasificarse
anomalías.
IEEE Std. 1044-2009 norma para la clasificación para el software de
anomalías
Esta norma proporciona un enfoque uniforme para la clasificación de las
anomalías de software, independientemente del momento en que se
originan o cuando se encuen- cados dentro del ciclo del proyecto,
producto o sistema de vida. Los datos de clasificación pueden ser
utilizados para una varie- dad de propósitos, incluyendo causal defecto
análi- sis, gestión de proyectos, y la mejora de procesos de software (por
ejemplo, para reducir la probabilidad de inserción de defectos y / o
aumentar la probabilidad de detección de defectos temprano).
En algunos sistemas, una propiedad particular del software es
tan importante que requiere un tratamiento especial más allá de la
proporcionada por un programa de verificación y validación
convencional. El término emergente para este tipo de tratamiento es
“siste- mas de garantía de software.” Los ejemplos incluyen la
seguridad, la privacidad, de alta seguridad, y ultrareliability. La
norma 15026 está en desarrollo para hacer frente a tales
situaciones. La primera parte del estándar de cuatro partes ofrece la
terminología y los conceptos utilizados en las partes restantes. Fue
escrito antes de las otras partes y ahora está siendo revisada para
el acuerdo com- pleta con los otros.
IEEE Std. 15.026,1-2011 Trial-Uso Adopción estándar de la norma
ISO / IEC TR 15026-1: 2010 Sistemas y de Ingeniería de
Software-Sistemas y de Software Assurance-Parte 1: Conceptos y
Vocabulario
Este estándar de prueba de uso adopta la norma ISO / IEC TR
15026-1: 2010, que define los términos y esta- lishes un conjunto
amplio y organizado de los conceptos y sus relaciones para el software
y los sistemas de seguridad, estableciendo así una base para la
comprensión común de los conceptos y cen- tral principios de la norma
ISO / IEC 15026 a través de sus comu- nidades de usuarios.
Proporciona información a los usuarios de las partes subsecuentes de
la norma ISO / IEC 15026, incluyendo la
utilizar de cada parte y el uso combinado de múltiples partes. La
cobertura de la garantía para un servicio que es operado y
administrado de forma continua no está cubierto en la norma ISO / IEC
15026.
La segunda parte de la norma describe la estructura de un “caso
de aseguramiento”, que pretende ser un argumento estructurado que
la propiedad crítica se ha logrado. Es una generalización de diversos
constructos específicos de dominio como “casos de seguridad”.
IEEE Std. 15026,2-2.011 adopción del estándar ISO / IEC 15026-2:
2011 Sistemas y de Ingeniería de Software-Sistemas y de Software
Assurance-Parte 2: Aseguramiento de la caja
ISO / IEC 15026-2: 2011 es adoptada por esta Dard Están-. ISO / IEC
15026-2: 2011 especifica 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 aseguramiento y para faci-
comunicaciones tate interesados, las decisiones de ingeniería y otros
usos de los casos de aseguramiento. Un caso de aseguramiento
incluye un reclamo de primer nivel para una propiedad de un sistema o
producto (o un conjunto de reclamaciones), la argumentación
sistemática con respecto a esta reclamación, y la evidencia y
supuestos explícitos que subyacen a esta argumentación. Discutiendo
a través de múltiples niveles de las reivindicaciones subordinadas, esta
argumentación estructurado conecta la reclamación de nivel superior
para las pruebas y supuestos. casos de Aseguramiento generalmente
se desarrollaron para apoyar las reivindicaciones en áreas tales como
la seguridad, la fiabilidad, facilidad de mantenimiento, factores
humanos, operabilidad, y la seguridad, aunque estos casos de garantía
son a menudo llamados por los nombres más específicos, por ejemplo,
el caso de seguridad o la fiabilidad y facilidad de mantenimiento 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 son solamente

incidental. Por ejemplo, el sistema de control de vuelo de un avión de
pasajeros es fundamental para la seguridad, pero el horno microondas
no lo es. Convencionalmente, las diversas partes se asignan niveles
de criticidad “” para indicar su significación para el logro general de la
propiedad. La tercera parte de la ISO / IEC 15026 describe cómo se
hace. Esta parte será revisado para un mejor ajuste con el resto de la
norma 15026.
ISO / IEC 15026-3: 2011 Sistemas y de Ingeniería de Software-Sistemas
y de Software Assurance-Parte 3: Niveles de Integridad del sistema
ISO / IEC 15026-3: 2011 especifica el concepto de niveles de
integridad con los requisitos de nivel de integridad que se requieren
para ser reunido con el fin de mostrar el logro del nivel de integridad
correspondiente. Se coloca requisitos sobre y recomienda ods met
para la definición y el uso de los niveles de integridad y de sus
requisitos de nivel de integridad, incluyendo la asignación de niveles
de integridad a los sistemas, productos de artículos blandos, sus
elementos, y dependencias exter- nos pertinentes.
ISO / IEC 15026-3: 2011 es aplicable a los siste- mas de
software y está diseñada para uso por:
• definidores de los niveles de integridad, tales como organizaciones
de la industria y profesionales, organizaciones de estándares y
agencias gubernamentales;
• usuarios de los niveles de integridad como desarrolladores y
mantenedores, proveedores y compradores, usuarios y
asesores de sistemas o software, y para el puerto SUP-
administrativa y técnica de sistemas y / o productos de
software.
Un uso importante de los niveles de integridad es mediante pinzas
SUP- y adquirentes en los acuerdos; por ejemplo, para ayudar a
asegurar las características de seguridad, económico, o de seguridad
de un sistema o producto entregado. ISO / IEC 15026-3: 2011 no
prescribe un conjunto específico de los niveles de integridad o sus
requisitos de nivel de integridad. Además, no se pre- escriba la forma
en que el uso nivel de integridad se inte- rallado con el conjunto del
sistema o software inge- niería procesos del ciclo de vida.
ISO / IEC 15026-3: 2011 se puede utilizar solo o con otras
partes de la norma ISO / IEC 15026. Se puede utilizar con una
variedad de análisis de riesgos y desarrollo enfoques técnicos y
especializados. ISO / IEC
Apéndice B B-25
TR 15026-1 proporciona información y referencias adicionales para ayudar
a los usuarios de la norma ISO / IEC 15026-3: 2011. ISO / IEC 15026-3:
2011 no requiere el uso de los casos de aseguramiento descritos en la
norma ISO / IEC 15026-2, pero describe cómo los niveles de integridad y
de garantía de los casos pueden trabajar juntos, especialmente en la
definición de las especificaciones de los niveles de integridad o mediante
el uso de la integridad los niveles dentro de una parte de un caso de
aseguramiento.
La parte final de 15026 proporciona orientación adicional para la
ejecución de los procesos del ciclo de vida de 12207 y 15288 cuando
se requiere un sistema o software para conseguir una propiedad
importante.
ISO / IEC 15026-4: 2012 Sistemas y de Ingeniería de Software-Sistemas
y de Software Assurance-Parte 4: Control de calidad en el ciclo de vida
Esta parte de la norma ISO / IEC 15026 proporciona orientación y
recomendaciones para la realización de pro- cesos seleccionados,
actividades y tareas para los sistemas y productos de software que
requieren las reclamaciones de garantía de las propiedades seleccionadas
de una atención especial, llamadas propiedades críticas. Esta parte de la
norma ISO / IEC 15026 especifica una lista erty independiente prop- de
procesos, actividades y tareas para lograr la reclamación y mostrar el logro
de la reclamación. Esta parte de la norma ISO / IEC 15026 establece los
procesos, actividades, tareas, orientación y recomendaciones en el
contexto de un modelo de ciclo de vida definido y un conjunto de procesos
de ciclo de vida para el sistema y / o gestión del ciclo de vida del software.
Los estándares siguientes se ocupa de una seguridad que a menudo
se identifica como propiedad-crítico. Originalmente fue desarrollado en
cooperación con la industria de la energía nuclear de Estados Unidos.
IEEE Std. 1228-1994 estándar para los planes de seguridad del software
Se establecen los requisitos mínimos aceptables para el
contenido de un plan de seguridad de software. Esta norma
se aplica al plan de seguridad de software utilizado para el
desarrollo, adquisición, mantenimiento y retirada de software
crítico.
B-26 Guía SWEBOK® V3.0
Esta norma requiere que el plan se preparará en el marco del pro-
grama de seguridad del sistema. Sólo se incluyen los aspectos de
seguridad del software. Esta norma no contiene disposiciones
especiales que se requieren para el software utilizado en los
sistemas de distri- buido o en procesadores paralelos.
tratamientos clásicos sugieren que las ofertas de “verificación” con
métodos de evaluación estática y que ofertas de “prueba” con
métodos de evaluación dinámicos. tratamientos recientes, incluyendo
ISO proyecto / IEC
29119, están difuminando esta distinción, aunque, por lo que aquí se
mencionan las normas de ensayo.
IEEE Std. 829-2008 Norma para el software y la documentación de prueba
del sistema Consulte Software Testing KA
IEEE Std. 1008-1987 estándar para el software de pruebas unitarias
Consulte Software Testing KA
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 revisores de Documentación
Consulte Software Testing KA
/ / IEEE 29119 [cuatro partes] (Borrador) Software ISO IEC y Sistemas de
Pruebas de Ingeniería de Software
Consulte Software Testing KA
INGENIERÍA DE SOFTWARE LA
PRÁCTICA PROFESIONAL
IEEE es un proveedor de productos relacionados con el CER tificación de
los practicantes profesionales de la ingeniería de software. La primera ya
ha sido descrito, el Guía de la Ingeniería de Software de Administración de
Conocimiento. los Guía SWEBOK ha sido adoptado por la norma ISO / IEC
como un esquema de los conocimientos que los ingenieros de software
pro- fesionales deben tener.
ISO / IEC TR 19759: 2005 Ingeniería de Software-Guía de los
Fundamentos de Ingeniería de Software
Conocimiento (SWEBOK)
ver general
Un estándar de 7 SC proporciona un marco para las
comparaciones entre las certificaciones de profesionales de la
ingeniería de software. Que norma indica que las áreas
consideradas en la certificación debe estar asignado a la Guía
SWEBOK.
ISO / IEC 24773: 2008 Ingeniería de Software-Certificación de
Profesionales de Ingeniería de Software
ISO / IEC 24773: 2008 establece un marco para la comparación de
esquemas de certificación de profesionales de ingeniería de software.
Un esquema de certificación es un conjunto de requisitos de
certificación para profesionales de la ingeniería de software. ISO / IEC
24773: 2008 especifica los artículos que se requiere un esquema para
contener e indica lo que debe ser definida para cada elemento.
ISO / IEC 24773: 2008 facilitará la Porta- bilidad de
ingeniería de software tifications cier- profesionales entre los
diferentes países o organiza- ciones. En la actualidad,
diferentes países y organizaciones han adoptado diferentes
enfoques sobre el tema, que se implementan por medio de
reglamentos y estatutos. La intención de la norma ISO / IEC
24773: 2008 es estar abierto a éstos individual y específico se
acerca al proporcionar un marco para expresarlos en un
esquema común que puede conducir a la comprensión.
SC 7 está elaborando una guía que suplementar
24773.
ECONOMÍA INGENIERÍA DE SOFTWARE
No hay normas se asignan a este KA.
FUNDAMENTOS DE INFORMATICA
No hay normas se asignan a este KA.
Fundamentos matemáticos
No hay normas se asignan a este KA.

FUNDAMENTOS DE INGENIERÍA
No hay normas se asignan a este KA.
ACTUAL STAYING
Este artículo era obsoleto el momento en que se redactó.
Algunos lectores necesitan saber cómo conseguir designaciones
y descripciones de las normas vigentes. En esta sección se
describen algunos recursos útiles.
DONDE ENCONTRAR NORMAS
La lista de normas publicadas por ISO / IEC JTC 1 / SC 7 se
puede encontrar en Catálogo de www.iso.org/iso/iso_ /
catalogue_tc / catalogue_tc_browse. htm? commid = 45086.
Debido a que la URL puede cambiar, los lectores podrían tener que
desplazarse a la lista. comenzará a las iso www.iso.org/ / store.htm , A
continuación, haga clic en “Catálogo de estándares de exploración”, luego
“navegar por el TC,” y luego “JTC 1” y luego “SC 7.”
Encontrar la lista actual de normas para S2ESC es un poco
más difícil. comenzará a las http: // estándares. ieee.org/. En el
cuadro de búsqueda en “Buscar Standards,” tipo “S2ESC.” Esto
debería producir una lista de normas publicadas por el cual es
responsable S2ESC.
Tenga en cuenta que las bases de datos accesibles son compilaciones.
Al igual que cualquier base de datos, que pueden contener errores que
conducen a resultados de búsqueda incompletos.
DONDE OBTENER LAS NORMAS
Algunos lectores querrán obtener normas descritas en este
artículo. Lo primero que debe saber es que algunas normas
internacionales están disponibles gratuitamente para su uso
individual. La lista actualizada de las normas ISO / IEC
Guía SWEBOK, ISO / IEC TR 19759, es una de las normas de
disponible bajo los términos se encuentra en http://standards.iso.org/ittf/
PubliclyAvailableStandards / index.html.
Uno de los estándares disponibles públicamente es la adopción
de ISO / IEC de la Guía SWEBOK, ISO / IEC 19759.
Apéndice B B-27
Las definiciones contenidas en la norma ISO / IEC / IEEE
24765, Sistema y software de vocabulario, son libremente
disponibles en www.computer.org/sevocab.
Sin embargo, la gran mayoría de las normas no son libres. normas
ISO / IEC generalmente se compran desde el organismo nacional de
normalización del país en que se vive. Por ejemplo, en los EE.UU.,
las normas internacionales se pueden adquirir en el Instituto
Americano de Estándares Nacionales en http://webstore.ansi.org/ .
Alternativamente, Standards se pueden comprar directamente de
ISO / IEC en www.iso.org/iso/store.htm . Cabe señalar que cada
nación es libre de fijar sus propios precios, por lo que puede ser útil
para comprobar ambas fuentes. Los estándares IEEE pueden estar
disponibles para usted de forma gratuita si su empleador o la
biblioteca tiene una suscripción a IEEE Xplore: http://ieeexplore.ieee.org/
. Algunas suscripciones a Xplore proporcionan acceso sólo a los
resúmenes de las normas; El texto completo puede entonces ser
adquirido a través de Xplore. Alternativamente, las normas pueden
ser adquiridos a través de la tienda de los estándares IEEE en
www.techstreet.com/ieeegate.html . Cabe señalar que la IEEE-SA
veces haces las normas en los grupos disponibles con un descuento
considerable. Por último, el lector debe tener en cuenta que los
estándares IEEE que ha adoptado de ISO / IEC, las normas que la
norma ISO / IEC tiene “vía rápida” de la IEEE, y las normas que se
han desarrollado o se revisan en conjunto están disponibles de
ambas fuentes. Para todas las normas descritas en este artículo, la
versión IEEE y la versión ISO / IEC son sustancialmente idénticos.
Las versiones respectivas pueden tener diferentes frontal y la
materia de nuevo pero los cuerpos son idénticos.
DONDE VER LA GUÍA SWEBOK
los Guía SWEBOK se publica en virtud de un derecho de
autor IEEE. La versión actual de la Guía SWEBOK es
gratuita para el público en www. swebok.org/ . La adopción
de ISO / IEC de la
libre disposición.
B-28 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 software SW Calidad

IEEE Std. 828-2012 Norma para la Gestión de la Configuración de Sistemas e Gestión de la

Ingeniería de Software Configuración SW

IEEE Std. 829-2008 Norma para el software y la documentación de prueba del sistema
Prueba de SW

IEEE Std. 982,1-2.005 estándar para Diccionario de Medidas de los aspectos del
SW Calidad
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 la verificación y validación de software

SW Calidad

IEEE Std. 1016-2009 estándar para las descripciones Diseño Tecnología de la

SW Diseño
Información-Sistemas-Diseño de Software

IEEE Std. 1028-2008 estándar para las revisiones de software y auditorías SW Calidad

IEEE Std. 1044-2009 norma para la clasificación para el software de anomalías

SW Calidad

IEEE Std. 1061-1998 Estándar de Calidad de Software Metodología Métrica

SW Calidad

IEEE Std. 1062-1998 Práctica Recomendada para Ingeniería de Software de Adquisición de SW

administración

IEEE Std. 1074-2006 estándar para desarrollar un proceso del ciclo de vida del software del proyecto Proceso de Ingeniería de
SW

IEEE Std. 1.175,1-2002 Guía para el CASO Clasificación Interconnections- SW modelos de

herramienta y Descripción ingeniería y Métodos

IEEE Std. 1175,2-2.006 Práctica Recomendada para la caja de herramienta de SW modelos de

interconexión-Caracterización de las interconexiones ingeniería y Métodos

IEEE Std. 1.175,3-2004 estándar para la caja de herramienta Interconnections- modelo de referencia SW modelos de
para especificar el comportamiento del software ingeniería y Métodos

IEEE Std. 1.175,4 a 2.008 estándar para CASE Modelo de Referencia de herramientas SW modelos de
Interconnections- para su comportamiento Especificación ingeniería y Métodos

IEEE Std. 1220-2005 (también conocido como ISO / IEC 26702: 2007) estándar para la Proceso de Ingeniería de
aplicación y gestión del proceso de Ingeniería de Sistemas SW

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- sintaxis y la SW modelos de
semántica de IDEF0 ingeniería y Métodos

IEEE Std. 1320,2-1998 estándar para Modelado Conceptual Lenguaje- sintaxis y la SW modelos de
semántica de IDEF1X97 (IDEFobject) ingeniería y Métodos

IEEE Std. 1490-2011 Guía de implantación de la Gestión de Proyectos Institute (PMI ®)

Gestión de
estándar, una guía para la Dirección de Proyectos del Conocimiento (Guía del PMBOK®)
Ingeniería de SW
-Cuarto Edición

IEEE Std. 1517-2010 estándar para la tecnología de la información del sistema y del software-Vida Proceso de Ingeniería de
Procesos de reutilización de procesos de ciclo SW
 Apéndice B B-29

Número y Título (enumerados en orden de número) Más relevantes KA

IEEE Std. 1633-2008 Práctica Recomendada para la fiabilidad del software SW Calidad

IEEE Std. 12207-2008 (también conocido como ISO / IEC 12207: 2008) estándar para los sistemas y Proceso de Ingeniería de
software de ingeniería en software procesos de ciclo de vida SW

IEEE Std. 14102-2010 La adopción del estándar ISO / IEC 14102: 2008 Tecnología de la
SW modelos de
Información-Directrices para la evaluación y selección de herramientas CASE
ingeniería y Métodos

ISO / IEC 14143 [seis partes] Tecnología de la Información-funcional de software

Requisitos SW
de medición-Medida del tamaño

IEEE Std. 14471-2010 Guía de implantación de la norma ISO / IEC TR 14471: 2007 Tecnología de la
SW modelos de
Información-Ingeniería de Software-Directrices para la adopción de las herramientas CASE
ingeniería y Métodos

IEEE Std. 14764-2006 (también conocido como ISO / IEC 14764: 2006) estándar para

Software de ingeniería en software de ciclo de vida Procesos de mantenimiento Mantenimiento software IEEE Std.
15.026,1-2011 Trial-Uso Adopción estándar de la norma ISO / IEC TR 15026-1: 2010 Sistemas y de Ingeniería de
Software-Sistemas y de Software Assurance-Parte 1: Conceptos y Vocabulario SW Calidad

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 Assurance-Parte 2: Aseguramiento de la caja SW Calidad

ISO / IEC 15026-3 Sistemas y de Ingeniería de Software-Sistemas y de Software

SW Calidad
Assurance-Parte 3: Niveles de Integridad del sistema

ISO / IEC 15026-4: 2012 Sistemas y de Ingeniería de Software-Sistemas y de Software

SW Calidad
Assurance-Parte 4: Control de calidad en el ciclo de vida

IEEE Std. 15288-2008 (también conocido como ISO / IEC 15288: 2008) Estándar de Sistemas e Proceso de Ingeniería de
Ingeniería de Software-Sistema de los procesos de ciclo de vida SW

ISO / IEC / IEEE 15289: 2011 Sistemas y Software Ingeniería- contenido del Ciclo de Proceso de Ingeniería de
Vida de Productos de Información (Documentación) SW

ISO / IEC 15504 [diez partes] Tecnología-Proceso de Información de Evaluación Proceso de Ingeniería de
SW

IEEE Std. 15939-2008 La adopción del estándar ISO / IEC 15939: 2007 Sistemas y Gestión de
Procesos de Ingeniería de Software de Mediciones Ingeniería de SW

ISO / IEC 15940: 2006 Tecnología de la Información-Ingeniería de Software Environment SW modelos de

Services ingeniería y Métodos

IEEE Std. 16085-2006 (también conocido como ISO / IEC 16085: 2006) Gestión de Riesgo
Gestión de
Estándar de Sistemas e Ingeniería de Software-Software Ciclo de Vida procesos-
Ingeniería de SW

ISO / IEC / IEEE 16326: 2009 de Gestión de Sistemas y de Ingeniería de Software-Life Gestión de
Cycle Procesos-Proyecto Ingeniería de SW
ISO / IEC 19501: 2005 Tecnología de la Información-distribuido abierto Modeling SW modelos de
Language (UML) Versión 1.4.2 Procesamiento-Unificado ingeniería y Métodos
B-30 Guía SWEBOK® V3.0

Número y Título (enumerados en orden de número) Más relevantes KA

ISO / IEC 19505: 2012 [dos partes] a objetos Grupo de Tecnología de Gestión de SW modelos de
Información Unified Modeling Language (UML del OMG) ingeniería y Métodos

ISO / IEC 19506: 2012 Tecnología de la Información-Object Management Group

SW modelos de
arquitectura dirigida Modernización (ADM) -Conocimiento Descubrimiento Meta-Modelo
ingeniería y Métodos
(KDM)

ISO / IEC 19507: 2012 Tecnología de la Información-Object Management Group Object SW modelos de
Constraint Language (OCL) ingeniería y Métodos

ISO / IEC TR 19759: 2005 Ingeniería de Software-Guía de la Ingeniería de Software de

[General]
Administración de Conocimiento (SWEBOK)

ISO / IEC 19761: 2011 Ingeniería de Software-CÓSMICO: Un Tamaño Funcional Método de

Requisitos SW
medición

ISO / IEC 20000-1: 2011 Tecnología de la Información-Servicio de Gestión-Parte 1: Proceso de Ingeniería de

Requisitos del sistema de gestión de servicios SW

ISO / IEC 20926: 2009 Software e Ingeniería de Sistemas-Software-Medición

Requisitos SW
IFPUG funcional Tamaño Método de medición
ISO IEC 20968/2002: Manual de Prácticas de Análisis de Puntos de Función de conteo de
Requisitos SW
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 Lineamientos contando para la Aplicación del Requisitos SW
Análisis de Puntos de Función

IEEE Std. 24.748,1-2011 Guía de implantación de la norma ISO / IEC TR 24748-1: 2010 Sistemas y
Proceso de Ingeniería de
de Ingeniería de Software de Gestión-Life-Cycle Parte 1: Guía para la Gestión del Ciclo de Vida
SW

IEEE Std. 24748,2-2012 Guía de implantación de la norma ISO / IEC TR 24748-2: 2011 Sistemas y de
Ingeniería de Software de Gestión de Vida-Parte 2 Ciclo: Guía para la aplicación de la norma ISO / IEC Proceso de Ingeniería de
15288 (Procesos del ciclo de vida del sistema) SW

IEEE Std. 24748-3: 2012 Guía de implantación de la norma ISO / IEC TR 24748-3: 2011 Sistemas y de
Ingeniería de Software de Gestión-Life-Cycle Parte 3: Guía para la aplicación de la norma ISO / IEC Proceso de Ingeniería de
12207 (Procesos del ciclo de vida del software) SW

ISO / IEC / IEEE 24765: 2010 Sistemas y de Ingeniería de

[General]
Software-Vocabulario

ISO / IEC TR 24772: 2013 Tecnología de la información-Lenguajes de Programación -

Orientación para evitar vulnerabilidades en lenguajes de programación a través de selección Construcción SW
de idioma y Uso

ISO / IEC 24773: 2008 Ingeniería de Software-Certificación de Profesionales de Ingeniería de SW Ingeniería Práctica
Software Profesional
IEEE Std. 24774: 2012 Guía de implantación de la norma ISO / IEC TR 24474: 2010 Sistemas y
Proceso de Ingeniería de
de Ingeniería de Software-Life Cycle Directrices para Management- Descripción del Proceso
SW

ISO / IEC 25000: 2005 Software de ingeniería y software Requisitos de calidad del producto
SW Calidad
y Evaluación (cuadrados) -Guía de cuadrar
 Apéndice B B-31

Número y Título (enumerados en orden de número) Más relevantes KA

ISO / IEC 25000 25099 a través de software de ingeniería y software Requisitos de

SW Calidad
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 y modelos de calidad del software SW Calidad

Formato ISO / IEC 25060 25064 a través de software de ingeniería y software Requisitos de
calidad del producto y Evaluación (cuadrados) Industria -Common (CIF) de la Usabilidad SW Calidad

ISO / IEC / IEEE 26511: 2012 Sistemas y Software INGENIERÍA-Requisitos para los Gestión de
gerentes de Documentación del usuario Ingeniería de SW
ISO / IEC / IEEE 26512: 2011 Requisitos de Sistemas y Software ingeniería- para Gestión de
adquirentes y proveedores de Documentación del usuario Ingeniería de SW
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 revisores de Documentación Prueba de SW

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 desarrolladores de documentación del usuario SW Diseño

ISO / IEC / IEEE 26515: 2012 Sistemas y Software Ingeniería- desarrollo de la SW modelos de
documentación del usuario en un entorno ágil ingeniería y Métodos

ISO / IEC 29110 [varias partes] Ingeniería de Software-ciclo de vida de los perfiles de Proceso de Ingeniería de
entidades muy pequeñas (VSE) SW

/ / IEEE 29119 [cuatro partes] (Borrador) Software ISO IEC y Sistemas de Pruebas de
Prueba de SW
Ingeniería de Software

/ IEC / IEEE 29148 ISO: 2011 Sistemas y de Ingeniería de Software-Life Cycle procesos
Requisitos SW
de Ingeniería de Requisitos

ISO / IEC / IEEE 42010: 2011 Sistemas y Software Ingeniería- Arquitectura

SW Diseño
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 la norma ISO 9001: 2000 para Programas informáticos SW Calidad
 APÉNDICE C
LISTA DE REFERENCIA CONSOLIDADO
La lista de referencias consolidado identifica todos los materiales
de referencia recomendados (a nivel de número de sección) que
acompañan a la descomposición de los temas dentro de cada área
de conocimiento (KA). Esta lista de referencias consolidado es
adoptada por la certificación de ingeniería de software y productos
asociados de desarrollo profesional ofrecido por el IEEE Computer
Society. Editores KA utilizan las referen- cias asignadas a su KA
por la Lista de referencia consolidado como sus referencias
recomendadas. En conjunto esta lista de referencia es consolidado
• Completar: Cubriendo todo el ámbito de la
Guía SWEBOK.
• Suficiente: Proporcionar suficiente información para describir
“generalmente aceptadas” conocimiento.
• Consistente: No es proporcionar conocimientos
contradictorios ni prácticas conflictivas.
• Creíble: Reconocido como proporcionar tratamiento experto.
• Actual: Tratar el tema de una manera que sea acorde con
los conocimientos actualmente generalmente aceptada.
• Sucinta: Lo más corto posible (tanto en nú- mero de
elementos de referencia y en el número total de páginas)
sin fallar otros objetivos.
[1 *] JH Allen et al., software de Seguridad  Elementos de software reutilizables orientada a
Ingeniería: Guía para los gerentes de
proyecto, Addison-Wesley, 2008.
[2 *] M. Bishop, Seguridad informática: Arte y  [12 *] P. Grubb y AA Takang, Software
Ciencia, Addison-Wesley, 2002.
[3 *] B. Boehm y R. Turner, agilidad Equilibrio 
y Disciplina: Una Guía de los Perplejos,
Addison-Wesley, 2003.
C-1
[4 *] F. Bott et al., Cuestiones profesionales en 
Ingeniería de software, 3ª ed., Taylor & Francis,
2000.
[5 *] JG Brookshear, Ciencias de la Computación: Un 
Visión de conjunto, 10ª ed., Addison-Wesley, 2008.
[6 *] D. Budgen, Diseño de software, 2ª ed.,
Addison-Wesley, 2003.
[7 *] EW Cheney y DR Kincaid, Numérico 
Matemáticas y Computación, 6ª ed., Brooks /
Cole, 2007.
[8 *] P. Clements et al., Software de documentación 
Vistas: arquitecturas y más allá, 2ª ed., Pearson
Education, 2010.
[9 *] RE Fairley, La gestión y líder 
Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009.
[10 *] D. Galin, Calidad de Software: 
De la Teoría a la implementación, Pearson
Educación, SA, 2004.
[11 *] E. Gamma et al., Patrones de diseño: 
objetos, 1ª ed., Addison-Wesley Professional, 1994.
 
Mantenimiento: Conceptos y práctica, 2ª ed.,
Editorial Científico Mundial, 2003.
[13 *] AMJ Hass, Gestión de la configuración 
Principios y Prácticas, 1ª ed., Addison-Wesley,
2003.
C-2 Guía SWEBOK® V3.0

[14 *] E. Horowitz et al., Los algoritmos de ordenador, [25 *] S. Naik y P. Tripathy, Pruebas de software 
2ª ed., Silicon Press, 2007. y aseguramiento de la calidad: teoría y
práctica, Wiley-Spektrum, 2008.
[15 *] IEEE CS / ACM Grupo de Trabajo Conjunto sobre

Ética de software de ingeniería y prácticas [26 *] J. Nielsen, Ingeniería de usabilidad, primera ed.,
profesionales, “software de código de Ingeniería de Morgan Kaufmann, 1993.
Ética y Práctica Profesional (Versión 5.2),” 1999;
[27 *] L. Null y J. Lobur, Lo Esencial de la 
www.acm.org/serving/se/code.htm . Organización ordenador y Arquitectura,
2ª ed., Jones and Bartlett Publishers,
[dieciséis*] IEEE Std. 828-2012, Norma para  2006.
Gestión de la Configuración en Sistemas e Ingeniería
de Software, IEEE 2012. [28 *] M. Página-Jones, Fundamentos de objeto-
Diseño orientado en UML, 1ª ed., Addison-Wesley,
[17 *] IEEE Std. 1028-2008, Reseñas de Software  1999.
y Auditorías, IEEE 2008.
[29 *] K. Rosen, Matemática Discreta y sus
[18 *] ISO / IEC 14764 IEEE Std. 14764-2006,  Aplicaciones, 7ª ed., McGraw-Hill, 2011.
Software de ingeniería en software de ciclo de vida Procesos
de mantenimiento, IEEE 2006. [30 *] A. Silberschatz, PB Galvin, y G.
Gagne, Conceptos del sistema operativo, Octava ed.,
[19 *] SH Kan, Métricas y modelos de software  Wiley, 2008.
Ingeniería de calidad, 2ª ed., Addison-Wesley,
2002. [31 *] HM Sneed, “Software Ofreciendo
Mantenimiento como un servicio Marino,” Proc. IEEE Conf
[20 *] S. McConnell, Código completo, 2ª ed., Int'l. Mantenimiento del software
Microsoft Press, 2004. (ICSM 08), IEEE, 2008, pp. 1-5.

[21 *] J. McGarry et al., Practical Software  [32 *] I. Sommerville, Ingeniería de software, noveno
Medición: información objetiva para la Toma de ed., Addison-Wesley, 2011.
Decisiones, Addison-Wesley Professional, 2001.
[33 *] S. Tockey, Retorno de software: 
Maximizar el retorno de su inversión en software, 1ª
[22 *] SJ Mellor y MJ Balcer, Ejecutable  ed., Addison-Wesley, 2004.
UML: La Base para Model-Driven
Architecture, 1ª ed., Addison-Wesley, [34 *] G. Voland, Ingeniería de Diseño, segundo
2002. ed., Prentice Hall, 2003.

[23 *] DC Montgomery y GC Runger, [35 *] KE Wiegers, Requisitos de Software, segundo

Aplicada Estadística y Probabilidad para ed., Microsoft Press, 2003.
Ingenieros, 4ª ed., Wiley, 2007.
[36 *] JM Wing, “Introducción de un especificador de
[24 *] JW Moore, La hoja de ruta de software  Métodos formales,” Computadora, vol. 23, no. 9,
Ingeniería: Una guía basada en estándares, 1ª ed., 1990, pp. 8, 10-23.
Wiley-IEEE Computer Society Press,
2006.