Sie sind auf Seite 1von 335

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 En 1958, John Tukey, la istician stat- de renombre mundial, acuñó el
que el conocimiento no siempre se define de una manera concisa. En término software. ingeniería de cerámica El término blandas se utiliza en
los casos en que no existe ninguna formalidad, el cuerpo de el título de una conferencia de la OTAN celebrada en Alemania en 1968.
conocimiento se “GEN-ralmente reconocido” por los médicos y puede El IEEE Computer Society publicó por primera vez su Las transacciones
ser codificado en una variedad de formas para una variedad de usos en Ingeniería de Software en 1972, y una camiseta de compromiso para
diferentes. Pero en muchos casos, una guía para un cuerpo de el desarrollo de la ingeniería de software Dardos Están- se estableció
conocimiento se documenta formalmente, el aliado no baja en una dentro de la IEEE Computer Society en 1976.
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 En 1990, se inició la planificación para una norma interna- cional
asociación profesional u organismo similar mantiene la administración para proporcionar una visión global de ingeniería de soft- ware. El
de la definición formal de un conjunto de conocimientos. 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
Durante los últimos cuarenta y cinco años, la ingeniería de software ha conocimientos capturado en SWEBOK 2004. La versión actual de
evolucionado a partir de una frase conferencia Catch en una profesión de 12207 se designa como ISO / IEC 12207: 2008 e IEEE 12.207 a
la ingeniería, caracteriza- da por la 1) una sociedad profesional, 2) las 2.008; que proporciona la base para este V3 SWEBOK. Esta Guía
normas que especifican las prácticas profesionales generalmente de la Ingeniería de Software de Administración de Conocimiento se
aceptadas; presenta a usted, el lector, como un mecanismo para adquirir los
3) un código de ética, 4) actas de la conferencia, conocimientos que necesita en su desarrollo de carrera de toda la
5) libros de texto, 6) directrices del plan de estudios y planes de vida como un profesional de la ingeniería de software.
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; Dick Fairley, Presidente

esta versión revisada y actualizada se denota SWEBOK V3. Este Software y Comité de Ingeniería de Sistemas
trabajo está en cumplimiento parcial de la responsabilidad de la IEEE Computer Society
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 Don Shafer, vicepresidente
ingeniería de soft- ware sino que sirve como guía para el conjunto de Junta actividades profesionales
conocimientos que se ha desarrollado durante más de cuatro IEEE Computer Society
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
Prólogo a la edición de 2004

En esto Guía, lishes la IEEE Computer Society esta- por primera normas. Estos talleres involucrados ners practitio- compartiendo sus
vez una línea de base para el conjunto de conocimientos para el experiencias con los Standards existentes. Los talleres también se
campo de la ingeniería de software, y el trabajo cumple llevaron a cabo sesiones sobre la Planificación de las normas futuras,
parcialmente la responsabilidad de la sociedad para promover el incluyendo uno que incluya las medidas y métricas para la ingeniería
avance de la teoría y la práctica en este campo. De este modo, la de software de productos y procesos. La planificación también resultó
Sociedad se ha guiado por la experiencia de disciplinas con en IEEE Std. 1002, Taxonomía de los Estándares de Ingeniería de
historias más largas, pero no estaba vinculado por sus Software ( 1986), que proporciona una nueva visión, holística de
problemas o sus soluciones. Cabe señalar que la Guía no PUR ingeniería de software. La norma describe la forma y el contenido de
puerto para definir el conjunto de conocimientos, sino más bien las normas de ingeniería de un soft- ware taxonomía. Se explican los
para servir como un compendio y guiar al cuerpo de diferentes tipos de Dardos de ingeniería de software Están-, sus
conocimiento que se ha ido desarrollando y en evolución ing en relaciones funcionales y externos, y el papel de las diversas
las últimas cuatro décadas. Por otra parte, este conjunto de funciones que participan en el ciclo de vida del software.
conocimientos no es estática. los Guía

debe, necesariamente, desarrollar y evolucionar a medida que madura la En 1990, se inició la planificación para un Dard Están-
ingeniería de software. Sin embargo, constituye un valioso elemento de internacional con una visión de conjunto. El la Planificación centrada
la infraestructura de la ingeniería de software. 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.
En 1958, John Tukey, la istician stat- de renombre mundial, Departamento de Defensa. La revisión fue publicada como aliado
acuñó el término software. El termino Ingeniería de software se eventu- DoD Std. 498. La norma internacional se completó en 1995
utilizó en el título de una conferencia de la OTAN celebrada en con la denomina- ción, ISO / IEC 12207, y se le dio el título de Dard
Alemania en 1968. El IEEE Computer Society publicó por primera Están- para los procesos de ciclo de vida del software. Std. ISO / IEC
vez su Las transacciones en Ingeniería de Software en 1972. El 12207 proporciona un importante punto de partida para el conjunto
comité establecido en la IEEE Computer Society para el desarrollo de conocimientos capturados en este libro. Era la Junta IEEE
de estándares de ingeniería de software fue fundada en 1976. 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
La primera visión integral de ingeniería de software para salir de Machinery Consejo (ACM) aprobó una moción relacionada en agosto
la IEEE Computer Society fue resultado de un esfuerzo dirigido por de 1993. Los dos movimientos condujeron a un comité conjunto bajo
Fletcher Buckley para desarrollar el estándar IEEE 730 para el la dirección de Mario Barbacci y Stuart Zweben que sirvió como
software de cali- dad de aseguramiento, que se completó en 1979. copresidentes. La declaración de la misión de la comisión conjunta
El propósito de la norma IEEE Std. 730 era proporcionar uniformes, era “Establecer los conjuntos apropiados (s) de criterios y normas
requisitos mínimos aceptables para la preparación y el contenido para la práctica profesional de la ingeniería de software sobre el cual
de los planes de ANCE assur- de calidad de software. Esta norma siones industriales terio, la certificación profesional, y los programas
fue influyente en com- pletar las normas de desarrollo de los de estudio se pueden basar.” El comité directivo grupos de trabajo
siguientes temas: gestión de configuración, software de Exámenes, organizados en las siguientes áreas:
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 1. Definir Obligatorio cuerpo de conocimientos y métodos
de la ingeniería de software recomendados.

xix
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 Thom Schoeffling, EE.UU. Reinhard


Mead, EE.UU. Schrage, Alemania Neetu Sethia,
Fuensanta Medina-Domínguez, España Silvia India Cindy C. Shelton, EE.UU. Alan
Judith Meles, Argentina Oscar A. Mondragon, Shepherd, Alemania Katsutoshi
México David W. Mutschler, EE.UU. Maria Shintani, Japón Erik Shreve, EE.UU.
Nelson, Brasil, John Noblin, EE.UU. Bryan G. Jaguaraci Silva, Brasil
Ogihara, EE.UU. Takehisa Okazaki, Japón Hanna
Oktaba, México Chin Hwee Ong, Hong Kong
Venkateswar Oruganti, India Birgit Penzenstadler, M. Somasundaram, India Peraphon
Alemania Larry Peters, EE.UU. 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.

SK Pillai, India Vaclav Rajlich,


EE.UU. Kiron Rao, India Luis
Reyes, EE.UU. Hassan Reza, J. Barrie Thompson, Reino Unido

EE.UU. Steve Roach, EE.UU. Steve Tockey, EE.UU.

Teresa L. Roberts, EE.UU. Miguel Eduardo Torres Moreno, Colombia Dawid


Dennis Robi, EE.UU. Trawczynski, EE.UU. Adam Trendowicz, Alemania Norio
Ueno, Japón Cenk Uyan, Turquía Chandra Sekar
Virappan, Singapur Oruganti Venkateswar, India Jochen
Warren E. Robinson, EE.UU. Jorge L. Vogt, Alemania Hironori Washizaki, Japón Ulf
Rodriguez, EE.UU. Alberto C. Sampaio, Westermann, Alemania Don Wilson, EE.UU. Aharon
Portugal Ed Samuels, EE.UU. Yadin, Israel Hong Zhou, Reino Unido

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
EXPRESIONES DE GRATITUD

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

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
literatura. El propósito de Guía es describir la parte del
Software Cuerpo de Ingeniería del
SWEBOK cuerpo de conocimientos que se gene- ralmente
Conocimiento
aceptada, para organizar esa porción, y para
proporcionar acceso tópica a la misma. los Guía de la
Publicación de la versión de este 2004 Guía de la Ingeniería de swebok (Guía SWEBOK) se estableció con los cinco
Software de Administración de Conocimiento ( SWE- BOK 2004) fue un objetivos siguientes:
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, 1. Promover una visión consistente de la ingeniería de software en
consistencia y facilidad de uso de la Guía. todo el mundo
2. Para especificar el alcance de, y aclarar el lugar de la
Todas las áreas de conocimiento (KAS) se han actualizado para ingeniería de software con respecto a otras disciplinas
reflejar los cambios en la ingeniería de software desde la publicación como la informática, la gestión del pro- yecto, ingeniería
de SWEBOK 2004. Cuatro nuevos dación Fun- KAs y una Ingeniería informática y matemáticas
de Software Prácticas Profe- sional KA se han añadido. Las
herramientas de ingeniería de software y métodos KA ha sido 3. Caracterizar los contenidos de la disciplina de la ingeniería
revisada como modelos y métodos de ingeniería de software. de software
herramientas de ingeniería de software es ahora un tema en cada 4. Proporcionar un acceso tópica en la Ingeniería de Software de

una de la KAS. Tres apéndices proporcio- nar las especificaciones Administración de Conocimiento

para la descripción KA, un conjunto anotada de normas relevantes 5. Proporcionar una base para el desarrollo curricular y
para cada KA, y una lista de las referencias citadas en el Guía. para la certificación individual y material de licencias

Esta Guía, escrita bajo los auspicios de la Junta de Actividades El primero de estos objetivos, una amplia visión del mundo
Profesionales de la Sociedad IEEE orde- nador, representa un coherente de ingeniería de software, fue apoyada por un proceso de
siguiente paso en la evolu- ción de la profesión de la ingeniería de desarrollo que dedica aproximada- mente 150 los colaboradores de
software. 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ó
Qué es la ingeniería de software? contacto con las agencias fesionales y las sociedades científicas y
públicas pro involucrados en la ingeniería de software, conscientes de
ISO / IEC / IEEE Sistemas y de Ingeniería de Software de este proyecto para actualizar SWEBOK, e invitados a participar en el
vocabulario (SEVOCAB) define las soluciones de inge- niería proceso de revisión. tores KA edi- fueron reclutados de América del
como “la aplicación de una disci- plined, enfoque sistemático y Norte, la cuenca del Pacífico, y Europa. Las presentaciones sobre el
cuantificable al desarrollo, operación y mantenimiento de proyecto se hicieron en varios lugares internacionales. El segundo de
software; es decir, la aplicación de la ingeniería al software) “. 1 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
¿QUÉ SON LOS OBJETIVOS DE LA GUÍA organiza en los quince KAs enumerados en la Tabla I.1. Cada uno de
SWEBOK? estos Kas es tratado en un capítulo de esta Guía.

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

fundamentos matemáticos Fundamentos de Ingeniería 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
Al especificar el alcance, también es importante adoptar la definición de a sí mismos, no en el Guía.
las disciplinas que se cruzan con la ingeniería de software. Con este fin,

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 MATERIAL DE REFERENCIA Y MATRIZ
es, sin embargo, un obje- tivo de la Guía SWEBOK para
caracterizar el conocimiento de las disciplinas relacionadas. 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.
Tabla I.2. Disciplinas relacionadas 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,
Introducción xxxiii

certificación y concesión de licencias, el criterio de generalmente El desglose de los temas en cada KA consti- tuye el
aceptado el conocimiento se ha aplicado, que se distingue de un núcleo la descripción KA, que describen la descomposición
conocimiento avanzado y la investigación (sobre la base de la de la KA en subáreas, temas y subtemas. Para cada tema
madurez) y de conocimiento especializado (por motivos de o subtema, se da una breve descripción, junto con una o
generalidad de la solicitud). El término equivalente generalmente más referencias.
reconocido 
El material de referencia fue elegido porque se considera que
proviene del Instituto de Gestión de Proyectos: “Generalmente constituye la mejor presentación de los conocimientos en relación
reconocido significa el conocimiento y las prácticas descritas son con el tema. Una matriz vincula los temas que el material de
aplicables a la mayoría de los proyectos, la mayor parte del referencia. La última parte de la descripción de cada KA es la lista
tiempo, y no hay consenso sobre su valor y utilidad.” 2 de referencias recomendadas y (opcionalmente) las lecturas ther de
pieles. normas pertinentes para cada KA se presentan en el
Sin embargo, los términos “generalmente aceptados” o Apéndice B de la Guía.
“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 APÉNDICE A. KA Descripción
determinan que-pero sí implica que, ingenieros de software capaces Especificaciones
competentes deberían estar equipados con este conocimiento para su
aplicación potencial. Más precisamente, el conocimiento generalmente Apéndice A describe las especificaciones proporcionadas por el
aceptado debe ser incluido en el estudio de mate- rial para la ingeniería equipo editorial de los editores asociados de los contenidos,
de licencias de software exami- nación que los graduados tomarían referencias, formato y estilo de las descripciones KA
después de ganar cuatro años de experiencia laboral. Aunque este cri- recomendado.
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. 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
ESTRUCTURA DE LAS DESCRIPCIONES KA SWEBOK.

Las descripciones KA se estructuran como sigue. En la LISTA DE REFERENCIA APÉNDICE C.


introducción, se presentan una breve definición de la KA y una CONSOLIDADO
visión general de su alcance y de su nave PARENTESCO con
otros KAs. Apéndice C contiene la lista consolidada de las referencias
citadas en reco- mienda la KAS (estas referencias están

2 Una guía para la Dirección de Proyectos del Conocimiento, 5 ed, marcados con un asterisco (*) en el texto).
el Project Management Institute, 2013.; www.pmi.org .
CAPÍTULO 1

REQUISITOS DE SOFTWARE

SIGLAS , No implica, sin embargo, que un ingeniero de software no pudo


realizar la función. Un riesgo inherente en la descomposición
Confidencialidad, integridad y
CIA propuesta es que un proceso de cascada-como puede deducirse.
disponibilidad de DAG Para evitar esto, el tema 2, los requisitos del proceso, está diseñado
Dirigido acíclicos Gráfico FSM para proporcionar una visión general de alto nivel del proceso de

Tamaño funcional Medición Consejo requisitos mediante el establecimiento de los recursos y las
limitaciones con las que opera el proceso y que actúan para
Internacional sobre Sistemas INCOSE
configurarlo. Una descomposición alternativa podría utilizar una
ingeniería
estructura a base de pro- ducto (requisitos del sistema, los requisitos
UML Lenguaje Unificado de Modelado de
de soft- ware, prototipos, casos de uso, y así sucesivamente). La
Sistemas SysML Lenguaje de Modelado 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
INTRODUCCIÓN (tanto secuenciales y simultáneas), en lugar de como una discreta,
de una sola vez la actividad realizada al inicio de un proyecto de
El área de conocimiento Requisitos de software (KA) se ocupa de desarrollo de software. Los requisitos de software KA se relaciona
la obtención, análisis, speci- ficación, y la validación de los estrechamente con el diseño de software, pruebas de software,
requisitos de software, así como la gestión de los requisitos mantenimiento de software, Software Configuration Management,
Duran- todo el ciclo de vida del producto de software. Es Gestión de Ingeniería de Software, Software de Ingeniería de
ampliamente reconocido entre los investigadores y profesionales Procesos, Ingeniería de Software y Modelos Métodos y Calidad de
de la industria que los proyectos de software son críticamente Software de Kas.
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.

DISTRIBUCIÓN DE TEMAS PARA


La “ingeniería de requisitos” plazo es ampliamente utilizado en REQUISITOS DEL SOFTWARE
el campo para indicar la manipulación sistemática de requisitos.
Por razones de coherencia, el término “ingeniería” no se utiliza El desglose de los temas de los requisitos de software KA
en este KA excepto para la ingeniería de software en sí. Por la se muestra en la Figura 1.1.
misma razón, “ingeniero de requisitos”, un término que aparece
en la parte de la literatura, no se utilizará tampoco. En cambio, el 1. Requisitos de software Fundamentos
término “ingeniero de software” o, en algunos casos específicos, [1 *, c4, c4s1, c10s1, c10s4] [2 *, C1, C6, c12]
“los requisitos especialista” se utilizará, este último donde el
papel en cuestión se realiza generalmente por una persona que 1.1. Definición de un requisito de software
no sea un ingeniero de software. Esta
En su forma más básica, un requisito de software es una
propiedad que debe ser exhibido por algo en

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

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

Para resolver algún problema en el mundo real. Se puede tratar requisitos pueden ser verificados dentro de las limitaciones de recursos
de automatizar parte de una tarea para alguien para apoyar los disponibles.
procesos de negocio de una organiza- ción, para corregir Requisitos tienen otros atributos en adi- ción a las propiedades de
defectos de software existente, o para controlar un nombre de comportamiento. Los ejemplos más comunes incluyen una clasificación
dispositivo a sólo algunos de los muchos problemas para los que de prioridad para permitir compensaciones en la cara de los recursos
son posibles soluciones de software . Las formas en que los finitos y un valor de estado para permitir el avance del proyecto a
usuarios, pro- cesos de negocio, y dispositivos de función suelen vigilar. Tıpicamente, los requisitos de software son singularmente
ser complejas. Por extensión, por lo tanto, los requisitos de identificadas con los de modo que puedan ser objeto de software de
software de par- ticular son típicamente una compleja gestión de con- figuración durante todo el ciclo de vida de la entidad y
combinación de varias personas en diferentes niveles de una del software.
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 1.2. Requisitos del producto y de proceso
software es que sean verificables como una característica
individual como requisito funcional o a nivel del sistema como un Un requisito de un producto es una necesidad o restricción en el
requisito no funcional. Puede ser difícil o costoso para verificar software que se desarrollarán (por ejemplo, “El software verificará
ciertos requisitos de soft- ware. Por ejemplo, la verificación del que un estudiante cumple con todos los requisitos previos antes de
requisito de caudal en un centro de llamadas puede hacer que él o ella se registre en un curso”). Un requisito proceso es
necesario el desarrollo de software de simulación. Requisitos de esencialmente un con- straint en el desarrollo del software (por
software, ING Ensayos software y personal de calidad debe ejemplo, “El software se desarrolla utilizando un proceso RUP”).
asegurar que el

Algunos de los requisitos de software generan los requisitos del


proceso implícitos. La elección de la verificación
Requisitos de software 1-3

técnica es un ejemplo. Otro podría ser el uso de técnicas de análisis dependen para su interpretación en un juicio subjetivo ( “el
particularmente rigurosas (tales como los métodos de especificación software será fiable”, “el software debe ser fácil de usar”).
formal) para reducir los fallos que pueden conducir a insuficiente Esto es Particularmente importante para los requisitos no
fiabilidad. requisitos pro- ceso También pueden imponerse funcionales. Dos ejemplos de requisitos cuantificados son los
directamente por la organización de desarrollo, su cliente, o un siguientes: software de un centro de llamadas debe aumentar
tercero, tal como un regulador de la seguridad. 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á
1.3. Requisitos funcionales y no funcionales en un nivel muy alto y tendrá que ser utilizado para derivar
una serie de requisitos detallados. El requisito dad fiabili- será
Funcional requisitos describen las funciones que el software es fuertemente restringir la arquitectura del sistema.
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. 1.6. Requisitos del sistema y requisitos de
software
no funcional los requisitos son los que actúan para limitar la
solución. Los requisitos no funcionales son a veces conocidos En este tema, los medios del “sistema”

como las restricciones o requisitos de calidad. Pueden ser


más clasifi- sified de acuerdo a si son los requisitos de una combinación de interacción de elementos para
rendimiento, facilidad de mantenimiento llevar a cabo un objetivo definido. Estos incluyen
requisitos, hardware, software, firmware,
requisitos de seguridad, requisitos de fiabilidad, requisitos de las personas, los elementos de información, técnicas,
seguridad, requisitos de interoperabilidad o uno de muchos instalaciones, servicios, y otra de apoyo,
otros tipos de requisitos de software (ver modelos y carac-
terísticas de calidad en el KA Calidad del Software). 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
1.4. Propiedades emergentes conjunto. En unos componentes de software del sistema que
contienen, software requisitos se derivan de requisitos del sistema.
Algunos requisitos representan emergentes como propiedades del Esta KA define “las necesidades del usuario” en forma restringida,
software, es decir, requisitos que no pueden ser tratados por un como los requisitos de los clientes del sis- tema o usuarios finales.
solo componente, sino que dependerá de cómo interactúen todos Los requisitos del sistema, por el contrario, abarcan necesidades de
los componentes de software. El requisito de caudal para un centro los usuarios, los requisitos de otras partes interesadas (tales como
de llamadas, por ejemplo, dependerá de cómo el sistema telefónico, las autoridades miento de reglamentación mentos), y los requisitos
sistema de información, y los operadores de todos interactuaron en sin una fuente humana identificable.
condiciones reales de explota- ción. Las propiedades emergentes
dependen fundamentalmente de la arquitectura del sistema.

2. Requisitos Proceso
[1 *, c4s4] [2 *, C1-4, c6, c22, c23]
1.5. Requisitos cuantificables
En esta sección se presenta el proceso de requisitos de software, la
Requisitos de software deben expresarse tan claramente y orientación de los cinco temas restantes y mostrando cómo el proceso se
sin ambigüedad como sea posible, y, en su caso, ajusta perfectamente a los requisitos del proceso general de la ingeniería
cuantitativamente. Es importante evitar los requisitos de de software.
vagas y no verificables que
1-4 Guía SWEBOK® V3.0

2.1. Los modelos de proceso la gente de marketing son a menudo necesarios para esta- blecer

las necesidades del mercado y para actuar como clientes de proxy.

El objetivo de este tema es el de proporcionar un entendimiento de


que el proceso de requisitos • Reguladores: Muchos dominios de aplicación, como la
banca y el transporte público, son re- gulada. Software en
• no es una actividad discreta front-end del ciclo de vida soft- estos ámbitos debe com- capas con los requisitos de las
ware, sino más bien un proceso iniciado en el comienzo de un autoridades reguladoras.
proyecto que continúa para ser refinado durante todo el ciclo de
vida; • Los ingenieros de software: Estos individuos tienen un interés
• identifica los requisitos de software como elementos de legítimo en sacar provecho de desa- oping el software, por
configuración y los gestiona utilizando las mismas prácticas de ejemplo, la reutilización de componentes o de otros productos.
gestión de configuración de software como otros productos de Si, en este escenario, un cliente de un producto particu- lar
los procesos del ciclo de vida del software; tiene requisitos específicos que comprometen la posibilidad de
reutilización de componentes, los ingenieros de software
• necesita ser adaptado al contexto de la organización y del deben sopesar cuidadosamente su propio juego contra los del
proyecto. cliente. Los requisitos específicos, las limitaciones particular-
mente, pueden tener un impacto importante en el precio o la
En particular, el tema tiene que ver con cómo se configuran entrega del proyecto, ya sea porque se ajustan bien o mal con
las actividades de obtención, análisis, especifica- ción y el conjunto de habilidades de los ingenieros. ventajas y
validación para diferentes tipos de proyectos y limitaciones. El desventajas importantes entre estos requisitos deben ser
tema también incluye actividades que proporcionan la entrada en identificados.
el proceso de requisitos, tales como la comercialización y la
factibilidad estudios.

No será posible satisfacer perfectamente las necesidades de


2.2. Los actores del proceso todas las partes interesadas, y es el trabajo del ingeniero de software
para negociar compensaciones que sean aceptables para los
Este tema se presentan las funciones de las personas que principales grupos de interés y dentro de las limitaciones
participan en el proceso de requisitos. Este pro- ceso es presupuestarias, técnicas, normativas, y otros. Un requisito previo
fundamentalmente interdisciplinario, y el especialista requisitos para esto es que se identifique a todos los interesados, la naturaleza
necesita para mediar entre el dominio de la parte interesada y la de de su “juego” analizados y sus requisitos provocaron.
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- 2.3. Administración y Apoyo Proceso
variarán según los proyectos, pero siempre incluirán los usuarios /
operadores y clientes (que no tiene por qué ser el mismo). 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
Ejemplos típicos de grupos de interés de software incluyen del Alcance) del Software Engineering Management KA. Su
(pero no se limitan a) los siguientes: objetivo prin- cipal es hacer que el vínculo entre las actividades
pro- ceso identificados en 2.1 y los problemas de costo, recursos
• Usuarios: Este grupo comprende aquellos que operará el humanos, capacitación y herramientas.
software. A menudo es un grupo heterogéneo que implica
a personas con diferentes roles y necesidades.
2.4. Proceso de Calidad y Mejora
• Clientes: Este grupo comprende aquellos que han
encargado el software o que REPRESENTA mercado En este tema se refiere a la evaluación de la calidad y la mejora
objetivo del software. del proceso de requisitos. Su propósito es hacer hincapié en el
• Los analistas de mercado: Un producto de mercado masivo no papel clave que desempeña el proceso de requerimientos en
tendrán un cliente puesta en marcha, por lo términos de la
Requisitos de software 1-5

costo y puntualidad de un producto de software y de la satisfacción para garantizar las necesidades de negocios más importantes del
del cliente con él. Esto ayudará a orientar el proceso de requisitos de cliente son las primeras en cubrirse. Esto minimiza el riesgo de
calidad con Dardos Están- y modelos de mejora de procesos para las especialistas necesidades de gasto de tiempo elicit- requisitos de
mercancías y los sistemas blandas. La calidad del proceso y la ING que son de poca importancia, o los que resultan ser ya no es
mejora está estrechamente relacionado tanto a la calidad del relevante cuando se entrega el software. Por otra parte, la
software y KA KA Proceso de Ingeniería de Software, que descripción debe ser escalable y extensible para aceptar otras
comprende exigencias no se expresa en las primeras listas formales y
compatibles con los anteriores como se contempla en métodos
recursivos.
• 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; Requisitos tienen muchas fuentes en cerámica típica blandas, y es
• seguridad / mejora de la CIA / planificación y esencial que se identifican y evalúan todas las fuentes potenciales.
ejecución. Este tema está diseñado para promover el conocimiento de las
diversas fuentes de requisitos de software y de los marcos para la
3. la obtención de requisitos gestión de los mismos. Los principales puntos cubiertos son los
[1 *, c4s5] [2 *, c5, c6, c9] siguientes:

La obtención de requisitos tiene que ver con los orígenes de


los requisitos de software y cómo el ingeniero de software • Metas. El término “objetivo” (a veces llamada “empresa
puede recogerlos. Es la primera etapa en la construcción de comercial” o “crítico de éxito fac- tor”) se refiere a los objeti-
una comprensión del problema se requiere el software de vos generales, de alto nivel de software. Objetivos
resolver. Es recuento fundamen- una actividad humana y es proporcionan la motiva- ción para el software, pero a menudo
donde se identifican las ERS stakehold- y las relaciones son muy vago. Los ingenieros de software deben prestar
establecidas entre el equipo de desarrollo y el cliente. Se especial atención a la evaluación del valor (en relación a la
denomina diversamente “captura de requisitos”, “requisitos prioridad) y el costo de las metas. Un estudio de factibilidad
descubrimiento” y “adquisición requisitos”. es una forma relativamente barata de hacer esto.

Uno de los principios fundamentales de un buen proceso de • Conocimiento del dominio. El ingeniero de software necesita
obtención requisitos es el de la comunicación tivo effec- entre los para adquirir o tener El conocimiento disponible sobre el
distintos titulares stake-. Esta comunicación continúa con el dominio de aplicación. conocimiento del dominio
proceso entero de desarrollo de software del Ciclo de Vida proporciona el contexto en el que todo el conocimiento
(SDLC) con diferentes actores a diferentes puntos en el tiempo. requisitos provocada debe ajustarse con el fin de
Antes de que comience el desarrollo, los especialistas requisitos entenderlo. Es una buena práctica para emular un enfoque
pueden formar el conducto para esta comunicación. Deben Medi ontológico en el dominio del conocimiento. relacio- nes entre
comieron entre el dominio de los usuarios de software (y otras los conceptos relevantes dentro del dominio de aplicación
partes interesadas) y el mundo de la técnica del ingeniero de deben ser identificados.
software. Un conjunto de modelos internamente consistentes en
diferentes niveles de abstracción facilitar las comunicaciones • Las partes interesadas (véase la sección 2.2, actores del
entre los usuarios de software / titulares stake- e ingenieros de proceso). Gran parte del software ha demostrado ser
software. 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
Un elemento crítico de la obtención de requisitos está informando estructuras culturales o políticas de la organización al cliente
al alcance del proyecto. Esto implica proporcio- nando una central. El ingeniero de software tiene que identificar,
descripción del software que se especifica y su propósito y dar representar y administrar
prioridad a los entregables
1-6 Guía SWEBOK® V3.0

los “puntos de vista” de muchos tipos diferentes de grupos de aún no se ha obtenido a partir de los usuarios finales. La importancia
interés. de la planificación, verificación y validación en la obtención de
• Reglas del negocio. Estas son declaraciones que definen o requisitos no puede ser exagerada. Existe un número de técnicas para
limitan algún aspecto de la estruc- tura o el comportamiento de los requisitos de elici- tación; las principales son las siguientes:
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 • Entrevistas. Entrevistando a las partes interesadas es un
negocio que sería una fuente requisito para el software del medio “tradicional” de provocar requisitos. Es importante
curso-registro de una uni- versidad. entender las ventajas y limitaciones de las entrevistas y la
forma en que debe llevarse a cabo.
• El entorno operativo. Requisitos se derivan del entorno en
el que se ejecutará el programa. Estos pueden ser, por • Escenarios. Escenarios proporcionan un medio valioso para
ejemplo, las limitaciones de tiempo en las restricciones proporcionar contexto a la ción elicita- de requisitos del usuario.
del software o de rendimiento en tiempo real en un Permiten que el ingeniero de software para proporcionar un
entorno empresarial. Estos deben ser buscados marco para las preguntas sobre las tareas del usuario al permitir
activamente, ya que pueden afectar en gran medida la que “qué pasaría si” y “cómo se hace” preguntas que se le
viabilidad y el costo de software así como restringir las pregunte. El tipo más común de escena- rio es la descripción de
opciones de diseño. casos de uso. Hay un enlace aquí al Tema 4.2 (Modelado
Conceptual) debido a las notaciones de escenarios tales como
• El entorno de la organización. El software se requiere a diagramas de casos de uso son comunes en el software de
menudo para apoyar un pro- ceso de negocios, la selección modelado.
de los cuales puede ser condicionado por la estructura, la
cultura y la política interna de la organización. El ingeniero • Prototipos. Esta técnica es una herramienta valiosa para aclarar
de software tiene que ser sensible a éstos, ya que, en los requisitos ambiguos. Pueden actuar de una manera similar a
general, el nuevo software no debe forzar el cambio no los escenarios por los pro- usuarios Viding con un contexto en el
planificado en el proceso de negocio. 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
3.2. técnicas de obtención pruebas beta de productos de software y un fuerte solapamiento
de sus usos separados para requisitos elicita- ción y para la
Una vez que las fuentes de requisitos se han iden- tificado, el validación de los requisitos (véase la sección 6.2, Prototyping) .
ingeniero de software puede iniciar la obtención de información de los Baja fidelidad prototipos se prefieren a menudo para evitar que
requisitos de los mismos. Tenga en cuenta que los requisitos rara vez las partes interesadas “anclaje” en la carac- terísticas de menor
se suscitó confeccionada. Más bien, el ingeniero de software obtiene importancia, incidental de un prototipo de mayor calidad que
información de la que él o ella formula requisitos. Este tema se centra puede limitar la flexibilidad de diseño de formas no deseadas.
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 • reuniones facilitadas. El propósito de estas reuniones es tratar
tareas, puede dejar infor- mación importante no declarada, o pueden de lograr un efecto acumulativo, por el que un grupo de
ser dispuestos o no pueden cooperar. Es particularmente importante personas puede traer más información sobre sus exigencias
entender que la provocación no es una actividad pasiva y que, incluso de software que trabajando individualmente. Pueden
si las cooperativas interesadas y articulados están disponibles, el intercambiar ideas y refinar las ideas que pueden ser difíciles
ingeniero de software tiene que trabajar duro para obtener la de llevar a la superficie utilizando entrevistas. Otra ventaja es
información correcta. Muchos de los requisitos de negocio o técnicas que los requisitos conflictivos superficie desde el principio en
son tácito o en la retroalimentación que una forma que permite a las partes interesadas reconocen
cuando éstos se producen. Cuando funciona bien, esta
técnica
Requisitos de software 1-7

puede resultar en un conjunto más rico y más coherente de los Análisis 4. Requisitos
requisitos que de otro modo podrían ser alcanzables. Sin [1 *, c4s1, c4s5, c10s4, c12s5]
embargo, las reuniones deben ser manejados con cuidado (de ahí [2 *, c7, c11, c12, c17]
la necesidad de un facilitador) para evitar una situación en la que
las habilidades críticas del equipo son erosionadas por la lealtad Este tema tiene que ver con el proceso de ana-
al grupo, o en las que los requisitos que reflejan las requisitos lyzing a
preocupaciones de unos pocos pelos en la lengua (y quizás de
alto nivel) las personas que se ven favorecidas en detrimento de • detectar y resolver los conflictos entre los
otros. requisitos;
• descubrir los límites del software y cómo debe
• Observación. La importancia del contexto de software dentro de interactuar con su entorno organizacional y
la ment ENTORNO organización ha llevado a la adaptación de operativa;
las técnicas observacionales tales como la etnografía para la • requisitos del sistema elaborados para derivar los requisitos de
obtención de requisitos. Los ingenieros de software aprenden soft- ware.
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 La visión tradicional de análisis de requisitos ha sido que ser
usuarios realizan sus tareas mediante la interacción con los reducido a ing modelo- conceptual usando uno de una serie de
demás y con herramientas de software y otros recursos. Estas métodos de análisis, tales como el método de análisis
técnicas son relativamente caros, sino también instructiva estructurado. Si bien el modelado conceptual es importante,
porque ilustran que muchas tareas de usuario y procesos de incluimos la clasificación de los requisitos para ayudar a informar
negocio son demasiado sutil y complejo por sus actores para a soluciones de compromiso entre los requisitos (clasificación
describir fácilmente. 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
• Historias de usuarios. Esta técnica se utiliza comúnmente en los los requisitos para ser validados, su aplicación a ser verificada, y
métodos de adaptación (ver Métodos ágiles en los modelos de sus costes a estimar.
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 4.1. requisitos Clasificación
manera que <beneficio>”. Una historia de usuario está destinado a
contener suficiente informa- ción para que los desarrolladores Los requisitos pueden ser clasificadas en varias dimensiones.
pueden producir una estimación razonable del esfuerzo para que Ejemplos incluyen los siguientes:
las aplicará. El objetivo es evitar algunos de los residuos que
sucede a menudo en proyectos en los que se utilizarán para reunir • Si el requisito es funcional o no funcional (ver
los requisitos detallados temprano, pero se han invalidado antes de sección 1.3, funcional y requerimientos no
que comience el trabajo. Antes se implementa una historia de funcionales).
usuario, un procedimiento de acep- tación adecuada debe ser • Si el requisito se deriva de uno o más requisitos de alto
escrita por el al cliente central para determinar si se han cumplido nivel o una propiedad de gent gencia (véase la sección
los objetivos de la historia de usuario. 1.4, propiedades emergentes), o está siendo impuesta
directamente en el software por un actor o alguna otra
fuente.

• Otras técnicas. Una variedad de otras técnicas para el apoyo a • Si el requisito es en el producto o el proceso (ver
la obtención de información de los requisitos existen y van sección 1.2, producto y requisitos del proceso).
desde el análisis de productos de la competencia para aplicar Requisitos en el proceso pueden limitar la elección de
los datos min-ing técnicas para el uso de fuentes de bases de Tor contracción, el proceso de ingeniería de software
datos de conocimiento de dominio o petición del cliente. 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 El desarrollo de modelos de un problema del mundo real es clave
escala de coma fija como obligatoria, altamente deseable, para el análi- sis requisitos de software. Su propósito es ayudar a
deseable u opcional, la prioridad que a menudo tiene que comprender la situación en la que se produce el problema, así
ser equili- brada con el coste de desarrollo e como que representa una solución. Por lo tanto, los modelos
implementación. conceptuales comprenden modelos de entidades del dominio del
problema, configurado para reflejar sus relaciones y dependencias
• El alcance de la prescripción. Ámbito de aplicación se refiere del mundo real. Este tema está estrechamente relacionado con las
a la medida en que un requisito afecta a los componentes de els Ingeniería de Software y Métodos Mod-KA.
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 Hay varios tipos de modelos pueden ser desarrollados. Estos incluyen

componente discreto. Por lo tanto, un requisito de ámbito diagramas de casos de uso, los modelos de flujo de datos, modelos de

global puede afectar en gran medida la arquitectura de estado, los modelos basados ​en objetivos, las interacciones del usuario,

software y el diseño de muchos componentes, mientras que modelos de objetos, modelos de datos, y muchos otros. Muchas de estas

uno con un alcance limitado puede ofrecer una serie de notaciones de modelado son parte de Unified Modeling Language (UML). Utilice

opciones de diseño y tienen poco impacto en la satisfacción diagramas de casos, por ejemplo, se utilizan rutinariamente para

de otras necesidades. 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.

• Volatilidad / estabilidad. Algunos de los requisitos cambiarán Los factores que influyen en la elección de la notación ing modelo-

durante el ciclo de vida de la Cesión de Software, e incluso incluyen los siguientes:

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 • La naturaleza del problema. Algunos tipos de software bajo
interés de crédito a las cuentas de los clientes tienden a ser demanda que ciertos aspectos sean ana- lisadas particularmente
más estable que un requisito para apoyar un tipo particular de rigurosa. Para modelos de ejemplo, estatales y paramétricos,
cuenta libre de impuestos. El primero refleja una característica que son parte de SysML [4], es probable que sean tant más
funda- mental del dominio bancario (cuentas que pueden impor- por software en tiempo real que para los sistemas
ganar intereses), mientras que los segundos pueden dejarlo informa- ción, al tiempo que normalmente sería el opuesto para
obsoleto por un cambio a la legislación gubernamental. Marcar modelos de objetos y de la actividad.
requisitos potencialmente volátiles puede ayudar al ingeniero
de software de establecer un diseño que es más hormiga • La experiencia del ingeniero de software. A menudo es más
tolerar de cambio. 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
Otras clasificaciones pueden ser apropiadas, pueden imponer su notación o método favorecido o prohibir
dependiendo de Tice prác- normal de la organización y la cualquier con las que están familiarizados. Este factor
propia aplicación. puede entrar en conflicto con el factor anterior.
Hay una fuerte superposición entre atributos requisitos
de clasificación y requisitos (ver sección 7.3, Requisitos
de atributos). 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.
Requisitos de software 1-9

Esto es crucial para la comprensión de con- texto del software en su 4.4. requisitos de Negociación
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 Otro término comúnmente utilizado para este subtema es
modelado particu- lar o anotación, sino más bien proporciona “resolución de conflictos”. Esto se refiere resolv- ing problemas con
orientación sobre el propósito e intención de modelado. 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
4.3. Diseño y requisitos arquitectónicos Asignación 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
En algún momento, la arquitectura de la solución debe ser derivado. interesada (s) para llegar a un consenso sobre una compensación
El diseño arquitectónico es el punto en el que el proceso se adecuada. A menudo es importante, por razones contractuales,
superpone con los requisitos de software o sistemas de diseño e que tales las decisiones sean detectables de nuevo al cliente.
ilustra lo imposible que es disociar limpiamente las dos tareas. Este Hemos clasificado esto como un tema de análisis de requisitos de
tema está estrechamente relacionada con la estructura y software debido a problemas surgen como el resultado del análisis.
arquitectura de software en el diseño de software KA. En muchos Sin embargo, un fuerte caso también se puede hacer por
casos, el ingeniero de software actúa como arquitecto de software considerarlo un tema de validación de requisitos (ver tema 6, los
debido a que el proceso de análisis y elaboración de los requisitos requisitos de validación). Requisitos priorización es necesario, no
que exige ser identificados los componentes / diseño de arquitectura sólo como un medio para filtrar los requisitos importantes, sino
que se encargarán de satisfacer los requisitos. Esta es la asignación también con el fin de resolver los conflictos y el plan de entregas
de-la requisitos de asignación a componentes de la arquitectura escalonadas, lo que significa tomar decisiones complejas que
respon- sable para satisfacer los requisitos. La asignación es requieren el conocimiento de dominio detallado y buenas
importante para permitir Ysis anal-detallado de las necesidades. Por habilidades de estimación. Sin embargo, a menudo es difícil
lo tanto, por ejemplo, una vez que un conjunto de requisitos se ha obtener información real que puede actuar como base para este
asignado a un componente, los requisitos individuales se pueden tipo de decisiones. Además, los requisitos a menudo dependen
analizar aún más para descubrir nuevos requisitos sobre cómo el unos de otros, y prioridades son relativos. En la práctica, los
componente tiene que interactuar con otros componen- tes con el fin ingenieros de software realizan requisitos priorización con
de satisfacer el requisito asignado mentos. En grandes proyectos, la frecuencia sin necesidad de conocer todos los requisitos.
asignación estimula una nueva ronda de análisis para cada Requisitos priorización puede seguir un enfoque de valor de costo
subsistema. Como ejemplo, los requisitos para un rendimiento que implica un análisis de las partes interesadas en una escala que
determinado de frenado para un coche (distancia de frenado, la definen los beneficios o el valor agregado que el ción ¡Ejecución
seguridad en condiciones de conducción pobres, suavidad de apli- del requisito les lleva, en comparación con las penas de no haber
cación, la presión del pedal necesarios, y así sucesivamente) puede implementado un requisito particular. También implica un análisis
ser asignada al hardware de frenado (conjuntos mecánicos e de los ingenieros de software de estimación en una escala el costo
hidráulicos) y un sistema de frenado antibloqueo (ABS). Sólo de la implementación de cada requisito, en relación con otros
cuando un requisito para un sistema antibloqueo de frenos ha sido requisitos. Otro enfoque oritization pri- requisitos llama el proceso
identificado, y los requerimientos asignados a ella, se pueden utilizar analítico jerárquico implica comparar todos los pares únicos de los
los lazos capabili- del ABS, el hardware de frenado, y emer- requisitos para determinar cuál de los dos es de mayor prioridad, y
propiedades Gent (tales como el peso del coche) para identificar la en qué medida.
detallada requisitos de software ABS. El diseño arquitectónico está
estrechamente identificada con el modelado conceptual (ver sección
4.2, Modelado Conceptual).
1-10 Guía SWEBOK® V3.0

4.5. Análisis formal un documento que pueda ser revisado de forma sistemática,
evaluada y aprobada. Para sistemas complejos, especialmente
preocupaciones formales de análisis no sólo el tema 4, pero también aquellos que involucran componentes mercancías nonsoft-
las secciones 5.3 y 6.3. En este tema también se relaciona con sustanciales, como se producen hasta tres diferentes tipos de
métodos formales en los modelos de ingeniería de software y métodos documentos: sistema de defini- ción, requisitos del sistema y los
Área de Conocimiento. Análisis formal ha hecho un impacto en algunos requisitos de software. Para los productos de software simple, sólo
dominios de aplicación, en particular los de los sistemas de alta se requiere el tercero de estos. Los tres documentos se describen
integridad. La expresión formal de requisitos requiere una lengua con aquí, con el entendimiento de que se pueden combinar según sea
la semántica formalmente definidos. El uso de un análisis formal para apropiado. Una descripción de la ingeniería de sistemas se puede
la expresión requisitos tiene dos ventajas. En primer lugar, permite a encontrar en las disciplinas de Ingeniería de Software capítulo de
los requisitos expresados ​en el idioma que se especifique con este Relacionados Guía.
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 5.1. Definición del sistema de documentos
soporte de herramientas para ser practicable para distintos de los
sistemas triviales nada, y herramientas generalmente se dividen en Este documento (a veces conocido como el documento de
dos tipos: los demostradores de teoremas o las damas modelo. En requerimientos del usuario o el concepto de documento de
ninguno de los casos puede ser totalmente automatizado prueba, y el operaciones) registra los requisitos del sistema. Define los
nivel de competencia en razonamiento formal sea necesario con el fin requisitos del sistema de alto nivel de la perspectiva de dominio. Su
de utilizar las herramientas restringe la aplicación más amplia de número de lectores incluye representantes de los usuarios del
análisis formal. El análisis más formal, se centra en etapas sistema / clientes (marketing puede desempeñar estas funciones
relativamente tardías de análisis de requisitos. Es general- mente para el software impulsado de mercado), por lo que su contenido
contraproducente para solicitar la formalización hasta que los objetivos debe ser expresada en términos de dominio. El documento
de negocio y necesidades de los usuarios han entrado en un enfoque enumera los requisitos del sistema, junto con la información de
nítido a través de medios tales como los descritos en otras partes de la fondo sobre los objetivos globales para el sistema, su entorno de
sección 4. SIN EMBARGO, una vez que los requisitos se han destino, y una declaración de las limitaciones, supuestos y
estabilizado y se han elaborado para especificar propie- concreto lazos requisitos no funcionales. Puede incluir modelos conceptuales
del software, puede ser beneficioso para para- malize al menos los diseñados para ilustrar el contexto del sistema, escenarios de uso,
requisitos críticos. Esto per- mite la validación estática que el software y las principales entidades de dominio, así como los flujos de
especificado por los requisitos sí tiene las pro- piedades (por ejemplo, trabajo.
ausencia de estancamiento) que el cliente, los usuarios, y el ingeniero
de software de esperar que tenga.

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
5. Requisitos Especificación software se derivan de los requisitos del sistema y, a continuación
[1 *, c4s2, c4s3, c12s2-5] [2 *, c10] los requisitos para el software com- ponentes se especifican.
Estrictamente hablando, la especificación de los requisitos del
Para la mayoría de las carreras de ingeniería, el término “memoria sistema es una actividad sistemas Engineer- ing y cae fuera del
descriptiva” se refiere a la asignación de valores numéricos o los límites a alcance de este
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 Guía.
producción de
Requisitos de software 1-11

5.3. Especificación de Requerimientos de Software 6. Requisitos de Validación


[1 *, c4s6] [2 *, c13, c15]
especificación de requisitos de software establece la base para un
acuerdo entre los clientes y los contratistas o proveedores (en proyec- Los documentos de los requisitos pueden estar sujetos a
tos impulsados ​por el mercado, estas funciones pueden ser jugados procedimientos de Val- idation y verificación. Los requisitos pueden
por las divisiones de marketing y desarrollo) en lo que el producto de ser validados para asegurar que el ingeniero de software ha
software es a hacer, así como lo que no es espera que lo haga. 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
especificación de requisitos de software permite una evaluación estándares de la compañía documentados o terminología sean
rigurosa de los requisitos de diseño antes de comenzar y se reduce el incompatibles con las normas generalmente aceptadas, una
rediseño más tarde. También debe proporcionar una base realista para asignación entre los dos debe ser acordado y se anexa al
ing realizan estimaciones los costos del producto, riesgos y horarios. Las documento. Las notaciones formales ofrecen la importante ventaja
organizaciones también pueden utilizar un documento de especificación de permitir que las dos últimas propiedades a ser probada (en un
de los requisitos de software de base para la elaboración de planes sentido restringido, por lo menos). Stake- distintos titulares, entre
eficaces de verificación y validación. 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
especificación de requisitos de software proporciona una base prestaciones de los procesos del ciclo de vida del software.
informada para la transferencia de UCT un software PRODUCIRSE a Cuando sea posible, los requisitos individuales también están
nuevos usuarios o plataformas de software. Por último, puede sujetos a la gestión de configuración, general- mente con una
proporcionar una base para la mejora del software. Requisitos de herramienta de gestión de requisitos (véase el tema 8, requisitos
software a menudo se escriben en lenguaje natural, pero, en la de software Herramientas). Es normal para programar
especificación de requisitos de software, esto puede complementarse explícitamente uno o más puntos en el proceso de requisitos
con for- mal o descripciones semiformales. La selección de las donde se validan los requisitos. El objetivo es recoger cualquier
anotaciones apropiadas permite particulares los requisitos y aspectos problema antes de recursos se comprometen a abordar los
de la arquitectura de software que se describirán con mayor precisión requisitos. Requisitos validada dación tiene que ver con el proceso
y concisión de lenguaje natural. La regla general es que ciones de examin- ing el documento de requisitos para garantizar que
notaciones se deben utilizar que permiten los requisitos que se define el software adecuado (es decir, el software que los usuarios
describen tan precisamente como sea posible. Esto es esperan).
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.

6.1. requisitos críticas


Una serie de indicadores de calidad se han desarrollado que puede
ser utilizado para relacionar la calidad de los requisitos de software de Tal vez la forma más común de la validación se realiza mediante
especificación a otras variables del proyecto, tales como el coste, la inspección o revisión del documento (s) requisitos. Un grupo de
aceptación, Formance per-, programar y reproducibilidad. Los revisores se le asigna un breve para buscar errores, suposiciones
indicadores de calidad para las declaraciones de especificación de erróneas, falta de claridad, y la desviación de Tice prác- estándar.
requisitos de software individuales son imperativos, directivas, frases La composición del grupo que lleva a cabo la revisión es
débiles, opciones y ANCES continuidades. Indicadores para todo el importante (al menos una representativa del cliente debe ser
documento de especificación de software exigencias incluyen el tamaño, incluido para un proyecto impulsado por el cliente, por ejemplo), y
la capacidad de lectura, la especificación, la profundidad y la estructura puede ayudar a proporcionar orientación sobre lo que debe
del texto. 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 dominio, el intercambio de datos. Si se utiliza el análisis formal notación

documento de definición del sistema, el documento de especificación del ciones, es posible utilizar ing razonable formal para probar las propiedades

sistema, el documento de especificación de requisitos de software, la de especificación. Este tema está estrechamente relacionado con las els

especificación de línea de base para un nuevo lanzamiento, o en cualquier Ingeniería de Software y Métodos Mod-KA.

otro paso en el proceso.

6.4. Prueba de aceptacion


6.2. prototipado
Una propiedad esencial de un requisito de software es que debe ser
Prototipos es comúnmente un medio para validar la interpretación posible validar que el producto final satisface. Requisitos que no
que el ingeniero de software de los requisitos de software, así pueden ser validados en realidad sólo son “deseos.” Por tanto, una
como para la obtención de nuevos requisitos. Al igual que con la tarea importante es la planificación de cómo ver- ify cada requisito.
elicitación, hay una gama de técnicas de prototipado y un número En la mayoría de los casos, el diseño de las pruebas de aceptación
de puntos en el proceso donde la validación prototipo puede ser hace esto por cómo los usuarios finales normalmente, un
apropiado. La ventaja de prototipos es que pueden hacer que sea comportamiento camente negocio utilizando el sistema. Identificación
más fácil interpretar los supuestos del ingeniero de soft- ware y, si y diseño de pruebas de aceptación puede ser difícil para los
es necesario, dar información útil acerca de por qué están requisitos no funcionales (véase la sección 1.3, Funcional y
equivocados. Por ejemplo, el comportamiento dinámico de un requerimientos no funcionales). Para ser validado, primero tienen
usuario interfase se puede entender mejor a través de un ani- que ser analizados y se descompone hasta el punto en que se
acoplado prototipo que a través de descripción textual o modelos pueden expresar cuantitativamente. Información adicional se puede
gráficos. La volatilidad de un requisito que se define después de la encontrar en la acep- tación / Calificación / pruebas de conformidad
creación de un prototipo que se ha hecho es extremadamente bajo en el Testing de Software KA.
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 7. Consideraciones prácticas
cuestiones cosméticas o problemas de calidad con el prototipo. Por [1 *, c4s1, c4s4, c4s6, c4s7] [2 *, c3,
esta razón, algunos prototipos defienden que eviten el software, c12, c14, c16, c18-21]
tales como maquetas basadas en rotafolio. totypes pro pueden ser
costosos de desarrollar. Sin embargo, si evitan el desperdicio de El primer nivel de descomposición tema pre- tantes en este KA
recursos que supone tratar de satisfacer los requisitos erróneos, su puede parecer para describir una secuencia lineal de actividades.
coste se puede justificar más fácilmente. prototipos tempranos Esta es una visión simplificada del proceso.
pueden contener aspectos de la solución final. Los prototipos
pueden ser evolutiva en lugar de usar y tirar. 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
6.3. Modelo de validación 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
Por lo general es necesario para validar la calidad de los modelos sobrecarga innecesaria. Muy a menudo, sin embargo, ya que estas
desarrollados durante el análisis. Por ejem plos, en modelos de empre- sas se expanden, a medida que crece su base de clientes, y
objetos, es útil para llevar a cabo un análisis estático para verificar la como su producto comienza a evolucionar, descubren que necesitan
existencia de rutas de comunicación entre los objetos que, en las para recuperar los requisitos que
partes interesadas
Requisitos de software 1-13

producto motivado cuenta con el fin de evaluar el impacto de los producto. Esto a menudo conduce a la revisión de los requisitos
cambios propuestos. Por lo tanto, la documentación y los requisitos finales del ciclo de vida. Tal vez el punto más crucial en la
de gestión del cambio son la clave para el éxito de cualquier proceso comprensión de los requisitos de software es que una proporción
de requisitos. significativa de los requisitos será cambio. Esto es a veces debido a
errores en el análisis, pero a menudo es una consecuencia
7.1. La naturaleza iterativa del proceso Requisitos 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
Existe una presión general en el software de indus- tria de los ciclos debe vender. Cualquiera que sea la causa, es importante reconocer
de desarrollo cada vez más cortos, y esto es particularmente la inevitabilidad del cambio y tomar medidas para mitigar sus
pronunciado en sectores altamente competitivos, impulsados ​por el efectos. El cambio tiene que ser gestionado por asegurar que los
mercado. Por otra parte, la mayoría de los proyectos se ven limitados cambios propuestos pasan por una revisión definido y tasa de
de alguna manera por su entorno, y muchos son actualizaciones o aprobación pro y mediante la aplicación de los requisitos
revisiones de software, tentes ing en el que se da por la arquitectura. cuidadosos trac- ción, análisis de impacto, y la gestión de
En la práctica, por lo tanto, casi siempre es práctico para implementar configuración de software (ver el KA Software Configuration
el proceso de requisitos como un proceso lineal y determinista en el Management). Por lo tanto, los requisitos de pro- ceso no es sólo
que los requisitos de software son provocados a partir de los grupos una tarea para el usuario en el desarrollo de software, pero se
de interés, bases forrado, asignado y entregado al equipo de extiende por todo el ciclo de vida del software. En un proyecto
desarrollo de software. Sin duda, es un mito que los requisitos para típico, el software requisito actividades mentos evolucionan con el
grandes proyectos de software están siempre perfectamente tiempo de obtención de la gestión del cambio. Una combinación de
entendidas o perfectamente especificados. En su lugar, los requisitos arriba hacia abajo métodos de análisis y diseño y de abajo hacia
normalmente iterar hacia un nivel de calidad y detalle que es arriba y métodos de implementación de refactorización que se
suficiente para permitir que las decisiones de diseño y de reúnen en el medio podría proporcionar lo mejor de ambos mundos.
adquisiciones a realizar. En algunos proyectos, esto puede dar lugar a Sin embargo, esto es difícil de lograr en la práctica, ya que depende
los requisitos que se baselined antes de todas sus propiedades se en gran medida de la madurez y la experiencia de los ingenieros de
entienden completamente. Se corre el riesgo expen- retrabajo siva si software.
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 7.2. Gestión del cambio
requisitos, así como los problemas conocidos.
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.
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 7.3. requisitos Atributos
desarrollándose requisitos para futuras iteraciones, mientras res
desarrollos proceder con el diseño y la construcción de la iteración actual. Los requisitos deben consistir no sólo en un ficación speci- de lo
Este enfoque proporciona ERS adaptado para el cliente con el valor de que se requiere, sino también de información auxiliar, lo que
negocio de forma rápida, mientras minimizando ing el costo de reproceso. 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.
En casi todos los casos, los requisitos de conocimiento sigue
evolucionando como el diseño y desarrollo 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 7.5. La medición de Requisitos
clasificación) y el método de verificación o sección del plan de
prueba de aceptación correspondiente. También puede incluir Como cuestión práctica, suele ser útil tener algún concepto de
información adicional, como una justificación de resumen para cada “volumen” de las exigencias para un producto de software en
requisito, la fuente de cada requerimiento, y un historial de cambios. particular. Este número es útil para evaluar el “tamaño” de un
Los requisitos más importantes atribuyen, SIN EMBARGO, es un cambio en los requisitos, al estimar el costo de una tarea de
identificador que permite a los requisitos para ser identificadas de desarrollo o mantenimiento, o simplemente para su uso como
manera única e inequívoca. 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.
7.4. requisitos de rastreo

Requisitos de rastreo tiene que ver con objeto de reembolso ing Información adicional sobre la medición y estándares de
la fuente de los requisitos y la predicción de los efectos de los tamaño se encuentra en el Proceso de Software niería Inge- KA.
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 8. Requisitos de software Herramientas

interesadas que la motivaron (de un requisito de software de


nuevo a la exigencia (s) del sistema que ayuda a satisfacer, por Herramientas para hacer frente a los requisitos de software se dividen
ejemplo). Por el contrario, un requisito debe ser trazable hacia en dos categorías: herramientas para el modelado y herramientas para
adelante en los requisitos de diseño y entidades que lo satisfacen la gestión de requisitos. herramientas de gestión de requisitos
(por ejemplo, de un requisito del sistema en los requisitos de normalmente el puerto SUP- una serie de actividades, incluyendo docu-
software que se han elaborado a partir de ella, y en en los mentación, la localización, y la gestión del cambio y han tenido un
módulos de código que lo implementan, o la casos de prueba impacto significativo en la práctica. De hecho, ing trac- y la gestión del
relacionados con ese código, e incluso una sección dada en el cambio son realmente sólo prác- ticable si es compatible con una
manual de usuario que describe la funcionalidad real) y en el herramienta. Desde la gestión de requisitos es fundamental para la
caso de prueba que verifica. 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).
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.
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


Requisitos de software 1-17

LECTURAS

I. Alexander y L. Beus-Dukic, El descubrimiento  A. van Lamsweerde, requisitos 


requisitos [ 5]. Ingeniería: A partir de los objetivos del sistema de modelos UML
a las especificaciones de software [ 7].
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 Sirve como una buena introducción a la ingeniería de requisitos,
sobre cómo los diferentes elementos de los requisitos de software pero su valor único es como un libro de referencia para los
encajan entre sí. Está lleno de consejos prácticos sobre (por requisitos orientados a objetivos lenguaje de modelado de KAOS.
ejemplo) la manera de identificar los distintos actores del sistema y Explica por qué el modelado meta es útil y muestra cómo se puede
cómo evaluar soluciones alternativas. Su edad cubierta- es ejemplar integrar con técnicas de modelado convencionales usando UML.
y sirve como una referencia útil para técnicas de clave, tales como
modelado de caso de uso y requisitos de priorización.
O. Gotel y A. Finkelstein, “Un análisis del problema
Requisitos trazabilidad” [8].

C. Potts, K. Takahashi, y A. Antón, “indagación Análisis Este trabajo es una obra de referencia clásica en un elemento
Requisitos Basado” [6]. clave de la gestión de requisitos. Basándose en estudios
empíricos, establece las razones y las barreras para el rastreo
Este documento es una cuenta de fácil digestión de trabajo que ha eficaz de los requisitos. Es una lectura esencial para la
demostrado ser muy influyente en el desa- rrollo de las necesidades comprensión de por qué los requisitos de rastreo es un elemento
de manipulación. En él se describe cómo y por qué la elaboración esencial de un proceso de software efectivo.
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 N. Maiden y C. Ncube, “La adquisición de COTS Requisitos
que ayuda a definir su uso en el descubrimiento y la descripción de de selección de software” [9].
los requisitos.
Este documento es importante porque reconoce explícitamente que los
productos de software a menudo integran componentes de terceros.
Ofrece una visión de los problemas de la selección de software
off-the-shelf para satisfacer los requisitos: por lo general hay una falta
de coincidencia. Esto desafía algunos de los supuestos sub fijando la
mayor parte de los requisitos tradicionales dling manipulan de, que
tiende a asumir software personalizado.
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 También podemos examinar y evaluar soluciones alternativas y


compensaciones. Finalmente, podemos utilizar los modelos resultantes
Arquitectura lenguaje de
ADL para planificar actividades de desarrollo posteriores, como la verificación
descripción de CDB del sistema y ción validación, además de su uso como entradas y como
Diseño basado en componentes CRC el punto de partida de la construcción y prueba. En una lista estándar de

Responsabilidad clase Colaborador DFD pro- cesos de ciclo de vida del software, tales como que en la norma ISO
/ IEC / IEEE Std. 12207,
Diagrama de flujo de datos

ERD Diagrama entidad-relación IDL


Procesos del ciclo de vida del software [ 2], diseño de software consiste en
Interfaz de lenguaje de descripción de dos actividades que se ajustan entre el análisis de los requisitos de

MVC Modelo Vista Controlador OO software y la construcción de software:

PDL orientada a objetos


• diseño de la arquitectura de software (a veces llamado
Programa de Lenguaje de Diseño
diseño de alto nivel): desarrolla la estructura de alto nivel y
organización del software y se identifican los distintos
componentes.
INTRODUCCIÓN • Software de diseño detallado: especifica cada componente
en suficiente detalle para facilitar su construcció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]. Esta área de conocimiento Diseño de Software (KA) no habla
Visto como un proceso, diseño de software es el ing la actividad de todos los temas que incluye la palabra “diseño”. En la
del ciclo de vida del software en el que Engineer- mentos de terminología de Tom DeMarco [3], los temas tratados en este
software requisito se analizan con el fin de producir una acuerdo KA principalmente con D-diseño (diseño de
descripción de la estructura interna del software que va a servir descomposición), cuyo objetivo es el mapeo de software en piezas
de base para su construcción. Un diseño de software (el componentes. Sin embargo, debido a su importancia en el campo
resultado) describe el software de archi- tecture, es decir, cómo de la arquitectura de software, también vamos a tratar FP-diseño
se descompone software y organizado en componentes-y las (diseño del patrón de la familia), cuyo objetivo es establecer
caras interrelaciones entre esos componentes. También debe aspectos comunes explotables en una familia de productos de
describir los componentes a un nivel de detalle que permite su software. Esta KA no se ocupa de la I-diseño (diseño invención),
construcció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
El diseño de software juega un papel importante en el requerimientos descu- Ered, ya que este tema es considerado
desarrollo de software: durante el diseño de software, como parte de el proceso de requisitos (ver los requisitos de
ingenieros de software producen varios modelos que forman software KA). Este software de diseño KA se relaciona
una especie de anteproyecto de la solución a implementar. específicamente a un los requisitos de software, Software
Podemos analizar y evaluar estos modelos para determinar si
son o no nos permitirán cumplir con los diversos requisitos.

2-1
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 la comprensión de los límites del diseño. Un número de otras nociones y
de ingeniería de software y met- ods, Calidad de Software y conceptos También son de interés en la comprensión del diseño en su
Computación Fundaciones ciones de Kas. 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).
DISTRIBUCIÓN DE TEMAS PARA EL DISEÑO
DEL SOFTWARE
1.2. Contexto de Diseño de Software
El desglose de temas para el Software de Diseño KA se muestra [4 *, c3]
en la Figura 2.1.
El diseño de software es una parte importante del proceso de
1. Fundamentos del Diseño de Software 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
La conceptos, nociones, y la terminología intro- ducido aquí software de desarrollo. Por lo tanto, es importante comprender las
forman una base subyacente para la sub pie el papel y el principales caracterís- ticas de análisis de requisitos de software,
alcance de diseño de software. diseño de software, la construcción de software, pruebas de software,
y el mantenimiento del software.
1.1. Conceptos generales de diseño
[4 *, c1]
1.3. Software de Diseño de Procesos
En sentido general, el diseño puede ser visto como una forma de [4 *, c2]
resolución de problemas. Por ejemplo, el con- cepto de una
solución de un problema complejo sin solución definitiva, es El diseño del software es generalmente considerado como un proceso de

interesante en términos de dos pasos:


Diseño de Software 2-3

• Diseño arquitectonico (También conocido como el diseño de alto el software se divide en una serie de componentes nombrados
nivel de diseño y de nivel superior) describe cómo el software está más pequeños que tienen interfaces bien definidas que describen
organizado en componentes. las interacciones de los componentes. Por lo general, el objetivo
• El diseño detallado se describe el comporta- miento deseado de es colocar diferentes funcionalidades y responsabilidades en
estos componentes. diferentes componentes.

La salida de estos dos procesos es un conjunto de modelos y • Encapsulación y ocultación de la información significa la
artefactos que registran las mayores las decisiones que se han agrupación y el envasado de los detalles internos de una
tomado, junto con una explicación de los fundamentos de cada abstracción y haciendo esos detalles inaccesibles a entidades
decisión no trivial. Guardando el razonamiento, la capacidad externas.
maintain- a largo plazo del producto de software es mayor. • 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
1.4. Principios de Diseño de Software (conocidos por los clientes) que es independiente de los
[4] [5 *, c6, c7, c21] [6 *, c1, c8, c9] detalles de cómo se realiza el componente (ver encapsulación
y ocultación de la información anterior).
UN principio es “una completa y fundamen- tal ley, doctrina o
suposición” [7]. principios de diseño de software son nociones • Suficiencia, integridad y primitivo. 
clave que proporcionan la base para muchos diferentes El logro de suficiencia y medios de integridad para
enfoques de diseño de software y conceptos. diseño de garantizar que un componente de software captura todas
software prin- cipios incluyen la abstracción; acoplamiento y de las características importantes de una abstracción y nada
cohesión; la descomposición y la modularización; ción más. Ness Primitive- significa que el diseño debe estar
encapsula- / ocultar información; separación de interfaz y la basado en patrones que son fáciles de implementar.
implementación; suficiencia, integridad, y primitivo; y la
separación de preocupaciones. • 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

• Abstracción es “una vista de un objeto que se centra en la para uno o más de sus grupos de interés. Cada vista de la

información relevante para un propósito particular y hace caso arquitectura enmarca uno o más preocupaciones. La separación de

omiso de la der restante de la información” [1] (véase las preocupaciones por los puntos de vista permite a las partes

Abstracción en los Fundamentos de computación KA). En el interesadas para centrarse en algunas cosas a la vez y ofrece un

contexto del diseño de software, dos mecanismos de medio para gestionar la complejidad [9].

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 2. Cuestiones clave en el diseño de software

datos como parámetros con nombre. Abstracción por la


especificación conduce a tres tipos principales de la Una serie de cuestiones clave debe ser tratado en el diseño de
abstracción: abstracción de procedimientos, la abstracción de software. Algunos son problemas de calidad que todo el software
datos, y la abstracción de control (iteración). 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
• Acoplamiento y cohesión. El acoplamiento se define como “una es tan fundamental que todos los enfoques de diseño enmarcan
medida de la interdependencia entre los módulos en un en una forma u otra (véase la sección 1.4, Principios de diseño de
programa de ordenador”, mientras que la cohesión se define software, y el tema 7, Software de Diseño Estrategias y Métodos).
como “una medida de la fuerza de la asociación de los Por el contrario, otras cuestiones “trato con algún aspecto del
elementos dentro de un módulo” [1]. comportamiento del software que no está en el dominio de la
aplicación, pero que aborda algunas de las apoyando
• La descomposición y la modularización. posando descomposición y
la modularización significa que grandes
2-4 Guía SWEBOK® V3.0

dominios”[10]. Estas cuestiones, que a menudo crosscut la 2.6. Interacción y Presentación 


funcionalidad del sistema, se han referido como aspectos, que [5 *, c16]
“tienden a no ser unidades de descomposición funcional de soft-
ware, sino más bien a ser propiedades que afectan al Este problema de diseño se ocupa de cómo es- tructura y organizar las
rendimiento o tics seman- de los componentes en formas interacciones con los usuarios, así como la presentación de información
sistémicas” [11]. Varias de estas cuestiones clave, transversales (por ejemplo, la separación de presentación y la lógica de negocio
se tratan en las secciones siguientes (presentados en orden utilizando el enfoque del Modelo-Vista-Controlador). Tenga en cuenta
alfabético). 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.1. concurrencia
[5 *, c18]
2.7. Seguridad
Diseño para la concurrencia tiene que ver con el software de presentación [5 *, c12, c18] [13 *, c4]
descomposición en los procesos, tareas y discusiones y hacer frente a

cuestiones relacionadas con la eficiencia, la atomicidad, sincronización y Diseño para la seguridad tiene que ver con la forma de pre ventilar la
programación. 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
2.2. Control y manejo de Eventos forma en que tolerar ataques o violaciónes relacionadas con la seguridad
[5 *, c21] 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.
Este problema de diseño se ocupa de la forma de organizar los datos y El control de acceso es un con- cepto fundamental de la seguridad, y
flujo de control, así como la forma de manejar los eventos reactivos y también se debe garantizar el buen uso de la criptografía.
temporales a través de diversos mecanismos como la invocación
implícita y devoluciones de llamadas.

3. Estructura del software y Arquitectura


2.3. Persistencia de datos 
[12 *, c9] En su sentido más estricto, una arquitectura de software es “el conjunto
de las estructuras necesarias para razonar acerca del sistema, que
Este problema de diseño se ocupa de cómo se manipulan de datos de comprenden elementos de software, las relaciones entre ellos, y las
larga vida dle. propiedades de ambos” [14 *]. A mediados de la década de 1990, sin
embargo, la arquitectura de software comenzó a surgir como una
2.4. Distribución de Componentes disciplina más amplia que implicaba el estudio de las estructuras y
[5 *, c18] 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
Este problema de diseño se ocupa de cómo redistribuir el diferentes nive- les de abstracción. Algunos de estos conceptos pueden
software en el hardware (INCLUYENDO hardware de ser útiles en el diseño arquitectónico (por ejemplo, los estilos
ordenador y hardware de red), cómo se comunican los arquitectónicos), así como durante el diseño detallado (por ejemplo, el
componentes, y cómo middleware se puede utilizar para diseño Pat- charranes). Estos conceptos de diseño también se pueden
tratar con el software heterogéneo. 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
2.5. Error y control de excepciones y la tolerancia a fallos reutilización, el conocimiento de diseño.

[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.
Diseño de Software 2-5

3.1. Las estructuras arquitectónicas y puntos de vista patrones que describen la organización de alto nivel de software,
[14 *, c1] otros patrones de diseño se pueden utilizar para describir los
detalles en un nivel inferior. Estos patrones de diseño de bajo nivel
Las diferentes facetas de alto nivel de un diseño de software pueden ser son los siguientes:
descritos y documentados. Estas facetas son a menudo llamados puntos
de vista: “Una vista representa un aspecto parcial de una arquitectura de • patrones de creación (por ejemplo, constructor, fábrica,
software que muestra propiedades especí- espe- de un sistema de prototipo, Singleton)
software” [14 *]. Vistas pertenecen a distintos temas relacionados con el • patrones estructurales (por ejemplo, adaptador, puente,
software de diseño, por ejemplo, la vista lógica (satisfaciendo los compuesto, decorador, fachada, peso FLY-, Proxy)
requisitos funcionales) frente a la vista de procesos (problemas de
concurrencia) frente a la vista física (problemas de distribu- ción) frente a • Los patrones de comportamiento (por ejemplo, comandos,

la vista de desarrollo (como el el diseño se divide en unidades de intérprete, iterador, mediador, recuerdo,
ejecución con representación explícita de las dependencias entre las observador, estado, estrategia, plantilla, visitante).
unidades). Varios autores utilizan diferentes terminologías-como frente a
la conducta funcional vs. vistas de modelado de datos vs. estructurales. 3.4. Las decisiones Arquitectura Diseño
En resumen, un diseño de software es un artefacto multifacético [5 *, c6]
producido por el proceso de diseño y generalmente compuesta de
puntos de vista relativamente independientes y ortogonales. 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
3.2. Estilos arquitectónicos [ 14 *, c1, c2, c3, c4, c5] 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.
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 3.5. Las familias de los programas y marcos 
software. Varios autores han identificado una serie de grandes estilos [5 *, C6, C7, C16]
tectural arqui-:
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

• Las estructuras generales (por ejemplo, capas, tuberías y como líneas de productos de software. Esto se puede hacer mediante la

filtros, pizarra) identificación de los puntos en común entre los miembros de estas familias

• Los sistemas distribuidos (por ejemplo, cliente-servidor, tres y mediante el diseño de componentes reutilizables y personalizables para

niveles, broker) dar cuenta de la variabilidad entre los miembros de la familia. En la

• Los sistemas interactivos (por ejemplo, Model-View- programación orientada a objetos (OO), una noción relacionada clave es

Controller, Presentación-Abstracción-Control) que de un marco: un sistema de software parcialmente completado que

• sistemas adaptables (por ejemplo, nel microker-, puede ser extendido por instanciar apropiadamente extensiones

reflexión) específicas (tales como plug-ins).

• Otros (por ejemplo, por lotes, intérpretes, control pro- ceso,


basado en reglas).

3.3. Patrones de diseño 4. Diseño de Interfaz de Usuario

[15 *, c3, c4, c5]


diseño de la interfaz de usuario es una parte esencial del proceso de
Sucintamente descrito, un patrón es “una solución común a un diseño de software. diseño de interfaz de usuario debe asegurarse de
problema común en un contexto dado” [16]. Mientras que los estilos que la interacción entre el humano y la máquina proporciona para un
arquitectónicos pueden ser vistos como funcionamiento eficaz
2-6 Guía SWEBOK® V3.0

y el control de la máquina. Para el software para alcanzar su pleno y la presentación del software, los antecedentes y la experiencia
potencial, la interfaz de usuario debe ser diseñado para que coincida de los usuarios de software y los dispositivos disponibles.
con las habilidades, experiencia y expectativas de sus usuarios
previstos.
4.3. El diseño de las modalidades de interacción del usuario
4.1. Principios generales para el usuario el diseño de interfaces [5 *, c29-web] [17 *, c2]
[5 *, c29-web] [17 *, c2] 1
La interacción del usuario implica la emisión de comandos y la
• Facilidad de aprendizaje. El software debe ser fácil de aprender para disponibilidad de datos asociada con el software. estilos de interacción
que el usuario pueda iniciar rápidamente tra- baja con el software. del usuario se pueden clasificar en los estilos primarios siguien- tes:

• la familiaridad del usuario. La interfaz debe utilizar términos y


conceptos extraídos de los experimentos de los cias personas que • Pregunta respuesta. La interacción es esencialmente
vayan a utilizar el software. restringido a un único intercambio de preguntas y
• Consistencia. La interfaz debe ser tienda de campaña consis- para respuestas entre el usuario y el software. El usuario
que las operaciones comparables se acti- vada de la misma envía una pregunta al software y el software devuelve la
manera. respuesta a la pregunta.
• sorpresa mínimo. El comportamiento del software no debe
sorprender a los usuarios. • Manipulación directa. Los usuarios interactúan con los objetos
• Recuperabilidad. La interfaz debe proporcionar mecanismos que en la pantalla del ordenador. La manipulación directa a
permitan a los usuarios a recuperarse de los errores. menudo incluye un dispositivo señalador (como un ratón,
trackball o un ger de dedos en las pantallas táctiles) que
• guía para el usuario. La interfaz debe dar retroalimentación manipula un objeto e invoca las acciones que especifican lo
significativa cuando se producen errores y proporcionar ayuda que se debe hacer con ese objeto.
contextual para los usuarios.
• la diversidad de usuario. La interfaz debe pro- mecanismos de • selección de menú. El usuario selecciona un comando de una lista
interacción vide apropiados para diversos tipos de usuarios y de los comandos de menú.

para los usuarios con capacidades diferentes (ciegos, • Forma de relleno. El usuario llena en los campos de un formulario.
problemas de visión, sordos, ciegos al color, etc.). A veces campos incluyen menús, en cuyo caso el formulario tiene
botones de acción para que el usuario inicie la acción.

4.2. Interfaz de usuario Problemas Diseño • lenguaje de comandos. El usuario emite un com- mand y
[5 *, c29-web] [17 *, c2] proporciona los parámetros relacionados para dirigir el
software qué hacer.
diseño de interfaz de usuario debe resolver dos cuestiones fundamentales: • Lenguaje natural. El usuario emite un com- mand en
lenguaje natural. Es decir, el lenguaje natural es una
• ¿Cómo debe el usuario interactuar con el software? interfaz a un lenguaje de comandos y se analiza y se
traduce en comandos de soft- ware.
• ¿Cómo debe la información desde el software se
presenta al usuario?
4.4. El diseño de la información Presentación
diseño de interfaz de usuario debe integrar la interacción del [5 *, c29-web] [17 *, c2]
usuario y presentación de la información. diseño de interfaz de
usuario debe considerar un compromiso entre los estilos más presentación de la información puede ser textual o gráficamente cal en
apropiados de interacción 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
1 Capítulo 29 es un capítulo basado en la web disponible en http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
presentación de información se separe de la información que se
WebChapters / .
presenta.
Diseño de Software 2-7

Los ingenieros de software también tienen en cuenta el tiempo de 4.6. Localización e internacionalización
respuesta del software y la retroalimentación en el diseño de presentación [17 *, c8, c9]
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 diseño de interfaz de usuario a menudo necesita considerar la
el software responde con una respuesta. Una indicación del progreso es internacionalización y localización, que son medios para adaptar el
deseable poder mientras que el software está preparando la respuesta. La software a los diferentes idiomas, diferencias regionales y las
retroalimentación puede ser proporcionado mediante la reformulación de exigencias técnicas de un mercado objetivo. La internacionalización
la entrada del usuario mientras que el procesamiento se está terminando. es el proceso de diseño de una aplicación de software para que
Abstractos visualizaciones pueden ser utilizados cuando grandes pueda ser adaptado a diferentes idiomas y regiones sin mayores
cantidades de información se han de presentar. De acuerdo con el estilo cambios de ingeniería. La localización es el proceso de adaptación
de presenta- ción de la información, los diseñadores también pueden de soft- ware internacionalizado para una región o idioma mediante
utilizar el color para mejorar la interfaz. Existen varias pautas importantes: 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.
• 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. 4.7. Metáforas y modelos conceptuales [ 17 *, c5]
• Use códigos de colores de una manera reflexiva y consis- carpa.

• Use colores para facilitar el acceso de las personas con los diseñadores de interfaces de usuario pueden utilizar metáforas y

ceguera o deficiencia cromática de color (por ejemplo, utilizar el modelos conceptuales para establecer correspondencias entre el software

cambio de la saturación del color y el brillo del color, tratar de y algún sistema de referencia conocida a los usuarios en el mundo real, lo

evitar combinaciones de azul y rojo). 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

• No dependa sólo en el color para transmitir información convertir en una metáfora con el icono de un cubo de basura. En el diseño

importante para los usuarios con capacidades diferentes de una interfaz de usuario, inge- niería de software deben tener cuidado

(ceguera, problemas de visión, ceguera por colores, etc.). 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

4.5. Proceso de Interfaz de usuario Diseño misma manera dentro de todas las culturas.

[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 5. Análisis de Calidad de Software de Diseño y
organización, y la apariencia de la interfaz de usuario soft- ware. Este Evaluación
proceso incluye tres actividades principales:
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
• análisis usuario. En esta fase, el diseñador ana- lyzes tareas de de software. (Véase también la calidad KA software).
los usuarios, la ment ENTORNO trabajo, otro software, y cómo
los usuarios interactúan con otras personas.
5.1. Los atributos de calidad
• creación de prototipos de software. El desarrollo de prototipos de [4 *, c4]
software ayudan a los usuarios a guiar la evolución de la interfaz.

Varios atributos contribuyen a la calidad de un diseño de software,


• evaluación de la interfaz. Los diseñadores pueden observar las incluyendo varios “-ilities” (mantenibilidad, portabilidad, capacidad de
experiencias de los usuarios con la interfaz de evolución. prueba, la facilidad de uso)
2-8 Guía SWEBOK® V3.0

y “-nesses” (exactitud, robustez). Hay una interesante distinción 5.3. medidas


entre la calidad buye atri- discernibles en tiempo de ejecución (por [4 *, c4] [5 *, c24]
ejemplo, per- formance, seguridad, disponibilidad, funcionalidad,
facilidad de uso), los que no discernible en tiempo de ejecución (por Las medidas pueden ser utilizados para evaluar o estimar
ejemplo, modificabilidad, portabilidad, reusabilidad, la capacidad de cuantitativamente diversos aspectos de un diseño de software; por
prueba), y aquellos relacionada con las cualidades intrínsecas de la ejemplo, tamaño, estructura, o la calidad. La mayoría de las
arquitectura (por ejemplo, conceptual integri- dad, exactitud, medidas que se han propuesto dependen del método utilizado para
integridad). (Véase también la calidad KA software). la producción del diseño. Estas medidas se clasifican en dos
grandes categorías:

5.2. Análisis de calidad y técnicas de evaluación • medidas (estructurada) de diseño basados ​en funciones: medidas
[4 *, c4] [5 *, c24] obtenidas mediante el análisis fun- cional de descomposición;
generalmente representado mediante un diagrama de estructura
Varias herramientas y técnicas pueden ayudar en ing analyz- y la (a veces llamado un diagrama jerárquico) sobre la que se pueden
evaluación de la calidad del diseño de software. calcular diversas medi- das.

• Software revisiones de diseño: técnicas malized informales y • medidas de diseño orientada a objetos: la estructura de diseño
lucro para determinar la calidad de los artefactos de diseño se representa típicamente como un diagrama de clases, en el
(por ejemplo, la arquitectura comentarios, revisiones de diseño, que se pueden calcular diversas medidas. Medidas sobre las
e inspecciones técnicas basadas en escenarios; propiedades del contenido interno de cada clase también se
requisitos pueden calcular.
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 6. Diseño de Software notaciones
revisados.

• El análisis estático: static formal o semiformal análisis (no Existen muchas notaciones para representar artefactos de diseño de
ejecutable) que puede ser utilizado para evaluar un diseño (por software. Algunos se utilizan para describir la organización estructural de
ejemplo, análisis de árbol a fallos o automatizada comprobación un diseño, otros para representar el comportamiento de soft- ware.
cruzada). análisis de vulnerabilidad de diseño (por ejemplo, el Ciertas notaciones se utilizan sobre todo durante el diseño arquitectónico
análisis estático de las debilidades de seguridad) puede llevarse y otros, principalmente durante el diseño detallado, aunque algunas
a cabo si la seguridad es una preocupación. El análisis formal anotaciones se pueden utilizar para ambos propósitos. Además, algunas
del diseño utiliza modelos matemáticos que permiten a los anotaciones se utilizan sobre todo en el contexto de los métodos de
diseñadores predicado el comportamiento y validar el diseño específicos (ver tema 7, Software de Diseño Estrategias y
rendimiento del software en lugar de tener que depender por Métodos). Tenga en cuenta que el diseño de software a menudo se logra
completo de la prueba. análisis de diseño formal puede ser usando notaciones múlti- ples. A continuación, se clasifican en las
utilizado para detectar errores de especificación y diseño notaciones para describir la vista estructural (estático) frente a la vista del
residuales (per- HAPS causado por la imprecisión, la comportamiento (dinámico).
ambigüedad, y algunas veces otros tipos de errores). (Ver
también los modelos de ingeniería de software y métodos KA).

6.1. Las descripciones estructurales (estático Vista)


[4 *, c7] [5 *, c6, c7] [6 *, c4, c5, c6, c7]
• Simulación y prototipado: técnicas dinámicas para [12 *, c7] [14 *, c7]
evaluar un diseño (por ejemplo, la simulación de
rendimiento o factibilidad Las siguientes anotaciones, en su mayoría, pero no siempre
prototipos). gráfica, describir y representar los aspectos estructurales de un
diseño de software es que, son
Diseño de Software 2-9

utilizan para describir los componentes principales y la forma en que están • diagramas de actividad: se utiliza para mostrar el flujo de control de

interconectados (visión estática): una actividad a. Se puede utilizar para repre- actividades

concurrentes resienten.

• Descripción de la arquitectura idiomas (AVD): textual, a • diagramas de comunicación: se utilizan para mostrar las
menudo formal, idiomas utilizados para describir la interacciones que se producen entre un grupo de objetos; se
arquitectura de software en términos de componentes y hace hincapié en los objetos, sus enlaces, y los mensajes que
conectores. intercambian en estos enlaces.
• Clase y objeto diagramas: se utilizan para represen- envían
un conjunto de clases (y objetos) y sus interrelaciones. • diagramas de flujo de datos (DFDs): Se utiliza para mostrar el flujo
de datos entre los elementos. Un flujo de datos gramo dia- ofrece
• diagramas de componentes: utilizados para representar un “una descripción basada en modelo- ing el flujo de información en
conjunto de componentes ( “físico y reemplazar- parte capaz [s] torno a una red de elementos operativos, con cada elemento
de un sistema que [conforme] para y [proporcionar] la haciendo uso de o la modificación de la información que fluye en
realización de un conjunto de caras inter” [18]) y sus ese elemento” [4 *]. Los flujos de datos (y por tanto los diagramas
interrelaciones . de flujo de datos) se pueden utilizar para el análisis de la
• Clase tarjetas responsabilidad colaboradores (CRC): se seguridad, ya que ofrecen identifica- ción de posibles caminos para
utiliza para denotar los nombres de los componentes (clase), sus el ataque y el cierre difusión de la información confidencial.
responsabilidades, y los nombres de sus componentes que
colaboran.
• Los diagramas de despliegue: utilizados para representar un • Las tablas de decisión y diagramas: se utilizan para REPRESENTA
conjunto de nodos (físicas) y sus interrelaciones, y, por lo combinaciones complejas de condiciones y acciones.
tanto, para modelar los aspectos físicos de software.
• Diagramas de flujo: se utilizan para representar el flujo
• diagramas entidad-relación (ERD): se utilizan para representar los de control y las acciones asociadas a realizar.
modelos conceptuales de los datos almacenados en los depósitos

de información. • Los diagramas de secuencia: se utiliza para mostrar las


• Descripción de la interfaz de idiomas (IDL): lenguajes de interacciones entre un grupo de objetos, con énfasis en el
programación que se usa para definir las interfaces (nombres ordenamiento hora de los mensajes transmitidos entre objetos.
y tipos de operaciones exportados) de los componentes de
software. • transición de estado y tabla de estado diagramas: se utiliza para
• los diagramas de estructura: se utiliza para describir la estructura de mostrar el flujo de control de estado a estado y cómo el
los programas de llamadas (que los módulos de llamada, y se comportamiento de un componente cambia sobre la base de su
llaman por, qué otros módulos). estado actual en una máquina de estado.

6.2. Las descripciones de comportamiento (vista dinámica)  • lenguajes de especificación formales: idiomas textuales que
[4 *, c7, c13] [5 *, c6, c7] [6 *, c4, c5, c6, c7] utilizan nociones básicas de matemá- ticas (por ejemplo, la lógica,
[14 *, c8] set, secuencia) para definir rigurosamente y de manera abstracta
interfaces de componentes de software y el comportamiento, a
Las siguientes notaciones y lenguajes, algunos gráfica y textual alguna, menudo en términos de condiciones previas y posteriores. (Véase
se utilizan para describir el comportamiento dinámico de los sistemas y también la Ingeniería de Software Modelos y ods met KA).
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 • pseudo código y lenguajes de diseño de programas (PDL):
justificación de la decisión de diseño tales como la forma de un diseño lenguajes de programación como estructurados utilizados para
cumplirá con los requisitos de seguridad. 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 diseño de mediados de 1980 (sustantivo = objeto; verbo = método;
adjetivo = atributo), donde heren- cia y el polimorfismo juegan un papel
Existen varias estrategias generales para ayudar a guiar el proceso de clave, al campo del diseño basado en componentes, donde la formación
diseño. En contraste con las estrategias generales, los métodos son de metain- se puede definir y se accede ( a través de la reflexión, por
más específicos en cuanto a que proporcionan generalmente un ejemplo). Aunque las raíces del diseño orientado a objetos provienen
conjunto de notaciones para ser utilizado con el método, una del concepto de abstracción de datos, diseño impulsado por la
descripción del proceso que se utilizará cuando se sigue el método, y responsabilidad ha sido propuesta como un enfoque alternativo al
un conjunto de directrices para el uso del método. Tales métodos son diseño orientado a objetos.
ú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.4. Estructura centrada en los datos de diseño [ 4 *, c14, c15]

7.1. Estrategias generales [ 4 *, c8, c9, c10] [12 *, c7] 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
Algunos ejemplos citados con frecuencia de las estrategias generales estructuras de datos de entrada y salida y luego se desarrolla la estructura
útiles en el proceso de diseño incluyen las estrategias de dividir-y-vencerás de control del programa en base a estos diagramas de estructura de
y refinamiento paso a paso, de arriba hacia abajo frente a las estrategias datos. Se han propuesto varias heurísticas para hacer frente a ejemplo
de abajo hacia arriba, y las estrategias que hacen uso de la heurística, el especial casos-para, cuando hay una falta de coincidencia entre las
uso de patrones y lenguajes tern PAT- y el uso de un enfoque iterativo y estructuras de entrada y salida.
mentales incre-.

7.5. Diseño basado en componentes (CDB)


7.2. Función-Oriented (Estructurado) Diseño [4 *, c17]
[4 *, c13]
Un componente de software es una unidad independiente, que tiene
Este es uno de los métodos clásicos de diseño de software, donde los interfaces bien definidas y dependen- cias que pueden estar
centros de descomposición en que identifique los valores las principales compuestos y desplegado de forma independiente. aborda cuestiones
funciones del software y luego elab- perorando y refinarlos en una de de diseño basadas en componentes relacionados con la prestación, el
arriba hacia abajo de forma jerárquica. Diseño estructurado se utiliza desarrollo y la integración de estos componentes con el fin de mejorar
generalmente después de un análisis estructurado, produciendo de este la reutilización. Reutilizados y off-the-shelf software com- ponentes
modo (entre otras cosas) diagramas de flujo de datos y descripciones de deben cumplir mentos el mismo requisito de seguridad como un nuevo
procesos asociados. Los investigadores han propuesto diversas software. gestión de la confianza es un problema de diseño;
estrategias (por ejemplo, el análisis de la transformación, análisis de componentes tratados como hav- ing un cierto grado de confiabilidad
transacciones) y heurística (por ejemplo, fan-in / fan-out, el alcance de no debe depender de componentes o servicios sean menos fiables.
efecto vs. alcance de control) para transformar un DFD en una arquitectura
de software en general representado como una diagrama de estructura.

7.6. Otros metodos


[5 *, c19, c21]
7.3. Diseño Orientado a Objetos
[4 *, c16] También existen otros enfoques interesantes (ver los
modelos de ingeniería de software y métodos KA). Los
Se han propuesto numerosos métodos de diseño de software métodos iterativos y adaptativas Imple- incrementos de
basados ​en objetos. El campo ha evolucionado a partir de la software Ment y reducir énfasis en el requisito de software
orientada a objetos temprano (OO) rigurosa y diseño .
Diseño de Software 2-11

diseño orientada a aspectos es un método por el cual el software se 8. Herramientas de diseño de software [ 14 *, c10, Apéndice A]

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 Las herramientas de diseño de software se puede utilizar para apoyar la

manera de construir software distribuido mediante servicios web creación de los artefactos de diseño de software durante el proceso de

ejecutados en ordenadores distribuidos. sistemas de soft- ware se desarrollo de software. Pueden apo- parte portuaria o la totalidad de las

construyen a menudo mediante el uso de servi- cios de diferentes siguientes actividades:

proveedores porque protocolos estándar (tales como HTTP, HTTPS,


SOAP) se han diseñado para soportar la comunicación de servicios y • traducir el modelo de requisitos en una representación
el intercambio de información de servicio. 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
Diseño de Software 2-15

LECTURAS Referencias

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]. 2010.

Por cerca de tres décadas, Roger Pressman de [2] IEEE Std. 12207-2008 (también conocido como ISO / IEC 

Ingeniería de Software: Enfoque para profesionales 12207: 2008) Estándar de Sistemas y Software de
ha sido uno de los libros de texto más importantes del mundo en Ingeniería de Software-procesos de ciclo de vida, IEEE
ingeniería de software. Cabe destacar que este libro de texto comple- 2008.
mentarios a [5 *] integral presenta software de diseño, incluyendo los
conceptos de diseño, diseño arquitectónico, diseño a nivel de [3] T. DeMarco, “The Paradox de Software
componentes, diseño de la interfaz de usuario, diseño basado en Arquitectura y diseño,”Conferencia Premio Stevens,
patrones y diseño de aplicaciones web. 1999.

[4 *] D. Budgen, Diseño de software, 2ª ed.,


“El 4 + 1 Ver Modelo de Arquitectura” [20]. Addison-Wesley, 2003.

El artículo seminal “The 4 + 1 Vista Modelo” or- noce una descripción [5 *] I. Sommerville, Ingeniería de software, noveno
de una arquitectura de software utilizando cinco vistas concurrentes. ed., Addison-Wesley, 2011.
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 [6 *] M. Página-Jones, Fundamentos de objeto-
casos o escenarios de uso seleccionadas para ilustrar la arquitectura. Diseño orientado en UML, 1ª ed., Addison-Wesley,
Por lo tanto, el modelo contiene 4 + 1 vistas. Las vistas se utilizan 1999.
para describir el software según lo previsto por las diferentes partes
interesadas, tales como los usuarios finales, desarrolladores y [7] Diccionario Colegiado de Merriam-Webster,
administradores de proyectos. ed 11., 2003.

[8] IEEE Std. 1069-2009 estándar para 


Tecnología de la Información-Sistemas-Diseño de Software
Len Bass, Paul Clements, y Rick Kazman, Las descripciones de diseño,
Arquitectura de software en la práctica [ 21]. IEEE 2009.

Este libro presenta los conceptos y las mejores ticas ticas de [9] ISO / IEC 42010: 2011 Sistemas y Software 
arquitectura de software, es decir, cómo el software está estructurado Ingeniería-Práctica Recomendada para la descripción
y cómo interactúan los componentes del software. Basándose en su arquitectónica de los sistemas intensivos Software-, ISO /
propia experiencia, los autores cubren los temas técnicos esenciales IEC 2011.
para el diseño, especificación y validación de arquitecturas de
software. También hacen hincapié en la importancia del contexto [10] J. Bosch, Diseño y Uso de Software 
empresarial en el que se ha diseñado gran soft- ware. Su objetivo es Arquitecturas: La adopción y el desarrollo de un enfoque
dar a conocer la arquitectura de software en un entorno del mundo Producto-Línea, ACM Press, 2000.
real, lo que refleja tanto las oportunidades y limitaciones que orga-
nizaciones encuentran. Este es uno de los mejores libros disponibles [11] G. Kiczales et al., “Orientado a Aspectos
en la actualidad en la arquitectura de software. 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


Construcción de Software 3-3

estos conceptos y describen cómo se aplican a la construcción. 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

1.1. Complejidad minimizando código y pruebas de unidad, la organización de código para apoyar

[1 *] pruebas automatizadas, y restrict- ing el uso de estructuras len- guaje

complejas o difíciles de comprender, entre otros.

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 1.4. Reutilizar
factor importante que influye en cómo las personas transmiten intención [2 *]
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 Reutilización refiere al uso de los activos existentes en la solución de
reducir la complejidad se aplica esencialmente a todos los aspectos de la diferentes problemas. En la construcción de software, los activos ical
construcción de software y es particularmente crítico para las pruebas de typ- que se reutilizan incluyen bibliotecas, módu-, componentes, código
las construcciones de software. 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
En la construcción de software, complejidad reducida se logra productividad de software, la calidad y mejora de los costes.
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 Reutilización tiene dos facetas estrechamente relacionados: “la

Construcción), el diseño modular (ver sección 3.1, Diseño construcción para la reutilización” y “reutilización construcción con” Los

Construcción), y otras numerosas técnicas específicas (ver antiguos medios para crear activos de software reutilizables, mientras que

sección 3.3, Coding). También es apoyado por técnicas de el segundo medio para la reutilización de activos de software en la

calidad centrado con la construcción (ver sec- ción 3.7, construcción de una nueva solución. Reutilización menudo trasciende los

Construcción de Calidad). límites de los proyectos, lo que significa activos reutilizados se pueden

construir en otros proyectos u organizaciones.

1.2. pronóstico del cambio 


[1 *] 1.5. Normas de construcción 
[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; La aplicación de Dardos desarrollo dares externos o internos durante la
los cambios en los entornos en los que opera el software también construcción ayuda a lograr los objetivos de un pro- yecto para la
afectan al software de diversas maneras. eficiencia, la calidad y el costo. En concreto, las opciones de progra-
permisible subconjuntos del lenguaje Ming y normas de uso de ayudas
Anticipar el cambio ayuda a los ingenieros de software construir son importantes para lograr una mayor seguridad. Normas que afectan
software extensible, lo que significa que pueden mejorar un directamente a problemas de construcción incluyen
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). • métodos de comunicación (por ejemplo, Standards para
formatos de documentos y contenidos)
1.3. La construcción de Verificación • lenguajes de programación (por ejemplo, las normas len-
[1 *] guaje para lenguajes como Java y C ++)

La construcción de medios de verificación de construcción de software de • los estándares de codificación (por ejemplo, los estándares para las

tal manera que los fallos pueden ser lectura ily encontrados por los convenciones de nomenclatura, el diseño y la sangría)

ingenieros de software de escritura del software, así como por los • plataformas (por ejemplo, los estándares de interfaz de llamadas al
probadores y usuarios durante sistema operativo)
3-4 Guía SWEBOK® V3.0

• herramienta (por ejemplo, normas para anotaciones el Software de Gestión y Procesos de Software KAs).
esquemáticas como UML (Unified Modeling Language)).
En consecuencia, lo que se considera que es “cons- trucción”
depende en cierta medida en el modelo de ciclo de vida utilizado. En
El uso de estándares externos. La construcción depende de la general, la construcción de software es en su mayoría codificación y
utilización de estándares externos para lenguajes de construcción, depuración, pero también implica la planificación de la construcción,
herramientas de construcción, interfaces técnicas, y las diseño detallado, las pruebas unitarias, pruebas de integración, y otras
interacciones entre el software de construcción KA y otros KAs. actividades.
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- 2.2. Ordenación de la Edificación
nacionales (tales como el IEEE o ISO). [1 *]

El uso de estándares internos. Las normas también pueden ser creados La elección del método de construcción es un aspecto clave de la
sobre una base de organización a nivel corpo- rativa o para su uso en actividad de la construcción-planificación. La elección del método
proyectos específicos. Estas normas apoyan la coordinación de las de construcción afecta el grado en que se realizan los requisitos
relaciones de grupo activi-, lo que minimiza la complejidad, la anticipación previos de la construcción, el orden en que se realizan, y el grado
del cambio, y la construcción para su verificación. en que deben ser completados antes de que comience el trabajo
de construcción.

2. Gestión de la 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
2.1. Construcción de Modelos de Ciclo de Vida construir para su verificación. Cada uno de estos objetivos también
[1 *] 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
Numerosos modelos han sido creados para el desarrollo de software; construcción.
algunos hacen hincapié en la construcción más que otros.
planificación de la construcción también define el orden en que
Algunos modelos son más lineal desde el punto cons- trucción de se crean los componentes e integrados, la estrategia de
vista, tales como la cascada y modelos de ciclo de vida de la integración (por ejemplo, por etapas o integración incremental), los
entrega por etapas. Estos modelos tratan de la construcción como procesos de gestión de calidad de software, la asignación de la
una actividad que se produce sólo después del trabajo prerrequisito asignación de tareas a los ingenieros de software específicos, y
importante ha sido com- pletó-requisitos detallados incluyendo el otras tareas, de acuerdo con el método elegido.
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 2.3. Medición de la construcción 
menticias SEP más claras entre las actividades. En estos modelos, [1 *]
el énfasis principal de la construcción puede ser de codificación.
Otros modelos son más iterativo como el prototipado evolutivo y Numerosas actividades de construcción y los artefactos se pueden medir,

desa- rrollo ágil. Estos enfoques tienden a tratar la cons- trucción incluyendo el código desarrollado, código modificado, reutilizado código, el

como una actividad que se produce simultáneamente con otras código destruida, código de complejidad, las estadísticas de inspección de

actividades de desarrollo de software (incluyendo los requisitos, el código, culpa y culpa-fix-encontrar tarifas, el esfuerzo y la programación.

diseño y la planificación) o que los solapamientos. Estos enfoques Estos surements Measure pueden ser útiles para los propósitos de la

tienden a diseño, codificación, y las actividades de prueba mezclar, gestión de la construcción, lo que garantiza la calidad durante la

y que a menudo tratan la combinación de actividades como la construcción, y mejorar el proceso de construcción, entre otros usos

construcción (ver (véase la Ingeniería de Procesos de Software KA para más información

sobre la medición).
Construcción de Software 3-5

3. Consideraciones prácticas instalaciones. Los archivos de configuración basados ​en texto que se
utilizan tanto en los sistemas operativos Windows y Unix son ejemplos
La construcción es una actividad en la que el ingeniero de software de esto, y las listas de selección de estilo de menú de algunos
tiene que hacer frente a las limitaciones del mundo real a veces generadores de programas constituiría, otro ejemplo de un lenguaje de
caóticos y cambiantes, y él o ella debe hacerlo con precisión. Debido a configuración.
la influencia de las restricciones del mundo real, la construcción está idiomas Toolkit se utilizan para construir aplica- ciones de elementos de
más impulsado por consideraciones prácticas que algunos otros Kas, e juegos de herramientas (series integradas de partes reutilizables

ingeniería de software es quizás lo más oficio- como en las actividades específicos de la aplicación); que son más complejos que los idiomas de

de construcción. 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

3.1. Diseño de la construcción herramientas.

[1 *]
Los lenguajes de script son tipos de uso común de los lenguajes de
Algunos proyectos de diseño asignan considerable activi- dad a la programación de aplicaciones. En algunos lenguajes de script, guiones
construcción, mientras que otros asignan diseño a una fase centrada son llamados archivos por lotes o macros.
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 Lenguajes de programación son el tipo más flexible de las lenguas
construcción, y que el trabajo de diseño tiende a ser dictado por las de construcción. También contienen la menor cantidad de
limitaciones impuestas por el problema del mundo real que está siendo información sobre áreas específicas de aplicación y desarrollo de
tratado por el software. procesos-, por lo tanto, requieren más entrenamiento y habilidad
para utilizar con eficacia. La elección del len- guaje de programación
Al igual que los trabajadores de la construcción la construcción de una puede tener un gran efecto sobre la probabilidad de vulnerabilidades
estructura físi- cas deben hacer modificaciones a pequeña escala para dar de ser introducido durante coding- por ejemplo, el uso acrítico de C y
cuenta de las lagunas no previstos en los planes del constructor, C ++ son opciones cuestionables desde un punto de vista de la
trabajadores de la construcción de software deben hacer modificaciones seguridad. Hay tres tipos generales de notación que se utiliza para
en una escala más pequeña o más grande para dar cuerpo a los detalles lenguajes de programación, es decir,
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, • lingüística (por ejemplo, C / C ++, Java)

pero se aplican en una escala más pequeña de algoritmos, • formales (por ejemplo, Evento-B)

estructuras de datos y las interfaces. • visual (por ejemplo, MatLab).

notaciones lingüísticas se distinguen en parti- cular por el uso


3.2. Idiomas de construcción de cadenas de texto para representar construcciones de software
[1 *] complejos. La combinación de cadenas de texto en patrones puede
lenguas de construcción incluyen todas las formas de comunicación tener una sintaxis frase similar. Si se usa adecuadamente, cada
mediante el cual un ser humano puede especificar una solución de un uno de tales cadena debe tener una fuerte connotación semántica
problema ejecutable a un problema. idiomas cons- trucción y sus proporcionar una comprensión intuitiva inmediata de lo que
implementaciones (por ejemplo, los compiladores) pueden afectar a los sucederá cuando el software se ejecuta trucción ción.
atributos de calidad de software de rendimiento, fiabilidad, rentabilidad
por-, y así sucesivamente. Pueden ser graves contribuyentes al
vulnerabilidades de seguridad. Las notaciones formales depender menos intuitiva, every- significados
día de palabras y cadenas de texto y más en las definiciones respaldadas

El tipo más simple del lenguaje es una construcción lenguaje de por definiciones precisas, de forma ambigua unidades organizativas y

configuración, en el que los ingenieros de software elegir entre un formales (o matemáticos). notaciones formales de construcción y ods met

conjunto limitado de opciones predefinidas para crear un software formales están en la base semántica de la mayoría de las formas de

nuevo o personalizado
3-6 Guía SWEBOK® V3.0

notaciones de programación del sistema, donde la precisión, 3.4. Prueba de la construcción


comportamiento en el tiempo, y la capacidad de prueba son más [1 *]
importantes que la facilidad de mapeo en lenguaje natural. construcciones

mal para- también utilizan formas definidas con precisión de la Construcción implica dos formas de pruebas, que a menudo son
combinación de símbolos que evitan la ambigüedad de muchas realizadas por el Neer niería de software que escribió el código:
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 • Examen
unidad de la

interpretación visual directa y la colocación de las entidades visuales • Pruebas de integración.

que representan el software subyacente. Visual de la construcción


tiende a ser algo limitado por la dificultad de hacer declaraciones El propósito de las pruebas de la construcción es el de reducir la
“complejas” utilizando sólo el Organizar- ción de los iconos en una brecha entre el momento en que los fallos se insertan en el código y el
pantalla. Sin embargo, estos iconos pueden ser herramientas momento cuando se detectan los fallos, reduciendo así el coste
poderosas en los casos en que la tarea de programación principal es incurrido para solucionarlos. En algunos casos, los casos de prueba se
simplemente para construir y “ajustar” una interfaz visual de un escriben después del código ha sido escrito. En otros casos, los casos
programa, el comportamiento detallado de los cuales tiene una de prueba pueden crearse antes de código está escrito. pruebas de
definición subyacente. 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
3.3. Codificación sistema, las pruebas alfa, pruebas beta, pruebas de estrés, pruebas de
[1 *] configuración, las pruebas de usabilidad, u otros tipos más
especializados de la prueba. Dos estándares han sido publicados
Las siguientes consideraciones se aplican a la actividad de sobre el tema de las pruebas de la construcción: Norma IEEE
codificación construcción soft- ware: 829-1998, IEEE Estándar para la Documentación de software de
prueba,
• Las técnicas para crear el código fuente comprensible,
incluyendo las convenciones de nomenclatura y el diseño de
código fuente; y la norma IEEE 1008-1987, IEEE estándar para el software de
• El uso de clases, tipos enumerados, variables, constantes con pruebas unitarias.
nombre, y otras entidades similares; (Ver secciones 2.1.1., Unidad de Pruebas, y 2.1.2., Pruebas de
• El uso de estructuras de control; integración, en el KA de Pruebas de Software para el material de
• Manipulación de las condiciones-tanto de error anticipó y referencia más especializado.)
excepcional (entrada de datos erróneos, por ejemplo);
3.5. Construcción de Reutilización
• Prevención de las infracciones a nivel de código de seguridad [2 *]
(desbordamientos de búfer o límites índice de matriz, por ejemplo);

Construcción para su reutilización crea software que tiene el potencial para


• El uso de recursos a través de uso de mecanis- y disciplina de ser reutilizado en el futuro para el presente proyecto u otros proyectos que
exclusión meca- para acceder a recursos en serie reutilizables tienen una base amplia, la perspectiva multisistémica. Construcción nueva
(incluyendo hilos y cerraduras de base de datos); 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
• Organización del código fuente (en Estado-mentos, fragmentos de código reutilizables en bibliotecas o componentes bien
rutinas, clases, paquetes, u otras estructuras); estructuradas. Las tareas relacionadas con la construcción de software
para su reutilización durante la codificación y las pruebas son las
• documentación de código; siguientes:
• Código de sintonía,
Construcción de Software 3-7

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

Construcción con reutilización significa crear un nuevo software con la La técnica o técnicas específicas seleccionadas dependen de la
reutilización de activos de software existentes. El método más popular naturaleza del software que se con- structed, así como en el conjunto de
de reutilización es la reutilización de código de las bibliotecas habilidades de los ingenieros de software que realizan la construcción
proporcionadas por el len- guaje, la plataforma, las herramientas que activi- lazos. Los programadores deben conocer las buenas prácticas y
se utiliza, o un repositorio organizativa. Los apartes de estos, las comunes ejemplo vulnerabilidades-para, a partir de listas ampliamente
aplica- ciones desarrolladas ampliamente hoy hacen uso de muchas reconocidos acerca de las vulnerabilidades comunes. análisis estático
bibliotecas de código abierto. Reutilizados y off-the-shelf software a automatizado de código para las debilidades de seguridad está
menudo tienen la misma o mejor calidad requisitos como nuevo disponible para varios lenguajes de programación mon com- y se puede
desarrollo de software (por ejemplo, nivel de seguridad). utilizar en proyectos críticos para la seguridad.

Las tareas relacionadas con la construcción de software con la actividades de construcción de calidad diferenciada se ated de otras
reutilización durante la codificación y las pruebas son las siguientes: actividades de calidad por su enfoque. actividades de calidad de la
construcción se centran en código y artefactos que están estrechamente
• La selección de las unidades reutilizables, Data- bases, relacionados con código como el diseño, a diferencia de otros artefactos
procedimientos de prueba, o datos de prueba. que están conectados directamente al menos el código, como los
• La evaluación de código o prueba de reutilización. requisitos, diseños de alto nivel, y los planes detallados.
• 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 3.8. Integración
procedimientos de prueba o datos de prueba. [1 *]

3.7. construcción de Calidad Una actividad clave durante la construcción es el ción integración
[1 *] de rutinas construidos individualmente, clases, componentes y
subsistemas en un único sis- tema. Además, puede necesitar ser
Además de los fallos que resultan de los requisitos y de diseño, defectos integrado con otros sistemas de software o hardware de un sistema
introducidos durante la construcción pueden dar lugar a problemas de software en particular.
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 Las preocupaciones relacionadas con la integración de la construcción
fallos en otras zonas que permiten la anulación de esta funcionalidad y incluyen la planificación de la secuencia en la que se integrarán los
otras debilidades de seguridad o violaciónes. Existen numerosas componentes, la identificación de lo que se necesita utensilios de
técnicas para asegurar la cali- dad de código como se construye. Las hardware, creando un andamio para apoyar versiones provisionales del
técnicas primarios utilizados para la calidad de la construcción incluyen 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 4.2. Orientado a Objetos Problemas de tiempo de ejecución 
provisionales del software. [1 *]
Los programas pueden estar integrados por medio de cualquiera de los

gradual o el enfoque incremental. la integración por etapas, también lenguajes orientados a objetos soportan una serie de mecanismos de
llamada integración “big bang”, implica retrasar la integración de las partes ejecución que incluye el polimorfismo y la reflexión. Estos mecanismos
componentes de software hasta que todas las partes destinados a la de ejecución aumentan la flexibilidad y adaptabilidad de los programas
liberación de una versión se han completado. la integración incremental se orientados a objetos. El polimorfismo es la capacidad de un lenguaje
cree que ofrecen muchas ventajas sobre el tra- dicional por fases de para apoyar las operaciones generales con- sin saber hasta que el
integración, por ejemplo, la ubicación de error más fácil, un mejor tiempo de ejecución qué tipo de objetos concretos del software incluirá.
seguimiento de los avances, a principios de la entrega del producto, y la Debido a que el programa no conoce el tipo exacto de los objetos de
mejora de relaciones con los clientes. En la integración gradual, el ERS antemano, el comportamiento exacto está determinado en tiempo de
desarrollos escribir y probar un programa en pequeños trozos y luego se ejecución (unión llamada dinámica). La reflexión es la capacidad de un
combinan las piezas una a la vez. infraestructura de pruebas adicionales, programa para observar y modificar su propia estructura y el
tales como talones, los controladores y los objetos de imitación, por lo comportamiento en tiempo de ejecución. La reflexión permite la
general se necesita para permitir la integración incrementales. Con la inspección de las clases, interfaces, campos y métodos en tiempo de
construcción y la integración de una unidad a la vez (por ejemplo, una ejecución con- sin saber sus nombres en tiempo de compilación.
clase o compo- nente), el proceso de construcción pueden proporcionar También permite la instanciación en tiempo de ejecución de nuevos
información temprana a los desarrolladores y clientes. Otras ventajas de la objetos y invocación de métodos que usan nombres de clase y método
integración incrementales incluyen la ubicación más fácil error, la mejora con parámetros.
de progreso Monitor-ing, unidades probado más completamente, y así

sucesivamente.

4.3. Parametrización y Genéricos


[4 *]
4. Tecnologías de la Construcción
tipos parametrizados, también conocidos como genéricos (ADA, Eiffel)
4.1. Diseño y Uso de la API y plantillas (C ++), permiten la definición de un tipo o clase sin
[3 *] especificar todos los otros tipos que utiliza. Los tipos no especificados
se suministran como parámetros en el punto de uso. Tros eterized
Una interfaz de programación de aplicaciones (API) es el conjunto de tipos proporcionan una tercera vía (además de la herencia de clases y
firmas que se exportan y disponibles para los usuarios de una composición de objetos) para com- representar comportamientos de
biblioteca o un marco para escribir sus aplicaciones. Además de las software orientado a objetos.
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 4.4. Afirmaciones, Diseño por contrato, y la programación
lugar a un código legible, ser difícil de mal uso, fácil de extender, ser defensiva
completa, y mantener la compatibilidad con versiones anteriores. [1 *]
Como las API generalmente duran más que sus implementaciones
para una biblioteca o un marco ampliamente utilizado, se desea que Una afirmación es un predicado ejecutable que se coloca en un programa

la API sea sencillo y se mantiene estable para facilitar el desarrollo y de por lo general una rutina o macro- que permite controles de tiempo de

mantenimiento de las aplicaciones cliente. 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í

uso API implica los procesos de ING Seleccionar-, el aprendizaje, las sucesivamente. Las afirmaciones se obtiene generalmente en el código en

pruebas, la integración, y posiblemente se extiende API proporcionadas tiempo de desarrollo y posteriormente se compilan fuera del código para

por una biblioteca o trabajo marco (véase la sección 3.6, de la construcción que no se degradan el rendimiento.

con la reutilización).
Construcción de Software 3-9

Diseño de contrato es un enfoque de desarrollo en los que las o que contiene sus efectos si la recuperación no es posi- ble. Las
condiciones previas y condiciones posteriores se incluyen para cada estrategias de tolerancia a fallos más comunes incluyen copias de
rutina. Cuando se utilizan condiciones previas y condiciones seguridad y de reintentar, utilizando el código auxiliar, utilizando
posteriores, se dice que cada clase de rutina o para formar un algoritmos de votación, y la sustitución de un valor erróneo con un valor
contrato con el resto del programa. Por otra parte, un contrato falso que tendrá un efecto benigno.
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 4.6. ejecutable modelos 
de software. [5 *]

La programación defensiva medios para proteger a una rutina de ser ejecutable modelos abstraer los detalles de los lenguajes de
roto por las entradas no válidas. Las formas más comunes para manejar programación específicos y las decisiones sobre la organización del
las entradas no válidas incluyen la comprobación de los valores de todos software. Diferente de los modelos tradicionales de software, una
los parámetros de entrada y decidir cómo manejar las malas entradas. especificación construido en un lenguaje de modelado ejecutable
ciones aseveraciones son de uso frecuente en la programación defensiva como xUML (UML ejecutable) se puede implementar en varios
para comprobar los valores de entrada. 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
4.5. Control de errores, control de excepciones, y la tolerancia a destino y el entorno de software. Por lo tanto, la construcción de
fallos modelos ejecutables puede considerarse como una forma de
[1 *] construir software ejecutable. ejecutable modelos son una fundación
apoyando actividades de gestión de la arquitectura dirigida por
La forma en que se manejan los errores afecta la capacidad del software modelos (MDA) inicia- tiva del Object Management Group (OMG).
para satisfacer los requisitos relacionados con Ness correcta-, robustez, y Un modelo ejecutable es una forma de especificar completamente
otros atri- buye no funcionales. Las afirmaciones se utilizan a veces para un modelo independiente de la plataforma (PIM); un PIM es un
comprobar si hay errores. -Están mercancías también se utilizan otras modelo de una solución a un problema que no se basa en ningún
técnicas-tales de manejo de errores como devolver un valor neutro, tecnologías de implementación. A continuación, un modelo de
sustituyendo la siguiente pieza de datos válidos, registrando un mensaje plataforma específica (PSM), que es un modelo que contenga los
de advertencia, devolver un código de error, o el cierre de la soft-. detalles de la tación aplica-, puede ser producido por tejer el PIM y
la plataforma sobre la que se basa.

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 4.7. Las técnicas de construcción basadas en tablas de base estatal y


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 [1 *]
manejo de excepciones deben ser cuidadosamente diseñadas
seguimiento ing principios comunes como la inclusión en el mensaje de programación basado en el estado, o la programación basada en
de excepción toda la información que llevó a la excepción, evitando los autómatas, es una tecnología de programación utilizando máquinas de
bloques catch vacías, conociendo las excepciones al código de la estado finito para describir comportamientos del programa. Los gráficos
biblioteca lanza, tal vez la construcción de un reportero de excepción de transición de una máquina de estados se utilizan en todas las etapas
centralizada, y la normalización de la el uso del programa de de desa- rrollo de software (especificación, implementación, ging
excepciones. tolerancia a fallos es una colección de técnicas que debug-, y documentación). La idea principal es la construcción de
aumentan la fiabilidad del software mediante la detección de errores y, programas de ordenador de la misma manera se realiza la
a continuación se recupera de ellos si es posible 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 las variables definidas por el programador que pueblan el árbol. Después
compuesto llamado , Programación orientada a objetos basado en el de construir el árbol de análisis, el programa utiliza como entrada a los
estado. procesos computacionales.
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 4.10. Las primitivas de concurrencia
ejemplo, Si y caso). Se utiliza en las circunstancias apropiadas, [7 *]
claves basadas en tablas

es más simple que la lógica complicada y más fácil de modificar. Al Una primitiva de sincronización es una abstracción de programación
utilizar métodos basadas en tablas, el programador se centra en dos proporcionada por un lenguaje de programación o el sistema
cuestiones: qué tipo de información a almacenar en la tabla o tablas, operativo que facilita rencia concurrente y sincronización. Conocidos
y cómo efi- ciente información de acceso en la tabla. primitivas RENCIA concurrentes incluyen semáforos, monitores y
exclusiones mutuas.

4.8. Configuración de tiempo de ejecución y la Un semáforo es un tipo de datos variable o extracto protegida
internacionalización que proporciona un simple pero útil abstracción para controlar el
[1 *] 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
Para lograr una mayor flexibilidad, un programa a menudo se construye datos abstractos que presenta un conjunto de operaciones
para soportar el tiempo de unión finales de sus Ables variabilidad. definidas por el programador que se ejecutan con la exclusión
configuración de ejecución es una técnica que une los valores de mutua. Un monitor de con- tains la declaración de variables
variables y ajustes del programa cuando el programa se está compartidas y cedimientos o funciones pro que operan en esas
ejecutando, por lo general mediante la actualización y la lectura de los variables. El constructo del monitor asegura que sólo un proceso
archivos de configuración en un modo justo a tiempo. La a la vez es activo dentro del monitor. Un mutex (exclusión mutua)
internacionalización es la activi- dad técnica de la preparación de un es un sin- cronización primitiva que permite el acceso exclusivo a
programa, generalmente software interactivo, para soportar múltiples un recurso compartido por un solo proceso o hilo a la vez.
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 4.11. middleware
conjunto de caracteres se va a utilizar, qué tipo de cadenas se usan, [3 *] [6 *]
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 Middleware es una amplia clasificación de soft- ware que proporciona
procesamiento y la interfaz de usuario. 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
4.9. Gramática-Basado procesamiento de entrada [ dieciséis*] 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
procesamiento de entrada basado en la gramática implica el análisis de comunicación entre múltiples aplicaciones de soft- ware interacción
sintaxis, o análisis, de la corriente de token de entrada. Se trata de la orientada al servicio.
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


Construcción de Software 3-11

4.12. Métodos de construcción de software distribuido 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
[7 *] programa utilizando informa- ción recopilada como se ejecuta el
programa, con el objetivo de identificar posibles puntos calientes en el
Un sistema distribuido es una colección de siste- mas informáticos programa para ser mejorado.
físicamente separados, posiblemente heterogéneos que están
conectados en red para proporcionar a los usuarios el acceso a los Código de sintonía, lo que mejora el rendimiento a nivel de código, es
diversos recursos que mantiene el sistema. Construcción de la práctica de modificar el código correcto en formas que hacen que
software distribuido se distingue de software tradicional trucción funcione más eficientemente. Código de sintonía por lo general implica
ción por cuestiones tales como paralelismo, comu- nicación, y sólo cambios a pequeña escala que afectan a una sola clase, una sola
tolerancia a fallos. 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,
programación distribuida normalmente cae en una de varias INCLUYENDO las de sintonización expresiones lógicas, bucles,
categorías arquitectónicos básicos: cliente-servidor, arquitectura de 3 transformaciones de datos, expresiones, y rutinas. El uso de un lenguaje
capas, de n niveles de arquitectura, dis- objetos Tributado, de de bajo nivel es otra téc- nica común para la mejora de algunos puntos
acoplamiento suelto, o estrecho acoplamiento (véase la sección 14.3 de calientes en un programa.
los fundamentos Informática KA y la sección 3.2 de el programa de
diseño KA).
4.15. Normas de plataforma
4.13. La construcción de sistemas heterogéneos [ 6 *] [6 *] [7 *]

estándares de la plataforma permiten a los programadores a


sistemas heterogéneos consisten en una variedad de unidades de desarrollar aplicaciones portátiles que se pueden eje- cuta en
computación especializados de diferentes tipos, tales como entornos compatibles sin cambios. estándares de la plataforma
procesadores de señal digital (DSPs), controladores de por lo general implican un conjunto de servicios estándar y API
microorganismos, y los procesadores periféricos. Estas unidades que compa- implementaciones de plataforma ible deben
de cómputo se controlan independientemente y se comunican implementar. Ejemplos típicos de estándares de la plataforma son
entre sí. Los sistemas embebidos son típicamente sistemas Java 2 Platform Enterprise Edition (J2EE) y el estándar POSIX
heterogéneos. El diseño de sistemas heterogéneos puede requerir para sistemas operativos (Portable Operating System Interface),
la combinación de varios lenguajes de especificación para el que representa un conjunto de normas implementadas
diseño de diferentes partes del sistema, en otras palabras, principalmente para sistemas operativos basados ​en UNIX.
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 4.16. Programación Test-First
descomposición gradual. La parte hardware generalmente se [1 *]
simula en el campo de las matrices de puertas programables
(FPGAs) o circui- tos integrados de aplicación específica (ASIC). Ensayos primera programación (también conocido como Test-Driven

La parte de software se traduce en un lenguaje de programación Development-TDD) es un estilo de desa- rrollo popular en la que los casos

de bajo nivel. 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

4.14. Análisis de Rendimiento y ajuste la codificación, exponiendo así a los requerimientos y problemas de diseño

[1 *] más pronto.

eficiencia-determinado código en la arquitectura, las decisiones de


diseño detallado, y la estructura de datos y
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 ejecutar. Es por esto que, en la práctica, un conjunto completo de


pruebas puede considerarse generalmente infi- nita, y la prueba
API Application Program Interface TDD
se lleva a cabo en un subconjunto de todas las pruebas posibles,
Test-Driven Development TTCN3 pruebas y de que está determinada por criterios de riesgo y priorización. Las

control de pruebas de notación pruebas siempre implica un equilibrio entre los recursos y los

La versión 3 horarios, por un lado limitados y los requisitos de prueba


inherentemente ilimitadas, por el otro.
XP Programación extrema

• Seleccionado: Las muchas técnicas de prueba propuestos


INTRODUCCIÓN difieren esencialmente en cómo se selecciona el equipo de
prueba, y los ingenieros de software deben ser conscientes de
Las pruebas de software consiste en la dinámica verifica- ción que ofrece que los diferentes criterios de selección pueden producir muy
un programa de esperado comportamientos en una finito un conjunto de diferentes grados de efectividad. Cómo identificar el criterio de
casos de prueba, adecuadamente seleccionado Del dominio de ejecución selección más adecuado bajo condiciones dadas es un
generalmente infinita. En la definición anterior, palabras en cursiva uso problema complejo; en la práctica, se aplican técnicas de
corresponden a cuestiones clave en la descripción del área de análisis de riesgos y la ingeniería de software tise exper-.
conocimiento de Pruebas de Software (KA):

• Esperado: Debe ser posible, aunque no siempre es fácil, para


• Dinámica: Este término significa que las pruebas siempre implica decidir si los resultados observados de las pruebas del
la ejecución del programa en las entradas seleccionadas. Para programa son aceptables o no; de lo contrario, el esfuerzo de
ser precisos, el valor de entrada por sí sola no siempre es prueba se uso- menos. El comportamiento observado puede
suficiente para SPEC- ify una prueba, ya que un sistema ser contrastada con las necesidades del usuario
complejo, no determinista podría reaccionar a la misma entrada (comúnmente conocidas como pruebas de validación), contra
con comportamientos diferentes, dependiendo del estado del un ficación speci- (prueba para la verificación), o, haps per-,
sistema. En este KA, sin embargo, el término “entrada” se contra el comportamiento esperado de los requisitos implícitos
mantendrá, con la conven- ción implícita que su significado o expectativas (ver pruebas de aceptación en el software de
también incluye un estado de entrada fied speci- en aquellos los requisitos KA).
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 En los últimos años, la vista de las pruebas de software ha
diferentes co- munidades y algunos utilizan el término “prueba” madurado hasta convertirse en una constructiva. Testing ya no se ve
también en referencia a las técnicas estáticas. 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
• Finito: Incluso en los programas simples, por lo que muchos casos planificación de las pruebas de software debe comenzar con las
de prueba son teóricamente posible que las pruebas tivo tamiento primeras etapas del proceso de requisitos de software,
podría requerir meses o años

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

técnicas dinámicas (la ejecución de código). Tanto catego- rías 1. Fundamentos de Software Testing
son útiles. Esta KA se centra en técnicas dinámicas.
1.1. Terminología de pruebas relacionados
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 1.1.1. Definiciones de Pruebas y terminología


Software). En particular, la unidad y pruebas de integración están relacionada 
íntimamente relacionados con la construcción de software, si no es parte [1 *, c1, c2] [2 *, c8]
de ella.

Definiciones de pruebas y terminología relacionados con las pruebas


DISTRIBUCIÓN DE TEMAS PARA LAS se proporcionan en las referencias citadas y se resumen como sigue.
PRUEBAS DE SOFTWARE

El desglose de temas para el Software de Exámenes KA se 1.1.2. Las fallas fallas vs. 
muestra en la Figura 4.1. Un desglose más detallado se [1 *, c1s5] [2 *, c11]
proporciona en la Matriz de Temas vs. Material de referencia al
final de este KA. El primer tema se describe damentals Software Muchos términos se utilizan en la literatura de ingeniería de
Testing FUn-. Cubre las definiciones básicas en el campo de software para describir un mal funcionamiento: en particular, avería,
pruebas de software, la terminología básica y las cuestiones clave, fallo, y error, entre otros. Este gía terminología se define
y el buque PARENTESCO de pruebas de software con otras precisamente en [3, c2]. Es esencial distinguir claramente entre el porque
actividades. de un mal funcionamiento (para el que se utilizará el fallo término
aquí) y un efecto no deseado observado en servicio entregado del
El segundo tema, los niveles de prueba, se compone de dos sis- tema (que será llamado un fracaso). En efecto bien puede
subtemas (ortogonales): la primera subtema se enumeran los niveles haber fallos en el software que nunca se manifiestan como
en los que la prueba de software grande se subdivide fracasos (ver limitaciones teóricas y prácticas de pruebas en la
tradicionalmente, y el segundo subtema considera la prueba para las sección 1.2, Temas clave). Por lo tanto ing Test- puede revelar
condiciones específicas o propie- dades y se conoce como objetivos fallos, pero es los defectos que pueden y deben ser removidos
de la prueba. No todos los tipos de pruebas se aplican a todos los [3]. El término más genérico
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 fracaso, cuando la distinción no es importante [3]. Sin embargo, se
a su composición- que los casos de prueba deben seleccionarse para debe reconocer que la causa de un fallo no siempre puede ser
lograr el objetivo declarado 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
(Aunque por lo general “para lograr el obje- tivo declarado” queda modificado para eliminar el fallo, pero otras modificaciones podría
implícita y sólo se plantea la primera parte de las dos preguntas haber funcionado igual de bien. Para evitar la ambigüedad, se
anteriores en cursiva). Criterios para hacer frente a la primera podría hacer referencia a
pregunta se denominan
adecuación de la prueba criterios, mientras que los relativos a la segunda entradas de fallo causante en lugar de los fallos, es decir, aquellos
pregunta son la prueba Criteria de selección. conjuntos de entradas que hacen que aparezca un fallo.

Varias técnicas de prueba se han desarrollado en las últimas


décadas, y todavía se están proponiendo nuevas. técnicas 1.2. Cuestiones clave
generalmente aceptadas están cubiertos en el tercer tema.
1.2.1. Criterios de selección de las pruebas / Criterios prueba de
Las medidas de prueba relacionados se tratan en el cuarto tema, adecuación (Reglas de parada) 
mientras que las cuestiones relativas a la prueba Pro- ceso están cubiertos [1 *, c1s14, c6s6, c12s7]
en el quinto. Finalmente, herramientas de prueba de software se presentan

en el tema seis. 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 en este sentido es el aforismo Dijkstra que “las pruebas pro- grama se
quacy ade- se pueden utilizar para decidir cuando la prueba sufi- puede utilizar para mostrar la presencia de insectos, pero nunca para
sufi- será, o se ha logrado [4] (ver terminación en la sección 5.1, mostrar su ausencia” [5]. La razón obvia de esto es que la prueba
las consideraciones prácticas). 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.2. Los tests de efectividad / Objetivos para las pruebas 

[1 *, c11s4, c13s11] 1.2.6. El problema de no factibles Caminos 


[1 *, c4s7]
Ensayos sobre la eficacia se determina mediante el análisis de un
conjunto de ejecuciones del programa. Selección de las pruebas que se caminos no factibles son trayectorias de flujo de control que no pueden ser

ejecutarán puede ser guiado por diferentes objetivos: es sólo a la luz del ejercidos por cualquier dato de entrada. Ellos son un problema no puede

objetivo perseguido que la eficacia del equipo de prueba se puede signifi- en pruebas basadas en el camino, sobre todo en la derivación

evaluar. automática de entradas de prueba para ejercer trayectorias de flujo de

control.

1.2.3. Las pruebas para detectar defectos Descubrimiento [ 1 *, c1s14]


1.2.7. la capacidad de prueba 
[1 *, c17s2]
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 El término “capacidad de prueba de software” tiene dos significados
pruebas para demostrar que el software cumple sus especificaciones o diferentes pero relacionados: por un lado, se refiere a la facilidad con la
otras propiedades deseadas, en los que las pruebas de caso tiene éxito que un criterio de cobertura de la prueba dada puede ser satisfecha;
si no se observan fallos en virtud de casos de prueba realistas y Por otro lado, se define como la probabilidad, posiblemente mide
entornos de prueba. estadísticamente, que un conjunto de casos de prueba expondrá un
fracaso Si el software es defectuoso. Ambos significados son
importantes.
1.2.4. El problema de Oracle 
[1 *, c1s9, c9s7]
1.3. Relación de las pruebas a otras actividades
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 Las pruebas de software se relaciona con, pero diferente de, estático técnicas
consecuencia resulta en un diccionario ver- de “pase” o Existen muchos de gestión de la calidad del software , Pruebas de corrección,
tipos dife- rentes de oráculos “fracaso”.; por ejemplo, las depuración y construcción de programas. Sin embargo, es informativa
especificaciones inequívocas requisitos, modelos de comportamiento, y para con- prueba Sider desde el punto de vista de los analistas de la
las anotaciones de código. La automatización de los oráculos calidad del software y de los certificadores.
mecanizadas puede ser difícil y costoso.

• Pruebas estáticas vs. Calidad de Software Hombre-


1.2.5. Limitaciones teóricas y prácticas de las Pruebas  Técnicas agement (Ver Técnicas de Gestión de la Calidad
de Software en la calidad del software KA [1 *, c12]).
[1 *, c2s7]
• Las pruebas de exactitud frente a pruebas y verificación
la teoría de las pruebas advierte contra atribuir un nivel cado formal (ver los modelos de ingeniería de software y
injustificado de confianza a una serie de pruebas con éxito. métodos KA [1 *, c17s2]).
Desafortunadamente, los resultados más establecidos de la teoría de • Prueba vs. Depuración (ver pruebas de la construcción
las pruebas son negativas, ya que afirman que la prueba nunca puede en la construcción del software KA y herramientas de
alcanzar a diferencia de lo que se consigue en realidad. La cita más depuración y técnicas en los cimientos Informática KA [1
famosa *, c3s6]).
Pruebas de Software 4-5

• Prueba vs. Programa de Construcción (ver pruebas de la hilos funcionales. Las pruebas de integración es a menudo una
construcción en la construcción del software KA [1 *, c3s2]). 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
2. Niveles de prueba inte- grando. Para que no sea el software pequeño, sencillo,
estrategias de pruebas de integración incrementales son el aliado
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 pruebas una vez que está a menudo llamado “big bang”.
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.3. Prueba del sistema 


[1 *, c8] [2 *, c8]
2.1. El objetivo de la prueba 
[1 *, c1s13] [2 *, c8s1] Las pruebas del sistema se ocupa de probar el comportamiento
de todo un sistema. unidad efectiva y pruebas de integración se
El objetivo de la prueba puede variar: un módulo individual, un grupo de han identificado muchos de los defectos de software. Las
tales módulos (relacionadas por finalidad, uso, comportamiento, o pruebas del sistema se considera generalmente adecuado para
estructura), o todo un sistema. Tres etapas de la prueba se pueden evaluar los requisitos del sistema, tales como no funcionales
distinguir: unidad, inte- gración, y el sistema. Estas tres etapas de seguri- dad, velocidad, precisión y fiabilidad (ver requisitos
prueba no implican ningún modelo de proceso, ni es uno cualquiera de funcionales y no funcionales en los requisitos de software y
ellos se supone que es más importante que los otros dos. 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.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 2.2. Objetivos de las Pruebas 
del contexto, estos podrían ser los subprogramas individuales o un [1 *, c1s7]
componente más grande hecha de unidades altamente cohesivos.

Típicamente, la unidad de pruebas se produce con acceso al código La prueba se llevó a cabo a la vista de objeti- vos específicos, que
siendo probado y con el apoyo de herramientas de depuración. Los se indican más o menos explícitamente y con diferentes grados
programadores que escribieron el código típicamente, pero no siempre, las de precisión. La indicación de los objetivos de la prueba en
pruebas unitarias conducta. términos precisos, cuantitativos apoya la medición y el control del
proceso de prueba.

2.1.2. Pruebas de integración  La prueba puede ser dirigido a la verificación de diferentes pro-
[1 *, c7] [2 *, c8] piedades. Los casos de prueba pueden ser diseñados para comprobar
que las especificaciones funcionales son correctamente mentado
Las pruebas de integración es el proceso de verificar las interacciones Implementers, que se refiere vario en el eratura lit- como las pruebas
entre los componentes de software. estrategias de pruebas de integración de conformidad, las pruebas de corrección, o pruebas funcionales. Sin
Sical cla-, como el de arriba hacia abajo y de abajo hacia arriba, se utilizan embargo, varias otras propiedades no funcionales pueden ser probados
a menudo con el software quía chically estructurado. como bien incluyendo el rendimiento, la fiabilidad y dad usabil-, entre
muchos otros (ver modelos y características de calidad de la calidad del
, estrategias de integración sistemáticas modernas son software KA). Otros objetivos importantes para las pruebas incluyen
típicamente arquitectura dirigida, que consiste en integrar pero no se limitan a la seguridad de medición,
progresivamente los componentes o subsistemas de software
basado en com- identificado
4-6 Guía SWEBOK® V3.0

identificación de las vulnerabilidades de seguridad, evaluación de la 2.2.4. Logro fiabilidad y Evaluación 


usabilidad y la aceptación de software, por lo que sería tomado diferentes [1 *, c15] [2 *, c15s2]
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 Las pruebas mejora la fiabilidad mediante la identificación y corrección
diferentes niveles de pruebas. de fallos. Además, las medidas estadísticas de fiabilidad se pueden
derivar por casos de prueba ing generat- aleatoria de acuerdo con el
Los subtemas que figuran a continuación son los más frecuentemente perfil de funcionamiento del software (ver perfil operativo en la sección
citado en la literatura. Tenga en cuenta que algunos tipos de pruebas son 3.5, Técnicas de uso-base). Este último enfoque se denomina las
más apropiados para las pruebas de software paquetes de instalación a pruebas de funcionamiento. Usando modelos de crecimiento fiabilidad,
medida, para ambos objetivos pueden perseguirse juntos [3] (ver L Prueba ife,
ejemplo- y otros productos de consumo, como el beta pruebas. Evaluación de confiabilidad en el apartado

4.1, Evaluación del Programa bajo prueba).


2.2.1. La prueba de aceptación / Calificación 
[1 *, c1s7] [2 *, c8s4] 2.2.5. Pruebas de regresión 
[1 *, c8s11, c13s3]
Las pruebas de aceptación / calificación determina si un sistema
cumple con sus criterios de aceptación, por lo general mediante la De acuerdo con [7], pruebas de regresión es la “repetición de pruebas
comprobación de los comportamientos deseados del sistema contra tiva selec- de un sistema o componente para verificar que las
los requerimientos del cliente. El cliente o representativos fies por lo modificaciones no han causado efectos no deseados y que el sistema o
tanto speci- de un cliente o directamente realiza actividades para componente sigue cumpliendo con sus requisitos especificados.” En la
comprobar que se han cumplido sus requisitos, o en el caso de un práctica, el enfoque es demostrar que las pruebas de software sigue
producto de consumo, que la organización ha cumplido con los pasando pasado previamente en un conjunto de pruebas (de hecho,
requisitos establecidos para el mercado de Tar conseguir. Esta también se refiere a las pruebas de progresión como nonre- veces). Para
actividad pruebas pueden o no implicar los desarrolladores del el desarrollo incremental, el propósito de las pruebas de regresión es
sistema. 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
2.2.2. Prueba de la instalación  garantía dada por regresión probando cada vez que se realiza un cambio
[1 *, c12s2] 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
A menudo, después de la finalización del sistema y pruebas de pueden ser ejecutados. Las pruebas de regresión consiste en
aceptación, el software se verifica después de la instalación en el entorno seleccionar, minimizar y / o dar prioridad a un subconjunto de los casos
de destino. las pruebas de instalación se puede ver como las pruebas del de prueba en un conjunto de pruebas exis- tentes [8]. Las pruebas de
sistema llevado a cabo en el entorno operativo de configuraciones de regresión puede ser con- conductos en cada uno de los niveles de
hardware ciones y otras limitaciones operacionales. procedimientos de ensayo descritos en sec- ción 2.1, el objetivo de la prueba, y pueden
instala- ción también pueden ser verificados. aplicarse a las pruebas funcionales y no funcionales.

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 2.2.6. Pruebas de rendimiento 


grupo de usuarios potenciales para su uso ensayo ( alfa pruebas) y / o [1 *, c8s6]
a un conjunto mayor de usuarios representativos ( beta pruebas).
Estos usuarios reportan problemas con el producto. Alfa y beta testing Las pruebas de rendimiento verifica que el software cumple con los
a menudo no están controlados y no siempre se hace referencia en requisitos de funcionamiento específicos y evalúa características
un plan de pruebas. de rendimiento-por ejemplo, la capacidad y el tiempo de respuesta.
Pruebas de Software 4-7

2.2.7. Pruebas de seguridad  2.2.12. Prueba de configuración 


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

Las pruebas de seguridad se centra en la verificación de que el software En los casos donde el software se construye para servir a diferentes

está protegido de ataques externos. En particular, las pruebas de usuarios, pruebas de configuración verifica el software bajo diferentes

seguridad verifica la confidenciales cialidad, integridad y disponibilidad configuraciones especificadas.

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 2.2.13. Usabilidad e inter-Ordenador prueba de la
sistema (pruebas negativas) blandas. acción 
[10 *, c6]

2.2.8. Pruebas de estrés  La tarea principal de la usabilidad y las pruebas interacción

[1 *, c8s8] 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

Las pruebas de estrés ejerce de software en la carga máxima de diseño, software fun- ciones que soporta las tareas del usuario, la documentación

así como más allá de ella, con el objetivo de determinar los límites de que ayuda a los usuarios, y la capacidad del sistema para recuperarse de

comportamiento, y para poner a prueba los mecanismos de defensa en los errores del usuario (ver diseño de la interfaz de usuario en el software

sistemas críticos. de diseño de KA).

2.2.9. Back-to-Back Testing 


[7] 3. Técnicas de Prueba

IEEE / ISO / IEC Standard 24765 define las pruebas de espalda de Uno de los objetivos de la prueba es detectar la mayor cantidad
Regreso a como “prueba en el que dos o más variantes de un posible de fallos. Muchas técnicas se han desarrollado para hacer
programa se ejecutan con las mismas entradas, las salidas se esto [6, parte 4]. Estas técnicas intentan “romper” un programa por ser
comparan, y los errores se analizan en caso de discrepancias.” 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
2.2.10. Prueba de recuperación  de entrada, los escenarios, los estados, y los flujos de datos. La
[1 *, c14s2] 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
las pruebas de recuperación está dirigido a comprobar la capacidad de software y expe- riencia, las especificaciones, la estructura del código,
reinicio de software después de un fallo del sistema o de otro tipo las faltas reales o imaginarios a ser descubiertos, el uso previsto,
“desastre”. 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.
2.2.11. Prueba de interfaz 
[2 *, c8s1.3] [9 *, c4s4.5]

defectos de interfaz son comunes en siste- mas complejas. pruebas de A veces, estas técnicas se clasifican como
la interfaz tiene como objetivo verificar si la interfaz componentes caja blanca ( también llamado caja de vidrio), Si las pruebas se basan en
correctamente para proporcionar el intercambio correcto de datos y la información sobre la forma en que el software ha sido diseñado o
control de informa- ción. Por lo general, los casos de prueba se codificado, o como recuadro negro si los casos de prueba se basan
generan a partir de la especificación de interfaz. Un objetivo específico únicamente en el comportamiento de la entrada / salida del software. La
de pruebas de la interfaz es para simular el uso de las API de siguiente lista incluye las técnicas de prueba que se utilizan normalmente,
aplicaciones de usuario final. Esto implica la genera- ción de los pero algunos médicos se basan en algunas de las técnicas más que
parámetros de las llamadas a la API, el ajuste de las condiciones del otros.
entorno externo, y a la definición de los datos interna que afecta a la
API.
4-8 Guía SWEBOK® V3.0

3.1. Sobre la base de la intuición y la experiencia del ingeniero de en lugar de considerar todas las combinaciones posibles. pruebas
software  Pairwise pertenece a combinatoria pruebas, que en general
también incluye combinaciones de más alto nivel que los pares:
3.1.1. Ad hoc estas técnicas se denominan t-sabia, por lo que cada combinación
posible de t variables de entrada se considera.
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. 3.2.3. Análisis de valores en la frontera 
pruebas Ad hoc puede ser útil para identificar las pruebas casos [1 *, c9s5]
que no generan fácilmente por técnicas más formales.
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
3.1.2. Prueba exploratoria 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
pruebas exploratorias se define como aprendizaje simultáneo, diseño prueba se eligen también fuera del dominio de entrada de variables a
de la prueba, y ejecución de la prueba [6, parte 1]; es decir, las robustez programa de prueba en el procesamiento de entradas
pruebas no se definen por adelantado en un plan de pruebas inesperadas o erróneos.
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 3.2.4. Pruebas al azar 
varias fuentes: el comportamiento del producto observada durante la [1 *, c9s7]
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 Las pruebas se generan puramente al azar (que no debe confundirse con

producto en particular, y así sucesivamente. 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

3.2. Las técnicas basadas en el dominio de entrada azar dentro de ella. Las pruebas al azar proporciona un enfoque

relativamente simple para la automatización de pruebas; recientemente, se

3.2.1. Partición de equivalencia  han propuesto formas mejoradas de pruebas al azar en los que pling la

[1 *, c9s4] 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

partición de equivalencia implica la partición del dominio de entrada en forma especial de pruebas al azar dirigida a romper el software; Con mayor

una colección de subconjuntos (o clases Alent valente) en base a un frecuencia se utiliza para las pruebas de seguridad.

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, 3.3. Técnicas de código-base
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 3.3.1. Criterios basados ​en el flujo de control 
conjunto representativo de pruebas (a veces sólo uno) es aliado no [1 *, c4]
baja tomada de cada clase de equivalencia.
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
3.2.2. Las pruebas por parejas  criterios basados ​Flow Control es la prueba de ruta, cuyo objetivo es
[1 *, c9s3] 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
Los casos de prueba se derivan mediante la combinación de valores exhaustiva por lo general no es factible debido a
interesantes para cada par de un conjunto de variables de entrada
Pruebas de Software 4-9

bucles, otros criterios menos estrictos se centran en la cobertura de 3.4.1. error de adivinanzas 
los caminos que limitan iteraciones del bucle, tales como la cobertura [1 *, c9s8]
de sentencias, cobertura de sucursales, y las pruebas DICIÓN / con-
decisión. La adecuación de estas pruebas se mide en porcentajes; por En adivinar de error, los casos de prueba están diseñados
ejemplo, cuando todas las ramas se han ejecutado al menos una vez específicamente por los ingenieros de software que intentan anticipan las
por los ensayos, se ha logrado 100% de cobertura de rama. 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.3.2. Criterios basados ​en el flujo de datos 


[1 *, c5] 3.4.2. Las pruebas de mutación 
[1 *, c3s5]
En las pruebas basadas en el flujo de datos, el gráfico de flujo de
control está anotado con información acerca de cómo se definen las Un mutante es una versión ligeramente modificada del programa bajo
variables del programa, utilizados, y mataron (indefinido). El criterio prueba, que difiere de ella por un pequeño cambio sintáctico. Cada
más fuerte, todos los caminos definición de uso, requiere que, para caso de prueba ejerce tanto el programa original y todos los mutantes
cada variable, se ejecuta cada segmento de trayectoria de flujo de generados: si un caso de prueba tiene éxito en la identificación de la
control de una definición de esa variable a un uso de esa definición. dife- rencia entre el programa y un mutante, se dice que este último
Con el fin de reducir el número de caminos necesarios, se emplean sea concebido originalmente como una técnica para evaluar la prueba
estrategias más débiles tales como todo-definiciones y todos los usos. “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
3.3.3. Modelos de referencia de las pruebas basadas en el aleatoriamente hasta que suficientes mutantes han muerto, o pruebas
Código están diseñadas específicamente para matar mutantes supervivientes.
[1 *, c4] 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
Aunque no es una técnica en sí misma, la estructura de control de subyacente de pruebas de mutación, el efecto de acoplamiento, es que
un programa puede ser gráficamente repre- sentadas usando un mediante la búsqueda de fallos sintácticos simples, se encontraron
gráfico de flujo para visualizar técnicas de ensayo basadas código-. defectos más complejos pero reales. Para que la técnica sea eficaz, un
Un gráfico de flujo es un grafo dirigido, los nodos y arcos de los gran número de mutantes debe ser generado y ejecutado de forma
cuales corresponderse a elementos (ver gráficos y los árboles en los sistemática [12] automáticamente.
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.5. Técnicas de uso-Basado

3.5.1. Perfil operativa 


[1 *, c15s5]
3.4. Técnicas basada en la culpa 
[1 *, c1s14] En las pruebas para la evaluación de la fiabilidad (llamada también
pruebas de funcionamiento), el entorno de prueba repro- duce el
Con diferentes grados de formalización, técnicas de ensayo basadas entorno operativo de la soft- ware, o la perfil operativo, lo mas
culpa- diseñar casos de prueba específica- mente destinados a revelar cercano posible. El objetivo es inferir a partir de los resultados de
categorías de fallos probables o predefinidas. Para enfocar mejor la las pruebas observadas el futuro fiabilidad del software cuando
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. 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 (Más o menos, las salidas). Los casos de prueba se derivan
consecución de los objetivos de fiabilidad y ejercer uso sistemáticamente por considerar cada posible combinación de
relativo y importancia de las distintas funciones similares a condiciones y sus acciones resul- tantes correspondientes. Una
lo que se encontró en el entorno operativo [3]. técnica relacionada es causa-efecto gráfica [ 1 *, c13s6].

3.5.2. La heurística de observación del usuario  3.6.2. Las máquinas de estados finitos 
[10 *, C5, C7] [1 *, c10]

principios de usabilidad pueden proporcionar directrices para los Al modelar un programa como una máquina de estados finitos, las pruebas

problemas de los descubrimientos confirma en el diseño de la cara del pueden ser seleccionados con el fin de cubrir los estados y transiciones.

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 3.6.3. Las especificaciones formales 
sistemática del uso del sistema bajo condiciones controladas con el fin de [1 *, c10s11] [2 *, c15]
deter- minar qué tan bien la gente puede utilizar el sistema y sus

interfaces. heurísticas de usabilidad incluyen recorridos cognitivos, análisis Indicando las especificaciones en un lenguaje formal (ver Métodos
de reclamaciones, observaciones de campo, pensando en voz alta, y los Formales en la ingeniería de software Modelos y Métodos KA)
enfoques incluso indirectos, tales como cuestionarios de usuario y permite la derivación automática de casos de prueba funcionales, y,
entrevistas. al mismo tiempo, proporciona un oráculo para comprobar los
resultados de pruebas.

3.6. Técnicas de ensayo basado en modelos 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

Un modelo en este contexto es una representación abstracta (formal) concebida para las necesidades específicas de los sistemas de prueba de

del software bajo prueba, o de sus requisitos de software (ver Modelado telecomunicaciones, por lo que es particularmente adecuado para probar

de los modelos de ingeniería de software y métodos KA). pruebas protocolos de comuni- cación complejos.

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 3.6.4. Modelos de flujo de trabajo 
pruebas basadas en modelo son [13]: la notación utilizada para [2 *, c8s3.2, c19s3.1]
representar el modelo del software o de sus requisitos; modelos de flujo
de obra o modelos similares; la estrategia de prueba o algoritmo modelos de flujo de trabajo especifican una secuencia de activi- lazos

utilizado para la generación de caso de prueba; la infraestructura de realizadas por los seres humanos y / o software aplica- ciones,

apoyo para la ejecución de la prueba; y la evaluación de los resultados generalmente representados a través de notaciones gráficas. Cada

de las pruebas en comparación con los resultados esperados. Debido a secuencia de acciones constituye un flujo de trabajo (también llamado un

la complejidad de las técnicas, los métodos de ensayo basados ​en escenario). Tanto cal normalmente, un y flujos de trabajo alternativos

modelos se utilizan a menudo en conjunción con los arneses ción de deben ser probados [6, parte 4]. Un enfoque especial en los papeles en

prueba automatización. técnicas de pruebas basadas en modelos una especificación de flujo de obra está dirigida en las pruebas de

incluyen los siguientes. procesos de negocio.

3.7. Las técnicas basadas en la naturaleza de la


aplicación
3.6.1. Las tablas de decisión 
[1 *, c9s6] 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
Las tablas de decisión representan las relaciones lógicas entre las basan en la naturaleza de la soft- ware siendo probado; por
condiciones (aproximadamente, insumos) y acciones ejemplo,
Software de Pruebas 4-11

• software orientado a objetos en cada punto de decisión. Para evitar este tipo de malentendidos,
• software basado en componentes una clara distinción debe hacerse entre las medidas relacionadas
• software basado en web con las pruebas que proporcionan una evaluación del programa que
• programas concurrentes se está probando, a partir de las salidas de prueba observadas y las
• software basado en el protocolo medidas que evalúan la minuciosidad de la prueba. (Véase la
• sistemas de tiempo real Ingeniería de Software de medición en la Gestión KA Ingeniería de
• sistemas de seguridad críticos Software para obtener información sobre los programas de
• software orientada a servicios medición. Ver Proceso de Software y Medición del producto en el
• software de código abierto Proceso de Ingeniería de Software KA para obtener información
• software embebido sobre las medidas).

3.8. La selección y la combinación de técnicas 


La medición se considera generalmente como funda- mental para el
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] la planificación y ejecución de las pruebas. Gestión de pruebas puede
utilizar varias medidas de diferencias ent proceso para monitorear el
Basado en modelos y técnicas de ensayo basadas en código son a progreso. (Véase la sección 5.1, las consideraciones prácticas, para una
menudo contrastan tan funcional frente a las pruebas estructurales. dis- cusión de las medidas del proceso de pruebas útiles para fines de
Estos dos enfoques para la selección de la prueba no deben ser vistos gestión).
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 4.1. Evaluación de la prueba el marco del Programa 
combinación, dependiendo de consideraciones presupuestarias.
4.1.1. Las mediciones de programas que ayudan en la
planificación y Análisis Diseñando 
[9 *, c11]
3.8.2. Determinista vs aleatoria 
[1 *, c9s6] 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 casos de prueba pueden seleccionarse de una manera los requisitos de software KA) o sobre la estructura del programa
determinista, de acuerdo con una de muchas técnicas, o puede ser utilizado para guiar las pruebas. Las medidas estructurales
aleatoriamente extraídas de alguna distribución de insumos, tal incluyen también medidas que determinan la frecuencia con la que
como se suele hacer en las pruebas de fiabilidad. comparaciones llaman módulos entre sí.
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.1.2. FALLO Tipos, clasificación y estadísticas 

4. Las medidas de prueba relacionados [9 *, c4]

A veces, las técnicas de prueba son confundidos con los objetivos de La literatura es rica en pruebas de clasificaciones y taxonomías
las pruebas. Técnicas de ensayo pueden ser vistos como auxiliares de faltas. Para hacer la prueba tivo más effec-, es importante
que ayudan a asegurar el logro de objetivos de la prueba [6, Parte 4]. saber qué tipos de fallos se pueden encontrar en el software bajo
Por ejemplo, la cobertura de la rama es una técnica de prueba prueba y la frecuencia relativa con la que se han producido estos
popular. El logro de una cobertura rama medida especificada (por fallos en el pasado. Esta información puede ser uso-ful para hacer
ejemplo, 95% de cobertura de sucursales) no debe ser el objetivo de predicciones de calidad, así como en la mejora de procesos
las pruebas per se: es una forma de improv- ing las posibilidades de (véase ción de defectos caracterización de la calidad del software
encontrar fallos por intentar ejercer sistemáticamente todas las ramas KA).
del programa
4-12 Guía SWEBOK® V3.0

4.1.3. Densidad de fallos 4.2.2. Siembra de fallos 


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

Un programa bajo prueba se puede evaluar por recuento fallos En la siembra de fallos, algunos fallos se intro- ducido artificialmente en
descubiertos como la relación entre el número de fallos encontrados y un programa antes de la prueba. Cuando se ejecutan las pruebas,
el tamaño del programa. algunos de estos fallos cabezas de serie se dará a conocer, así como,
posiblemente, algunos defectos que ya estaban allí. En teoría,
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] 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
Una estimación estadística de la fiabilidad del software, que estadísticos cuestionan la distribu- ción y la representatividad de los
puede ser obtenido mediante la observación de fiabilidad fallos sembradas en relación con los fallos genuinos y el tamaño
alcanzado, se puede utilizar para evaluar un producto de software pequeño de la muestra sobre la que se basan las extrapolaciones.
y decidir si o no la prueba puede ser detenido (ver sección 2.2, Algunos también argumentan que esta técnica se debe utilizar con
Logro Fiabilidad y evaluación). mucho cuidado ya que la inserción de fallos en el software implica el
riesgo evidente de dejarlos allí.

4.1.5. Los modelos de crecimiento fiabilidad 


[1 *, c15] [9 *, c8]
4.2.3. Puntuación mutación 
modelos de crecimiento Fiabilidad proporcionan una predicción de [1 *, c3s5]
fiabilidad basado en fracasos. Suponen, en gene- ral, que cuando las
fallas que causaron las fallas observadas se han fijado (aunque En las pruebas de mutación (ver pruebas de mutación en sec- ción
algunos modelos también aceptan correcciones imperfectas), 3.4, Técnicas basada en la culpa), la proporción de mutantes muertos
exposiciones de fiabilidad del pro- ducto estimado, en promedio, una al número total de mutantes generados puede ser una medida de la
tendencia creciente. Hay muchos modelos de crecimiento fiabilidad eficacia del equipo de prueba ejecutado.
publicados. En particular, estos modelos se dividen en

el fracaso de conteo y tiempo entre fallos modelos. 4.2.4. La comparación y la eficacia relativa de las
diferentes técnicas
4.2. La evaluación de las pruebas realizadas
Se han realizado varios estudios para com- parar la eficacia relativa
4.2.1. Medidas de cobertura / Minuciosidad  de las diferentes técnicas de prueba. Es importante ser preciso en
[9 *, c11] cuanto a la propiedad contra la cual se están evaluando las
técnicas; lo que, por ejemplo, es el significado exacto dado al
Varios criterios de adecuación de prueba requieren que los casos de término “eficacia”? Posibles interpretaciones incluyen el número de
prueba ejercen sistemáticamente un conjunto de elementos pruebas necesarias para encontrar el primer fracaso, la proporción
identificados en el programa o en las especificaciones (véase el tema entre el número de fallos que se encuentran a través de pruebas de
3, Técnicas de Prueba). Para evaluar la rigurosidad de las pruebas todos los defectos encontrados durante y después de la prueba, y la
ejecutadas, nieros de software niería pueden monitorear los elementos cantidad de fiabili- dad se ha mejorado. comparaciones analíticas y
cubiertos de manera que puedan medir dinámicamente la relación empíricas entre diferentes técnicas se han llevado a cabo de
entre los elementos cubiertos y el número total. Por ejem plos, es acuerdo con cada una de las nociones de eficacia especificados
posible medir el porcentaje de ramas cubiertas en el gráfico de flujo del anteriormente.
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. 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 5.2. Las actividades de prueba
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 Como se muestra en la siguiente descripción, manejo exitoso de
prueba falló, entre otros. las actividades de prueba depende en gran medida Cess la
gestión de configuración de software pro (véase el software de
Evaluación de los informes de las pruebas de fase puede ser configuración Manage- ment KA).
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. 5.2.1. Planificación 
Por otra parte, los recursos que merece la pena el gasto en las pruebas [1 *, c12s1, c12s8]
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 Al igual que todos los otros aspectos de la gestión de proyectos, se deben

diferentes niveles de confianza en la fiabilidad del producto. 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

5.1.8. Terminación  resultados no deseable. Si se mantiene más de una línea de base del

[9 *, c10s4] 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

Una decisión debe ser tomada en cuanto a cuánto ing Test- es prueba se establece en la configuración adecuada.

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 5.2.2. Ensayos caso de la generación [ 1 *, c12s1, c12s3]
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 Generación de casos de prueba se basa en el nivel de pruebas a
de selección Prueba / Criterios de prueba de adecuación en la sección realizar y las técnicas de ensayo particulares. Los casos de
1.2, Temas clave). prueba deben estar bajo el con- trol de gestión de configuración
de software e incluir los resultados esperados para cada prueba.

5.1.9. Prueba de reutilización y de prueba Patrones [ 9 *, c2s5] 5.2.3. Desarrollo Entorno de prueba 
[1 *, c12s6]

Para llevar a cabo pruebas o mantenimiento de una forma nizado y El entorno utilizado para la prueba debe ser com- patible con
rentable or-, los medios utilizados para probar cada parte del herramientas niería otro software adoptada niería. Se debe
software deben ser reutilizados de forma sistemática. Un repositorio facilitar el desarrollo y control de casos de prueba, así como el
de materiales de prueba debe estar bajo el control del software de registro y la recuperación de los resultados esperados, guiones y
gestión de con- figuración de modo que los cambios en los requisitos otros materiales de prueba.
de software de diseño o se pueden reflejar en cambios en las
pruebas realizadas.
5.2.4. Ejecución 
Las soluciones de ensayo adoptadas para probar algunos tipos de [1 *, c12s7]
aplicaciones, en determinadas circunstancias, con las motivaciones detrás

de las decisiones tomadas, forman un patrón de prueba que puede en sí La ejecución de los ensayos deberá incorporar un prin- cipio básico de
mismo ser documentados para su posterior reutilización en proyectos la experimentación científica: todo lo realizado durante la prueba debe
similares. 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 Minimización, selección y priorización: una encuesta,” Pruebas
práctica, Wiley-Spektrum, 2008. de verificación de software y fiabilidad, vol. 22, no. 2,
marzo 2012, pp. 67-120.
[2 *] I. Sommerville, Ingeniería de software, noveno
ed., Addison-Wesley, 2011.
[9 *] SH Kan, Métricas y modelos de software 
[3] MR Lyu, ed., Manual de Software  Ingeniería de calidad, 2ª ed., Addison-Wesley,
Ingeniería de Confiabilidad, McGraw-Hill y IEEE 2002.
Computer Society Press, 1996.
[10 *] J. Nielsen, Ingeniería de la Usabilidad, Morgan
[4] H. Zhu, PAV Hall y JHR mayo, Kaufmann, 1993.
“Unidad de Software Cobertura de la prueba y suficiencia” ACM
Computing Surveys, vol. [11] TY Chen et al, “Adaptive Pruebas al Azar.:
29, no. 4, diciembre de 1997 pp. 366-427. El arte de caso de prueba Diversidad” Diario de sistemas
y software, vol. 83, no. 1, enero
[5] EW Dijkstra, “Notas sobre Estructurado 2010, pp. 60-66.
Programación,”Informe TH-70-WSE-03, Universidad
Tecnológica de Eindhoven, 1970; [12] Y. Jia y M. Harman, “An Analysis
http://www.cs.utexas.edu/users/EWD/ ewd02xx / y la Encuesta de Desarrollo de pruebas de mutación” IEEE
EWD249.PDF . Trans. Ingeniería de software, vol. 37, no. 5, Sep.-Oct.
2011, pp. 649-678.
[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 / [13] M. Utting y B. Legeard, Práctico 
IEEE 2012. Basado en modelos de prueba: Un Enfoque de herramientas,
Morgan Kaufmann, 2007.
[7] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
CAPÍTULO 5

MANTENIMIENTO DEL SOFTWARE

SIGLAS durante la etapa de posparto. actividades antes de la entrega incluyen la


planificación para las operaciones de posparto, el mantenimiento, y la
SEÑOR Solicitud de modificación PR determinación de la logística para las actividades de transición [1 *,

Problema Informe del c6s9]. posparto actividades incluyen la modificación de software,


capacitación y operativo o interfaz con una mesa de ayuda. El área de
Configuración del software de
SMC conocimiento de mantenimiento de software (KA) se relaciona con todos
Gestión de SLA
los demás aspectos de la ingeniería de software. Por lo tanto, esta
Servicio de nivel Acuerdo SQA descripción KA está vinculado a todos los demás de ingeniería de
Software Quality Assurance V & V software de la KAs Guía.

Verificación y validación

INTRODUCCIÓN DISTRIBUCIÓN DE TEMAS PARA


MANTENIMIENTO DE SOFTWARE
los esfuerzos de desarrollo de software como resultado la ery deliv- de un

producto de software que satisfaga las necesidades del usuario. En El desglose de temas para el manteni- Software Principal- KA se
consecuencia, el producto de software debe cambiar o evolucionar. Una muestra en la Figura 5.1.
vez en funcionamiento, los defectos se descubren, cambian entornos

operativos, y los nuevos requisitos de los usuarios superficie. La fase de 1. Fundamentos de mantenimiento de software
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 Esta primera sección presenta los conceptos y terminología que forman
actividades de mantenimiento producirse mucho antes. 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.
El mantenimiento de software es una parte integral de un ciclo de Categorías de mantenimiento de software son fundamentales para la
vida del software. Sin embargo, no ha recibido el mismo grado de comprensión de su significado subyacente.
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 1.1. Definiciones y terminología
que las empresas se esfuerzan para exprimir el máximo rendimiento de [1 *, c3] [2 *, c1s2, C2S2]
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 El propósito del mantenimiento del software se define en el estándar
traído más aten- ción a la cuestión del mantenimiento de artefactos de internacional para el mantenimiento de software: ISO / IEC / IEEE
software desarrollados por otros. En esto Guía, mantenimiento del 14764 [1 *]. 1 En el contexto de la ingeniería de software,
software se define como el conjunto de actividades necesarias para mantenimiento de software es esencialmente uno de los muchos
proporcionar soporte rentable de software. Las actividades se llevan a procesos técnicos.
cabo durante la etapa de pre-entrega, así como

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-1
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 modificada, la prueba se lleva a cabo, y una nueva versión del
software existente, preservando su integridad. La norma producto de software es liberado. Además, forma- ción y apoyo diario
internacional también señala la importancia de tener algunas se proporcionan a los usuarios. El termino mantenedor se define como
actividades de mantenimiento antes de la entrega final de software una organización que lleva a cabo actividades de mantenimiento. En
(actividades previas a la entrega). En particular, IEEE 14764 hace este KA, el término se referirá en ocasiones a las personas que per-
hincapié en la importancia de los aspectos de mantenimiento formar esas actividades, lo que contrasta con los desarrolladores.
previo a la entrega de planificación, por ejemplo.

IEEE 14764 identifica las principales actividades de mantenimiento


1.2. Naturaleza de Mantenimiento de software como la implementación de procesos, análisis de
[2 *, c1s3] problemas y la modificación, la implementación de modificación,
revisión de mantenimiento / aceptación, la migración, y la jubilación.
mantenimiento de software sostiene UCT el software PRODUCIRSE lo Estas actividades se describen en la sección 3.2, las actividades de
largo de su ciclo de vida (desde el desarrollo de las operaciones). Las mantenimiento. Mantenedores pueden aprender a partir del
solicitudes de modificación se registran y se realiza un seguimiento, se conocimiento del software de la ERS desarrollos. El contacto con los
determina el impacto de los cambios propuestos, código de software y desarrolladores y la participación temprana de la
otros artefactos son
El software de mantenimiento 5-3

mantenedor ayuda a reducir el esfuerzo de mantenimiento percepción de mantenimiento del software es que se limita a fijar los
general. En algunos casos, el desarrollador inicial no puede ser fallos. Sin embargo, estudios y encuestas realizadas a lo largo de los
alcanzado o ha pasado a otras tareas, lo que crea un desafío años han indicado que la dad de División, más del 80 por ciento, del
adicional para man- recipientes. El mantenimiento debe tener mantenimiento del software se utiliza para acciones noncorrective [2 *,
artefactos de software de desarrollo (por ejemplo, código o docu- figura 4.1]. La agrupación de mejoras y correcciones juntos en los
mentación) y apoyarlos de inmediato, y luego evolucionar informes de gestión contribuye a algunos conceptos erróneos con
progresivamente / mantenerlas durante un ciclo de vida del respecto a los altos costos de correcciones. La comprensión de las
software. 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
1.3. La necesidad de mantenimiento  mantenimiento de software puede ayudar a contener los costos. Algunos
[2 *, c1s5] factores medioambientales y su relación con los costos de
mantenimiento de software incluyen los siguientes:
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 • Entorno de funcionamiento se refiere a hardware y
cambian debido a las acciones correctivas y de software noncorrective. software.
Mantenimiento debe ser realizado con el fin de • ambiente organizacional se refiere a cies POLI,
competencia, proceso, producto, y personal.

• corregir fallas;
• mejorar el diseño; 1.5. Evolución de Software 
• implementar mejoras; [2 *, c3s5]
• interactuar con otros softwares;
• adaptar los programas a fin de que distintos tipos de hardware, el El mantenimiento del software en términos de evolución se abordó por

software, las características del sistema y de las primera vez en la década de 1960. Durante un período de veinte años, la

telecomunicaciones instalaciones se pueden utilizar; investigación condujo a la formulación de ocho “leyes de la evolución.” Las

• migrar software heredado; y principales conclusiones son una propuesta que el mantenimiento es desa-

• retirarse de software. rrollo evolutivo y que las decisiones de mantenimiento son ayudados

mediante la comprensión de lo que ocurre con el software con el tiempo.

Cinco características clave incluyen las actividades de la er Algunos afirman que el mantenimiento se continúa el desarrollo, con la

maintain-: 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

• mantener el control sobre las funciones de día-a-día del evolucionando; a medida que evoluciona, crece más compleja si no se

software; toman algunas medidas para reducir esta complejidad.

• 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 1.6. Categorías de Mantenimiento 


vulnerabilidades de seguridad; y [1 *, c3, c6s2] [2 *, c3s3.1]
• la prevención de rendimiento del software de la degradación
a niveles inaceptables. Se han definido tres categorías (tipos) de mantenimiento:
correctivo, adaptativo y perfec- tivo [2 *, c4s3]. IEEE
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 • El mantenimiento correctivo: modifica- ción reactiva (o
en un ciclo de vida del software. Una común reparación) de un producto de software
5-4 Guía SWEBOK® V3.0

realizado después de la entrega para corregir problemas Ered próximo lanzamiento, mientras que el envío de parches de emergencia
descu-. Se incluyen en esta categoría es el mantenimiento de para la versión actual, también crea un desafío. En la siguiente sección
emergencia, que es una modificación no programada se realiza se presentan algunos de los problemas gías Nical y de gestión
para mantener temporariamente un producto de software en relacionados con el mantenimiento del software. Se han agrupado bajo
funcionamiento en espera de mantenimiento correctivo. los siguientes encabezados de los temas:

• mantenimiento adaptativo: modificación de un producto de


software se realiza después de la entrega para mantener un • problemas técnicos,
producto de software que puedan utilizarse en un entorno • asuntos Gerenciales,
cambiante o cambiar. Por ejemplo, el sistema operativo puede • estimación de costos, y
ser actualizado y algunos cambios en el software puede ser • medición.
necesario.
2.1. Problemas técnicos
• mantenimiento perfectivo: modificación de un producto de
software después de la entrega para proporcionar mejoras 2.1.1. La comprensión limitada 
para los usuarios, mejora de la documentación del programa, y [2 *, c6]
​la recodificación para mejorar el rendimiento del software,
capacidad maintain-, u otros atributos de software. 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
• El mantenimiento preventivo: modificación de un producto de software que él o ella no se desarrolló. Las investigaciones indican que
software después del parto para detectar fallas latentes y aproximadamente la mitad del total del esfuerzo de mantenimiento se
correctas en el producto de software antes de que sean fallos de dedica a pie Adjunto del software para ser modificado. Por lo tanto, el
funcionamiento. 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
IEEE 14764 clasifica mantenimiento adaptativo y perfectivo representación en orientada a texto, por ejemplo, donde a menudo es
como mejoras de mantenimiento. También agrupa a las difícil trazar la evolución del software a través de sus publicaciones /
categorías de mantenimiento tiva correctivas y prevención en una versiones si los cambios no están documentados y si los desarrolladores
corrección CAT- goría, como se muestra en la Tabla 5.1. 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.

Tabla 5.1. Mantenimiento de Software Categorías

Mejora de la corrección

Proactivo Preventivo perfectivo


2.1.2. Pruebas
Reactivo Correctivo Adaptado
[1 *, c6s2.2.2] [2 *, c9]

2. Temas clave en el mantenimiento de software 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
Una serie de cuestiones clave debe ser tratada para garantizar el garantizar que los informes de problemas solicitados son válidos, el
mantenimiento eficaz de software. mantenimiento de software ofrece mantenedor debe replicar o verificar los problemas mediante la ejecución
retos únicos cal y de gestión técnicamente para los ingenieros de de las pruebas adecuadas. Las pruebas de regresión (la repetición de
software-para ejemplo, tratando de encontrar un fallo en el software pruebas selec- tiva de software o un componente de ver- ify que las
que contiene un gran número de líneas de código que otro ingeniero modificaciones no han causado efectos unin- cuidados) es un concepto
de software desarrollados. Del mismo modo, compitiendo con los importante en las pruebas de mantenimiento. Además, encontrar tiempo
desarrolladores de software de recursos es una batalla constante. para probar es a menudo difícil. La coordinación de las pruebas cuando
La planificación de una versión futura, que a menudo incluye la diferentes miembros del equipo de mantenimiento están trabajando
codificación
El software de mantenimiento 5-5

sobre diferentes problemas al mismo tiempo sigue siendo un desafío. 2.1.4. mantenibilidad [ 1 *, c6s8] [2 *, c12s5.5]
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 IEEE 14 764 [1 *, c3s4] define mantenibilidad como la capacidad del
Prueba KA Software proporciona información y referencias adicionales producto de software para ser modificado. Las modificaciones
sobre este asunto en su subtema en las pruebas de regresión. 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,
2.1.3. Análisis de impacto [ 1 *, c5s2.5] [2 *, c13s3] 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
Análisis de impacto describe cómo llevar a cabo, de manera rentable, mantenibilidad es a menudo difícil de lograr debido a las
un análisis completo del impacto de un cambio en el software subcaracterísticas menudo no son un foco importante durante el
existente. Mantenedores deben poseer un conocimiento profundo de proceso de desarrollo de soft- ware. Los desarrolladores están, por
la estructura y el contenido del software. Ellos usan este conocimiento lo general, más preocupados con muchas otras actividades y con
para llevar a cabo análisis de impacto, que identifica a todos los frecuencia propensos a ignorar las exigencias del mantenedor. Esto
sistemas y productos de software afectadas por una solicitud de a su vez puede, ya menudo lo hace, dar lugar a una falta de
cambio de software y desarrolla una estimación de los recursos documentación de software y entornos de prueba, que es una de las
necesarios para llevar a cabo el cambio. Además, se determina el principales causas de los lazos dificultades en la comprensión del
riesgo de hacer el cambio. La solicitud de cambio, a veces se llama programa y análisis de impacto posterior. La presencia de procesos
una petición de modificación (MR) y, a menudo llamado un informe de sistemáticos y maduros, técnicas y herramientas de ayuda para
problemas (PR), primero debe ser analizado y traducido en términos mejorar la capacidad de mantenimiento de software.
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:

2.2. Asuntos Gerenciales

• analizar MRs / IPs; 2.2.1. La alineación con los objetivos


• replicar o verificar el problema; organizacionales 
• desarrollar opciones para la aplicación de la [2 *, c4]
modificación;
• documentar el MR / PR, los resultados y las opciones de objetivos de la organización describen cómo demostrar los retorno de la

ejecución; inversión de software de man- actividades tenance. desarrollo de software

• obtener la aprobación de la opción de modificación seleccionado. 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.

La gravedad de un problema a menudo se utiliza para decidir Por el contrario, el mantenimiento de software a menudo tiene el objetivo

cómo y cuándo va a ser fijo. El ingeniero de soft- ware a de extender la vida de software para el mayor tiempo posible. Además,

continuación, identifica los componen- tes afectados. Se puede ser impulsado por la necesidad de satisfacer la demanda del

proporcionan varias soluciones posibles, seguido de una usuario para las actualizaciones y mejoras del software. En ambos casos,

recomendación sobre el mejor curso de acción. 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

Software diseñado con capacidad de mantenimiento en mente facilita consume recursos significativos sin ningún beneficio cuantificable clara

en gran medida el análisis del impacto. más infor- mación se puede para la organización.

encontrar en el software de gestión de la configuración KA.


5-6 Guía SWEBOK® V3.0

2.2.2. dotación de personal asignación de la responsabilidad de mantenimiento a un solo grupo o


[2 *, c4s5, c10s4] persona, independientemente de la estructura de la organiza- ción.

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 2.2.5. La externalización


visto como un trabajo glamoroso. Como resultado, el personal de [3 *]
mantenimiento de software son frecuentemente vistos como “ciudadanos

de segunda clase”, y por lo tanto, la moral se resiente. 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
2.2.3. Proceso del software. Más a menudo, la opción de la externalización se selecciona
[1 *, c5] [2 *, c5] 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
El proceso del ciclo de vida del software es un conjunto de actividades, principal. Uno de los principales retos para los subcontratistas es
métodos, prácticas y transformaciones que PEO uso PLE para determinar el alcance de los servicios de mantenimiento requeridos, los
desarrollar y mantener el software y sus productos asociados. A nivel términos de un acuerdo de nivel de ser- vicio, y los detalles contractuales.
de proceso, las actividades de mantenimiento de software tienen Subcontratistas tendrán que invertir en una infraestructura de
mucho en común con el desarrollo de software (por ejemplo, gestión de mantenimiento y el servicio de asistencia en el sitio remoto debe contar
configuración de software es una actividad crucial en ambos). El con personal con hablantes de lengua nativa. La externalización requiere
mantenimiento también requiere varias actividades que no se una inver- sión inicial importante y la configuración de un proceso de
encuentran en desarrollo de software (ver sección 3.2 en actividades mantenimiento que requerirá la automatización.
ú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]
Los ingenieros de software deben entender las diferentes categorías de

Aspectos organizativos describen cómo iden- tificar qué mantenimiento de software, expuestos anteriormente, con el fin de abordar

organización y / o función será responsable del mantenimiento la cuestión de ing realizan estimaciones del costo de mantenimiento de

del software. El equipo que desarrolla el software no está software. Para fines de planificación, estimación de costos es un aspecto

necessar- ily asignado para mantener el software una vez que importante de la planificación para el mantenimiento del software.

esté en funcionamiento.

Al decidir dónde se ubicará la función de mantenimiento de software, 2.3.1. Estimación de costos


las organizaciones de ingeniería de software pueden ser, por ejemplo, [2 *, c7s2.4]
quedarse con el desarrollador original o ir a un equipo de mantenimiento
específico permanente (o personal de mantenimiento). Tener un equipo Sección 2.1.3 se describe cómo el análisis del impacto iden- tifica todos
de mantenimiento permanente tiene muchos beneficios: 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.
• permite la especialización;
• crea canales de comunicación; estimaciones de los costos de mantenimiento se ven afectados
• promueve una atmósfera sin ego, universitarios; por muchos factores técnicos y no técnicos. IEEE 14764 establece
• reduce la dependencia de los individuos; que “los dos métodos más populares a los recursos de estimación
• permite controles de auditoría periódicas. para el mantenimiento del software son el uso de modelos
paramétricos y el uso de la experiencia” [1 *, c7s4.1]. Una
Puesto que hay muchos pros y los contras de cada opción, la combinación de estos dos también se puede utilizar.
decisión debe hacerse sobre una base de caso por caso. Lo que es
importante es la delegación o
El software de mantenimiento 5-7

2.3.2. Los modelos paramétricos modelo de calidad sugiere medidas que son específicos para el
[2 *, c12s5.6] mantenimiento del software. Medidas para la carac- subchar- de
mantenimiento incluyen la si- guiente [4 *, p. 60]:
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 • Analizabilidad: medidas de esfuerzo o recursos utilizados en el
usar y calibrar los modelos matemáticos. atributos generador de intento, ya sea para diagnosticar deficiencias o causas de fallo
costos afectan las estimaciones. o para identificar las partes del mantenedor a ser modificados.

• Mutabilidad: medidas de esfuerzo del mantenedor asociados


2.3.3. Experiencia con la implementación de una modificación cado speci-.
[2 *, c12s5.5]
• Estabilidad: medidas del comporta- miento inesperado de
La experiencia, en forma de juicio de expertos, se utiliza a menudo para software, incluidos los que se encontró durante la prueba.
estimar el esfuerzo de mantenimiento. Claramente, el mejor enfoque para
el mantenimiento mación estimación es combinar los datos históricos y • La capacidad de prueba: medidas del mantenedor del esfuerzo y de

expe- riencia. El coste para llevar a cabo una modificación (en términos los usuarios en el intento de probar el software modificado.

de número de personas y la cantidad de tiempo) se deriva entonces.


datos históricos de estimación de mantenimiento deben ser • Otras medidas que utilizan los mantenedores incluyen
proporcionados como resultado de un programa de medición. • tamaño del software,
• complejidad del software,
• comprensibilidad, y
• facilidad
mantenimiento.
de

2.4. Medición de mantenimiento de software


[1 *, c6s5] [2 *, c12] Proporcionar esfuerzo de mantenimiento de software, por categorías,
para diferentes aplicaciones proporciona información de la empresa a los
Entidades relacionadas con el mantenimiento del software, usuarios y sus organiza- ciones. También puede permitir la comparación
cuyos atributos puede ser sometido a medición, incluyen de los perfiles de mantenimiento soft- ware internamente dentro de una
procesos, recursos, y el producto [2 *, c12s3.1]. organización.

Hay varias medidas de software que se pueden derivar de los


atributos del software, el proceso de mantenimiento y personal, 3. Proceso de Mantenimiento

tamaño ing INCLUYENDO, la complejidad, la calidad, la


comprensibilidad, mantenibilidad y esfuerzo. medidas de la Además de la ingeniería de software cesos pro estándar y las
complejidad del software también se pueden obtener utilizando actividades descritas en el estándar IEEE 14764, hay una serie de
herramientas comerciales disponibles. Estas medidas constituyen actividades que son exclusivas de los mantenedores.
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 3.1. Los procesos de mantenimiento
Software KA. El tema de un programa de medición de software se [1 *, c5] [2 *, c5] [5, S5.5]
describe en el Software Engineering Management KA.
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
2.4.1. Las medidas específicas muestran en la figura
[2 *, c12] 5.2. las actividades de mantenimiento de software incluyen

El mantenedor debe determinar qué medidas son adecuadas para • implementación de procesos,
una organización específica basada en el propio contexto de esa • problema y el análisis de la modificación,
organización. El software • 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,
El software de mantenimiento 5-9

y las auditorías. Otra actividad importante apoyo consiste en la • identificación de la organización de mantenimiento de
formación de los mantenedores y usuarios. software, y
• estimación de los costes de mantenimiento de software.

3.2.3. Actividades de mantenimiento Planificación


[1 *, c7s3] El siguiente paso es desarrollar un plan de mantenimiento de
software correspondiente. Este plan debe ser preparado durante el
Una actividad importante para el mantenimiento del software es la desarrollo de software y debe especificar cómo los usuarios solicitar
planificación, y mantenedores debe abordar las cuestiones relacionadas modifi- caciones de software o reportar problemas. la planificación del
con la planificación de una serie de perspectivas, incluyendo 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
• la planificación de negocios (nivel de la organización), actividades de planificación de negocios (y los recursos humanos,
• la planificación del mantenimiento (nivel de transición), presupuestarios financieros) al igual que todas las otras divisiones de
• planificación de entregas / versión (versión de software), y la organización. Gestión se discute en el capítulo relacionado
• planificación individual cambio de software petición (nivel de Disciplinas de Ingeniería de Software.
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 3.2.4. Gestión de la Configuración de Software
impacto). La actividad de planificación de entregas / versión requiere [1 *, c5s1.2.3] [2 *, c11]
que el mantenedor:
IEEE 14 764 describe la administración de configuración de software
• recoger las fechas de disponibilidad de las solicitudes individuales, como un elemento crítico del proceso de manteni- miento. Ment
procedimientos manage- de configuración de software deben
• de acuerdo con los usuarios sobre el contenido de versiones proporcionar para la verifica- ción, validación y auditoría de cada
posteriores / versiones, paso necesario para identificar, autorizar, implementar y liberar el
• identificar los conflictos potenciales y desarrollar producto de software.
alternativas,
• evaluar el riesgo de un comunicado dado y desarrollar un plan No es suficiente con realizar un seguimiento de las solicitudes de
de respaldo en caso de que surjan problemas, y modifi- cación o informe de problemas. El producto de software y los
cambios realizados a la misma deben ser Controlled. Este control se
• informar a todos los interesados. establece por ING implement- y aplicación de un proceso de
software de gestión aprobado configu- ración (SMC). La
Considerando que los proyectos de desarrollo de software Administración de KA del software de configuración proporciona
normalmente pueden durar desde algunos meses hasta unos pocos detalles de SMC y discute el proceso por el cual las solicitudes de
años, la fase de mantenimiento suele durar muchos años. Haciendo cambio soft- Ware presentado, evaluado y aprobado. SMC para el
estimaciones de los recursos es un elemento clave de la planificación del mantenimiento de software es diferente de SMC para el desarrollo
mantenimiento. Software de planificación de manteni- miento debe de software en el número de pequeños cambios que debe ser
comenzar con la decisión de desarrollar un nuevo producto de software y controlada con- el software operativo. El pro- ceso SMC se
deben considerar los objetivos de calidad. Un documento de reflexión implementa mediante el desarrollo y siguiendo los procedimientos
debe ser desarrollado, seguido de un plan de mantenimiento. El concepto del plan de gestión y operación de configuración de software.
de mantenimiento para cada producto de software debe ser documentado Mantenedores participan en las Juntas de Control de configuración
en el plan [1 *, c7s2] y debe hacer frente a la para determinar el contenido de la próxima versión / versión.

• ámbito del mantenimiento de software,


• la adaptación del proceso de mantenimiento de software,
5-10 Guía SWEBOK® V3.0

3.2.5. Calidad del software 4.3. Ingeniería inversa[ 1 *, c6s2] [2 *, c7, c14s5]
[1 *, c6s5, c6s7, c6s8] [2 *, c12s5.3]

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

4. Técnicas de Mantenimiento

Este tema se presentan algunas de las técnicas generalmente aceptados 4.4. Migración
utilizados en el mantenimiento del software. [1 *, c5s5]

4.1. programa de Comprensión Durante la vida de software, que puede tener que ser modificada
[2 *, c6, c14s5] convenientemente para funcionar en entornos diferentes. Con el fin de
migrar a un nuevo entorno, el responsable tiene que determinar las
Los programadores pasan considerable tiempo a la lectura y la acciones necesarias para la migración cumpla cabalmente, y luego
comprensión de los programas con el fin de implementar los cambios. desarrollar y docu- mento los pasos necesarios para llevar a cabo la
navegadores de código son herramientas clave para la comprensión del migración en un plan de migración que cubre la migración tos requisitos,
programa y se utilizan para organizar y código fuente ent PRESION. herramientas de migración, conversión de producto y datos, la ejecución,
documentación clara y concisa también puede ayudar en la comprensión la verificación, y el apoyo. Migración de software también puede implicar
del programa. una serie de actividades adicionales, tales como

4.2. reingeniería
[2 *, c7]
• notificación de la intención: una declaración de por qué
Reingeniería se define como el examen y la alteración de software para el antiguo entorno ya no ser Apoyado, seguida de una
reconstituir en una nueva forma, e incluye el ción ¡Ejecución posterior descripción del nuevo entorno y su fecha de
de la nueva forma. A menudo no se lleva a cabo para mejorar la disponibilidad es;
mantenibilidad, pero para reemplazar el envejecimiento de software • operaciones paralelas: poner a disposición los viejos y
ACY pierna-. Refactoring es una téc- nica reingeniería que pretende nuevos entornos de modo que el usuario experimenta
reorganizar un programa sin cambiar su comportamiento. Se trata de una transición suave al nuevo entorno;
mejorar una estructura pro- grama y su facilidad de mantenimiento. ING
técnicas Refactor- se pueden utilizar durante los cambios de menor • notificación de finalización: cuando se haya completado la
importancia. migración ULed sched-, se envía una notificación a todos los
interesados;
El software de mantenimiento 5-11

• opinión después de la operación: una evaluación de la • rebanadoras de programas, que seleccionan sólo partes de un

operación parale- y el impacto del cambio al nuevo programa afectado por un cambio;

entorno; • analizadores estáticos, que permiten ing vista- general y


• archivado de datos: almacenamiento de los datos del software de edad. resúmenes de un contenido del programa;
• analizadores dinámicos, que permiten al tainer man-
4.5. Jubilación  conocer la vía de ejecución de un programa;
[1 *, c5s6]
• analizadores de flujo de datos, que permiten al tainer man- realizar

Una vez que el software ha alcanzado el final de su vida ful uso-, el seguimiento de todos los posibles flujos de datos de un programa;

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 • cruzadas referencers, que generan los índices de los
plan de retiro, que cubre mentos de jubilación requisitos, el componentes del programa; y
impacto de reemplazo, calendario, y esfuerzo. Accesibilidad de • analizadores de dependencia, que ayudan a ERS maintain-
copias de archivo de datos también puede ser incluido. Retirarse analizar y comprender las interrelaciones entre los
de software conlleva una serie de actividades similares a la componentes de un programa.
migración.
Herramientas de ingeniería inversa ayudan al proceso trabajando
hacia atrás desde un producto existente para crear artefactos tales como
5. Herramientas de Mantenimiento de Software especificación y diseño descripciones, que a continuación se pueden
[1 *, c6s4] [2 *, c14] transformar para generar un nuevo producto de una antigua. Principal-
también utilizan recipientes de prueba de software, gestión de con-
Este tema abarca herramientas que son particularmente importantes en el figuración de software, documentación de software y herramientas de
mantenimiento de software donde se está modificando el software existen- medición de software.
ing. Ejemplos CON RESPECTO A comprensión del programa incluye
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 Referencias

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]. 14764: 2006) estándar para el software de ingeniería
en software de ciclo de vida Procesos de
mantenimiento, IEEE 2006.
Este libro explora el dominio de los procesos de mantenimiento de
software pequeños (S3M). Proporciona mapas ROAD- para mejorar [2 *] P. Grubb y AA Takang, Software 
cesos pro de mantenimiento de software en las organizaciones. En Mantenimiento: Conceptos y práctica, 2ª ed.,
él se describe un modelo de madurez específica mantenimiento de Editorial Científico Mundial, 2003.
software organizada por niveles que permiten la evaluación
comparativa y la mejora continuas con. Metas para cada área clave [3 *] HM Sneed “, software de Oferta
Tice prác- se proporcionan, y el modelo de proceso de pre-tantes Mantenimiento como un servicio Marino,” Proc. IEEE Conf
está totalmente alineado con la arquitectura y el marco de las Int'l. Mantenimiento del software
normas ISO12207 internacional ISO14764 y ISO15504 y modelos de (ICSM 08), IEEE, 2008, pp. 1-5.
madurez populares como ITIL, COBIT, CMMI y CM3.
[4 *] JW Moore, La hoja de ruta de software 
Ingeniería: Una guía basada en estándares,
Wiley-IEEE Computer Society Press, 2006.
M. Kajko-Mattsson, “Hacia un Modelo de Negocio de
Mantenimiento,” IEEE Int'l Conf. Mantenimiento [5] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Software [7]. Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
2010.
Este artículo presenta una visión general del modelo de madurez de
mantenimiento correctivas (cm3). A diferencia de otros modelos de [6] A. abril y A. Abran, Software 
procesos, CM3 es un modelo espe- cializada, dedicado Gestión de Mantenimiento: evaluación y mejora
exclusivamente al mantenimiento correctivo del software. Se continua, Wiley-IEEE Computer Society Press,
considera que el mantenimiento en términos de las actividades a 2008.
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 [7] M. Kajko-Mattsson, “Hacia un negocio
niveles de organización y roles involucrados en las distintas etapas Mantenimiento Modelo” Proc. Int'l Conf.
de un proceso típico de mantenimiento correctivo. Mantenimiento del software, IEEE, 2001, pp. 500-509.
CAPÍTULO 6

Software Configuration Management

SIGLAS 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
CCB Configuración de la tarjeta de control CM
configuración de un sistema en distintos puntos en el tiempo con el fin
Configuración de Gestión de la FCA de sistemáticamente control- ling cambios en la configuración y el

PCA Auditoría de Configuración Funcional mantenimiento de la integridad y la trazabilidad de la configuración de


todo el ciclo de vida del sistema. Se define formalmente como
Auditoría de Configuración física

Software de configuración de la tarjeta de control


SCCE
SCI
Una disciplina aplicando dirección adminis- tración y
Software SMC elemento de configuración
técnica y vigilancia a: tificar iden- y documentar las
Configuración del software de características funcionales y cal Physicians de un
elemento de configuración, los cambios de control a las
gestión PGCS
Plan de Gestión de la características, el procesamiento y la aplicación de registro

Configuración de Software SCR


y cambio de informe de estado, y verifican El cumplimiento
con los requisitos especificados. [1]
Solicitud de cambio de software SCSA

Software Estado de Configuración de

contabilidad SDD gestión de configuración de software (SCM) es un proceso de


El software de diseño de documentos SEI ciclo de vida del software de apoyo que beneficia a las actividades

/ CMMI Madurez de Capacidades del Software de gestión de proyectos, desarrollo y mantenimiento, actividades de

Engineering Institute Modelo de Integración SQA aseguramiento de la calidad, así como los clientes y usuarios del
producto final.

Software Quality Assurance SRS


Los conceptos de gestión de la configuración se aplican a todos los
Software de especificación de
artículos que deben ser controlados, aunque hay algunas diferencias en
requisitos
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
INTRODUCCIÓN 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
Un sistema puede ser definido como la combinación de elementos requerimientos especificados por la planificación, la promulgación, y la
organizados para lograr uno o más propósitos declarados [1] realización de un conjunto de actividades para proporcionar la confianza
interactuar. La configuración de un sistema es la carac- terísticas adecuada de que la calidad se está construyendo en el software.
funcionales y físicas de hardware o software que se exponen en actividades de SCM ayudan en el cumplimiento de estos objetivos SQA.
técnica- cal documentación o conseguidos en un producto [1]; También En algunos contextos pro- yecto, los requisitos específicos SQA
se puede considerar como una colección de versiones específicas de prescriben ciertas actividades de SCM.
hardware, firmware, software o elementos combinados de acuerdo a los
procedimientos específicos de construcción

6-1
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 el desarrollo y el cambio aplicación activi- lazos. Una
proceso de SMC, identificación de la configuración de software, el implementación exitosa de SMC requiere una planificación y
control de la configuración de software, la contabilidad de estado de una gestión cuidadosa. Esto, a su vez, requiere una
configuración de software, auditoría de configuración de software, y la comprensión del contexto de la organización para, y las
gestión de versión de software y la entrega. limitaciones impuestas a, el diseño y la implementación del
proceso de SMC.
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 1.1. Contexto de organización de SMC 
la configuración es el artefacto pro ducido y utilizado en todo el [2 *, c6, Ann. D] [3 *, la introducción] [4 *, c29]
software de inge- niería proceso.
Para planificar un proceso de SMC para un proyecto, es preciso
proceder a entender el contexto de la organización y las relaciones
DISTRIBUCIÓN DE TEMAS PARA LA entre los elementos de la organización. SMC interactúa con otras
GESTIÓN DE CONFIGURACIÓN DEL actividades o elementos de la organización.
SOFTWARE
Los elementos de la organización responsable de la ingeniería de
El desglose de los temas para el Config- Software de Gestión software procesos de apoyo pueden estructurarse de varias
URACIÓN KA se muestra en la Figura 6.1. maneras. Aunque la responsabili- dad para realizar ciertas tareas
SCM podría ser asignado a otras partes de la organización (por
1. Gestión del Proceso de SMC ejemplo, la organización de desarrollo), el responsa- bilidad global
para SCM menudo recae en un elemento zational orga- distinta o
SCM controla la evolución y la integridad de un producto mediante la persona designada. El software se desarrolló con frecuencia como
identificación de sus elementos; la gestión y el control del cambio; y parte de un sistema más grande que contiene los elementos de
verificar, grabación, y la información sobre la información de hardware y firmware. En este caso, las actividades se llevan a cabo
configuración. Desde la perspectiva del ingeniero de software, SCM SCM
facilita
Configuración del software 6-3 Gestión

en paralelo con hardware y firmware CM activi- dades y deben ingeniería emitido por las diversas normas orga- nizaciones
ser compatibles con el sistema de nivel (ver Apéndice B de las normas).
CM. Tenga en cuenta que el firmware contiene hardware y software;
Por lo tanto, ambos conceptos CM de hardware y software son 1.3. La planificación de SMC 
aplicables. [2 *, c6, Ann. D, Ann. E] [3 *, c23] [4 *, c29]
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 La planificación de un proceso de SMC para un proyecto dado debe ser
elementos no conformes. Respecto al primero, algunos artículos bajo coherente con el contexto organiza- zational, las restricciones
control SMC también pueden incluir datos sobre los proyectos sujetos a aplicables, comúnmente aceptado orientación com-, y la naturaleza del
las disposiciones del programa de garantía de calidad de la organización. proyecto (por ejemplo, el tamaño, la criticidad de seguridad, y la
La gestión de elementos no conformes es aliado no baja de la seguridad). Las principales actividades cubiertas son la identificación
responsabilidad de la actividad de aseguramiento de la calidad; Sin del software de configuración, control de configuración de software, la
embargo, SCM puede ayudar con pista- ing e informar sobre los contabilidad de estado de configuración de software, auditoría de
elementos de configuración de software que caen en esta categoría. 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
Tal vez la relación más estrecha es con el desarrollo de software y la aplicación, el control de proveedores y subcontratistas, y el control
mantenimiento or- nizaciones. Es dentro de este contexto que de la interfaz son típicamente sidered con-. Los resultados de la
muchas de las tareas de control de la configuración del software se actividad de planificación se registran en un Plan de SCM (SCMP), que
con- canalizado. Con frecuencia, las mismas herramientas soportan es Tıpicamente sujeto a SQA revisión y auditoría. Ramificación y las
desa- rrollo, el mantenimiento y los propósitos de SCM. 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
1.2. Limitaciones y orientación para el proceso SMC  de la evolución de versiones de archivo fuente [1]. La fusión consiste
en la combinación de diferentes cambios en el mismo archivo [1]. Este
[2 *, c6, Ann. D, Ann. E] [3 *, C2, C5] Tıpicamente se produce cuando más de una persona cambia de un
[5 *, c19s2.2] 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
Limitaciones que afectan, y una guía para el proceso de SMC discusión adicional). El modelo de ciclo de vida de desarrollo de
provenir de varias fuentes. normativas y procedimientos de exponen software (véase el ciclo de vida del software Modelos en el proceso de
a niveles de organización corporativos u otros podrían influir o ingeniería de software KA) también afecta SCM actividades, y la
prescribir el diseño y la implementación del pro- ceso SMC para un planificación SMC debe tener esto en cuenta. Por ejemplo, la
proyecto determinado. Además, el contrato entre el comprador y el integración continua es una práctica común en muchos enfoques desa-
proveedor podría con- disposiciones Tain que afectan el proceso de rrollo de software. Por lo general se caracteriza por ciclos de
SMC. Por ejemplo, podrían ser necesarias ciertas auditorías de acumulación de prueba de implementar frecuentes. SCM actividades
configuración, o puede ser especificado que ciertos artículos pueden deben planificarse en consecuencia.
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.
1.3.1. Organización y responsabilidades SMC
[2 *, Ann. DS5, Ann. DS6] [3 *, c10-11]
[4 *, introducción, c29]
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 Para evitar la confusión sobre quién llevará a cabo las actividades
las normas sobre el software 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 • Futuro: ¿cuál es el plan para el uso de las herramientas en el

claramente identificados. Las responsabilidades específicas para las futuro?

actividades o tareas SCM dados también tienen que ser asignados a • Cambiar: su capacidad de adaptación son las herramientas?
entidades de organización, ya sea por título o por el elemento de la • Ramas y la mezcla: son capaci- dades de dichas herramientas
organización. Los informes dad y canales globales de Autor-SMC compatibles con el ing rama-planificada y estrategias de la
también deben ser identificados, aunque esto puede ser logrado en la fusión?
etapa de planificación de la gestión de proyectos o la garantía de • Integración: hacer las diferentes herramientas de SCM inte-
calidad. rejilla entre sí? Con otras herramientas en uso en la
organización?
• Migración: el repositorio puede mantenida por la herramienta de
1.3.2. Recursos SCM y horarios control de versiones ser portado a otra herramienta de control de
[2 *, Ann. DS8] [3 *, c23] versiones, manteniendo la historia com- pleta de los elementos de
configuración que contiene?
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 SMC por lo general requiere un conjunto de herramientas, en lugar de

necesarias tareas de SCM y que identifique los valores de sus relaciones una sola herramienta. Tales conjuntos de herramientas son algunas veces

con los programas de los proyectos y los hitos establecidos en el proyecto referidos como bancos de trabajo. En un texto tan con-, otra consideración

de manage- ment etapa de planificación. También se especifican los importante en la Planificación para la selección de la herramienta es

requisitos de formación necesarios para la ejecución de los planes y la determinar si el banco de trabajo SMC será abierto ( en otras palabras, las

formación de los nuevos miembros del personal. herramientas de diferentes proveedores serán utilizados en diferentes

actividades del proceso SMC) o integrado

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] juntos).
El tamaño de la organización y el tipo de proyectos que participan
En cuanto a cualquier área de la ingeniería de software, la selección e también puede afectar a la selección de herramientas (ver tema 7,
implementación de herramientas de SCM deben ser cuidadosamente Configuración de Software Manage- Herramientas Ment).
planificadas. Los siguientes pre- guntas deben ser considerados:

1.3.4. Vendedor / Control de Subcontratista


• Organización: lo que motiva adquisi- ción de herramientas desde [2 *, c13] [3 *, c13s9, c14s2]
una perspectiva organizacional?
• Herramientas: podemos utilizar herramientas comerciales o a Un proyecto de software puede adquirir o hacer uso de los productos
desarrollar nosotros mismos? de software adquiridos, tales como compiladores y otras herramientas.
• Medio Ambiente: ¿cuáles son las limitaciones la planificación SMC considera si y cómo se tomarán estos elementos
impuestas por la organización y su téc- nico contexto? bajo control con- figuración (por ejemplo, integrado en las bibliotecas
pro- yecto) y cómo van a ser evaluados y gestionados cambios o
• Legado: cómo utilizarán los proyectos (o no) las nuevas actualizaciones.
herramientas?

• Financiación: ¿quién va a pagar por la adquisición, el mantenimiento Consideraciones similares se aplican al software subcontratado.
de las herramientas, entrenar y Al utilizar el software de subcontratación, tanto los requisitos de
personalización? SCM a ser impuestas sobre el proceso de SMC del subcontratista
• Alcance: cómo se deployed- las nuevas herramientas, por como parte del subcontrato y los medios para vigilar pliance com-
ejemplo, a través de toda la organización o sólo en proyectos necesitan ser establecidos. Este último incluye la consideración de
específicos? lo que debe estar disponible para la vigilancia del cumplimiento
• Propiedad: ¿quién es el responsable de la introducción de nuevas efectivo de información SMC.
herramientas?
Configuración del software 6-5 Gestión

1.3.5. control de interfaz • Horarios de SCM (coordinación con otras actividades del
[2 *, c12] [3 *, c24s4] proyecto)
• Recursos SCM (herramientas, recursos físicos y recursos
Cuando un elemento de software de interfaz con otro elemento de humanos)
software o hardware, un cambio a cualquiera de elemento puede • Mantenimiento SCMP.
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 1.5. La vigilancia de la Gestión de la Configuración de
y cambios en los elementos. El papel SCM puede ser parte de un Software 
proceso de sistema de nivel más grande para la especificación y [3 *, c11s3]
control de la interfaz; puede tratarse de especificaciones de interfaz,
planes de control de interfaz, y los documentos de control de Después del proceso de SMC se ha implementado, un cierto grado
interfaz. En este caso, la planificación de SMC para el control de la de vigilancia puede ser necesario para garantizar que las
interfaz tiene lugar dentro del contexto del proceso de nivel del disposiciones de la PGCS se realicen adecuadamente. No es
sistema. 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
1.4. Plan de SMC [ 2 *, Ann. D] [3 *, c23] [4 *, c29s1] 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.
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 El uso de herramientas de SCM integrados con capacidad de control
proceso de SMC. Se mantiene (es decir, actualizada y aprobada) de procesos puede hacer más fácil la tarea de vigilancia. Algunas
según sea necesario durante el ciclo de vida del software. En herramientas facilitan el proceso pliance com- mientras que proporciona
Menting imple- PGCS, normalmente es necesario desarrollar una flexibilidad para el ingeniero de soft- ware para adaptar los
serie de procedimientos más detallados, subordinados que define procedimientos. Otras herramientas de cumplir proceso, dejando el
cómo los requisitos específicos se llevará a cabo durante ingeniero de software con menos flexibilidad. requisitos de vigilancia y el
actividades- del día a día, por ejemplo, que se utilizarán estrategias nivel de flexibilidad para ser proporcionados al ingeniero de software son
de ramificación y con qué frecuencia se basa ocurrir y auto-pruebas consideraciones importantes en la selección de herramientas.
apareadas de todo tipo se ejecutan.

Orientación sobre la creación y mantenimiento de un PGCS, 1.5.1. Medidas de SCM y Medición


basado en la información producida por la actividad de planificación, [3 *, c9s2, c25s2-s3]
está disponible a partir de diversas fuentes, como por ejemplo [2 *].
Esta referencia proporciona requisitos para la información a ser SCM medidas pueden ser diseñados para proporcionar información
contenida en un SCMP; También define y describe seis catego- rías CIFIC espe- sobre el producto en evolución o para proporcionar
de información SMC que deben incluirse en un SCMP: 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
• Introducción (propósito, el alcance, los términos utilizados) seguimiento de la eficacia de las actividades de la SCM de manera
• Gestión de SMC (organización, responsabilidades, continua. Estas mediciones son útiles en characteriz- ing el estado
autoridades, las políticas aplicables, directivas y actual del proceso, así como en la provisión de una base para hacer
procedimientos) comparaciones en el tiempo. El análisis de las mediciones puede
• Actividades SCM (identificación de la configuración, control producir
de configuración, etc.)
6-6 Guía SWEBOK® V3.0

ideas que lleva a procesar los cambios y actualizaciones Esto implica la comprensión de la configuración del software en el contexto

correspondientes a la PGCS. de la configuración del sistema, la selección de los elementos de

Bibliotecas de software y las diversas posibilidades de configuración de software, desarrollo de una estrategia para los elementos

herramientas SCM proporcionan fuentes para extraer información de software de etiquetado y la descripción de sus relaciones, y la

acerca de las características del proceso de SMC (así como el identificación tanto de las líneas de base a ser utilizados y el procedimiento

suministro de información agement hombre-proyecto y). Por para la adquisición de una línea de base de los artículos.

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 2.1.1. Configuración del software
para la autorización de ciertos tipos de cambios y para la [1, c3]
estimación de cambios en el futuro. Se debe tener cuidado para
mantener el foco de la vigilancia en las ideas que se pueden Software configuración es las características de iCal funcionales y
obtener a partir de las mediciones, no en las propias mediciones. phys- de hardware o software como se establece en la
La discusión de los procesos de software y medición del producto documentación técnica o logrado en un producto. Puede ser visto
se presenta en el Proceso de Cesión de Software Ingeniería KA. como parte de una configuración general del sistema.
programas de software surement Measure se describen en el
Software Engineering Management KA.
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


1.5.2. En-Proceso de Auditorías de SMC de hardware o software o ambos que está diseñado para ser manejado
[3 *, C1S1] 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
Las auditorías pueden ser llevadas a cabo durante el proceso de configuración [1]. El SCM controla típicamente una variedad de
ingeniería de software para investigar la tus esta- actual de artículos, además del propio código. los elementos de software con
elementos específicos de la configuración o para evaluar la potencial para convertirse en LIC incluye planes, especifi- caciones y
aplicación del proceso de SMC. En-proceso de auditoría de SMC documentación de diseño, pruebas de mate- riales, herramientas de
proporciona un mecanismo mal más para- para el seguimiento de los software, la fuente y el código ejecutable, librerías de código, datos y
aspectos seleccionados del proceso y puede ser coordinado con la diccionarios de datos y documentación para la instalación,
función SQA (ver tema 5, Software configuraciones Auditoría ció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
Identificación 2. Configuración del software controlados.
[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 2.1.3. Software Relaciones elemento de
a utilizar en la adquisición y gestión de elementos controlados. configuración
Estas actividades proporcionan la base para las otras actividades [3 *, c7s4]
de la SCM.
Las relaciones estructurales entre los LIC seleccionados, y sus
partes constituyentes, afectan a otras actividades o tareas 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] de los cambios propuestos. seguimiento adecuado de estas
relaciones también es importante para apoyar la trazabilidad. El
Uno de los primeros pasos en el control del cambio es la identificación de diseño del esquema de identificación para LIC
los elementos de software que deben ser controlados.
Configuración del software 6-7 Gestión

Figura 6.2. Adquisición de artículos

debe considerar la necesidad de asignar elementos identificados a la líneas de base. La línea de base funcional corresponde a los
estructura del software, así como la necesidad de apoyar la requisitos del sistema revisado. La línea de base asignarse los
evolución de los elementos de software y sus relaciones. 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
2.1.4. Versión del software  la hora seleccionada durante el ciclo de vida del software. Cambio
[1, c3] [4 *, c29s3] autoridad de esta línea de base normalmente recae principalmente
en la organización de desarrollo, sino que puede ser compartida
los elementos de software evolucionar como Ceeds pro de proyectos de con otras organizaciones (por ejemplo, SMC o de prueba). La línea
software. Una versión de un elemento de software es una instancia de base del producto se corresponde con el producto de software
identifica- do de un elemento. Puede ser considerado como un estado de para la integración completado entregado sis- tema. Las líneas de
un elemento en evolución. Una variante es una versión de un programa base a utilizar para un proyecto dado, junto con los niveles
resultante de la aplicación de la diversidad soft- ware. asociados de autoridad necesario para la aprobación del cambio,
son Tıpicamente identificado en el SCMP.

2.1.5. Base 
[1, c3]

Una línea de base software es un aprobado formalmente ver- sión de un 2.1.6. La adquisición de elementos de configuración de software
elemento de configuración (con independencia de los medios de [3 *, c18]
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 los elementos de configuración de software se colocan bajo control
término también se utiliza para referirse a una ver- sión particular de un SCM en diferentes momentos; es decir, que se incorporan en una línea
elemento de configuración de software que ha sido acordado. En cualquier de base en particular en un punto particular en el ciclo de vida del
caso, la línea de base sólo puede modificarse a través de procedimientos software. El evento desencadenante es la realización de algún tipo de
trol das a cambios formales. Una línea de base, junto con todos los tarea formal de aceptación, tales como una revisión formal. Figura
cambios aprobados en la línea de base, representa la configuración actual

aprobado. 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
líneas de base utilizados comúnmente incluyen fun- cional, los propósitos de la ilustración solamente; los subíndices usados ​en la
asignado, de desarrollo, y el producto figura indican versiones
6-8 Guía SWEBOK® V3.0

de los elementos cambiantes. La solicitud de cambio de software (SCR) se qué cambios hacer, la autoridad de approv- ing ciertos cambios,
describe en la sección 3.1. el apoyo a la ción ¡Ejecución de esos cambios, y el concepto de
En la adquisición de un SCI, se deben establecer su origen y desviaciones formales de los requisitos del proyecto, así como
integri- dad inicial. Después de la adquisi- ción de un SCI, cambios exenciones de ellos. La información derivada de estas
en el elemento debe ser formalmente aprobado como adecuado para actividades es útil en la medición de tráfico el cambio y la rotura,
el SCI y la línea de base que participan, como se define en el PGCS. así como los aspectos de reproceso.
Después de la aprobación, el elemento se incorpora en la línea de
base software de acuerdo con el procedimiento adecuado.
3.1. Solicitar, evaluar y cambios que aprueba
Software 
[2 *, c9s2.4] [4 *, c29s2]
2.2. software Library
[3 *, c1s3] [4 *, c29s1.2] El primer paso en la gestión de los cambios a los artículos
controlados es determinar qué cambios hacer. El proceso de solicitud
Una biblioteca de software es una colección controlada de software y la de cambio de software (véase un flujo típico de un proceso de
documentación relacionada diseñado para ayudar en el desarrollo de solicitud de cambio en la figura 6.3) proporciona procedimientos
software, uso o mantenimiento [1]. También es fundamental para la formales para la presentación y el registro de las solicitudes de
versión de software agement hombre- y actividades de entrega. Existen cambio, evaluar el costo TiAl poten- y el impacto de un cambio
varios tipos de bibliotecas podrían ser utilizados, cada uno correspondiente propuesto, y aceptar, modificar, difiriendo, o rechazar el cambio
a nivel particular del elemento de software de madurez. Por ejemplo, una propuesto. Una solicitud de cambio (CR) es una petición para
biblioteca de trabajo podría apoyar la codificación y una biblioteca de expandir o reducir el alcance del proyecto; modificar las políticas,
soporte proyecto podría apoyar de Exámenes, mientras que una librería procesos, planes o procedimientos; modificar los costos o
maestra podría ser utilizado para productos termi- nado. Un nivel presupuestos; o horarios Revisar [1]. Las solicitudes de cambios en
adecuado de SCM trol con- (línea de base y el nivel de autoridad para el el software artículos con- figuración pueden ser originados por
cambio asociado) está asociado con cada biblioteca. Seguridad, en cualquier persona en cualquier momento del ciclo de vida del
términos de control de acceso y las instala- copia de seguridad, es un software y pueden incluir una propuesta de solución y la prioridad
aspecto clave de la gestión de la biblioteca. La herramienta (s) que se solicitada. Una fuente de un CR es el inicio de una acción correctiva
utiliza para cada biblioteca debe ser compatible con las necesidades de en respuesta a los informes de problemas. Independientemente de la
control de SMC para esa biblioteca, tanto en términos de control de LIC y fuente, el tipo de cambio (por ejemplo, defecto o mejora) que se
controlar el acceso a la biblioteca. A nivel biblioteca de trabajo, se trata de registra en el CR Software (SCR).
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 Esto proporciona una oportunidad para el seguimiento de
más restringida y SCM es el usuario principal. 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
Estas bibliotecas son también una importante fuente de comprensión de las relaciones entre el software (y, posiblemente, el
información para las mediciones de trabajo y progreso. 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á
3. Control de Configuración de Software los aspectos técnicos y de gestión de la solicitud de cambio y, o
[2 *, c9] [4 *, c29s2] bien aceptar, modificar, rechazar o posponer el cambio propuesto.

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
Configuración del software 6-9 Gestión

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] Un vínculo entre esta capacidad de la herramienta y el sistema de reporte
de problema puede facilitar el seguimiento de soluciones para problemas
La autoridad para aceptar o rechazar los cambios propuestos se detectados.
apoya con una entidad típicamente conocida como un tablero de
control de configuración (CCB). En proyectos más pequeños, esta 3.2. Cambios en el software de aplicación 
autoridad puede residir de manera efectiva con el líder o una persona [4 *, c29]
asignada en lugar de una tabla con varias personas. Puede haber
varios niveles de autoridad cambian dependiendo de una variedad de SCRs aprobados se implementan utilizando los procedimientos de
terios teria, tales como el carácter crítico del tema planteado y la software definidos de acuerdo con los requisitos de programación
naturaleza del cambio (por ejemplo, impacto en el presupuesto y el aplicables. Puesto que un número de SCRs aprobados podría
calendario), o punto actual del proyecto en la vida ciclo. La implementarse de forma simultánea, es necesario proporcionar un
composición de los CCBs se utilizan para un sistema dado varía en medio para el seguimiento que SCRs se incorporan en las
función de estos criterios (un representante SCM siempre estaría versiones de software particulares y líneas de base. Como parte
presente). Todos los interesados, de acuerdo al nivel de la CCB, están del cierre del proceso de cambio, cambios pletó com- pueden
representados. Cuando el alcance de la autoridad de un CCB es someterse a auditorías de configuración y la calidad del software
estrictamente cerámica blandas, que se conoce como una Junta de de verificación-Esto incluye garantizar que se han realizado
Control de Configuración de Software (SCCE). Las actividades de la cambios aprobados. El proceso de solicitud de cambio de software
CCB son típicamente sujetos a auditoría o revisión de calidad del descrito anteriormente por lo general documentará el SMC (y otra)
software. información de aprobación para el cambio.

Los cambios pueden ser apoyadas por herramientas de control de

3.1.2. Software Proceso de Solicitud de Cambio código fuente sión ver-. Estas herramientas permiten a un equipo de

[3 *, c1s4, c8s4] ingenieros de software, o un solo ingeniero de software, para realizar un

seguimiento y documentar los cambios en el código fuente. Estas

Una solicitud de cambio de software eficaz (SCR) proceso requiere herramientas proporcionan un único repositorio para almacenar el código

el uso de herramientas de apoyo y procedi- mientos para originar fuente, puede evitar más de un ingeniero de soft- ware de la edición del

las solicitudes de cambio, enforc- ing el flujo del proceso de mismo módulo, al mismo tiempo, y registrar todos los cambios realizados

cambio, la captura en el
6-10 Guía SWEBOK® V3.0

código fuente. Los ingenieros de software de verificación módulos del sistema de información, la información de estado de configuración para
repositorio, hacer cambios, documentar los cambios, a continuación, ser administrado por los las configuraciones cambiantes deben ser
guarde los módulos editados en el repositorio. Si es necesario, los identificados, recogidos, y mantenido. Diversa información y las
cambios también pueden ser descartados, la restauración de una línea mediciones son necesarias para apoyar el proceso de SMC y para cumplir
de base anterior. herramientas más potentes pueden apoyar el con el estado de con- figuración necesidades de información de gestión,
desarrollo paralelo y entornos distribuidos geográficamente. Estas ingeniería de software, y otras actividades relacionadas. Los tipos de
herramientas se pueden manifestar como aplicaciones información disponibles incluyen la identificación de la configuración
independientes, especializados bajo el control de un grupo aprobada, así como la identificación y tus implementación actual de esta-
independiente SMC. También pueden aparecer como una parte cambios, desviaciones, y las renuncias. Alguna forma de soporte de la
integrada del entorno de la ingeniería de software. Por último, pueden herramienta automatizada es preciso proceder para llevar a cabo la
ser tan elemental como un sistema de control de cambios rudimentaria recogida de datos SCSA y tareas de informes; esto podría ser una
provisto de un sistema operativo. capacidad de base de datos, una herramienta independiente, o una
capacidad de un entorno de herramientas más amplio e integrado.

3.3. Desviaciones y renuncias 


[1, c3]
4.2. Informes de estado de configuración de software 
Las limitaciones impuestas a un software Engineer- esfuerzo ing o las [2 *, c10s2.4] [3 *, c1s5, c9s1, c17]
especificaciones que se producen durante las actividades de desarrollo

podría contener disposiciones que no pueden ser satisfechas en el punto información reportada puede ser utilizado por varios elementos,
designado en el ciclo de vida. Una desviación es un rización autori- escrita, incluyendo los proyectos de organización y el equipo de desarrollo, el
otorgada con anterioridad a la fabricación de un elemento, para apartarse equipo de mantenimiento, gestión de proyectos, y la calidad del
de una actuación en particular o requisito de diseño para un número software activi- dades. Informes pueden tomar la forma de Que- hoc
determinado de unidades o un período específico de tiempo. Una renuncia Ries anuncios para responder a preguntas específicas o la producción
es un diez autorización ESCRITO para aceptar un elemento de periódica de informes prediseñados. Algunos infor- mación producida
configuración o de otro elemento designado que se encuentra, durante la por la actividad contable de estado durante el curso del ciclo de vida
produc- ción o después de haber sido presentado para su inspección, a podría convertirse en los registros de control de calidad.
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 Además de informar el estado actual de la configuración, la
aprobación de las desviaciones de las renuncias, o de, las disposiciones. 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.

4. Configuración de software de contabilidad Estado


[2 *, c10] Auditoría 5. Configuración del software
[2 *, c11]
Software de contabilidad estado de configuración (SCSA) es un
elemento de gestión de la configuración sisting con- del registro y la Una auditoría de software es una examina- ción independiente de un

notificación de la informa- ción necesaria para gestionar una producto de trabajo o conjunto de productos de trabajo para evaluar el

configuración efectiva. cumplimiento de las especificaciones, normas, acuerdos contractuales, u

otros criterios [1]. Las auditorías se llevaron a cabo de acuerdo con un

4.1. Software de información de estado de configuración  proceso bien definido que consiste en diversas funciones y

[2 *, c10s2.1] responsabilidades auditor. En consecuencia, cada auditoría debe ser

cuidadosamente planificado. Una auditoría puede requerir un nú- mero de

Los diseños de actividad SCSA y opera un sis- tema para la captura y personas para realizar una variedad de tareas durante un período

presentación de la información necesaria a medida que avanza el ciclo relativamente corto de tiempo. Herramientas de apoyo

de vida. Como en cualquier


Configuración del software de gestión 6-11

la planificación y realización de una auditoría pueden facilitar enormemente la actividad de desarrollo; esto incluye comunicados internos, así como la
el proceso. distribución a los clientes. Cuando diferentes versiones de un elemento de
auditoría de configuración software determina el grado en que software están disponibles para la entrega (tales como versiones para
un elemento satisface las características funcionales y físicas diferentes formas plataformas o versiones con diferentes capacidades),
requeridas. auditorías informal de este tipo puede llevarse a cabo frecuentemente es necesario volver a crear versiones específicas y
en puntos clave del ciclo de vida. Hay dos tipos de auditorías empaquetar los materiales adecuados para la entrega de la versión. La
formales podrían ser requeridos por el contrato que rige (por ejem- biblioteca de software es un elemento clave en la realización de tareas de
plo, en los contratos que cubren software crítico): la Auditoría liberación y entrega.
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 6.1. Edificio de software 
producto. [4 *, c29s4]

edificio Software es la actividad de la combinación de las versiones

5.1. Software de Auditoría de Configuración Funcional  correctas de los elementos de configuración de software, utilizando los

[2 *, c11s2.1] 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

El propósito de la FCA software es para asegurar que el elemento de sistemas con hardware o firmware, el programa ejecutable se entrega a la

software auditado es consistente con sus especificaciones de gobierno. activi- dad de la capacidad del sistema. Construir instrucciones de

La salida de las mercancías de las actividades de verificación y asegurar que las medidas adecuadas de construcción se toman en la

validación blandos (véase Verificación y validación en el software de secuencia correcta. Además de la creación de software para los nuevos

cali- dad KA) es un insumo clave para esta auditoría. 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

5.2. Auditoría de Configuración física de software se construye a partir de versiones particulares de herramientas de apoyo,

[2 *, c11s2.2] tales como compiladores (véase Fundamentos Piler Com- en los

Fundamentos de Informática KA). Puede ser que sea necesario reconstruir

El propósito de la auditoría de software guración física ción (PCA) es una copia exacta de un elemento de configuración de software

asegurar que la documentación de proyectos y de referencia es previamente construida. En este caso, las herramientas de apoyo y las

consistente con el producto de software como incorporado. instrucciones de construcción asociados deben estar bajo el control de

SMC para garantizar la disponibilidad de las versiones correctas de las

herramientas.

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 Una capacidad de herramienta es útil para la selección de las
cabo durante el proceso de desarrollo para investigar el estado actual de versiones rect angulares del elementos de software para un entorno de
los elementos específicos de la con- figuración. En este caso, una destino dado y para automatizar el proceso de construcción del software
auditoría se podría aplicar a los elementos de línea de base de la muestra de las versiones seleccionadas y datos de configuración apropiados. Para
para asegurar que per- formance es consistente con las especificaciones o proyectos con am- bientes desarrollo paralelos o distribuidos, esta
para asegurar que la documentación evolución sigue siendo compatible capacidad herramienta es necesaria. La mayoría de los entornos de
con el elemento de referencia en desarrollo. 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
6. El software de administración de lanzamientos y gráficos que ocultan gran parte de la complejidad de una instalación de
Entrega acumulación “inteligente”. El proceso de construcción y los productos son
[2 *, c14] [3 *, c8s2] a menudo sub- ject de verificación de la calidad del software. Las salidas
de
En este contexto, lanzamiento se refiere a la distribu- ción de un
elemento de configuración de software fuera
6-12 Guía SWEBOK® V3.0

el proceso de construcción podría ser necesaria para futuras referencias y 7. herramientas de Software
puede convertirse en los registros de control de calidad. [3 *, c26s1] [4 *, c8s2]

6.2. Software de administración de lanzamientos [ 4 *, c29s3.2] 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
gestión de versiones de software abarca la identificación, el apoyo: el apoyo vidual indicación, el apoyo relacionados con el proyecto,
empaquetado, y la entrega de los elementos de un ejemplo de y el apoyo en procesos com- panywide.
producto-para, un programa capaz execut-, documentación, notas de la
versión, y datos de configuración. Teniendo en cuenta que los cambios herramientas de apoyo individual son apropiadas y por lo
de producto pueden producirse de manera continua, una preocupación general suficiente para organizaciones o grupos de desarrollo
por la gestión de la liberación es determinar cuándo deben emitir un de pequeñas y sin variantes de sus productos de software u
comunicado. La gravedad de los problemas abordados por la liberación otras exigencias SCM compleja. Incluyen:
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 • herramientas de control de versiones: pista, documentar y

correctas de esos elementos, dada la aplica- ción previsto del producto. almacenar elementos de configuración individuales como el código

La información documento- ing el contenido físico de un comunicado se fuente y la documentación externa.

conoce como un documento de descripción de la versión. Las notas de • Construir herramientas de manipulación: en su forma más simple,

la versión describen típicamente nuevas capacidades, problemas este tipo de herramientas de compilación y enlace para una versión

conocidos y requisitos de plataforma necesarios para el funcionamiento ejecutable del software. Más herramientas avanzadas de

adecuado del producto. El paquete que se lanzará también contiene construcción extracto de la última versión del software de control de

instrucciones de instalación o actualización. Este último puede ser versiones, realizar comprobaciones de cali- dad, ejecutar pruebas

complicado por el hecho de que algunos usuarios actuales podrían tener de regresión, y producir diversos tipos de informes, entre otras

versiones que son varias las viejas versiones. En algunos casos, la tareas.

administración de liberación puede ser necesario con el fin de realizar un • Cambiar las herramientas de control: sobre todo apoyar el control de

seguimiento de la distribución del producto a varios clientes o Sistemas las solicitudes de cambio y eventos noti- ficación (por ejemplo,

de destino, por ejemplo, en un caso donde se requiere el proveedor para cambios en el estado de solicitud de cambio, los hitos alcanzados).

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 herramientas de apoyo relacionados con el proyecto principal
él. 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.
Se necesita una capacidad de herramienta para apoyar estas
funciones de gestión de versiones. Se uso-ful tener una relación con la herramientas de apoyo en procesos de toda la compañía puede
capacidad de herramienta de apoyo al proceso de solicitud de cambio Tıpicamente automatizar partes de un pro- ceso de toda la compañía,

con el fin de asignar los contenidos de liberación de los SCR que se proporcionando soporte para mentos de flujo de trabajo manage-, roles y

han recibido. Esta capacidad herramienta también puede mantener responsabilidades. Ellos son capaces de manejar muchos artículos, datos

información sobre diversas plataformas de destino y en diversos y ciclos de vida. Estas herramientas se suman el apoyo relacionados con

entornos de clientes. 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
Configuración del software de gestión 6-15

LECTURAS Referencias

Stephen P. Berczuk y Brad Appleton, [1] ISO / IEC / IEEE 24765: 2010 Sistemas y 
Los patrones de software de gestión de configuraciones: Ingeniería de Software-Vocabulario, ISO / IEC / IEEE
el trabajo en equipo, la integración práctica [ 6]. 2010.

[2 *] IEEE Std. 828-2012, Norma para 


Este libro expresa prácticas de SCM y estrategias útiles como patrones. Gestión de la Configuración en Sistemas e Ingeniería
Los patrones pueden ser implementado utilizando diversas herramientas, de Software, IEEE 2012.
sino que se expresa de una manera independiente del instrumento.

[3 *] AMJ Hass, Gestión de la configuración 


Principios y Prácticas, 1ª ed., Addison-Wesley,
“CMMI para el Desarrollo”, versión 1.3, pp. 2003.
137-147 [7].
[4 *] I. Sommerville, Ingeniería de software, noveno
Este modelo presenta una recopilación de las mejores ticas ticas para ed., Addison-Wesley, 2011.
ayudar a las organizaciones de desarrollo de software a mejorar sus
procesos. En el nivel de madurez 2, sugiere actividades de gestión de [5 *] JW Moore, La hoja de ruta de software 
configuración. 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 • Los clientes a menudo no saben lo que se necesita o lo que es


factible.
PMBOK ® Guía para la Dirección de Proyectos del
• Los clientes a menudo carecen de reconocimiento por las
Guía Conocimiento
complejidades inherentes a la ingeniería de software, en particular
SDLC La vida de desarrollo de software de ciclo SEM sobre el impacto de los requisitos de ING cam- bios.

Ingeniería de Software de Gestión de SQA


• Es probable que el aumento de la comprensión y las
Calidad de Software
condiciones cambiantes generarán requisitos nuevos o
Extensión de software para el PMBOK ® modificados de software.
SWX
Guía • Como resultado de cambios en los requisitos, soft- ware se

construye a menudo usando un proceso iterativo en lugar de como


WBS Work Breakdown Structure
una secuencia de tareas cerradas.

• La ingeniería de software incorpora necesariamente las


INTRODUCCIÓN tasas de creatividad y disciplina. El mantenimiento de un
equilibrio adecuado entre los dos es a veces difícil.
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, • El grado de novedad y complejidad es a menudo alta.
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 • A menudo hay una rápida tasa de cambio en la tecnología
software se entregan de manera eficiente, efectiva y en beneficio de los subyacente.
interesados. La disciplina relacionada tienen una gestión es un
elemento importante de todas las áreas de conocimiento (KAS), pero actividades de gestión de la ingeniería de software se producen
por supuesto es más relevante para este KA que a otros KAs. La en tres niveles: gestión de la organización y estructura de
medición es también un aspecto importante de todos los KAs; el tema infraestructura, gestión de proyectos y gestión del programa de
de los programas La medición se presenta en este KA. En un sentido, medición. Los dos últimos se tratan en detalle en esta descripción
debería ser posible para gestionar un proyecto de ingeniería de KA. Sin embargo, esto no es para disminuir la importancia de los
software de la misma manera se gestionan otras actividades problemas de gestión de la organización y de infraestructura. En
complejas. Sin embargo, hay aspectos específicos de los proyectos de general se acepta que los gerentes de ingeniería de software de
software y procesos del ciclo de vida del software que complican la organización deben estar familiarizados con el proyecto manage-
gestión eficaz, incluyendo los siguientes: 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.
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
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 Otro aspecto importante de la gestión de la organización son las
impacto en la ingeniería de software (por ejemplo, políticas de la políticas y procedimientos de gestión de personal para la
organización y los procedimientos que constituyen el marco en el contratación, capacitación y mentor personal ing para el desarrollo
que se llevan a cabo proyectos de ingeniería de software). Estas profesional, no sólo a nivel de proyecto, sino también a la Cess Suc a
normativas y procedimientos de pueden necesitar ser ajustado por más largo plazo de una organización. el personal de ingeniería de
los requisitos de software eficaz Desa-, crear y mantener. Además, software pueden presentar retos de formación o gestión de personal
una serie de políticas específicas para la ingeniería de software único (por ejemplo, el mantenimiento de la moneda en un contexto
puede necesitar estar en su lugar o establecido para la gestión eficaz donde la tecno- logía subyacente sufre un cambio rápido y continuo).
de la ingeniería de software a nivel nizational or-. Por ejemplo, las gestión de la comunicación también se menciona a menudo como un
políticas son generalmente necesarios para establecer procesos de aspecto pasado por alto pero importante del rendimiento de las
toda la organización o procedimientos específicos para tareas de personas en un campo en el que es necesaria la comprensión
ingeniería de software, tales como diseño de software, software de precisa de las necesidades del usuario, requisitos de software y
construc- ción, la estimación, el seguimiento y la presentación de diseños de software. Por otra parte, la gestión de carteras, que pro-
informes. Este tipo de políticas son importantes para la gestión porciona una visión de conjunto, no sólo de software actualmente en
efectiva a largo plazo de los proyectos de ingeniería de software en fase de desarrollo en diversos proyectos y programas (proyectos
toda la organización (por ejemplo, el establecimiento de una base integrados), sino también de software previstas y actualmente en uso
constante por el que analizar los resultados anteriores pro- yecto e en una organiza- ción, se deseable. Además, la reutilización de
implementar mejoras). software es la clave
Ingeniería de Software de Gestión de 7-3

factor en el mantenimiento y la mejora de la productividad y la -gestión de un principio básico de cualquier verdadera


competitividad. reutilización efectiva requiere una visión disciplina inge- niería (ver Medición de las fundaciones
estratégica que refleja las ventajas y desventajas de reutilización. inge- niería KA) -pueden ayudar a mejorar la percepción
y la realidad. En esencia, la gestión sin medición
Además de comprender los aspectos de gestión que son (cualitativa y cuantitativa) sugiere una falta de disciplina,
influenciados de forma única por los proyectos de software, y la medición sin gestión sugiere una falta de propósito o
ingenieros de software deben tener algún conocimiento de los contexto. La gestión eficaz requiere una combinación de
aspectos más generales de gestión que se tratan en este KA ambos medición y experiencia.
(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 Las siguientes definiciones de trabajo se adoptan aquí:
influencia, aunque sea indirectamente, en los procesos de ingeniería
de software de una organización.
• administración es un sistema de procesos y controles
necesarios para lograr los objetivos estratégicos fijados por
Extensa información relativa a la gestión de proyectos de la organización.
software se puede encontrar en el Guía para la Dirección de • Medición se refiere a la asignación de los UE Val- y
Proyectos (PMBOK ® Guía) y el Extensión de software para el etiquetas a los productos de trabajo de ingeniería de
PMBOK ® Guía (SWX) [ 1] [2]. Cada una de estas guías incluye software, los procesos y los recursos más los modelos que
KAs diez proyectos de gestión: gestión de la integración de se derivan de ellos, si estos modelos son desarrollados
proyectos, gestión del alcance del proyecto, gestión del tiempo, usando técnicas estadísticas u otras [3 *, C7, C8].
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 Las secciones de gestión de proyectos de ingeniería de software en
de proyectos, gestión de proyectos y adquisiciones gestión de este KA hacen un amplio uso de la sección de medición de la ingeniería
los interesados ​del proyecto. Cada KA tiene relación directa de software. Esta KA está estrechamente relacionado con otros
con esta Ingeniería de Software de Gestión de KA. miembros de la
Guía SWEBOK, y la lectura de las siguientes descripciones
KA en conjunción con éste será particularmente útil:

La información adicional también se proporciona en las otras


referencias y otras lecturas de este KA. Este Ingeniería de • El Fundamentos de Ingeniería KA describe algunos
Software de Gestión de KA se compone de los cesos de gestión conceptos generales de medición que son aplicables
de proyectos de software pro en los primeros cinco temas en la directamente a la sección de ingeniería de software de
Figura 7.1 (Initiative ción y definición del alcance, Software medición de este KA. Además, los conceptos y técnicas
Proyecto planificación, proyecto de software promulgación, presentados en la sección Análisis estadístico de los
revisión y evaluación, de cierre), además de Ingeniería de Fundamentos de Ingeniería KA se aplican directamente a
Software medición en el sexto tema y herramientas de software muchos temas en este KA.
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 • Los requisitos de software KA se describen algunas de
unidad independiente, y de hecho cada sí posee muchos atributos las actividades que deben ser formados per- durante la
únicos, la estrecha relación que ha llevado al tratamiento fase Volumen defini- ción Iniciación y del proyecto.
combinado en este KA.
• 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
Por desgracia, una percepción común de la industria del software es software de con- figuraciones junto con la administración de la
que los productos de software se Ered deliv- tarde, por encima del versión de software y herramientas de administración y gestión de
presupuesto, de mala calidad y con una funcionalidad incompleta. La software de configu- ración.
medición-informada
7-4 Guía SWEBOK® V3.0

• El Proceso de Ingeniería de Software KA describe los implementación de programas de medición en las


modelos del ciclo de vida del software y las relaciones organizaciones de ingeniería de software;
entre los procesos y productos de trabajo. • 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
• La calidad del software KA hace hincapié en cali- dad como un de ingeniería de software.
objetivo de la gestión y como un objetivo de muchas actividades de

ingeniería de software. 1. Iniciación y Definición del Alcance


• La Ingeniería de Software Economía KA discute cómo tomar
decisiones relacionadas con el software en un contexto El objetivo de estas actividades es de determinación eficaz de los
empresarial. requisitos de software utilizando métodos de obtención variabilidad
ous y la evaluación de la viabilidad del proyecto a partir de una
DISTRIBUCIÓN DE TEMAS PARA LA variedad de puntos de vista. Una vez que se ha establecido la
GESTIÓN DE INGENIERÍA DE viabilidad del proyecto, las tareas restantes en esta sección son los
SOFTWARE ficación speci- de los requisitos y selección de los pro- cesos de
revisión y revisión de requisitos.
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 1.1. La determinación y la negociación de los
basado en la actividad. Esa ruptura se muestra en la Figura 7.1. Los requisitos
elementos del Break-nivel superior mostrado en esa figura son las [3 *, c3]
actividades que se realizan por lo general cuando se está
gestionando un proyecto de desarrollo de software, independiente Determinar y está llevando a cabo los requisitos establecidos de
del modelo de ciclo de vida de desarrollo de software (ver Software negociación de los límites visibles para el conjunto de tareas (ver los
Modelos de Ciclo de Vida de la Ingeniería de Software proceso KA) requisitos de software KA). Las actividades incluyen la obtención de
que ha sido elegido para un proyecto específico. No hay intención requisitos, análi- sis, especificación y validación. Métodos y técnicas
en esta averiado para recomendar un modelo específico del ciclo de deben ser seleccionadas y aplicadas, teniendo en cuenta las diversas
vida. El desglose implica sólo lo que sucede y no implica cuándo, perspectivas de los interesados. Esto lleva a la determinación del
cómo, o cuántas veces se produce cada actividad. Los siete temas alcance del proyecto con el fin de cumplir con los objetivos y
son: satisfacer las restricciones.

1.2. Análisis de viabilidad


• Iniciación y definición del alcance, que se refieren a la [4 *, c4]
decisión de embarcarse en un proyecto de ingeniería de
software; El propósito del análisis de viabilidad es el desarrollo de una descripción
• Software de planificación, que se ocupa de las actividades clara de los objetivos del proyecto y eva- comió enfoques alternativos
llevadas a cabo para preparar un proyecto de ingeniería de con el fin de determinar si el proyecto propuesto es la mejor alternativa,
software exitoso desde el punto de vista de gestión; dadas las limitaciones de la tecnología, los recursos, las finanzas, y las
consideraciones políticas sociales /. Un proyecto inicial y la declaración
• Software promulgación del proyecto, que se ocupa de las del alcance del producto, los entregables del proyecto, las limitaciones
actividades de gestión de la ingeniería de software generalmente de duración del proyecto, y una estimación de los recursos necesarios
aceptados que se producen durante la ejecución de un proyecto de deben estar preparados. Los recursos incluyen un número suficiente de
ingeniería de software; personas que tienen las habilidades necesarias, las instalaciones, la
• Revisión y evaluación, que tratan de garantizar que, infraestructura y el apoyo (ya sea interna o externamente). Análisis de
horario, costo, y las actividades de ingeniería técnica de viabilidad a menudo requiere estimaciones aproximadas de esfuerzo y
calidad son satisfactorios; el coste sobre la base de métodos apropiados (véase la sección 2.3,
• Cierre, que se ocupa de las actividades realizadas para Esfuerzo, Schedule, y el coste de estimación).
completar un proyecto;
• Ingeniería de Software de medición, que se ocupa
del desarrollo efectivo y
Ingeniería de Software de Gestión de 7-5

1.3. Proceso para el examen y revisión de los 2.1. Planificación de procesos 


requisitos [3 *, c3, c4, c5] [5 *, c1]
[3 *, c3]
Software de ciclo de vida de desarrollo (SDLC) els mo- abarcan un
Dada la inevitabilidad del cambio, las partes interesadas deben continuo que va desde predictivo para adaptable (consulte el software
ponerse de acuerdo sobre los medios por los cuales los requisitos y del ciclo de vida Los modelos de la Ingeniería de Procesos de
alcance han de ser examinado y revisado (por ejemplo, procedimientos Software KA). SDLCs predictivos se caracterizan por el desarrollo de
de gestión del cambio, retrospectivas ciclo tivos iteraciones). Esto los requisitos de soft- ware detalladas, la planificación detallada del
implica claramente que el alcance y requisitos no serán “inamovibles”, proyecto, y planificación mínima para la iteración entre fases de
pero pueden y deben ser revisados ​en puntos predeter- MINED como desarrollo. SDLCs adaptativos están diseñados para adaptarse a los
se desarrolla el proyecto (por ejemplo, en el momento en que se crean requisitos de software emergentes y el ajuste iterativo de planes. A
las prioridades de retraso acumulado o al hito comentarios). Si se predictiva SDLC altamente pre- ejecuta los primeros cinco procesos
aceptan los cambios, entonces alguna forma de análisis de trazabilidad enumerados en la figura 7.1 en una secuencia lineal con siones revi- a
y análisis de riesgos se debe utilizar para determinar el impacto de fases anteriores sólo cuando sea necesario. SDLCs tivos
esos cambios (véase la sección 2.5, ment Riesgo Manage-, y Control adaptaciones se caracterizan por ciclos desa- rrollo iterativos. SDLCs
de Configuración de Software en el KA Software Configuration en la gama media de los incrementos SDLC continuum producto de
Management). Un enfoque de cambio administrado también puede funcio- nalidad ya sea en un horario planificada de antemano (en el
formar la base para la evaluación del éxito durante el cierre de un ciclo lado predictivo del continuo) o como los pro- ductos de los ciclos de
incremental o un proyecto completo, basado en los cambios que se desarrollo frecuentemente actualizadas (en el lado de adaptación del
han producido a lo largo del camino (véase el tema 5, Cierre). 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
2. software de planificación deben planificar y adquiridas. Las herramientas pueden incluir
herramientas para la programación de proyectos, los requisitos de
El primer paso en la planificación de proyectos de software debe software, diseño de software, la construcción de software,
ser la selección de un modelo de desa- rrollo ciclo de vida del mantenimiento de software, gestión de configuración de software,
software apropiado y quizá adaptándola basado en el alcance del proceso de ingeniería de software, la calidad del software, y otros. Si
proyecto, los requisitos de software, y una evaluación de riesgos. bien muchas de estas herramientas debe seleccionarse con base
Otros factores que deben consi- Ered incluir la naturaleza del principalmente en las consideraciones técnicas discutidas en otros
dominio de aplicación, complejidad funcional y técnica, y los Kas, algunos de ellos están estrechamente relacionados con las
requisitos de calidad blandos Ware (ver Requisitos de calidad de consideraciones Ment manage- discutidos en este capítulo.
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 2.2. determinar entregables
del software, verificación y validación, opiniones y auditorías (ver la [3 *, c4, c5, c6]
calidad KA software ). Procesos y responsabilidades para la
revisión en curso y la revisión del plan de proyecto y los planes El producto (s) de trabajo de cada actividad de proyecto (por ejemplo, la
relacionados también deben estar claramente establecidos y arquitectura software docu- mentos de diseño, informes de inspección,
acordados. 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 así como por las cuestiones relativas al personal (por ejem- plo, la

terceros para desarrollar las prestaciones debe ser planeada y productividad de las personas y los equipos, la dinámica del equipo, y

proveedores seleccionados (ver sección 3.2, Software de estructuras de equipo).

Adquisición y Gestión de Proveedores de contrato).


2.5. Gestión de riesgos
[3 *, c9] [5 *, c5]
2.3. Esfuerzo, Calendario, y Estimación de costos [ 3 *, c6]
Riesgo e incertidumbre están relacionados pero distintos conceptos. La
incertidumbre resulta de la falta de informa- ción. El riesgo se caracteriza
El rango estimado de esfuerzo requerido para un proyecto, o partes de por la probabilidad de un evento que se traducirá en un impacto negativo
un proyecto, se puede determinar utilizando un modelo de estimación además de una caracterización de los efectos negativos sobre un proyec-
calibrada en base al tamaño y esfuerzo datos históricos (cuando esté ect. El riesgo es a menudo el resultado de la incertidumbre. Lo contrario
disponible) y otros métodos pertinentes, tales como el juicio de expertos de riesgo es la oportunidad, que se caracterizarse por la probabilidad de
y la analogía. dependencias de tareas se pueden establecer y que un evento que tenga se puede producir un resultado positivo. La
oportunidades potenciales para la realización de tareas al mismo tiempo gestión del riesgo implica la identificación de factores de riesgo y análisis
y de forma secuencial pueden ser identificados y documentados de la probabilidad y el impacto poten- cial de cada factor de riesgo, la
mediante un diagrama de Gantt, por ejem- plo. Para proyectos SDLC priorización de los factores de riesgo, y el desarrollo de estrategias de
predictivos, el calendario previsto de tareas con tiempos de inicio mitigación de riesgos para reducir la probabilidad y minimizar el impacto
proyectada, ciones durabilidad y el final de los tiempos se produce negativo si un factor de riesgo se convierte en un problema. métodos de
normalmente durante la planificación. Para proyectos SDLC de evaluación de riesgos (por ejemplo, la opinión de expertos, datos
adaptación, una estimación general de esfuerzo y el horario típicamente históricos, árboles de decisión, y simulaciones de procesos) a veces se
se desarrolló a partir de la comprensión inicial de los requisitos, o, pueden utilizar con el fin de identificar y evaluar los factores de riesgo.
alternativamente, las restricciones sobre el esfuerzo global y el condiciones de abandono del proyecto también se pueden determinar en
calendario puede ser especificado y se utiliza para determinar una este punto de la discusión con todos los interesados. aspectos de
estimación inicial de la nú- mero ciclos y estimaciones del esfuerzo de software única de riesgo, tales como la tendencia ingenieros de software
iterativos y otros recursos asignados a cada ciclo. Recursos necesarios para añadir características que no sean necesarios, o los riesgos
(por ejemplo, personas y herramientas) pueden traducirse en relacionados con la naturaleza intangible del software, puede influir en el
estimaciones de costos. la estimación inicial de esfuerzo, horario, y el riesgo hombre- agement de un proyecto de software. aten- ción
costo es una actividad iterativa que debe ser negociado y revisado entre particular, se debe prestar a la gestión de los riesgos relacionados con
las partes interesadas afectadas hasta que se alcanza consenso sobre los requisitos de calidad de software, tales como la seguridad o la
los recursos y el tiempo disponible para la finalización del proyecto. 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.4. Asignación de recursos


[3 *, c5, c10, c11]

Equipos, instalaciones y personas deben asignarse los que las 2.6. Gestión de la calidad
tareas identificadas, incluyendo el catión alo de responsabilidades [3 *, c4] [4 *, c24]
para la realización de elementos de variabilidad ous de un proyecto
y el proyecto en general. Una matriz que muestra quién es los requisitos de calidad de software deben ser identifi- cado, tal vez en
responsable de, responsables de, consultado sobre, e informado términos cuantitativos y cualitativos, para un proyecto de software y los
sobre cada una de las tareas se pueden utilizar. La asignación de productos de trabajo asociados. Los umbrales para las mediciones de
recursos se basa en, y limitada por la disponibilidad de recursos y calidad aceptables deben establecerse para cada requisito de calidad de
su uso óptimo, como se software basada en las necesidades de las partes interesadas
Ingeniería de Software de Gestión de 7-7

y expectativas. Procedimientos relacionados con el software en ejemplo, diseño de software, código de software y pruebas de software
curso Garantía de Calidad (SQA) y la mejora de la calidad de los casos) se generan.
durante todo el proceso de desarrollo, y para la verificación y
validación del producto software entregable, también deben 3.2. Software de Adquisición y Gestión de Proveedores
especificarse durante la planificación de la calidad (por ejemplo, Contrato
las revisiones e inspecciones técnicas o de- mostraciones de [3 *, c3, c4]
completado funcionalidad, véase la calidad del software KA).
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
2.7. Gestión del plan adquieren los productos de trabajo y entregables con los
[3 *, c4] proveedores que suministran productos o servicios a la organización
de ingeniería de software.
Para proyectos de software, donde el cambio es un tación tivas, los
planes deben ser manejados. Administrar el plan de proyecto por lo Esto puede implicar la selección de los tipos apropiados de
tanto debe ser planificada. Planes y procesos seleccionados para el contratos, como el precio fijo, el tiempo y mate- als, de costo más una
desarrollo de software deben ser controlados de forma sistemática, cuota fija, o el costo más gasto de incentivo. Acuerdos con clientes y
revisados, informaron, y, en su caso, revisada. Planes asociados a los proveedores normalmente, un especifican camente el alcance del
procesos de apoyo (por ejem- plo, la documentación, configuración de trabajo y los Ables deliver- e incluyen cláusulas tales como las
software agement hombre- y resolución de problemas) también sanciones de entrega o de no entrega tardía y acuerdos de propiedad
deberían ser manejadas. Informes, seguimiento y control de un intelectual que especifican lo que el proveedor o proveedores están
proyecto debe encajar dentro de la SDLC seleccionado y las realidades ofreciendo y lo que el adquirente es pagar - ing para, además de lo
del proyecto; planes deben tener en cuenta los diversos artefactos que que será entregado y propiedad del adquirente. Para el software está
serán utilizados para la edad causados ​por el hombre del proyecto. 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
La promulgación 3. Proyecto de Software 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
Durante software del proyecto promulgación (también conocidos como tema [2]).
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 3.3. Implementación de Proceso de medida
logro de los objeti- vos del proyecto. Fundamental para la [3 *, c7]
incorporación son las actividades de gestión en curso de supervisión,
control-ling, y generación de informes. 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.1. Implementación de Planes
[4 *, c2]
3.4. Process monitor
Las actividades del proyecto deben llevarse a cabo en ajustan al [3 *, c8]
plan del proyecto y los planes de apoyo. Recursos (por ejemplo,
personal, tecnología y financiación) son utilizados y productos de La adhesión al plan del proyecto y planes relacionados
trabajo (por debe ser continuamente evaluado y al
7-8 Guía SWEBOK® V3.0

intervalos predeterminados. Además, se deben evaluar los productos y procedimientos de gestión de control de configuración de software y
los criterios pletion com- para cada tarea. Entregables deben ser configuración de software deben ser atendidas (ver el software de
evaluados en términos de sus características requeridas (por ejemplo, a configuración Hombre- agement KA), las decisiones deben ser
través de las inspecciones o mediante la demostración de la documentados y comunicados a todas las partes interesadas, los
funcionalidad de trabajo). gasto esfuerzo, horario de la adherencia, y los planes deben ser revisados ​y revisados ​cuando sea necesario, y los
costes hasta la fecha deben ser analizados, y el uso de recursos datos pertinentes registrados ( véase la sección 6.3, Per- formar el
examinados. El perfil de riesgo del proyecto (ver sección proceso de medició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 3.6. informes
calidad de software en la calidad del software KA). [3 *, c11]

Los datos de medición deben ser analizados (véase Sta- Análisis En especificado y acordado veces, el progreso hasta la fecha se debe
Statistical en los Fundamentos de Ingeniería KA). El análisis de informar, tanto dentro de la organiza- ción (por ejemplo, a un co- mité
varianza basado en la desviación de real de los resultados y valores de dirección del proyecto) y para los colaboradores externos (por
esperados debe ser determinado. Esto puede incluir los excesos de ejemplo, clientes o usuarios). Los informes deben centrarse en las
costes, cronograma deslizamiento, u otras medidas similares. necesidades de información del público objetivo en comparación con
identificación y análisis de los datos de calidad y otra de medición el estado detallado de informes dentro del equipo del proyecto.
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 4. Revisión y Evaluación
la detección del problema e identificación excepción basada en
umbrales que se han superado. Los resultados deben ser En tiempos pre-especificados y según sea necesario, reso general
reportados cuando se han superado los umbrales, o según sea prog- hacia el logro de los objetivos planteados y la satisfacción de las
necesario. 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
3.5. Control de procesos como determinados por las circunstancias.
[3 *, C7, C8]

Los resultados de las actividades de seguimiento de proyectos 4.1. La determinación de satisfacción de los requisitos
proporcionan la base sobre la cual se pueden tomar decisiones. En su [4 *, c8]
caso, y cuando la probabilidad y el impacto de los factores de riesgo
se entienden, se pueden realizar cambios al proyecto. Esto puede Debido a lograr la satisfacción de las partes interesadas es un
tomar la forma de acción correctiva (por ejemplo, volver a probar objetivo principal de la gerente de ingeniería de software, el
ciertos componentes de software); que puede implicar calificación progreso hacia este objetivo debe evaluarse periódicamente. El
incorpora acciones adicionales (por ejemplo, la decisión de utilizar la progreso debe ser evaluado en el logro de los principales hitos del
creación de prototipos para ayudar en software de validación de los proyecto (por ejemplo, la finalización de la arquitectura de diseño
requisitos; ver Prototipos en los requisitos de software KA); y / o de software o la finalización de una revisión técnica de software),
puede implicar la revisión del plan del proyecto y otros documentos oa la conclusión de un ciclo de desarrollo iterativo que se traduce
del proyecto (por ejemplo, los requisitos de software especifi- cación) en un incremento del producto. Las variaciones de los requisitos
para dar cabida a eventos no previstos y sus implicaciones. 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

En algunos casos, el proceso de control puede llevar al


abandono del proyecto. En todos los casos,
Ingeniería de Software de Gestión de 7-9

procedimientos de gestión de configuración de software de control y 5.2. Actividades de cierre


se deben seguir (véase el Software Configuration Management KA), [2, s3.7, S4.8]
las decisiones documentadas y comunicadas a todas las partes
interesadas, los planes de examinar y modificar cuando sea Tras el cierre se haya confirmado, el archivo de los materiales del
necesario, y se registran los datos pertinentes (véase la sección 6.3, proyecto debe llevarse a cabo de acuerdo con los grupos de
realizar el proceso de medición) . 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
4.2. Revisión y Evaluación del desempeño residentes. base de datos de medición de la organización debe
[3 *, c8, c10] actualizarse con los datos relevantes del proyecto. Un proyecto, la
fase o análisis retrospectivo iteración deben llevarse a cabo para
evaluaciones de desempeño periódicas para el proyecto sonal que los temas, problemas, riesgos y oportunidades encontradas
per- pueden proporcionar información en cuanto a la probabilidad pueden ser analizados (ver tema 4, Revisión y Evaluación). Las
de cumplimiento de los planes y procesos, así como posibles lecciones aprendidas deben extraerse del proyecto y se
áreas de dificultad (por ejemplo, conflictos miembros del equipo). introducen en el aprendizaje y la mejora de los esfuerzos de
Los diversos métodos, herramientas y técnicas empleadas deben organización.
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 6. Software de Ingeniería de medición
y gestionados.
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
5. Cierre medi- efectiva se ha convertido en una de las piedras angulares
de la madurez de la organización. La medida puede ser
Un proyecto completo, una fase importante de un proyecto, o un aplicada a las organizaciones, proyectos, procesos y productos
ciclo de desarrollo iterativo alcanza ClO seguro de que cuando se de trabajo. En esta sección se centra en la aplicación de la
han aprobado y completado todos los planes y procesos. Los medida a nivel de proyec- tos, procesos y productos de trabajo.
criterios para el proyecto, la fase o el éxito iteración deberían ser Esta sección sigue el estándar IEEE 15939: 2008 [6], que
evaluados. Una vez que se establece el cierre, de archivo, describe un proceso para definir las actividades y tareas
retrospectivo, y de mejora de procesos actividades se pueden necesarias para implementar un proceso de medición de
realizar. software. El estándar también incluye un modelo de información
de medición.

5.1. Cierre la determinación


[1, s3.7, S4.6]
6.1. Establecer y mantener el compromiso de
El cierre se produce cuando las tareas especificadas para un Medición
proyecto, una fase, o una iteración se han com- pletó logro y [7 *, c1, c2] 2
satisfactoria de los criterios pletion com- ha sido confirmada.
Requisitos de software se pueden confirmar que se cumple o no, • Requisitos para la medición. Cada esfuerzo de medición
y el grado de consecución de los objetivos se pueden debe ser guiada por objetivos de la organización y
determinar. procesos de cierre deben involucrar a las partes accionado por un conjunto de requisitos de medición
interesadas y el resultado en la documentación de aceptación de establecidos por
las partes interesadas; problemas conocidos deben ser
documentados. 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 priorizado. A continuación, un subconjunto de los objetivos que se

organización podrían ser “los primeros en el mercado con abordarán se puede seleccionar, documentado, com- municated, y

nuevos productos”). revisado por los interesados.

• Ámbito de aplicación de la medición. La unidad • Optar por medidas. medidas candidatos deben ser
organizativa a la que cada requisito de medición se va a seleccionados, con claros vínculos con las necesidades de
aplicar debe ser establecido. Esto puede consistir en un informa- ción. Las medidas deben ser seleccionados en base a
área funcional, un solo proyecto, un solo sitio, o toda una las prioridades de las necesidades de información y otros
empresa. criterios tales como coste de la recogida, el grado de
El ámbito temporal de la medición de esfuerzo también interrupción del proceso durante la recogida, la facilidad de
debe ser considerado porque puede ser necesario series obtención, los datos Consistente precisa, y la facilidad de
de tiempo de algunas mediciones; por ejemplo, para análisis y ing informe-. Debido a las características de calidad
calibrar los modelos esti- mación (ver sección 2.3, interna (ver modelos y características de calidad de la calidad
Esfuerzo, ULE Sched-, y estimación de costos). del software KA) a menudo no contenida en los requisitos de
software contractuales, es importante tener en cuenta medi-
• el compromiso del equipo de medición. El compromiso suring la calidad interna del software para proporcionar un
debe establecerse formalmente, comunica, y apoyado indicador temprano de potencial cuestiones que puedan afectar
por los recursos (ver siguiente punto). a las partes interesadas externas.

• Recursos para la medición. El compromiso de una organiza-


ción de medición es un factor esencial para el éxito, como • Definir la recogida de datos, análisis y procedimientos de
lo demuestra la asignación de recursos para implement- ing ING informe-. Esto abarca procedimientos de recogida y
el proceso de medición. Asignación de recursos incluye la horarios, almacenamiento, verifica- ción, análisis, informes y
asignación de responsabili- dad para las diversas tareas del gestión de la configuración de datos.
proceso de medición (tales como el analista y bibliotecario).
ade- cuada financiación, formación, herramientas y apoyo • Seleccione los criterios de evaluación de los productos de
para llevar a cabo el proceso también deben asignarse. 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
6.2. Planificar el proceso de medición  y medir el proyecto.
[7 *, c1, c2]
• Proporcionar recursos para las tareas de medición. El plan de
• Caracterizar la unidad organizativa. La unidad de medición debe ser revisado y aprobado por los interesados
organización proporciona el contexto para la medición, por ​apropiados para incluir todos los procedimientos de recolección
lo que el contexto de la organización debe ser explícita, de datos; procedimientos de almacenamiento, análisis y
incluyendo los straints confirma que la organización presentación de informes; criterios de evaluación; horarios; y
impone en el proceso de medición. La caracterización se responsabilidades. cri- terios para la revisión de estos artefactos
puede afirmar en términos de procesos de organización, deberían haberse establecido a nivel de unidad organizativa o
dominios de aplicación, la tecnología, las interfaces de superior y deben utilizarse como base para estas revisiones.
organización y estructura organizativa. 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
• Identificar las necesidades de información. Información desde ticas ticas actuales. Aprobación demuestra el compromiso
necesidades se basan en los objetivos, limitaciones, con el proceso de medición.
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 • Identificar recursos para poner a disposición para la
identificados y realización del planeado y aprobado
Ingeniería de Software de Gestión 7-11

tareas de medición. La disponibilidad de recursos puede ser Fundamentos de ingeniería KA). Los resultados y
puesta en escena en los casos en que los cambios han de ser conclusiones son generalmente revisados, usando un
pilotado antes del despliegue generalizado. Deberán tener en proceso definido por la organización (que puede ser formal o
cuenta a los recursos necesarios para la implementación exitosa informal). Los proveedores de datos y usuarios de medida
de nuevos procedimientos o medidas. deben participar en la revisión de los datos para asegurarse
de que son significativos y precisos y que puedan dar lugar a
• Adquirir y desplegar tecnologías de apoyo. Esto incluye la acciones razonables.
evaluación de las tecnologías de soporte disponibles, la
selección de las tecnologías más adecuadas, la adquisición • Comunicar los resultados. Los productos de información deben ser
de esas tecnologías, y el despliegue de esas tecnologías. documentados y comunicados a los usuarios y grupos de interés.

6.3. Realizar el proceso de medición [ 7 *, c1, c2] 6.4. evaluar Medición


[7 *, c1, c2]

• Integrar los procedimientos de medición con los procesos de • Evaluar productos de información y el proceso surement medi- contra
software Evant rel. Los procedimientos de medición, tales como especificado Evaluation criterios ación y determinar las
la recopilación de datos, deben integrarse en los procesos de fortalezas y debilidades de los productos de información o
software que se está midiendo. Esto puede implicar cam- ing proceso, respectivamente. La evaluación puede ser realizada por
procesos de software actuales para acomodar la recopilación de un proceso interno o una auditoría nal externamente; que debe
datos de fecha o actividades de generación. También puede incluir la retroalimentación de los usuarios de medición. Las
implicar el análisis de los procesos de soft- ware actuales para lecciones aprendidas deben ser registrados en una base de
reducir al mínimo esfuerzo adicional y la evaluación del efecto datos adecuada.
de los empleados para asegurar que se aceptarán los
procedimientos de medición. problemas de moral y otros • identificar el potencial mejoras. Tal
factores humanos deben ser considerados. Además, los mejoras pueden ser cambios en el formato de los
procedimientos de medición deben ser comu- nicated a los que indicadores, los cambios en unidades medidas, o
proporcionan los datos. También puede ser necesario reclasificación de categorías de medición. Los costos y los
proporcionar formación y apoyo. procedimientos de análisis de beneficios potenciales de las mejoras deben ser
datos y de información están típicamente integrados en los determinados y acciones de mejora apropiadas deben ser
procesos de organización y / o proyecto de manera similar. 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
• Recolectar datos. Los datos deben recogerse, que ha potenciales debe comuni- nicated si el análisis no
comprobado, y se almacenan. Colección veces se puede identifica ninguna mejora.
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 7. Herramientas de Gestión de Ingeniería de Software

los datos y elaborar informes. Los datos pueden ser agregados, [3 *, c5, c6, c7]
transformadas, o recodificados como parte del proceso de
análisis, utilizando un grado de rigor apropiado a la naturaleza de herramientas de gestión de la ingeniería de software a menudo se
los datos y las necesidades de información. Los resultados de utilizan para proporcionar visibilidad y control de los procesos de gestión
este análisis son típicamente indicadores tales como gráficos, de ingeniería de software. Algunas herramientas son automatizados,
números u otras indicaciones que serán interpretadas, resultando mientras que otros son manualmente implementado. Ha habido una
en conclusiones y recomendaciones que se presentará a las tendencia reciente hacia el uso de suites integradas de ingeniería de
partes interesadas (ver Análisis estadístico en el 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 Press, 2009.
PMBOK®) [ 2].
[4 *] I. Sommerville, Ingeniería de software, noveno
SWX ofrece adaptaciones y ampliaciones de las prácticas ed., Addison-Wesley, 2011.
genéricas de gestión de proyectos documentados en el Guía del
PMBOK® para proyectos de software ing manag-. La principal [5 *] B. Boehm y R. Turner, agilidad Equilibrio 
contribución de esta extensión a la Guía del PMBOK® es una y Disciplina: Una Guía de los Perplejos,
descripción de los procesos que son aplicables para la gestión de Addison-Wesley, 2003.
proyectos de software de ciclo de vida de adaptación.
[6] IEEE Std. 15939-2008 La adopción del estándar 
ISO / IEC 15939: 2007 Sistemas y Procesos de
La adopción de la norma IEEE ISO / IEC 15939 [ 6]. Software Ingeniería de Mediciones,
IEEE 2008.
Esta norma internacional identifica un proceso que es compatible con la
definición de un conjunto adecuado de medidas para hacer frente a las [7 *] J. McGarry et al., Practical Software 
necesidades específicas de información. Se identidades FIES las Medición: información objetiva para la Toma de
actividades y tareas que son necesarias para identificar con éxito, definir, Decisiones, Addison-Wesley Professional, 2001.
seleccionar, aplicar y mejorar la medición dentro de un proyecto global o
la estructura organizativa de medición.
[8] J. McDonald, La gestión del desarrollo de 
Los sistemas intensivos de software, John Wiley and Sons, Inc.,
J. McDonald, La gestión del desarrollo de  2010.
Los sistemas intensivos de software, Wiley, 2010 [8].

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

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


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

Lenguaje de Modelado Unificado 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
INTRODUCCIÓN software y modificación. La calidad KA software se ocupa de la
planificación, aseguramiento y control de procesos para el proyecto
Un proceso de ingeniería consiste en un conjunto de actividades y la calidad del producto. Medición y medición de los resultados en
interrelacionadas que transforman una o más entradas en salidas, la Ingeniería Foundation ciones KA son esenciales para la
mientras que consume recursos cumpla cabalmente la evaluación de los procesos de software y control- ling.
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 DISTRIBUCIÓN DE TEMAS DE INGENIERÍA DE
los ingenieros de software para desarrollar, mantener y operar el PROCESOS DE SOFTWARE
software, tales como los requisitos, diseño, construcción, pruebas,
gestión de con- figuración, y otra procesos de ingeniería de software. Como se ilustra en la Figura 8.1, este KA tiene que ver con la definición
Para facilitar la lectura “, la ingeniería de software 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 concluido, incluyendo los criterios de aceptación para el producto del
[1 *, P177] [2 *, P295] [3 *, p28-29, p36, c5] trabajo de salida o productos de trabajo. Un proceso de software
puede incluir subprocesos. Por ejemplo, la validación de los requisitos
Este tema tiene que ver con una definición de proceso de software, de software es un proceso utilizado para determinar si los requisitos
gestión de procesos de software, y la infraestructura de procesos de proporcionarán una base adecuada para el desarrollo de software; es
software. un subproceso del proceso de requisitos de software. Las entradas
Como se mencionó anteriormente, un proceso de software es un para la validación de requisitos son típicamente unos requisitos de
conjunto de actividades y tareas interrelacionadas que transforman los software valor especificado y los recursos necesarios para realizar la
productos de trabajo de entrada en productos de trabajo de salida. Como validación (personal, herramientas de validación, tiempo suficiente).
mínimo, la descripción de un pro- ceso de software incluye entradas Las tareas de la actividad de validación requisitos podrían incluir
requiere, transformar las actividades de trabajo y genera salidas. Como se requisitos de los comentarios, prototipado y validación del modelo.
ilustra en la Figura 8.2, un proceso de software también puede incluir su Estas tareas incluyen las asignaciones de trabajo para las personas y
entrada y criterios de salida y la descomposición de las actividades de equipos. La salida de validación de requisitos suele ser una
trabajo en tareas, que son las unidades más pequeñas de trabajo sujetas especificación de requisitos de software validado que proporciona
a la responsabilidad de gestión. Una entrada de proceso puede ser un entradas para el diseño de software y el software de Exámenes
evento ing Trigger o la salida de otro proceso. Los criterios de ingreso procesos ing. validación de requisitos y otros subprocesos del
deben ser satisfechas antes de que un proceso pueda comenzar. Todas proceso de requisitos de software son a menudo intercalada y
las condiciones especificadas deben ser satisfechas antes de que un reiterada en varias formas;
proceso puede ser con éxito
Software de Ingeniería de Procesos 8-3

Figura 8.2. Elementos de un proceso de software

el proceso de requisitos de software y sus subprogramas, cesos resultado de un enfoque sistemático para accomplish- ing
pueden entraba y salía varias veces durante el desarrollo de procesos de software y producir trabajo Pro- ductos-ya sea a
software o modificación. definición completa de un proceso de nivel individual, proyecto, o el nivel y organizativa para introducir
software también puede incluir las funciones y competencias, TI procesos nuevos o mejorados.
SUP- puerto, técnicas de ingeniería de software y herramientas, y
ambiente de trabajo necesario para llevar a cabo el proceso, así Los procesos se cambian con la expectativa de que un proceso
como los enfoques y medidas (indicadores clave de rendimiento) nuevo o modificado mejorará la eficiencia y / o la eficacia del proceso y
que se utiliza para determinar la la eficiencia y la eficacia de la la calidad de los productos de trabajo resultantes. El cambio a un nuevo
realización del proceso. 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
Además, un proceso de software puede incluir actividades inicia generalmente con el objetivo de mejorar el coste, el desarrollo
tivas técnicas, colaborativas y administraciones intercalados. 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
Notaciones para la definición de procesos de software incluyen listas menudo conducen al cambio organizativo. El cambio de un proceso o la
textuales de actividades que lo componen y las tareas que se describen en introducción de un nuevo proceso puede tener efectos de la ondulación a
lenguaje natural; diagramas de flujo de datos; gráficos de estado; BPMN; lo largo de un orga- nización. Por ejemplo, los cambios en las
IDEF0; redes de Petri; y los diagramas de actividad UML. Las tareas de herramientas informáticas infra- estructura y la tecnología a menudo
transformación dentro de un proceso pueden definirse como procedimien- requieren cambios en el proceso.
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- Los procesos existentes pueden ser modificados cuando otros
ware deben ser seleccionados, adaptados, y se aplican según sea procesos nuevos se despliegan por primera vez (por ejemplo, la
apropiado para cada proyecto y cada contexto de la organización. No hay introducción de una actividad de inspección dentro de un proyecto de
proceso ideal, o un conjunto de procesos, existe. 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
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] acomodar los cambios en el proceso.

Dos objetivos de la gestión de procesos de software son para


darse cuenta de la eficiencia y eficacia que
8-4 Guía SWEBOK® V3.0

1.2. Infraestructura de Procesos de Software adaptación de procesos, y consideraciones prácticas. Un ciclo de vida
[2 *, P183, P186] [4 *, p437-438] de desarrollo de software (SDLC) incluye los procesos de software
utilizados para especificar y transformar los requisitos de software en
El establecimiento, implementación y gestión de procesos de software y un producto de software erable deliv-. Un ciclo de vida del producto
modelos de ciclo de vida del software a menudo se produce en el nivel de software (SPLC) incluye un software de ciclo de vida de desarrollo
de los proyectos de software individuales. Sin embargo, la aplicación de software más procesos adicionales que proporcionan para el
sistemática de los procesos de software y de ciclo de vida del software despliegue, mantenimiento, soporte, la evolución, la jubilación, y
els mo- través de una organización puede proporcionar beneficios a todos los demás procesos inception--a la jubilación para un producto
todos los trabajos de software dentro de la organización, a pesar de que de software, incluyendo la gestión de configuración de software y los
requiere un compromiso a nivel orga- zational. Una infraestructura de procesos de garantía de calidad del software que se aplican a lo largo
proceso de software puede proporcionar definiciones de los procesos, las de un ciclo de vida del software de producto. Un ciclo de vida del
políticas de preting inter y la aplicación de los procesos, y las producto de software puede incluir software PLE ciclos de vida de
descripciones de los procedimientos que se utilizarán para implementar desarrollo múltiples para desarrollar y mejorar el software. procesos
los procesos. Además, una infraestructura de proceso de software puede de software individuales no tienen ningún pedido ral tempo entre
proporcionar financiación, herramientas, ING forma-, y miembros del ellos. Las naves PARENTESCO temporales entre los procesos de
personal que hayan sido asignadas responsabilidades para establecer y software son proporcionados por un modelo de ciclo de vida del
mantener la infraestructura de proceso de software. 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
infraestructura de proceso de software varía, Dependiendo del ciclo de vida se pueden proporcionar directamente o por referencia a
tamaño y la complejidad de la organización y los proyectos llevados otros documentos.
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 Además de transmitir las relaciones temporales y lógicas entre los
ingeniería de software o un comité ing steer-) para supervisar la procesos de software, el modelo de desarrollo de software de ciclo de
aplicación y mejora de los procesos de software. Un error común es vida (o modelos usan dentro de una organización) incluye los
que el establecimiento de una infraestructura de proceso de software mecanismos de control para la aplicación de criterios de entrada y salida
e implementación de procesos de software repetibles añadirá tiempo (por ejemplo, las revisiones del proyecto, el cliente approv- del als, las
y costo para el desarrollo y mantenimiento de software. Hay un costo pruebas de software , umbrales de calidad, onstrations demos-, equipo
asociado con la introducción o la mejora de un proceso de software; de consenso). La salida de un proceso de software a menudo
Sin embargo, expe- riencia ha demostrado que la aplicación de la proporciona la entrada para ERS oth- (por ejemplo, requisitos de
mejora sistemática de los procesos de software tiende a dar lugar a software proporcionan entrada para un proceso de diseño arquitectónico
menor costo mediante la mejora de la eficiencia, Ance Evitar- de software y los cesos de construcción de software y pruebas de software
repetición del trabajo, y el software más fiable y asequible. por lo pro). ejecución concurrente de varias actividades del proceso de
tanto el rendimiento del proceso influye en la calidad del producto de software pueden producir una salida compartida (por ejemplo, las
software. 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. 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
Software de Ingeniería de Procesos 8-5

2.1. Categorías de procesos de software 2.2. Modelos de Ciclo de vida del software 
[1 *, Prefacio] [2 *, p294-295] [3 *, c22-c24] [1 *, c2] [2 *, S3.2] [3 *, S2.1] [5]

Muchos procesos diferentes de software se han definido para su La naturaleza intangible y maleable de software permite una amplia
uso en las diversas partes de los ciclos de vida de desarrollo de variedad de modelos de ciclo de vida del software de desarrollo, que
software de mantenimiento y software. Estos procesos se pueden van desde los modelos lineales en los que las fases de desarrollo de
clasificar como sigue: 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
1. procesos primarios cesos incluir software para pro- desarrollo,
desarrolla software en incrementos de aumentar la funcionalidad en
operación y mantenimiento de software. ciclos iterativos; a los modelos ágiles que normalmente implican
manifestaciones frecuentes de software que trabaja con un
2. apoyar los procesos se aplican de forma intermitente o representante del cliente o usuario que dirige el desarrollo del
continua durante todo el ciclo de vida del producto de software en ciclos iterativos cortos que producen incrementos
software para apoyar cesos pro primarias; que incluyen pequeños de trabajo, software entregable. modelos incrementales,
procesos de software, tales como gestión de la iterativos y ágiles pueden entregar los primeros subconjuntos de
configuración, Ance assur- calidad, y la verificación y software que trabaja en el entorno del usuario, si lo desea. modelos
validación. lineales SDLC se refieren a veces como los modelos de predicción del
3. procesos de organización proporcionar puerto SUP- para la ciclo de vida de desarrollo de software, mientras que SDLCs iterativos
ingeniería de software; que incluyen capacitación, análisis y ágiles se conocen como modelos de adaptación del ciclo de vida de
de medición de procesos, gestión de infraestructuras, desarrollo de software. Cabe señalar que variabilidad actividades de
gestión de cartera y reutilización, mejora de procesos de mantenimiento OU durante una SPLC puede llevarse a cabo
organización y gestión de los modelos del ciclo de vida del utilizando diferentes modelos SDLC, según sea apropiado para las
software. actividades de mantenimiento. Una característica distintiva de los
diferentes modelos de ciclo de vida de desarrollo de software es la
4. procesos entre proyectos, tales como la reutilización, la línea de manera en que se gestionan los requisitos de software. modelos de
productos soft- ware, y la ingeniería de dominio; que involucran a desarrollo del oído Lin- desarrollan típicamente por un juego completo
más de un proyecto de software solo en una organización. 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
procesos de software, además de los mencionados anteriormente requisitos de software se basan en las solicitudes de cambio que son
incluyen los siguientes. procesados ​por un tablero de control de cambios (véase la Solicitud,
los procesos de gestión de proyectos incluyen procesos para la evaluación y aprobación de software Cambios en el Consejo de
la planificación y la estimación, gestión de recursos, medición y Control de Cambios en el Software de Gestión de Con- figuración KA).
control, lo que lleva, la gestión de riesgos, la gestión de las Un modelo incremental produce incrementos sucesivos de traba-
partes interesadas, y que coordinara la primaria, el apoyo, la jando, software entregable basado en la partición de los requisitos de
organización, y entre proyectos de procesos de software Desa-, software para ser implementados en cada uno de los incrementos.
crear y mantener proyectos. Los requisitos de software pueden ser rigurosamente controladas,
como en un modelo lineal, o puede haber cierta flexibilidad en la
procesos de software también se han desarrollado para necesidades revisión de los requisitos de software como el producto de software
particulares, tales como las actividades del proceso que se ocupan de evoluciona. modelos ágiles pueden definir el alcance del producto y
las características de calidad de software (ver la calidad KA Software). de alto nivel incluye inicialmente; Sin embargo, ágil
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.
8-6 Guía SWEBOK® V3.0

modelos están diseñados para facilitar la evolución de los construcción y pruebas) se pueden adaptar para facilitar su manejo
requisitos de software durante el proyecto. Se debe enfatizar Tate, soporte, mantenimiento, migración, y el retiro del software.
que el continuo de SDLCs de lineal a ágil no es una línea Otros factores a tener en cuenta en la definición y la adaptación de
delgada, recta. Elementos de diferentes enfoques pueden ser un modelo de ciclo de vida del software incluyen la conformidad
incorporados en un modelo específico; por ejem- plo, un requerida a las normas, las Directivas y políticas; demandas de los
software de modelo de ciclo de vida de desarrollo incremental clientes; criticidad del producto de software; y organizativo ridad
puede incorporar requisitos de software secuenciales y fases maduración y competencias. Otros factores incluyen la naturaleza
de diseño, pero permitir una gran flexibilidad en la revisión de del trabajo (por ejemplo, modificación del software existen- tes
los requisitos de software y la arquitectura durante la contra nuevo desarrollo) y el dominio de aplicación (por ejemplo, el
construcción de software. espacio aéreo frente a la gestión del hotel).

2.3. La adaptación de procesos de software


[1 *, s2.7] [2 *, p51] 3. Software de Evaluación y Mejora de
Procesos
SDLCs predefinida, SPLCS, y procesos de soft- ware individuales a [2 *, P188, P194] [3 *, c26] [4 *, P397, c15]
menudo necesitan ser adaptados (o “a medida”) para servir mejor a las
necesidades locales. contexto organiza- cional, las innovaciones en la Este proceso de modelos de evaluación de software direcciones tema,
tecnología, el tamaño del proyecto, la criticidad del producto, los ods met evaluación de procesos de software, modelos de mejora de
requisitos normativos, prácticas de la industria, y la cultura corporativa procesos de software, y continua y por etapas clasificaciones de
pueden determinar las adaptaciones necesarias. La adaptación de los proceso. evaluaciones del proceso de software se utilizan para evaluar
procesos de software individuales y los modelos del ciclo de vida del la forma y el contenido de un proceso de software, que podrá ser
software (desarrollo de productos) y puede consistir en añadir más indicada por un conjunto estandarizado de criterios. En algunos casos,
detalles a los procesos de software, actividades, tareas y los términos “evaluación de proceso” y “capacidad de evaluación” se
procedimientos para abordar los problemas críticos. Puede consistir en utilizan en lugar de la evaluación del proceso. evaluaciones de
el uso de un conjunto alter- nar de las actividades que logra el propósito capacidad se realizan típicamente por un adquirente (o adquirente
y los resultados del proceso de software. La adaptación también puede potencial) o por un agente externo en nombre de un adquirente (o
incluir la omisión de los procesos o actividades de software de un adquirente potencial). Los resultados se utilizan como un indicador de
modelo de ciclo de vida del producto o de desarrollo que son si los procesos de software utilizados por un proveedor (o potencial
claramente inaplicables al alcance del trabajo a ser realizado. 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
2.4. Consideraciones prácticas proceso se realizan en los nive- les de organizaciones enteras,
[2 *, p188-190] unidades organizativas dentro de las organizaciones y proyectos
individuales. La evaluación puede incluir temas como evalua- ción si
En la práctica, los procesos y actividades de software a menudo se se están cumpliendo de entrada de proceso de software y terios salida
entrelazan, se superponen, y se aplican concurrente tualmente. Los teria, para revisar los factores de riesgo y la gestión del riesgo, o para
modelos del ciclo de vida del software que especifican los procesos identificar las lecciones aprendidas. evaluación de proceso se lleva a
de software Creta dis-, con criterios de entrada y salida rigurosamente cabo utilizando tanto un modelo de evaluación y un método de
especificadas y los límites e interfaces prescritas, deben ser evaluación. El modelo puede proporcionar una norma para una
reconocidos como idealizaciones que deben adaptarse para reflejar evaluación comparativa
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,
Software de Ingeniería de Procesos 8-7

la comparación entre los proyectos dentro de una organiza- ción y examinar los pasos del procedimiento seguido y los resultados
entre organizaciones. obtenidos, además de los datos relativos a los defectos encontrados y el
Una auditoría de proceso difiere de un proceso de Assessment. Las tiempo requerido para encontrar y corregir los defectos en comparación
evaluaciones se realizaron para determinar niveles de capacidad o con las pruebas de software. Un método típico de proceso de software
madurez y para identificar los procesos de software que ser mejorado. evalua- ción incluye la planificación, determinación de los hechos (por
Las auditorías se realizan normalmente para verificar el cumplimiento collect- pruebas ing a través de cuestionarios, entrevistas y observación
con las políticas y normas. Auditorías proporcionan visibilidad ción de las prácticas de trabajo), la recopilación y validación de los datos del
manage- en las operaciones reales que se lleva a cabo en la proceso, y el análisis y generación de informes. evaluaciones del
organización para que las decisiones precisas y significativas se proceso pueden confiar en el criterio subjetivo, cualitativo del evaluador,
pueden hacer cuestiones ING concern- que están afectando a una o en la presencia objetiva o ausencia de artefactos definidos, registros y
actividad de mantenimiento de desarrollo pro- yecto, o un tema otras pruebas. Las actividades llevadas a cabo durante una evaluación
relacionado con el software. 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
factores de éxito de los procesos de software evalua- ción y pueden emprender para desarrollar calificaciones de capacidad que se
mejora dentro del software Engineer- organizaciones ing incluyen utilizan para hacer recomendaciones para mejoras en el proceso o
buque gestión patrocinio, la planificación, la formación, los líderes pueden llevarse a cabo para obtener una calificación de madurez de los
experimentados y capaces, el compromiso del equipo, gestión de las procesos con el fin de calificar para un contrato o premio. La calidad de
expectativas, el uso de agentes de cambio, además de proyectos los resultados de la evaluación depende del método de evaluación de
piloto y experimentación con herramientas. fac- tores adicionales procesos de software, la integridad y la calidad de los datos obtenidos, la
incluyen la independencia del evaluador y la oportunidad de la capacidad y la objetividad del equipo de evaluación, y las pruebas
evaluación. 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
3.1. Modelos de evaluación de procesos de software la mejora de procesos; la realización de una evaluación de procesos de
[2 *, S4.5, S4.6] [3 *, s26.5] [4 *, p44-48] software siguiendo una lista de comprobación para la conformidad y sin
hacerse una idea agrega poco valor.
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.3. Modelos de mejora de procesos de software 


3.2. Proceso de Software Métodos de evaluación [2 *, p187-188] [3 *, s26.5] [4 *, s2.7]
[1 *, p322-331] [3 *, s26.3]
[4 *, p44-48, s16.4] [6] modelos de mejora de procesos de software enfatiza
tamaño ciclos iterativos de mejora continua. Un ciclo de
Un método de evaluación de procesos de software puede ser mejora de procesos de software general afecta a los
cualitativa o cuantitativa. Las valoraciones cualitativas se basan en subprocesos de medición, lyzing ana- y cambiantes. El
el juicio de expertos; evaluaciones cuantitativas asignar modelo de Plan-Do-Check-Act es un enfoque iterativo bien
puntuaciones numéricas a los procesos de software basados ​en el conocido para la mejora de procesos de software. Las
análisis de pruebas objetivas que indica la consecución de los actividades de mejora incluyen identificar y priorizar mejoras
objetivos y resultados de un proceso de software definido. Por deseadas (planificación); la introducción de una mejora,
ejemplo, una evaluación cuantitativa del proceso de inspección incluyendo la gestión y la formación (hacer) el cambio;
soft- ware puede ser realizada por evaluación de la mejora
8-8 Guía SWEBOK® V3.0

en comparación con los resultados anteriores o ejemplares de visibilidad de los productos de trabajo intermedios y puede ejercer
proceso y costes (control); y hacer modificaciones adicionales (en algún control sobre las transiciones entre procesos. En el nivel 3, un
funciones). El Plan-Do-Check-Act modelo de mejora de procesos se único proceso de software o los procesos en un nivel 3 grupo de
puede aplicar, por ejemplo, para mejorar los procesos de software madurez más el proceso o los procesos en el nivel de madurez 2
que mejoran la prevención de defectos. 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
3.4. Software puntuaciones proceso continuo y puesta en escena 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-
[1 *, p28-34] [3 *, s26.5] [4 *, p39-45] 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,
Software de la capacidad de proceso y software de madurez de los las medidas cuantitativas pueden ser aplicados y utilizados para la
procesos se clasifican normalmente usando cinco o seis niveles para evaluación de procesos; análisis tical estadís- puede ser utilizado. Al
caracterizar la capacidad o madurez de los procesos de software utilizados nivel de madurez 5, se aplican los mecanismos para el proceso
dentro de una organización. UN continuo sistema de calificación implica la continuo de mejoras.
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- representaciones continuos y por etapas se pueden utilizar para
presentación de continua y el proceso de lev- els se proporciona en la determinar el orden en que los procesos de software son un ser
Tabla 8.1 puesta en escena. modelos continuos suelen utilizar un nivel 0 mejorado. En la representación continua, los diferentes niveles de
opinión; por etapas modelos Tıpicamente no lo hacen. 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
Tabla 8.1. Niveles de software proceso de calificación de madurez se lleva a cabo para ese nivel de madurez, lo que
proporciona una base para la mejora de todos los procesos de
La representación La representación por
software en el siguiente nivel superior.
continua de los niveles etapas de niveles de
Nivel
de capacidad madurez

0 incompleta 1
4. Software de medición [ 3 *, s26.2] [4 *, s18.1.1]
realizado Inicial
2 Managed Gestionado

3 definido definido Este proceso de software direcciones tema y medición pro- ducto, la
calidad de los resultados de medición, modelos de información,
cuantitativamente
4 software y técnicas de medición de procesos de software (ver
Gestionado
Medición en los Fundamentos de Ingeniería KA). Antes de que un
5 Optimización nuevo proceso se ejecute o un proceso actual es modificado, los
resultados de medición de la situación actual deben obtenerse a
En la Tabla 8.1, el nivel de 0 indica que un proceso de software se proporcio- nar una línea de base para la comparación entre la
lleva a cabo de forma incompleta o no se puede realizar. En el nivel 1, situación actual y la nueva situación. Para exami- plo, antes de
se está realizando un proceso de software (valoración capacidad), o introducir el proceso de inspección de software, el esfuerzo
se están realizando los procesos de software en un grupo de madurez necesario para reparar defectos descubiertos por las pruebas deben
nivel 1, pero de forma puntual, de manera informal. En el nivel 2, un ser medidos. Después de un período de puesta en marcha ini- cial
proceso de software (valoración capacidad) o los procesos en el nivel después de que el proceso de inspección se introduce, el esfuerzo
de madurez 2 están siendo per- forman de una manera que combinado de la inspección
proporciona una gestión
Software de Ingeniería de Procesos 8-9

además de las pruebas puede ser comparada con la cantidad anterior de documentación de diseño, y otros productos de trabajo relacionados.
esfuerzo requerido para probar solo. consideraciones simi- lar se aplican
si se cambia un proceso. También tenga en cuenta que la eficiencia y la eficacia son
conceptos independientes. Un proceso de software eficaz puede ser
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] 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
procesos de software y medición del producto tienen que ver con la baja eficiencia, en comparación con las expectativas. Un proceso
determinación de la eficiencia y la eficacia de un proceso de software, la eficiente puede ser ineficaz en acompa- plishing la transformación
actividad o tarea. los eficiencia de un proceso de software, la actividad o deseada de los productos de trabajo de entrada en los productos de
tarea es la relación entre los recursos consumidos efectivamente a los trabajo de salida; por ejemplo, el hecho de encontrar y corregir un
recursos esperados o deseados para ser consumidos en el cumplimiento número suficiente de defectos de software durante el proceso de
de un proceso de software, la actividad o tarea (véase la eficiencia en el prueba. Las causas de la baja eficiencia y / o baja efectividad en la
software de Economía Ingeniería KA). Esfuerzo (o el costo equivalente) forma de un proceso de software, la actividad o tarea se ejecuta podría
es la principal medida de los recursos para la mayoría de los procesos incluir uno o más de los siguientes problemas: trabajo de entrada pro-
de software, las actividades y tareas; que se mide en unidades tales ductos deficientes, personal sin experiencia, la falta de herramientas e
como horas-persona-persona, días, semanas, o entre el personal y infraestructura adecuados , el aprendizaje de un nuevo proceso, un
persona-meses de esfuerzo o en unidades monetarias equivalentes-tales producto complejo, o un dominio del producto desconocido. La eficiencia
como euros o dólares. 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
Eficacia es la relación de salida real a la salida esperado representante del cliente, o una nueva política organizativa.
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 En la ingeniería de software, la productividad en per- que forman
medición de los procesos de software effec- tividad requiere la un proceso, actividad o la tarea es la relación de salida producida
medición de los atributos de productos de referencia; por ejemplo, dividida por recursos consumidos; por ejemplo, el número de defectos
la medición de los defectos de software descubierto y corregido de software dis- cubierto y corregida dividida por horas-hombre de
durante pruebas de software. 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
Hay que tener cuidado en la medición de los atributos del proceso de software, activi- dad o la tarea; por ejemplo, el esfuerzo
producto con el fin de determinar la efectividad del proceso. Por requerido para corregir defectos descubiertos durante el software de
ejemplo, el número de defectos detectados y corregidos por la Exámenes deben ser incluidos en la productividad del desarrollo de
prueba no puede alcanzar el número esperado de defectos y por lo software.
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 El cálculo de la productividad se debe tener en cuenta el contexto
inspección aguas arriba recién introducido se ha reducido el en el que se lleva a cabo el trabajo. Por ejemplo, se incluirá el
número restante de defectos en el software. 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
medidas de productos que pueden ser importantes en la pruebas por los desarrolladores de software o en un equipo ágil de
determinación de la eficacia de los pro- cesos de software incluyen la funciones cruzadas. O el cálculo de la productividad puede incluir ya
complejidad del producto, defectos totales, densidad de defectos, y la sea el esfuerzo del software
calidad de los requisitos,
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;
Software de Ingeniería de Procesos 8-11

2. Los resultados calculados para un nuevo conjunto de datos se Técnicas de medición de proceso también proporcionan la
encuentran cerca de los resultados reales de ese conjunto de datos, información necesaria para medir los efectos de las iniciativas de
en cuyo caso los menores se realizan ajustes a los parámetros del mejora de procesos. técnicas surement medi- proceso puede ser
modelo para mejorar el acuerdo; utilizado para recoger datos tanto cuantitativos como cualitativos.

3. Los resultados calculados para los nuevos conjunto de datos y


conjuntos de datos posteriores están muy cerca y no se necesitan 4.4.1. Técnicas de medición de procesos
ajustes en el modelo. cuantitativa
[4 *, S5.1, S5.7, s9.8]
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 El propósito de las técnicas de medición de procesos
aplica el modelo de cambios. Las Metas / Preguntas / Métrica método cuantitativos es recoger, transformar y analizar los datos de
(GQM) fue pensado originalmente para el establecimiento de proceso cuantitativo y producto de trabajo que se puede utilizar
actividades La medición, pero también se pueden utilizar para guiar el para indicar dónde se necesitan mejoras de proceso y para
análisis y mejora de procesos de software. evaluar los resultados de las iniciativas de mejora de procesos.
Técnicas de medición de proceso cuantitativo se utilizan para
Se puede utilizar para guiar la construcción de información de software COL- lect y analizar los datos en forma numérica a la que
modelo de análisis impulsada; resultados obtenidos del modelo de técnicas matemáticas y estadísticas se pueden aplicar.
información de software se puede utilizar para guiar la mejora del proceso.

El siguiente ejemplo ilustra la aplicación del método datos de proceso cuantitativos se pueden recoger como un
GQM: subproducto de los procesos de software. Por ejemplo, el número de
defectos detectados durante las pruebas de software y las horas de
• Meta: Reducir el tiempo medio de solicitud de cambio de personal gastados pueden debe desechar por por medición directa, y la
procesamiento en un 10% dentro de los seis meses. productivi- dad de descubrimiento defecto se pueden derivar por
• Pregunta 1-1: ¿Cuál es el tiempo de procesamiento de solicitud de calculat- defectos ing descubiertos por personal horas. Herramientas
cambio de línea de base? básicas para el control de calidad se pueden utilizar para analizar los
• Métricas 1-1-1: promedio de los tiempos de procesamiento de datos de medición de procesos cuantitativos (por ejemplo, hojas de
solicitud de cambio en la fecha de inicio verificación, diagramas de Pareto, histogramas, diagramas de
• Métricas 1-1-2: Desviación estándar de los tiempos de dispersión, gráficos de series, gráficos de control y diagramas de causa
procesamiento de solicitud de cambio en la fecha de inicio y efecto) (véase el análisis de causa raíz en la Ingeniería fundamentos
• Pregunta 1-2: ¿Cuál es la hora actual de procesamiento de KA). Además, diversas técnicas estadísticas se pueden usar de ese
solicitud de cambio? rango de cálculo de las medianas y los medios para métodos de análisis
• Métricas 1-2-1: promedio de los tiempos de procesamiento de multivariante (ver Análisis estadístico en los Fundamentos de Ingeniería
solicitud de cambio actualmente KA). Los datos recogidos usando proceso cuantitativo medi- técnicas
• Métricas 1-2-2: Desviación estándar de los tiempos de surement también se pueden utilizar como entradas a los modelos de
procesamiento de solicitud de cambio actualmente simulación (ver Modelando, Prototyp- Ing, y Simulación en la Ingeniería
Foundation ciones KA); estos modelos se pueden utilizar para evaluar el
4.4. Técnicas de medición de procesos de software impacto de diferentes enfoques para la mejora 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 Clasificación de defectos ortogonal (ODC) se puede utilizar para
algunos casos, pueden ser necesarios nuevos procesos de analizar los datos Ment medición cuantitativa del proceso. ODC se
software. 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, Además, las herramientas de negocio de propósito general, tal como una

donde un grupo de defectos origi- NATed (ver Defecto Caracterización en hoja de cálculo, puede ser útil. Ingeniería de Software (CASE),

la Soft mercancías Quality KA). defectos interfaz de software, por ejemplo, herramientas de ayuda de computadora pueden reforzar el uso de

pueden haberse originado durante una inade- equiparan proceso de procesos integrados, apoyar la ejecución de las definiciones de procesos

diseño de software; mejorar el proceso de diseño de software reducirá el defi-, y proporcionar orientación a los seres humanos en la formación de

número de defectos de la interfaz de software. ODC puede proporcionar per- procesos bien definidos. herramientas simples, tales como

datos cuantitativos para la aplicación de análisis de causa raíz. Control procesadores de texto y hojas de cálculo se pueden utilizar para preparar

Estadístico de Procesos se puede utilizar para realizar un seguimiento de las descripciones textuales de pro- cesos, actividades y tareas; Estas

la estabilidad del proceso, o la falta de estabilidad del proceso, utilizando herramientas también SUP- puerto de trazabilidad entre las entradas y

gráficos de control. 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

4.4.2. Técnicas de medición de procesos documentación , componentes de software, casos de prueba, y la

cualitativos información de errores. La mayor parte de las áreas de conocimiento en

[1 *, s6.4] este Guía

Cualitativa técnicas- medición de procesos que incluyen


entrevistas, cuestionarios y la opinión de expertos, se puede Describir las herramientas especializadas que pueden ser utilizados para
utilizar para aumentar las técnicas de medición de procesos gestionar los procesos dentro de ese KA. En particu- lar, véase la Gestión
cuantitativos. técnicas de consenso del grupo, incluyendo la de la Configuración de Software KA para una discusión de las
técnica Delphi, se pueden utilizar para obtener un consenso entre herramientas de gestión de configuración de software que pueden ser
los grupos de interesados. 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
5. Proceso de Ingeniería de Software Herramientas [ 1 *, s8.7] 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
herramientas de proceso de software soportan muchas de las notaciones instalaciones de computación en la nube, así como a través de
ciones utilizadas para definir, implementar y gestionar los procesos de infraestructuras dedicadas. Un panel de control de proyectos o en el
software individuales y los modelos del ciclo de vida del software. Incluyen salpicadero pueden dis- proceso seleccionado el juego y los atributos del
editores para anotaciones tales como diagramas de flujo de datos, gráficos producto para proyectos de software e indicar las medidas que están
de estado, BPMN, diagramas IDEF0, redes de Petri, y los diagramas de dentro de los límites de control y aquellos que necesitan una acción
actividad UML. En algunos casos, las herramientas de proceso de software correctiva.
permiten diferentes tipos de análisis y simulaciones (por ejemplo, de

simulación de eventos discretos). En


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 Referencias

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]. Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009.

SWX ofrece adaptaciones y ampliaciones de las prácticas genéricas [2 *] JW Moore, La hoja de ruta de software 
de gestión de proyectos documentado en el Guía del PMBOK® para Ingeniería: Una guía basada en estándares,
la gestión de proyectos de software. La principal contribución de Wiley-IEEE Computer Society Press, 2006.
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 [3 *] I. Sommerville, Ingeniería de software, noveno
software de ciclo de vida de adaptación. ed., Addison-Wesley, 2011.

[4 *] SH Kan, Métricas y modelos de software 


D. Gibson, D. Goldenson, y K. Kost, “Rendimiento de Ingeniería de calidad, 2ª ed., Addison-Wesley,
resultados de mejora de proceso basado en CMMI” 2002.
[6].
[5] Instituto de Gestión de Proyectos e IEEE
Este informe técnico resume públicamente dispo- evidencia Computer Society, Software de la extensión de la Guía
empírica poder sobre los resultados de rendimiento que pueden del PMBOK® quinta edición, ed: Project Management
ocurrir como consecuencia de la mejora de procesos basados Institute, 2013.
​CMMI-. El informe contiene una serie de breves descripciones de
casos que fueron CREADA con la colaboración de representantes [6] D. Gibson, D. Goldenson, y K. Kost,
de 10 organizaciones que han logrado notables resultados de “Rendimiento Resultados de la mejora de procesos
rendimiento cuantitativo a través de sus esfuerzos de mejora basado en CMMI,” Software Engineering Institute,
basados ​en CMMI. 2006; http: // resources.sei.cmu.edu/library/asset-view.
cfm? assetId = 8065 .

CMMI ® para el Desarrollo, Versión 1.3 [ 7].


[7] CMMI equipo de productos, “CMMI para
CMMI ® para el Desarrollo, versión 1.3 proporciona un conjunto Desarrollo, Versión 1.3,”Software Engineering
integrado de directrices para el proceso de ING Desa- y la mejora de Institute, 2010; http: //
productos y servicios. Estas directrices incluyen las mejores prácticas resources.sei.cmu.edu/library/asset-view. cfm?
para el desarrollo y mejora de productos y servicios para satisfacer las assetId = 9661 .
necesidades de los clientes y usuarios finales.
[8] ISO / IEC 15504-1: 2004, Información 
Tecnología-Proceso de Evaluación-Parte 1: Conceptos
ISO / IEC 15504-1: 2004 Información tecno- y vocabulario, ISO / IEC 2004.
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.
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 submodelos y proporciona algunas características generales de
los tipos de modelo comúnmente encontradas en la práctica de la
modelos y métodos de ingeniería de software imponen estructura en ingeniería de software.
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 • El análisis de los modelos: presenta algunas de las técnicas de
modelos proporciona un enfoque para la resolución de problemas, análisis comunes utilizados en ing modelo- para verificar la
una notación, y los procedimientos para la construcción y análisis de integridad, la consistencia, rectness cor-, trazabilidad, y la
modelo. Métodos proporcionan una aproximación a la especificación interacción.
sistemática, diseño, construcción, pruebas y verificación del software • Métodos de software de ingeniería: presenta un breve resumen
de punto final y los productos de trabajo asociados. modelos y de los métodos de ingeniería de software de uso común. La
métodos de ingeniería de software varían ampliamente en su discusión se guía al lector a través de un resumen de los
alcance-de abordar una sola fase del ciclo de vida del software de métodos heurísticos, métodos formales, la creación de
cubrir el ciclo de vida del software pleta com-. El énfasis en esta prototipos, y los métodos ágiles.
á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 El desglose de los temas para los modelos de ingeniería de
de vida están cubiertas por otra KAs. 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 decisiones importantes a otros en las comunidades interesadas.
interesadas pertinentes. Las partes interesadas son aquellas Hay tres principios generales que guían este tipo de actividades de
personas o partes que tienen un interés explícitas o implícitas en el modelado:
software (por ejemplo, usuario, comprador, proveedor, arquitecto,
certificando autori- dad, evaluador, desarrollador, ingeniero de • Modelar los Fundamentos: buenos modelos no suelen
software, y tal vez otros). representan cada aspecto o característica del software bajo
todas las condiciones posibles. Modelado por lo general
Si bien hay muchos lenguajes de modelado, notaciones, implica el desarrollo de sólo aquellos aspectos o
técnicas y herramientas en la literatura y en la práctica, hay que características del software que necesitan respuestas
unifica conceptos generales que se aplican en alguna forma a específicas, abstraerse de cualquier información no esencial.
todos ellos. Las siguientes secciones proporcionan antecedentes Este enfoque mantiene los modelos manejable y útil.
sobre estos conceptos generales.
• Proporcionar Perspectiva: modelado proporciona vistas del
software bajo estudio utilizando un conjunto definido de
1.1. Principios de modelado  normas para la expresión del modelo dentro de cada vista.
[1 *, C2S2, c5s1, c5s2] [2 *, C2S2] [3 *, c5s0] Este enfoque perspectiva- impulsado proporciona
dimensionalidad al modelo (por ejemplo, una vista estructural,
Modelado proporciona al ingeniero de software con un enfoque vista del comportamiento, vista temporal, vista organizativa, y
organizado y sistemático de los aspectos significativos tando otros puntos de vista como relevante). La organización de la
sentantes de software en estudio, facilitando la toma de información en vistas centra los esfuerzos de modelado de
decisiones sobre el software o elementos de la misma, y ​la software en concreto
comunicación de los
Modelos de Ingeniería de Software y Métodos 9-3

preocupaciones pertinentes a la vista mediante las apropiadas Los modelos se construyen para representar objetos del mundo
notación, el vocabulario, métodos y herramientas. real y sus comportamientos para responder a preguntas específicas
acerca de cómo se espera que el software para operar. Interrogar a
• Permitir comunicaciones efectivas: modelado emplea el los modelos, ya sea a través de la exploración, simulación, o
dominio de aplicación del vocabulario del software, un revisión-puede exponer áreas de incertidumbre dentro del modelo y
lenguaje de modelado, y la expresión semántica (en otras el software al que se refiere el modelo. Estas incertidumbres y
palabras, tras tanto dentro del contexto ing). Cuando se utiliza preguntas sin respuesta sobre los requisitos, diseño y / o
de manera rigurosa y sistemática, esta modelado resultado implementación pueden ser manejados de manera apropiada. El
en un enfoque de informes que facilita la comunicación eficaz elemento de expresión primaria de un modelo es una entidad. Una
de la información de software para interesados ​en el entidad puede representar artefactos de hormigón (por ejemplo,
proyecto. 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-
Un modelo es una abstracción o la simplificación de un ciones (en otras palabras, líneas o los operadores textuales en las
componente de software. Una consecuencia del uso de la entidades de destino). Expresión de las entidades modelo se puede
abstracción es que hay una única abstracción completa- mente realizar usando textuales o gráficas lenguajes de modelado; Ambos
describe un componente de software. Por el contrario, el modelo del tipos de lenguaje de modelado se conectan a través de entidades
software se representa como una agregación de abstracciones, que, del modelo de construcciones del lenguaje específicos. El significado
cuando se toman juntos-describir aspectos seleccionados, de una entidad puede ser representado por su forma, atributos de
perspectivas o puntos de vista, sólo aquellos que son necesarios texto, o ambos. En general, la información textual se adhiere a la
para tomar decisiones informadas y responder a las razones de la estructura sintáctica del idioma. Los significados Cise previas
creación de la modelo en el primer lugar. Esta simplificación relacionadas con el modelado de contexto, estructura y
conduce a un conjunto de supuestos sobre el contexto en el que se comportamiento de uso de estas entidades y las relaciones depende
coloca el modelo que también deben ser capturado en el modelo. del lenguaje de modelado utilizado, el rigor del diseño aplicado al
Entonces, al reutilizar el modelo, estos supuestos pueden ser esfuerzo de modelado, la vista específica está construyendo, y la
validados primero en establecer la relevancia del modelo reutilizados entidad a la que el elemento notación específica puede estar unido.
dentro de su nuevo uso y el contexto. Múltiples vistas del modelo pueden ser necesarios para capturar la
semántica necesarios del software.

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 Al usar los modelos soportados con automatización ción, los
distintivas de un modelo en particular utilizados para caracterizar su modelos se pueden comprobará la integridad y consistencia. La utilidad
integridad, la consistencia y exactitud dentro de la notación de modelado de estas comprobaciones depende en gran medida del nivel de rigor
elegido y utillaje utilizado. Propiedades de los modelos incluyen los táctica semántica y sin- aplicada al esfuerzo de modelado en adi- ción
siguientes: al soporte de herramientas explícita. La corrección es Tıpicamente
comprobado a través de la simulación y / o revisión.
• Lo completo: el grado en que se han aplicado todos
los requisitos y comprobada dentro del modelo.
1.3. Sintaxis, la semántica y la pragmática
• Consistencia: el grado en que el modelo no contiene [2 * c2s2.2.2p6] [3 *, c5s0]
requisitos en conflicto, ciones aseveraciones, restricciones,
funciones o descripciones de componentes. 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
• Exactitud: el grado en que el modelo satisface sus conducir a uno en un falso sentido de completa- mente la comprensión
requisitos y el diseño especifi- caciones y está libre de del software de un solo modelo. Un modelo completo ( “completo”
defectos. siendo
9-4 Guía SWEBOK® V3.0

en relación con el esfuerzo de modelado) puede haber una unión de varios puede ser introducido, lo que conduce a errores. Con muchos
submodelos y cualquiera de los modelos de función especiales. El examen ingenieros de software que trabajan en una parte del modelo con el
y la relación tivo de toma de decisiones a un modelo único dentro de esta tiempo junto con las actualizaciones de la herramienta y tal vez nuevas
colección de submodelos pueden ser problemáticos. exigencias, hay oportunidades para partes del modelo para
representar algo diferente de la intención del autor original y el
La comprensión de los significados precisos de constructos contexto modelo inicial.
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 1.4. Condiciones previas, postConditions, e invariantes
que define construcciones len- guaje válidos (por ejemplo, la Forma
Backus-Naur (BNF)). Para lenguajes gráficos, la sintaxis se define [2 *, c4s4] [4 *, c10s4p2, c10s5p2p4]
usando modelos gráficos llamados els metamod-. Al igual que con
BNF, metamodelos definen las construcciones sintácticas válidas Al modelar las funciones o métodos, el ingeniero de software
de un lenguaje de modelado gráfico; metamodelo define cómo suele comenzar con un conjunto de suposiciones sobre el estado
estos constructos se pueden componer para producir modelos del software antes de, durante y después de la función o método
válidos. La semántica de lenguajes de modelado especifican el cutis eje-. Estos supuestos son esenciales para el funcionamiento
significado que se atribuye a las entidades y relaciones capturados rect angular de la función o método y se agrupan, para la
dentro del modelo. Por ejemplo, un diagrama simple de dos cajas discusión, como un conjunto de condiciones previas,
conectadas por una línea está abierto a una variedad de postcondiciones, e invariantes.
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 • Condiciones previas: un conjunto de condiciones que deben ser
modelo. Como cuestión práctica, por lo general hay un buen satisfechas antes de la ejecución de la función o método. Si estas
entendimiento de la semántica de un modelo de software específico condiciones previas no se sostienen antes de la ejecución de la
debido al lenguaje de modelado elegido, cómo se utiliza ese función o método, la función o método pueden producir resultados
lenguaje de modelado para expresar las entidades y las relaciones involuntaria de OU.
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 • Condiciones posteriores: un conjunto de condiciones que se
representado. El significado se com- municated a través del modelo garantiza que sea cierto después de la función o método ha
incluso en presencia de información incompleta a través de ejecutado con éxito. Por lo general, las condiciones posteriores
abstracción; pragmática explica cómo el significado se materializa representan cómo el estado del software ha cambiado, cómo
en el modelo y su contexto y comunicarse efectivamente a otros pará- metros pasados ​a la función o método han cambiado,
ingenieros de software. Todavía hay casos, sin embargo, donde se cómo los valores de datos han cambiado, o cómo se ha visto
necesita cautela ción en relación con el modelado y la semántica. afectado el valor de retorno.
Por ejemplo, las piezas modelo importado de otro modelo o de la
biblioteca deben ser examinados para supuestos semánticos que • invariantes: un conjunto de condiciones dentro del
entran en conflicto en el nuevo entorno de modelado; esto puede entorno operativo que persisten (en otras palabras, no
no ser obvia. El modelo debe ser revisado para supuestos cambie) antes y después de la ejecución de la función o
documentados. Mientras que la sintaxis de modelado puede ser método. Estas invariantes son pertinentes y necesarios
idéntico, el modelo puede significar algo muy diferente en el nuevo para el software y el correcto funcionamiento de la
entorno, que es un contexto diferente. Además, consideran que función o método.
como software madura y se realizan cambios, la discordia
semántica
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
Modelos de Ingeniería de Software y Métodos 9-5

lenguajes de modelado o una sola modelado LANGUAGE. El 2.3. Modelado estructura


Lenguaje de Modelado Unificado (UML) reconoce una rica colección [1 *, c7s2.5, c7s3.1, c7s3.2] [3 *, c5s3] [4 *, c4]
de modelar dia- gramos. El uso de estos diagramas, junto con las
construcciones del lenguaje de modelado, lleva cerca de tres tipos de modelos de estructura ilustran la composición física o lógica de
modelos generales de uso común: los modelos de información, software a partir de sus diversas partes compo- nente. modelado
modelos de comportamiento, y los modelos de estructura (ver sección de estructuras establece el límite definido entre el software en
1.1). 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
2.1. Modelado de Información [ 1 *, c7s2.2] [3 *, c8s1] 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
modelos de información proporcionan un foco central en datos e inter funcionales. diagramas de estructura proporcionados por el
información. Un modelo de información es una representación UML para el modelado de la estructura incluyen clases,
abstracta que identifica y define un conjunto de conceptos, componentes, objetos, despliegue y diagramas de embalaje.
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, 3. Análisis de Modelos
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 El desarrollo de modelos permite el ingeniero de software la
conceptual es una abstracción y, como tal, incluye sólo los oportunidad de estudiar, razonar sobre, y comprender la
conceptos, propiedades, relaciones y restricciones necesarias para estructura, función, uso fun- cional, y las consideraciones de
conceptualizar el punto de vista del mundo real de la información. montaje se asocia a los programas. Es necesario un análisis de los
transformaciones posteriores del modelo de información semántica o modelos construidos para asegurar que estos modelos son
conceptual conducen a la elaboración de modelos de datos, completos, coherentes, y lo suficientemente correcta para servir a
entonces Physicians cal lógico y como se implementa en el su propósito previsto para las partes interesadas. Las secciones
software. 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.
2.2. Modelado del comportamiento
[1 *, c7s2.1, c7s2.3, c7s2.4] [2 *, c9s2]
[3 *, c5s4]
3.1. Para completar el análisis
modelos de comportamiento identifican y definen las fun- ciones del [3 *, c4s1.1p7, c4s6] [5 *, P8-11]
software que está siendo modelado. Tamiento modelos ioral
generalmente tomar tres formas básicas: máquinas de estado, los Con el fin de tener un software que satisfaga plenamente las necesidades
modelos de flujo de control, y Data- modelos de flujo. Las máquinas de de los interesados, la integridad es crítico del proceso de obtención de
estado proporcionan un modelo de software como una colección de requisitos para codificar mentación imple-. Integridad es el grado en el
estados definidos, eventos y transiciones. Las transiciones de software de que todos los requisitos especificados han sido implementado y
un estado a otro por medio de un evento de activación guardado o verificado. Los modelos pueden ser comprobados por la totalidad de una
descuido que se produce en el entorno de modelado. modelos de flujo de herramienta de modelado que utiliza técnicas tales como el análisis
control representan cómo una secuencia de acontecimientos provoca estructural y análisis de espacio de estado de accesibilidad (que aseguran
procesos para ser activado o desactivado. Los datos de flujo tamiento ior que todos los caminos en los modelos de estado se alcanzan por un
se tipifica como una secuencia de pasos donde los datos se mueve a conjunto de entradas correctas); modelos también se pueden examinar
través de procesos hacia almacenes de datos o sumideros de datos. 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 y pseudo-código, código escrito a mano y generado herramienta, casos

una inspección o revisión indican las acciones correctivas necesarias manuales y automatizados de prueba e informes, y archivos y datos. Estos

probables para garantizar la integridad de los modelos. 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

3.2. La consistencia para analizar extendido, hay una necesidad de asignar y controlar estas relaciones de

[3 *, c4s1.1p7, c4s6] [5 *, P8-11] trazabilidad para demostrar los requisitos de software coherencia con el

modelo de software (consulte Requisitos de seguimiento en los requisitos

La consistencia es el grado en que los modelos con- tienen no hay de software KA) y los muchos productos de trabajo. El uso de trazabilidad

requisitos en conflicto, afirmaciones, straints con-, funciones o suele mejorar el manage- ment de productos de trabajo de software y

descripciones de componentes. Típicamente, la comprobación de software de calidad pro- ceso; sino que también proporciona garantías a

consistencia se logra con la herramienta de modelado utilizando una los titulares de stake- que todos los requisitos se han cumplido. La

función de análisis automatizado; modelos también se pueden examinar trazabilidad permite cambiar el análisis una vez que el software es

para consistencia de forma manual mediante inspecciones u otras desarrollado y puesto en libertad, ya que las relaciones a los productos de

técnicas de revisión (ver la calidad KA Software). Al igual que con trabajo de software fácilmente se pueden desplazar para evaluar el

integridad, errores y avisos generados por estas herramientas de análisis impacto del cambio. Las herramientas de modelado suelen proporcionar

y demostrado en una inspección o revisión indicar la necesidad de una alguna automatizado o manual de los medios para espec- ify y gestionar

acción correctiva. 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

3.3. El análisis de la corrección trazabilidad, ver el KA Software Configuration Management).

[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 3.5. Análisis de interacción
corrección sintáctica del modelo (es decir, el uso correcto de la [2 *, c10, c11] [3 *, c29s1.1, c29s5] [4 *, c5]
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 Interacción análisis se centra en las relaciones de las comunicaciones
modelado construye para representar correctamente el significado de o de control de flujo entre entidades utilizadas para llevar a cabo una
que que está siendo modelado). Para analizar un modelo de tarea o función específica dentro del modelo de software. Este
corrección sintáctica y semántica, se analiza que, ya sea de forma análisis plos ines el comportamiento dinámico de las interacciones
automática (por ejemplo, usando la herramienta de modelado para entre las diferentes porciones del modelo de software, incluyendo
comprobar modelo corrección sintáctica) o manualmente (mediante otras capas de software (tal como el sistema oper- ating, middleware,
inspecciones u otras técnicas de revisión) -searching para posibles y aplicaciones). También puede ser importante para algunas
defectos y luego retirar o la reparación de los defectos confirmados aplicaciones de software para examinar las interacciones entre la
antes de que el software está liberado para su uso. 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
3.4. trazabilidad ingeniero de software para revisar el diseño de interacción y verificar
[3 *, c4s7.1, c4s7.2] que las diferentes partes de la obra de software juntos para
proporcionar las funciones previstas.
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
Modelos de Ingeniería de Software y Métodos 9-7

4. Métodos de ingeniería de software diseños de bases de datos o datos de repositorios Tıpicamente

encuentran en software de negocios, donde los datos se gestiona

métodos de ingeniería de software proporcionan un enfoque activamente como un recurso sistemas de negocio o activo.

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 • Análisis y Diseño Orientado a Objetos met ODS-: El modelo
importante para el ingeniero de software para elegir un método o orientado a objetos se representa como una colección de
métodos para la tarea de desarrollo de software a la mano apropiada; objetos que encapsulan datos y las relaciones e interactuar
esta elección puede tener un efecto dramático en el éxito del proyecto con otros objetos a través de métodos. Los objetos pueden
de software. El uso de estos métodos de ingeniería de software, junto ser objetos del mundo real o elementos virtuales. El modelo
con la gente de la derecha conjunto de habilidades y herramientas de software se construye utilizando diagramas para
permiten a los ingenieros de software para visualizar los detalles del constituir vistas seleccionadas del software. refinamiento
software y, finalmente, transformar la representación en un conjunto progresivo del software mode- los conduce a un diseño
de trabajo de código y datos. 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,
métodos de ingeniería de software seleccionados se dis- cussed a donde el código y Envoltorios enfoque para el lanzamiento
continuación. Las áreas temáticas se organizan en las discusiones de los eventual producto de software y el despliegue ing se
métodos heurísticos, Métodos formales, métodos de prototipos, y los expresa.
métodos ágiles.

4.1. Los métodos heurísticos


[1 *, c13, c15, c16] [3 *, c2s2.2, c5s4.1, c7s1,] 4.2. Métodos formales
[1 *, c18] [3 *, c27] [5 *, p8-24]
Los métodos heurísticos son aquellos métodos de ingeniería de
software basados ​en la experiencia que han sido y son bastante Los métodos formales son los métodos de ingeniería de software
ampliamente practicados en el software indus- tria. Esta área temática utilizadas para especificar, desarrollar y verificar el software mediante la
contiene tres grandes categorías: Discusión del análisis estructurado aplicación de un riguroso notación y lenguaje basado camente
y métodos de diseño, métodos de modelado de datos y métodos de mathemat-. A través del uso de un lenguaje de especificación, el
análisis y diseño orientados a objetos. 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
• Análisis estructurado y Métodos Diseño: está relacionado con la sección de análi- sis formal de los requisitos de
El modelo de software se desarrolla principalmente a partir de software KA. Esta sección se ocupa de los lenguajes de especificación,
un punto de vista funcional o conductual, a partir de una vista el refinamiento de programas y de derivación, cationes verificables
de alto nivel del software (incluyendo elementos de datos y de formal, y la inferencia lógica.
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 • Idiomas: Especificación Especificación
muy específicos (con la mano, generado automáticamente, o lenguajes proporcionan la base matemática de un método
ambos), construido, probado y verificado. 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)
• Datos métodos de modelado: El modelo de datos se construye programa- lenguaje ming) utilizado durante la especificación
desde el punto de vista de los datos o informaciones utilizados. de software, análisis de requerimientos, y / o etapas de
Las tablas de datos y barcos PARENTESCO definen los modelos diseño específico para describir la entrada / salida
de datos. Este método mo- datos eling se utiliza principalmente comportamiento. lenguajes de especificación son idiomas no
para definir y analizar las necesidades de datos de apoyo directamente ejecutables; son
9-8 Guía SWEBOK® V3.0

típicamente compuesto de una notación y sintaxis, la semántica 4.3. Los métodos de prototipado
para el uso de la notación, y un conjunto de relaciones permitidos [1 *, c12s2] [3 *, c2s3.1] [6 *, c7s3p5]
para objetos.
• Programa de Perfeccionamiento y Derivación: Pro- gram creación de prototipos de software es una actividad que generalmente
refinamiento es el proceso de creación de un nivel más bajo (o más crea siones ver- incompletas o mínimamente funcionales de una
detallada) especificación utilizando una serie de transformaciones. aplicación de software, por lo general para prueba- ing nuevas
Es a través de sucesivas transformaciones que el ingeniero de características, solicitando información sobre los requisitos de software
software se deriva una representación ejecutable de un programa. o interfaces de usuario, fur- Ther explorar requisitos de software,
Las especificaciones pueden ser refinados, añadiendo detalles diseño de software, o opciones de implementación, y / o la obtención
hasta que el modelo se puede formu- lated en un lenguaje de de alguna otra información útil sobre el software. El ingeniero de
programación 3GL o en una parte ejecutable de la lengua software selecciona un método de creación de prototipos para
especifica- ción elegida. Este refinamiento especificación se hace entender el menos aspectos o compo- nentes del software primero
posible mediante la definición de las especificaciones con entiende; este enfoque es en contraste con otros métodos de
propiedades semánticas precisas; las especificaciones deben ingeniería de software que normalmente comienzan desarrollo con las
establecer no sólo las relaciones entre las entidades, sino también porciones más entendidos primeros. Típicamente, el producto
los significados de tiempo de ejecución exactos de esas relaciones proto-mecanografiada no se convierta en el producto de software final
y operaciones. sin extensa retrabajo desarrollo o la refactorización.

• 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 En esta sección se analiza estilos de creación de prototipos, Tar

de análisis ción o de alcanzabilidad un exploratorios espacio de recibe, y técnicas de evaluación en breve.

estado para demostrar que el diseño de software representado


tiene o conserva ciertas propiedades modelo de inter- est. Un • Estilo de prototipos: Esto se refiere a los diversos enfoques para
ejemplo de comprobación de modelo es un análisis que verifica desarrollar prototipos. prototipos pueden desarrollarse como
programa correcto comporta- ior bajo posible entrelazado de código o productos de papel de usar y tirar, como una evolución
eventos o mensajes llegados. El uso de cationes verificables de un diseño traba- jando, o como una especificación ejecutable.
formales requiere un modelo determinado de forma rigurosa el Diferentes procesos del ciclo de vida de prototipos se utilizan
software y en su entorno operativo; este modelo a menudo normalmente para cada estilo. El estilo CHO-sen se basa en el
toma la forma de una máquina de estados finitos u otro tipo de resultados que necesita el proyecto, la calidad de los
autómata formalmente definido. resultados es necesario, y la urgencia de los resultados.

• Creación de un prototipo de destino: El objetivo de la actividad proto-


• La inferencia lógica: inferencia lógica es un método de diseño tipo es el producto específico que se está servido por el esfuerzo de

de software que implica especificar las condiciones previas y creación de prototipos. Los ejemplos de objetivos de creación de

condiciones posteriores alrededor de cada bloque importante prototipos incluyen una especificación de requisitos, un elemento de

del diseño, y el uso de la lógica del desarrollo de la prueba de diseño arquitectónico o componente, un algoritmo, o una interfaz de

que las condiciones previas y condiciones posteriores deben usuario hombre-máquina.

tener en todas las entradas matemática. Esto proporciona una


manera para que el ingeniero de software para predecir el • Técnicas de Evaluación de prototipos: Un proto- tipo puede
comportamiento del software sin tener que ejecutar el ser usado o evaluado en un nú- mero de maneras por el
software. Algunos entornos de desarrollo integrado (IDE) ingeniero de software u otros interesados ​en el proyecto,
incluyen formas de representar estas pruebas junto con el impulsado principalmente por las razones subyacentes que
diseño o código. 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
Modelos de Ingeniería de Software y Métodos 9-9

un objetivo conjunto de requisitos (por ejemplo, un prototipo • Melé: Este enfoque es más ágil la gestión del medio ambiente
requisitos); el prototipo también puede servir como modelo para que los otros proyectos. El scrum master gestiona las
un futuro esfuerzo de desarrollo de software (por ejemplo, como actividades dentro del proyecto de la subasta; cada incremento
en una especificación de interfaz de usuario). 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,
4.4. Los métodos ágiles  definidas, prioridad, y estima. Una versión traba- jando del
[3 *, c3] [6 *, c7s3p7] [7 *, c6, App. UN] software ha sido probado y puesto en libertad en cada
incremento. Las reuniones diarias de scrum asegurar el trabajo
Los métodos ágiles nacieron en la década de 1990 a partir de la se logró planificar.
necesidad de reducir la gran sobrecarga aparente asocia- dos con el
peso pesado, los métodos basados ​en planes utilizados en los • FDD: Este es un enfoque basado en modelos, corto, iterativo
proyectos de desarrollo de software a gran escala. Los métodos de desarrollo de software tivo usando un proceso de cinco
ágiles son considerados métodos ligeros en cuanto a que se fases: (1) el desarrollo de un modelo de producto a alcance la
caracterizan por ciclos cortos, iteraciones de desarrollo tiva, equipos amplitud del dominio, (2) crear la lista de necesidades o
auto-organizados, los diseños más simples, la refactorización de características, (3 ) construir el plan de desarrollo de
código, desarrollo basado en pruebas, la participación de cliente funciones, (4) el desarrollo de diseños para funciones de
frecuente, y un énfasis en la creación de un trabajo demostrable iteración específica, y (5) de código, prueba, y luego integrar
producto con cada ciclo de desarrollo. Muchos métodos ágiles están las funciones. FDD es similar a un enfoque incremental de
disponibles en la lit- eratura; algunos de los enfoques más populares, desarrollo de software; También es similar a XP, excepto que
que se discuten aquí en breve, incluyen desarrollo rápido de la propiedad del código es asignado a individuos más que el
aplicaciones (RAD), eXtreme Pro- gramación (XP), Scrum, y el equipo. FDD hace hincapié en un enfoque de arquitectura
desarrollo de funciones-Driven (FDD). global para el software, que promueve la creación de la función
correctamente la primera vez en lugar de enfatizar
refactorización continua.

• RAD: métodos rápidos de desarrollo de software se utilizan


principalmente en el desarrollo de aplicaciones sistemas de Hay muchas más variaciones de ods met ágiles en la literatura y en
negocios-intensivo de datos. El método RAD está habilitado con la práctica. Tenga en cuenta que siempre habrá un lugar para los pesos
fines especiales herramientas de desarrollo Base de datos se pesados, métodos de ingeniería de software basados ​en plan, así como
utilizan los ingenieros de software para desarrollar rápidamente, los lugares donde brillan los métodos ágiles. Hay nuevos métodos
probar e implementar aplicaciones nuevas o modificadas de derivados de combinaciones de los métodos ágiles y basadas en el
negocio. plan donde los practicantes están definiendo nuevos métodos que
• XP: Este enfoque utiliza historias o escenarios para las equilibren las características necesarias en ambos métodos de peso
necesidades, desarrolla pruebas en primer lugar, tiene pesado y ligero basado principalmente en las necesidades de negocio
implicación directa con el cliente en el equipo (por lo general la que prevalece zational nizaciones. Estas necesidades de negocio, ya
definición de las pruebas de aceptación), utiliza la programación que por lo general representado por algunos de los interesados ​en el
en parejas, y prevé continua- refactorización código ous e proyecto, deben y no conducir la elección en el uso de método de
integración. Historias se descomponen en tareas, priorizado, ingeniería de software una sobre otra o en la construcción de un nuevo
estimación aparearon, desarrollados, y se ensayaron. Cada ment método de las mejores características de una combinación de métodos
incre- de software se prueba con pruebas automatizados y de ingeniería de software.
manuales; un incremento puede ser liberado con frecuencia,
como cada dos semanas más o menos.
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. Métodos formales,” Computadora, vol. 23, no. 9,
1990, pp. 8, 10-23.
[2 *] SJ Mellor y MJ Balcer, Ejecutable 
UML: La Base para Model-Driven [6 *] JG Brookshear, Ciencias de la Computación: Un 
Architecture, 1ª ed., Addison-Wesley, Visión de conjunto, 10ª ed., Addison-Wesley, 2008.
2002.
[7 *] B. Boehm y R. Turner, agilidad Equilibrio 
[3 *] I. Sommerville, Ingeniería de software, noveno y Disciplina: Una Guía de los Perplejos,
ed., Addison-Wesley, 2011. 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


embargo, estas definiciones hacen hincapié en que la calidad
Despliegue de la Función Calidad SPI
depende de los requisitos. Estas definiciones se ilustran también
Software SQA Mejora de Procesos
otra razón de la prevalencia de la calidad del software lo largo de
Software Quality Assurance SQC 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 ("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
INTRODUCCIÓN también pueden especificar el uso de recursos, un protocolo de
comunicación, o muchas otras características. Este KA intenta claridad
¿Cuál es la calidad del software, y por qué es tan impor- tante que mediante el uso de la calidad del software en el sentido más amplio de
se incluye en muchas áreas de conocimiento (KAS) de la Guía las definiciones anteriores y mediante el uso de los requisitos de calidad
SWEBOK? de software como con- straints sobre los requisitos funcionales. La
Una de las razones es que el término la calidad del software está calidad del software se logra mediante la conformidad con todos los
sobrecargado. La calidad del software puede referirse: a deseable requisitos, independientemente de lo que es característico manera
características capaces de productos de software, en la medida en especificada o cómo se agrupan o se nombra requisitos. La calidad del
que un determinado posi- producto de software sess esas software también se considera en muchos de los SWEBOK KAs porque
características, y para procesos, herramientas y técnicas utilizadas es un eter param básica de un esfuerzo de ingeniería de software. Para
para lograr esas características. Con los años, los autores y todos los productos neered nieros, el objetivo principal es ofrecer un
organizaciones han definido el término calidad diferente. Para Phil valor máximo de las partes interesadas, mientras que el equilibrio de las
Crosby, que era “la conformidad con los requisitos” [1]. Watts limitaciones de costo y cronograma de desarrollo; esto a veces se
Humphrey refiere a él como “lograr excelentes niveles de‘aptitud caracteriza como “aptitud para
para el uso’[2]. Entre tanto, IBM acuñó la frase “impulsada por el
mercado

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 los muchos aspectos de la calidad se definirán y discutirán
productos de software, los interesados ​podrían valorar el precio (lo que formalmente.
pagan por el producto), tiempo de espera (la rapidez con que reciben el Un ingeniero de software debe entender los conceptos cali-
producto), y la calidad del software. dad, las características, valores y su aplicación al software
bajo desarrollo o mantenimiento. El concepto importante es
Esta KA aborda las definiciones y proporciona una visión general que los requisitos de software definen los atributos de calidad
de las prácticas, herramientas y técnicas para la definición de la requeridos del software. Requisitos de software influyen en los
calidad del software y para valorar el estado de la calidad del software métodos de medición y los criterios de acep- tación para
durante el desarrollo, mantenimiento y despliegue. Las referencias evaluar el grado en que el software y la documentación
citadas proporcionan detalles adicionales. relacionada a alcanzar los niveles de calidad deseados.

DISTRIBUCIÓN DE TEMAS PARA LA CALIDAD


DEL SOFTWARE 1.1. Software de Ingeniería de la Cultura y Ética
[3 *, c1s4] [6 *, c2s3.5]
El desglose de los temas de la calidad del software KA se
presenta en la figura 10.1. Se espera que los ingenieros de software para compartir un
compromiso para la calidad del software como parte de su cultura. Una
1. Fundamentos de Calidad de Software cultura de ingeniería de software saludable incluye muchas
características, incluyendo el entendimiento de que los equilibrios entre
Llegar a un acuerdo sobre lo que constituye la calidad de todos los costes, plazos y calidad son un principio básico de la ingeniería de
grupos de interés y la comunicación clara de ese acuerdo a los cualquier pro- ducto. Una ética fuerte de ingeniería de software asume
ingenieros de software que requieren
La calidad del software 10-3

que los ingenieros informan con precisión la información, con- producto de software para el cliente. costos ure Fail externos incluyen
diciones, y los resultados relacionados con la calidad. La ética actividades para responder a problemas de software descubiertas
también juegan un papel importante en la calidad del software, la después de la entrega al cliente. Los ingenieros de software deben ser
cultura, y las actitudes de los ingenieros de software. El IEEE capaces de utilizar métodos cosq para determinar los niveles de calidad
Computer Society y la ACM han desarrollado un código de ética y del software y también deben ser capaces de presentar alternativas de
la práctica pro- fesional (ver Códigos de Ética y Conducta calidad y sus costes de manera que se pueden realizar compensaciones
Profesional de la Ingeniería de Software KA Práctica Profesional). entre costo, horario, y la entrega de valor para los accionistas.

1.2. Valor y costos de la Calidad 1.3. Modelos y características de calidad


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

Definir y luego la consecución de la calidad del software no es Terminología para características de calidad de software difiere de
simple. Las características de calidad pueden o pueden no ser una taxonomía (o modelo de la calidad del software) a otro, cada
necesarios, o se les puede pedir a un mayor o menor grado, y las modelo tal vez tener un número diferente de niveles jerárquicos y un
compensaciones se pueden hacer entre ellos. Para ayudar a número total diferente de características. Varios autores han
determinar el nivel de calidad del software, es decir, el logro de producido modelos de características de calidad de software o
valor para los accionistas, esta sección presenta coste de la calidad atributos que pueden ser útiles para la discusión, la planificación, y
del software (cosq): un conjunto de medidas derivadas de la la calificación de la calidad de los productos de software. ISO / IEC
evaluación económica de los procesos de desarrollo y 25010: 2011 [4] define la calidad del producto y la calidad en uso
mantenimiento de software de calidad. Las mediciones cosq son como dos modelos de calidad relacionados. Apéndice B en el Guía
ejemplos de mediciones de proceso que pueden utilizarse para SWE- BOK proporciona una lista de las normas aplicables para cada
inferir carac- terísticas de un producto. KA. Normas de este KA cubren diversas formas de caracterizar la
calidad del software.

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 1.3.1. Calidad de Procesos de Software
de la mala calidad. La mala calidad significa que el producto de
software no totalmente “satisfacer necesidades expresadas o gestión de la calidad del software y la calidad de los procesos niería
implícitas” o Hay cuatro categorías de calidad coste de “estable- ció de software niería tienen una influencia directa en la calidad del
requisitos.”: prevención, evaluación, fallo interno y externo fracaso. 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,
Los costos de prevención incluyen inversiones en los esfuerzos de están cubiertos en el Proceso de Gestión de Ingeniería de Software
mejora de procesos de software, infra- estructura de calidad, herramientas e Ingeniería de Software de Kas.
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 No es posible distinguir por completo la calidad del proceso de la
proyecto que encuentran defectos. Estas actividades de evaluación se calidad del producto debido a los resultados del proceso incluyen
pueden clasificar en los costos de los exámenes (diseño, pares) y los productos. La determinación de si un proceso tiene la capacidad de
costos de las pruebas (pruebas software de la unidad, de integración de productos Duce consistentemente pro de la calidad deseada no es
software, pruebas de nivel de sistema, pruebas de aceptación); los costos simple. El proceso de ingeniería de software, discutido en el proceso
de evaluación se extenderían a los proveedores de software de ingeniería de software KA, las influencias de las características de
subcontratados. Los costos de fallos internos son los que se incurre para calidad de software pro